Multiplexed data transfer in a wireless communication system

Abstract

Various aspects of the present disclosure relate to a first network entity for wireless communication. The first network entity may be configured, capable, or operable to establish a first connection with a second network entity for data traffic, wherein the data traffic comprises first data associated with a first client entity and second data associated with a second client entity; multiplex the first data and the second data based at least in part on an identifier associated with the first data or the second data, wherein the multiplexed data comprising the first data and the second data are encapsulated in accordance with a tunnel protocol; and transmit the multiplexed and encapsulated data to the second network entity via the established first connection.

Description

MULTIPLEXED DATA TRANSFER IN A WIRELESS COMMUNICATION SYSTEMTECHNICAL FIELD

[0001] The present disclosure relates to wireless communication, including multiplexed data transfer in a wireless communications system.BACKGROUND

[0002] A wireless communications system may include one or multiple network communication devices, which may be otherwise knowns as network equipment (NE), supporting wireless communications for one or multiple user communication devices, which may be otherwise known as user equipment (UE), or other suitable terminology. The wireless communications system may support wireless communications with one or multiple user communication devices by utilizing resources of the wireless communication system (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers, or the like). Additionally, the wireless communications system may support wireless communications across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, among other suitable radio access technologies beyond 5G (e.g., sixth generation (6G)).SUMMARY

[0003] An article “a” before an element is unrestricted and understood to refer to “at least one” of those elements or “one or more” of those elements. The terms “a,” “at least one,” “one or more,” and “at least one of one or more” may be interchangeable. As used herein, including in the claims, “or” as used in a list of items (e.g., a list of items prefaced by a phrase such as “at least one of’ or “one or more of’ or “one or both of’) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (e.g., A and B and C). Also, as used herein, the phrase “based on” shall not be construed as a reference to a closed set of conditions. For example, an example step that is described as “based on condition A” may be based on both a condition A and a condition Bwithout departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be construed in the same manner as the phrase “based at least in part on. Further, as used herein, including in the claims, a “set” may include one or more elements.

[0004] A first network entity for wireless communication is described. The first network entity may be configured, capable, or operable to perform one or more operations as described herein. For example, the first network entity may comprise: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the first network entity to: establish a first connection with a second network entity for data traffic, wherein the data traffic comprises first data associated with a first client entity and second data associated with a second client entity; multiplex the first data and the second data based at least in part on an identifier associated with the first data or the second data, wherein the multiplexed data comprising the first data and the second data are encapsulated in accordance with a tunnel protocol; and transmit the multiplexed and encapsulated data to the second network entity via the established first connection.

[0005] A method performed or performable by a first network entity is described. The method may comprise: establishing a first connection with a second network entity for data traffic, wherein the data traffic comprises first data associated with a first client entity and second data associated with a second client entity; multiplexing the first data and the second data based at least in part on an identifier associated with the first data or the second data, wherein the multiplexed data comprising the first data and the second data are encapsulated in accordance with a tunnel protocol; and transmitting the multiplexed and encapsulated data to the second network entity via the established first connection.

[0006] A processor for wireless communication is described. The processor may be configured, capable, or operable to perform one or more operations as described herein. For example, the processor may comprise at least one controller coupled with at least one memory and configured to cause the processor to: establish a first connection with a second network entity for data traffic, wherein the data traffic comprises first data associated with a first client entity and second data associated with a second client entity; multiplex the first data and the second data based at least in part on an identifier associated with the first dataor the second data, wherein the multiplexed data comprising the first data and the second data are encapsulated in accordance with a tunnel protocol; and transmit the multiplexed and encapsulated data to the second network entity via the established first connection.

[0007] A second network entity for wireless communication is described. The second network entity may be configured, capable, or operable to perform one or more operations as described herein. For example, the second network entity may comprise: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the second network entity to: receive, from a first network entity, multiplexed data encapsulated according to a tunnel protocol; and demultiplex the multiplexed data based on an identifier and on the tunnel protocol.

[0008] A method performed or performable by a second network entity is described. The method may comprise: receiving, from a first network entity, multiplexed data encapsulated according to a tunnel protocol; and demultiplexing the multiplexed data based on an identifier and on the tunnel protocol.

[0009] A processor for wireless communication is described. The processor may be configured, capable, or operable to perform one or more operations as described herein. For example, the processor may comprise at least one controller coupled with at least one memory and configured to cause the processor to: receive, from a first network entity, multiplexed data encapsulated according to a tunnel protocol; and demultiplex the multiplexed data based on an identifier and on the tunnel protocol.

[0010] A method for wireless communication at a network function is described. The method may comprise: establishing a first connection on behalf of a first client for a tunnel protocol encapsulation of a first application data flow traffic corresponding to the client, wherein the connection is established with an application server (AS); routing the first application data flow traffic between the first client and the AS within the first connection over the tunnel protocol encapsulation; the AS acting as a proxy to a second AS, a target AS; establishing a second connection on behalf of a second client for a tunnel protocol encapsulation of at least a second application data flow traffic, wherein the connection is established with the AS; multiplexing based on a flow identifier and on the tunnel protocol encapsulation the second application data flow traffic with the first application data flowtraffic between the network function and the AS; and routing the second application data flow traffic between the second client and the AS within the second connection over the tunnel protocol encapsulation.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 illustrates an example of a wireless communications system in accordance with aspects of the present disclosure.

[0012] Figure 2 illustrates an example of a framework for proxying encrypted packets.

[0013] Figure 3 illustrates a Packet Data Unit (PDU) set marking and User Datagram Protocol (UDP) payload within a Hypertext Transfer Protocol / 3 (HTTP / 3) datagram in accordance with aspects of the present disclosure.

[0014] Figure 4 illustrates a PDU Set marking in accordance with aspects of the present disclosure.

[0015] Figure 5 illustrates a 3GPP payload and UDP payload within a HTTP / 3 Datagram in accordance with aspects of the present disclosure.

[0016] Figure 6 illustrates tunnelling over an HTTP / 3 connection and CONNECT requests differentiated by query parameters in accordance with aspects of the present disclosure.

[0017] Figure 7 illustrates tunnelling over an HTTP / 3 connection and CONNECT requests differentiated by authority port numbers in accordance with aspects of the present disclosure.

[0018] Figure 8 illustrates tunnelling over an HTTP / 3 connection and CONNECT requests differentiated by authority port numbers mapped to different tunnels in accordance with aspects of the present disclosure.

[0019] Figure 9 illustrates tunnelling over an HTTP / 3 connection using 3GPP-specific identifiers in accordance with aspects of the present disclosure.

[0020] Figure 10 illustrates a Context ID format in accordance with aspects of the present disclosure.

[0021] Figure 11 illustrates tunnelling over an HTTP / 3 connection using Context Identifiers (IDs) in accordance with aspects of the present disclosure.

[0022] Figure 12 illustrates a Flow Identifier, PDU set marking and UDP payload within an HTTP / 3 datagram in accordance with aspects of the present disclosure.

[0023] Figure 13 illustrates a 3 GPP-specific payload header and UDP payload in accordance with aspects of the present disclosure.

[0024] Figure 14 illustrates a Format Identifier in accordance with aspects of the present disclosure.

[0025] Figure 15 illustrates an example of a process flow for communications between a client, a server, and an origin server in accordance with aspects of the present disclosure.

[0026] Figure 16 illustrates an example of a UE 1600 in accordance with aspects of the present disclosure.

[0027] Figure 17 illustrates an example of a processor 1700 in accordance with aspects of the present disclosure.

[0028] Figure 18 illustrates an example of a NE 1800 in accordance with aspects of the present disclosure.

[0029] Figure 19 illustrates a flowchart of a method 1900 performed by a UE in accordance with aspects of the present disclosure.

[0030] Figure 20 illustrates a flowchart of a method 2000 performed by a NE in accordance with aspects of the present disclosure.DETAILED DESCRIPTION

[0031] A wireless communication system, including one or more UE and NE may support encryption of packets (e.g., media packets) to maintain security and / or integrity of the packets. The wireless communication system may support proxying of the encrypted packets (e.g., fully encrypted packets) via, for example, an N6 interface. (In the context of this disclosure, “fully encrypted packet” refers to a proxying payload of a HTTP Datagram payload, which may be encrypted E2E (e.g., between a client UE and a target AS). A UDPpayload (504) as shown in Figure 5 can be virtually any encrypted Service Data Unit (SDU) of UDP, e.g., Datagram Transport Layer Security (DTLS), QUIC or even Secure Real-time Transport Protocol (SRTP) with encrypted Real-Time Transport Protocol (RTP header extensions)). The N6 interface may support routing of the encrypted packets between one or more UE, NE, or UPFs (e.g., two or more network entities) of the wireless communication system. In some cases, it might be challenging to distinguish data traffic (e.g., packets, traffic elements), particularly their origin (e.g., source). Additionally, wireless communication (e.g., transmission of encrypted packets, reception of encrypted packets) might become inefficient, as a result of an increase in a number of UEs and / or an amount of traffic, including encrypted packets. This is at least partly due to there being a common, single, client (e.g., UE, UPF) communicating with a single server (e.g., AS, target server) on behalf of a plurality of different UEs and / or applications.

[0032] Aspects of the present disclosure support techniques for managing (e.g., distinguishing) traffic flows, for example in a multiplexed traffic flow, that correspond to different clients or applications. The different traffic flows are encapsulated using an encapsulation protocol. To differentiate these traffic flows, aspects of the present disclosure provide identifiers that enable identification of individual traffic flows and the client or application with which they are associated. Also, aspects of the present disclosure improve interoperability and scalability of the wireless communication system when handling, for example, fully encrypted media packets. Improve interoperability and scalability may be provided by introducing a specific identifier (e.g., a 3GPP-specific identifier) as part of a UDP payload, which is useable by core network and proxy network paths to differentiate traffic flows from one another.

[0033] Aspects of the present disclosure are described in the context of a wireless communications system.

[0034] Figure 1 illustrates an example of a wireless communications system 100 in accordance with aspects of the present disclosure. The wireless communications system 100 may include one or more NE 102, one or more UE 104, and a core network (CN) 106. The wireless communications system 100 may support various radio access technologies. In some implementations, the wireless communications system 100 may be a 4G network, such as anLTE network or an LTE -Advanced (LTE-A) network. In some other implementations, the wireless communications system 100 may be a NR network, such as a 5G network, a 5G- Advanced (5G-A) network, or a 5G ultrawideband (5G-UWB) network. In other implementations, the wireless communications system 100 may be a combination of a 4G network and a 5G network, or other suitable radio access technology including Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20. The wireless communications system 100 may support radio access technologies beyond 5G, for example, 6G. Additionally, the wireless communications system 100 may support technologies, such as time division multiple access (TDMA), frequency division multiple access (FDMA), or code division multiple access (CDMA), etc.

[0035] The one or more NE 102 may be dispersed throughout a geographic region to form the wireless communications system 100. One or more of the NE 102 described herein may be or include or may be referred to as a network node, a base station, a network element, a network function, a network entity, a radio access network (RAN), a NodeB, an eNodeB (eNB), a next-generation NodeB (gNB), or other suitable terminology. An NE 102 and a UE 104 may communicate via a communication link, which may be a wireless or wired connection. For example, an NE 102 and a UE 104 may perform wireless communication (e.g., receive signalling, transmit signalling) over a Uu interface.

[0036] An NE 102 may provide a geographic coverage area for which the NE 102 may support services for one or more UEs 104 within the geographic coverage area. For example, an NE 102 and a UE 104 may support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcast, etc.) according to one or multiple radio access technologies. In some implementations, an NE 102 may be moveable, for example, a satellite associated with a non-terrestrial network (NTN). In some implementations, different geographic coverage areas associated with the same or different radio access technologies may overlap, but the different geographic coverage areas may be associated with different NE 102.

