Cellular system support for end-to-end redundancy delivery at service layer

Abstract

Methods and systems for supporting redundancy delivery in a cellular system at an application layer are disclosed herein. A user equipment may establish a first connection and a second connection with a wireless network. The user equipment may transmit data to the receiver device via both the first connection and the second connection. The first connection and the second connection may be redundant connections. Methods and systems apply to the context of key problem # 1 in a 3GPP SA6 vertical service enabler architecture layer (SEAL) and 3GPP TR 23.700-34.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. patent application No. 63 / 324,550, filed on March 28, 2022. Background Art

[0003] 3GPP SA6 defines a Vertical Service Enabler Architecture Layer (SEAL) for providing a horizontal layer in which public services are made available to the vertical application layer, for example in the following: 3GPP TS23.434, Vertical Service Enabler Architecture Layer (SEAL); Functional Architecture and Information Flows; V17.4.0; 3GPP SP-210955, Study of SEAL Data Delivery Enabler for Vertical Applications; and 3GPP TR 23.700-34, Study of SEAL Data Delivery Enabler for Vertical Applications; V0.3.0. Summary of the invention

[0004] Methods and systems for supporting redundant transport in a cellular system at a service layer are described herein. For example, redundant transport can be provided by the SEAL Data Delivery (SEALDD) layer of a 5G application enabler system, because the SEALDD layer can provide common horizontal services to some or all vertical applications. The method can focus on the support of redundant transport at the SEALDD layer to ensure compatibility between various vertical applications and minimize functional duplication at the vertical application layer that may be incompatible. Application clients and servers can utilize a common interface to obtain reliable communication without the need to support session management functions required by redundant transport.

[0005] On the one hand, an API definition for application clients and servers to request data delivery services from a SEALDD layer is described, and the API definition can provide an application client-triggered process and an application server-triggered process for enabling communication with redundant transport. In addition, the SEALDD layer can also initiate an upgrade from a single transport communication to a redundant transport communication for reliable data delivery.

[0006] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not 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 solve any or all disadvantages noted in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The following detailed description is better understood when read in conjunction with the accompanying drawings. For illustrative purposes, examples are shown in the drawings; however, the subject matter is not limited to the specific components and instrumentalities disclosed. In the drawings:

[0008] Figure 1 An example architecture of the service enabler layer is shown.

[0009] Figure 2 An example method is shown.

[0010] Figure 3 An example method is shown.

[0011] Figure 4 An example method is shown.

[0012] Figure 5 An example method is shown.

[0013] Figure 6 An example method is shown.

[0014] Figure 7 An example computing device interface is shown.

[0015] Fig. 8A An example system is shown.

[0016] Figure 8B An example device is shown.

[0017] Figure 8C An example system is shown.

[0018] Fig.8D An example system is shown.

[0019] Fig. 8E An example system is shown.

[0020] Fig.8F An example system is shown.

[0021] Figure 8G An example system is shown. DETAILED DESCRIPTION

[0022] Methods and apparatus for supporting redundant transport in a cellular system at a service layer are described herein.

[0023] The following abbreviations may be used in this article:

[0024]

[0025]

[0026] SEAL Architecture

[0027] Figure 1is copied from 3GPP TS23.434 and shows an example of a vertical service enabler architecture layer (SEAL) defined in the 3GPP SA6 working group. The SEAL can provide a horizontal layer in which public services are made available to the vertical application layer. Examples of public services include: location management; group management; configuration management; identity management; key management; and / or network resource management.

[0028] A vertical application layer (VAL) client can access one or more services provided by a SEAL client on a UE, which can use the SEAL-UU interface to deliver traffic to a SEAL server. The SEAL server can route traffic to a destination VAL server and can communicate with other SEAL servers. In addition, the SEAL server can access network exposure information via a network interface with a 3GPP network. SEAL services can be accessed by VAL clients and VAL servers through API exposure of public functions provided by the SEAL layer to at least multiple vertical applications.

[0029] The SEAL server can be deployed as part of a PLMN operator domain or a VAL service provider domain. When deployed in a VAL service provider domain, the SEAL server can have connections to multiple PLMN operator domains. The SEAL server can be connected to a 3GPP network system, and one SEAL server can support multiple VAL servers. The functional model of the SEAL layer can be described as an on-network where the communication involves a 3GPP network or an off-network where the communication occurs between two UEs.

[0030] SEAL Data Delivery

[0031] In Release 18, 3GPP recognizes the need for application layer support for efficient data distribution, delivery, and caching towards the application layer. The purpose of the study on the SEAL Data Delivery (SEALDD) enabler is to study new capabilities for data delivery of application data. Various aspects of the study include potential integration of existing functions, such as MSGin5G and data delivery via 5G multicast-broadcast services. Other aspects include the introduction of new capabilities for supporting application functions such as caching and delivery of application content or data, different application data characteristics, and end-to-end ultra-reliable low-latency communication (URLLC) data delivery mechanisms. 3GPPSP-210955 captures the goals of the SEALDD study.

[0032] Redundant PDU sessions using dual connections

[0033] Dual connectivity is specified in Release 16 to support URLLC traffic, where the UE establishes a PDU session through a primary RAN node and a secondary RAN node. The two PDU sessions are set up with disjoint user plane paths to provide redundancy for the underlying traffic. At the sender end, data can be replicated and sent over two PDU sessions, and at the receiver end, data from one PDU session can be eliminated when data from both PDU sessions are available. In the event of data loss from one PDU session, the receiver may be able to use data from another PDU session to continue the service uninterrupted.

[0034] In Release 17, redundant transmission using dual connectivity is enhanced to provide both the Redundant Sequence Number (RSN) and the PDU Session Pair ID to the RAN node. The RSN that had been provided to the RAN node in Release 16 only informed the RAN node whether the PDU session was redundant. However, the RAN node did not know which PDU Session pairs were redundant and could be associated with each other until the PDU Session Pair ID was introduced in Release 17. The RAN node can use the PDU Session Pair ID to associate the PDU sessions and further optimize redundant traffic. The PDU Session Pair ID and RSN values ​​are defined in the UE Routing Selection Policy (URSP) rules that the UE uses to route application traffic to the PDU sessions that the UE establishes with the 5G core network.

[0035] Network data analysis function

[0036] 5G networks can expose information about UE and network performance by using analytics provided by the Network Data Analysis Function (NWDAF). If the application server is operated by a mobile network operator, the application server can access NWDAF directly, or if the application server is a third party, it can access NWDAF via the Network Exposure Function (NEF). NWDAF can provide statistics or predictions on information such as observed service experience, network function load, network performance, UE mobility, UE communications, user data congestion, QOS sustainability, etc.

[0037] One aspect of SEALDD research focuses on the support of end-to-end data delivery mechanisms for URLLC situations. This aspect is captured as Key Issue #1 in 3GPP TR 23.700-34. Support for end-to-end data delivery depends on the availability of dual connectivity functionality introduced in Release 16. Currently, dual connectivity support is at the lower layers of the protocol stack, and as a result, it is expected that upper layer support is required to utilize dual connectivity for redundant transmission. Therefore, the application layer may need to support data duplication and elimination required by redundant transmission.

[0038] Key issue #1 of 3GPP TR 23.700-34 notes that upper layer protocols that support redundant communications may not always be available to application clients, and procedures for using redundant user plane paths are not yet defined. Therefore, support for packet / data duplication and elimination is required at the application layer to enable end-to-end redundant transport. In addition, new enabler services need to interact appropriately with existing dual connectivity capabilities provided by 5G networks. Finally, having redundant communication support at the SEALDD layer enables multiple vertical applications to take advantage of redundant transport.

[0039] Support for redundant transport may be best provided by the SEALDD layer of the 5G application enabler system, because the SEALDD layer provides common horizontal services to all vertical applications. The example methods described herein focus on supporting redundant transport at the SEALDD layer, thereby ensuring compatibility between various vertical applications and reducing or avoiding functional duplication at the vertical application layer that may be incompatible. Application clients and servers can utilize a common interface to obtain reliable communication without the need to support session management functions required by redundant transport.

[0040] The example described in this article proposes an API definition for application clients and servers to request data delivery services from the SEALDD layer, and provides an application client-triggered process and an application server-triggered process for enabling communication with redundant transport. In addition, the SEALDD layer can also initiate an upgrade from a single transport communication to a redundant transport communication for reliable data delivery.

