5G delay tolerant data services

Abstract

The invention relates to 5G delay tolerant data services. Methods and apparatus are described herein for a 5G system that deploys and provides optimized services and value-added services based on a delay tolerant data (DTD) exchange between a final device and a machine-to-machine (M2M) server. According to one embodiment, a device may receive information including a delay-tolerant communication configuration from a second device via a network, the delay-tolerant communication configuration including an identifier and a delay-tolerant feature. The apparatus may receive data in a plurality of data bundles from a third apparatus, each data bundle including an identifier. The apparatus may process the plurality of data bundles based on the first information. The apparatus may route the plurality of data bundles based on the first information. The third apparatus may include a user equipment (UE).

Description

[0001] This application is a divisional application of the invention patent application with application date of July 2, 2019, application number 201980051415.2, and invention name “5G Delay Tolerant Data Service”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 693,108, filed on July 2, 2018, which is incorporated herein by reference in its entirety. Background Art

[0004] Internet of Things (IoT) devices may sometimes send information as delay tolerance regarding how long it will take for data to reach a service capability server (SCS). In a system where low-cost IoT devices use relays to communicate with one or more machine-to-machine (M2M) servers, the data sender may not immediately know when and if its data arrives at the destination, and may not always know the best repeater to forward its data to. This can result in duplicate copies of the data being sent to the destination. In addition, the same data bundle may be transmitted to multiple repeaters, resulting in multiple copies that only the endpoint can resolve. These copies use network resources unnecessarily before reaching the endpoint. If only a single copy is sent from the end sensor, delivery to the endpoint is unlikely to be successful. There may be no available information within the network (except at the SCS) that allows other nodes to eliminate duplication. Therefore, network resources are wasted.

[0005] Thus, there is a need to optimize network resources when handling delay tolerant data (DTD) traffic and to transmit DTD information in order to identify delay tolerant traffic and provide services based on the unique characteristics of this traffic. Summary of the invention

[0006] This summary is provided to introduce some concepts in a simplified form, which will be further described in the detailed description below. This summary is neither intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that address any or all disadvantages noted in any part of this disclosure.

[0007] This article describes a method and apparatus for a 5G system that deploys optimized services and value-added services based on the exchange of delay-tolerant data (DTD) between end devices and machine-to-machine (M2M) servers. Remote user equipment (UE) or capillary devices can often exchange DTD with M2M servers via repeaters. Services in the 5G core network and repeaters can identify delay-tolerant traffic and provide reliable delivery, path optimization, prioritization, and other value-added functions.

[0008] According to one embodiment, a device may receive first information including a delay tolerant communication configuration from a second device via a network, the delay tolerant communication configuration including an identifier and a delay tolerant feature. The device may receive data in a plurality of data bundles from a third device, each data bundle including an identifier. The device may process the plurality of data bundles based on the first information. The device may route the plurality of data bundles based on the first information. The third device may include a user equipment (UE). BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In order to promote a more robust understanding of the present application, reference is now made to the accompanying drawings, in which like elements are referenced with like reference numerals. These drawings should not be construed as limiting the present application, but are merely illustrative.

[0010] Figure 1 is a diagram of an example non-roaming reference architecture for a 5G system with service-based interfaces in the control plane;

[0011] Figure 2 is a diagram of an example architecture model using 3GPP Proximity Services (ProSe) UE to Network Relay Entity;

[0012] Figure 3 is a diagram of an example procedure for direct communication via a ProSe UE to network relay for a remote UE;

[0013] Figure 4 is a diagram of an example process for requesting monitoring of a temporary mobility group identity (TMGI);

[0014] Figure 5 is an example system for a delay tolerant data UL use case;

[0015] Figure 6 is a diagram of an example 5G architecture depicting DTDS@CN functionality as a standalone NF or an integrated NF, which may be used in conjunction with any of the embodiments described herein;

[0016] Figure 7 is a diagram of an example DTDS deployment;

[0017] Figure 8 is a diagram of an example procedure for DTDS configuration and establishment at a CN and a relay UE;

[0018] Fig. 9 is a diagram of an example process for UL delay tolerant data sent by a remUE to an SCS / AS via a relay UE and a CN, which may be used in conjunction with any of the embodiments described herein;

[0019] Fig.10is a diagram of an example process 1000 for DL ​​delay tolerant data sent by an SCS / AS to a remUE via a CN and a relay UE, which may be used in conjunction with any of the embodiments described herein;

[0020] Fig.11 is an example procedure for group or MBMS delay tolerant data sent by the SCS / AS to the remUE via the CN and relay UE, which may be used in conjunction with any of the embodiments described herein;

[0021] Fig.12 is a diagram of an example graphical user interface (GUI);

[0022] Fig.13A An example communication system is illustrated;

[0023] Fig. 13B is a system diagram of an example RAN and core network;

[0024] Fig. 13C is another example system diagram of RAN and core network;

[0025] Fig.13D is another example system diagram of RAN and core network;

[0026] Fig.13E Another example communication system is illustrated;

[0027] Fig.13F is a block diagram of an example apparatus such as a WTRU; and

[0028] Figure 13G is a block diagram of an exemplary computing system. DETAILED DESCRIPTION

[0029] Methods and apparatus for Delay Tolerant Delay Service (DTDS) are described herein. The methods and apparatus described herein are directed to enablers for Delay Tolerant Data (DTD) processing for DTDS implemented via DTD tags associated with DTD bundles and within a 5G core network (5GC) (e.g., via DTDS@CN) and in a repeater (e.g., via DTDS@UE). Methods for DTDS@CN and DTDS@UE configuration and initialization, methods for DTD UL and DL delivery, and methods for delivering value-added delay tolerant services are also described herein.

[0030] Internet of Things (IoT) devices may sometimes send information that is delay tolerant in terms of how long it takes for data to reach a Service Capability Server (SCS). In order to optimize network resources, the SCS should be able to tell the Core Network (CN) whether the data source is delay tolerant. When UL DTDs are sent via repeaters, the network may receive duplicate information. If a relay goes in and out of coverage, then confirmation of end-to-end data delivery may not be delivered and unnecessary retransmissions may occur. The CN needs to be configured with DTD-specific information in order to identify delay tolerant traffic and provide services based on the unique characteristics of this traffic, such as: aggregation, advanced filtering and / or pre-processing near the edge; reliability assistance through partial confirmation of data reception along the communication path, error correction, or transmission redundancy; assistance with data path optimization and evaluation of communication performance; and prioritization, quality of service (QoS) and charging assistance using rules and policies associated with the DTD.

[0031] As used herein, the term service provider may refer to a stakeholder (eg, a company) that is responsible for the deployment and management of application server(s) (AS) and the services provided through the AS.

[0032] As used herein, the term data bundle may refer to information exchanged between peer entities as a single unit in a delay-tolerant data exchange, regardless of its payload type. In a 5G system, a data bundle may include one or more packet data units (PDUs). A data bundle may have an identifier associated with it. If a data bundle does not have an identifier associated with it, then a network node or base station may determine whether two received data bundles are the same by comparing the sender, the receiver, the data, the hash of the sender, the hash of the receiver, and / or the hash of the data. A data bundle identifier may be assigned by a UE and may be attached to the data bundle when the data bundle is sent to the network.

[0033] The following is a list of acronyms related to the techniques that may be used in the examples described in this article:

[0034]

[0035]

[0036] Figure 1 is a diagram of an example non-roaming reference architecture 50 for a 5G system with service-based interfaces in the control plane. Figure 1 UDSF, NEF and NRF are not depicted, but all network functions (NFs) shown can interact with UDSF, UDR, NEF and NRF. Figure 1, a UE 72 is able to access an access and mobility management function (AMF) 67 via a radio access network (RAN) 73 through an N1 interface 69. A Namf interface 64 is also shown. The RAN 73 is able to access the AMF 67 via an N2 interface 70. The RAN 73 is able to access a user plane function (UPF) 75 via an N3 interface 74. The UPF 75 is able to access a session management function (SMF) 68 via an N4 interface 71. An Nsmf interface 65 is also shown. The UPF 75 is able to access a data network (DN) 77 via an N6 interface 76.

[0037] Figure 1 The example also shows other NFs within the control plane, such as the network exposure function (NEF) 52 and the Nnef interface 58, the NF repository function (NRF) 53 and the Nnrf interface 59, the policy control function (PCF) 54 and the Npcf interface 60, the unified data management (UDM) 55 and the Nudm interface 61, the application function (AF) 56 and the Naf interface 62, and the authentication server function (AUSF) 66 and the Nausf interface 63, and the network slice selection function (NSSF) 51 and the Nnssf interface 57. The mobility management and session management functions can be separated. A single N1 69 non-access stratum (NAS) connection can be used for both registration management and connection management, and for session management related messages and processes for the UE. A single N1 69 termination point can be located in the AMF 67, which can forward NAS information related to session management to the SMF 68. The AMF 67 can handle the registration management and connection management parts of the NAS signaling exchanged with the UE 72. The SMF 68 may handle the session management portion of the NAS signaling exchanged with the UE 72. User plane data may flow between the UE 72 and the UPF 75 via the N3 interface 74. Control plane data between the UE and the core network flows between the UE and the AMF via the N1 interface 69.

[0038] In 5GC, network slicing is a mechanism that can be used by mobile network operators in 5G to support multiple virtual networks behind the air interface across the fixed part of the mobile operator network, where the network can include a backhaul network and a core network. This may involve slicing the network into multiple virtual networks to support different RANs or different service types running across a single RAN. Network slicing can enable operators to create customized networks to provide optimized solutions for different market scenarios that may require various requirements (for example, in terms of functionality, performance, and isolation). A network slice instance can consist of a collection of NFs and the resources to run these NFs. Some NFs (or groups of NFs) can be shared by multiple network slice instances.

[0039] 3GPP 5G networks can incorporate network slicing technology. Network slicing technology can meet the very diverse and extreme requirements required by various 5G use cases (e.g., massive IoT, critical communications, and enhanced mobile broadband). Pre-5G architectures can utilize a relatively single network and transport framework to accommodate a variety of services, such as mobile traffic from smartphones, over-the-top (OTT) content, feature phones, data cards, and embedded M2M devices. It is expected that when pre-5G architectures each have a specific set of performance, scalability, and availability requirements, they are not flexible enough and scalable enough to efficiently support a wider range of business needs. In addition, the introduction of new network services can be made more efficient. However, it is expected that multiple use cases will be activated concurrently in the same operator network, requiring 5G networks to have a high degree of flexibility and scalability.

[0040] Network slicing can enable operators to create customized networks to provide optimized solutions for different market scenarios that may require various requirements (for example, in terms of functionality, performance, and isolation).

[0041] Figure 2 is a diagram of an example architecture model 200 using a 3GPP Proximity Services (ProSe) UE to network relay entity. Figure 2 In the example of , the ProSe UE to network relay entity 202 may provide functionality to support connectivity to a network (e.g., an evolved packet core (EPC) 204) for a remote UE 201, for example, via a PC5 interface 210. The ProSe UE to network relay entity 202 may access an evolved Node B (eNB) 203 via a Uu interface 211. The public security AS 205 accesses the EPC 204 via an SGi interface 212. The ProSe UE to network relay 202 may relay unicast traffic (downlink (DL) and / or uplink (UL)) to / from the remote UE 201. The ProSe UE to network relay 202 may relay evolved Multimedia Broadcast Multicast Service (eMBMS) traffic using one-to-many ProSe direct communication.

[0042] Figure 3 is a diagram of an example process 300 for direct communication via a ProSe UE to network relay for a remote UE. Figure 3In the example of , a UE capable of ProSe UE-to-network relay may attach to the network (if not already connected) and connect to the PDN connection to enable relay traffic. Alternatively, a UE capable of ProSe UE-to-network relay may connect to (one or more) additional PDN connections to provide relay traffic towards (one or more) remote UEs. (One or more) PDN connections supporting UE-to-network relay may only be used to relay traffic for (one or more) remote ProSe UEs. For example, this relay feature may be used in 3GPP public safety use cases.

[0043] refer to Figure 3, the ProSe UE to network relay 302 may perform an initial E-UTRAN attach and / or establish a PDN connection via the eNB 303 with the MME 304, the S-GW 305, and the P-GW 306 (if not already attached) to provide relay traffic (if there is no appropriate PDN connection for such relay) (step 310). The remote UE (remUE) 301 may perform discovery of the ProSe UE to network relay (e.g., the ProSe UE to network relay 302) (step 311). Model A discovery or Model B discovery defined in 3GPP may be performed. The remote UE 301 may select the ProSe UE to network relay (e.g., the ProSe UE to network relay 302) and establish a connection for one-to-one ProSe direct communication (step 312a). If there is no PDN connection associated with the ProSe relay UE ID, or an additional PDN connection is needed for relaying, the ProSe UE to network relay 302 may initiate a new PDN connection establishment procedure for relaying (step 312b). The remote UE 301 may then be assigned an IPv6 prefix or an IPv4 address (step 313), and uplink and downlink traffic relaying may then begin. The ProSe UE to network relay 302 may send a remote UE report (e.g., information including but not limited to a remote user ID and / or IP information) message for the PDN connection associated with the ProSe UE to network relay 302 to the MME 304 (step 314). The remote user ID may include the identity of the remote UE 301 user that was successfully connected in step 312a (provided via user information). The MME 304 may store the remote user ID and related IP information in an Evolved Packet System (EPS) bearer context of the ProSe UE to network relay 302 for the PDN connection associated with the relay. MME 304 may forward the remote UE report message to S-GW 305, and S-GW 305 may forward the message to P-GW 306 of UE to network relay 302 (step 315). For example, MME 304 may report multiple remote UEs in one remote UE report message. Relayed traffic may then be sent and received (step 316).