[0037] The one or more UE 104 may be dispersed throughout a geographic region of the wireless communications system 100. A UE 104 may include or may be referred to as a remote unit, a mobile device, a wireless device, a remote device, a subscriber device, atransmitter device, a receiver device, or some other suitable terminology. In some implementations, the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples. Additionally, or alternatively, the UE 104 may be referred to as an Internet-of-Things (loT) device, an Internet-of-Everything (loE) device, or machine-type communication (MTC) device, among other examples.

[0038] A UE 104 may be able to support wireless communication directly with other UEs 104 over a communication link. For example, a UE 104 may support wireless communication directly with another UE 104 over a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular-V2X deployments, the communication link may be referred to as a sidelink. For example, a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.

[0039] An NE 102 may support communications with the CN 106, or with another NE 102, or both. For example, an NE 102 may interface with other NE 102 or the CN 106 through one or more backhaul links (e.g., SI, N2, N2, or network interface). In some implementations, the NE 102 may communicate with each other directly. In some other implementations, the NE 102 may communicate with each other or indirectly (e.g., via the CN 106. In some implementations, one or more NE 102 may include subcomponents, such as an access network entity, which may be an example of an access node controller (ANC). An ANC may communicate with the one or more UEs 104 through one or more other access network transmission entities, which may be referred to as a radio heads, smart radio heads, or transmission-reception points (TRPs).

[0040] The CN 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. The CN 106 may be an evolved packet core (EPC), or a 5G core (5GC), which may include a control plane entity that manages access and mobility (e.g., a mobility management entity (MME), an access and mobility management functions (AMF)) and a user plane entity that routes packets or interconnects to external networks (e.g., a serving gateway (S-GW), a Packet Data Network (PDN) gateway (P-GW), or a user plane function (UPF)). In some implementations, the control plane entity may manage non-access stratum (NAS) functions, such as mobility,authentication, and bearer management (e.g., data bearers, signal bearers, etc.) for the one or more UEs 104 served by the one or more NE 102 associated with the CN 106.

[0041] The CN 106 may communicate with a packet data network over one or more backhaul links (e.g., via an SI, N2, N2, or another network interface). The packet data network may include an AS. In some implementations, one or more UEs 104 may communicate with the AS. A UE 104 may establish a session (e.g., a PDU session, or the like) with the CN 106 via an NE 102. The CN 106 may route traffic (e. g. , control information, data, and the like) between the UE 104 and the AS using the established session (e.g., the established PDU session). The PDU session may be an example of a logical connection between the UE 104 and the CN 106 (e.g., one or more network functions of the CN 106).

[0042] In the wireless communications system 100, the NEs 102 and the UEs 104 may use resources of the wireless communications system 100 (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communications). In some implementations, the NEs 102 and the UEs 104 may support different resource structures. For example, the NEs 102 and the UEs 104 may support different frame structures. In some implementations, such as in 4G, the NEs 102 and the UEs 104 may support a single frame structure. In some other implementations, such as in 5G and among other suitable radio access technologies, the NEs 102 and the UEs 104 may support various frame structures (e.g., multiple frame structures). The NEs 102 and the UEs 104 may support various frame structures based on one or more numerologies.

[0043] One or more numerologies may be supported in the wireless communications system 100, and a numerology may include a subcarrier spacing and a cyclic prefix. A first numerology (e.g., / r=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first numerology (e.g., / r=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one slot per subframe. A second numerology (e.g., / r=l) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g., / r=2) may be associated with a third subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth numerology (e.g., / r=3) may be associated with a fourth subcarrier spacing (e.g., 120kHz) and a normal cyclic prefix. A fifth numerology (e.g., / r=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.

[0044] A time interval of a resource (e.g., a communication resource) may be organized according to frames (also referred to as radio frames). Each frame may have a duration, for example, a 10 millisecond (ms) duration. In some implementations, each frame may include multiple subframes. For example, each frame may include 10 subframes, and each subframe may have a duration, for example, a 1 ms duration. In some implementations, each frame may have the same duration. In some implementations, each subframe of a frame may have the same duration.

[0045] Additionally or alternatively, a time interval of a resource (e.g., a communication resource) may be organized according to slots. For example, a subframe may include a number (e.g., quantity) of slots. The number of slots in each subframe may also depend on the one or more numerologies supported in the wireless communications system 100. For instance, the first, second, third, fourth, and fifth numerologies (e.g., / r=0, jU=l, / r=2, jU=3, / r=4) associated with respective subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single slot per subframe, two slots per subframe, four slots per subframe, eight slots per subframe, and 16 slots per subframe, respectively. Each slot may include a number (e.g., quantity) of symbols (e.g., OFDM symbols). In some implementations, the number (e.g., quantity) of slots for a subframe may depend on a numerology. For a normal cyclic prefix, a slot may include 14 symbols. For an extended cyclic prefix (e.g., applicable for 60 kHz subcarrier spacing), a slot may include 12 symbols. The relationship between the number of symbols per slot, the number of slots per subframe, and the number of slots per frame for a normal cyclic prefix and an extended cyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g., / i =0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

[0046] In the wireless communications system 100, an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands, frequency channels, etc. By way of example, the wireless communications system 100 may support one or multiple operating frequency bands, such as frequency range designationsFR1 (410 MHz - 7.125 GHz), FR2 (24.25 GHz - 52.6 GHz), FR3 (7.125 GHz - 24.25 GHz), FR4 (52.6 GHz - 114.25 GHz), FR4a or FR4-1 (52.6 GHz - 71 GHz), and FR5 (114.25 GHz - 300 GHz). In some implementations, the NEs 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands. In some implementations, FR1 may be used by the NEs 102 and the UEs 104, among other equipment or devices for cellular communications traffic (e.g., control information, data). In some implementations, FR2 may be used by the NEs 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.

[0047] FR1 may be associated with one or multiple numerologies (e.g., at least three numerologies). For example, FR1 may be associated with a first numerology (e.g., / r=0), which includes 15 kHz subcarrier spacing; a second numerology (e.g., / r=l), which includes 30 kHz subcarrier spacing; and a third numerology (e.g., / r=2), which includes 60 kHz subcarrier spacing. FR2 may be associated with one or multiple numerologies (e.g., at least 2 numerologies). For example, FR2 may be associated with a third numerology (e.g., / r=2), which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g., / r=3), which includes 120 kHz subcarrier spacing.

[0048] Figure 2 illustrates an example of a framework for proxying encrypted packets. Figure 2 shows a system 200 comprising an Extended Reality Application Function (XR AF) 210, a Policy and Control Function (PCF) 215, a Session Management Function (SMF) 220, an Access and Mobility Function (AMF) 225, a Radio Access Network (RAN) 230, a User Equipment (UE) 235, a User Plane Function (UPF) 240, and an Extended Reality Video Application server 245. The operation of system 200 is described in the example of downlink traffic, and a similar process may operate for uplink traffic. At 280, the XR AF 210 determines PDU-set requirements. With reference to Figure 2, a general syntax and PDU format is now described.

[0049] Internet Protocol (IP) PDUs at an N6 reference point include a transport QUIC underlaying layer of an encapsulation tunnel, e.g., connect-udp, established between a UPF and an AS.

[0050] A Service Data Unit (SDU) of the QUIC packet comprises (e.g., once the connect- udp request completes successfully with a successful response) QUIC datagrams of Frame Type 0x30 when Length field is absent and the datagram extends to the end of the QUIC SDU, or alternatively, 0x31 when the Length field is present and the datagram does not extend to the end of the QUIC SDU. The QUIC datagram encapsulates a HyperText Transfer Protocol (HTTP) Datagram (e.g., an HTTP / 3 datagram). The HTTP Datagram comprises a Quarter Stream ID which enables multiplexing of logically connected HTTP datagrams over the same HTTP / 3 connection, and the HTTP datagram payload.

[0051] Figure 3 shows an example of a PDU set marking (302) and UDP pay load (304) within the HTTP Datagram (306). In the example shown, the HTTP Datagram (306) is an HTTP / 3 Datagram. With reference to Figures 2 and 3, the HTTP Datagram Payload (308) may further comprise a Context Identifier (ID) (310) and the UDP Payload (304), which may be a UDP Proxying Payload. The UDP Proxying Payload may comprise application UDP payload (potentially encrypted) and an extension to the UDP payload (304), where the extension augments the UDP payload (304) with additional Media Related Information, e.g., for PDU Set information. The Context ID (310) may be a variable length integer between (0 to 2A62-1) that determines the semantics of the proxied payload. The Context ID (310) may be registered (potentially dynamically) between an HTTP / 3 client and a UDP proxy to determine the known semantics of the UDP Proxying Payloads for the UDP tunnel. In other words, Figure 3 illustrates an example wire format for an IP PDU encapsulated over connect- udp over N6. The PDU Set marking (302) may be an example of 3 GPP Media Related Information. The UDP Pay load (304) may be an application UDP payload, e.g., part of or an entire video frame or slice.

[0052] Figure 4 shows a PDU set marking illustrating syntax and semantics for encapsulation (400). The HTTP datagram payload (308) of Figure 3 may be determined based on the Context ID (310), where the Context ID (310) may be a 62-bit integer (0 to 2A62-1), and may be encoded as a variable-length integer indicating the format, syntax and semantics of the HTTP datagram payload (308) and of the PDU Set marking (302). The PDU Set marking (302) may follow the syntax and semantics for encapsulation (400) over the wire within RTP Header Extensions.

[0053] The fields in Figure 4 may be described as follows: E (1 Bit) (402) represents End PDU of the PDU Set; R (2Bits) (404) represents Reserved; D (IBit) (406) represents End of Data Burst; PSI (4Bits) (408) represents PDU Set Importance; PSSN (lOBits) (410) represents PDU Set Sequence Number; PSN (6Bits) (412) represents PDU Sequence Number within a PDU Set; PSSize (24Bits) (414) represents PDU Set Size; and NPDS (16Bits) (416) represents Number of PDUs in the PDU Set.

[0054] Where plain UDP SDUs are carried and no other special metadata is comprised therein, the Context ID may be ‘O’.

[0055] Figure 5 shows a 3GPP payload (502) and UDP payload (504) within a HTTP / 3 Datagram (506). The HTTP Datagram Payload (508) may comprise a Context ID (510). The Context ID (510) may indicate the 3GPP-specific payload (502), where the 3GPP specific payload (502) may include PDU Set Marking and other information that may be conveyed over the headers of the encapsulation protocol used over the N6 tunnel. The 3GPP payload (502) may include the PDU Set Marking, a Data Burst Size, a Time to Next Burst, Data Boost Indication, or a combination thereof. One or more of these may facilitate support of enhanced XR services. The 3GPP payload has the capacity to include other future metadata provided via the N6 tunnel.

[0056] Figure 6 shows tunnelling over an HTTP / 3 connection and CONNECT requests differentiated by query parameters, in accordance with embodiments described herein. In these and similar embodiments, client UEs / apps may be multiplexed within a single HTTP / 3 connection.

[0057] With reference to Figure 6, a UPF (602) may be configured to establish for each UE (604, 606) and / or application a separate connect-udp tunnel (608, 610) with the AS (612) acting as a UDP proxy. A QoS flow may be configured with connect-udp tunnelling. An HTTP / 3 client at the UPF (602) may issue a CONNECT request on the commonly established HTTP / 3 connection (601) to the AS (612) acting as UDP proxy. The CONNECT requests may include an authority, i.e, IP address, or alternatively FQDN, of the AS acting as UDP proxy, target host address (i.e, target AS IP address, or alternatively FQDN thereof), target port address (e.g., target AS UDP bound port) and any additional elements such as path orquery elements (e.g., a flow identifier, in short a “fid”). The request may trigger the AS (612) acting as UDP proxy to establish a UDP tunnel to the target AS (614) requested.

[0058] Additional elements (e.g., path or query elements), part of the client URI, or alternatively, of the path header element may aid the AS acting as UDP proxy to distinguish between different client CONNECT requests. Such additional elements (e.g., “fid” query element) may not be necessary and the AS (612) acting as UDP proxy may establish a tunnel with each duplicate CONNECT request. Additional authority ports may be used to distinguish and issue different CONNECT requests leading to establishing different tunnels over different connect-udp available ports of the AS (612) acting as a UDP proxy.

[0059] The different tunnels (608, 610) may be distinguishable by different Quarter Stream IDs at the UPF (602) and at the AS (612) acting as UDP proxy as the different tunnels are established by means of different HTTP / 3 CONNECT requests binding the Quarter Stream IDs to their corresponding CONNECT requests stream IDs. Therefore, the different tunnels (608, 610) and corresponding Quarter Stream IDs may distinguish among the different UEs (604, 606) and / or applications.

[0060] The different tunnels (608, 610) may be correspondingly mapped to different UDP ports (616, 618) over the proxied network path as per proxy handling requirements. The AS (612) acting as UDP proxy may also utilize a same UDP proxying port to different target paths (e.g., different target AS and / or target AS ports). In effect, the AS (612) acting as UDP proxy and the target AS (614) may be able to distinguish different traffic flows across different UEs and / or applications based on different 4-tuples (620, 622), which are shown in Figure 6.

[0061] The CONNECT HTTP / 3 requests from the UPF (602) to the AS (612) acting as UDP proxy to establish a connect-udp different tunnels for two UEs / apps (604, 606) may be different based on a query, or alternatively, path parameter, e.g., “fid”. Examples are set out below:

[0062] Example 1: UPF request corresponding to UE1 (or alternatively APP1) tunnel (a first tunnel):CONNECT https : / / proxy. example . org : 4443 / masque?h=xr . example. org&p=4000&fid=f id-value#lHEADERS: method = CONNECT: protocol = connect-udp: scheme = https: path = / masque?h=xr. example . org&p=4000&fid=fid-value#l: authority = proxy. example. org: 4443Example 2: UPF request corresponding to UE2 (or alternatively APP1) tunnel (a second tunnel):CONNECT https : / / proxy . example . org : 4443 / masque ?h=xr . example . org&p=4000&f id=f id-value#2HEADERS: method = CONNECT: protocol = connect-udp: scheme = https: path = / masque?h=xr. example . org&p=4000&fid=fid-value#2: authority = proxy. example. org: 4443Example 3: UPF request corresponding to UE1 (or alternatively APP1) tunnel (a first tunnel):CONNECT https : / / proxy . example. org : 4443 / masque / udp / xr. example .org / 4000 / fid- value#l / HEADERS: method = CONNECT: protocol = connect-udp: scheme = https: path = / masque / udp / xr . example. org / 4000 / fid-value#l / : authority = proxy. example. org: 4443Example 4: UPF request corresponding to UE2 (or alternatively APP1) tunnel (a second tunnel):CONNECT https : / / proxy . example. org : 4443 / masque / udp / xr. example .org / 4000 / fid- value#2 / HEADERS: method = CONNECT: protocol = connect-udp: scheme = https: path = / masque / udp / xr . example. org / 4000 / fid-value#2 / : authority = proxy. example. org: 4443

[0063] The examples are combinable. The “fid” path parameter of the examples set out above may be described as a flow identifier for both the UPF (602) and AS (612) acting as UDP proxy. A flow identifier may uniquely identify a proxied flow over a connect-udp tunnel. The “fid” values may be assigned in implementations as Universal Unique Identifiers (UUIDs) or any other identifier generation scheme.

[0064] Figure 7 shows tunnelling over an HTTP / 3 connection and CONNECT requests differentiated by authority port numbers, in accordance with embodiments described herein.

[0065] With reference to Figure 7, CONNECT HTTP / 3 requests from a UPF (702) to an AS (712) acting as UDP proxy to establish different connect-udp tunnels (708, 710) for two UEs / apps (704, 706) are different based on different authority (AS (712) acting as UDP proxy) ports (e.g., :44301 vs. :44302) (724, 726). Examples are set out below:Example 5: UPF request corresponding to UE1 (or alternatively APP1) tunnel (a first tunnel):CONNECT https : / / proxy . example. org: port l / masque?h=xr. example . org&p=4000HEADERS: method = CONNECT: protocol = connect-udp: scheme = https: path = / masque?h=xr . example . org&p=4000: authority = proxy. example . org : port 1Example 6: UPF request corresponding to UE1 (or alternatively APP2) tunnel (a second tunnel):CONNECT https : / / proxy . example. org: port 2 / masque?h=xr. example . org&p=4000HEADERS: method = CONNECT: protocol = connect-udp: scheme = https: path = / masque?h=xr . example . org&p=4000 authority = proxy. example . org : port 2Example 7: UPF request corresponding to UE1 (or alternatively APP1) tunnel (a first tunnel):CONNECT https : / / proxy . example . org : portl / masque / udp / xr . example . org / 4000 / HEADERS: method = CONNECT: protocol = connect-udp: scheme = https: path = / masque / udp / xr . example. org / 4000 / authority = proxy. example . org : port 1Example 8; UPF request corresponding to UE2 (or alternatively APP2) tunnel (a second tunnel):CONNECT https : / / proxy . example . org : port2 / masque / udp / xr . example . org / 4000 / HEADERS: method = CONNECT: protocol = connect-udp: scheme = https: path = / masque / udp / xr . example . org / 4000 / : authority = proxy. example . or : port 2

[0066] Separating client flows by different CONNECT requests over a single HTTP / 3 connection (701) maps the different CONNECT request and their correspondingly created tunnels (708, 710) to the individual flows of client UEs / apps (704, 706). This may be achieved by means of different Quarter Stream IDs (QSIDs) corresponding to each different tunnel (708, 710) established by the different CONNECT requests. The different CONNECT requests may contain different ports (724, 726) as set out in the examples of 5-8 and shown in Figure 7 or different query parameters (or flow parameters, “fid”) as set out in Examples 1-4 and shown in Figure 6.

[0067] Figure 8 shows tunnelling over an HTTP / 3 connection and CONNECT requests differentiated by authority port numbers mapped to different tunnels, in accordance with embodiments described herein.

[0068] With reference to Figure 8, different QSIDs (e.g., different tunnels) (808, 810, 81 On) over the same HTTP / 3 connection (801) may be mapped to different client UEs / apps (804, 806, 806n) data flows, and respectively, to different ports (830, 832, 832n) of the AS (812) acting as UDP proxy. Differentiation of tunnelled and proxied traffic among different UEs (804, 806, 806n) and / or applications based on multiple tunnels (808, 810, 81 On) and separate CONNECT requests is thereby enabled. The separate CONNECT requests may be differentiated by authority port numbers mapped to different tunnels (e.g., QSIDs 1-N mapped to tunnels #1-#N for flows #1-#N) corresponding to different UEs / apps (e.g., UEs 1-N).

[0069] Figure 9 illustrates tunnelling over an HTTP / 3 connection using 3GPP-specific identifiers, in accordance with embodiments described herein. In these embodiments, theremay be a common tunnel for different UEs / apps with different Context ID differentiation within CN.

[0070] A UPF (902) may be configured to establish a common connect-udp tunnel (908) for all UEs (904, 906) and / or applications with the AS (912) acting as UDP proxy, as shown in Figure 9. An example request establishing the common tunnel (908) between the UPF (902) and the AS (912) acting as UDP proxy for all UEs (904, 906) and / or applications is provided below:Example 9: CONNECT request for user-Zapp-common connect-udp tunnel between UPF and the AS acting as UDP proxyCONNECT https : / / proxy . example . org : 4443 / masque ?h=xr . example . org&p=4000 HEADERS: method = CONNECT: protocol = connect-udp: scheme = https: path = / masque?h=xr . example . org&p=4000: authority = proxy. example. org: 4443

[0071] The common tunnel (908) may include different Context IDs (934, 936). Each of the Context IDs (934, 936) may correspond to a UE (904, 906) and / or application. The different Context IDs (934, 936) may therefore be used by the UPF (902) to distinguish and differentiate among flows corresponding to different UEs (904, 906) and / or applications. In such a case, the UPF (902) may issue a single CONNECT request (as per Example 9 above) on the commonly established HTTP / 3 connection (901) to the AS (912) acting as UDP proxy. The CONNECT request may establish a single connect-udp shared across all UEs (904, 906) and / or applications proxied.

[0072] A Context ID value may be set as any non-zero odd-numbered value and may include a flow identification component (e.g., a flow identifier) matched to a corresponding application data flow corresponding to a UE (904, 906) and / or an application. An odd- numbered value may be used when the Context ID is allocated by the AS (912) acting as UDP proxy.

[0073] Figure 10 shows a Context ID format, in accordance with embodiments described herein. The Context ID may be for differentiating tunnelled and proxied traffic among different UEs and / or applications based on a common tunnel and Context ID.

[0074] The Context ID (1002) may contain any non-zero odd-numbered value (1004) and an additional flow identification component (1006), e.g., the flow identifier, or alternatively, a Flow ID (1008). The non-zero odd-numbered value (1004) may occupy a first part field (1010) representation of the Context ID and identify the proxying payload semantics. The additional identifier may represent a second part field (1006) distinguishing and identifying a flow of a UE and / or app. The UPF may be configured to associate the flow identifier (1008) with a QoS flow by N4 rules shared, or alternatively updated, by an SMF for the connect-udp tunnel. The flow identifier (1008) may be set by a unique ID generation scheme (e.g., derived from or part of a UUID).

[0075] The UPF may use the Context ID (1004) to distinguish and route traffic flows tunnelled over the connect-udp protocol to their corresponding UEs and / or applications. As shown in Figure 9, the UPF (902) may route a first Context ID (934) to a first client UE (904), and a second (different) Context ID (936) to a second client UE (906) as instructed by the SMF N4 rules. Where the proxying payload semantics are the same among clients / applications, a first Context ID (934) and a second Context ID (936) may be different but share a common part, for example, the first part (1010) as shown in Figure 10, which may correspond to the same semantics of the UDP proxying payload.

[0076] Figure 11 shows tunnelling over an HTTP / 3 connection using 3GPP-specific identifiers. Figure 12 shows a Flow Identifier, PDU set marking and UDP payload within an HTTP / 3 datagram. Figure 13 shows a 3 GPP-specific payload header and UDP payload. Figure 14 shows a Format Identifier in octet form. Embodiments are described below with reference to Figures 11-14.

[0077] The UPF (1102) may be configured to establish a common connect-udp tunnel for all UEs (1104, 1106) and / or applications with the AS (1112) acting as UDP proxy. The UPF (1102), AS (1112) acting as UDP proxy, and target AS (1114) connect-udp network entities may be further configured, as shows in Figure 11, to utilize a single, common Context ID (1134) over the common tunnel (1108) and over the commonly established HTTP / 3connection (1101). The common Context ID (1134) may identify a common, single semantic of the UDP proxying payload (1204, 1304). The Context ID (1134) may be assigned any non-zero odd-numbered value. The choice of the odd-numbered value may be due to the Context ID (1134) being allocated by the AS (1112) acting as UDP proxy.

[0078] The UDP proxying payload (1204, 1304) may include, as illustrated in Figures 12 and 13, a first 3 GPP-specific part (1302) formed of one or more fields followed by a second part, representing the UDP payload (1204, 1304). The first 3GPP-specifc part (1302) may considered as a 3 GPP-specific payload, or alternatively, a 3 GPP-specific header of the UDP proxying payload (1204, 1304), and may include one or more fields, among which at least one may encapsulate an identifier (1206, 1306) of the traffic flow. The 3 GPP-specific identifier (1206, 1306) of the traffic flow may identify and map particular application data flows to the corresponding client UEs / apps (1104, 1106) behind the UPF (1102). Similarly, the 3GPP-specific identifier (1206, 1306) may be used by the AS (1112) acting as a UDP proxy and / or the target AS (1114) to distinguish and multiplex traffic originating from the same client UPF (1102) to the same target AS (1114) (e.g., the same client UEs / apps being serviced by the same target AS for the same service or application). The 3GPP-specific identifier (1206, 1306) for a traffic flow be described as a “flow identifier”. The flow identifier may be commonly used by the UPF (1102), AS (1112) acting as UDP proxy, and / or target AS (1114) to differentiate among traffic flows of different UEs (1104, 1106) and / or applications that are multiplexed over the same HTTP / 3 (1101) connection and / or same tunnel (1108) corresponding to a connect-udp session configuration, as illustrated in Figure 11.

[0079] The UPF (1102) may apply the 3GPP-specific identifier (1206, 1306), e.g., the flow identifier, to route the UDP proxying payloads (1204, 1304) to / from their corresponding client UEs (1104, 1106) and / or applications QoS flows across the CN. The AS (1112) acting as UDP proxy may multiplex the tunnelled flows on the same UDP port to the target AS (1114). The target AS (1114) may utilize the 3GPP-specific identifier (1206, 1306) and / or the flow identifier to multiplex / demultiplex packets belonging to different UEs (1104, 1106) and / or applications flows. The value of the 3GPP-specific identifier (1206, 1306) may be set by the target AS (1114) and configured to the UPF (1102) (e.g., by means of SMF N4 rulesindications or updates to the connect-udp tunnel configuration). Furthermore, because of recurring to a flow identifier to distinguish among different application data flows, the Context ID (1134, 1208) and semantics of the HTTP datagram payload (1210) may be kept same across all multiplexed application data flows. A single common Context ID (1134, 1208) may then be registered among all proxied UDP traffic flows.

[0080] The second part, the UDP payload (1204, 1304), may be further encrypted end- to-end between a target AS (1114) and a UE (1104, 1106). The security context (i.e., cipher suite, keys, nonce, key distribution protocol etc.) may be up to applications’ implementations.

[0081] The first 3GPP-specific part (1302) of the UDP proxying payload, i.e., 3GPP- specific payload, or alternatively “header” of the UDP proxying payload, may comprise a Format ID (1312). The Format ID (1312) may be a bitmap field and may further indicate the presence of any 3 GPP-specific Media Related Information elements as part of the 3 GPP- specific header (1302).

[0082] The Format ID (1312) may be the first field of the 3 GPP-specific header (1302). With reference to Figure 14, the Format ID (1312) may be a bitmap represented as (at least) an octet (1402), indicating the presence of different 3GPP-specific information elements as encoded in the UDP proxying pay load (1204, 1304) by either the target AS (1114), in DE, and / or the UE (1104, 1106), in UL. The Format ID (1312) may indicate for instance the presence of following Media Related Information fields: Flow ID field (1404); PDU Set Information field (1406); Data Burst Information (1408) (i.e., End of Data Burst Information, Data Burst Size, Time to Next Burst etc.) field; and Expedited Transfer Indication field (1410). Some bits (1412) of the octet bitmap of the Format ID may be reserved for future use of other 3 GPP-specific information elements.

[0083] Figure 15 shows a process flow of communications between a client (1502), server (1504), and origin (or alternatively, target) server (1506), in accordance with embodiments described herein, particularly, but not exclusively, with embodiments involving multiplexing client UEs / applications by HTTP connections such as HTTP / 3 connections and embodiments where application traffic from the UE is transported using QUIC protocol.

[0084] The multiplexing of client UEs, or alternatively, applications may be done based on establishing different HTTP / 3 connections between the HTTP / 3 client (1502) at the UPF and the AS acting as UDP proxy. Each of the different HTTP / 3 connections may correspond to a client UE, or alternatively, an application connection, carrying application data flow for the client UE, or alternatively, the application. In effect, each HTTP / 3 connection may comprise a connect-udp tunnel encapsulating the application data flow traffic of a separate client UE, or alternatively, application.

[0085] To establish different HTTP / 3 connections to the same AS acting as UDP proxy, the UPF as HTTP / 3 client (1502) may use different TLS 1.3 configuration for each connection to establish different underlying QUIC connections. The different TLS 1.3 configuration may include any of a different cipher suite configuration, a different client certificate or a different set of secrets for the QUIC encryption configuration.

[0086] The process flow may implement or be implemented by embodiments described above, such as by a UPF, an AS, and a target server. Additionally, the process flow may implement or be implemented by aspects of the wireless communication system 100. The process flow may include one or more of the following steps, which detail an HTTP / 3 connection establishment procedure using QUIC. The process flow may be referred to as a procedure, including one or more operations performed by one or more of the client (1502), the server (1504), and the origin server (1506). In the following description of the process flow, the operations or signalling performed between one or more of the client (1502), the server (1504), and the origin server (1506) may be performed or signalled (e.g., transmitted, received) in a different order than the example order shown, or the operations or signalling performed by one or more of the client (1502), the server (1504), and the origin server (1506) may be performed or signalled (e.g., transmitted, received) in different orders or at different times. Some operations or signalling may also be omitted from the process flow. Additionally, although some operations or signalling may be shown to occur at different times, these operations or signalling may occur at the same time or in overlapping time periods.

[0087] 1. (1508): A QUIC connection is started by the client that sends an Initial QUIC packet containing at least a CRYPTO frame including the TLS ClientHello. The ClientHellomay include as per TLS1.3 the maximum TLS supported, list of cipher suites supported, client random and TLS extensions. One TLS extension may comprise the Server Name Indication extension pointing the HTTP / 3 server (1504) to the origin server (1506) name (e.g., proxy.example.org). A second TLS extension may comprise ALPN to negotiate the QUIC application layer protocol as “h3” for HTTP / 3. A third TLS extension may comprise a Key Share for exchanging one or more client ephemeral public keys for securing the rest of the TLS exchange after the TLS ClientHello / ServerHello based on a client selected set of cipher suites (e.g., x25519 client public key for key exchange based on curve25519). A fourth TLS extension may comprise a TLS supported version indicating support of TLS 1.3. A fifth TLS extension may comprise QUIC transport parameters (e.g., max_udp_payload_size: 65527, initial_max_data: 10485760, initial_max_stream_data_bidi_local: 1048576, initial max stream data bidi remote: 1048576, initial max stream data uni: 1048576, initial max streams bidi: 12, initial max streams uni: 12, etc.). The client Initial QUIC packet may contain the Source Connection ID to be used by the server and a random Destination Connection ID. The random Destination Connection ID may be used as keying material for packet protection of the Initial packets of the client (1502) and the server (1504).

[0088] 2. (1510): The server (1504) may respond to the QUIC client Initial packet comprising the ClientHello with its own Initial QUIC packet. The server (1504) may establish the Initial keys based on the Destination Connection ID received from the client Initial QUIC packet. The server Initial QUIC packet may comprise the Source Connection ID (to be used further by the client (1502) when sending QUIC packets on this connection), Destination Connection ID (reused Source Connection ID value of the client Initial QUIC packet) and at least a CRYPTO frame and Initial packet ACK frame. The ACK frame may acknowledge the receipt of the client QUIC Initial packet within the Initial packet numbering namespace. The CRYPTO frame may enclose the TLS ServerHello indicating TLS parameters such as server chosen TLS version (e.g., TLS1.3), cipher suite, server random and TLS extensions. One TLS extension may comprise a Key Share indicating the server public key for securing the rest of the TLS handshake (e.g., x25519 server public key for key exchange based on curve25519) after ClientHello / ServerHello. The server (1504) may then compute the Handshake keys based on the TLS Key Share extensions and send back the TLS Handshake. The TLS Handshake may be part of the QUIC Handshake packet and includedwithin at least one CRYPTO frame. The CRYPTO frame may encapsulate therefore the encrypted TLS Handshake including at least TLS encrypted extensions (EE) (i.e., ALPN, e.g., “h3” and QUIC transport parameters, e.g., original destination connection id: <value_set_to_client_indicated_destination_connection_id>, max idie timeout: 120000ms (2 minutes), max_udp_payload_size: 65527, initial_max_data: 5242880, initial max stream data bidi local: 524288, initial max stream data bidi remote:524288, initial_max_stream_data_uni: 524288, initial_max_streams_bidi: 16, initial max streams uni: 4, ack delay exponent: 3 etc.), server TLS certificate for authentication (CERT), certificate verify message (i.e., hash of all TLS handshake messages) signed by the server private key corresponding to the server certificate, and the TLS Handshake finished (FIN) message. The FIN message may verify that the handshake was successful and not tampered with, by verification data that client may later confirm. The verification data may be built from a hash of all handshake messages authenticated based on the TLS Exchange key derived by the server.

[0089] 3. (1512): The client (1502) may receive the server QUIC Initial packet and determine the TLS Exchange keys based at least on the TLS Key Share extension and determine the rest of the TLS configuration parameters. The client (1502) may then decrypt and process the server QUIC Handshake packet and corresponding TLS Handshake. After verifying the TLS Handshake integrity, the client (1502) has all necessary data to derive the TLS and QUIC transport secret keys for the TLS session, and respectively, for the QUIC connection. The TLS key derivation for the TLS sessions may be performed based on HKDF- Extract and HKDF-Expand-Label operations for the Master Secret. The QUIC connection packet protection and header protection keys may be derived based on a TLS key derivation procedure. This operation yields the QUIC connection client / server keys and Initialization Vectors (I Vs): client key = HKDF-Expand-Label(key: client secret, label: "quic key", ctx: len: 16); server key = HKDF-Expand-Label(key: server secret, label: "quic key", ctx: len: 16); client iv = HKDF-Expand-Label(key: client secret, label: "quic iv", ctx: len: 12); server_iv = HKDF-Expand-Label (key: server_secret, label: "quic iv", ctx: len: 12); client hp key = HKDF-Expand-Label(key: client secret, label: "quic hp", ctx: len: 16);and server hp key = HKDF-Expand-Label(key: server secret, label: "quic hp", ctx: len: 16) based on the TLS client, i.e., client_secret, and server, i.e., server_secret, security primitives. At this point, the client (1502) may acknowledge via QUIC Initial and Handshake packets the server QUIC Initial and Handshake packets received. A client QUIC Handshake packet may include further a CRYPTO frame carrying the TUS Handshake Finished (FIN) to verify that the handshake was successful and not tampered with. The client verification data may be built from a hash of all handshake messages and signed based on the client secret key of the TUS Handshake. The server (1504) may confirm the FIN message. At this point, the client (1502) may send application layer data if it chooses to do so using the QUIC packet protection mechanism and 1-RTT keys. For example, in case of H3 AUPN, the client (1502) may already open its control stream and indicate to the server (1504) its H3 configuration parameters via the SETTINGS frame.

[0090] 4. (1514): The server (1504) may decrypt the client QUIC Handshake packet and verify the client TLS Handshake Finished message. Once the handshake is verified and so completed, the server (1504) may acknowledge with a QUIC Handshake packet the client last Handshake packet. In addition, the server (1504) may similarly derive TLS and QUIC connection client / server keys and IVs as the client such that it can decrypt and process any client 1-RTT packet and / or send any 1-RTT packet to the client (1502). For example, in case of HTTP / 3, the server (1504) may decrypt the client-originating control stream comprising the client SETTINGS HTTP / 3 frame and simultaneously open its own control stream and send to the client (1502) its HTTP / 3 configuration parameters and constraints via a SETTINGS frame. The 1-RTT encapsulating the control stream may further include a QUIC ACK frame acknowledging the original client 1-RTT packet.

[0091] 5. (1516): At this point the communication between client (1502) and server(1504) may follow based on HTTP / 3 semantics or extensions such as connect-udp protocol. For example, the client (1502) may open a connect-udp tunnel within the established HTTP / 3 connection via a CONNECT request. The CONNECT request may be sent on a new bidirectional client-initiated STREAM within the QUIC Connection, corresponding to a HTTP / 3 request-response client-server interaction. An example request could be:CONNECT https : / / proxy . example . org : 4443 / masque ?h=xr . example . org&p=4000HEADERS: method = CONNECT: protocol = connect-udp: scheme = https: path = / masque?h=xr . example . org&p=4000: authority = proxy. example . org : 4443

[0092] 6. (1518): The HTTP / 3 server (1504) may receive the CONNECT request and upon resolving the target host and port may open a UDP socket connection to the determined target host IP address and port. Next, the HTTP / 3 server (1504) may respond to the client (1502) with a HTTP Success code 2xx indicating to the client (1502) that the requested connect-udp tunnel has been established. The server response may leave the request bidirectional stream open, and the connect-udp tunnel Quarter Stream ID may be assigned the original request Stream ID divided by 4. The bi-directional traffic may be tunnelled over HTTP Datagrams which may be transported in QUIC DATAGRAM frames and may not use directly at QUIC transport level the request STREAM that created the tunnel.

[0093] 7. (1520): At this point data may flow over the tunnel in both directions between the HTTP / 3 client (1502) and HTTP / 3 server (1504). The HTTP / 3 server (1504) may act as a proxy tunnelling UDP traffic to / from an origin server (1506).

[0094] A UPF, acting as a HTTP / 3 client (1502), may establish therefore a virtually infinite number of HTTP / 3 connections to the same AS HTTP / 3 server (1504) acting as UDP proxy. Each HTTP / 3 connection may encapsulate its own connect-udp tunnel, multiplexing client UEs / applications at the level of HTTP / 3 connections. Each HTTP / 3 connection may be therefore established based on different TLS configurations, such that each new HTTP / 3 connection requires a new client certificate, or alternatively public-private key pair for the QUIC handshake and connection establishment. The UPF may provide and map such client certificates to each new HTTP / 3 connection of a client UE and / or app. The handling and generation of client public-private key pair may be up to UPF implementation.

[0095] Similar steps may be appropriate if the server (1504) chooses to issue a token and QUIC Retry packet to ensure client address validation by means of the server token, and that the client (1502) may access server resources. In such a case, the client QUIC Initial packet may not be acknowledged by the server (1504) which may send a QUIC Retry with a tokenfor the client for initial access. The client (1502) may then issue a new QUIC Initial packet including the token, after which the steps previously detailed above and shown in Figure 15 follow similarly.

[0096] The HTTP / 3 AS (1504) acting as UDP proxy may employ peer authentication. The AS (1504) may request the client (1502) to authenticate during the handshake and may refuse a connection if the client (1502) is unable to authenticate when requested. The server (1504) may request client authentication only during TLS handshake. The request may follow by means of a server TLS CertificateRequest embedded into the TLS Handshake as part of the Server Parameters. This corresponds to the CertificateRequest being part of Step 2 above. The client (1502) may follow in the TLS Handshake response with its own TLS Certificate and CertificateVerify message, similarly to the certificate authentication procedures applicable to the server (1504). In effect, the additional client certificates may be part of the QUIC Handshake packet(s) of Step 3. The server (1504) may then complete client authentication during the TLS Handshake phase as desired for a HTTP / 3 connection. The client certificates may be different for each HTTP / 3 connection established.

[0097] Embodiments described herein that relate to different tunnels over a single HTTP / 3 connection and / or different HTTP / 3 connections each with its own tunnel are readily applicable to other encapsulation protocols based on HTTP Datagrams encapsulation that act as multiplexed application substrate over QUIC encryption (MASQUE). As a result, the encapsulation protocol connect-udp may be replaced by connect-ip or connect-ethernet. In both scenarios, the tunnel between the HTTP / 3 client (1502) and HTTP / 3 server (1504) acting as proxy may be established by similar extended CONNECT requests and may be based on HTTP Datagram encapsulation over QUIC Datagrams when HTTP / 3 is used. However, in embodiments relating to connect-ip, the proxying to a target server (1506) may be done at IP (L3) Layer instead of UDP (L4 / Transport) Layer. In embodiments relating to connect-ethernet, the proxying to a target node in the network may be done at Ethernet (L2) Layer instead of UDP (L4 / Transport) Layer.

[0098] Following embodiments are described that may fall into a scenario as described as follows: Scenario 1 : The UE may establish an end-to-end QUIC connection with the target AS where the QUIC traffic is routed via a 3 GPP network function, i.e., via a UPF based onan encapsulation tunnel. The UPF may not be QUIC-aware relative to the E2E traffic; and Scenario 2: The UE may establish an end-to-end QUIC connection with the target AS where the QUIC traffic is routed via a 3 GPP network function, i.e., via a UPF, based on an encapsulation tunnel. The UPF may be QUIC-aware relative to the E2E traffic and may establish a QUIC-aware connection for the encapsulation tunnel with an AS acting as QUIC- Aware proxy. The QUIC-aware proxy connection may indicate the AS acting as QUIC-aware proxy the target AS address (or FQDN) as the end point address (or FQDN). The indication may be based on the extended CONNECT HTTP semantics over HTTP / 3 wherein the path of the CONNECT request comprises the necessary path information including target and authority information as shown below:CONNECT https : / / quic- aware- proxy . example . org : 4443 / masque ?h=xr . example . org&p=4000 HEADERS: method = CONNECT: protocol = connect-udp: scheme = https: path = / masque?h=xr . example . org&p=4000 (target AS host and port) : authority = quic -aware-proxy. example . org :4443

[0099] In both of the above scenarios the UPF (acting as an HTTP / 3 client) may establish a connect-udp tunnel with the AS (acting as an HTTP / 3 proxy) and use the tunnel to multiplex traffic from different UEs and / or applications towards the target AS.

[0100] In both scenarios, when the UE establishes a QUIC connection E2E with the target AS, the QUIC client in the UE may assign a QUIC Connection ID for the connection. In both scenarios, the QUIC Connection ID field may be visible at the UPF as this parameter may not be encrypted in the QUIC headers.

[0101] For embodiments falling into scenario 1, the UPF may use the Connection ID field to separate traffic of each UE and map the QUIC traffic to a separate Quarter Stream ID over the connect-udp tunneled connection between the UPF and AS acting as UDP proxy based on the principles described previously. This corresponds to a realization scenario wherein the QUIC E2E traffic is simply tunneled between the UPF and AS acting as UDP proxy to the target AS.

[0102] For embodiments falling into scenario 2, the UPF may use the Connection ID fields (i.e., including both Source and Destination Connection IDs) to separate traffic of each UE and map the QUIC traffic to a Virtual Connection IDs over the same Quarter Stream ID stream over the connect-udp tunnel connection between the UPF and the AS acting as QUIC- aware proxy.

[0103] A basic call flow for scenario 1 may be as described below:

[0104] 0. The UPF may be configured by N4 rules to encapsulate E2E QUIC traffic between a first UE and a target AS over an encapsulation protocol tunnel (i.e., connect-udp) to an AS acting as UDP proxy.

[0105] 1. The UE may establish a QUIC connection with the target AS via the encapsulation protocol tunnel. The connection may be assigned QUIC Connection ID (i.e., a client-side Connection ID and a target AS-side Connection ID). The QUIC traffic may be carried over the connect-udp tunnel between the UPF and AS acting as UDP proxy.

[0106] 2. The UPF based on N4 rules may be aware of the connect-udp tunnel encapsulation to the AS acting as UDP proxy. As a result, it may map the Connection IDs (e.g., the client-server QUIC Connection IDs assigned) to the tunnel specific Quarter Stream ID.

[0107] 3. When a second UE for which N4 rules are similarly configured at the UPF(i.e., to tunnel traffic to the target AS via a proxy AS acting as UDP proxy) establishes a QUIC connection with the target AS, the QUIC connection similarly may be assigned a QUIC Connection ID. The QUIC traffic may be carried over another connect-udp tunnel between the UPF and AS acting as UDP proxy.

[0108] 4. The UPF based on N4 rules may be aware that traffic is to be sent via a second connect-udp tunnel to the target AS. Consequently, the UPF may map the Connection IDs (e.g., the client-server QUIC Connection IDs assigned) to a second Quarter Stream ID.

[0109] A basic call flow for scenario 2 may be as described below:

[0110] 0. The UPF may be configured by N4 rules to encapsulate E2E QUIC traffic between a first UE and a target AS over an encapsulation protocol tunnel (i.e., connect-udp) to an AS acting as QUIC-aware proxy.

[0111] 1. The UE may establish a QUIC connection with the target AS and via the encapsulation protocol tunnel. The connection may be assigned a QUIC Connection ID (i.e., a client-side Connection ID and a target AS-side Connection ID). The QUIC traffic may be carried over the connect-udp tunnel between the UPF and AS acting as QUIC-aware proxy.

[0112] 2. The UPF based on N4 rules may be aware that traffic between UE and targetAS is to be sent via a connect-udp tunnel to AS acting as QUIC-aware proxy. The UPF may register via Capsule Protocol as per draft-masque-ietf-quic-aware-proxy-04 (e.g., REGIS TER CLIENT CID, REGISTER TARGET CID, ACK CLIENT CID, ACK TARGET CID) the assigned Connection IDs to Virtual Connection IDs. The Virtual Connection IDs may apply to the QUIC-aware encapsulation protocol. These may map E2E QUIC Connection IDs (i.e., client-side Connection ID and server Connection IDs) to Virtual Connection IDs over the UPF to AS acting as QUIC-aware proxy connect-udp tunnel for a specific Quarter Stream ID. Over the connect-udp tunnel between the UPF and AS, the UPF (client) and target AS may negotiate thus as per draft-masque-ietf-quic-proxy-04 via capsule protocol UE and Virtual Connection IDs (VCIDs). The UPF may map them to the UE and target QUIC Connection IDs at its connect-udp tunnel endpoint and may identify the corresponding E2E QUIC traffic.

[0113] 3. When a second UE for which N4 rules are similarly configured at the UPF(i.e., to tunnel traffic to the target AS via a proxy AS acting as QUIC-aware proxy) establishes a E2E QUIC connection with the target AS, the QUIC connection may similarly be assigned a QUIC Connection ID. The QUIC traffic may be carried over another connect-udp tunnel with QUIC-awareness between the UPF and the AS acting as QUIC-aware proxy.

[0114] 4a. The UPF based on N4 rules may be aware that traffic of the second UE is to be sent via the same connect-udp tunnel to the target AS. Consequently, the UPF may map the assigned Connection IDs (e.g., the client-server QUIC Connection IDs assigned) to a second pair of Virtual Connection IDs over the UPF to the AS acting as QUIC-aware proxyconnect-udp tunnel over the same Quarter Stream ID used in step 2. As per step 2, the second pair of Virtual Connection IDs may be negotiated by the UPF and target AS.

[0115] 4b. The UPF based on N4 rules may be aware that traffic of the second UE is to be sent via a second connect-udp tunnel to the target AS. Consequently, the UPF may map the assigned Connection IDs (e.g., the client-server QUIC Connection IDs assigned) to a second pair of Virtual Connection IDs over the UPF to the AS acting as QUIC-aware proxy on a second connect-udp tunnel and over a corresponding second Quarter Stream ID. As per step 2, the second pair of Virtual Connection IDs may be negotiated by the UPF and target AS.

[0116] For embodiments falling into either scenario, the UPF may be able to determine QUIC Connection IDs changes and remap the QUIC connection to the same (or alternatively, corresponding) Quarter Stream ID over the connect-udp tunnel.

[0117] For embodiments falling into scenario 2, if the UPF cannot negotiate Virtual Connection IDs, the UPF may forward the UE QUIC stream via a separate Quarter Stream ID over the same connect-UDP tunnel towards the target AS, or alternatively, a second connect-udp tunnel towards the target AS (i.e., and fallback to scenario 1).

[0118] Figure 16 illustrates an example of a UE 1600 in accordance with aspects of the present disclosure. The UE 1600 may include a processor 1602, a memory 1604, a controller 1606, and a transceiver 1608. The processor 1602, the memory 1604, the controller 1606, or the transceiver 1608, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0119] The processor 1602, the memory 1604, the controller 1606, or the transceiver 1608, or various combinations or components thereof may be implemented in hardware (e.g., circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

[0120] The processor 1602 may include an intelligent hardware device (e.g., a general- purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof). In some implementations, the processor 1602 may be configured to operate the memory 1604. In some other implementations, the memory 1604 may be integrated into the processor 1602. The processor 1602 may be configured to execute computer-readable instructions stored in the memory 1604 to cause the UE 1600 to perform various functions of the present disclosure.

[0121] The memory 1604 may include volatile or non-volatile memory. The memory 1604 may store computer-readable, computer-executable code including instructions when executed by the processor 1602 cause the UE 1600 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 1604 or another type of memory. Computer-readable media includes both non- transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or specialpurpose computer.

[0122] In some implementations, the processor 1602 and the memory 1604 coupled with the processor 1602 may be configured to cause the UE 1600 to perform one or more of the functions described herein (e.g., executing, by the processor 1602, instructions stored in the memory 1604). For example, the processor 1602 may support wireless communication at the UE 1600 in accordance with examples as disclosed herein. The UE 1600 may be configured to support the arrangements described herein.

[0123] The controller 1606 may manage input and output signals for the UE 1600. The controller 1606 may also manage peripherals not integrated into the UE 1600. In some implementations, the controller 1606 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 1606 may be implemented as part of the processor 1602.

[0124] In some implementations, the UE 1600 may include at least one transceiver 1608. In some other implementations, the UE 1600 may have more than one transceiver 1608. The transceiver 1608 may represent a wireless transceiver. The transceiver 1608 may include one or more receiver chains 1610, one or more transmitter chains 1612, or a combination thereof.

[0125] A receiver chain 1610 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 1610 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 1610 may include at least one amplifier (e.g., a low-noise amplifier (LN A)) configured to amplify the received signal. The receiver chain 1610 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 1610 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0126] A transmitter chain 1612 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 1612 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The transmitter chain 1612 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 1612 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0127] Figure 17 illustrates an example of a processor 1700 in accordance with aspects of the present disclosure. The processor 1700 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 1700 may include a controller 1702 configured to perform various operations in accordance with examples as described herein. The processor 1700 may optionally include at least one memory 1704, which may be, for example, an L1 / L2 / L3 cache. Additionally, or alternatively, the processor 1700 may optionally include one or more arithmetic-logic units (ALUs) 1706. One or more of these components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses).