[0041] Examples described herein include a method for a SEALDD client to perform the following steps: 1) Receive a first request for a data delivery service from an application or a VAL client, wherein the first request may include information of application traffic. The information of the application traffic may include at least one of the following: an application identifier, application server contact information (FQDN, IP address and port number), QoS requirements, indication of reliable communication, time constraints, spatial constraints, UE mobility information, and utilization of edge resources; 2) determining that redundant delivery is required to meet the data delivery requirements of the application or VAL client based on the information received in the first request; 3) discovering a SEALDD server that can serve the application traffic, and sending a second request to the SEALDD server to configure the application traffic for redundant delivery; 4) receiving a response to the second request, the response indicating the status of the request for redundant delivery; 5) sending a response to the application or VAL client with the status of the first request for data delivery service; 6) sending a third request and a fourth request to enable the user equipment to establish a redundant PDU session with the network; or 7) receiving data from the application client or application server, and processing the data to send to the redundant PDU session established in the third request and the fourth request, wherein the processing of the data may include data segmentation, data replication, data elimination and data reassembly.

[0042] Examples described herein include a method for a SEALDD server to perform the following steps: 1) detecting a trigger condition to send a request to a cellular network to affect traffic for a UE, wherein the trigger condition may be one or more of the following: receiving a first request for a data delivery service from an application or VAL server to configure a communication session for application traffic, and receiving a notification from the cellular network about one or more events (e.g., network congestion, etc.) that may affect the application traffic of the UE; 2) using information from the first request, sending a second request to the cellular network to affect traffic for the application traffic of the user equipment. The second request may include one or more of the following: an AF identifier, service parameters describing the application traffic (e.g., such as DNN, S-NSSAI, UE application descriptor, AF service identifier), a target UE identifier or information about the UE, a UE location, redundant transport information, temporal and spatial validity conditions, application or VAL server contact information such as FQDN or IP address and port number, wherein the redundant transport information may include a PDU session pair ID and a redundant sequence number. The second request may cause the network to send one or more UE routing policies (URSPs) to the user equipment for establishing a PDU session for application traffic, wherein the URSPs may include information in the second request; 3) send a message to notify the SEALDD client to configure redundant transport for application traffic; 4) receive an acknowledgment of the message that redundant transport has been configured for application traffic; 5) send a response to the first request that data delivery service has been established; and 6) receive application data on the redundant transport and reassemble the data for sending to the application server.

[0043] The examples described herein include a method for a SEALDD client to perform the following steps: 1) receiving a first request for a data delivery service from an application or VAL client, wherein the first request may cause a user device to create a PDU session to carry application traffic from the UE to an application server; 2) detecting that data communication for application traffic is unreliable, wherein the user device needs to retransmit data packets to the application server; 3) sending a second request to a SEALDD server to configure the application traffic for redundant delivery. The second request may cause the SEALDD server to send a third request to the network, the third request may include an AF identifier, service parameters describing the application traffic (e.g., such as DNN, S-NSSAI, UE application descriptor, AF service identifier), a target UE identifier or information about the UE, UE location, redundant delivery information, temporal and spatial validity conditions, application or VAL server contact information such as FQDN or IP address and port number, wherein the redundant delivery information may include a PDU session pair ID and a redundant sequence number. The third request may cause the network to send one or more UE routing policies (URSPs) to the user equipment for establishing a PDU session for application traffic, wherein the URSP may include information in the third request; 4) receiving a response to the second request indicating a status of the request for redundant transport; 5) sending a response to the application or VAL client regarding the status of the first request for data delivery service; 6) sending a third request and a fourth request for the user equipment to establish a PDU session with the network; and 7) receiving data from the application client or application server and processing the data to send to the PDU session established in the third request and the fourth request, wherein processing the data may include data segmentation, data duplication, data elimination, and data reassembly.

[0044] When the SEALDD layer provides data delivery services to applications or VAL clients and servers, API service requests can be defined to enable applications or VAL clients and servers to access the services. Using the API definitions, the application or VAL client or server can request redundant transport, and the SEALDD layer can perform the required communications to enable the service. The SEALDD client can communicate with the lower layers of the UE, and the SEALDD server can communicate with the 5G core network and OAM system. Note that the terms application and VAL are used interchangeably below to refer to client or server operations performed at the vertical application layer on the UE or application server, respectively. In addition, the terms redundant transport, redundant PDU sessions, and reliable communication refer to the fact that redundancy has been established for application traffic to flow on non-intersecting user paths to minimize communication interruptions.

[0045] Open API for triggering SEALDD service with redundant delivery

[0046] Table 1 shows an example API definition that an application client or server can use to request data delivery services from the SEALDD layer. The API definition shown in Table 1 provides a non-exhaustive list of parameters included in the API call and associated requirements specified by the M / O column, where M represents a mandatory inclusion in the API and O represents an optional inclusion. A request for redundant transport can be explicitly indicated through the reliable communication parameter.

[0047]

[0048]

[0049] Table 1 - SEALDD service request example API definition

[0050] The service request API includes one or more mandatory parameters that the requester provides in order to access the SEALDD service. Identifiers are required for the requester, the UE from which the application traffic originates, and the application identifier. Additionally, server contact information for the traffic destination and any QoS requirements for the application traffic are required. This information allows the SEALDD layer to effectively manage the traffic between the UE and the application server.

[0051] Other optional information may be provided to allow the SEALDD layer to better manage application traffic between the UE and the application server. If the application traffic requires low latency or high reliability, reliable communication parameters may be explicitly indicated to inform the SEALDD layer to initiate the establishment of redundant transport for the UE. Any known time or space restrictions may also be provided to ensure that application traffic is allowed during the time and location where the application traffic is authorized. Mobility information of the UE (if known) may be provided to assist the SEALDD layer in managing service continuity issues, especially if edge computing information is also provided.

[0052] The SEALDD service request API can be accessed by an application client or server to initiate services at the SEALDD layer. In the example of a gaming use case, the application or VAL client can access the API when a game is launched by a user of the UE. Similarly, after the user registers with the application or VAL server to establish a gaming session, the application or VAL server can access the API on behalf of the user of the UE.

[0053] The API may be accessed for situations where application traffic is initially established without assistance from the SEALDD layer and is later upgraded to use SEALDD services with redundant transports due to poor quality of service. For these situations, application traffic is initially established using a single transport instead of using SEALDD services. The application traffic may experience QoS degradation, and an application client or server may access the service request API to request assistance from the SEALDD layer to improve the QoS of the application traffic, for example by upgrading to use redundant transports.

[0054] Although an explicit indication of reliable communication parameters for redundant transport may be provided, the SEALDD layer may also infer the need for redundant transport using QoS requirements provided by the application client or server and other information that the SEALDD layer has about the UE or in the performance degradation indication system provided by the network. The SEALDD client may access information about UE capabilities, UE mobility, performance measurements from lower layers, and other application or edge computing information that may be used to determine the need for redundant transport. The SEALDD server may use information about the UE (e.g., obtained from the SEALDD client, application server, 5G network, or OAM system) and also information about network performance and analysis (e.g., obtained from the 5G network or OAM system) to make a determination to perform redundant transport.

[0055] A response may be returned to the requestor regarding the status of the service request, which may also include a transaction identifier. In the event that the requested service cannot be granted, the response may also include an error code, and potentially additional information regarding the reason why the request was not granted.

[0056] The service request API definition shown in Table 1 can be a common API applied to both application clients and application servers to obtain SEALDD services. In this way, some parameters may be open only to application servers and not to application clients. For example, edge computing resource parameters may be open only to application servers to request SEALDD services for traffic from applications on UEs. The application server may have additional information about the UE, such as location, relative distance of the UE to the application server, and UE mobility prediction from the NWDAF to make determinations for requesting reliable communications for the UE and using edge computing resources when needed.

[0057] SEALDD layer support for redundant transport

[0058] The SEALDD service request API may allow an application client or server to request reliable communication from the SEALDD layer. Upon receiving the service request API, the SEALDD layer performs communication to enable data delivery service with redundant transport. Figure 2 An example of an application client on a UE making a service request to use a SEAL data delivery service with redundant transport is shown. In this example, the application client may have been provisioned or configured with contact information of an application server to which the application data is sent. The contact information may be the FQDN or IP address and port number of the application server.

[0059] In step 1, the application or VAL client on the UE issues a request for a data delivery service from the SEALDD layer to send application traffic to the application or VAL server. The request may include one or more of the following: an application identifier, application or VAL server contact information such as an FQDN or IP address and port number, QoS requirements for the traffic, possible UE mobility information, an indication of reliable communication (if desired), and any known time or space restrictions on the application traffic. The UE mobility information may be an indication of the UE's mobility, or it may be more detailed location information obtained from a navigation application on the UE representing a planned route.