[0044] Figure 4 is a diagram of an example process 400 for requesting monitoring of a temporary mobile group identity (TMGI). Figure 4In the example of , the remUE can request the ProSe UE-to-network relay to start monitoring the availability of a specific TMGI. In this example, in order to distinguish the remote UE from the relay UE, the remote UE is referred to as the remUE and the relay is referred to as the relay UE. When a TMGI is detected on the serving cell, the ProSe UE-to-network relay can broadcast the detected TMGI and its corresponding ProSe Layer 2 Group ID by using the relay discovery additional information sent on the discovery transport. The eMBMS traffic related to this TMGI (if available) can be forwarded to the remote UE served by the relay through a one-to-many link with a specific ProSe Layer 2 Group ID identity provided by the relay when performing this procedure.

[0045] refer to Figure 4, the remote UE 401 (remUE) may discover the ProSe UE to network relay 402 (relayUE) and may have obtained (in-band or out-of-band) the TMGI, QoS class identifier (QCI), radio frequency, and multimedia broadcast multicast service (MBMS) service area identifier (SAI) to receive the relevant eMBMS content (step 410). The application layer in the UE may set the ProSe per-packet priority associated with the TMGI. The remote UE 401 may send a TMGI monitoring request (TMGI, MBMS SAI, ProSe per-packet priority) to the ProSe UE to network relay 402 even if it already knows the ProSe layer 2 group ID for the corresponding TMGI (step 411). The ProSe UE to network relay 402 may retrieve a list of MBMS SAIs from the system information of the cell on which it camps, and may check whether at least one of the MBMS SAIs obtained at step 411 is included in the MBMS SAI list (step 412). If the ProSe UE to network relay 402 detects at least one requested MBMS SAI, the ProSe UE to network relay may confirm the request with a TMGI Monitoring Response (ProSe Layer 2 Group ID, TMGI_Monitoring_Refresh timer, SAI indicator = true) to the remote UE 401 (step 413). The ProSe Layer 2 Group ID may be used to forward the eMBMS content associated with the TMGI value received at step 411 to the remote UE. When the TMGI_Monitoring_Refresh timer expires, the relay stops monitoring the TMGI unless the TMGI Monitoring Request procedure is performed again. The ProSe UE to network relay 402 may detect the TMGI that it has requested to monitor (step 414). Upon detecting the TMGI, the ProSe UE to network relay 402 may broadcast the availability of the TMGI and the corresponding ProSe Layer 2 Group ID by sending a Relay Discovery Additional Information message (TMGI, ProSe Layer 2 Group ID) to the remote UE 401 (step 415). This operation may be repeated at a configurable repetition interval, which may be less than the TMGI_Monitoring_Refresh timer. If the TMGI being advertised by the relay is of interest, the value of the TMGI may be used by the device discovering the UE to the network relay 402 as a priority criterion for relay selection. The remote UE 401 may detect the advertisement of step 415 and may subsequently begin receiving the broadcast content on the one-to-many link associated with the Prose layer 2 group ID defined in step 413 over the PC5 ProSe, and the remote UE 401 may request the release of the unicast distribution branch if it is being used (step 416).The ProSe UE-to-network relay may apply the received ProSe per-packet priority value to transmit the eMBMS traffic over the PC5 interface in step 411. Even if the remote UE 401 has not completed the TMGI monitoring request / response procedure, the remote UE 401 belonging to the announced TMGI may receive the relayed eMBMS traffic via the ProSe Layer 2 Group ID.