[0128] The processor 1700 may be a processor chipset and include a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) in accordance with examples as described herein. The processor chipset may include one or more cores, one or more caches (e.g., memory local to or included in the processor chipset (e.g., the processor 1700) or other memory (e.g., random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), static RAM (SRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase change memory (PCM), and others).

[0129] The controller 1702 may be configured to manage and coordinate various operations (e.g., signalling, receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) of the processor 1700 to cause the processor 1700 to support various operations in accordance with examples as described herein. For example, the controller 1702 may operate as a control unit of the processor 1700, generating control signals that manage the operation of various components of the processor 1700. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating timing of operations.

[0130] The controller 1702 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from the memory 1704 and determine subsequent instruct! on(s) to be executed to cause the processor 1700 to support various operations in accordance with examples as described herein. The controller 1702 may be configured to track memory address of instructions associated with the memory 1704. The controller 1702 may be configured to decode instructions to determine the operation to be performed and the operands involved. For example, the controller 1702 may be configured to interpret the instruction and determine control signals to be output to other components of the processor 1700 to cause the processor 1700 to support various operations in accordance with examples as described herein. Additionally, or alternatively, the controller 1702 may be configured to manage flow of data within the processor 1700. The controller 1702 may be configured to control transfer of databetween registers, arithmetic logic units (ALUs), and other functional units of the processor 1700.

[0131] The memory 1704 may include one or more caches (e.g., memory local to or included in the processor 1700 or other memory, such RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc. In some implementations, the memory 1704 may reside within or on a processor chipset (e.g., local to the processor 1700). In some other implementations, the memory 1704 may reside external to the processor chipset (e.g., remote to the processor 1700).

[0132] The memory 1704 may store computer-readable, computer-executable code including instructions that, when executed by the processor 1700, cause the processor 1700 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. The controller 1702 and / or the processor 1700 may be configured to execute computer-readable instructions stored in the memory 1704 to cause the processor 1700 to perform various functions. For example, the processor 1700 and / or the controller 1702 may be coupled with or to the memory 1704, the processor 1700, the controller 1702, and the memory 1704 may be configured to perform various functions described herein. In some examples, the processor 1700 may include multiple processors and the memory 1704 may include multiple memories. One or more of the multiple processors may be coupled with one or more of the multiple memories, which may, individually or collectively, be configured to perform various functions herein.

[0133] The one or more ALUs 1706 may be configured to support various operations in accordance with examples as described herein. In some implementations, the one or more ALUs 1706 may reside within or on a processor chipset (e.g., the processor 1700). In some other implementations, the one or more ALUs 1706 may reside external to the processor chipset (e.g., the processor 1700). One or more ALUs 1706 may perform one or more computations such as addition, subtraction, multiplication, and division on data. For example, one or more ALUs 1706 may receive input operands and an operation code, which determines an operation to be executed. One or more ALUs 1706 be configured with a variety of logical and arithmetic circuits, including adders, subtractors, shifters, and logic gates, to process andmanipulate the data according to the operation. Additionally, or alternatively, the one or more ALUs 1706 may support logical operations such as AND, OR, exclusive-OR (XOR), not-OR (NOR), and not- AND (NAND), enabling the one or more ALUs 1706 to handle conditional operations, comparisons, and bitwise operations.

[0134] The processor 1700 may support wireless communication in accordance with examples as disclosed herein. The processor 1700 may be configured to or operable to support a means for establishing a first connection with a second network entity for data traffic, wherein the data traffic comprises first data associated with a first client entity and second data associated with a second client entity; multiplexing the first data and the second data based at least in part on an identifier associated with the first data or the second data, wherein the multiplexed data comprising the first data and the second data are encapsulated in accordance with a tunnel protocol; and transmitting the multiplexed and encapsulated data to the second network entity via the established first connection. Alternatively, the processor 1700 may be configured to or operable to support a means for receiving, from a first network entity, multiplexed data encapsulated according to a tunnel protocol; and demultiplexing the multiplexed data based on an identifier and on the tunnel protocol.

[0135] Figure 18 illustrates an example of a NE 1800 in accordance with aspects of the present disclosure. The NE 1800 may include a processor 1802, a memory 1804, a controller 1806, and a transceiver 1808. The processor 1802, the memory 1804, the controller 1806, or the transceiver 1808, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0136] The processor 1802, the memory 1804, the controller 1806, or the transceiver 1808, or various combinations or components thereof may be implemented in hardware (e.g., circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

[0137] The processor 1802 may include an intelligent hardware device (e.g., a general- purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof). In some implementations, the processor 1802 may be configured to operate the memory 1804. In some other implementations, the memory 1804 may be integrated into the processor 1802. The processor 1802 may be configured to execute computer-readable instructions stored in the memory 1804 to cause the NE 1800 to perform various functions of the present disclosure.

[0138] The memory 1804 may include volatile or non-volatile memory. The memory 1804 may store computer-readable, computer-executable code including instructions when executed by the processor 1802 cause the NE 1800 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 1804 or another type of memory. Computer-readable media includes both non- transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or specialpurpose computer.

[0139] In some implementations, the processor 1802 and the memory 1804 coupled with the processor 1802 may be configured to cause the NE 1800 to perform one or more of the functions described herein (e.g., executing, by the processor 1802, instructions stored in the memory 1804). For example, the processor 1802 may support wireless communication at the NE 1800 in accordance with examples as disclosed herein. The NE 1800 may be configured to support a means for establishing a first connection with a second network entity for data traffic, wherein the data traffic comprises first data associated with a first client entity and second data associated with a second client entity; multiplexing the first data and the second data based at least in part on an identifier associated with the first data or the second data, wherein the multiplexed data comprising the first data and the second data are encapsulated in accordance with a tunnel protocol; and transmitting the multiplexed and encapsulated data to the second network entity via the established first connection. Alternatively, the NE 1800 may be configured to or operable to support a means for receiving, from a first network entity, multiplexed data encapsulated according to a tunnel protocol; and demultiplexing the multiplexed data based on an identifier and on the tunnel protocol.

[0140] The controller 1806 may manage input and output signals for the NE 1800. The controller 1806 may also manage peripherals not integrated into the NE 1800. In some implementations, the controller 1806 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 1806 may be implemented as part of the processor 1802.

[0141] In some implementations, the NE 1800 may include at least one transceiver 1808. In some other implementations, the NE 1800 may have more than one transceiver 1808. The transceiver 1808 may represent a wireless transceiver. The transceiver 1808 may include one or more receiver chains 1810, one or more transmitter chains 1812, or a combination thereof.

[0142] A receiver chain 1810 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 1810 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 1810 may include at least one amplifier (e.g., a low-noise amplifier (LN A)) configured to amplify the received signal. The receiver chain 1810 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 1810 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0143] A transmitter chain 1812 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 1812 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The transmitter chain 1812 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 1812 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0144] Figure 19 illustrates a flowchart of a method 1900 in accordance with aspects of the present disclosure. The operations of the method may be implemented by a first networkentity as described herein. In some implementations, the first network entity may execute a set of instructions to control the function elements of the first network entity to perform the described functions.