[0060] In step 2, the SEALDD client on the UE may process the request and, based on information provided by the application or VAL client, make a determination to use redundant transport for application traffic. The SEALDD client may make the determination based on one or more of specified QoS requirements, the presence of an indication of reliable communication, and / or performance measurements obtained from lower layers of the UE (e.g., low signal strength). The SEALDD client may perform SEALDD server discovery to find a SEALDD server that supports redundant transport and can serve the UE.

[0061] In step 3, the SEALDD client may send a request to the SEALDD server to configure redundant transport for an application on the UE, and may include one or more of the following: application descriptors for traffic (e.g., operating system identifier and version, application identifier), identifier and location of the UE, UE capabilities, QoS requirements, indication of reliable communication, time and / or space restrictions on application traffic, UE mobility information, UE performance measurements such as signal strength obtained from lower layers, application or VAL server contact information such as FQDN or IP address and port number, data segmentation requirements and packet size, etc. The SEALDD client may consider the performance measurements obtained from the lower layers when making a determination for redundant transport or for the use of data segmentation. Alternatively, the SEALDD client may forward information about the UE without making a determination for redundant transport, and let the SEALDD server make a determination to use redundant transport based on the provided information.

[0062] In step 4, the SEALDD server acting as an application function (AF) may initiate an AF impact on the URSP process using the 5G core network. The SEALDD server may induce one or more of the following in the request: a service description that may be an AF identifier, service parameters describing application traffic (e.g., such as DNN, S-NSSAI, UE application descriptor, AF service identifier), a target UE identifier or information about the UE, UE location, UE capabilities, redundant transport information, time and space validity conditions, application or VAL server contact information such as FQDN or IP address and port number, subscription information for receiving notifications, etc. The UE may receive an updated URSP rule in which a traffic descriptor and / or a routing descriptor (RSD) includes information provided by the SEALDD server. Some examples include: an IP descriptor including an application or VAL server IP address and port number, a domain descriptor including an FQDN, and / or an RSD including redundant transport information such as a PDU session pair ID and an RSN value to enable redundant PDU sessions for the UE. The PDU Session Pair ID and RSN values ​​may have been provided to the SEALDD server by the 5G core network, the OAM system, or as part of pre-configuration. Alternatively, the SEALDD server may have been supplied with mapping information relating the DNN and / or S-NSSAI to the PDU Session Pair ID and RSN values.

[0063] In step 5, the SEALDD server may issue a response to the SEALDD client to enable redundant transport for application traffic. The response may include information about one or more of the time and space limits for redundant transport and the selected data segment packet size. The SEALDD client may issue a response to the application or VAL client with the status of the service request.

[0064] In step 6, the SEALDD client may trigger the UE to use the updated URSP rules and establish a redundant PDU session with dual connectivity. As a result, the PDU session is established with disjoint user plane paths.

[0065] In step 7, the SEALDD client may receive the application data and duplicate the data on the redundant PDU session. If data segmentation is enabled to provide finer granularity of transmission packets for situations where the transmission quality may be low or the size of the application data payload exceeds the maximum packet size supported by one or both of the redundant PDU sessions, the SEALDD client may apply segmentation of the data before duplication. This may be required if the UE is at the edge of network coverage to minimize the packet retransmission size for situations when packets from two PDU sessions may be lost. Alternatively, instead of requiring separate requests for steps 1 and 6, these steps may be combined into a single request (i.e., the application data and / or an indication to establish a session between the application / VAL client and the application / VAL may be included in the request defined in step 1).

[0066] In step 8, the application data may be sent to the SEALDD server over the redundant PDU session via a disjoint user plane path. When sending application data, the SEALDD client may encapsulate the application data within a SEALDD message. The SEALDD client may also segment the application data into multiple SEALDD messages. For example, if the application data payload is larger than the maximum packet size configured for data segmentation requirements. The SEALDD message may also include a SEALDD header, which may include information such as a SEALDD message identifier or sequence number. The SEALDD header may include an indicator of whether a SEALDD message confirmation needs to be returned from the SEALDD server to the SEALDD client. Similarly, the SEALDD server may apply data segmentation (if enabled) before performing data replication to send downlink application traffic to the UE over a disjoint user plane path.

[0067] In step 9, when receiving data, the SEALDD server can reorganize application data according to the received SEALDD message received from the SEALDD client before the reorganized data is sent to the application or VAL server. As a part of the reorganization, the SEALDD server can eliminate duplicate packets from redundant transmission, and can also reorganize the application data payload segmentation of segmentation across multiple SEALDD messages. The SEALDD server can also compensate for any lack of message synchronization across redundant transmission. For example, the SEALDD server can compensate for any delay between the redundant SEALDD messages it receives by buffering the message from one or both in the PDU session. The SEALDD message identifier or the sequence number in the header of the SEALDD message can be used to perform message replication, segmentation and reorganization and synchronization operation. For the situation that the data from the same segment is not received on any transmission, the SEALDD server can notify the SEALDD client to resend the data for those segments. This notification can be implemented as the confirmation that the SEALDD server returns to the SEALDD client in band by one or both in the redundant PDU session. Alternatively, the notification can be implemented as a message sent from the SEALDD server to the SEAL client out-of-band via a separate PDU session. For example, the SEALDD client may have a subscription to receive notifications from the SEALDD server. These notifications may target the notification URI of the SEALDD client and may use a separate PDU session from a redundant PDU session. Since segmentation reduces the size of the data packet, retransmissions may be faster, especially when the UE signal strength is weak. Similar to the processing performed by the SEALDD server, the SEALDD client may also perform the same processing (e.g., data desegmentation, elimination, and reassembly) for traffic received from the SEALDD server via disjoint user plane paths.

[0068] Notice, Figure 2 Steps 7 to 9 of describe redundant delivery of application traffic flows from the UE to the application server on the uplink path. Redundant delivery of application traffic flows from the application server to the UE on the downlink path is also supported. For downlink traffic, the SEALDD server can perform data segmentation and replication, while the SEALDD client performs data elimination and reassembly.

[0069] Currently, dual connectivity only supports 3GPP access technologies. However, redundant transport can also be applied to support redundancy by using one 3GPP access and one non-3GPP access such as Wi-Fi. Figure 2The same process as shown in , but with slight changes to the routing descriptor (RSD) of the URSP rule. In this case, the access type preference parameter of the RSD can be specified so that one PDU session uses 3GPP access and the other PDU session uses non-3GPP access. The SEALDD client and server can communicate the use of multiple access types within the SEALDD layer and manage redundant PDU sessions accordingly. For example, the SEALDD client can copy application traffic to both 3GPP access and non-3GPP access, and the SEALDD server can eliminate data from one of the accesses before sending the application data to the application server. Unlike the dual connection method in which the 5G network is aware of and can optimize redundant PDU sessions, this method can limit awareness of redundant transport to the SEALDD layer. For some UEs, dual connectivity may not be available, and this method can allow those UEs to use redundant transport to communicate reliably using multiple access types. The SEALDD client on the UE or the SEALDD server in the network can access information about the UE capabilities and make a determination as to which method to use for redundant transport.

[0070] Systems and methods for redundant delivery are presented herein. For example, Figure 2 The method described in may include a redundant transport client and sending a request to a redundant transport server to configure the redundant transport server for redundant transport of an application associated with a user device. The method may also include receiving an indication of a redundant transport session associated with the application from the redundant transport server. The method may also include establishing a plurality of redundant protocol data unit (PDU) sessions associated with the user device by the redundant transport client and for the user device. The method may also include replicating application data received from the application associated with the user device on at least two of the plurality of redundant PDU sessions. The method may also include sending the replicated application data to the redundant transport server via at least two of the plurality of redundant PDU sessions.

[0071] Figure 2 The method described in may also include receiving a request from an application associated with the user device to send application data to an application server associated with the application via redundant transport.

[0072] Figure 2 The method described in may also include: wherein the redundant transport server is a suitable redundant transport server among a plurality of redundant transport servers, and the redundant transport client is configured to discover the suitable redundant transport server in response to receiving a request to send application data via a redundant transport.

[0073] Figure 2The method described in may also include: wherein the request includes at least one of the following: an application identifier, an indication of an application server, a quality of service indication associated with the application data, mobility information associated with the user device, a request for reliable communication, or a restriction associated with the application data.

[0074] Figure 2 The method described in may also include: in response to sending the request for redundant transport, receiving updated user equipment (UE) routing selection policy (URSP) rules associated with redundant transport.

[0075] Figure 2 The method described in may also include: wherein the redundant transport client is further configured to segment the application data based on at least one of transmission quality, a size associated with the application data, or a maximum packet size of the application data associated with at least one of the redundant PDU sessions.

[0076] Figure 2 The method described in may also include: wherein the redundant PDU sessions include disjoint user plane paths.

