System and method for protocol data unit set identification

Abstract

A Protocol Data Unit (PDU) set identification system and method for end-to-end encrypted services (e.g., QUIC services between a User Equipment (UE) and an Application Server (AS)). The mechanism may include one or more of the following: (i) utilizing an additional path identifier corresponding to a Connection ID (CID), for example, for even and odd sets; (ii) sharing key information to obtain a set sequence number; (iii) merging the PDU set identification information in the encapsulation with the encrypted packet data of the PDU on an encrypted channel; and / or (iv) removing the encapsulation information of the PDU set in subsequent transmissions after the initial transmission to reduce signaling overhead.

Description

Technical Field

[0001] Embodiments related to encrypted communication are disclosed. Specifically, a mechanism is disclosed for identifying protocol data units (PDUs) of encrypted information (e.g., QUIC-based end-to-end (e2e) encrypted extended reality and media (XRM) transmitted over a 5G network) using the QUIC-based multiplexing application support layer (MASQUE) protocol. Background Technology

[0002] 5G is the fifth generation of mobile communication, applicable to a wide range of use cases. Figure 1 The 5G reference architecture defined by the 3rd Generation Partnership Project (3GPP) is shown, providing, for example, a policy and charging control framework. Figure 1 System 100 includes Application Function (AF), Network Open Function (NEF), Policy Control Function (PCF), Session Management Function (SMF), and User Plane Function (UPF). AF can interact with the 3GPP core network and, in some respects, allows external parties to use open APIs provided by the network operator. NEF can support different functions, particularly different open APIs in certain situations. PCF supports a unified policy framework to manage network behavior. Specifically, PCF provides PCC (Policy and Charging Control) rules to PCEF (Policy and Charging Enforcement Function), i.e., the SMF / UPF executes policy and charging decisions based on pre-configured PCC rules. In this example, SMF supports different functions; for example, SMF receives PCC rules from PCF and configures UPF accordingly. UPF supports user plane service processing, including packet detection, packet routing and forwarding, service usage reporting, QoS processing, etc.

[0003] QUIC is a stream multiplexing and secure transport protocol based on User Datagram Protocol (UDP), featuring an integrity-protected header and an encrypted payload. Most QUIC headers use a separate header protection mechanism and are further encrypted using a separately derived encryption key. Unlike traditional transport protocol stacks that typically reside in the operating system kernel and employ Transmission Control Protocol (TCP), QUIC can be implemented in user space, such as at the application layer. This increases the transport protocol's evolutionary flexibility in implementing new features, congestion control, deployment capabilities, and adoptability. QUIC is standardized by the Internet Engineering Task Force (IETF) and has the potential to become the dominant transport protocol for the internet user plane. Driven by improved latency and enhanced security, most applications currently running over HTTP / HTTPS are expected to migrate to QUIC. Notably, unlike HTTPS, encryption in QUIC covers both the transport protocol header and payload, unlike TCP-based Transport Layer Security (TLS). As an example, HTTPS only protects the payload. Furthermore, the IETF is specifying an extension to the QUIC protocol that enables the simultaneous use of multiple parallel network paths (UDP quadruples) within a single QUIC connection. A multi-path QUIC connection can use multiple Connection IDs (CIDs), with each path using one or more CIDs, and each path having its own 5-tuple address and port value. In some respects, the scheduling of data transmission along the path does not need to be defined in a canonical manner, but can be adapted to application requirements and path attributes to meet transmission objectives.

[0004] A proxy can act as an intermediary entity, such as a node or device. For example, one type of proxy can be an intermediary that acts as both a server and a client, creating requests on behalf of other entities or simply forwarding them. In this case, the request is either serviced internally or by passing the request (possibly transformed) to another server. There are several types of proxies. A "transparent proxy" can refer to a proxy that does not modify the request or response except as required for proxy authentication and identification. A "non-transparent proxy" can refer to a proxy that modifies the request or response to provide some additional service to the user agent (such as group annotation service, media type conversion, protocol simplification, or anonymization filtering). A "reverse proxy" can refer to a proxy that essentially pretends to be the actual server (to any client or client agent) but passes the request to the actual server, which is usually behind another layer of firewall. A "performance-enhancing proxy" (PEP) can refer to a proxy used to improve the performance of protocols along a network path, for example, when the characteristics of links or subnets along the path cause native performance degradation.

[0005] Currently, the IETF has a working group on QUIC-based multiplexing application support layers, or "MASQUE," which aims to develop mechanisms that allow multiple proxies to be configured and run simultaneously within HTTPS connections, both stream-based and datagram-based. These mechanisms are collectively referred to as MASQUE. The working group has specified HTTP and / or HTTP / 3 extensions that enable this functionality. It is anticipated that through MASQUE: (i) applications can create secure connections to network proxies along the path; (ii) secure end-to-end connections can be established to one or more servers via the proxies; (iii) application data will be protected by end-to-end security to prevent unauthorized use within the network; and (iv) content providers and / or mobile network operators will have secure channels to exchange information about applications and policies in real time.

[0006] Systems and devices that can support PDU set information identification for end-to-end encrypted communication, including end-to-end encrypted communication using QUIC, are still needed. Summary of the Invention

[0007] According to some embodiments, systems and methods are provided for implementing MASQUE-based PDU set identification for end-to-end encrypted services (e.g., QUIC services between a user equipment (UE) and an application server (AS)). In some embodiments, the mechanism may be optimized by one or more of the following: (i) PDU set identification based on an additional path with a corresponding CID (e.g., for even and odd sets respectively); (ii) sharing key information to obtain set sequence numbers; (iii) merging the PDU set identification information (e.g., in a capsule) with the encrypted packet data of the PDUs on an encrypted channel; and / or (iv) removing the PDU set capsule information in subsequent transmissions after the initial transmission to reduce signaling overhead and processing.

[0008] According to some embodiments, a method is provided, comprising: establishing a secure tunnel for sending PDU set information; and sending encrypted first PDU set information via said secure tunnel. An apparatus may be configured to perform the method.

[0009] According to some embodiments, a method is provided, comprising: identifying a packet received from a UE, wherein the packet is part of a request to establish a QUIC connection with a target AS; sending a request to tunnel the connection of the UE to the target AS, wherein the request indicates the transmission of encrypted PDU set information over a secure tunnel; and receiving the PDU set information from the target AS through the secure tunnel, wherein the PDU set information corresponds to encrypted PDUs received from the AS. An apparatus may be configured to perform the method.

[0010] According to some embodiments, a method is provided that includes the following steps: establishing or configuring a secure tunnel connection; and sending or receiving first PDU set information merged with one or more initial PDUs via the secure tunnel connection. Subsequent PDUs may or may not include the PDU set information. An apparatus may be configured to perform these methods.

[0011] According to an embodiment, a system is provided that can perform any step of these methods, and the system may include one or more of the means described above.

[0012] According to some embodiments, a computer program product may include a non-transitory computer-readable medium storing instructions that, when executed by the processing circuitry of a device, cause the device to perform any of the methods described herein. Attached Figure Description

[0013] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.

[0014] Figure 1 The 5G system architecture is shown.

[0015] Figure 2 A system using an agent is shown.

[0016] Figure 3A and Figure 3B This is a signaling flowchart illustrating a process according to an embodiment.

[0017] Figure 4 , Figure 5 , Figure 6A and Figure 6B This is a flowchart illustrating a process according to an embodiment.

[0018] Figures 7 to 12 Networks, systems, and devices according to one or more embodiments are illustrated. Detailed Implementation

[0019] There are certain challenges at present.

[0020] For example, 3GPP TR 23.700-70 includes "Study on architecture enhancement for Extended Reality and Media service (XRM); Phase 2," which identifies certain challenges in supporting advanced media services, such as High Data Rate Low Latency (HDRLL) services and Augmented Reality (AR) / Virtual Reality (VR) / Extended Reality (XR) services. Specifically, key issue #2 points to the need for "support for PDU set information identification for end-to-end encrypted XRM services." This could include, for example, the use of end-to-end encryption, which is widely deployed in current networks to provide security, and is expected to be the case for XRM applications as well. According to some embodiments, the mechanisms described herein address whether and how 5GS performs PDU set information identification in end-to-end encrypted scenarios, including those for AR / VR / XR / XRM applications.

[0021] Existing solutions for PDU set identification in 3GPP are based on the following: (a) for XRM applications, providing a Real-Time Transport Protocol (RTP) or Secure RTP (SRTP) extension header with PDU set identification information; and (b) PSA-UPF identifying PDU sets based on analysis of the RTP payload with the aid of the protocol description provided by AF. Under this framework, the identification of PDU sets for end-to-end encrypted media services can currently be achieved by combining the SRTP protocol and the RTP extension header. However, the PDU set identification information is sent in plaintext and is therefore unprotected. Thus, man-in-the-middle attacks could be launched by modifying the SRTP extension header and / or impersonating content providers, which would affect the normal operation of Next Generation Radio Access Networks (NG-RAN). Furthermore, the currently defined solutions only work with RTP transport protocols and do not support evolved transports such as QUIC-based media, thus limiting their evolution, applicability, and adoptability.

[0022] Certain aspects of this disclosure and its embodiments may provide solutions to these or other challenges based on one or more of the following:

[0023] In some embodiments, end-to-end encryption is implemented using the QUIC protocol. MASQUE is used to establish an in-band signaling channel between the UPF and the content provider's application server (AS), where the MASQUE agent is co-located with the AS. "AS" can also refer to the corresponding AF, which is a network function in 5G used to provide application-related information to other network functions.

[0024] In this embodiment, the AS communicates with the 5G network via AF, requesting the establishment of an AF session with Quality of Service (QoS). Subsequently, the AS receives and transmits user plane payload packets via the Internet (N6 interface) + MASQUE in-band signaling. In some aspects, for each downlink packet, the AS uses an encapsulation to provide the UPF with PDU set information for each packet, such as PDU set sequence number, size, importance, PDU sequence numbers within the PDU set, and PDU set end indication. To avoid encapsulation and encryption of payload packets between the AS and the UPF, the encapsulation and QUIC payload packets are merged and transmitted in the same UDP packet, and an HTTP-based QUIC-aware proxy process is used to forward the QUIC payload packets.

[0025] In some respects, the solution can be optimized to minimize UDP packet overhead by sending the encapsulation only along with the initial payload packet and the last packet. Alternatively, PDU set identification can be implemented using multipath QUIC and alternating connection IDs for odd and even PDU sets. In this case, the PDU set sequence number is counted by the UPF. For example, it can be made more robust (e.g., resistant to burst packet loss) by adding more connection IDs. Additionally, PDU set-level information (e.g., size and importance) can be sent only with the initial packet of each PDU set, as their values ​​are identical for all PDUs in the set. In an embodiment, this information is repeated for multiple PDUs to compensate for possible packet loss. As another example, the PDU set end indication can be sent only in the encapsulation along with the last PDU in the set. Furthermore, the PDU set sequence number for each PDU can be obtained without sending the encapsulation using the header in the QUIC packet of the end-to-end connection. For this purpose, in an embodiment, the AS sends the header protection key to the UPF immediately after the end-to-end QUIC connection is established in the MASQUE encapsulation. In this embodiment, the SN is sent along with the initial packet and the PDU set size and importance to map the end-to-end QUIC packet sequence number to the PDU sequence number in the PDU set.

[0026] In some embodiments, a mechanism is provided for exchanging PDU set metadata between the AS and the UPF via the MASQUE encapsulation protocol, incorporating the following optimizations: (i) packet processing optimization by merging the MASQUE encapsulation and the QUIC payload PDU in the same UDP packet; and / or (ii) UDP packet overhead optimization using multipath QUIC, wherein the encapsulation with metadata is initially sent, and the QUIC header protection key is shared for PDU sequence number derivation.

[0027] In addition, certain embodiments may provide one or more of the following technical advantages:

[0028] • End-to-end XRM services can be QUIC-based RTP, QUIC-based media, or any other XRM application protocol carried over QUIC.

[0029] • This solution is transparent to the application client at the UE level;

[0030] • By avoiding encapsulation and double encryption, packet processing at UPF and AS is optimized;

[0031] • Minimize UDP packet overhead between UPF and AS; and / or

[0032] • The solution still works even with packet loss and out-of-order delivery.

[0033] According to some embodiments, the improvements and advantages described herein can be achieved by updating one or more standards. For example, 3GPP TS 29.501 can be updated to add Connect-UDP processing for PDU set identification and tagging to the PDU set processing procedure. As another example, 3GPP TS 29.503 can be updated to add an indication to the PCC rule for using Connect-UDP for PDU set detection in conjunction with FQDN for AS. As another example, for 3GPP TS 29.522, the extension of the NnefAFSessionwithQoS API can be updated using an indication for using Connect-UDP for PDU set detection in conjunction with FQDN for AS. As another example, 3GPP TS 29.244 can be updated to add an indication to the N4 rule for using Connect-UDP for PDU set detection in conjunction with FQDN for AS.

[0034] Figure 2 This illustrates aspects of client / server interaction with the proxy. Figure 2In this configuration, communication between client 202 and server 204 utilizes proxy 206. This may include connections 210a, 210b, 212a, and 212b. In some embodiments, the application client explicitly opens a QUIC tunnel connection to the proxy and requests forwarding, using protocols such as HTTP CONNECT and custom protocols to request or negotiate forwarding, authentication, and configuration. In some aspects, QUIC proxy 206 provides secure forwarding and performance enhancement services, such as congestion control support (mobile / satellite), access policy enforcement, load balancing / mobility, multi-hop chained routing / onion routing, etc. The QUIC proxy may also optionally open a tunnel to server 204 (if the server supports it). By using these mechanisms, client 202 and / or server 204 (typically the client) explicitly contact proxy 206 (e.g., the QUIC proxy) to expose information between the content provider (application client and / or server) and the mobile network operator (e.g., the QUIC proxy at the UPF). See reference. Figure 2 Internal connections 212a and 212b are used to carry (encrypted) application services (invisible to the proxy) between the client and the server, while external connections 210a and 210b can be used to expose information between the content provider (application client and / or server) and the mobile network operator (e.g., a QUIC proxy at the UPF). In some embodiments, the server (e.g., an application server (AS)) may have an integrated proxy, such as a MASQUE proxy, for handling certain communications. For example, a UE or other client may connect to the UPF via an access network; and the UPF (e.g., as a MASQUE client) may connect to the AS via the Internet. In some embodiments, the AS itself may include a MASQUE proxy tightly integrated with the XRM sender portion of the AS.

[0035] Some embodiments of the concepts described herein will now be described more fully with reference to the accompanying drawings. These embodiments are provided by way of example in order to convey the scope of the subject matter to those skilled in the art.

[0036] Now refer to Figure 3A and Figure 3B According to some embodiments, process 300 is provided. Process 300 can be implemented using one or more of, for example, UE, NG-RAN, PSA-UPF, SMF, PCF / NEF, and / or AF / AS. In embodiments, these can be combined. Figure 1 , Figure 2 ,and Figures 7 to 12 One or more of the described functions, nodes, devices, or other entities. And in some embodiments, Figure 3B The various aspects of process 300 shown in the diagram can be followed in combination. Figure 3AFollowing the described aspects, according to some embodiments, one or more steps may be omitted, and the order of the steps may be adjusted.

[0037] The process can begin, for example, with step 301, PDU session establishment. In an embodiment, a PDU session establishment procedure as defined in clause 4.3.2.2.1 of TS 23.502 is performed. This may include one or more steps performed by the UE, NG-RAN, PSA-UPF, and SMF. In step 302, the AF sends a session establishment request to the PCF / NEF, such as the Nnef_AFsessionWithQoS_Create request as defined in clause 4.15.6.6 of TS 23.502. This can provide QoS requirements based on the PDU set and auxiliary information for service detection. In an embodiment, it also provides an indication for PDU set identification using Connect-UDP and an AS address for the Connect-UDP request. In an embodiment, the PCF generates PCC rules based on information provided by the AF and / or local policies, such as as defined in clause 6.1.3.27.4 of TS 23.503. This may include a request to identify and tag PDU set information in end-to-end encrypted media services. In step 303, the PCF forwards the PCC rules for end-to-end encrypted XRM services during SM policy association establishment / modification. While XRM services are used in this example, other types of services (e.g., other media services or other AR / VR / XR services) may also be applicable according to the embodiment. In step 304a, the SMF configures the UPF. For example, the SMF binds the PCC rules to a new QoS flow, determines the applicable QoS profile, and determines the N4 rules, which include QoS enforcement rules with PDU set tag indications, packet detection rules including packet detection information, and indications for PDU set detection using Connect-UDP in conjunction with the FQDN for the AS. According to the embodiment, the SMF sends the N4 rules to the PSA-UPF, which include QER, FAR, and PDR with packet detection information, as well as Connect-UDP information. In some aspects, as part of step 304a, the UPF is configured with a PDR with application detection information, a MASQUE protocol description, and an indication for establishing a MASQUE tunnel and a FAR for the FQDN for the AS. In step 304b, the SMF provides a QoS profile to the NG-RAN (e.g., via the AMF), and in step 304c, the SMF pre-configures QoS rules for the UE, for example, in a NAS message sent to the UE via the AMF and NG-RAN.

[0038] In step 305, the UE initiates encrypted communication, such as an end-to-end QUIC connection to the AS, to achieve e2e encryption for XRM services (or other services).

[0039] In step 306, the UPF performs target selection and / or matching, for example, based on rules. In an embodiment, the UPF uses packet detection information to match the PDR for end-to-end encrypted XRM and determines the PDU set identifier and tag to be applied based on associated quality enforcement rules. The UPF may select the FQDN of the target AS based on information in the associated Forwarding Action Rules (FAR). In step 307, for example, if no existing QUIC connection exists between the UPF and the AS, a new QUIC connection for tunneling is established. This could be a MASQUE tunnel, for example. In some embodiments, this connection requires multipath capability. The QUIC connection can be identified on its initial path by an indicator (e.g., CID=MI). In some aspects, based on associated Connect-UDP information, the UPF decides to establish a QUIC connection to the AS (if not already established) and sends a Connect-UDP to the target AS. According to some embodiments, for example, if one or more optimizations are implemented, it also indicates its support for multipath QUIC. In step 308, the UPF forwards the initial QUIC packet sent by the UE in step 305 to the AS. According to an embodiment, it uses a MASQUE connection for transmission. In step 309, the AS and UE complete the QUIC connection establishment. This may include packets forwarded via the MASQUE connection. According to an embodiment, step 309 may establish a CID for the end-to-end QUIC connection from the AS to the UE.

[0040] Now refer to Figure 3BIn step 310, according to some embodiments, if one or more optimizations are implemented, the UPF establishes additional new paths to the AS (e.g., two or more new paths). This could be, for example, to distinguish PDUs sent through these paths belonging to odd-numbered and even-numbered PDU sets without additional metadata. Furthermore, additional paths are only needed if there are not enough paths for the MASQUE QUIC connection. In embodiments, different paths can be identified by new CIDs (e.g., M1, M2, etc.) for the direction from the AS to the UPF. Based on multi-path QUIC, for example, the UPF and AS can establish corresponding virtual connection IDs for each path for the Connect-UDP tunnel context established for the end-to-end QUIC connection in step 307. These virtual CIDs (e.g., vM1, vM2, etc.) are used for the direction from the AS to the UPF. In some respects, these paths do not necessarily represent different physical paths to the AS, but are distinguished by their quadruple and connection ID. The process can be made more robust (e.g., to withstand sudden packet loss) by adding more connection IDs to the mechanism, so that sudden packet loss will not mask the operation of switching back to the CID used before the loss occurred, thus avoiding the UPF mistakenly believing that no change has occurred when it has actually changed.

[0041] In step 311, if optimization is achieved, the AS derives the 1-RTT key for the UE and sends the header protection key to the UPF in the encapsulation, enabling the UPF to extract the sequence number of the QUIC packet in the end-to-end service and include it as the PDUSN in the packet forwarded to the NG-RAN. According to an embodiment, the end-to-end SN is not included as the PDU SN of the PDU set, and the end-to-end SN increments for each packet throughout the entire lifecycle of the e2e QUIC connection. For example, for each new PDU set, the PDU SN within the PDU set can be reset to 1. In some respects, this is why the PDU SN is signaled along with the initial packet of each PDU set so that subsequent packets can be mapped.

[0042] According to an embodiment, steps 312 to 314 are performed, for example, when using one or more of the optimizations described herein.

[0043] Referring now to step 312a, according to some embodiments, when the AS sends the first packet in the PDU set, one or more of the following operations are performed. First, a virtual CID associated with the end-to-end QUIC connection is selected for use. This may include, for example, selecting a path from the paths existing between the AS and the UPF, such as vM1 (in this case, an odd number). In this example, the end-to-end QUIC packet follows an HTTP-based QUIC-aware proxy, and its CID=E2 is replaced with CID=vM1. The PDU set information for this packet (PDU) is sent in an encapsulation. The encapsulation can be provided as an extension of the encapsulation protocol defined in IETF RFC 9297, although other encapsulation techniques may also be used. In an embodiment, the encapsulation is sent as a datagram in the MASQUE QUIC connection; that is, it will be encapsulated in a QUIC packet with CID=M1. These two QUIC packets with CIDs vM1 and M1 respectively can be merged into the same UDP payload, sharing the payload space of that UDP packet. The PDU set information encapsulation may contain information such as the PDU set size, importance, PDU set sequence number, and PDU sequence numbers within the PDU set. If the PDU is the last PDU in the PDU set, it may also include an end-of-PDU indication. According to an embodiment, if one or more optimizations implemented herein are used, the AS performs this step on the first N packets in the PDU set, which are combined with the corresponding PDU set information. The value of N can be chosen to be suitable for handling any possible level of packet loss in a given implementation.

[0044] Furthermore, in step 312a, the initial payload packets of the AS are sent via one of the established MASQUE connections (e.g., a connection for odd (or even) PDU sets). These packets are not encapsulated but are forwarded using an HTTP-based QUIC-aware proxy. Additionally, the AS sends encapsulations that include the PDU set size and importance, and in some embodiments, the PDU sequence numbers within the PDU set; these encapsulations are merged with the payload QUIC packets in the same UDP packet. Other information may also be included and merged. To compensate for possible packet loss, the encapsulations with PDU set metadata are repeated with an appropriate number of initial packets.

[0045] In steps 312b and 312c, for example, upon receiving the first payload packet on an odd (or even) QUIC connection, the UPF sets the PDU set sequence number to an initial value (e.g., "1"), forwards the packets received on that QUIC connection to the NG-RAN, and obtains the determined PDU set SN and the received PDU set size and importance from the merged encapsulation. The UPF also derives the PDU sequence number from the payload QUIC packet using a stored header protection key, and sends all PDU set metadata as a GTP-U extended header along with the payload. The UPF stores the PDU set sequence number, PDU set size, and importance for subsequent use on the same virtual connection ID. According to an embodiment, the NG-RAN sends the first PDU set in steps 312c, 313c, and 314c. According to an embodiment, processing / extraction of PDU information is performed based on the received key as described in step 311.