[0145] At 1902, the method 1900 may include establishing a first connection with a second network entity for data traffic, wherein the data traffic comprises first data associated with a first client entity and second data associated with a second client entity. The operations of 1902 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1902 may be performed by a first network entity (e,g, a UPF, or alternatively, an AS acting as proxy) as described with reference to Figure 18.

[0146] At 1904, the method 1900 may include multiplexing the first data and the second data based at least in part on an identifier associated with the first data or the second data, wherein the multiplexed data comprising the first data and the second data are encapsulated in accordance with a tunnel protocol. The operations of 1904 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1904 may be performed by a first network entity (e.g., a UPF, or alternatively, an AS acting as proxy) as described with reference to Figure 18.

[0147] At 1906, the method 1900 may include transmitting the multiplexed and encapsulated data to the second network entity via the established first connection. The operations of 1906 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1906 may be performed a first network entity (e.g., a UPF, or alternatively, an AS acting as proxy) as described with reference to Figure 18.

[0148] It should be noted that the method 1900 described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0149] Figure 20 illustrates a flowchart of a method 2000 in accordance with aspects of the present disclosure. The operations of the method 2000 may be implemented by a second network entity as described herein. In some implementations, the second network entity mayexecute a set of instructions to control the function elements of the second network entity to perform the described functions.