[0046] After detecting the loss of TMGI, the ProSe UE-to-network relay 402 may stop broadcasting the availability of TMGI, and the remote UE 401 may request a unicast distribution branch from the GCS AS (step 417). The ProSe UE-to-network relay 402 may send a positive indication of TMGI loss to accelerate the UE ( Figure 4 The remote UE 401 may stop receiving broadcast content on the PC5 ProSe one-to-many link associated with the ProSe layer group 2 ID defined at step 413 (step 418). The relative ordering between steps 417 and 418 may depend on when the eMBMS content becomes unavailable in the cell.

[0047] This document describes 3GPP identifiers for ProSe functions. The following identifiers for EPC-level ProSe discovery may be used in the examples described herein: EPC ProSe user ID, application layer user ID, and application ID. ProSe functions may be identified by a fully qualified domain name (FQDN) constructed by the UE using the Home Public Land Mobile Network (HPLMN) ID.

[0048] The following identifiers for ProSe direct communication may be used in the embodiments described herein:

[0049] ProSe UE ID: This may include a link layer identifier which is used as source layer 2 ID in all packets sent by the UE for one-to-many and one-to-one ProSe direct communications.

[0050] The ProSe Management Function may ensure that the ProSe UE ID is unique in the context of one-to-many ProSe direct communication for this group. When bearer level security is not used, the ProSe UE ID may be either configured in the UE or self-assigned by the UE.

[0051] ProSe Layer-2 Group ID: This may include a link layer identifier that identifies the group in the context of one-to-many ProSe direct communication. It may be used as the destination Layer 2 ID in all packets sent by the UE to this group for one-to-many ProSe direct communication.

[0052] The following identifiers for ProSe direct discovery may be used in the embodiments described herein:

[0053] ProSe Application ID: For open ProSe discovery, the ProSe Application ID is called Public ProSe Application ID. The geographical scope of the Public ProSe Application ID can be PLMN-specific, country-specific, or global.

[0054] Each Public ProSe Application ID may consist of a ProSe application ID name and a PLMN ID corresponding to the PLMN to which the ProSe application ID name is assigned.

[0055] The ProSe application code may be obtained from the HPLMN ProSe function using a notification request procedure for notifying the UE and a monitoring request procedure for monitoring the UE.

[0056] Each ProSe Application Code may include a temporary identifier corresponding to the ProSe Application ID Name and the PLMN ID of the ProSe Function to which the ProSe Application Code is assigned.

[0057] The following identifiers for ProSe UE to network relay discovery and selection Model A may be used in the embodiments described herein:

[0058] The ProSe Relay UE ID may include a link layer identifier for direct communication and associated with a relay service code. For each relay service code, the UE-to-network relay may have a different ProSe Relay UE ID. To support multiple PDN connections, a different ProSe Relay UE ID may be assigned to the ProSe UE-to-network relay for each PDN connection.

[0059] Announcer Info may include information about the announcing user.

[0060] The Relay Service Code may include identifying the connectivity service and configuring (one or more) parameters for announcement in the ProSe UE-to-network relay. The Relay Service Code may also identify authorized users to whom the ProSe UE-to-network relay may provide services, and may select relevant security policies or information, e.g., for authentication and authorization between the remote UE and the ProSe UE-to-network relay.

[0061] The following identifiers for ProSe UE to network relay discovery and selection Model B may be used in the embodiments described herein:

[0062] Discoverer Info may include information about the discoverer user.

[0063] The relay service code may include information about the connectivity that the discoverer UE is interested in. The relay service code may be configured in a remote UE that is interested in the related connectivity services.

[0064] The ProSe relay UE ID may include a link layer identifier of the UE-to-network relay, which may be used for direct communication and is associated with a relay service code. For each relay service code, the UE-to-network relay may have a different ProSe relay UE ID.

[0065] Discovere Info may include information about the discoverer.

[0066] The following identifiers for group member discovery (Model A) may be used in the embodiments described herein:

[0067] The ProSe UE ID may include a link layer identifier, which may be used for subsequent direct one-to-one and one-to-many communications.

[0068] Announcer Info may include information about the announcing user.

[0069] The Discovery Group ID may include an identifier of a discovery group to which the UE belongs.

[0070] The following parameters may be used in a group member discovery solicitation message (Model B):

[0071] Discoverer Info may include information about the discoverer user.

[0072] The Discovery Group ID may include an identifier of a discovery group to which the target UE belongs.

[0073] Target Info may include information about the target discoverer (single user or group). Target Info may be provided by the upper layer of the UE.

[0074] The following parameters may be used in a group member discovery response message (Model B):

[0075] The ProSe UE ID may include a link layer identifier, which may be used for subsequent direct one-to-one and one-to-many communications.

[0076] Discoveree Info may include information about the discoveree.

[0077] The Discovery Group ID may include an identifier of a discovery group to which the discoverer UE belongs.

[0078] The following identifiers for repeater discovery additional information may be used in the embodiments described herein:

[0079] Relay service code may include a code associated with the message and is used to identify security parameters used by the receiving UE to process the discovery message.

[0080] The ProSe relay UE ID may include a link layer identifier used for direct communication and associated with a relay service code.

[0081] Announcer info may include information about the announcing user.

[0082] The TMGI may indicate to the ProSe UE the MBMS being relayed by the network relay.

[0083] The ProSe Layer-2 Group ID may include a link layer identifier of a group transmitting MBMS traffic corresponding to the TMGI.

[0084] The E-UTRAN Cell Global Identifier (ECGI) can identify the serving cell of the ProSe UE to the network relay.

[0085] A single repeater discovery additional information message may carry information including but not limited to the following:

[0086] ProSe UE to ECGI on which the network relay resides;

[0087] One or more advertised TMGIs and their corresponding ProSe Layer 2 group IDs, up to the maximum allowed message size; or

[0088] The ECGI on which the ProSe UE camps to the network relay, and one or more advertised TMGIs and their corresponding ProSe Layer 2 Group IDs, up to the maximum allowed message size.

[0089] The following requirements have been specified for 5G systems but have not yet been addressed in the systems:

[0090] (1) 5G networks should optimize resource usage in the control plane and / or user plane to support high-density connections (e.g., 1 million connections per square kilometer), taking into account criteria such as: type of mobility support; communication mode (e.g., send-only, frequent, or infrequent); characteristics of the payload (e.g., small or large data payload); characteristics of the application (e.g., provisioning operations, normal data transfer); UE location; and timing mode of data transmission (e.g., real-time or non-delay sensitive).

[0091] (2) Based on the operator's policy, the 5G system should be able to prevent the UE from accessing the network using relevant barring parameters that vary according to the access identity and access category. The access category is defined by a combination of conditions related to the UE and the type of access attempt. One or more access identities are selected, and only one access category is selected and tested for the access attempt.

[0092] (3) The 5G network should be able to broadcast barring control information (i.e., a list of barring parameters associated with an access identity and access category) in one or more areas of the RAN.

[0093] (4) The UE should be able to determine whether to allow a specific new access attempt based on the barring parameters received by the UE from the broadcast barring control information and the configuration in the UE.

[0094] (5) When multiple core networks share the same RAN, the RAN should be able to apply access control to different core networks separately.

[0095] (6) The unified access control framework should apply to both UEs accessing 5G CN using E-UTRA and UEs accessing 5G CN using NR.

[0096] (7) The unified access control framework shall apply to UEs in RRC idle, RRC inactive, and RRC connected states when initiating a new access attempt (e.g., a new session request). A "new session request" in RRC connected may refer to events such as a new 3GPP / NGN IP Multimedia Subsystem (IMS) Multimedia Telephony Service (MMTel) voice or video session, the sending of a Short Message Service (SMS) (SMS over IP or SMS over NAS), a new PDU session establishment, an existing PDU session modification, and a service request to reestablish the user plane for an existing PDU session.

[0097] (8) The 5G system should support a means by which operators can define operator-defined access categories as mutually exclusive. Examples of operator-defined access category criteria may include network slices, applications, and application servers.

[0098] (9) A unified access control framework shall be applicable to inbound roamers of a PLMN. The serving PLMN may be able to provide the UE with the definition of operator-defined access categories.

[0099] Many IoT applications can be characterized as delay tolerant, i.e., they can exchange data with a server or device, and whether the data is delivered to the destination in a timely manner is irrelevant to the overall application layer functionality. Many such applications are hosted on UEs that experience interruptions in their connectivity or on UEs that communicate only at scheduled times (e.g., a sensor that collects environmental data over a 24-hour period, compresses 24 hours' worth of data, and then attempts to send the data to a remote server). The services and functions provided by 3GPP networks (EPC and 5GC) rely heavily on AS and UE applications to coordinate their delay tolerant communication activities. In terms of services, 3GPP networks do not provide much for UEs and ASs to support delay tolerant communications.

[0100] In another example, devices in a smart grid may share data with each other and with a service capability server (SCS) infrastructure where the data is analyzed. The output of the data analysis may need to be communicated to end users and smart devices, for example, the output may be an updated set of instructions describing when the smart device should operate. For applications with limited connectivity, intermediate nodes may need to store / carry data until they find an opportunity to forward the data to its final destination.

[0101] Figure 5 is an example system 500 for a Delay Tolerant Data UL use case. One communication model for delay insensitive applications can be found in rural environments, where network coverage is often insufficient. Non-real-time Internet access (e.g., for email) can be obtained through a network implementing a kiosk 503 that collects data from mobile devices via point-to-point links. The data is then collected and transmitted to the coverage area by a repeater 510 placed on a bus, where data exchange with a core network (CN) 505 occurs. A remote server (e.g., SCS 504) can use the same model to collect data from multiple sensors 501, 502 distributed in an urban environment and charge for delay tolerant data in a different manner, where each sensor does not have its own subscription but has other 3GPP identities (i.e., user identities). The repeater stores the data until coverage is obtained and then sends the data to the CN 511.

[0102] In a system where low-cost IoT devices use repeaters to communicate with one or more M2M servers to carry delay-tolerant data in an opportunistic manner, the data sender does not immediately know when and if its data reaches the destination, and may not always know the best repeater to forward its data to. This results in duplicate copies of the data being sent toward the destination. The data path that can be used to deliver the response can be different from the original data path. As a result, the following issues / inefficiencies arise:

[0103] The same data bundle may be transmitted to multiple repeaters, resulting in multiple copies that only the endpoint can resolve. These copies unnecessarily use network resources before reaching the endpoint. If only a single copy is sent from the end sensor, then delivery to the endpoint is unlikely to be successful. There may be no information available in the network (except at the SCS) that would allow other nodes to eliminate duplicates, thus wasting network resources.

[0104] Many 5G error correction techniques rely on retransmissions without taking into account the data duplicates available in the system. Therefore, the error correction mechanism will not be optimized when there are copies available. In addition, an end-to-end path between the data source and the destination may not exist, so it may be necessary to allow the data and responses to arrive using different paths. The alternative is to send the response to every possible relay station, which may flood the system. Current techniques for letting UEs relay communications occur over a "generic" connection. This does not allow more complex models to handle the heterogeneity of data, such as sensors, emails, etc., which can also have different destinations. Therefore, a mechanism is needed to maintain the relative priority between data bundles from different UEs.

[0105] The ProSe relay model relies on sensors being UEs. However, some IoT use cases, such as data collection in urban environments described above, may require the use of sensors that the CN can identify but do not have a cellular service subscription. Improved ways are needed to use information at the repeater or in the network about the expected path or connectivity period to be used in order to optimize DL data delivery when delay tolerant, for example, by buffering at the repeater without the originator being involved in delays or retransmissions. A method is needed to provide delayed paging or triggering or tracking sensors based on sensor relay or peer-to-peer communications using delay tolerant communications. Methods are also needed for offloading group and multicast capabilities to repeaters, which is very useful for large-scale IoT.

[0106] Described herein is a method of providing a Delay Tolerant Data Service (DTDS) with optimized connectivity using 5GC capabilities with Delay Tolerant Data (DTD) and functionality enabled. Also described herein is a method of enabling DTDS in a system via a DTD tag with a DTD bundle. Described herein is a DTDS and DTDS implementation in 5GC (e.g., DTDS@CN) as NF and in UE and repeater (e.g., DTDS@UE). The functionality provided by the service includes, but is not limited to, the following:

[0107] Duplicate detection and resolution of UL data sent over connections to multiple repeaters;

[0108] Aggregation / decomposition of DTDs from one or more endpoints, thus saving network resources;

[0109] Perform advanced filtering and / or pre-processing of endpoint data before further transmission using network resources, including appending necessary metadata;

[0110] reliability assistance by providing or processing partial acknowledgment of data receipt as delay tolerant data travels along a communications path, providing optimization of data processing, providing error correction capabilities, evaluating communications performance, adding redundancy to increase chances of delivery, etc.;

[0111] using a DTD tag based policy to determine the priority and QoS assistance of an UL bearer on which the received bundle should be sent; and

[0112] Dedicated charging assistance using rules and policies based on DTD tags.

[0113] This document describes methods how the DTDS functionality in the CN and the functionality at a repeater can be configured and initialized. In addition to the repeater case, this document also describes the case where the UE is directly connected to the CN and DTDS is configured. This document describes methods for DTD delivery. The procedures described include use cases for connectivity loss and re-establishment, which highlight some of the features of DTDS. This document also describes additional delay tolerant services at DTDS, namely, delay tolerant paging procedures and group and eMBMS tolerant procedures.

[0114] Figures 6 to 11(described below) illustrate various embodiments related to DTDS. In these figures, various steps or operations performed by one or more nodes, devices, equipment, servers, functions, or networks are shown. For example, the devices may operate alone or in combination with each other to implement the methods described herein. As used herein, the terms "device", "network device", "node", "server", "device", "entity", "network function" and "network node" may be used interchangeably. It should be understood that the nodes, devices, servers, functions or networks shown in these figures may represent logical entities in a communication network and may be implemented in the form of software (e.g., computer executable instructions) stored in a memory of a node of such a network and executed on a processor of a node of such a network, which network may include the following description Fig.13A Or one of the general architectures shown in 13B. That is, Figures 6 to 11 The method shown in may be stored in a network node (such as, for example Fig. 13C The present invention is implemented in the form of software (e.g., computer executable instructions) in the memory of a node or computer system (e.g., a node or computer system shown in FIG. 13D), which, when executed by a processor of the node, performs the steps shown in the drawings. It should also be understood that any transmission and reception steps shown in these figures can be performed by the communication circuit system of the node (e.g., a node or a computer system, respectively) under the control of the processor of the node and the computer executable instructions (e.g., software) executed by it. Fig. 13C It should also be understood that the nodes, devices, and functions described herein may be implemented as virtualized network functions.

[0115] Figure 6 6 is a diagram of an example 5G architecture 600, which depicts the DTDS@CN functionality as a standalone NF or an integrated NF, which can be used in conjunction with any of the embodiments described herein. Figure 6 As shown in the example of FIG. 6 , UE 610 can access AMF 620 via RAN 611 through N1 interface 630. Namf interface 641 is also shown. RAN 611 can access AMF 620 via N2 interface 631. RAN 611 can access UPF 612 via N3 interface 632. UPF 612 can access SMF 621 via N4 interface 633. Nsmf interface 642 is also shown. UPF 612 can access DN 613 via N6 interface 634. Other NFs in the control plane are shown in FIG. Figure 6As shown in the example, such as NEF 614 and Nnef interface 643, NRF 615 and Nnrf interface 644, PCF 616 and Npcf interface 645, UDM 617 and Nudm interface 646, AF 618Naf interface 647, AUSF 619 and Nausf interface 640, NSSF 622 and Nnssf interface 648.

[0116] Figure 6 Also depicted are enablers for providing DTD support and optimization in 5G. The 5G functionality of DTD may be implemented in the CN or in a node such as a repeater. The DTDS functionality in the CN may be implemented in a separate NF (e.g., DTDS@CN NF 623 and Ndtds interface 649). This functionality may also be included in existing NFs, for example, in AMF 620 as DTDS@CN 650, in SMF 621 as DTDS@CN 651, in NEF 614 as DTDS@CN 652, or in UPF 612 as DTDS@CN 653, as in Figure 6 The independent DTDS@CN NF 623 may interact with these or any other NFs in the CN. It may be a common NF for several network slices, or it may be dedicated to a network slice. The DTDS@CN may have aspects that are implemented separately as part of the control and data planes.

[0117] In the embodiments described herein, the DTDS functionality may be implemented in a repeater, for example, using the ProSe UE to network terminology and paradigm described above. As used herein, the term relay UE may refer to a UE that is attached to a network and supports connectivity to the network for other remote UEs (remUEs). The UE may also act as a repeater for non-3GPP devices (i.e., capillary devices). Moreover, the UE may use DTDS for its own mobile originated (MO) / mobile terminated (MT) data. As such, DTDS implemented by any UE (whether or not acting as a repeater) is described herein as DTDS@UE. DTDS may provide many delay tolerant services, including but not limited to the following services:

[0118] Duplicate Detection: DTDS can determine when an endpoint has sent multiple copies of the same data (e.g., due to connections to multiple repeaters), and it can remove the copies.

[0119] Aggregation: Ingress DTDS (i.e., DTDS@CN for DL ​​and DTDS@UE for UL) can aggregate data from one or more endpoints and treat the aggregated data as a single 3GPP packet, thereby saving network resources. Egress DTDS (i.e., DTDS@UE for DL ​​and DTDS@CN for UL) can decompose 3GPP packets into separate data. Aggregation can be by endpoint type, by priority of traffic generated by the endpoint, etc.

[0120] Advanced filtering and / or processing: DTDS can perform processing or filtering of endpoint data. For example, when a repeater connected to multiple water level sensors sends the first sensor reading received within an hour, it can be configured in normal mode. The same repeater can have a flood warning mode when all sensor readings are relayed. Similarly, being closer to the edge of the network can provide statistical analysis (such as averaging, finding variances, etc.) and reduce air communication and centralized processing requirements. The DTDS@UE function can also provide additional or derived information / metadata about the collected data. For example, DTDS@UE can add collection location information, but the individual sensors themselves are mobile and not equipped with location services.

[0121] Reliability assistance: When delay-tolerant data travels along a communication path, DTDS can provide or process partial acknowledgements of data reception. This helps with path optimization in both UL and DL, and provides reliability in situations where data delivery is particularly unreliable.

[0122] DTDS can also assist in providing error correction, which enables the system to reduce the requirements of over-the-air detection and correction schemes. For example, in the case where delay-tolerant endpoint data is available in multiple replicas, errors can be resolved without the need for additional over-the-air transmissions to correct each replica. In this role, DTDS can also assist in evaluating communication performance, such as end-to-end latency and throughput.

[0123] DTDS can also provide reliability through redundancy. For example, DTDS@CN can send DL data to multiple repeaters, which can be able to transmit the data to the destination endpoint, thereby increasing the chance of delivery.

[0124] Prioritization and QoS assistance: DTDS in the repeater can help determine on which UL bearer and when a received bundle should be transmitted. For example, the repeater can be provided with simple rules or policies that can be used in addition to the priority indicated on the remote UE to repeater link to determine the timing and QoS of UL retransmissions.

[0125] Dedicated charging assistance: DTDS can be used to implement novel charging schemes. For example, DTDS@UE can be configured to mark UL data from multiple remUEs so that the entire data flow is charged using a specific subscription, which can be DTD-specific and common to remUEs, etc. Similarly, although the device has no subscription in the 3GPP system, data delivery to / from non-3GPP capillary devices can be marked for charging using a specific subscription. DTDS@UE can also indicate how much UL data has been collected for charging purposes, but has been eliminated through local processing or aggregation at the repeater. Conversely, DTDS@CN can track DL data sent multiple times over the air to achieve reliable delivery to enable appropriate charging.

[0126] Figure 7 is a diagram of an example DTDS deployment 700, which may be used in conjunction with any of the embodiments described herein. Figure 7 The example DTDS deployment 700 depicts a UL use case, and depicts DTDS@CN 706 and DTDS@UE 707. Figure 7 As shown in the example of , SCS / AS 704 can request and configure DTDS (step 710). DTDS@CN 706 can configure DTDS@UE 707 (step 711). Kiosk network 703 can collect data from mobile devices through point-to-point links. Delay tolerant data can be collected and sent to repeaters (step 712). Repeaters can store data until coverage is obtained and then send delay tolerant data to CN 705 (step 713). CN 705 can then send delay tolerant data to SCS / AS 704 (step 714).

[0127] In the embodiments described herein, the delay tolerant data in the 5GC may be organized into bundles identified by DTD tags. The DTD tag may include an identifier for the delay tolerant data in the network. The DTD tag may be used at data endpoints (e.g., sensors, UEs, and SCS / AS) to identify the delay tolerant data bundle. The service provider may be responsible for providing configuration information to the SCS / AS, for example, via pre-configuration of the format of the DTD tag, the rules used by the DTD tag.

[0128] DTD tags can include but are not limited to the following information:

[0129] Information identifying a service or application or service / application type (e.g., Serv_type);

[0130] Information identifying the service / application instance or flow (e.g., Flow_id) or pre-negotiated prioritization or QoS category (e.g., Cat_index); and

[0131] Information identifying a service / application instance or a data bundle within a flow (e.g., Boundle_id).

[0132] Other numbering information may be implemented, for example, including the originator and source instead of the flow identifier, etc. Numbering schemes may be MNO or SP specific, they may be standardized or global, and may include existing identifiers (e.g., IP address and port id of the endpoint instead of Flow_id).

[0133] In the embodiments described herein, the UE may be pre-configured to be able to create / manage DTD tags, or may be configured out-of-band by the SCS / AS.

[0134] DTD tags may be used in addition to or as a replacement for traffic flow and packet identifiers associated with other types of traffic, and may be used for purposes including, but not limited to, the following:

[0135] Create a delay tolerant data flow or stream that can be transmitted on various paths. For this purpose, the DTD tag can be independent of the IP packet number, although the source and destination can be identified similarly. When a packet associated with a given DTD tag is received, if the delay tolerance parameters are met, the repeater can wait until the entire bundle is received before relaying. Note that the DTD tag can then be effectively used for the identification of the DTD data flow. They also allow the use of a connectionless control plane (signaling) mode for delay tolerant data exchange on the user plane.

[0136] Identify the core network entity that serves the data flow.

[0137] Prioritize, aggregate or buffer DTD traffic. For example, when network coverage allows, a repeater may aggregate all bundles with a given Serv_type and may send them in preference to all other bundles. Alternatively, a mapping table may be provided to the repeater to determine how long a bundle with a given Flow_id or Cat_index will be buffered, or on which UL bearer it will be transmitted. The repeater may also reorder received bundles in order (based on Boundle_id) before retransmission.

[0138] Reliability and resource optimization are enabled by using the entire DTD tag. For example, duplicate detection can be performed by matching the tag to a list of UL DTD tags that the system has already received, and resource optimization is enabled. Conversely, when duplicate DTD tags are found, they can be used for error correction, similar to retransmissions. Reliability via redundancy can be enabled in the DL by sending the same data with the same DTD tag to multiple repeaters. Reliability can also be enabled by including the DTD tag in partial acknowledgments for received beams.

[0139] Provides advanced filtering and processing by identifying the data that needs to be included in the processing. For example, a simple relay service that collects data from many temperature and water level sensors can provide an average of the accumulated data every 10 minutes and then send it on the UL. It can use Serv_type to distinguish between the two types of data.

[0140] Implementing DTD tag based charging scheme: DTD tags can be used to define charging policies specifically for delay tolerant data services. By using DTD tag based policies, the MNO may be able to differentiate between traffic traversing the core network that is generated by non-3GPP devices or sent to non-3GPP devices through repeaters. Such a scheme may also enable charging schemes that are independent of the creation of traffic flows and sessions. For example, DL DTDs sent to medical devices and advertising devices that are regularly transported by the same repeater can be charged differently. In the case of medical devices, assuming that delivery reliability is more important, then each bundle may be sent via 20 repeaters, while for advertising devices, each bundle may be sent via 2 repeaters. In this example, the requirement for additional resources results in different charges.

[0141] Figure 8 is a diagram of an example process 800 for DTDS configuration and establishment at a CN and relay UE, which may be used in conjunction with any of the embodiments described herein. Figure 8 In the example of , the relayUE is used for remUE data. Process 800 starts with a NF (e.g., DTDS@CN NF 806) that is pre-configured by the SCS / AS 808 and 809 to provide services for DTD in the CN. The process includes the steps of configuring DTDS at the relayUE (e.g., DTDS@UE 803). The configuration of DTDS@UE 803 is performed when the repeater is connected to the network and / or when a remUE requiring DTDS establishes communication with the repeater. After these process steps, DTD exchange can be performed. In another embodiment, the configuration of DTDS@UE can be performed by the SCS / AS, for example, the NEF function can allow the SCS / AS to configure the service directly at the repeater (including the DTDS@UE).

[0142] refer to Figure 8 , each SCS / AS (e.g., SCS / AS 808 and SCS / AS 809) may provide configuration information for the required services to the DTDS@CN NF 806 (step 810). Alternatively, for example, after the attach procedure, the UE may perform the provision of configuration information for DTD services to the DTDS@CN service by the UE in this initial step, in which case the services supported by the UE provide information about its DTD requirements, and the UE sends this information to the CN. Moreover, several of these parameters may be provided as part of a parameter set that describes the expected UE behavior. The configuration information may also be provided via NEF 807, and may include parameters, including but not limited to the parameters in the following table:

[0143]

[0144]

[0145]

[0146] Table 1 DTDS configuration information from SCS / AS

[0147] DTDS@CN NF 806 may derive information required to provide its services (step 811). For example, DTDS@CN NF 806 may derive buffer sizes for each data type, may determine geographic areas that may correspond to remUEs (e.g., remUE 801 and remUE 802) and relayUEs (e.g., rRelayUE 803) corresponding to the services, etc.

[0148] The relayUE 803 may attach to the CN and other CN NFs 805 via the RAN 804 (if not already attached) (step 812). At this point, the relayUE 803 may receive an authorization policy for acting as a relayUE, parameters that enable it to perform discovery, etc. If the relayUE 803 is already attached, it may be triggered by the CN indicating that DTDS has been configured in the network, and the relay may register its own DTDS. Alternatively, the DTDS@CN NF 806 may provide the DTDS information directly in the trigger message, effectively proceeding directly to step 814.

[0149] Step 812 may include the relayUE DTDS@UE 803 performing a 5G registration, service request, or PDU session establishment. The request may include an indication that the relayUE DTDS@UE 803 is attaching for DTDS. The request may also include an identity representing an instance of a DTDS service on the relayUE DTDS@UE 803 or in the network. The response from the network may indicate that the operation is not currently allowed or prohibited due to network congestion or the network is processing a higher priority service. The response may also indicate a backoff time to the relayUE DTDS@UE 803 so that it knows when it can reply again. The relayUEDTDS@UE 803 may provide backoff time information to the remUE (e.g., remUE 801 and remUE 802) so that the remUE knows how long its data may be delayed or buffered in the relay UE DTDS@UE 803, or the backoff time may be an indication of when the remUE should retry again. The relayUE DTDS@UE 803 may monitor the system information broadcast by the base station to determine whether access to DTDS is prohibited. Receiving a prohibited indication may indicate to the relay UE DTDS@UE 803 that this step should not be attempted.

[0150] In some embodiments, the relayUE DTDS@UE 803 may indicate its DTDS (DTDS@UE) capability by sending a DTDS registration message routed to the DTDS@CN NF 806 (step 813). This 5G registration or service request may include the parameters listed in Table 2. In some embodiments, this information may be encoded as part of the S-NSSAI. In another example embodiment, this information may be included in the messages exchanged in step 812 during the attachment of the relayUE DTDS@UE 803 to the CN.

[0151]

[0152]

[0153] Table 2 DTDS registration message

[0154] If the relayUE DTDS@UE 803 sends a DTDS registration message, the DTDS@CN NF 806 may send a DTDS registration response message to the relayUE DTDS@UE 803 (step 814). If the DTDS registration message is part of a 5G registration or service request message, the response from the DTDS@CN NF 806 may be delivered to the relayUE DTDS@UE 803 as part of a 5G registration or service request response message.

[0155] Alternatively, the DTDS registration / response messages of steps 8133 and 814 may be performed in a subsequent step (eg, step 818).

[0156] The relayUE DTDS@UE 803 may receive authorization policies for relaying delay tolerant traffic, such as:

[0157]

[0158]

[0159] Table 3 DTDS registration response message

[0160] Then, discovery may be performed between remUE 801 and remUE 802 and relayUE DTDS DTDS@UE 803 (step 815). If discovery is performed using a ProSe link, the discovery may include Model A discovery or Model B discovery. remUE 801, remUE 802, and relayUE DTDS@UE 803 may exchange their DTDS endpoint IDs.

[0161] Then, the remUE (e.g., remUE 801 and remUE 802) and relayUE DTDS@UE 803 communication to remUE 801 and remUE 802 may be established (step 816a). The remUE (e.g., remUE 801 and / or remUE 802) may indicate to the relayUE DTDS@UE 803 that it wants to connect for services including DTDS. In 5G, the relayUE DTDS@UE 803 may, for example, indicate to the network in turn via a specific indicator in the registration request or NSSAI that it wants to connect to a slice providing DTDS. This step may also be performed before the relayUE DTDS@UE 803 registers in step 813.

[0162] In some cases, the remUE may be a capillary device that is unaware of DTDS. For example, the capillary device may include a small sensor that communicates with the relayUE DTDS@UE 803 via Bluetooth. In such cases, the relayUE DTDS@UE 803 may request DTDS services on behalf of the capillary device. The SCS / AS (e.g., SCS / AS 808 and SCS / AS 809) may provide the CN with a list of capillary device IDs and their requested (one or more) DTDS services. The CN may then notify the relayUE (e.g., relayUE DTDS@UE 803) of this list. When a capillary device on the list is connected to the relayUE (e.g., relayUE DTDS@UE 803), it may enable the DTDS services requested by the SCS / AS (e.g., SCS / AS 808 and SCS / AS 809).

[0163] The IP addresses of the remUEs (e.g., remUE 801 and remUE 802) may then be assigned for the ProSe link. If necessary, the relayUE DTDS@UE 803 may establish a new connection with the network via the RAN 804 in its relay role (step 816b). The remUEs (e.g., remUE 801 and remUE 802) may indicate their DTDS requirements to the relayUEs (e.g., relayUE DTDS@UE 803), including but not limited to the following information presented in Table 4:

[0164]

[0165]

[0166] Table 4: remUE requirements for DTD services

[0167] The remUE (e.g., remUE 801 and remUE 802) may also provide some of the information listed in step 810 and provided by the SCS / AS (e.g., SCS / AS 808 and SCS / AS 809) (Table 1). This is particularly useful when the remUE (e.g., remUE 801 and remUE 802) has the ability to provide further details about its communications at a finer granularity than that known by the SCS / AS (e.g., SCS / AS 808 and SCS / AS 809). For example, the remUE (e.g., remUE 801 and remUE 802) may provide an exact data size and maximum delivery delay value instead of a range, a specific service type instead of a list, its own precise measurement reporting interval, etc.

[0168] Alternatively, the constrained remUEs (e.g., remUE 801 and remUE 802) may provide only minimal information about their DTDS communications and may rely on configurations provided to the network by the SCS / AS (e.g., SCS / AS 808 and SCS / AS 809). For example, the remUEs (e.g., remUE 801 and remUE 802) may provide an indicator that they use delay tolerant communications.

[0169] The relayUE DTDS@UE 803 may send a report to the network about the remUEs it communicates with (step 817). This report may contain the DTDS endpoint ID and the IP information of the remUEs (eg, remUE 801 and remUE 802) if applicable.

[0170] The relayUE DTDS@UE 803 may send a DTD service request message to the DTDS@CN NF 806 to obtain the delay tolerant service it needs to provide to the remUE (e.g., remUE 801 and remUE 802) (step 818). The message may contain all the information received from the remUE and listed in the above steps 816a and 816b and Table 4. The message may also be used to send some or all information about the DTDS-related capabilities of the relayUE DTDS@UE 803, such as listed in step 813 and Table 2. This message may also include information about the DTD tag received by the DTDS@CN NF 806.

[0171] DTDS@CN NF 806 may send a DTD service request response message to relay UE DTDS@UE 803 (step 819). In an alternative embodiment, steps 813 and 814 may be combined with steps 818 and 819 using a combined registration and service request message.

[0172] remUE to SCS / AS delay tolerant communication via DTDS@CN NF 806 and / or relayUE DTDS@UE 803 (step 820). CN facilitates end-to-end remUE to SCS / AS delay tolerant communication for UL and DL by asynchronously using 3 separate communication segments:

[0173] remUE (e.g., remUE 801 and remUE 802) to / from relayUE DTDS@UE 803 fragment;

[0174] relayUE DTDS@UE 803 to / from DTDS@CN NF 806 fragment; and

[0175] SCS / AS 808 and / or SCS / AS 809 to / from DTDS@CN NF 806 segment.

[0176] Assuming that the relayUE DTDS@UE 803 is usually within the network coverage, and the remUEs (eg, remUE 801 and remUE 802) are often not connected to any relayUE, the following may apply:

[0177] In the UL direction, for example, when the remUE is not connected to any relayUE, remUE to DTDS@UE data delivery is often asynchronous with respect to DTDS@UE to DTDS@CN data delivery. DTDS@CN to SCS / AS data delivery may or may not be asynchronous with respect to DTDS@UE to DTDS@CN data delivery, depending on the service level provided by DTDS@CN. For example, if the SCS / AS does not request the CN to provide any UL bundle duplication service, then each UL bundle arriving at DTDS@CN may be immediately forwarded to the SCS / AS.

[0178] In the DL direction, assuming the relayUE is in coverage, the SCS / AS to DTDS@CN data delivery can be synchronized with the DTDS@CN to DTDS@UE data delivery. DTDS@UE to remUE data delivery is often asynchronous with respect to DTDS@CN to DTDS@UE data delivery, for example, when the remUE is not connected to any relayUE.

[0179] The network may also provide delay tolerant services for UEs that are directly connected to the network (ie, without relays). This may be useful for UEs that go in and out of network coverage and whose applications can tolerate delays.

[0180] exist Figure 8 In the example process 800, the same device that can be connected to the repeater as the remUE can directly connect to the CN if they are in coverage. In this case, if end-to-end delivery or delay-tolerant paging of DL data has not yet been achieved through the repeater, the DTDS@CN can directly perform the data delivery / paging and then notify the repeater to discard the not yet delivered beam or page. For this case, the relay-based DL data delivery process and the relay-based delay-tolerant paging process can be easily used / adapted. For this case, the UL DTD data delivery process can also be used / adapted, where the DTDS@CN resolves duplicates, or the DTDS@UE waits for possible late confirmation of end-to-end delivery even if the UE is in network coverage.

[0181] exist Figure 8 The same devices that act as relayUEs in the example process 800 may also act as standalone UEs and request DTDS for their own data, such as a delayed paging procedure.

[0182] Fig. 9 FIG. 9 is a diagram of an example process 900 for UL delay tolerant data sent by a remUE to an SCS / AS via a relay UE and a CN, which may be used in conjunction with any of the embodiments described herein. A similar process may be applied to a UE directly connected to a CN without a relay. For consistency and clarity, Figure 8 The step nomenclature and order of the example process 800 are retained in Fig. 9 In the example process 900, therefore, the steps may not be described sequentially below.

[0183] exist Fig. 9 In the example of FIG. 1 , remUE 901 sends a data bundle via a first relay (e.g., relayUE 902), after which it establishes communication with a second relay (e.g., relayUE 903) and then confirms receipt of the bundle at a destination SCS / AS 908. In this example, remUE 901 may retransmit the bundle via the second relay (e.g., relayUE 903) to increase the chances of the data reaching the destination, since the relayUE may also not have coverage for an extended period of time.

[0184] Fig. 9 The example process 900 of FIG. 900 describes how to resolve data duplication through the DTDS@UE service or the DTDS@CN service. Where the duplication can be resolved depends on the service implementation and capabilities, the timing of data arrival at different entities, etc.

[0185] Fig. 9 The example process 900 depicts the following functionality: The DTDS@CN NF 906 may be able to predict the location / trajectory of the remUE and relayUE, based on which it proactively configures the DTDS@UE for upcoming transmissions, notifies the DTDS@UE which UL data the CN has received, etc. The DTDS@UE can then use this information to discard duplicates, thereby saving air interface resources. Proactive DTDS@UE configuration can also be done in batches and at convenient times, thereby optimizing resource usage.

[0186] refer to Fig. 9, the DTDS@CN NF 906 service may be configured by the SCS 908 for the required service and derive the information required to provide its service (step 910). The relayUE 902 may attach to the CN and other CN NFs 905 via the RAN 904 (step 911). The relayUE 902 may send a DTDS registration message as described above, and the DTDS@CN NF 906 may send a DTDS registration response message to the relayUE 902 (step 912).

[0187] Then, discovery between remUE 901 and relayUE 902 may be performed (step 913a), and relayUE 902 may establish a new connection with the network via RAN 904 to implement its relay role (step 913b). Communication from remUE 901 to relayUE 902 may then be established (step 914). When communication is established with remUE 901, relayUE 902 may send a report with ProSe UE ID, IP information, etc. to the CN for its communication with remUE 901, and request services from DTDS@CN NF 906. RelayUE 902 may be provided with information about the DTDS required at the relay, including, for example, information about the DTD tag that has been received by DTDS@CN NF 906. RelayUE 902 may send a DTDS request to DTDS@CN NF 906 (step 915), which may send a DTDS response to relayUE 902 (step 916). These steps effectively establish a connectionless UL data communication mode.

[0188] In one example, the remUE 901 may send uplink data to the relayUE 902 in one or more data bundles, each bundle including a DTD tag (or an indicator that the DTD tag is applicable to multiple bundles) (step 917).

[0189] The relayUE 902 may use information about the DTDS required at the relay (such as sent in step 917) to evaluate how to handle the DTD from the remUE 901 (step 919). For example, the relayUE 902 may:

[0190] If the bundle does not meet the delay tolerance parameters, e.g. exceeds the maximum delivery delay calculated based on the data generation time etc., then decide to discard the bundle;

[0191] If the bundle does not satisfy the path constraints (relayUE 902 is not allowed in the path), or does not match the information type, data size constraints, communication type, etc., then decide to discard the bundle;

[0192] Deciding that it should be buffered for a while in order to perform the requested service, such as error correction or aggregation (aggregation may be based on source or destination bundles, or may include completely unrelated bundles, for the purpose of optimizing its UL air interface. The data may then be queued for delivery to the CN); and / or

[0193] If DTDS@CN has received the bundle and has requested duplicate removal, it decides to discard the bundle.

[0194] In this example, due to loss of network coverage at the relayUE 902, the bundle is not dropped, but is not delivered to the CN.

[0195] If the bundle is not dropped, then the relayUE 902 may respond with an acknowledgement of receipt of the data bundle (step 918). This is considered a partial acknowledgement because it provides the originator with knowledge that the bundle will only be delivered to the next hop. Depending on the implementation, DTDS may rely on partial acknowledgements, end-to-end acknowledgements, or a combination of both.

[0196] The remUE 901 may discover another relay, for example, when the relayUE 902 loses coverage, the relayUE 903 and the relayUE 902 may not be able to forward the received data beam to the CN for a long time. Then, the discovery between the remUE 901 and the relayUE 903 may be performed (step 920a), and the relayUE 903 may establish a new connection with the network via the RAN 904 to implement its relay role (step 920b). Then, the communication from the remUE 901 to the relayUE 903 may be established (step 921). When the communication is established with the remUE 901, the relayUE 903 may send a report with the ProSe UE ID, IP information, etc. to the CN for its communication with the remUE 901, and request services from the DTDS@CN NF 906. The relayUE 903 may be provided with information about the DTDS required at the relay, including, for example, information about the DTD tag that has been received by the DTDS@CN NF 906. The relayUE 903 may send a DTDS request to the DTDS@CN NF 906 (step 922), which may send a DTDS response to the relayUE 903 (step 923). Since the remUE 901 receives only a partial acknowledgment at step 925, the remUE 901 may resend the same data bundle via the relayUE 903 in order to maximize the chance of receiving the data at the destination (step 924). The same bundle may be sent to the relayUE 903 in the uplink with the same DTD tag for each bundle. The relayUE 903 may respond with a partial acknowledgment indicating receipt of the data bundle (step 925).

[0197] The relayUE 903 may process the received bundle (step 926), similar to what was performed at the relayUE 902 in step 919. In this case, the data is queued for delivery to the CN.

[0198] The relayUE 903 may send the data bundle to the DTDS@CN NF 906 service in the CN (step 927). In some embodiments, the DTDS@CN NF 906 may respond with a partial acknowledgment indicating receipt of the data bundle (step 928).

[0199] The DTDS@CN NF 906 may process and record the received bundle (step 929). If the same bundle is sent later by the relayUE 901 and duplicate removal has been requested, the DTDS@CN NF 906 may discard later copies, use them for error correction, etc. Depending on the service level requested from the SCS / AS 908 during configuration, the DTDS@CN NF 906 may make a determination similar to that described in step 919. The DTDS@CN NF 906 may also provide additional services. For example, the remUE 901 (or DTDS@UE) may group bundles with different SCS / AS destinations to optimize the use of the air interface. The DTDS@CN NF 906 may cancel the grouping of the bundles and forward the UL data accordingly. Moreover, the DTDS@CN NF 906 may be able to determine which relays are likely to receive bundles from the remUE 901 in order to notify them of the bundles received in the CN. To provide this functionality, the DTDS@CN NF 906 may:

[0200] Track the relays used by the remUE and include them in a list of candidate relays, which is updated periodically;

[0201] Pre-configured by the SCS / AS with a list of candidate repeaters (this can be done in the initial DTDS configuration (step 910, Table 1 and parameters such as data path constraints, communication schedule, service geographic information) or later updates);

[0202] The DTDS@UE provides information generated by the remUE 901 through the DTD service request message (step 915, Table 4, parameters such as scheduling information, geographical information, etc.); and / or

[0203] Use the analysis and location information available in the CN to determine possible paths and match them to known / expected repeater locations.

[0204] The DTDS@CN NF 906 may send the received data bundle to the destination SCS / AS 908 (step 930). In some embodiments, the SCS / AS 908 may respond with a partial acknowledgment indicating receipt of the data bundle (step 931).

[0205] Since the data bundle has been delivered to the destination, the DTDS@CN NF 906 can send an acknowledgement of the end-to-end delivery of the data bundle to the relay from which it was received (i.e., relayUE 903) (step 932). In some embodiments, the DTDS@CN NF 906 can proactively notify other relays that may receive the bundle from the remUE 901 that the bundle has been received in the CN. This can be achieved by sending an end-to-end acknowledgement to the other relays (e.g., relayUE 902) (step 933), or can be provided via a regular configuration update of the DTDS@UE sent to the target relay.

[0206] The relayUE 903 may inform the remUE 901 of the end-to-end delivery of the data bundle (step 934). If the remUE 901 to RelayUE 903 communication is no longer active, then based on step 933, other relays may be able to forward this confirmation even if they are not in the UL delivery path.

[0207] Based on step 933, repeater 901 may be able to discard the received but not yet transmitted beam because it knows that the beam has been delivered to the destination (step 935).

[0208] Fig.10 is a diagram of an example process 1000 for sending DL delay tolerant data by an SCS / AS via a CN and a relayUE to a remUE, which may be used in conjunction with any of the embodiments described herein. A similar process may be applied to a UE directly connected to the CN without a relay. For consistency and clarity, Figure 8 The step notation and order of the exemplary process 800 are retained in Fig.10 In the example process 1000, therefore, the steps may not be described sequentially below.

[0209] exist Fig.10 In the example of , the DL data bundle is provided by SCS / AS 1008 to the CN for delivery to the final remUE 1001. Although the relayUE 1002 is configured to provide service to the remUE 1001 when initiating DL data transmission, in this case, it is assumed that the remUE 1001 establishes communication with another relay (relayUE 1003) before receiving data from the relayUE 1002. Fig.10 The following functionality is also depicted: The DTDS@CN NF 1006 may be able to predict the location / trajectory of the remUE and relayUE based on proactively sending DL data to multiple relays in advance.

[0210] refer to Fig.10, the DTDS@CN NF 1006 service can be configured by the SCS 1008 for the required service, and the information required to provide its service is derived (step 1010). The relayUE 1002 can be attached to the CN and other CNNFs 1005 via the RAN 1004 (step 1011). The relayUE 1002 can send a DTDS registration message as described above, and the DTDS@CN NF 1006 can send a DTDS registration response message to the relayUE 1002 (step 1012). Discovery can then be performed between the remUE 1001 and the relayUE 1002 (step 1013a), and the relayUE 1002 can establish a new connection with the network via the RAN 1004 to implement its relay role (step 1013b). The remUE 1001 to relayUE 1002 communication can then be established (step 1014). When establishing communication with the remUE 1001, the relayUE 1002 may send a report with the ProSe UE ID (or equivalent), IP information, etc. to the CN to communicate with the remUE 1001 and request services from the DTDS@CN NF 1006. The relayUE 1002 may be provided with information about the DTDS required at the relay, including, for example, information about the DTD tag that has been received by the DTDS@CN NF 1006. The relayUE 1002 may send a DTDS request to the DTDS@CN NF 1006 (step 1015), and the DTDS@CN NF 1006 may send a DTDS response to the relayUE 1002 (step 1016). These steps effectively establish a connectionless DL data communication mode.

[0211] The SCS / AS 1008 may send DL data for the remUE 1001 with one or more data bundles to the DTDS@CN NF 1006, each bundle including a DTD tag (or an indicator that the DTD tag applies to multiple bundles) (step 1017). A partial acknowledgement for delivery to the CN may be sent from the DTDS@CN NF 1006 to the SCS / AS 1008 (step 1018).

[0212] The DTDS@CN NF 1006 may determine how to forward the DL beam based on the received information about the destination remUE 1001 (step 1019). Depending on the DTDS configured by the SCS / AS 1008 for communication with the remUE 1001 and depending on its capabilities, the DTDS@CN NF 1006 may decide to send the beam to other relays in addition to the relayUE 1002 that recently registered to provide the DTDS 1001 for the remUE. Fig.10 In the example of , it is assumed that during this period, remUE 1001 loses communication with relayUE 1002 and the network is unaware of this (step 1020).

[0213] The DTDS@CN may send the DL data bundle to the relayUE 1001 (step 1021). In some embodiments, the relayUE 1001 may respond with a partial acknowledgment indicating the reception of the data bundle (step 1022). Based on the decision in step 1019, the relay DTDS@CN NF 1006 may also send the DL data bundle to the relayUE 1003 (step 1023). The relayUE 1003 may respond with a partial acknowledgment indicating the reception of the data bundle (step 1024).

[0214] Depending on the implementation and configuration from the SCS / AS 1008, the DTDS@CN NF 1006 may send a partial acknowledgement to the SCS / AS 1008 indicating the receipt of the data beam at one or more repeaters (step 1025).

[0215] The relayUE 1002 (e.g., via DTDS@UE) may process the received data based on pre-configured service requirements, such as, for example, by determining how long the data can be buffered and still meet delay tolerance requirements (step 1026). If an aggregate service is configured, the relay may wait to aggregate the bundle with other bundles (e.g., from different SCSs / ASs) before delivering it to the remUE 1001. If more than one copy is sent, the same type of processing occurs at all relays receiving DL data.

[0216] The remUE 1001 may then discover the relayUE 1003. Discovery may then be performed between the remUE 1001 and the relayUE 1003 (step 1027a), and the relayUE 1003 may establish a new connection with the network via the RAN 1004 to implement its relay role (step 1027b). The remUE 1001 to relayUE 1003 communication may then be established (step 1028). When communication is established with the remUE 1001, the relayUE 1003 may send a report with the ProSe UE ID (or equivalent), IP information (if applicable), etc. to the CN to communicate with the remUE 1001 and request services from the DTDS@CN NF 1006. The relayUE 1003 may be provided with information about the DTDS required at the relay, including, for example, information about the DTD tag that has been received by the DTDS@CN NF 1006. The relayUE 1003 may send a DTDS request to the DTDS@CN NF 1006 (step 1029 ), and the DTDS@CN NF 1006 may send a DTDS response to the relayUE 1003 (step 1030 ).

[0217] If the DL data bundle has not been previously sent to the relayUE 1003, the DTDS@CN NF 1006 may also send the DL data bundle to the relayUE 1003 (step 1030), and the relayUE 1003 may respond with a partial acknowledgement indicating reception (step 1031).

[0218] The relayUE 1003 may send the received data bundle to the destination remUE 1001 (step 1033), and the destination REMUE 1001 may respond with a partial acknowledgment indicating reception of the DL data bundle (step 1034).

[0219] Since the data bundle has been delivered to the destination, the relayUE 1003 (e.g., via the DTDS@UE) may send a confirmation of the end-to-end delivery of the data bundle to the DTDS@CN NF 1006 (step 1035). The DTDS@CN NF 1006 may inform the SCS / AS of the end-to-end delivery of the data bundle (step 1036). Then, based on step 1035, the DTDS@CN NF 1006 may decide to inform other relays to discard the received but not yet transmitted bundle, because it knows that the bundle has been delivered to the destination (step 1037).

[0220] The DTDS@CN may notify the relayUE 1002 of the end-to-end delivery of the data bundle via the relayUE 1003 (step 1038). This step may use an acknowledgement or partial acknowledgement message, or may reuse the DTD service request response message to notify the delivered bundle.

[0221] The DTDS@UE of relayUE 1002 may discard the bundle that has not been transmitted because it knows that the bundle has been delivered to the destination (step 1039).

[0222] After receiving the DL beam request from SCS / AS 1008, the DTDS@CN NF 1006 may first page the candidate relayUE if the candidate relayUE is in idle mode. It may provide a list of relayUEs to the MME or AMF, and then the relayUE may be paged. This may be a DTD type of paging (e.g., DTDS paging), which commands the relayUE to stay connected until the DTDS operation that triggered the paging is completed.

[0223] The DTDS capability can be used to enable a delay tolerant paging procedure for a remUE or capillary device. Delay tolerant paging can be useful for large-scale IoT deployments as both a location service and an alternative to paging. It can also be used for sensors connected to the relayUE via technologies other than 3GPP if it has a unique identity in the CN. If the SCS / AS is tracking an asset / sensor, it can configure the network to query the last sensor it interacted with and provide a notification.

[0224] The delay tolerant paging procedure may be similar to Fig.10 DL data delivery process. For example, Fig.10 The DL DTS bundle request and DL DTS bundle reception messages may be replaced by DTDS paging request and DTS paging reception messages, respectively. The DTDS paging request message may include parameters, including but not limited to the following parameters listed in Table 5:

[0225]

[0226]

[0227] Table 5 DTDS paging request

[0228] After receiving a DL Paging Request from the SCS / AS, the DTDS@CN may first page the candidate relayUE if the candidate relayUE is in idle mode. The DTDS@CN may provide a list of relayUEs to the MME or AMF, which may then page the relayUEs. This may be a DTDS type of paging (e.g., DTDS Paging), which commands the relayUE to remain connected until the DTDS operation that triggered the paging is completed.

[0229] After receiving the paging message, the relayUE can contact the DTDS and receive a list of UEs to be paged. The relayUE can respond to the DTDS with a list of UEs, and the list can include an indication of whether the relayUE can currently reach the UEs on the list to indicate when the relayUE last contacted the UEs on the list. The DTDS can aggregate responses from multiple relayUEs and forward this information to the SCS / AS.

[0230] Fig.11 is an example process 1100 for group or MBMS delay tolerant data sent by the SCS / AS to the remUE via the CN and relayUE, which can be used in conjunction with any of the embodiments described herein. A similar process can be applied to a UE directly connected to the CN without a relay. The DTDS capability can also be used to enable group or MBMS transmissions to the remUE. Fig.11 In the example of , it is assumed that TMGI, MBMS SAI and ProSe per-packet priority are pre-configured or delivered to the remUE by the SCS / AS using out-of-band signaling (e.g., application layer messaging).

[0231] Fig.11 The example depicts a DL data bundle provided by SCS / AS1109 to the CN for delivery to the final remUEs (e.g., remUE 1101 and re UE 1102) with a given TMGI. The DTDS may determine which relays to send the DL bundle to. Although two remUEs (e.g., re UE 1101 and remUE 1102) may have been connected to the same relayUE 1103 at the end, the DTDS@CN NF 1107 may decide to send the DL bundle to other relays. For example, it may include relayUE 1104 because it knows that it may communicate with remUEs (e.g., remUE 1101 and remUE 1102). In this example, remUE 1101 may lose its connection with relayUE 1103, but be able to receive the DL bundle from relayUE 1104.

[0232] When the DTDS@UE of relayUE 1103 is within the delay tolerance, it can also allow the rebroadcast of the data. Even if the remUE is not registered for the TMGI, the DTDS@UE of the relayUE 1104 embodiment can also allow the broadcast of the data if requested by the DTDS@CN NF 1107. Moreover, because the UE belonging to the announced TMGI can receive the relayed eMBMS traffic even if the TMGI monitoring request / response procedure is not completed, the DTDS@UE of relayUE 1103 can also allow the broadcast of the data even if the remUE 1101 requester is no longer connected.

[0233] refer to Fig.11 , similar to Figure 8-10 , the relayUE 1103 may attach to the CN. The DTDS@CN NF 1107 service may be configured by the SCS for the required service, and when communication is established with the remUE 1101 and the remUE 1102, the relayUE 1103 may send a report with the ProSe UE ID (or equivalent), IP information (if applicable), etc. to the CN and request service from the DTDS@CN NF 1107 (step 1110). The relayUE 1103 may be provided with information about the DTDS required at the relay.

[0234] remUE 1102 may send a DTD monitoring request for a given TMGI to relayUE 1103, indicating its own ID TMGI (step 1111). relayUE 1103 may convert it into a DTD service request and forward it to DTDS@CN NF 1107 (step 1112). DTDS@CN NF 1107 may send a response to relayUE 1103 (step 1113). relayUE 1103 may send a response to request 1102 (step 1114).

[0235] Steps 1111, 1112, 1113, and 1114 may be repeated for the remUE 1101 (step 1115). Even if the TMGI monitoring request / response procedure is not completed, the remUE 1101 may still receive relayed eMBMS communications.

[0236]

[0237]

[0238] Table 6. DTDS monitoring request

[0239] The SCS / AS 1109 may send a DL Group Data bundle including a DTD tag for each bundle (or an indicator that the DTD tag applies to multiple bundles) (step 1116). A partial acknowledgement for delivery to the CN is sent by the DTDS@CN NF 1107 to the SCS / AS 1109 (step 1117).

[0240] The DTDS@CN NF 1107 may determine how to forward the DL group bundle based on the information received from the SCS / AS 1109 and from the remUE 1102 (step 1118). Depending on the TMGI and DTDS configured by the SCS / AS 1109 for communicating with the remUE 1102 and its capabilities, the SCS / AS 1109 may decide to send the bundle to other relays that have recently registered to monitor the TMGI in addition to the relayUE 1103. It may be assumed that the remUE 1102 may lose communication with the relayUE 1103 during this time and the network is not aware of it (step 1119).

[0241] The DTDS@CN may send the DL group data bundle to the relayUE 1103 (step 1120). The relayUE 1103 may send a partial acknowledgement indicating the reception of the data bundle (step 1121). Depending on the decision in 1118, the DTDS@CN may send the DL group data bundle to the relayUE 1104 (step 1122). The relayUE 1104 may send a partial acknowledgement indicating the reception of the data bundle (step 1123).

[0242] Depending on the implementation and configuration from the SCS / AS 1109, the DTDS@CN NF 1107 may send a partial acknowledgement to the SCS / AS 1109 indicating that the data bundle was received at one or more repeaters (step 1124).

[0243] The DTDS@UE of relayUE 1103 may process the received group data based on the pre-configured service requirements (step 1125). For example, the relay may calculate how long this data can be buffered and still meet the delay tolerance requirements. If the monitoring requester (remUE 1102) is not currently communicating with relayUE 1103, the relay may decide to still broadcast or rebroadcast the data.

[0244] The relayUE 1103 may send a DL bundle group delivery (step 1126), and may send a partial acknowledgement indicating the delivery of (or a response to) the DL data bundle (step 1127).

[0245] Fig.11These steps in the example of can be accomplished through unicast or multicast signaling to a group of devices, and can also be accomplished outside of 3GPP signaling.

[0246] The DTDS configuration may indicate additional logic to be applied, such as "deliver via unicast until X responses are received" (in which case an anycast / somecast mechanism is effectively implemented at the repeater).

[0247] remUE2 1101 can discover relayUE 1104. Similar to Figure 8-10 1128). The relayUE 1104 may be attached to the CN. The DTDS@CN NF 1107 service may be configured by the SCS for the required service, and when communication is established with the remUE 1101, the relayUE 1104 may send a report with the ProSe UE ID (or equivalent), IP information (if applicable), etc. to the CN and request service from the DTDS@CN NF 1107 (step 1128). The relayUE 1104 may be provided with information about the DTDS required at the relay.

[0248] The relayUE 1104 repeats steps 1126 and 1127 to broadcast the given DL group bundle and respond to the DTDS@CN. The relayUE 1104 may send a DL bundle group delivery (step 1129) and may send a partial confirmation indicating the delivery of (or response to) the DL data bundle (step 1130). Figure 8 If additional parameters can be provided for group behavior, more complex functionality can be implemented. For example, the configuration can indicate conditional logic to be applied, such as "respond to DL bundle group delivery only if more than 5 responses have been received within the time window" (if the delivery is unicast).

[0249] The DTDS@CN NF 1107 may notify the SCS / AS 1109 of the completion of the group delivery of the data bundle (step 1131).

[0250] Fig.12 is a diagram of an example graphical user interface (GUI) 1200. The example GUI 1200 may enable a user to configure parameters or trigger actions as follows:

[0251] Enable DTDS@UE service for the UE itself 1201. Setting this option may trigger the DTDS configuration process.

[0252] Enables the UE to relay DTDS data for other UEs 1202. Setting this option may allow configuration of the UEs or groups of UEs for which the UE is willing to relay data.

[0253] Enables manual configuration of DTDS parameters, e.g. buffer 1203. Setting this option can trigger:

[0254] Buffer clear option 1204, which when selected causes the UE to clear any data that has been buffered.

[0255] Maximum buffer size option 1205 allows the user to limit the amount of data buffered in the DTDS@UE service.

[0256] Buffer time option 1206 allows the user to configure how long data packets are buffered.

[0257] The Third Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication network technologies, including radio access, core transport networks, and service capabilities - including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE-Advanced standards, and New Radio (NR), also referred to as "5G". The development of the 3GPP NR standards is expected to continue and include the definition of next generation radio access technologies (new RATs), which are expected to include the provision of new flexible radio access below 7 GHz, and the provision of new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to include new, non-backwards compatible radio access in new spectrum below 7 GHz, and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide set of 3GPP NR use cases with different requirements. Ultra-mobile broadband is expected to include cmWave and mmWave spectrum, which will provide opportunities for ultra-mobile broadband access for, for example, indoor applications and hotspots. In particular, ultra-mobile broadband is expected to share a common design framework with sub-7 GHz flexible radio access, with cmWave- and mmWave-specific design optimizations.

[0258] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (eMBB) ultra-reliable low-latency communication (URLLC), massive machine type communication (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy saving), and enhanced vehicle-to-everything (eV2X) communications, which may include vehicle-to-vehicle communication (V2V), vehicle-to-infrastructure communication (V2I), vehicle-to-network communication (V2N), vehicle-to-pedestrian communication (V2P), and vehicle communication with other entities. Specific services and applications in these categories include, for example, monitoring and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first responder connectivity, automotive electronic calling (ecall), disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile Internet, virtual reality, home automation, robotics, and aerial drones, among others. All of these use cases and others are contemplated herein.

[0259] Fig.13A An example communication system 100 is illustrated in which the systems, methods, and apparatus described and claimed herein may be used. The communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g, which may be generally or collectively referred to as WTRUs 102 or WTRUs 102. The communication system 100 may include a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and network services 113. The network services 113 may include, for example, V2X servers, V2X functions, ProSe servers, ProSe functions, IoT services, video streaming, and / or edge computing, etc.

[0260] It will be appreciated that the concepts disclosed herein may be used with any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102 may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Fig.13A In the example of FIG. 1 , each of the WTRUs 102 is Figures 13A-13EIt should be understood that for various use cases contemplated for wireless communications, each WTRU may include or be included in any type of device or apparatus configured to transmit and / or receive wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronics product, a wearable device (such as a smart watch or smart clothing), a medical or e-health device, a robot, an industrial equipment, a drone, a vehicle (such as a car, bus or truck, a train or airplane, etc.).

[0261] The communication system 100 may also include a base station 114a and a base station 114b. Fig.13A In the example of , each base station 114a and 114b is depicted as a single element. In practice, the base stations 114a and 114b may include any number of interconnected base stations and / or network elements. The base station 114a may be configured to wirelessly interface with at least one of the WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks (e.g., core networks 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112). Similarly, the base station 114b may be any type of device configured to wirelessly interface with at least one of the remote radio heads (RRHs) 118a, 118b, transmission and reception points (TRPs) 119a, 119b, and / or roadside units (RSUs) 120a and 120b to facilitate access to one or more communication networks (such as core networks 106 / 107 / 109, the Internet 110, other networks 112, and / or network services 113). The RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102 (e.g., WTRU 102c) to facilitate access to one or more communication networks (such as the core network 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112).

[0262] The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks (e.g., the core network 106 / 107 / 109, the Internet 110, the network services 113, and / or the other networks 112). The RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks (such as the core network 106 / 107 / 109, the Internet 110, the other networks 112, and / or the network services 113). By way of example, the base stations 114a, 114b may be base transceiver stations (BTSs), Node Bs, eNode Bs, Home Node Bs, Home eNode Bs, next generation Node Bs (gNode Bs), satellites, site controllers, access points (APs), wireless routers, and the like.

[0263] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. Similarly, the base station 114b may be part of the RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as a BSC, a RNC, a relay node, etc. The base station 114a may be configured to transmit and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). Similarly, the base station 114b may be configured to transmit and / or receive wired and / or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, for example, the base station 114a may include three transceivers, eg, one transceiver for each sector of the cell. The base station 114a may employ multiple-input multiple-output (MIMO) technology and may therefore use multiple transceivers for each sector of the cell, for example.

[0264] The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c, and 102g over an air interface 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0265] The base station 114b may communicate with one or more of the RRHs 118a and 118b, the TRPs 119a and 119b, and / or the RSUs 120a and 120b via a wired or air interface 115b / 116b / 117b, which may be any suitable wired (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., RF, microwave, IR, UV, visible light, cmWave, mmWave, etc.). The air interface 115b / 116b / 117b may be established using any suitable RAT.