[0077] Figure 2 The method described in may also include: wherein the redundant transport server is configured to send one of the replicated application data instances to an application server associated with the application.

[0078] Figure 2 The method described in may also include: wherein the redundant transport server is configured to de-duplicate the multiple instances of the application data based on receiving the multiple instances of the application data from the redundant PDU session.

[0079] For example, Figure 2 An apparatus may be described that includes one or more processors and a memory storing instructions that, when executed by the one or more processors, cause a server apparatus to perform one or more actions. For example, Figure 2 The device described in the embodiment may receive a request to configure redundant transport associated with an application from a redundant transport client. The device may also send an application function (AF) impact on a user equipment (UE) routing selection policy (URSP) request to a 5G core network. The device may send an indication of an implementation of a redundant transport session to a redundant transport client. The device may receive at least one copy of application data associated with an application from a redundant transport client, the at least one copy of the application data being received via one of a plurality of redundant protocol data unit (PDU) sessions. The device may send at least one copy of the application data to an application server associated with the application.

[0080] Figure 2The device may also include: wherein the redundant transport client and the application are associated with the user device.

[0081] Figure 2 The device may also include: wherein the AF impact includes one or more of the following: a UE application descriptor, an AF service identifier, an indication associated with the UE, an indication of an application server, or a redundant delivery indicator.

[0082] Figure 2 The apparatus may further include: wherein the at least one copy of the application data is segmented application data, and wherein the server apparatus is configured to send the segmented application data to an application server associated with the application.

[0083] Figure 2 The device may also include: wherein the multiple redundant PDU sessions include disjoint user plane paths.

[0084] Figure 2 The device may also receive multiple copies of application data, wherein each copy of the application data is received from one of the multiple redundant PDU sessions, and the device may also de-duplicate the multiple copies of the application data.

[0085] In addition to SEALDD clients initiating requests for redundant delivery, SEALDD servers can also initiate requests for redundant delivery on behalf of applications or UEs. For example, an application on a UE can provide a configuration for a game session to an application or VAL server, which can trigger a process for a SEALDD server to determine that the game session will benefit from redundant delivery. The application can provide this information during registration or after logging into the application or VAL server. Figure 3 A process is shown whereby a SEALDD server initiates redundant delivery for an application on a UE to support a gaming session.

[0086] In step 1, an application or VAL client may register or log in to an application or VAL server to configure a game session for a user of the UE. As part of this configuration, the application or VAL client may provide information about the game session to the corresponding application or VAL server, such as an application descriptor (e.g., operating system identifier and version, application identifier), QoS requirements, indications of reliable communication (if desired), any known time or space restrictions on application traffic, and indications for use of edge computing resources. The QoS requirements may be based on the desired resolution, frame rate, amount of background detail, scrolling effects, etc. configured by the user for the application. In addition, other information may also be provided: UE identifier and / or IP address, UE capabilities (e.g., support for dual connectivity or multiple access technologies), UE location, etc.

[0087] In step 2, the application or VAL server may process the request and make a determination that SEALDD service is needed for the application traffic based on information provided by the application or VAL client. The application or VAL server may make the determination based on one or more of specified QoS requirements, the presence of an indication of reliable communication, and / or performance measurements obtained from the application or VAL client or from the network. The application or VAL server may perform SEALDD server discovery to find a SEALDD server that supports the desired SEALDD service (e.g., redundant transport) and can serve the UE.

[0088] In step 3, the application or VAL server may issue a request to the SEALDD server to provide data delivery services for application traffic. The application or VAL server may include one or more of the following in the request: UE identifier and / or IP address and port number, application identifier, QoS requirements, UE location, UE capabilities, indications of reliable communication, any time or space restrictions on application traffic, and indications for using edge computing resources. The application or VAL server may include an explicit indicator requesting redundant transport. Alternatively, the application or VAL server may not be aware of the redundant transport function, but only provides application-level information used by the SEALDD server to manage redundant transport.

[0089] In step 4, the SEALDD server may use information provided by the application or VAL server to determine whether the session requires low latency or ultra-reliability. In addition, the SEALDD server may use an indication for using edge computing resources together with the UE location to discover a list of DNAIs that can be used to support application traffic. The SEALDD server, acting as an application function (AF), initiates an AF impact on the URSP process using the 5G core network. The SEALDD server may include in the request an AF identifier, service parameters describing the application traffic (e.g., such as DNN, S-NSSAI, UE application descriptor, AF service identifier), a target UE identifier or information about the UE, UE location, UE capabilities, redundant transport information, time and space validity conditions, application or VAL server contact information such as FQDN or IP address and port number, subscription information for receiving notifications, etc. The UE may receive an updated URSP rule in which the traffic descriptor and / or routing descriptor (RSD) include information provided by the SEALDD server. Examples include: an IP descriptor including an application or VAL server IP address and port number, a domain descriptor including an FQDN, and / or an RSD including redundant transport information such as a PDU Session Pair ID and RSN value. The PDU Session Pair ID and RSN value may have been provided to the SEALDD server by the 5G Core Network, the OAM system, or as part of pre-configuration. Alternatively, the SEALDD server may have been supplied with mapping information relating the DNN and / or S-NSSAI to the PDU Session Pair ID and RSN value.

[0090] Using the provided UE identifier and / or IP address and port number, the SEALDD server can configure the SEALDD client to enable redundant transport for the application on the UE. The message may include the application identifier, the application or VAL server FQDN or IP address and port number, any time or space restrictions on the application traffic. The message may also include information about one or more URSPs that have been updated or newly configured on the UE so that the SEALDD client is aware of them. The SEALDD client confirms the configuration from the SEALDD server and may include an update of the UE location and an indication of the data segmentation requirements and packet size for redundant transport.

[0091] In step 5, the SEALDD server may provide the application or VAL server with the status of the service request and may include the transaction and / or session identifier and a timestamp of the transaction.

[0092] In step 6, the application or VAL server may confirm the configuration request to the application or VAL client. The confirmation may indicate that the SEALDD service has been configured for the application and include a parameter list for the application or VAL client to use when requesting services from the SEALDD client. The parameter list may include information exchanged between the application or VAL server and the SEALDD server.

[0093] In step 7, the application or VAL client may issue a service request for the SEALDD service, possibly using the information provided by the application or VAL server.

[0094] In step 8, using the updated URSP rules, the UE can use dual connectivity or establish redundant PDU sessions using multiple access types, depending on the capabilities of the UE and based on other information that the SEALDD client may have. As a result, PDU sessions can be established using disjoint user plane paths.

[0095] In step 9, the SEALDD client may perform appropriate data processing (e.g., data segmentation and replication) on the data received from the application or VAL client, and send the replicated data through the redundant PDU session. The SEALDD server may receive data from the redundant PDU session and perform appropriate data reassembly to send the data to the application or VAL server. This step corresponds to Figure 2 Steps 7 to 9 of . Note that redundant delivery is also supported for downlink application traffic. For downlink traffic, the SEALDD server performs data replication, and the SEALDD client performs data elimination and reassembly.

[0096] In the previous example, the SEALDD service for reliable communication was started before the application traffic began. Figure 4 Another example of how a SEALDD client can be used to upgrade or shift application traffic to use redundant transports is shown. The original application traffic may have been established without the services of the SEALDD layer and using a single transport. For this case, the application or VAL client may make a determination to upgrade the application traffic to use reliable communications after experiencing service degradation such as increased buffering time, receiving an out-of-buffer error, or losing data.

[0097] In step 1, the UE may be sending application traffic without utilizing the SEALDD service and using a single transport setup.

[0098] In step 2, the application or VAL client may detect QoS degradation of the application traffic and decide to request upgrading the application traffic to use redundant transport or to migrate the application to use redundant transport.

[0099] In step 3, the application or VAL client may issue a request to the SEALDD client for a data delivery service to upgrade the application traffic to use redundant transport. The request may include one or more of the following: an application identifier or PDU session ID for the application, application or VAL server contact information such as an FQDN or IP address and port number, QoS requirements for the traffic, possible UE mobility information, an indication of reliable communication (if desired), any known time or space restrictions on the application traffic, and an indication for using edge computing resources. The UE mobility information may be an indication of UE mobility or more detailed location information obtained from a navigation application on the UE representing a planned route.

[0100] In step 4, the SEALDD client on the UE may process the request and make a determination to use redundant transport for application traffic based on information provided by the application or VAL client. The SEALDD client may make the determination based on one or more of specified QoS requirements, the presence of an indication of reliable communication, and / or performance measurements obtained from lower layers of the UE (e.g., low signal strength). The SEALDD client may perform SEALDD server discovery to find a SEALDD server that supports redundant transport and can serve the UE.