[0150] At 2002, the method 2000 may include receiving, from a first network entity, multiplexed data encapsulated according to a tunnel protocol. The operations of 2002 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2002 may be performed by a second network entity (e.g., an AS acting as proxy, or alternatively, a UPF) as described with reference to Figure 18.

[0151] At 2004, the method 2000 may include demultiplexing the multiplexed data based on an identifier and on the tunnel protocol. The operations of 2004 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2004 may be performed by a second network entity (e.g., an AS acting as proxy, or alternatively, a UPF) as described with reference to Figure 18.

[0152] The present disclosure provides a first network entity for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the first network entity to: establish a first connection with a second network entity for data traffic, wherein the data traffic comprises first data associated with a first client entity and second data associated with a second client entity; multiplex the first data and the second data based at least in part on an identifier associated with the first data or the second data, wherein the multiplexed data comprising the first data and the second data are encapsulated in accordance with a tunnel protocol; and transmit the multiplexed and encapsulated data to the second network entity via the established first connection.

[0153] Multiplexing first and second data based on identifiers and a tunnel protocol encapsulation enables participants to distinguish data associated with different client entities (such as UEs) and / or applications tunnelled over the encapsulation protocol comprised within the at least one connection. Many types of identifier are provided that enable the distinguishing of data associated with different client entities and they facilitate the distinguishing of data when using respective communication protocols, thereby increasing the utility of the distinguishability.