[0046] In steps 313a and 313b, the AS sends subsequent QUIC packets without encapsulation via the same Virtual Connection ID (vM1), and the UPF forwards these packets to the NG-RAN using metadata obtained from the initial packets. The UPF uses the header protection key to extract the sequence numbers of the end-to-end QUIC packets and then maps them to PDU sequence numbers within the PDU set by comparing them with the PDU sequence numbers and end-to-end packet sequence numbers received in step 312a. The PDU sequence numbers within the PDU set are also forwarded to the NG-RAN in the GTP-U header extension. If the first N packets of each PDU set are sent with the PDU set information, this embodiment can detect PDU changes for up to N consecutive packet losses and recover the PDU set information for N-1 consecutive packet losses. In steps 314a and 314b, the AS sends the last packet of the PDU set, which is merged with an encapsulation indicating the end of the PDU set. UPF forwards it to NG-RAN, adding the instruction in the GTP-U header extension.

[0047] In steps 315a-c, 316a-c, and 317a-c, the AS sends packets for the next PDU set via another virtual connection ID (e.g., vM2 for even-numbered PDU sets). The UPF increments the PDU set SN and forwards packets with added metadata as in steps 312b to 314b. Furthermore, the AS sends subsequent PDU sets via even-numbered and odd-numbered virtual connection IDs, and the UPF determines the PDU set SN and other PDU set metadata as described above. To make the detection of PDU set changes detectable and more reliable, multiple paths and multiple virtual CIDs can be used between the AS and the UPF. Therefore, even if a burst of PDU packet loss causes the entire PDU set to be lost, changes to the PDU set can still be detected.

[0048] According to some embodiments, if these optimizations are not implemented, one or more of steps 310 and 311 will not be performed, and steps 312a to 317a in process 300 can be simplified as follows. First, multiple virtual connection IDs are not necessarily used between the UPF and the AS. Second, all payload packets are sent in a combined manner with a MASQUE encapsulation containing PDU set information, including the PDU set sequence number, PDU set size, importance, PDU sequence number within the PDU set, and a PDU set end indication for the last PDU or for each PDU set for which reduced overhead optimizations have not been implemented. Third, the UPF retrieves all PDU set information from the MASQUE encapsulation and forwards it to the NG-RAN as a GTP-U header extension.

[0049] Combination Figure 3A and Figure 3B One or more embodiments described enable PDU set-related processing for end-to-end encrypted services that use QUIC as the transport protocol and MASQUE as the in-band communication between the 5GS and the content provider AS (and optionally, between the UE and the 5GS). For example, end-to-end XRM services can be QUIC-based RTP, QUIC-based media, or any other XRM application protocol carried over QUIC. In embodiments, XRM packets (or other media) are encapsulated within QUIC packets via QUIC streams and datagrams to transmit real-time data for a specific IP stream (represented by an IP 5-tuple) within a QUIC connection, and are encrypted using an embedded QUIC security mechanism.

[0050] Now refer to Figure 4In some embodiments, process 400 may begin at step 410, in which a session establishment request is sent to transmit PDU set identification information. For example, this request may be sent to the network to enable the network to recognize packets received from the UE as part of a QUIC connection establishment request. In some embodiments, establishing a secure tunnel includes receiving a request for a secure tunneling protocol with an indication to provide PDU set information. However, in other embodiments, this may be configured as a local policy in the PCF; it may also be implemented by configuring triggering conditions for establishing Connect-UDP and the FQDN of the AS in the SMF and / or UPF. In step 420, a secure tunnel for sending PDU set information is established. According to an embodiment, the tunneling protocol is MASQUE, and the PDUs and / or PDU set information are sent via a MASQUE connection. In step 430, a request for an end-to-end QUIC connection is received from the client via the secure tunnel. In step 440, a message to establish an additional path is received. In this case, for example, the PDU set is sent via a first path identified by a first CID, and the next PDU set is sent via a second path identified by a second CID. Step 450 may be optional in some embodiments, including sending a QUIC header protection key for PDU identification information within the encapsulation. In step 460, encrypted first PDU set information is sent via a secure tunnel. In step 470, encrypted second PDU set information is sent via a secure tunnel. According to embodiments, process 400 may include sending one or more encrypted first PDUs from the first PDU set to the client, wherein the first PDU set information corresponds to these first PDUs. Furthermore, one or more encrypted second PDUs from the second PDU set are sent, and in some embodiments, the PDUs in the second PDU set are sent using a different CID than those used to send the PDUs in the first PDU set. The PDU set information may be sent along with the PDUs within the encapsulation. In some embodiments, two QUIC PDUs are merged into a single UDP payload. For example, the payload QUIC packet may be merged with the signaling encapsulation in the same UDP packet, thereby avoiding encapsulating the payload packet within an encapsulation and avoiding the associated double encryption of the payload packet. Examples of set information include PDU set size, importance, PDU set sequence number, PDU sequence number within the first PDU set, and end PDU indication. According to some embodiments, process 400 is composed of... Figure 3A and Figure 3B The AF / AS described is executed. In an embodiment, process 400 may include one or more of steps 301 to 317.

[0051] Now refer to Figure 5Process 500 may begin at step 510, in which packets received from the UE are identified. According to an embodiment, these packets are part of a QUIC connection establishment request initiated to a target AS. In step 520, a target AS is selected, for example, by rule matching and / or based on received information or configuration. In step 530, a request to tunnel the UE's connection to the target AS is sent. In some aspects, this request instructs the transmission of encrypted PDU set information over a secure tunnel. This request may include sending a Connect-UDP to the target AS. Step 540 includes receiving PDU set information from the target AS via a secure tunnel, wherein the PDU set information corresponds to encrypted PDUs received from that AS. In an embodiment, the secure tunnel used to transmit the PDU set information is a MASQUE tunnel. In step 550, at least one QUIC packet is forwarded from the UE to the target AS using the secure tunnel connection. In step 560, one or more paths to the target AS are established. In an embodiment, a first path is used for a first PDU set and identified by a first CID, and a second path is used for a second PDU set and identified by a second CID (e.g., for even-numbered sets and odd-numbered sets, respectively). In step 570 (which may be optional in some embodiments), the process includes receiving a header protection key in the encapsulation and using the key to extract the sequence number of the QUIC packet. In an embodiment, the PDU sequence number within the PDU set can be derived from the sequence number of the QUIC packet by applying the difference between the sequence number of the QUIC packet and the PDU sequence number within the PDU set received in the encapsulation of the received PDU. In step 580, packets received from the target AS are forwarded on the tunnel connection to the NG-RAN. According to an embodiment, the set identification information includes one or more of the following: PDU set size, importance, PDU set sequence number, PDU sequence number within the PDU set, and PDU set end indication. According to some embodiments, process 500 is composed of, in combination with, Figure 3A and Figure 3B The described PSA-UPF execution. In an embodiment, process 500 may include one or more of steps 301 to 317.

[0052] In some embodiments, information and messages received as part of process 400 are the same information and messages sent in process 500. Similarly, information and messages received as part of process 500 can be information and messages sent in process 400. That is, according to embodiments, processes 400 and 500 are executed together. For example, process 400 can be executed by an AS or AF (e.g., with an integrated MASQUE agent) connected to a PSA-UPF or other client executing process 500. According to embodiments, the system may include one or more devices or nodes executing processes 400 and / or 500.

[0053] Now refer to Figure 6A and Figure 6B The document provides processes 600 and 650 related to the use of the package. Process 600 may be executed, for example, in an application server (AS) or other application function (AF), while process 650 may be executed in a user plane function (UPF) (e.g., PSA-UPF). In embodiments, processes 600 and 650 may include one or more of steps 301 to 317.

[0054] Now refer to Figure 6A Process 600 may begin at step 601, in which a secure tunnel connection is established. In step 602, PDU set information merged with one or more initial PDUs is transmitted via the secure tunnel connection. In some embodiments, the tunnel connection is a MASQUE connection, and the PDU set information and the PDUs are merged in an encapsulation. The method may also optionally include one or more of the following: transmitting (603) one or more subsequent PDUs in the first PDU set via the tunnel connection without the merged PDU set information; transmitting (604) the last PDU of the first PDU set merged with the PDU set end indication via the tunnel connection; transmitting (605) second PDU set information merged with one or more initial PDUs via the secure tunnel connection; transmitting (606) one or more subsequent PDUs in the second PDU set via the tunnel connection without the merged PDU set information; and transmitting (607) the last PDU of the second PDU set merged with the PDU set end indication via the tunnel connection. PDUs in the first PDU set can be sent using the first CID, and PDUs in the second PDU set can be sent using different second CIDs (e.g., for the even set and the odd set respectively).

[0055] Now refer to Figure 6BProcess 650 may begin at step 651, in which a secure tunnel connection is configured. In step 652, PDU set information merged with one or more initial PDUs is received via the secure tunnel connection. In some embodiments, the tunnel connection is a MASQUE connection, and the PDU set information and the PDUs are merged within a package. The method may also optionally include one or more of the following: receiving (653) one or more subsequent PDUs from the first PDU set via the tunnel connection without the merged PDU set information; receiving (654) the last PDU of the first PDU set merged with a PDU set end indication via the tunnel connection; receiving (655) second PDU set information merged with one or more initial PDUs via the secure tunnel connection; receiving (656) one or more subsequent PDUs from the second PDU set via the tunnel connection without the merged PDU set information; and receiving (657) the last PDU of the second PDU set merged with a PDU set end indication via the tunnel connection. PDUs in the first PDU set can be received on a path with a first CID, and PDUs in the second PDU set can be received on paths with different second CIDs (e.g., for even sets and odd sets respectively).

[0056] Processes 400, 500, 600, and 650 can be implemented, for example, using one or more of the following: UE, NG-RAN, PSA-UPF, SMF, PCF / NEF, and / or AF / AS. In embodiments, these can be combined. Figure 1 , Figure 2 , Figures 3A to 3B ,as well as Figures 7 to 12 The description refers to one or more functions, nodes, devices, or other entities. Furthermore, according to some embodiments, one or more steps may be omitted, and the order of the steps may be adjusted.

[0057] According to some embodiments, in order to securely obtain PDU set information from the AS, the UPF establishes a MASQUE connection with an HTTP proxy integrated in the AS according to the encapsulation protocol, indicating the ability to receive PDU set information in the encapsulation. In some aspects, the encapsulation can be defined to contain PDU set information such as PDU set size, importance, and data burst end indication. An encapsulation with PDU set size and importance but without a payload can be sent at the beginning of each PDU set and repeated an appropriate number of times to compensate for possible packet loss. To ensure that the PDU set information is available for all PDU set payload packets, the encapsulation can be merged with the initial QUIC packets in the PDU set containing the XRM payload. Furthermore, to avoid re-encapsulation and re-encryption, in embodiments, all XRM (or other media service) payload packets are forwarded using an HTTP-based QUIC-aware proxy. In some embodiments, to indicate each PDU set, a mechanism is defined such that whenever a new PDU set is to be sent, the QUIC entity at the AS selects a different QUIC CID until the maximum number of CIDs is reached, after which the established connection is reused. This allows for the indication of the PDU set of these packets while they are being forwarded directly, without encapsulating them in a MASQUE datagram. For this purpose, using two connection IDs is typically sufficient. In some embodiments, the end PDU set indication is sent as an encapsulation in a QUIC packet, which is merged with the last packet in the data burst within the same UDP payload. The PDU set sequence number can be obtained from the QUIC packets of the end-to-end connection by having the AS send a header protection key to the UPF within the MASQUE encapsulation. Alternatively, if another MASQUE connection is established between the UE and the UPF to support service identification of the encrypted payload itself (rather than the PDU set), the header protection key can be sent by the UE. In some embodiments, non-PDU set services can be forwarded via a separate connection ID.

[0058] In some embodiments, the AF sends an AF request message to the NEF / PCF, which includes Quality of Service (QoS) requirements and ancillary information for the media service. This may include: QoS requirements containing QoS parameters based on a set of PDUs; a service description, such as matching conditions (IP filter or application ID) and a target FQDN; and / or a protocol description indicating an HTTP-based QUIC-aware proxy, accompanied by an XRM wrapper specification.