[0266] The RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a and 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f via an air interface 115c / 116c / 117c, which may be any suitable wireless communication link (e.g., RF, microwave, IR, UV, visible light, cmWave, mmWave, etc.). The air interface 115c / 116c / 117c may be established using any suitable RAT.

[0267] The WTRUs 102 may communicate with each other via a direct air interface 115d / 116d / 117d, such as a sidelink communication, which may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, cmWave, mmWave, etc.). The air interface 115d / 116d / 117d may be established using any suitable RAT.

[0268] The communication system 100 may be a multiple-access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a and 120b and the WTRUs 102c, 102d, 102e, 102f in the RAN 103b / 104b / 105b may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 and / or 115c / 116c / 117c, respectively, using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0269] The base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c and 102g or the RRHs 118a and 118b, TRPs 119a and 119b and / or RSUs 120a and 120b and the WTRUs 102c and 102d in the RAN 103b / 104b / 105b may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish an air interface 115 / 116 / 117 or 115c / 116c / 117c using, for example, Long Term Evolution (LTE) and / or Advanced LTE (LTE-A), respectively. The air interface 115 / 116 / 117 or 115c / 116c / 117c may implement 3GPP NR technology. LTE and LTE-A technologies may include LTE D2D and / or V2X technologies and interfaces (such as sidelink communications, etc.). Similarly, 3GPP NR technologies may include NR V2X technologies and interfaces (such as sidelink communications, etc.).