[0154] The first network entity may comprise a UPF. The second network entity may comprise an AS. The AS may operate as a proxy for a further AS. The further AS may be a target AS. The proxy may comprise a UDP proxy.

[0155] The tunnel over the encapsulation protocol may be bidirectional and support bidirectional communication. When the tunnel is bidirectional, the first network entity may comprise an AS. The AS may operate as a proxy for a further AS. The further AS may be a target AS. The proxy may comprise a UDP proxy. The second network entity may comprise a UPF.

[0156] The first client entity may comprise a first UE. The second client entity may comprise a second UE.

[0157] The first data may comprise first application traffic flow data corresponding to the first client entity. The second data may comprise second application traffic flow data corresponding to the second client entity.

[0158] The identifier may be a flow identifier.

[0159] The tunnelling may be tunnelling over N6 interface.

[0160] The tunnel protocol may be based at least in part on QUIC transport protocol.

[0161] The at least one processor may be configured to cause the first network entity to: proxy User Datagram Protocol, UDP, payloads based on Hypertext Transfer Protocol, HTTP, encapsulation tunnel as connect-udp; proxy QUIC payloads based on HTTP encapsulation tunnel as connect-udp; proxy Internet Protocol, IP, payloads based on HTTP encapsulation tunnel as connect-ip; or proxy Ethernet, ETH, payloads based on HTTP encapsulation tunnel as connect-ethernet.