[0101] In step 5, the SEALDD client may send a request to the SEALDD server to configure redundant transport for applications on the UE, and may include one or more of the following: application descriptors for traffic (e.g., operating system identifier and version, application identifier), identifier and location of the UE, UE capabilities, QoS requirements, indication of reliable communication, time and / or space restrictions on application traffic, UE mobility information, UE performance measurements such as signal strength obtained from lower layers, application or VAL server contact information such as FQDN or IP address and port number, data segmentation requirements and packet size, etc. The SEALDD client may consider the performance measurements obtained from the lower layers when making a determination for redundant transport or for use of data segmentation. Alternatively, the SEALDD client may forward information about the UE without making a determination for redundant transport, and let the SEALDD server make a determination to use redundant transport based on the provided information.

[0102] In step 6, the SEALDD server may use information provided by the application or VAL server to determine whether the session requires low latency or ultra-reliability. In addition, the SEALDD server may use an indication for using edge computing resources together with the UE location to discover a list of DNAIs that can be used to support application traffic. The SEALDD server acting as an application function (AF) may initiate an AF impact on the URSP process using the 5G core network. The SEALDD server may include one or more of the following in the request: an AF identifier, service parameters describing application traffic (e.g., such as DNN, S-NSSAI, UE application descriptor, AF service identifier), a target UE identifier or information about the UE, UE location, UE capabilities, redundant transport information, time and space validity conditions, application or VAL server contact information such as FQDN or IP address and port number, subscription information for receiving notifications, etc. The UE may receive an updated URSP rule in which the traffic descriptor and / or routing descriptor (RSD) include information provided by the SEALDD server. Examples include one or more of the following: an IP descriptor including an application or VAL server IP address and port number, a domain descriptor including an FQDN, and / or an RSD including redundant transport information such as a PDU session pair ID and RSN value to enable redundant PDU sessions for the UE. The PDU session pair ID and RSN value may have been provided to the SEALDD server by the 5G core network, the OAM system, or as part of pre-configuration. Alternatively, the SEALDD server may have been supplied with mapping information relating the DNN and / or S-NSSAI to the PDU session pair ID and RSN value.

[0103] In step 7, the SEALDD server may issue a response to the SEALDD client to enable redundant transport for application traffic. The response may include information about time and space limits for redundant transport and the selected data segment packet size. The SEALDD client may issue a response to the application or VAL client with the status of the service request.

[0104] In step 8, the SEALDD client may trigger the UE to establish a redundant PDU session with the 5G core network. In this case, the SEALDD client may need to modify the existing PDU session established in step 2 to make it redundant, for example by providing a PDU session pair ID and RSN, or the SEALDD client may need to manually manage two PDU sessions without specifying that the PDU sessions are redundant.

[0105] In step 9, the SEALDD client may perform appropriate data processing (e.g., data segmentation and replication) on the data received from the application or VAL client, and send the replicated data through the redundant PDU session. The SEALDD server may receive data from the redundant PDU session and perform appropriate data reassembly to send the data to the application or VAL server. Step 9 corresponds to the above description of Figure 3 Described in step 9.

[0106] In the previous examples, the application or VAL client initiated an upgrade or shift of application traffic to use the SEALDD service with reliable delivery. Figure 5 Another example of how a SEALDD server may be used to upgrade or divert application traffic to use a redundant transport is shown. In a similar manner, the original application traffic may have been established without the services of the SEALDD layer and using a single transport. For this case, the application or VAL server may make a determination to upgrade or divert application traffic to use reliable communications based on a notification received from the 5G network predicting that network resource usage is increasing in a particular service area toward which the UE is moving. Alternatively, and also in Figure 5 As shown in FIG. 4 , the application or VAL client may also trigger a request for SEALDD service from the SEALDD server to upgrade the application traffic to redundant transport.

[0107] In step 1, the UE is sending application traffic without the service utilizing SEALDD and using a single transport setup.

[0108] In step 2, the application or VAL server may be subscribed to receive network performance measurements and network generated statistics and forecasts from the 5G core network or OAM system. The application or VAL server receives a notification from the 5G core network showing a network performance forecast for a particular service area where network resource usage is increasing. Additionally, the application or VAL server may also receive network analysis of UE mobility showing that the UE is moving towards a service area where network resource usage is increasing.

[0109] In step 3, the application or VAL client may detect QoS degradation of the application traffic in step 3a and request to upgrade the application traffic to use redundant transport or to divert the application traffic to use redundant transport. The request shown in step 3b may include the request as previously described in Figure 3 The information about the UE and the application traffic described in step 1 of . Note that in this figure, either step 2 or step 3 or even both steps 2 and 3 can trigger the action performed by the application or the VAL server in step 4.

[0110] In step 4, the application or VAL server may process the request and make a determination that SEALDD service is desired for the application traffic based on information provided by the application or VAL client. If the application or VAL server receives a notification from the 5G network or from the OAM system in step 2, the application or VAL server may already have information about the UE and the corresponding application traffic. The application or VAL server may also make a determination based on specified QoS requirements, the presence of an indication of reliable communication, and / or performance measurements obtained from the application or VAL client or from the network. The application or VAL server may perform SEALDD server discovery to find a SEALDD server that supports the desired SEALDD service (e.g., redundant transport) and can also serve the UE.

[0111] In step 5, in response to network performance and UE mobility prediction or application or VAL client request, the application or VAL server may issue a request for data delivery service to upgrade or transfer the UE from using a single transport to using redundant transport. The application or VAL server may issue a request to the SEALDD server that may serve the UE to configure the UE for redundant transport. The request may include one or more of the following: UE identifier and / or IP address, application identifier, QoS requirements, UE location, UE capabilities, indication of reliable communication, any time or space restrictions on application traffic, and indication for using edge computing resources.

[0112] In step 6, the SEALDD server may utilize the information provided by the application or VAL server to utilize the 5G core network to initiate an AF impact on the URSP process. The SEALDD server may include one or more of the following in the request: an AF identifier, service parameters describing the application traffic (e.g., such as DNN, S-NSSAI, UE application descriptor, AF service identifier), a target UE identifier or information about the UE, UE location, UE capabilities, redundant transport information, time and space validity conditions, application or VAL server contact information such as FQDN or IP address and port number, subscription information for receiving notifications, etc. The SEALDD server may use an indication of the use of edge computing resources together with the UE location to discover a list of DNAIs that can be used to support application traffic. The UE may receive an updated URSP rule in which the traffic descriptor and / or routing descriptor (RSD) includes information provided by the SEALDD server. A non-exhaustive list of examples includes: an IP descriptor including an application or VAL server IP address and port number, a domain descriptor including an FQDN, and / or an RSD including redundant transport information such as a PDU Session Pair ID and RSN value to enable redundant PDU sessions for the UE. The PDU Session Pair ID and RSN value may have been provided to the SEALDD server by the 5G Core Network, the OAM system, or as part of pre-configuration. Alternatively, the SEALDD server may have been supplied with mapping information relating the DNN and / or S-NSSAI to the PDU Session Pair ID and RSN value.

[0113] If step 4 is triggered by step 2, the SEALDD server can inform the SEALDD client to enable redundant transport for the application on the UE. The SEALDD server may have received information about the UE from the VAL server or network notification to be able to communicate with the SEALDD client. The notification may include one or more of the following: application identifier, application or VAL server FQDN or IP address and port number, any time or space restrictions on application traffic. The notification may include information about one or more URSPs that have been updated or newly configured on the UE so that the SEALDD client is aware of them. The SEALDD client can confirm the notification from the SEALDD server, and may include an update of the UE location and an indication of the data segmentation requirements and packet size for redundant transport. The SEALDD server confirms the result of the redundant transport request for the application to the application or VAL server.

[0114] In step 7, the SEALDD server may provide the application or VAL server with the status of the service request, and may include the transaction and / or session identifier and a timestamp of the transaction.

[0115] In step 8, if step 3b triggers the application or VAL server to request SEALDD services from the SEALDD server, the application or VAL server may confirm the configuration request to the application or VAL client. The confirmation may indicate that SEALDD services have been configured for the application and include a list of one or more parameters for the application or VAL client to use when requesting services from the SEALDD client.

[0116] In step 9, the application or VAL client may issue a service request to the SEALDD service, possibly using the information provided by the application or VAL server.

[0117] In step 10, the SEALDD client may trigger the UE to establish a redundant PDU session with the 5G core network. In this case, the SEALDD client may need to modify the existing PDU session established in step 2 to make it redundant, for example by providing a PDU session pair ID and RSN, or the SEALDD client may need to manually manage the two PDU sessions without specifying that the PDU sessions are redundant. The SEALDD client may also create two new PDU sessions for redundant transport and delete the old PDU session if it has been transmitted within the SEALDD layer.