[0270] The base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, and 102g or the RRHs 118a and 118b, the TRPs 119a and 119b and / or the RSUs 120a and 120b and the WTRUs 102c, 102d, 102e, and 102f in the RAN 103b / 104b / 105b may implement a radio technology such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE(GERAN) etc.

[0271] For example, Fig.13A The base station 114c in the figure can be a wireless router, a Home Node B, a Home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as a business place, a home, a vehicle, a train, an antenna, a satellite, a factory, a campus, etc. The base station 114c and the WTRU 102 (e.g., WTRU 102e) can implement radio technologies such as IEEE802.11 to establish a wireless local area network (WLAN). Similarly, the base station 114c and the WTRU 102 (e.g., WTRU 102d) can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). The base station 114c and the WTRU 102 (e.g., WRTU 102e) can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a picocell or a femtocell. As Fig.13A As shown in FIG, the base station 114c may have a direct connection to the Internet 110. Therefore, the base station 114c may not be required to access the Internet 110 via the core network 106 / 107 / 109.

[0272] The RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b may be in communication with a core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, messaging, authorization and authentication, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., and / or perform high-level security functions (such as user authentication).

[0273] Although not in Fig.13A 105b and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b, which may utilize an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) that employs a GSM or NR radio technology.

[0274] The core network 106 / 107 / 109 may also serve as a gateway for the WTRU 102 to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The other networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include any type of packet data network (e.g., an IEEE 802.3 Ethernet network) or another core network connected to one or more RANs, which may employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b, or a different RAT.