[0162] The at least one connection may comprise an HTTP / 3 connection.

[0163] The at least one processor may be configured to cause the first network entity to: establish at least two connections comprising the first connection and a second connection, wherein each connection of the at least two connections is associated with a different corresponding Transport Layer Security, TLS, configuration.

[0164] Each different corresponding TLS configuration may comprise one or more different public-private client key pairs.

[0165] Each different corresponding TLS configuration may comprise one or more different client certificates for client authentication.

[0166] At least one connection may comprise a first tunnel for a first application data flow associated with the first data and a second tunnel for a second application data flow associated with the second data.

[0167] The first tunnel and the second tunnel may be established by means of different corresponding CONNECT requests.

[0168] The CONNECT request may correspond to a HTTP / 3 CONNECT method. The CONNECT request may comprise request information for establishing a connect-udp tunnel over the first connection. The CONNECT request may comprise request information for establishing a connect-ip tunnel over the first connection. The CONNECT request may comprise request information for establishing a connect-ethernet tunnel over the first connection.

[0169] Each of the different corresponding CONNECT requests may comprise one or more different corresponding query parameter values.

[0170] A different query parameter may correspond to the identifier.

[0171] Each of the different corresponding CONNECT requests may comprise a different corresponding port instance of an authority.

[0172] The authority may correspond to the AS acting as a proxy.

[0173] The identifier may comprise a Connection Identifier, CID, of the at least one connection.

[0174] The CID may be a QUIC connection ID. The CID may be a QUIC connection ID tuple. The QUIC connection ID may comprise a Source Connection ID. The QUIC connection ID may comprise a Destination Connection ID.

[0175] The identifier may comprise a Virtual Connection Identifier, VCID, associated with a CID.

[0176] A VCID may be assigned to a CID for a QUIC-aware encapsulation tunnel and proxy.

[0177] The identifier may comprise a Context Identifier (ID) of a proxying payload.

[0178] The Context ID may be of a UDP proxying payload. The Context ID may comprise a first part encoding an identifier value of the identifier. The Context ID may comprise a second part encoding an identifier corresponding to proxying payload semantics.

[0179] The identifier may comprise a proxying payload additional field.

[0180] The proxying payload additional field may comprise a proxying payload header. The proxying pay load header may be specific to 3 GPP media related information. The 3 GPP media related information may comprise PDU Set Information. The 3GPP media related information may comprise Dynamic Data Burst Information. The 3 GPP media related information may comprise Expediated Transfer Indication. The 3 GPP media related information may comprise the identifier field. The identifier field may comprise an identifier value of the identifier.

[0181] 3 GPP-specific flow identifiers provide better interoperability and scalability (e.g., avoiding exhaustion of ports, increased memory usage by additional tunnels, HTTP / 3 connections etc.).

[0182] The present disclosure provides a method for wireless communication performed or performable by a first network entity, the method comprising: establishing a first connection with a second network entity for data traffic, wherein the data traffic comprises first data associated with a first client entity and second data associated with a second client entity; multiplexing the first data and the second data based at least in part on an identifier associated with the first data or the second data, wherein the multiplexed data comprising the first data and the second data are encapsulated in accordance with a tunnel protocol; and transmitting the multiplexed and encapsulated data to the second network entity via the established first connection.

[0183] The present disclosure provides a second network entity for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the second network entity to: receive, from a first network entity, multiplexed data encapsulated according to a tunnel protocol; and demultiplex the multiplexed data based on an identifier and on the tunnel protocol.

[0184] The present disclosure provides a method for wireless communication performed or performable by a second network entity, the method comprising: receiving, from a first network entity, multiplexed data encapsulated according to a tunnel protocol; and demultiplexing the multiplexed data based on an identifier and on the tunnel protocol.

[0185] The present disclosure provides a processor for wireless communication, comprising at least one controller coupled with at least one memory and configured to cause the processor to: establish a first connection with a second network entity for data traffic, wherein the data traffic comprises first data associated with a first client entity and second data associated with a second client entity; multiplex the first data and the second data based at least in part on an identifier associated with the first data or the second data, wherein the multiplexed data comprising the first data and the second data are encapsulated in accordance with a tunnel protocol; and transmit the multiplexed and encapsulated data to the second network entity via the established first connection.

[0186] The present disclosure provides a processor for wireless communication, comprising at least one controller coupled with at least one memory and configured to cause the processor to: receive, from a first network entity, multiplexed data encapsulated according to a tunnel protocol; and demultiplex the multiplexed data based on an identifier and on the tunnel protocol.

[0187] The present disclosure address issues including how to distinguish among different UEs and / or apps tunnelled at N6 over an encapsulation protocol (e.g., connect-udp over HTTP / 3 proxy) between a UPF and an AS acting as UDP proxy towards a target AS. The issue arises mainly as many UEs and / or apps can be served by the same UPF acting as same HTTP / 3 client interacting with the AS acting as UDP proxy. To appropriately route and handle traffic flows of different UEs and / or apps, it is advantageous therefore to distinguish among them on both the CN path and the proxied network path.

[0188] The present disclosure sets out different approaches (e.g., single HTTP / 3 connection with different tunnels, different Context IDs, different UDP proxied ports and combinations thereof or multiple HTTP / 3 connections) to distinguish among different UEs / apps traffic flows encapsulated within an encapsulation protocol. All of them achieve establishment of a flow identifier to differentiate among UEs / apps. For better interoperability and scalability (e.g., avoiding exhaustion of ports, increased memory usage by additional tunnels, HTTP / 3 connections etc.) a 3GPP-specific flow identifier field is introduced as part of the UDP proxying payload. This can be used both by CN and proxy network paths to differentiate traffic flows among different UEs / apps.

[0189] The introduction of a 3GPP-specific flow identifier improves scalability and eases implementations related to distinguishing traffic flows among different UEs and apps.

[0190] Some embodiments use a single HTTP / 3 connection for one or more connect-udp tunnels to multiplex different client UEs / apps. In these embodiments, multiplexing by different tunnels is established between client (e.g., UPF) and server (e.g., AS acting as UDP proxy) based on different requests. The different requests may be distinguishable based on different query elements (e.g., flow identifier assigned by the client), or by different ports (e.g., UDP ports for HTTP / 3 tunnels). Alternatively, a single connection and a single tunnel may be used to multiplex client UEs / apps. In this case, it is advantageous to establish other differentiating identifiers for the application data flows corresponding to different client UEs / apps. Some solutions use dynamic Context IDs comprising a part that identifies the corresponding multiplexed flow and a second part that specifies the tunnelled payload semantics. Other solutions use a 3GPP-specific payload header which carries identifier information related to the multiplexed flow both cross established tunnel and proxied network path.

[0191] Some embodiments perform multiplexing of application data flows of client UEs / apps based on different HTTP / 3 connections each with its own connect-udp tunnel. To establish different HTTP / 3 connections, it is advantageous for UPF to establish different TLS configurations corresponding to different client UEs / apps. Such different TLS configurations include different public-private key pairs, different TLS client certificates (if client authentication is configured) or combinations thereof.

[0192] The present disclosure also provides a method at a network function, the method comprising: establishing a first connection on behalf of a first client for a tunnel protocol encapsulation of a first application data flow traffic corresponding to the client, wherein the connection is established with an AS; routing the first application data flow traffic between the first client and the AS within the first connection over the tunnel protocol encapsulation; the AS acting as a proxy to a second AS, a target AS; establishing a second connection on behalf of a second client for a tunnel protocol encapsulation of at least a second application data flow traffic, wherein the connection is established with the AS; multiplexing based on a flow identifier and on the tunnel protocol encapsulation the second application data flow traffic with the first application data flow traffic between the network function and the AS; and routing the second application data flow traffic between the second client and the AS within the second connection over the tunnel protocol encapsulation.

[0193] The tunnel protocol encapsulation may be based on QUIC transport protocol.