[0118] In step 11, the SEALDD client may perform appropriate data processing (e.g., data segmentation and replication) on the data received from the application or VAL client, and send the replicated data through the redundant PDU session. The SEALDD server may receive data from the redundant PDU session and perform appropriate data reassembly to send the data to the application or VAL server. Step 11 corresponds to the above description of Figure 3 Described in step 9.

[0119] In the previous example, the application client or application server initiates support for redundant transport for the application on the UE. For the case where the application traffic is initially established to use only a single transport and utilize the SEALDD service, the SEALDD layer can support autonomously upgrading the application traffic for reliable communication based on the information about the UE that the SEALDD layer has and also information about network performance. The SEALDD client can access one or more of the performance measurements such as bit rate, round-trip time delay, number of retransmissions, signal-to-noise ratio, signal strength, etc. received from the lower layers of the UE. Using these performance measurements, the SEALDD client can detect when data transmission on a single transport can benefit from upgrading to redundant transport. Similarly, the SEALDD server can access network performance measurements and analysis available from the 5G network or OAM system to make the same determination to upgrade the current application traffic from a single transport to redundant transport.

[0120] Figure 6 An example is shown in which an application or VAL client initially issues a request to send application traffic to an application or VAL server using the SEALDD service. However, the request does not indicate a need for reliable communications, and as a result, the SEALDD layer establishes a single transport for the application traffic. At least one of the SEALDD client or the SEALDD server may detect that the data transmission has degraded to a point where there are a threshold number of retransmissions. For example, the UE may be mobile and may have moved to an area where signal strength is weak or there is a lot of congestion in the network. Upon detecting that the data transmission has degraded, the SEALDD client may make a determination to upgrade the single transport to dual transport for redundancy. The SEALDD server may also initiate an upgrade to a redundant transport if the SEALDD server has received network analysis of the UE's mobility and observes a service experience that indicates that the UE's service experience has degraded from the initial service experience, such as Figure 6 as shown in .

[0121] In step 1, an application client or a VAL client on a UE may issue a request to send data to an application or a VAL server.

[0122] In response, in step 2, the SEALDD client may communicate with lower layers to create a PDU session for the UE to support application traffic.

[0123] In step 3, based on the establishment of the PDU session, application data may be sent from the application or VAL client to the application or VAL server.

[0124] In step 4, the SEALDD client or SEALDD server may detect that data delivery has degraded and become unreliable, or receive a prediction from an analysis function within the 5G system that data delivery will degrade and become unreliable. The SEALDD client may have obtained performance measurements from lower layers on the UE, and the SEALDD server may have obtained performance measurements, QoS monitoring information, or network analysis from the 5G network or via an OAM system. The SEALDD client or server may decide to upgrade the PDU session to use redundant delivery for the UE.

[0125] In step 5, the upgrade using the redundant transport may be communicated within the SEALDD layer between the SEALDD client and the SEALDD server. If the SEALDD client initiates the upgrade to the redundant transport, the SEALDD client may perform Figure 2 Step 2 of , and if the SEALDD server initiates the upgrade to the redundant transport, the SEALDD server can execute Figure 3Step 4. In addition, the SEALDD server may perform an AF impact on the URSP procedure to update the UE with the URSP rules to enable redundant PDU sessions. Note that the AF impact on the URSP procedure may need to be performed before the SEALDD server configures the redundant transport to the SEALDD client. For this case, the SEALDD client and the SEALDD server may exchange information on how to upgrade from the existing transport to the redundant transport. The information may indicate the creation of two new PDU sessions for the redundant transport and the deletion of the existing PDU session. The information may also specify the creation of a new PDU session and the modification of an existing PDU session, or that the SEALDD layer will manually manage the new PDU sessions and the existing PDU sessions.

[0126] In step 6, the SEALDD client may trigger the UE to establish a redundant PDU session with the 5G core network. In this case, the SEALDD client may need to modify the existing PDU session established in step 2 to make it redundant, for example by providing a PDU session pair ID and RSN, or the SEALDD client may need to manually manage the two PDU sessions without specifying that the PDU sessions are redundant. The SEALDD client may also create two new PDU sessions for redundant delivery and delete the old PDU session if it has been transmitted within the SEALDD layer.

[0127] In step 7, the SEALDD client may perform appropriate data processing (e.g., data segmentation and replication) on the data received from the application or VAL client, and send the replicated data through the redundant PDU session. The SEALDD server may receive data from the redundant PDU session and perform appropriate data reassembly to send the data to the application or VAL server. Step 7 corresponds to the above description of Figure 3 Described in step 9.

[0128] Interface between the SEALDD layer and lower layers for redundant transport

[0129] Upon receiving a request for a SEALDD service, the SEALDD layer can interact with the 5G network to enable the service for application traffic. The SEALDD server can access the 5G core network by leveraging one or more of the monitoring, provisioning, and analysis reporting capabilities of the network open function (NEF). The SEALDD server can also access the OAM system to further obtain configuration or network information to provide better data delivery services. Similarly, the SEALDD client on the UE can communicate with the lower layers of the protocol stack to establish and manage PDU sessions for application traffic, and also obtain information about the UE to better manage data delivery services for applications on the UE.

[0130] When the SEALDD client receives an initial request for a service from an application client, the SEALDD client may communicate with the lower layers of the UE to establish a PDU session for the UE. In this communication, the SEALDD client may include information for application traffic, such as an application identifier, application server contact information (e.g., FQDN, IP address, and port number), and one or more of QoS requirements. If the SEALDD client has determined that redundant transport is required, the communication may also include a PDU session pair ID and / or RSN to indicate that the PDU session should have redundant features enabled. During the establishment of redundant transport within the SEALDD layer, the SEALDD client may have received a PDU session pair ID and / or RSN from the SEALDD server.

[0131] The SEALDD server may access information about network performance and / or UE configuration through an interface with the NEF of the 5G network or via an interface with an OAM system. Using this information, the SEALDD server may evaluate network performance statistics and / or predictions to assist in making a determination for upgrading application traffic to use redundant transport. As an example, the SEALDD server may have subscribed to receive statistics and predictions about network function load, network performance, observed service experience, UE mobility and communications, etc. from the NWDAF. In addition, the SEALDD server may have obtained UE capabilities and other UE information from the SEALDD client to assist in making a determination.

[0132] Once the SEALDD server has made a determination for redundant transport, it may communicate with the 5G network, for example via the NEF interface, to affect application traffic by updating the URSP rules to the UE. The SEALDD server may be able to derive the PDU session pair ID and / or RSN value from mapping information provided by the 5G network or OAM system based on the DNN and S-NSSAI information for the PDU session. The PDU session pair ID and / or RSN may be provided in the URSP rule update or provided to the SEALDD client for requesting the establishment of a PDU session to support redundant transport.

[0133] Graphical User Interface

[0134] Users of gaming applications on UEs may be presented with information such as Figure 7The GUI allows the user to configure settings for the game, such as resolution, refresh rate, background detail, and smooth scrolling. The game settings can be used by the application or VAL client / server to derive QoS requirements, which can be passed to the SEALDD client / server when requesting service. In addition, the GUI can provide other settings that may affect game performance and are used to trigger the SEAL data delivery service: settings for reliable communication and use of edge computing resources.

[0135] The 3rd 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 known as "5G". The development of 3GPP NR standards is expected to continue and include the definition of next-generation radio access technologies (new RATs), which are expected to include new flexible radio access below 7 GHz, and new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to consist of new non-backward 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 cope with a wide range of 3GPP NR use case sets with different requirements. Ultra-mobile broadband is expected to include centimeter wave (cmWave) and millimeter wave (mmWave) spectrum that will provide opportunities for ultra-mobile broadband access for indoor applications and hotspots, for example. In particular, ultra-mobile broadband is expected to share a common design framework with flexible radio access below 7 GHz, leveraging design optimizations specific to centimeter-wave and millimeter-wave.

[0136] 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 communications (URLLC), massive machine type communications (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy conservation), and enhanced vehicle-to-everything (eV2X) communications, which can include any of vehicle-to-vehicle communications (V2V), vehicle-to-infrastructure communications (V2I), vehicle-to-network communications (V2N), vehicle-to-pedestrian communications (V2P), and communications between vehicles and other entities. Specific services and applications within these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first responder connectivity, car recalls, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile Internet, virtual reality, home automation, robotics, and aerial drones, to name a few. All of these use cases and others are contemplated herein.