[0275] Some or all of the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f in the communication system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f may include multiple transceivers for communicating with different wireless networks via different wireless links. Fig.13A The WTRU 102g shown in FIG. 1 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.

[0276] Although not in Fig.13A 106 / 107 / 109. It will be appreciated that many of the concepts contained herein may be equally applicable to UEs of WTRUs and UEs that connect to the network using a wired connection. For example, concepts applicable to wireless interfaces 115, 116, 117, and 115c / 116c / 117c may be equally applicable to wired connections.

[0277] Fig. 13B 1 is a system diagram of an example RAN 103 and a core network 106. As described above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. Fig. 13B As shown in FIG. 1 , the RAN 103 may include Node-Bs 140a, 140b, and 140c, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 115. The Node-Bs 140a, 140b, and 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and Radio Network Controllers (RNCs).

[0278] like Fig. 13BAs shown in , Node B 140a, 140b can communicate with RNC 142a. In addition, Node B 140c can communicate with RNC 142b. Node B 140a, 140b and 140c can communicate with corresponding RNC 142a and 142b via Iub interface. RNC 142a and 142b can communicate with each other via Iur interface. Each of RNC 142a and 142b can be configured to control the corresponding Node B 140a, 140b and 140c to which it is connected. In addition, each of RNC 142a and 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security function, data encryption, etc.