[0059] Identifying end-to-end encrypted services can be challenging when the payload is end-to-end encrypted. Currently, limited identification based on IP filters and SNIs is possible, but this distinction may be insufficient in many cases. One or more embodiments can identify XRM services requiring PDU set marking with the assistance of both the UE and AF. In some aspects, the XRM application can transmit an XRM service identifier to the 5GS as a service detection aid. In some aspects, the PCF can use the XRM service identifier to generate PCC rules and pass these PCC rules to the SMF, and then to the UPF for service detection. In some aspects, before the end-to-end connection is established, the UE sends a Connect-UDP to the UPF to establish an uplink MASQUE connection, indicating the target XRM service. In some aspects, in addition to PDU set identification and marking, the UPF can also match a suitable PDR and execute corresponding policies based on the indicated XRM service identifier. In some aspects, the disclosed mechanisms allow the UPF to identify services with a finer granularity than IP filters and SNIs.

[0060] Figure 7 An example of a communication system 700 that can implement embodiments of the present disclosure is shown.

[0061] In this example, the communication system 700 includes a telecommunications network 702, which includes an access network 704 such as a radio access network (RAN), and a core network 706, which includes one or more core network nodes 708. The access network 704 includes one or more access network nodes, such as network nodes 710A and 710B (one or more of which may generally be referred to as network node 710), or any other similar 3GPP access node or non-3GPP access point (AP). Furthermore, those skilled in the art will understand that network nodes are not necessarily limited to an implementation that integrates the radio and baseband portions by a single vendor. Therefore, it will be understood that network nodes include decomposed implementations or portions thereof. For example, in some embodiments, the telecommunications network 702 includes one or more Open RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunications network 702 that supports ORAN specifications (e.g., specifications published by the O-RAN Alliance or any similar organization) and can operate independently or together with other nodes to perform one or more functions of any node in the telecommunications network 702 (including one or more network nodes 710 and / or core network nodes 708).

[0062] Examples of ORAN network nodes include Open Radio Units (O-RUs), Open Distributed Units (O-DUs), Open Central Units (O-CUs) (including O-CU control planes (O-CU-CPs) or O-CU user planes (O-CU-UPs)), RAN intelligent controllers (near real-time or non-real-time) with managed software or software plug-ins (e.g., near real-time control applications (e.g., xApps) or non-real-time control applications (e.g., rApps)), or any combination thereof (the adjective "open" indicates support for the ORAN specification). Network nodes can support the specification by, for example, supporting interfaces defined by the ORAN specification (e.g., A1, F1, W1, E1, E2, X2, Xn interfaces), open fronthaul user plane interfaces, or open fronthaul management plane interfaces. Furthermore, ORAN access nodes can be logical nodes within physical nodes. Additionally, ORAN network nodes can be implemented in a virtualized environment (described further below) where one or more network functions are virtualized. For example, the virtualized environment can include an O-Cloud computing platform orchestrated by a service management and orchestration framework via the O-2 interface or similar technologies defined by the O-RAN Consortium. Network node 710 facilitates direct or indirect connections of user equipment (UE), such as connecting UE 712A, 712B, 712C and 712D (one or more of which may generally be referred to as UE 712) to core network 706 via one or more wireless connections.

[0063] Examples of wireless communication via wireless connection include sending and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information without the use of wires, cables, or other conductors. Furthermore, in various embodiments, communication system 700 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that can facilitate or participate in data and / or signal communication (whether via wired or wireless connection). Communication system 700 may include and / or interface with any type of communications, telecommunications, data, cellular, radio network, and / or other similar type of system.

[0064] UE 712 can be any of a wide variety of communication devices, including wireless devices that are arranged, configured, and / or operable to communicate wirelessly with network node 710 and other communication devices. Similarly, network node 710 is arranged, capable, configured, and / or operable to communicate directly or indirectly with UE 712 and / or with other network nodes or devices in telecommunication network 702 to achieve and / or provide network access (e.g., wireless network access) and / or to perform other functions in telecommunication network 702 (e.g., management).

[0065] In the depicted example, core network 706 connects network node 710 to one or more hosts, such as host 716. These connections can be direct connections or indirect connections via one or more intermediate networks or devices. In other examples, network nodes can be directly coupled to hosts. Core network 706 includes one or more core network nodes (e.g., core network node 708) that are formed together with hardware and software components. The characteristics of these components can be substantially similar to those described with respect to UE, network nodes, and / or hosts, such that the description is generally applicable to the corresponding components of core network node 708. Example core network nodes include the functions of one or more of the following: Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier Unhiding Function (SIDF), Unified Data Management (UDM), Security Edge Protection Agent (SEPP), Network Open Function (NEF), and / or User Plane Function (UPF).

[0066] Host 716 may be owned or under the control of a service provider other than the operator or provider of access network 704 and / or telecommunications network 702, and may be operated by or on behalf of that service provider. Host 716 may host a variety of applications to provide one or more services. Examples of such applications include real-time and pre-recorded audio / video content, data collection services (e.g., retrieving and compiling data about various environmental conditions detected by multiple UEs), analytics functions, social media, functions for controlling or otherwise interacting with remote devices, functions for alarms and monitoring centers, or any other such functions performed by the server.

[0067] Overall, Figure 7The communication system 700 enables connectivity between the UE, network nodes, and hosts. In this sense, the communication system can be configured to operate according to predefined rules or procedures (e.g., specific standards), including but not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE) and / or other suitable second-, third-, fourth-, or fifth-generation (2G, 3G, 4G, or 5G) standards, or any applicable future-generation standard (e.g., sixth-generation (6G)); Wireless Local Area Network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi); and / or any other suitable wireless communication standards, such as Global Microwave Access Interoperability (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC), ZigBee, LiFi, and / or any Low Power Wide Area Network (LPWAN) standards such as LoRa and Sigfox.

[0068] In some examples, telecommunications network 702 is a cellular network implementing 3GPP standardized features. Therefore, telecommunications network 702 can support network slicing to provide different logical networks to different devices connected to it. For example, telecommunications network 702 can provide ultra-reliable low-latency communication (URLLC) services to some UEs while providing enhanced mobile broadband (eMBB) services to other UEs, and / or massive machine-type communication (mMTC) / massive Internet of Things (IoT) services to yet another set of UEs.

[0069] In some examples, UE 712 is configured to send and / or receive information without direct human interaction. For example, the UE may be designed to send information to access network 704 according to a predetermined schedule when triggered by internal or external events or in response to a request from access network 704. Additionally, the UE may be configured to operate in a single RAT or multiple radio access technology (RAT) or multiple standards mode. For example, the UE may operate using any or a combination of WiFi, New Radio (NR), and LTE, i.e., configured for multiple radio dual connectivity (MR-DC), such as Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) NR-Dual Connectivity (EN-DC).

[0070] In this example, hub 714 communicates with access network 704 to facilitate indirect communication between one or more UEs (e.g., UE 712C and / or 712D) and network nodes (e.g., network node 710B). In some examples, hub 714 may be a controller, router, content source and analyzer, or any other communication device described herein relating to the UE. For example, hub 714 may be a broadband router that enables the UE to access core network 706. As another example, hub 714 may be a controller that sends commands or instructions to one or more actuators in the UE. Commands or instructions may be received from the UE, network node 710, or via executable code, scripts, processes, or other instructions in hub 714. As another example, hub 714 may be a data collector that acts as a temporary storage device for UE data, and in some embodiments, data analysis or other processing may be performed. As another example, hub 714 may be a content source. For example, for a UE acting as a virtual reality (VR) headset, display, speaker, or other media delivery device, hub 714 can retrieve VR assets, video, audio, or other media or data related to perceived information via network nodes, and then provide them directly to the UE after performing local processing and / or adding additional local content. In yet another example, hub 714 acts as a proxy server or orchestrator for the UE, particularly if one or more of these UEs are low-power IoT devices.

[0071] The hub 714 can have a constant / persistent connection or an intermittent connection with the network node 710B. The hub 714 can also allow different communication schemes and / or scheduling between the hub 714 and the UE (e.g., UE 712C and / or 712D) and between the hub 714 and the core network 706. In other examples, the hub 714 is connected to the core network 706 and / or one or more UEs via a wired connection. Furthermore, the hub 714 can be configured to connect to a machine-to-machine (M2M) service provider via the access network 704, and / or to another UE via a direct connection. In some scenarios, the UE can establish a wireless connection with the network node 710 while still being connected via the hub 714 via a wired or wireless connection. In some embodiments, the hub 714 can be a dedicated hub, i.e., a hub whose primary function is to route communication between the UE and the network node 710B. In other embodiments, the central hub 714 may be a non-dedicated central hub, that is, a device capable of routing communication between the UE and the network node 710B, and also capable of functioning as the communication start point and / or end point of certain data channels.

[0072] Figure 8A UE 800 according to some embodiments is illustrated. As used herein, a UE refers to a device capable of, configured, positioned, and / or operable to wirelessly communicate with network nodes and / or other UEs. Examples of UEs include, but are not limited to, smartphones, mobile phones, cellular phones, Voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, gaming consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablet computers, laptop computers, laptop embedded devices (LEEs), laptop-mounted devices (LMEs), smart devices, wireless client devices (CPEs), vehicles, vehicle-mounted or vehicle-embedded / integrated wireless devices, etc. Other examples include any UE identified by 3GPP, including Narrowband Internet of Things (NB-IoT) UEs, Machine Type Communication (MTC) UEs, and / or Enhanced MTC (eMTC) UEs.

[0073] The UE can support device-to-device (D2D) communication, for example, by implementing 3GPP standards for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, the UE may not necessarily be a user in the sense of a human user who owns and / or operates the associated device. Alternatively, the UE may represent a device intended to be sold to or operated by a human user but which may not or initially may not be associated with a particular human user (e.g., a smart sprinkler controller). Or, the UE may represent a device not intended to be sold to or operated by an end user but which may be associated with or operated for the benefit of the user (e.g., a smart meter).

[0074] UE 800 includes processing circuitry 802, which is operatively coupled via bus 804 to input / output interface 806, power supply 808, memory 810, communication interface 812, and / or any other component, or any combination thereof. Some UEs may utilize... Figure 8 The components shown may be all or a subset. The level of integration between components can vary depending on the UE. Furthermore, some UEs may include multiple instances of components, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0075] Processing circuitry 802 is configured to process instructions and data and can be configured to implement any sequential state machine operable to execute instructions stored in memory 810 as a machine-readable computer program. Processing circuitry 802 can be implemented as: one or more hardware-implemented state machines (e.g., implemented with discrete logic, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors (e.g., microprocessors or digital signal processors (DSPs)) together with appropriate software; or any combination of the foregoing. For example, processing circuitry 802 may include multiple central processing units (CPUs).

[0076] In this example, the input / output interface 806 can be configured to provide one or more interfaces to input devices, output devices, or one or more input and / or output devices. Examples of output devices include speakers, sound cards, graphics cards, displays, monitors, printers, actuators, transmitters, smart cards, other output devices, or any combination thereof. Input devices can allow users to capture information into the UE 800. Examples of input devices include touch-sensitive or proximity-sensitive displays, cameras (e.g., digital cameras, digital camcorders, webcams, etc.), microphones, sensors, mice, trackballs, directional keyboards, touchpads, scroll wheels, smart cards, etc. Presence-sensitive displays may include capacitive or resistive touch sensors to sense input from the user. Sensors may be, for example, accelerometers, gyroscopes, tilt sensors, force sensors, magnetometers, optical sensors, proximity sensors, biometric sensors, etc., or any combination thereof. Output devices can use the same type of interface port as input devices. For example, a Universal Serial Bus (USB) port can be used to provide both input and output devices.

[0077] In some embodiments, power supply 808 is configured as a battery or battery pack. Other types of power sources can be used, such as external power sources (e.g., power outlets), photovoltaic devices, or batteries. Power supply 808 may also include power supply circuitry for delivering power from power supply 808 itself and / or external power sources to various parts of UE 800 via input circuitry or an interface such as a power cable. The delivery of power can, for example, be used for charging power supply 808. The power supply circuitry can perform any formatting, conversion, or other modifications on the power from power supply 808 to suit the power for the various components of UE 800 to which it is supplied power.

[0078] Memory 810 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), disk, optical disk, hard disk, removable magnetic tape, flash drive, etc. In one example, memory 810 includes one or more application programs 814, such as an operating system, web browser application, widget, utility engine, or other application, and corresponding data 816. Memory 810 may store any one or a combination of various operating systems used by UE 800.