[0137] Fig. 8A An example communication system 100 in which the systems, methods, and apparatus described and claimed herein may be used is illustrated. The communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g, which may be collectively or jointly referred to as WTRUs 102 or multiple 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, a V2X server, a V2X function, a ProSe server, a ProSe function, IoT services, video streaming, and / or edge computing, etc.

[0138] It should 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. 8A In the example of FIG. 1 , each of the WTRUs 102 is FIG. 8A to FIG. 8E. It is to be understood that for a wide variety of use cases contemplated for wireless communication, each WTRU may include or be included in any type of device or apparatus configured to send 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 electronic product, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, an industrial device, a drone, a vehicle such as a car, bus or truck, a train or airplane, and the like.

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

[0140] 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, such as the core network 106 / 107 / 109, the Internet 110, network services 113, and / or 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, other networks 112, and / or network services 113. By way of example, the base stations 114a, 114b may be base transceiver stations (BTSs), Node Bs, eNode Bs (eNodeBs), Home Node Bs, Home eNode Bs (eNodeBs), next generation Node Bs (gNodeBs), satellites, site controllers, access points (APs), wireless routers, and the like.

[0141] 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, an RNC, a relay node, etc. The base station 114a may be configured to send 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 send 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 also be 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, for example, one transceiver for each sector of the cell. For example, the base station 114a may employ multiple-input multiple-output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0142] 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, centimeter wave, millimeter wave, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0143] 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, centimeter wave, millimeter wave, etc.). The air interface 115b / 116b / 117b may be established using any suitable RAT.

[0144] The RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 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, ultraviolet UV, visible light, centimeter wave, millimeter wave, etc.). The air interface 115c / 116c / 117c may be established using any suitable RAT.

[0145] 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, centimeter wave, millimeter wave, etc.). The air interface 115d / 116d / 117d may be established using any suitable RAT.

[0146] 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 in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d, 102e, and 102f may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interfaces 115 / 116 / 117 and / or 115c / 116c / 117c, respectively. 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).

[0147] The base station 114a and the WTRUs 102a, 102b, 102c, and 102g in the RAN 103 / 104 / 105 or the RRHs 118a and 118b, the TRPs 119a and 119b, and / or the 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, respectively, using, for example, Long Term Evolution (LTE) and / or Advanced LTE (LTE-A). 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.).

[0148] The base station 114a and the WTRUs 102a, 102b, 102c, and 102g in the RAN 103 / 104 / 105 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.

[0149] Fig. 8A The base station 114c in the example may be, for example, a wireless router, a Home Node B, a Home eNode B (eNode B), or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a train, an airplane, a satellite, a manufacturing plant, a campus, and the like. The base station 114c and the WTRU 102 (e.g., WTRU 102e) may implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). Similarly, the base station 114c and the WTRU 102 (e.g., WTRU 102d) may 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) may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a picocell or a femtocell. Fig. 8A As shown in FIG, the base station 114c may have a direct connection to the Internet 110. Therefore, the base station 114c may not need to access the Internet 110 via the core network 106 / 107 / 109.

[0150] 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.

[0151] Despite Fig. 8A Although not shown, it will be appreciated that the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 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.

[0152] 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 IP in the TCP / Internet Protocol (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 that may employ the same RAT or a different RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b.

[0153] Some or all of the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f in the communication system 100 may include multi-mode capabilities. For example, the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f may include multiple transceivers for communicating with different wireless networks via different wireless links. Fig. 8A 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.

[0154] Despite Fig. 8A Not shown, but it will be understood that the user equipment may have a wired connection to the gateway. The gateway may be a residential gateway (RG). The RG may provide a connection to the core network 106 / 107 / 109. It should be understood that many of the concepts contained herein may be equally applicable to a UE that is a WTRU and a UE that uses a wired connection for connecting to a network. For example, the concepts applied to the wireless interfaces 115, 116, 117, and 115c / 116c / 117c may be equally applicable to a wired connection.

[0155] Figure 8B 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. Figure 8B As shown in FIG. 1 , the RAN 103 may include Node-Bs 140a, 140b, and 140c, which may each 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).

[0156] like Figure 8BAs 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 connected to it. 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 functions, data encryption, etc.

[0157] Figure 8B 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 understood that any of these elements may be owned and / or operated by an entity other than a core network operator.

[0158] 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.

[0159] 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.

[0160] 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.

[0161] Figure 8C1 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.

[0162] 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, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0163] 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, user scheduling in uplink and / or downlink, etc. Figure 8C As shown in FIG. 1 , eNode-Bs 160a , 160b , and 160c may communicate with each other via an X2 interface.

[0164] Figure 8C 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 understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0165] 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, etc. 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.

[0166] 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 and forward user data packets to / from the WTRUs 102a, 102b, and 102c. The serving gateway 164 may also perform other functions, such as anchoring the user plane during inter-eNode-B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, and 102c, managing and storing the contexts of the WTRUs 102a, 102b, and 102c, and the like.

[0167] 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, and 102c and IP-enabled devices.

[0168] 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, such as 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 be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves 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.

[0169] Fig.8D 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.

[0170] 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 WTRU and the gNode-Bs, which may be via one or more gNBs as the core network 109. The gNode-Bs 180a and 180b may implement MIMO, MU-MIMO, and / or digital beamforming techniques. Thus, the gNode-B 180a, for example, may use multiple antennas to send wireless signals to and receive wireless signals from the WTRU 102a. It should be appreciated that the RAN 105 may employ other types of base stations such as eNode-B. It will also be appreciated that the RAN 105 may employ more than one type of base station. For example, the RAN may employ both eNode-B and gNode-B.

[0171] 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.

[0172] 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, user scheduling in uplink and / or downlink, etc. Fig.8D As shown in FIG. 1 , gNode-Bs 180a and 180b may communicate with each other via, for example, an Xn interface.

[0173] Fig.8DThe core network 109 shown in the figure can be a 5G core network (5GC). The core network 109 can provide numerous communication services to customers interconnected by a radio access network. The core network 109 includes multiple entities that perform core network functions. 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 logical entity implemented in the form of computer executable instructions (software) stored in a device or such as a computer configured for wireless and / or network communications. Figure 8G The system 90 is stored in the memory of a computer system such as the system 90 illustrated in FIG. 1 and is executed on a processor thereof.

[0174] exist Fig.8D 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 open 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 understood that any of these elements may be owned and / or operated by an entity other than the core network operator. It will also be understood that the 5G core network may not consist of all of these elements, may consist of additional elements, and may consist of multiple instances of each of these elements. Fig.8D The network functions are shown connected directly to each other, however, it should be understood that they may communicate via a routing agent such as a diameter routing agent or a message bus.

[0175] exist Fig.8D In the example of , the connection between network functions is realized via a set of interfaces or reference points. It will be understood that the network function can be modeled, described or realized as a set of services that are called out (invoke) or called by other network functions or services. The calling out of network function services can be realized via direct connection between network functions, message exchange on a message bus, calling software functions, etc.

[0176] 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. Fig.8D The N1 interface is not shown.

[0177] The SMF 174 may be connected to the AMF 172 via the N11 interface. Similarly, the SMF may be connected to the PCF 184 via the N7 interface and to the UPFs 176a and 176b via the 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 UPF 176a and UPF 176b, and generation of downlink data notifications to the AMF 172.

[0178] 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 an N4 interface. The UPF 176a and UPF 176b may provide access to a packet data network by connecting to the packet data network using an N6 interface or by connecting to each other and to other UPFs via an 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 processing for user plane traffic, and downlink packet buffering.

[0179] 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 radio interface technology not defined by 3GPP. The AMF may interact with the N3IWF 199 in the same or similar manner as it interacts with the RAN 105.

[0180] 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. Fig.8D The N15 and N5 interfaces are not shown in FIG. 1. The PCF 184 may provide policy rules to control plane nodes such as the AMF 172 and SMF 174, thereby allowing the control plane nodes to enforce these rules. The PCF 184 may send policies to the AMF 172 for the WTRUs 102a, 102b, and 102c so that the AMF may deliver the policies to the WTRUs 102a, 102b, and 102c via the N1 interface. The policies may be enforced or applied at the WTRUs 102a, 102b, and 102c.

[0181] The UDR 178 may act as a repository for authentication credentials and subscription information. The UDR may be connected to a network function so that the network function may add to, read 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.

[0182] 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.

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

[0184] NEF 196 exposes the capabilities and services in 5G core network 109 to application function (AF) 188. The exposure can be done 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 open the capabilities and services of 5G core network 109.

[0185] The application function 188 may interact with the network functions in the 5G core network 109. The interaction between the application function 188 and the network functions may be via a direct interface or may be 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.