[0279] Fig. 13B The core network 106 shown in FIG. 1 may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the foregoing elements is depicted as part of the core network 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0280] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communications devices.

[0281] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and IP-enabled devices.

[0282] The core network 106 may also be connected to other networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0283] Fig. 13C1 is a system diagram of an example RAN 104 and a core network 107. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0284] The RAN 104 may include eNode-Bs 160a, 160b, and 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs. The eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. For example, the eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0285] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and / or downlink, etc. Fig. 13C As shown in FIG. 1 , eNode-Bs 160a , 160b , and 160c may communicate with each other via an X2 interface.

[0286] Fig. 13C The core network 107 shown in FIG. 1 may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements is depicted as part of the core network 107, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0287] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, and 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0288] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route user data packets to and forward user data packets from the WTRUs 102a, 102b, and 102c. The serving gateway 164 may also perform other functions, such as anchoring a user plane during an inter-eNode B handover, triggering paging when downlink data is available for the WTRUs 102a, 102b, and 102c, managing and storing contexts of the WTRUs 102a, 102b, and 102c, and the like.

[0289] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0290] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks (e.g., the PSTN 108) to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communications devices. For example, the core network 107 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0291] Fig.13D 1 is a system diagram of an example RAN 105 and a core network 109. The RAN 105 may employ NR radio technology to communicate with the WTRUs 102a and 102b over the air interface 117. The RAN 105 may also be in communication with the core network 109. A non-3GPP interworking function (N3IWF) 199 may employ non-3GPP radio technology to communicate with the WTRU 102c over the air interface 198. The N3IWF 199 may also be in communication with the core network 109.

[0292] The RAN 105 may include gNode-Bs 180a and 180b. It will be appreciated that the RAN 105 may include any number of gNode-Bs. The gNode-Bs 180a and 180b may each include one or more transceivers for communicating with the WTRUs 102a and 102b over the air interface 117. When an integrated access and backhaul connection is used, the same air interface may be used between the WTRUs and the gNode-Bs, which may be a core network 109 via one or more gNBs. The gNode-Bs 180a and 180b may implement MIMO, MU-MIMO, and / or digital beamforming techniques. Thus, for example, the gNode-B 180a may use multiple antennas to transmit wireless signals to and receive wireless signals from the WTRU 102a. It will be appreciated that the RAN 105 may employ other types of base stations, such as an eNode-B. It will also be appreciated that the RAN 105 may employ more than one type of base station. For example, RAN may employ eNode-B and gNode-B.

[0293] The N3IWF 199 may include a non-3GPP access point 180c. It will be appreciated that the N3IWF 199 may include any number of non-3GPP access points. The non-3GPP access point 180c may include one or more transceivers for communicating with the WTRU 102c over the air interface 198. The non-3GPP access point 180c may communicate with the WTRU 102c over the air interface 198 using the 802.11 protocol.

[0294] Each of the gNode-Bs 180a and 180b may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and / or downlink, etc. Fig.13D As shown in FIG. 1 , for example, gNode-Bs 180a and 180b may communicate with each other via an Xn interface.

[0295] Fig.13D The core network 109 shown in the figure can be a 5G core network (5GC). The core network 109 can provide a variety of communication services to customers interconnected by a radio access network. The core network 109 includes multiple entities that perform the functions of the core network. As used herein, the term "core network entity" or "network function" refers to any entity that performs one or more functions of the core network. It should be understood that such a core network entity can be a device or computer system (such as a 5G core network) stored in a device or computer system configured for wireless and / or network communications. Figure 13GA logical entity implemented in the form of computer-executable instructions (software) stored in a memory of the system 90 shown in FIG. 1 and executed on a processor thereof.

[0296] exist Fig.13D In the example of , the 5G core network 109 may include access and mobility management function (AMF) 172, session management function (SMF) 174, user plane function (UPF) 176a and 176b, user data management function (UDM) 197, authentication server function (AUSF) 190, network exposure function (NEF) 196, policy control function (PCF) 184, non-3GPP interworking function (N3IWF) 199, user data repository (UDR) 178. Although each of the foregoing elements is depicted as part of the 5G core network 109, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator. It will also be appreciated that the 5G core network may not include all of these elements, may include additional elements, and may include multiple instances of each of these elements. Fig.13D The network functions are shown connected directly to each other, however, it should be appreciated that they may communicate via a routing agent such as a diameter routing agent or a message bus.

[0297] exist Fig.13D In the example of , the connectivity between network functions is realized via a set of interfaces or reference points. It will be appreciated that a network function can be modeled, described or realized as a set of services invoked or called by other network functions or services. The invocation of network function services can be realized via direct connections between network functions, message exchanges on a message bus, calling software functions, etc.

[0298] The AMF 172 may be connected to the RAN 105 via an N2 interface and may serve as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, access authorization. The AMF may be responsible for forwarding user plane tunnel configuration information to the RAN 105 via the N2 interface. The AMF 172 may receive user plane tunnel configuration information from the SMF via the N11 interface. The AMF 172 may generally route and forward NAS packets to / from the WTRUs 102a, 102b, and 102c via the N1 interface. The N1 interface is not used in Fig.13D Shown in.

[0299] The SMF 174 may be connected to the AMF 172 via an N11 interface. Similarly, the SMF may be connected to the PCF 184 via an N7 interface and to the UPFs 176a and 176b via an N4 interface. The SMF 174 may serve as a control node. For example, the SMF 174 may be responsible for session management, IP address allocation for the WTRUs 102a, 102b, and 102c, management and configuration of traffic steering rules in the UPFs 176a and 176b, and generation of downlink data notifications to the AMF 172.

[0300] The UPF 176a and UPF 176b may provide the WTRUs 102a, 102b, and 102c with access to a packet data network (PDN), such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, and 102c and other devices. The UPF 176a and UPF 176b may also provide the WTRUs 102a, 102b, and 102c with access to other types of packet data networks. For example, the other network 112 may be an Ethernet network or any type of network that exchanges data packets. The UPF 176a and UPF 176b may receive traffic steering rules from the SMF 174 via the N4 interface. The UPF 176a and UPF 176b may provide access to the packet data network by connecting the packet data network to the N6 interface or by connecting to each other and to other UPFs via the N9 interface. In addition to providing access to the packet data network, UPF 176 may also be responsible for packet routing and forwarding, policy rule enforcement, quality of service handling for user plane traffic, and downlink packet buffering.

[0301] The AMF 172 may also be connected to the N3IWF 199, for example, via an N2 interface. The N3IWF facilitates connectivity between the WTRU 102c and the 5G core network 170, for example, via a 3GPP undefined radio interface technology. The AMF may interact with the N3IWF 199 in the same or similar manner as it interacts with the RAN 105.

[0302] PCF 184 may be connected to SMF 174 via an N7 interface, to AMF 172 via an N15 interface, and to application function (AF) 188 via an N5 interface. The N15 and N5 interfaces are not Fig.13D1. The PCF 184 may provide policy rules to control plane nodes such as the AMF 172 and the SMF 174, thereby allowing the control plane nodes to enforce these rules. The PCF 184 may send policies for the WTRUs 102a, 102b, and 102c to the AMF 172 so that the AMF may deliver the policies to the WTRUs 102a, 102b, and 102c via the N1 interface. The policies may then be enforced or applied at the WTRUs 102a, 102b, and 102c.

[0303] The UDR 178 may act as a repository for authentication credentials and subscription information. The UDR may be connected to network functions so that the network functions may add data to, read data from, and modify data in the repository. For example, the UDR 178 may be connected to the PCF 184 via an N36 interface. Similarly, the UDR 178 may be connected to the NEF 196 via an N37 interface, and the UDR 178 may be connected to the UDM 197 via an N35 interface.