[0079] The memory 810 can be configured to include multiple physical drive units, such as a redundant array of independent disks (RAID), flash memory, a USB flash drive, an external hard drive, a thumb drive, a pen drive, a key drive, a high-density digital versatile optical disc (HD-DVD) drive, an internal hard drive, a Blu-ray disc drive, a holographic digital data storage (HDDS) disc drive, an external mini dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro DIMM SDRAM, smart card memory (e.g., a tamper-proof module in the form of a universal integrated circuit card (UICC), including one or more subscriber identification modules (SIMs), such as a universal SIM (USIM) and / or an IP multimedia service identification module (ISIM)), other memory, or any combination thereof. The UICC can be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly referred to as a "SIM card." The memory 810 can allow the UE 800 to access instructions, applications, etc., stored on transient or non-transient storage media to offload or upload data. Articles of manufacture, such as those utilizing a communication system, may be tangibly embodied in or contained in memory 810, which may be or include a device-readable storage medium.

[0080] Processing circuitry 802 can be configured to communicate with an access network or other network using communication interface 812. Communication interface 812 may include one or more communication subsystems and may include or be communicatively coupled to antenna 822. Communication interface 812 may include one or more transceivers for communication (e.g., via one or more remote transceivers capable of wireless communication with another device (e.g., another UE or a network node in the access network). Each transceiver may include a transmitter 818 and / or a receiver 820 suitable for providing network communication (e.g., optical, electrical, frequency assignment, etc.). Furthermore, transmitter 818 and receiver 820 may be coupled to one or more antennas (e.g., antenna 822) and may share circuitry, software, or firmware, or alternatively, be implemented separately.

[0081] In the illustrated embodiment, the communication functions of the communication interface 812 may include cellular communication, WiFi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, NFC, location-based communication (e.g., using a Global Positioning System (GPS) to determine location), another type of communication function, or any combination thereof. Communication may be implemented according to one or more communication protocols and / or standards (e.g., IEEE 802.11, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, NR, UMTS, WiMax, Ethernet, Transmission Control Protocol / Internet Protocol (TCP / IP), Synchronous Optical Network (SONET), Asynchronous Transfer Mode (ATM), Fast User Datagram Protocol Internet Connection (QUIC), Hypertext Transfer Protocol (HTTP), etc.).

[0082] Regardless of the sensor type, the UE can provide the output of data captured by its sensors via its communication interface 812 through a wireless connection with a network node. Data captured by the UE's sensors can be transmitted via another UE through the same wireless connection. The output can be periodic (e.g., every 15 minutes if it reports the sensed temperature), random (e.g., to balance the load of reports from several sensors), responsive to a triggering event (e.g., sending an alarm when humidity is detected), responsive to a request (e.g., a user-initiated request), or a continuous stream (e.g., real-time video feed of a patient).

[0083] As another example, the UE includes actuators, motors, or switches associated with a communication interface configured to receive wireless input from a network node via a wireless connection. The state of the actuator, motor, or switch can change in response to the received wireless input. For example, the UE may include a motor that adjusts the control surfaces or rotors of a flying drone based on the received input, or adjusts a robotic arm performing a medical procedure based on the received input.

[0084] When the UE is in the form of an Internet of Things (IoT) device, the UE can be a device used in one or more application areas, including but not limited to urban wearable technology, extended industrial applications, and healthcare. Non-limiting examples of such IoT devices include or embedded in the following devices: connected refrigerators or freezers, televisions, connected lighting devices, electricity meters, robotic vacuum cleaners, voice-controlled smart speakers, home security cameras, motion detectors, thermostats, smoke detectors, door and window sensors, flood / humidity sensors, electronic door locks, connected doorbells, air conditioning systems (such as heat pumps), autonomous vehicles, surveillance systems, weather monitoring devices, vehicle parking monitoring devices, electric vehicle charging stations, smartwatches, fitness trackers, head-mounted displays for augmented reality (AR) or virtual reality (VR), wearable devices for haptic or sensory enhancement, sprinklers, animal or item tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and any kind of medical device (such as heart rate monitors or remote-controlled surgical robots). In addition to the above... Figure 8 In addition to the other components described in the UE 800 shown, UEs in the form of IoT devices also include circuitry and / or software depending on the intended application of the IoT device.

[0085] As another specific example, in an IoT scenario, a UE can represent a machine or other device that performs monitoring and / or measurement and sends the results of such monitoring and / or measurement to another UE and / or network node. In this case, the UE can be an M2M device, which can be referred to as an MTC device in the 3GPP context. As a specific example, this UE can implement the 3GPP NB-IoT standard. In other scenarios, a UE can represent a vehicle (e.g., a car, bus, truck, ship, or aircraft) or other device capable of monitoring and / or reporting its operational status or other functions associated with its operation.

[0086] In practice, any number of UEs can be used together for a single use case. For example, the first UE can be a drone or integrated into a drone, and provides the drone's speed information (obtained via a speed sensor) to a second UE, which is a remote controller for operating the drone. When the user makes a change from the remote controller, the first UE can adjust the throttle on the drone (e.g., by controlling the actuators) to increase or decrease the drone's speed. The first UE and / or the second UE can also include more than one of the functions described above. For example, the UE can include sensors and actuators, and handle data communication between both the speed sensor and the actuators.

[0087] Figure 9 A network node 900 according to some embodiments is illustrated. As used herein, a network node refers to a device capable of, configured, arranged, and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or devices in a telecommunications network. Examples of network nodes include, but are not limited to, access points (e.g., radio access points), base stations (BSs) (e.g., radio BSs, NodeBs, evolved NodeBs (eNBs), NR NodeBs (gNBs)), and O-RAN nodes or components of O-RAN nodes (e.g., O-RUs, O-DUs, O-CUs).

[0088] Base stations can be classified based on the coverage they provide (or, in other words, their transmission power levels); therefore, depending on the coverage provided, a base station can be called a femtobase, picobase, microbase, or macrobase. A base station can be a relay node or a relay donor for a control relay. Network nodes can also include one or more (or all) portions of a distributed radio base station, such as centralized digital units, distributed units (e.g., in O-RAN access nodes), and / or remote radio units (RRUs), sometimes referred to as remote radio headends (RRHs). These RRUs may or may not be integrated with antennas to form an antenna-integrated radio. A portion of a distributed radio base station can also be referred to as a node in a distributed antenna system (DAS).

[0089] Other examples of network nodes include multi-transmitter point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment (e.g., MSR BS), network controllers (e.g., radio network controller (RNC) or base station controller (BSC)), base transceiver stations (BTS), transmitter points, transmitter nodes, multi-cell / multicast coordination entities (MCE), operations and maintenance (O&M) nodes, operations support system (OSS) nodes, self-organizing network (SON) nodes, location nodes (e.g., evolved Serving Mobility Location Center (E-SMLC)) and / or minimized drive test (MDT).

[0090] Network node 900 includes processing circuitry 902, memory 904, communication interface 906, and power supply 908. Network node 900 may consist of multiple physically separate components (e.g., NodeB components and RNC components, BTS components and BSC components, etc.), each with its own corresponding components. In some scenarios where network node 900 includes multiple separate components (e.g., BTS and BSC components), one or more separate components may be shared among several network nodes. For example, a single RNC can control multiple NodeBs. In such scenarios, each unique NodeB and RNC pair may be considered a single, separate network node in some cases. In some embodiments, network node 900 may be configured to support multiple RATs. In such embodiments, some components may be replicated (e.g., separate memory 904 exists for different RATs), and some components may be reused (e.g., the same antenna 910 may be shared by different RATs). Network node 900 may also include multiple sets of various components shown for different wireless technologies (e.g., GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, RFID, or Bluetooth wireless technologies). These wireless technologies may be integrated into the same or different chips or chipsets and other components within network node 900.

[0091] Processing circuitry 902 may include one or more of the following: a microprocessor, controller, microcontroller, CPU, DSP, ASIC, FPGA or any other suitable computing device, resource, or combination of hardware, software and / or coding logic, operable to provide network node 900 functionality, either alone or in combination with other network node 900 components (e.g., memory 904).

[0092] In some embodiments, the processing circuitry 902 includes a system-on-a-chip (SOC). In some embodiments, the processing circuitry 902 includes one or more of a radio frequency (RF) transceiver circuitry 912 and a baseband processing circuitry 914. In some embodiments, the RF transceiver circuitry 912 and the baseband processing circuitry 914 may be on separate chips (or chipsets), boards, or units (e.g., radio units and digital units). In alternative embodiments, some or all of the RF transceiver circuitry 912 and the baseband processing circuitry 914 may be on the same chip or chipset, board, or unit group.

[0093] Memory 904 may include any form of volatile or non-volatile computer-readable memory, including but not limited to permanent storage devices, solid-state memory, remotely mounted memory, magnetic media, optical media, RAM, ROM, mass storage media (e.g., hard disk), removable storage media (e.g., flash drives, optical discs (CDs), or digital video discs (DVDs)) and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that stores information, data, and / or instructions usable by processing circuitry 902. Memory 904 may store any suitable instructions, data, or information, including computer programs, software, applications including logic, rules, codes, tables, and / or other instructions executable by processing circuitry 902 and usable by network node 900. Memory 904 may be used to store any calculations performed by processing circuitry 902 and / or any data received via communication interface 906. In some embodiments, processing circuitry 902 and memory 904 are integrated together.

[0094] Communication interface 906 is used for wired or wireless communication of signaling and / or data between network nodes, access networks, and / or UEs. As shown, communication interface 906 includes a port / terminal 916 for transmitting and receiving data to and from the network, for example, via a wired connection. Communication interface 906 also includes radio front-end circuitry 918, which may be coupled to antenna 910, or in some embodiments, is part of antenna 910. Radio front-end circuitry 918 includes a filter 920 and an amplifier 922. Radio front-end circuitry 918 may be connected to antenna 910 and processing circuitry 902. Radio front-end circuitry 918 may be configured to modulate the signal transmitted between antenna 910 and processing circuitry 902. Radio front-end circuitry 918 may receive digital data to be transmitted to other network nodes or UEs via a wireless connection. Radio front-end circuitry 918 may use a combination of filter 920 and / or amplifier 922 to convert the digital data into a radio signal with appropriate channel and bandwidth parameters. The radio signal may then be transmitted via antenna 910. Similarly, when data is received, antenna 910 can collect radio signals, which are then converted into digital data by radio front-end circuitry 918. The digital data can then be passed to processing circuitry 902. In other embodiments, the communication interface may include different components and / or different combinations of components.

[0095] In some alternative embodiments, network node 900 does not include a separate radio front-end circuitry 918; instead, processing circuitry 902 includes radio front-end circuitry and is connected to antenna 910. Similarly, in some embodiments, all or some of the RF transceiver circuitry 912 is part of communication interface 906. In yet another embodiment, communication interface 906 includes one or more ports or terminals 916, radio front-end circuitry 918, and RF transceiver circuitry 912 as part of a radio unit (not shown), and communication interface 906 communicates with baseband processing circuitry 914, which is part of a digital unit (not shown).

[0096] Antenna 910 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals. Antenna 910 may be coupled to radio front-end circuitry 918 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, antenna 910 is decoupled from network node 900 and may be connected to network node 900 via an interface or port.

[0097] Antenna 910, communication interface 906, and / or processing circuitry 902 can be configured to perform any receive operation and / or certain acquire operation described herein by a network node. Any information, data, and / or signals can be received from the UE, another network node, and / or any other network device. Similarly, antenna 910, communication interface 906, and / or processing circuitry 902 can be configured to perform any transmit operation described herein by a network node. Any information, data, and / or signals can be transmitted to the UE, another network node, and / or any other network device.

[0098] Power supply 908 supplies power to the various components of network node 900 in a form suitable for each component (e.g., at the voltage and current levels required by each respective component). Power supply 908 may also include or be coupled to power management circuitry to supply power to the components of network node 900 for performing the functions described herein. For example, network node 900 may be connected to an external power source (e.g., the mains or a power outlet) via input circuitry or an interface (e.g., a cable), thereby supplying power to the power circuitry of power supply 908. As another example, power supply 908 may include a power source in the form of a battery or battery pack, which is connected to or integrated into the power circuitry. The battery can provide backup power if the external power source fails.

[0099] Implementations of network node 900 may include more than Figure 9The components shown are additional components used to provide certain aspects of the functionality of the network node, including any functionality described herein and / or any functionality required to support the topics described herein. For example, network node 900 may include a user interface device to allow information to be input into and output from network node 900. This allows users to perform diagnostic, maintenance, repair, and other management functions on network node 900.

[0100] Figure 10 This is a block diagram of host 1000 based on the various aspects described herein, which host 1000 may be Figure 7 The embodiment of host 716. Host 1000 as used herein can be or include various combinations of hardware and / or software (including processing resources in standalone servers, blade servers, cloud-implemented servers, distributed servers, virtual machines, containers, or server clusters). Host 1000 can provide one or more services to one or more UEs.

[0101] Host 1000 includes processing circuitry 1002, which is operatively coupled via bus 1004 to input / output interface 1006, network interface 1008, power supply 1010, and memory 1012. Other components may be included in other embodiments. The features of these components may be substantially similar to those with respect to the previous figures (e.g., Figure 8 and Figure 9 The characteristics described for the device make its description generally applicable to the corresponding components of the host 1000.

[0102] Memory 1012 may include one or more computer programs, including one or more host applications 1014 and data 1016, which may include user data, such as data generated by the UE for the host 1000, or data generated by the host 1000 for the UE. Embodiments of the host 1000 may utilize only a subset or all of the illustrated components. Host application 1014 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Universal Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), Moving Picture Experts Group (MPEG), VP9) and audio codecs (e.g., Free and Lossless Audio Codec (FLAC), Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for a variety of different categories, types, or implementations of UEs (e.g., mobile phones, desktop computers, wearable display systems, and head-up display systems). Host application 1014 can also provide user authentication and authorization checks, and can periodically report health status, routing, and content availability to a central node (e.g., a device in the core network or a device at the core network edge). Therefore, host 1000 can select and / or indicate different hosts for over-the-top (OTT) services for the UE. Host application 1014 can support various protocols, such as HTTP Live Streaming (HLS), Real-time Messaging Protocol (RTMP), Real-time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (DASH or MPEG-DASH), etc.

[0103] Figure 11 This is a block diagram illustrating a virtualization environment 1100 capable of virtualizing functionality implemented by some embodiments. In this context, virtualization means creating a virtual version of an apparatus or device that may include a virtualized hardware platform, storage devices, and network resources. Virtualization as used herein can be applied to any device or component thereof described herein, and involves at least a portion of its functionality being implemented as an implementation of one or more virtual components. Some or all of the functionality described herein can be implemented as virtual components executed by one or more virtual machines (VMs) in one or more virtual environments 1100 hosted by one or more hardware nodes (e.g., hardware computing devices operating as network nodes, UEs, core network nodes, or hosts). Furthermore, in embodiments where the virtual node does not require radio connectivity (e.g., core network nodes or hosts), the node can be fully virtualized. In some embodiments, the virtualization environment 1100 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated via an O-2 interface by a service management and orchestration framework.

[0104] Application 1102 (which may also be referred to as a software instance, virtual device, network function, virtual node, virtual network function, etc.) runs in virtualization environment 1100 to implement some of the features, functions and / or benefits of some embodiments disclosed herein.

[0105] Hardware 1104 includes processing circuitry, memory storing software and / or instructions executable by the hardware processing circuitry, and / or other hardware devices described herein (e.g., network interfaces, input / output interfaces, etc.). The software can be executed by the processing circuitry to instantiate one or more virtualization layers 1106 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1108A and 1108B (one or more of which may generally be referred to as VM 1108), and / or perform any functionality, features, and / or benefits described in relation to some embodiments described herein. Virtualization layer 1106 can present a virtual operating platform to VM 1108, which appears as network hardware.

[0106] VM 1108 includes virtual processing, virtual memory, virtual network or interface, and virtual storage, and can be run by a corresponding virtualization layer 1106. Different embodiments of instances of virtual device 1102 can be implemented on one or more VMs 1108, and the implementation can be made in different ways. In some contexts, hardware virtualization is referred to as Network Functions Virtualization (NFV). NFV can be used to unify numerous network device types onto industry-standard high-capacity server hardware, physical switches, and physical storage devices that can be located in data centers and customer premises equipment (CPE).

[0107] In the context of NFV, VM 1108 can be a software implementation of a physical machine, whose program runs as if it were running on a physical, non-virtualized machine. Each VM 1108, along with the portion of hardware 1104 that executes that VM (whether it is dedicated hardware for that VM and / or hardware shared by that VM and other VMs 1108), forms a separate virtual network element. Still within the context of NFV, the virtual network function is responsible for handling the specific network functions running on one or more VMs 1108 above hardware 1104 and corresponding to application 1102.

[0108] Hardware 1104 can be implemented in a standalone network node with general or specific components. Hardware 1104 may implement some functions via virtualization. Alternatively, hardware 1104 may be part of a larger hardware cluster (e.g., in a data center or CPE) where many hardware nodes work together and are managed through management and orchestration 1110, which in particular oversees the lifecycle management of application 1102. In some embodiments, hardware 1104 is coupled to one or more radio units, each radio unit including one or more transmitters and one or more receivers that can be coupled to one or more antennas. The radio units may communicate directly with other hardware nodes via one or more suitable network interfaces and may be used in conjunction with virtual components to provide radio capabilities to virtual nodes (e.g., RAN or base stations). In some embodiments, some signaling may be provided using a control system 1112, which may alternatively be used for communication between hardware nodes and radio units.

[0109] Figure 12 A communication diagram is shown showing a host 1202 communicating with a UE 1206 via a partial wireless connection through a network node 1204, according to some embodiments. Reference will now be made to... Figure 12 To describe the UE discussed in the preceding paragraphs (e.g., Figure 7 UE 712A and / or Figure 8 UE 800), network nodes (e.g., Figure 7 Network node 710A and / or Figure 9 Network node 900) and host (e.g., Figure 7 Host 716 and / or Figure 10 Example implementations of the host 1000 according to various embodiments.

[0110] Similar to host 1000, embodiments of host 1202 include hardware such as a communication interface, processing circuitry, and memory. Host 1202 also includes software stored in or accessible by host 1202 and executable by the processing circuitry. This software includes a host application operable to provide services to a remote user, such as UE 1206 connected via an OTT connection 1250 extending between UE 1206 and host 1202. When providing services to a remote user, the host application can provide user data transmitted using OTT connection 1250.

[0111] Network node 1204 includes hardware that enables it to communicate with host 1202 and UE 1206. Connection 1260 can be a direct connection or via a core network (such as...). Figure 7The connection to the core network (706) and / or one or more other intermediate networks (e.g., one or more public, private, or hosted networks). For example, an intermediate network could be a backbone network or the Internet.

[0112] UE 1206 includes hardware and software stored in or accessible by UE 1206 and executable by the UE's processing circuitry. The software includes client applications (e.g., web browsers or carrier-specific "applications") operable to provide services to human or non-human users via UE 1206, supported by host 1202. In host 1202, the executing host application can communicate with the executing client application via OTT connection 1250, which terminates between UE 1206 and host 1202. When providing services to a user, the UE's client application can receive request data from the host application of the host and, in response to the request data, provide user data. OTT connection 1250 can transmit both request data and user data. The UE's client application can interact with the user to generate user data provided to the host application via OTT connection 1250.

[0113] OTT connection 1250 can be extended via connection 1260 between host 1202 and network node 1204 and via wireless connection 1270 between network node 1204 and UE 1206 to provide connectivity between host 1202 and UE 1206. Connection 1260 and wireless connection 1270, which provide OTT connection 1250, have been abstractly drawn to illustrate communication between host 1202 and UE 1206 via network node 1204, without explicitly involving any intermediate devices and the precise routing of messages via these devices.

[0114] As an example of sending data via OTT connection 1250, in step 1208, host 1202 provides user data, which can be performed by executing a host application. In some embodiments, the user data is associated with a specific human user interacting with UE 1206. In other embodiments, the user data is associated with UE 1206, which shares data with host 1202 without explicit human interaction. In step 1210, host 1202 initiates a transmission to UE 1206 carrying the user data. Host 1202 may initiate the transmission in response to a request sent by UE 1206. This request may be caused by human interaction with UE 1206 or by the operation of a client application executed on UE 1206. According to the teachings of the embodiments described throughout this disclosure, this transmission may be delivered via network node 1204. Therefore, in step 1212, according to the teachings of the embodiments described throughout this disclosure, network node 1204 sends the user data carried in the transmission initiated by host 1202 to UE 1206. In step 1214, UE 1206 receives user data carried in the transmission, which can be performed by a client application running on UE 1206, which is associated with a host application running by host 1202.

[0115] In some examples, UE 1206 executes a client application that provides user data to host 1202. User data can be provided as a response to data received from host 1202. Therefore, in step 1216, UE 1206 can provide user data, which can be done by executing the client application. When providing user data, the client application may also consider user input received from a user via the input / output interface of UE 1206. Regardless of the specific manner in which user data is provided, in step 1218, UE 1206 initiates the transmission of user data to host 1202 via network node 1204. In step 1220, in accordance with the teachings of the embodiments described throughout this disclosure, network node 1204 receives user data from UE 1206 and initiates the transmission of the received user data to host 1202. In step 1222, host 1202 receives the user data carried in the transmission initiated by UE 1206.

[0116] One or more embodiments in various examples improve the performance of OTT services provided to UE 1206 using OTT connection 1250, in which wireless connection 1270 forms the final part.

[0117] In the example scenario, host 1202 can collect and analyze plant status information. As another example, host 1202 can process audio and video data that may have been retrieved from the UE for map creation. As another example, host 1202 can collect and analyze real-time data to assist in controlling traffic congestion (e.g., controlling traffic lights). As another example, host 1202 can store surveillance video uploaded by the UE. As another example, host 1202 can store or control access to media content such as video, audio, VR, or AR, which can be broadcast, multicast, or unicast to the UE. As other examples, host 1202 can be used for energy pricing, remote control of non-time-critical power loads to balance generation demand, location services, presentation services (e.g., compiling charts based on data collected from remote devices), or any other function that collects, retrieves, stores, analyzes, and / or transmits data.

[0118] In some examples, a measurement process may be provided to monitor data rate, latency, and other factors that one or more embodiments may improve upon. Optional network functions may also be present for reconfiguring the OTT connection 1250 between host 1202 and UE 1206 in response to changes in measurement results. The measurement process and / or the network functions for reconfiguring the OTT connection 1250 may be implemented in the software and hardware of host 1202 and / or UE 1206. In some embodiments, sensors (not shown) may be deployed in or associated with other devices traversed by the OTT connection 1250; the sensors may participate in the measurement process by providing values ​​of the monitored quantities exemplified above or by providing values ​​of other physical quantities from which software can calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 1250 may include message formatting, retransmission settings, preferred routing, etc.; reconfiguration does not require a direct change to the operation of network node 1204. Such processes and functions may be known and practiced in the art. In some embodiments, the measurement may involve proprietary UE signaling that facilitates host 1202's measurement of throughput, propagation time, latency, etc. Measurements can be achieved by having the software use an OTT connection 1250 to send messages (especially empty or “virtual” messages) while monitoring propagation time, errors, etc.

[0119] While the computing devices described herein (e.g., UE, network node, host) may include combinations of the hardware components shown, other embodiments may include computing devices with different combinations of components. It should be understood that these computing devices may include any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. The determination, calculation, acquisition, or similar operations described herein may be performed by processing circuitry that processes information in ways such as: converting acquired information into other information, comparing the acquired or converted information with information stored in a network node, and / or performing one or more operations based on the acquired or converted information, and making determinations based on the results of said processing. Furthermore, although components are depicted as single boxes located within larger boxes or nested within multiple boxes, in practice, a computing device may include multiple different physical components constituting a single illustrated component, and functionality may be partitioned between individual components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of a component may be partitioned between processing circuitry and the communication interface. In another example, the non-computationally intensive functions of any such component may be implemented in software or firmware, and the computationally intensive functions may be implemented in hardware.

[0120] In some embodiments, some or all of the functions described herein may be provided by processing circuitry that executes instructions stored in memory, which in some embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functions may be provided by the processing circuitry, for example, in a hard-wired manner, without executing instructions stored on a separate or discrete device-readable storage medium. In any of these particular embodiments, the processing circuitry may be configured to perform the described functions regardless of whether instructions stored on a non-transitory computer-readable storage medium are executed. The benefits provided by such functions are not limited to the individual processing circuitry or other components of the computing device, but are enjoyed holistically by the computing device and / or generally by the end user and wireless network.

[0121] Although various embodiments have been described herein, it should be understood that these embodiments are presented by way of example only and not as limitations. Therefore, the breadth and scope of this disclosure should not be limited to any of the exemplary embodiments described above. Furthermore, unless otherwise indicated herein or the context clearly contradicts it, any combination of all possible variations of the foregoing elements is included in this disclosure.

[0122] Furthermore, although the process described above and shown in the accompanying drawings is presented as a series of steps, this is merely for illustrative purposes. Therefore, it is conceivable that some steps may be added, some steps may be omitted, the order of the steps may be rearranged, and some steps may be performed in parallel.

[0123] List of cited references

[0124] 3GPP TR 23.700-70 v0.3.0 (February 2024): Study on architecture enhancement for Extended Reality and Media service (XRM); Phase 2.

[0125] IETF RFC 9297: HTTP Datagrams and the Capsule Protocol;

[0126] IETF RFC 9298: Proxying UDP in HTTP;

[0127] IETF RFC 9484: Proxying IP in HTTP;

[0128] Multipath Extensions for QUIC (available at https: / / datatracker.ietf.org / doc / draft-ietf-quic-multipath / ).

[0129] QUIC-Aware Proxying Using HTTP (available at https: / / datatracker.ietf.org / doc / draft-pauly-masque-quic-proxy / ).

[0130] This invention may also be limited by the following provisions:

[0131] 1. A method (400) comprising:

[0132] Establish (420) a secure tunnel for sending Protocol Data Unit (PDU) set information; and

[0133] The encrypted first PDU set information is sent via the secure tunnel (460).

[0134] 2. The method according to Clause 1, wherein establishing the secure tunnel comprises: receiving a request for a secure tunneling protocol, the request carrying an indication to provide PDU set information.

[0135] 3. The method described according to Clause 1 or 2 further includes:

[0136] Receive (430) requests for end-to-end QUIC connections from the client via a secure tunnel.

[0137] 4. The method according to any one of clauses 1 to 3 further includes:

[0138] Send one or more encrypted first PDUs of a first PDU set to the client, wherein the information of the first PDU set corresponds to the first PDU.

[0139] 5. The method according to Clause 4, wherein the first PDU is sent together with the PDU set information for each PDU in the set.

[0140] 6. The method according to any one of clauses 1 to 5 further includes:

[0141] Send (410) a request to the network to establish an application session for transmitting PDU set identification information, thereby enabling the network to identify packets received from the user equipment (UE) that are part of a QUIC connection.

[0142] 7. The method according to Clause 6, wherein the request for establishing an application session includes one or more of the following: multiplexed application support layer MASQUE protocol description information based on QUIC encryption; an indication of PDU set identification using Connect-UDP; the fully qualified domain name (FQDN) of the application server AS; and / or the address of the AS used for the Connect-UDP request.

[0143] 8. The method according to any one of clauses 1 to 7, wherein the tunneling protocol is MASQUE, and wherein the PDU and PDU set information are sent via a MASQUE connection.

[0144] 9. The method according to Clause 8, wherein the PDU set information is sent together with the PDU in the package.

[0145] 10. The method according to Clause 8, wherein the encapsulation body and the QUIC PDU are combined into a single User Datagram Protocol (UDP) payload.

[0146] 11. The method according to any one of Clauses 1 to 10, wherein the PDU set information includes one or more of the following: PDU set size, importance, PDU set sequence number, PDU sequence number within the first PDU set, and end PDU indication.

[0147] 12. The method according to Clause 11, wherein the PDU sequence number in the first PDU set is sent with one or more initial PDUs instead of with all PDUs in the set.

[0148] 13. The method according to Clause 11 or 12, wherein the PDU sequence number in the first PDU set is sent together with each PDU in the set.

[0149] 14. The method according to any one of Clauses 1 to 13, wherein sending PDU set information includes: selecting a connection ID, i.e., a CID, to signal packets belonging to different PDU sets.

[0150] 15. The method according to any one of Clauses 1 to 14, wherein one or more PDUs are sent to the User Equipment (UE) according to an encrypted end-to-end QUIC protocol.

[0151] 16. The method according to any one of clauses 1 to 15 further comprises:

[0152] Send at least one additional encrypted PDU from the first PDU set without a set identification information encapsulation.

[0153] 17. The method according to any one of clauses 1 to 16 further comprises:

[0154] Send (450) the QUIC header protection key for PDU identification information in the encapsulation.

[0155] 18. The method according to any one of clauses 1 to 17, further comprising:

[0156] Receive (440) a message to establish an additional path, wherein the first PDU set is sent via a first path identified by a first CID, and the second PDU set is sent via a second path identified by a second CID.

[0157] 19. The method according to Clause 18, wherein a plurality of subsequent PDU sets are sent alternately via a first path and a second path.

[0158] 20. The method according to Clause 18 or 19, wherein the first path is used for the odd-numbered PDU set and the second path is used for the even-numbered PDU set.

[0159] 21. The method according to any one of clauses 3 to 20, wherein the received QUIC connection establishment message indicates support for multipath QUIC.

[0160] 22. The method according to any one of clauses 1 to 21 further comprises:

[0161] (470) Encrypted second PDU set information is sent via the secure tunnel, and (470) one or more encrypted second PDUs of the second PDU set are sent, wherein the PDUs of the second PDU set are sent using a CID different from the PDUs of the first PDU set.

[0162] 23. The method according to any one of Clauses 1 to 22, wherein the PDU includes Extended Reality and Media XRM groups.

[0163] 24. The method according to any one of clauses 1 to 23, wherein establishing the secure tunnel comprises: receiving a connection establishment message for PDU set identification information according to the tunneling protocol.

[0164] 25. The method according to any one of clauses 1 to 23, wherein establishing the secure tunnel comprises: receiving Connect-UDP from PSA-UPF.

[0165] 26. An apparatus (204, 708, 900, 1100) configured to:

[0166] Establish a secure tunnel for sending Protocol Data Unit (PDU) set information; and

[0167] The encrypted first PDU set information is sent via the secure tunnel.

[0168] 27. The apparatus according to Clause 26 is also configured to perform any of the steps in Clauses 2 through 24.

[0169] 28. The apparatus according to clause 26 or 27, wherein the apparatus is an application server AS.

[0170] 29. The apparatus according to any one of clauses 26 to 28, wherein the apparatus includes an integrated QUIC-encrypted multiplexed application support layer MASQUE proxy for transmitting PDU collection information.

[0171] 30. A method (500) comprising:

[0172] Identify (510) packets received from user equipment (UE), wherein the packets are part of a QUIC connection with a target application server (AS);

[0173] Sending (530) a request to tunnel the UE's connection to the target AS, wherein the request indicates the transmission of encrypted Protocol Data Unit (PDU) set information over a secure tunnel; and

[0174] (540) PDU set information is received from the target AS through the secure tunnel, wherein the PDU set information corresponds to the encrypted PDU received from the AS.

[0175] 31. The method according to Clause 30, wherein sending a request to tunnel the connection of the UE to the target AS comprises: sending a Connect-UDP to the target AS.

[0176] 32. The method according to clause 30 or 31, wherein received packets of a QUIC connection that will receive PDU set information are identified based on received information or configured information.

[0177] 33. The method according to Clause 32, wherein the received information includes N4 rules, or MASQUE-related information based on QUIC encryption for tunneling connections to the target AS.

[0178] 34. The method according to Clause 33, wherein the N4 rule includes one or more of the following: Quality Enforcement Rule (QER); Forwarding Action Rule (FAR); Packet Detection Rule (PDR); Fully Qualified Domain Name (FQDN) of the target AS; and / or Connect-UDP information.

[0179] 35. The method according to any one of clauses 30 to 34, wherein the secure tunnel used for transmitting PDU set information is a MASQUE tunnel.

[0180] 36. The method according to any one of clauses 30 to 35 further comprises:

[0181] Select the target AS as described in (520).

[0182] 37. The method according to Clause 36, wherein the selection is based on matching at least one rule with received information, the received information relating to an encrypted service identifier and an associated PDU set identifier.

[0183] 38. The method according to any one of clauses 30 to 37 further comprises:

[0184] Using the secure tunnel connection, forward (550) at least one QUIC packet from the UE to the target AS.

[0185] 39. The method according to any one of clauses 20 to 37, wherein at least one received encrypted PDU is not encapsulated and is transmitted using QUIC-aware forwarding, which converts the QUIC header destination connection identifier of the AS into a UE QUIC packet.

[0186] 40. The method according to any one of clauses 30 to 39, wherein the encrypted PDU is received together with a package containing identification information of the corresponding PDU set.

[0187] 41. The method according to Clause 40, wherein the encrypted PDU and the PDU set information are each encapsulated in a QUIC packet and merged into a single User Datagram Protocol (UDP) payload.

[0188] 42. The method according to any one of clauses 30 to 41, wherein the set identification information includes one or more of the following: PDU set size, importance, PDU set sequence number, PDU sequence number within the PDU set, and PDU set end indication.

[0189] 43. The method according to any one of clauses 30 to 42 further comprises:

[0190] Receive at least one additional encrypted PDU corresponding to the PDU set, without the set identification information encapsulation.

[0191] 44. The method according to any one of clauses 30 to 43 further comprises:

[0192] Forward (580) packets received from the target AS on the tunnel connection to NG-RAN.

[0193] 45. The method according to Clause 44, wherein the forwarding further comprises: setting a PDU set sequence number for packets of the first PDU set.

[0194] 46. ​​The method according to any one of clauses 30 to 45 further comprises:

[0195] Establish one or more paths with the target AS, wherein a first path is used for a first PDU set and identified by a first connection ID (CID), and a second path is used for a second PDU set and identified by a second CID.

[0196] 47. The method according to Clause 46, wherein the first path is used for the odd-numbered PDU set and the second path is used for the even-numbered PDU set.

[0197] 48. The method according to any one of clauses 30 to 47, wherein the PDU set sequence number is received in a package containing PDU set information, the PDU set information being merged with each PDU in the set.

[0198] 49. The method according to any one of clauses 30 to 48 further comprises:

[0199] Receive (570) the header protection key in the encapsulation and use the key to extract the sequence number of the QUIC packet.

[0200] 50. The method according to any one of clauses 30 to 49 further comprises:

[0201] The PDU sequence number in the PDU set is derived from the QUIC packet sequence number by applying the difference between the sequence number of the QUIC packet and the PDU sequence number in the PDU set received in the package of the received PDU.

[0202] 51. An apparatus (202, 708, 900, 1100) configured to:

[0203] Identify packets received from a user equipment (UE), wherein the packets are part of a QUIC connection with a target application server (AS);

[0204] Send a request to connect the UE's connection to the target AS via a tunnel, wherein the request indicates the transmission of encrypted Protocol Data Unit (PDU) set information over a secure tunnel; and

[0205] PDU set information is received from the target AS through the secure tunnel, wherein the PDU set information corresponds to encrypted PDUs received from the AS.

[0206] 52. The apparatus described in Clause 51 is also configured to perform any of the steps in Clauses 30 to 50.

[0207] 53. The apparatus according to clause 51 or 52, wherein the apparatus is a PSA-UPF.

[0208] 54. A method (600) comprising:

[0209] Establish (601) a secure tunnel connection; and

[0210] The first PDU set information, which is merged with one or more initial PDUs, is sent (602) via the secure tunnel connection.

[0211] 55. The method according to Clause 54, wherein the tunnel connection is a QUIC-encrypted multiplexed application support layer MASQUE connection, and wherein the PDU set information and the PDU are merged in an encapsulation.

[0212] 56. The method described pursuant to clause 54 or 55 further comprises:

[0213] (603) Send one or more subsequent PDUs of the first PDU set via the tunnel connection without merging PDU set information.

[0214] 57. The method according to any one of clauses 54 to 56 further comprises:

[0215] The last PDU of the first PDU set, which is merged with the PDU set end indication, is sent via the tunnel connection (604).

[0216] 58. The method according to any one of clauses 54 to 57 further comprises:

[0217] Transmit (605) a second PDU set information merged with one or more initial PDUs via the secure tunnel connection;

[0218] Transmit (606) one or more subsequent PDUs of the second PDU set via the tunnel connection, without merging PDU set information; and

[0219] The last PDU of the second PDU set, which is merged with the PDU set end indication, is sent via the tunnel connection (607).

[0220] 59. The method according to Clause 58, wherein the PDUs of the first PDU set are sent using a first connection ID (CID), and the PDUs of the second PDU set are sent using a different second CID.

[0221] 60. The method according to Clause 59, wherein the first CID is used for the odd-numbered PDU set, and the second CID is used for the even-numbered PDU set.

[0222] 61. The method according to any one of Clauses 54 to 60 further includes any one of the steps in Clauses 1 to 25.

[0223] 62. A method (650) comprising:

[0224] Configure (651) a secure tunnel connection; and

[0225] Receive (652) first PDU set information merged with one or more initial PDUs via the secure tunnel connection.

[0226] 63. The method according to Clause 62, wherein the tunnel connection is a QUIC-encrypted multiplexed application support layer MASQUE connection, and wherein the PDU set information and the PDU are merged in an encapsulation.

[0227] 64. The method described pursuant to clause 62 or 63 further comprises:

[0228] Receive (653) one or more subsequent PDUs of the first PDU set via the tunnel connection without merging PDU set information.

[0229] 65. The method according to any one of clauses 62 to 64 further comprises:

[0230] The last PDU of the first PDU set, which is merged with the PDU set end indication, is received via the tunnel connection (654).

[0231] 66. The method according to any one of clauses 62 to 65 further comprises:

[0232] Receive (655) second PDU set information merged with one or more initial PDUs via the secure tunnel connection;

[0233] Receive (656) one or more subsequent PDUs of the second PDU set via the tunnel connection, without merging PDU set information; and

[0234] The last PDU of the second PDU set, which is merged with the PDU set end indication, is received via the tunnel connection (657).

[0235] 67. The method according to Clause 66, wherein the PDUs of the first PDU set are received on a path having a first connection ID (CID), and the PDUs of the second PDU set are received on a path having a different second CID.

[0236] 68. The method according to Clause 67, wherein the first CID is used for the odd-numbered PDU set, and the second CID is used for the even-numbered PDU set.

[0237] 69. The method according to any one of Clauses 62 to 68 further includes any one of the steps in Clauses 27 to 45.

[0238] 70. An apparatus configured to perform any one of clauses 54 to 69.

[0239] 71. A computer program product comprising a non-transitory computer-readable medium storing instructions that, when executed by processing circuitry of a device, cause the device to perform any one of clauses 1 to 25, 30 to 50, and 54 to 69.

Claims

1. A method (400) comprising: Establish (420) a secure tunnel for sending Protocol Data Unit (PDU) set information; as well as The encrypted first PDU set information is sent via the secure tunnel (460).

2. The method according to claim 1, wherein, Establishing the secure tunnel includes receiving a request for a secure tunneling protocol, the request carrying an indication to provide PDU set information.

3. The method according to claim 1 or 2, further comprising: Receive (430) requests for end-to-end QUIC connections from the client via a secure tunnel.

4. The method according to any one of claims 1 to 3, further comprising: Send one or more encrypted first PDUs of a first PDU set to the client, wherein the information of the first PDU set corresponds to the first PDU.

5. The method according to claim 4, wherein, The first PDU is sent together with the PDU set information for each PDU in the set.

6. The method according to any one of claims 1 to 5, further comprising: Send (410) a request to the network to establish an application session for transmitting PDU set identification information, thereby enabling the network to identify packets received from the user equipment (UE) that are part of a QUIC connection.

7. The method according to claim 6, wherein, The request to establish an application session includes one or more of the following: a QUIC-encrypted multiplexed application support layer MASQUE protocol description information; an indication of PDU set identification using Connect-UDP; the fully qualified domain name (FQDN) of the application server AS; and / or the address of the AS used for the Connect-UDP request.

8. The method according to any one of claims 1 to 7, wherein, The tunneling protocol is MASQUE, and the PDU and PDU set information are sent via a MASQUE connection.

9. The method according to claim 8, wherein, The PDU set information is sent together with the PDU in the package.

10. The method according to claim 9, wherein, The encapsulation and QUIC PDU are combined into a single User Datagram Protocol (UDP) payload.

11. The method according to any one of claims 1 to 10, wherein, The PDU set information includes one or more of the following: PDU set size, importance, PDU set sequence number, PDU sequence number within the first PDU set, and end PDU indication.

12. The method according to claim 11, wherein, The PDU sequence number in the first PDU set is sent with one or more initial PDUs, rather than with all PDUs in the set.

13. The method according to claim 11 or 12, wherein, The PDU sequence number in the first PDU set is sent together with each PDU in the set.

14. The method according to any one of claims 1 to 13, wherein, Sending PDU set information includes selecting a connection ID, or CID, to signal packets belonging to different PDU sets.

15. The method according to any one of claims 1 to 14, wherein, One or more PDUs are sent to the User Equipment (UE) according to the encrypted end-to-end QUIC protocol.

16. The method according to any one of claims 1 to 15, further comprising: Send at least one additional encrypted PDU from the first PDU set without a set identification information encapsulation.

17. The method according to any one of claims 1 to 16, further comprising: Send (450) the QUIC header protection key for PDU identification information in the encapsulation.

18. The method according to any one of claims 1 to 17, further comprising: Receive (440) a message to establish an additional path, wherein the first PDU set is sent via a first path identified by a first CID, and the second PDU set is sent via a second path identified by a second CID.

19. The method according to any one of claims 1 to 18, wherein, Establishing the secure tunnel includes: receiving a connection establishment message for PDU set identification information according to the tunnel protocol.

20. The method according to any one of claims 1 to 18, wherein, Establishing the secure tunnel includes receiving Connect-UDP from the PSA-UPF.

21. An apparatus (204, 708, 900, 1100) configured to: Establish a secure tunnel for sending Protocol Data Unit (PDU) set information; and The encrypted first PDU set information is sent via the secure tunnel.

22. The apparatus of claim 21 is further configured to perform any one of the steps of claims 2 to 20.

23. The apparatus according to claim 21 or 22, wherein, The device is an application server (AS).

24. A method (500) comprising: Identify (510) packets received from user equipment (UE), wherein the packets are part of a QUIC connection with a target application server (AS); Sending (530) a request to tunnel the UE's connection to the target AS, wherein the request indicates the transmission of encrypted Protocol Data Unit (PDU) set information over a secure tunnel; and (540) PDU set information is received from the target AS through the secure tunnel, wherein the PDU set information corresponds to the encrypted PDU received from the AS.

25. The method according to claim 24, wherein, Sending a request to connect the UE's connection to the target AS via a tunnel includes sending a Connect-UDP to the target AS.

26. The method according to claim 24 or 25, wherein, The received packets of a QUIC connection that will receive PDU set information are identified based on received or configured information.

27. The method according to claim 26, wherein, The received information includes N4 rules, or MASQUE-related information based on QUIC encryption for tunnel connections to the target AS.

28. The method according to claim 27, wherein, The N4 rule includes one or more of the following: Quality Execution Rule (QER); Forwarding Action Rule (FAR); Packet Detection Rule (PDR); Fully Qualified Domain Name (FQDN) of the target AS; and / or Connect-UDP information.

29. The method according to any one of claims 24 to 28, wherein, The secure tunnel used to transmit PDU set information is the MASQUE tunnel.

30. The method according to any one of claims 24 to 29, further comprising: Select the target AS as described in (520).

31. The method according to claim 30, wherein, The selection is based on matching at least one rule with the received information, which is related to an encrypted service identifier and an associated PDU set identifier.

32. The method according to any one of claims 24 to 31, further comprising: Using the secure tunnel connection, forward (550) at least one QUIC packet from the UE to the target AS.

33. The method according to any one of claims 24 to 31, wherein, At least one received encrypted PDU was not encapsulated and was transmitted using QUIC-aware forwarding, which converts the destination connection identifier of the AS's QUIC header into a UE QUIC packet.

34. The method according to any one of claims 24 to 33, wherein, The encrypted PDU is received together with a package containing the corresponding PDU set identifier information.

35. The method according to claim 34, wherein, The encrypted PDU and the PDU set information are each encapsulated in a QUIC packet and merged into a single User Datagram Protocol (UDP) payload.

36. The method according to any one of claims 24 to 35, wherein, The set identification information includes one or more of the following: PDU set size, importance, PDU set sequence number, PDU sequence number within the PDU set, and PDU set end indication.

37. The method according to any one of claims 24 to 36, further comprising: Receive at least one additional encrypted PDU corresponding to the PDU set, without the set identification information encapsulation.

38. The method according to any one of claims 24 to 37, further comprising: Forward (580) packets received from the target AS on the tunnel connection to NG-RAN.

39. The method according to claim 38, wherein, The forwarding also includes setting a PDU set sequence number for the group of the first PDU set.

40. An apparatus (202, 708, 900, 1100) configured to: Identify packets received from the user equipment (UE), wherein, The packet is part of a QUIC connection to the target application server AS; Send a request to connect the UE's connection to the target AS via a tunnel, wherein the request indicates the transmission of encrypted Protocol Data Unit (PDU) set information over a secure tunnel; and PDU set information is received from the target AS through the secure tunnel, wherein the PDU set information corresponds to encrypted PDUs received from the AS.

41. The apparatus of claim 40 is further configured to perform any one of the steps of claims 25 to 39.

42. The apparatus according to claim 40 or 41, wherein, The device is a PSA-UPF.

43. A computer program product comprising a non-transitory computer-readable medium storing instructions that, when executed by processing circuitry of a device, cause the device to perform the method of any one of claims 1 to 20 and 24 to 39.

Images