[0186] Network slicing is a mechanism that can be used by mobile network operators 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 that are customized to provide optimized solutions for different market scenarios that require different requirements in terms of functionality, performance and isolation, for example.

[0187] 3GPP has designed the 5G core network to support network slicing. Network slicing is a useful tool that network operators can use to support a diverse set of 5G use cases (e.g., massive IoT, critical communications, V2X, and enhanced mobile broadband) that require diverse and sometimes extreme requirements. Without the use of network slicing technology, the network architecture is likely to not have sufficient flexibility and scalability to effectively support the larger range of use cases required when each use case has its own specific set of performance, scalability, and availability requirements. In addition, the introduction of new network services should be more efficiently conducted.

[0188] Reference again Fig.8D 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 be logically 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, 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.

[0189] 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.

[0190] Described herein and Fig. 8A , Figure 8C , Fig.8D and Fig. 8E The core network entities illustrated in the figure are identified by the names given to those entities in certain existing 3GPP specifications, but it should be understood that in the future, those entities and functions may be identified by other names, and that certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP NR specifications. FIG. 8A to FIG. 8E The specific network entities and functionality described and illustrated in the present disclosure 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.

[0191] Fig. 8E An example communication system 111 in which the systems, methods, and devices described herein may be used is illustrated. 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 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 of the WTRUs A, B, C, D, E, and F may be outside the range of the access network coverage 131. WTRUs A, B, and C form a V2X group in which WTRU A is the group leader and WTRUs B and C are group members.

[0192] 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. 8EIn the example of FIG. 1 , WTRUs B and F are shown as being within access network coverage 131. WTRUs A, B, C, D, E, and F may communicate directly with each other via sidechain interfaces (e.g., PC5 or NRPC5) such as interfaces 125a, 125b, or 128, regardless of whether they are within or outside of access network coverage 131. For example, in Fig. 8E In the example of , WTRU D outside the access network coverage 131 communicates with WTRU F within the coverage 131.

[0193] 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.

[0194] Fig.8F is an example device or apparatus WTRU 102 (such as FIG. 8A to FIG. 8E 102). Fig.8F As shown in , the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 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 will be appreciated that the WTRU 102 may include any sub-combination of the above elements. In addition, 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 (among others)) may include Fig.8F Some or all of the elements depicted in and described herein.

[0195] 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.8F The processor 118 and the transceiver 120 are depicted as separate components, but it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0196] The transmit / receive element 122 of the UE may be configured to transmit data to a base station (eg, Fig. 8A The base station 114a) of the wireless communication equipment 114a) sends a signal to or receives a signal from it, or sends a signal to or receives a signal from another UE through the air interface 115d / 116d / 117d. For example, the send / receive element 122 can be an antenna configured to send and / or receive RF signals. The send / receive element 122 can be a transmitter / detector configured to, for example, send and / or receive IR, UV or visible light signals. The send / receive element 122 can be configured to send and receive both RF and optical signals. It will be understood that the send / receive element 122 can be configured to send and / or receive any combination of wireless or wired signals.

[0197] In addition, although the transmit / receive element 122 is Fig.8F 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 sending and receiving wireless signals over the air interface 115 / 116 / 117.

[0198] 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.

[0199] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keyboard 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 keyboard 126, and / or the display / touchpad / indicator 128. In addition, the processor 118 may access information from any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132, and store data therein. 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 in memory hosted in a cloud or edge computing platform or in a home computer (not shown).

[0200] The processor 118 may receive power from the power source 134 and may be configured to distribute the power to and / or control the power to 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.

[0201] 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.

[0202] 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 an accelerometer, a biometric (e.g., fingerprint) sensor, an electronic compass (e-compass), a satellite transceiver, a digital camera (for photos or videos), a universal serial bus (USB) port or other interconnect interface, a vibration device, a television transceiver, a hands-free headset, a Bluetooth modules, FM radio units, digital music players, media players, video game player modules, internet browsers, etc.

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

[0204] Figure 8G is a block diagram of an exemplary computing system 90 in which the Fig. 8A , Figure 8C , Fig.8D and Fig. 8E103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, 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 such software is stored or accessed, or in any manner. 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.

[0205] In operation, processor 91 fetches, decodes and executes instructions, and transfers information to and from other resources via the computing system's primary 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.

[0206] 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 circuits that allow information to be stored and retrieved. ROM 93 generally contains stored data that cannot be easily modified. The data stored in RAM 82 can be read or changed by the processor 91 or other hardware devices. 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 converts a virtual address into a physical address when executing an instruction. 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; it cannot access memory in the virtual address space of another process unless memory sharing between processes has been established.

[0207] In addition, the computing system 90 may include a peripheral device controller 83 , which 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 .

[0208] 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 using a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch panel. The display controller 96 includes the electronic components required to generate the video signal sent to the display 86.

[0209] Additionally, computing system 90 may include communications circuitry such as, for example, a wireless or wired network adapter 97 that may be used to connect computing system 90 to an external communications network or device, such as FIG. 8A to FIG. 8E The RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110, the WTRU 102 or other networks 112 to enable the computing system 90 to communicate with other nodes or functional entities of those networks. The communication circuitry may be used alone or in combination with the processor 91 to perform the sending and receiving steps of certain devices, nodes or functional entities described herein.

[0210] 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 communications. 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 storage technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage device, cassette, tape, disk storage device or other magnetic storage device, or any other tangible or physical medium that can be used to store the desired information and can be accessed by a computing system.

Claims

1. A method, include: sending, by a redundant delivery client and to a redundant delivery server, a request for the redundant delivery server to configure redundant delivery for an application associated with a user device; receiving, from the redundant transport server, an indication of a redundant transport session associated with the application; establishing, by the redundant transport client and for the user device, a plurality of redundant protocol data unit (PDU) sessions associated with the user device; replicating application data received from an application associated with the user device over at least two of a plurality of redundant PDU sessions; as well as The replicated application data is sent to the redundant transport server via the at least two of the plurality of redundant PDU sessions. 2 . The method of claim 1 , further comprising receiving a request from an application associated with the user device to send the application data to an application server associated with the application via redundant transport.

3. The method according to claim 2, in, The redundant transport server is a suitable redundant transport server among a plurality of redundant transport servers, and the redundant transport client is configured to discover the suitable redundant transport server in response to receiving a request to send the application data via a redundant transport.

4. The method according to claim 2, in, The request includes at least one of an application identifier, an indication of the application server, a quality of service indication associated with the application data, mobility information associated with the user device, a request for reliable communications, or restrictions associated with the application data.

5. The method according to claim 1, further comprising: include: In response to sending the request for the redundant transport, an updated User Equipment (UE) Routing Policy (URSP) rule associated with the redundant transport is received.

6. The method according to claim 1, in, The redundant transport client is further configured to segment the application data based on at least one of a transmission quality, a size associated with the application data, or a maximum packet size of the application data associated with at least one of the redundant PDU sessions.

7. The method according to claim 1, in, The redundant PDU sessions include disjoint user plane paths.

8. The method according to claim 1, in, The redundant transport server is configured to send one of the replicated application data instances to an application server associated with the application.

9. The method according to claim 7, in, The redundant transport server is configured to de-duplicate the multiple instances of the application data based on receiving the multiple instances of the application data from the redundant PDU session.

10. A server device, include: one or more processors; as well as a memory storing instructions that, when executed by the one or more processors, cause the server device to: receiving a request from a redundant transport client to configure a redundant transport associated with an application; The application function AF affects sending a request for a user equipment UE routing policy URSP to the 5G core network; sending an indication of a method for implementing a redundant transport session to the redundant transport client; receiving at least one copy of application data associated with the application from the redundant transport client, the at least one copy of the application data being received via one of a plurality of redundant protocol data unit (PDU) sessions; as well as At least one copy of the application data is sent to an application server associated with the application.

11. The server device according to claim 10, in, The redundant transport client and the application are associated with a user device.

12. The server device according to claim 10, in, The AF impact includes one or more of: a UE application descriptor, an AF service identifier, an indication associated with the UE, an indication of the application server, or a redundant delivery indicator.

13. The server device according to claim 10, in, The at least one copy of the application data is segmented application data, and wherein the server device is configured to send the segmented application data to the application server associated with the application.

14. The server device according to claim 10, in, The plurality of redundant PDU sessions include disjoint user plane paths.

15. The server device according to claim 10, in, The instructions, when executed, further cause the server device to: receiving a plurality of copies of the application data, wherein each copy of the application data is received from one of the plurality of redundant PDU sessions; and The multiple copies of the application data are deduplicated.

Images