[0194] The tunnel protocol encapsulation may be one of: proxying UDP payloads based on Hypertext Transfer Protocol (HTTP) encapsulation tunnel as connect-udp, comprising the AS acting as a UDP proxy; proxying QUIC payloads based on HTTP encapsulation tunnel as connect-udp, comprising the AS acting as QUIC-aware proxy; proxying Internet Protocol (IP) payloads based on HTTP encapsulation tunnel as connect-ip, comprising the AS acting as an IP proxy; or proxying Ethernet (ETH) payloads based on HTTP encapsulation tunnel as connect-ethernet, comprising the AS acting as ETH proxy.

[0195] Any of the connections established between the network function and the AS acting as a proxy may be based on HTTP / 3.

[0196] The establishment of the second connection may comprise using different Transport Layer Security (TLS) configuration as for the establishment of the first connection.

[0197] The usage of different TLS configuration between the first connection and second connection may comprises at least one of: a different public-private client key pair; and client certificate for client authentication.

[0198] The establishment of the second connection may comprise reusing the first connection as a common connection.

[0199] The common connection may comprise a first tunnel for the first application data flow and a second tunnel for the second data flow. The first and second tunnel may correspond to different requests to establish the tunnel protocol encapsulation.

[0200] The different requests to establish the tunnel protocol encapsulation may comprise of at least one of: a different query parameter value of a CONNECT request, the different query parameter corresponding to the flow identifier; a different port instance of an authority, the authority corresponding to the AS acting as proxy; or a combination thereof.

[0201] The flow identifier may comprise at least one of: a connection identifier (CID) of the connection (e.g., a QUIC connection ID, or alternatively, a QUIC connection ID tuple (e.g., Source Connection ID, Destination Connection ID)); a virtual connection identifier (VCID) mapped to the connection identifier (e.g., as for example VCIDs assigned to CIDs for QUIC-aware encapsulation tunnels and proxies); a Quarter Stream Identifier (QSID) of the tunnel encapsulation protocol (e.g., QSID of a connect-udp tunnel, or alternatively, connect-ip / connect-eth tunnel); a Context Identifier (ID) of proxying payloads comprised within the tunnel encapsulation protocol (e.g., the Context ID of a UDP proxying payload); the Context ID further comprising a first part encoding an identifier value of the flow identifier, and a second part encoding an identifier corresponding to the proxying payload semantics; a proxying payload additional field (e.g., a proxying payload header specific to 3GPP media related information comprising among other fields, e.g., PDU Set Information, Dynamic Data Burst Information, Expediated Transfer Indication, also the flow identifier field), the proxying payload additional field including Media Related Information comprising an identifier value of the flow identifier; or a combination thereof.

[0202] It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0203] The description herein is provided to enable a person having ordinary skill in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, thedisclosure is not limited to the examples and designs described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.

[0204] The following abbreviations are relevant in the field addressed by this document: 5GCN - 5G Core Network; 5GS - 5G System; AF - Application Function; AMF - Access and Mobility Management Function; ANDSP - Access Network Discovery and Selection Policy; API - Application Programming Interface; APN - Access Point Name; ATSSS - Access Traffic Steering, Switching, Splitting; AS - Application Server; BRID - Broadcast Remote Identification; BVLOS - Beyond Visual Line of Sight; C2 - Command and Control; CAA - Civil Aviation Administration; CERT - Certificate; CH - ClientHello; CV - Certificate Verification; DCN - Dedicated Core Network; DNN - Data Network Name; DNS - Domain Name System; EDN - Edge Data Network; EE - Encrypted Extensions; EPS - Evolved Packet System; ER-NSSAI - Extended rejected NSSAI; E-UTRA - Evolved Universal Terrestrial Radio Access; FQDN - Fully Qualified Domain Name; GPRS - General Packet Radio Service; GPT - GPRS Tunnelling Protocol; GUMMEI - Globally Unique Mobility Management Entity Identifier; GUTI - Globally Unique Temporary Identity; HKDF - HMAC-based Extract-and-expand Key Derivation Function; HMAC - Hash-based Message Authentication Code; HPLMN - Home PLMN; HSS - Home Subscriber Server; IE - Information Element; IMSI - International Mobile Subscriber Identity; IP - Internet Protocol; IV - Initialization Vector; KPI - Key Performance Indicator; LADN - Local Area Data Network; LCS - LoCation Services; MCC - Mobile Country Code; MME - Mobility Management Entity; MNC - Mobile Network Code; N3AN - Non-3GPP Access Network; N3IWF - Non-3GPP InterWorking Function; NEF - Network Exposure Function; NF - Network Function; NID - Network Identifier; NRF - Network Repository Function; NRID - Networked Remote Identification; NSAC - Network Slice Admission Control; NSCE - Network Slice Capability Exposure; NSSF - Network Slice Selection Function; OS - Operating System; OS Id - Operating System Identity; OS App Id - Operating System Application Identity; PCF - Policy Control Function; PCO - Protocol Configuration Options; PD - Protocol Discriminator; PDN - Packet Data Network; PDN GW - PDN Gateway; PDR - Packet Detection Rules; PDU - Protocol Data Unit; PGW - PDN GW; PLMN - Public Land Mobile Network; PLMN ID - Public Land Mobile Network identity; ProSe - Proximity Services; ProSeP - ProSe Policy; PSDB - PDU Set Delay Budget; PSER - PDU Set ErrorRate; PSI - PDU Set Importance; PTI - Procedure Transaction Identity; P-TMSI - Packet Temporary Mobile Subscriber Identity; RAI - Routing Area Identity; RAN - Radio Access Network; RID - Remote Identification; RPLMN - Registered PLMN; RRC - Radio Resource Control; SAP - Service Access Point; SEAL - Service Enabler Architecture Layer; SDF - Service Data Flow; SDU - Service Data Unit; SGW - Serving Gateway; SH - ServerHello; SLA - Service Level Agreement; SMF - Session and Mobility Management Function; SM- PCO - Session Management PCO; SNPN - Standalone Non-Public Network; SNSCE - SEAL Network Slice Capability Enablement; SNSCE-C - SEAL Network Slice Capability Enablement Client; SNSCE-S - SEAL Network Slice Capability Enablement Server; S- NSSAI - Single Network Slice Selection Assistance Information; SSC - Session and Service Continuity; SSID - Service Set Identifier; SUCI - Subscription Concealed Identifier; SUPI - Subscription Permanent Identifier; TA - Tracking Area; TAI - Tracking Area Identity; TAU- Tracking Area Update; TEID - Tunnel Endpoint Identifier; TLS - Transport Layer Security; TNAN - Trusted Non-3GPP-Access-Network; TNAP - Trusted Non-3GPP Access Network; TNGF - Trusted Non-3GPP Gateway Function; TPAE - Third Party Authorized Entity; UAS- Uncrewed Aerial System; UAS NF - Uncrewed Aerial System Network Function; UAV - Uncrewed Aerial Vehicle; UAV-C - Uncrewed Aerial Vehicle Controller; UDM - Unified Data Management; UDR - Unified Data Repository; UE - User Equipment; UPDS - UE Policy Delivery Service; UPF - User Plane Function; UPSC - UE Policy Section Code; UPSI- UE Policy Section Identifier; URSP - UE Route Selection Policy; USIM - Universal Subscriber Identity Module; USS - UAS Service Supplier; UTM - Uncrewed Aerial System Traffic Management; UUAA - USS UAV Authorization / Authentication; UUID - Universal Unique Identifier; V2X - Vehicle to Everything; V2XP - V2X Policy; VAL - Vertical Application Layer; WLANSP - Wireless Location Area Network Selection Policy.

Claims

CLAIMS1. A first network entity for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the first network entity to: establish a first connection with a second network entity for data traffic, wherein the data traffic comprises first data associated with a first client entity and second data associated with a second client entity; multiplex the first data and the second data based at least in part on an identifier associated with the first data or the second data, wherein the multiplexed data comprising the first data and the second data are encapsulated in accordance with a tunnel protocol; and transmit the multiplexed and encapsulated data to the second network entity via the established first connection.

2. The first network entity according to claim 1, wherein the tunnel protocol is based at least in part on QUIC transport protocol.

3. The first network entity according to claim 1, wherein the at least one processor is configured to cause the first network entity to: proxy User Datagram Protocol, UDP, payloads based on Hypertext Transfer Protocol, HTTP, encapsulation tunnel as connect-udp; proxy QUIC payloads based on HTTP encapsulation tunnel as connect-udp; proxy Internet Protocol, IP, payloads based on HTTP encapsulation tunnel as connect-ip; or proxy Ethernet, ETH, payloads based on HTTP encapsulation tunnel as connect-ethernet.

4. The first network entity according to any preceding claim, wherein the at least one connection comprises a Hypertext Transfer Protocol / 3, HTTP / 3, connection.

5. The first network entity according to any preceding claim, wherein the at least one processor is configured to cause the first network entity to: establish at least two connections comprising the first connection and a second connection, wherein each connection of the at least two connections is associated with a different corresponding Transport Layer Security, TLS, configuration.

6. The first network entity according to claim 5, wherein each different corresponding TLS configuration comprises one or more different public-private client key pairs.

7. The first network entity according to claim 5 or claim 6, wherein each different corresponding TLS configuration comprises one or more different client certificates for client authentication.

8. The first network entity according to claim 4, wherein the at least one connection comprises a first tunnel for a first application data flow associated with the first data and a second tunnel for a second application data flow associated with the second data.

9. The first network entity according to claim 8, wherein the first tunnel and the second tunnel are established by means of different corresponding CONNECT requests.

10. The first network entity according to claim 8, wherein each of the different corresponding CONNECT requests comprise one or more different corresponding query parameter values.

11. The first network entity according to claim 9 or claim 10, wherein each of the different corresponding CONNECT requests comprises a different corresponding port instance of an authority.

12. The first network entity according to any preceding claim, wherein the identifier comprises a Connection Identifier, CID, of the at least one connection.

13. The first network entity according to any preceding claim, wherein the identifier comprises a Virtual Connection Identifier, VCID, associated with a CID.

14. The first network entity according to any preceding claim, wherein the identifier comprises a Context Identifier, ID, of a proxying payload.

15. The first network entity according to any preceding claim, wherein the identifier comprises a proxying payload additional field.

16. A method for wireless communication performed or performable by a first network entity, the method comprising: establishing a first connection with a second network entity for data traffic, wherein the data traffic comprises first data associated with a first client entity and second data associated with a second client entity; multiplexing the first data and the second data based at least in part on an identifier associated with the first data or the second data, wherein the multiplexed data comprising the first data and the second data are encapsulated in accordance with a tunnel protocol; and transmitting the multiplexed and encapsulated data to the second network entity via the established first connection.

17. A second network entity for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the second network entity to: receive, from a first network entity, multiplexed data encapsulated according to a tunnel protocol; anddemultiplex the multiplexed data based on an identifier and on the tunnel protocol.

18. A method for wireless communication performed or performable by a second network entity, the method comprising: receiving, from a first network entity, multiplexed data encapsulated according to a tunnel protocol; and demultiplexing the multiplexed data based on an identifier and on the tunnel protocol.

19. A processor for wireless communication, comprising at least one controller coupled with at least one memory and configured to cause the processor to: establish a first connection with a second network entity for data traffic, wherein the data traffic comprises first data associated with a first client entity and second data associated with a second client entity; multiplex the first data and the second data based at least in part on an identifier associated with the first data or the second data, wherein the multiplexed data comprising the first data and the second data are encapsulated in accordance with a tunnel protocol; and transmit the multiplexed and encapsulated data to the second network entity via the established first connection.

20. A processor for wireless communication, comprising at least one controller coupled with at least one memory and configured to cause the processor to: receive, from a first network entity, multiplexed data encapsulated according to a tunnel protocol; and demultiplex the multiplexed data based on an identifier and on the tunnel protocol.

Images