[0304] The UDM 197 may serve as an interface between the UDR 178 and other network functions. The UDM 197 may authorize network functions to access the UDR 178. For example, the UDM 197 may be connected to the AMF 172 via the N8 interface, and the UDM 197 may be connected to the SMF 174 via the N10 interface. Similarly, the UDM 197 may be connected to the AUSF 190 via the N13 interface. The UDR 178 and the UDM 197 may be tightly integrated.

[0305] The AUSF 190 performs operations related to authentication and is connected to the UDM 178 via the N13 interface and to the AMF 172 via the N12 interface.

[0306] NEF 196 exposes the functions and services in 5G core network 109 to application function (AF) 188. The exposure can occur on the N33 API interface. NEF can be connected to AF 188 via the N33 interface, and it can be connected to other network functions to expose the functions and services of 5G core network 109.

[0307] The application function 188 may interact with the network function in the 5G core network 109. The interaction between the application function 188 and the network function may occur via a direct interface or may occur via the NEF 196. The application function 188 may be considered part of the 5G core network 109 or may be external to the 5G core network 109 and deployed by an enterprise having a business relationship with a mobile network operator.

[0308] Network slicing is a mechanism that mobile network operators can use to support one or more "virtual" core networks behind the operator's air interface. This involves "slicing" the core network into one or more virtual networks to support different RANs or different service types running across a single RAN. Network slicing enables operators to create networks tailored to provide optimized solutions for different market scenarios that require different requirements (for example, in terms of functionality, performance and isolation).

[0309] 3GPP has designed the 5G core network to support network slicing. Network slicing is a great tool that network operators can use to support a diverse set of 5G use cases that require very diverse and sometimes extreme requirements (e.g., massive IoT, critical communications, V2X, and enhanced mobile broadband). Without using network slicing technology, the network architecture may not be flexible and scalable enough to efficiently support a wide range of traffic requirements when each use case has its own specific set of performance, scalability, and availability. In addition, the introduction of new network services should be made more efficient.

[0310] Reference again Fig.13D In a network slicing scenario, the WTRU 102a, 102b, or 102c may be connected to the AMF 172 via the N1 interface. The AMF may logically be part of one or more slices. The AMF may coordinate the connection or communication of the WTRU 102a, 102b, or 102c with one or more UPFs 176a and 176b, SMF 174, and other network functions. Each of the UPFs 176a and 176b, the SMF 174, and other network functions may be part of the same slice or different slices. When they are part of different slices, they may be isolated from each other in the sense that they may utilize different computing resources, security credentials, etc.

[0311] The core network 109 may facilitate communications with other networks. For example, the core network 109 may include, or may communicate with, an IP gateway (such as an IP Multimedia Subsystem (IMS) server) that serves as an interface between the 5G core network 109 and the PSTN 108. For example, the core network 109 may include, or may communicate with, a short message service (SMS) service center that facilitates communications via a short message service. For example, the 5G core network 109 may facilitate the exchange of non-IP data packets between the WTRUs 102a, 102b, and 102c and a server or application function 188. In addition, the core network 170 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0312] This article describes and Fig.13A , 13C The core network entities shown in 13D and 13E are identified by the names given to those entities in certain existing 3GPP specifications, but it will be appreciated that those entities and functions may be identified by other names in the future and that certain entities or functions may be combined in future specifications published by 3GPP (including future 3GPP NR specifications). Fig.13A , 13B The specific network entities and functions described and illustrated in 13C, 13D and 13E are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be implemented or realized in any similar communication system, whether currently defined or defined in the future.

[0313] Fig.13E An example communication system 111 is illustrated in which the systems, methods, and apparatus described herein may be used. The communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, a base station gNB 121, a V2X server 124, and roadside units (RSUs) 123a and 123b. In practice, the concepts presented herein may be applied to any number of WTRUs, base stations gNBs, V2X networks, and / or other network elements. One or several or all WTRUs A, B, C, D, E, and F may not be within the coverage of the access network 131. WTRUs A, B, and C form a V2X group, where WTRU A is the group leader and WTRUs B and C are group members.

[0314] If WTRUs A, B, C, D, E, and F are within access network coverage 131, they may communicate with each other via gNB 121 over the Uu interface 129. Fig.13E In the example of FIG. 1 , WTRUs B and F are shown within access network coverage 131. WTRUs A, B, C, D, E, and F may communicate directly with each other via a sidelink interface (e.g., PC5 or NR PC5) such as interface 125a, 125b, or 128, whether they are within or outside access network coverage 131. For example, in Fig.13E In the example of , WTRU D outside the access network coverage 131 communicates with WTRU F within the coverage 131.

[0315] WTRUs A, B, C, D, E, and F may communicate with the RSU 123a or 123b via the vehicle-to-network (V2N) 133 or the sidelink interface 125b. WTRUs A, B, C, D, E, and F may communicate with the V2X server 124 via the vehicle-to-infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, and F may communicate with another UE via the vehicle-to-person (V2P) interface 128.

[0316] Fig.13F is a block diagram of an example apparatus or device WTRU 102 that may be configured to wirelessly communicate and operate in accordance with the systems, methods, and apparatus described herein, such as Fig.13A , 13B , 13C, 13D, or 13E. Fig.13F As shown in the example WTRU 102, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements. Moreover, the base stations 114a and 114b, and / or the nodes that the base stations 114a and 114b may represent (such as, but not limited to, a transceiver station (BTS), a Node B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node B gateway, a next generation node B (gNode B), and a proxy node, etc.), may include Fig.13F Some or all of the elements depicted in and described herein.

[0317] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Fig.13F The processor 118 and the transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0318] The transmit / receive element 122 of the UE may be configured to transmit data to a base station (eg, Fig.13A The transmission / reception element 122 may be a base station 114a) of a wireless communication network, or may transmit or receive signals to or from another UE via an air interface 115d / 116d / 117d. For example, the transmission / reception element 122 may be an antenna configured to transmit and / or receive RF signals. The transmission / reception element 122 may be a transmitter / detector configured to, for example, transmit and / or receive IR, UV, or visible light signals. The transmission / reception element 122 may be configured to transmit and receive both RF and optical signals. It will be appreciated that the transmission / reception element 122 may be configured to transmit and / or receive any combination of wireless or wired signals.

[0319] In addition, although the transmit / receive element 122 is Fig.13F Although depicted as a single element in the figure, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0320] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11 or NR and E-UTRA) or to communicate with the same RAT via multiple beams to different RRHs, TRPs, RSUs, or nodes.

[0321] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, or the like. The processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server hosted in a cloud or edge computing platform or in a home computer (not shown).

[0322] The processor 118 may receive power from the power source 134 and may be configured to distribute power to and / or control other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.

[0323] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 115 / 116 / 117 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method.

[0324] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, Bluetooth modules, FM radio units, digital music players, media players, video game player modules, internet browsers, etc.

[0325] The WTRU 102 may be included in other devices or equipment, such as sensors, consumer electronics, wearable devices (such as smart watches or smart clothing), medical or e-health equipment, robots, industrial equipment, drones, vehicles (such as cars, trucks, trains or airplanes, etc.) The WTRU 102 may be connected to other components, modules or systems of such devices or equipment via one or more interconnect interfaces (such as an interconnect interface that may include one of the peripheral devices 138).

[0326] Figure 13G is a block diagram of an exemplary computing system 90 in which Fig.13A , 13C , 13D and 13E, such as certain nodes or functional entities in the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110, other networks 112 or network services 113. The computing system 90 may include a computer or a server and may be primarily controlled by computer-readable instructions, which may be in the form of software, regardless of where or how such software is stored or accessed. Such computer-readable instructions may be executed within the processor 91 to enable the computing system 90 to work. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor distinct from main processor 91 that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

[0327] In operation, processor 91 fetches, decodes and executes instructions, and transfers information to and from other resources via the computing system's main data transfer path, system bus 80. Such a system bus connects components in computing system 90 and defines a medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0328] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes a circuit system that allows information to be stored and retrieved. ROM 93 generally contains stored data that is not easily modified. The data stored in RAM 82 can be read or changed by a processor 91 or other hardware device. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that translates a virtual address into a physical address when an instruction is executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing between processes has been set up, it cannot access memory within the virtual address space of another process.

[0329] In addition, the computing system 90 may include a peripheral device controller 83 that is responsible for transmitting instructions from the processor 91 to peripheral devices such as a printer 94 , a keyboard 84 , a mouse 95 , and a disk drive 85 .

[0330] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). The display 86 may be implemented with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch pad. The display controller 96 includes the electronic components required to generate the video signal sent to the display 86.

[0331] Additionally, computing system 90 may include communications circuitry such as, for example, a wireless or wired network adapter 97, which may be used to connect computing system 90 to an external communications network or device (such as a wireless or wired network adapter 97). Fig.13A , 13B, RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, WTRU 102 or other network 112 of 13C, 13D and 13E to enable the computing system 90 to communicate with other nodes or functional entities of those networks. Alone or in combination with the processor 91, the communication circuit system can be used to perform the transmission and reception steps of certain devices, nodes or functional entities described herein.

[0332] It should be understood that any or all of the devices, systems, methods, and processes described herein may be implemented in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor (such as processor 118 or 91), causes the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any step, operation, or function described herein may be implemented in the form of such computer executable instructions executed on a processor of a device or computing system configured for wireless and / or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any non-transient (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, cassette, tape, disk storage or other magnetic storage device, or any other tangible or physical medium that can be used to store desired information and can be accessed by a computing system.

Claims

1. A wireless transmission / reception unit WTRU, comprising a processor, wherein the processor is configured to: establishing a connection with a radio access network; receiving a downlink transmission from a core network entity, the downlink transmission comprising delay tolerant data DTD and control information; Sending a partial acknowledgment to a core network entity; determining buffered downlink transmissions; Establishing a connection with a remote WTRU; sending delay tolerant data to a remote WTRU; receiving a reception from a remote WTRU; as well as Send end-to-end confirmation to the core network entity.

2. The WTRU of claim 1, wherein the downlink transmission comprises a DTD tag.

3. The WTRU of claim 1 , wherein the connection with the remote WTRU is a sidelink connection.

4. The WTRU of claim 1, wherein the WTRU is a user equipment (UE).

5. The WTRU of claim 1 , wherein the processor is further configured to: receiving Delay Tolerant Data Service (DTDS) information from a remote WTRU; and A report is sent to a core network entity indicating DTDS information associated with the remote WTRU.

6. The WTRU of claim 5, wherein the report includes one or more of an identifier (ID) of the remote WTRU or address information associated with the remote WTRU.

7. The WTRU of claim 1 , wherein the processor is further configured to: receiving a downlink paging request from a core network entity; paging the remote WTRU in accordance with the downlink paging request; and Send a paging report to the core network entity.

8. The WTRU of claim 1 , wherein the processor is further configured to: One or more of delay tolerant data service information or DTDtag information is received from a core network entity.

9. The WTRU of claim 1 , wherein the processor is further configured to: Sending a Delay Tolerant Data Service (DTDS) request to a core network entity; and Receive a DTDS response from the core network entity.

10. A method for a wireless transmit / receive unit WTRU, comprising: establishing a connection with a radio access network; receiving a downlink transmission from a core network entity, the downlink transmission comprising delay tolerant data DTD and control information; Sending a partial acknowledgment to a core network entity; determining buffered downlink transmissions; Establishing a connection with a remote WTRU; sending delay tolerant data to a remote WTRU; receiving a reception from a remote WTRU; as well as Send end-to-end confirmation to the core network entity. The method of claim 10 , wherein the downlink transmission comprises a DTD tag.

12. The method of claim 10, wherein the connection with the remote WTRU is a sidelink connection.

13. The method of claim 10, wherein the WTRU is a user equipment (UE).

14. The method of claim 10, further comprising: receiving delay tolerant data service (DTDS) information from a remote WTRU; as well as A report is sent to a core network entity indicating DTDS information associated with the remote WTRU.

15. The method of claim 14, wherein the report includes one or more of an identifier (ID) of the remote WTRU or address information associated with the remote WTRU.

16. The method of claim 10, further comprising: receiving a downlink paging request from a core network entity; paging the remote WTRU in accordance with the downlink paging request; as well as Send a paging report to the core network entity.

17. The method of claim 10, further comprising: One or more of delay tolerant data service information or DTDtag information is received from a core network entity.

18. The method of claim 10, further comprising: Sending a Delay Tolerant Data Service (DTDS) request to a core network entity; as well as Receive a DTDS response from the core network entity.

19. An apparatus comprising a receiver and a transmitter, wherein the receiver and the transmitter are configured to: receiving a paging request from a network entity, the paging request including an indication of one or more wireless transmit / receive units WTRUs to be paged; providing a list of relay WTRUs in response to the paging request; sending a message to each relay WTRU in the list of relay WTRUs, wherein the message indicates one or more WTRUs to be paged; receiving a response from a relay in the list of relay WTRUs, wherein the response indicates that the relay is able to contact one or more of the WTRUs to be paged; as well as An indication is sent to a network entity that the relay can contact one or more of the WTRUs to be paged.

20. The device of claim 19, wherein: The receiver and the transmitter are further configured to send a command to each relay WTRU in the relay WTRU list, wherein the command includes an instruction to remain connected until paging is complete.

Images