Identification of payloads in a wireless communication system

Abstract

Various aspects of the present disclosure relate to a network entity for wireless communication. The network entity may be configured to, capable of, or operable to determine at least one identifier associated with at least one semantic of a datagram payload, construct a packet comprising a datagram payload comprising the at least one identifier, and transmit, to a further network entity, the constructed packet.

Description

IDENTIFICATION OF PAYLOADS IN A WIRELESS COMMUNICATIONSYSTEMTECHNICAL FIELD

[0001] The present disclosure relates to wireless communication, including identification of payloads in a wireless communication 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 (i.e., 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 second network entity for wireless communication is described. The second network entity may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the second network entity may include 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: determine at least one identifier associated with at least one semantic of a datagram payload; construct a packet comprising a datagram payload comprising the at least one identifier; and transmit, to a first network entity, the constructed packet.

[0005] A first network entity for wireless communication is described. The first network entity may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the first network entity may include 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: receive a packet; and determine, based at least in part on an identifier in a datagram payload of the packet, a semantic of the datagram payload.

[0006] A method performed or performable by a second network entity is described. The method may include: determining at least one identifier associated with at least one semantic of a datagram payload; constructing a packet comprising a datagram payload comprising the at least one identifier; and transmitting, to a first network entity, the constructed packet.

[0007] A method performed or performable by a first network entity is described. The method may include: receiving a packet; and determining, based at least in part on an identifier in a datagram payload of the packet, a semantic of the datagram payload.

[0008] A processor for wireless communication is described. The processor may be configured to, capable of, or operable to: determine at least one identifier associated with at least one semantic of a datagram payload; construct a packet comprising a datagram payloadcomprising the at least one identifier; and transmit, to a first network entity, the constructed packet.

[0009] A processor for wireless communication is described. The processor may be configured to, capable of, or operable to: receive a packet; and determine, based at least in part on an identifier in a datagram payload of the packet, a semantic of the datagram payload.BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

[0013] Figure 4 illustrates a Quick UDP Internet Connection (QUIC) packet with stream frame type in accordance with aspects of the present disclosure.

[0014] Figure 5 illustrates a QUIC packet with datagram frame type in accordance with aspects of the present disclosure.

[0015] Figure 6 illustrates a HTTP datagram in accordance with aspects of the present disclosure.

[0016] Figure 7 illustrates a UDP proxying HTTP datagram payload in accordance with aspects of the present disclosure.

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

[0018] Figure 9 illustrates a Context Identifier (ID) in accordance with aspects of the present disclosure.

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

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

[0021] Figure 12 illustrates a Context ID containing a timestamp in accordance with aspects of the present disclosure.

[0022] Figure 13 illustrates four examples of PDU Set marking format in accordance with aspects of the present disclosure.

[0023] Figure 14 illustrates a Context ID in accordance with aspects of the present disclosure.

[0024] Figure 15 illustrates a Context ID containing a timestamp in accordance with aspects of the present disclosure.

[0025] Figure 16 illustrates a signalling diagram in accordance with aspects of the present disclosure.

[0026] Figure 17 illustrates a message exchange in accordance with aspects of the present disclosure.

[0027] Figures 18 through 22 illustrate semantic negotiations in accordance with aspects of the present disclosure.

[0028] Figures 23 through 25 illustrate multiplexed pay loads with different semantics in accordance with aspects of the present disclosure.

[0029] Figure 25b illustrates multiplexed payloads with different semantics for different UDP tunnels in accordance with aspects of the present disclosure.

[0030] Figure 26 illustrates an example of a processor in accordance with aspects of the present disclosure.

[0031] Figure 27 illustrates an example of a NE in accordance with aspects of the present disclosure.

[0032] Figures 28 through 30 illustrate flowcharts of methods performed by a NE in accordance with aspects of the present disclosure.DETAILED DESCRIPTION

[0033] In a wireless communication network, one or more NE (e.g., base stations, network entities of core networks, such as an Application Server (AS)) or UE (e.g., mobile devices) may support various applications and transport (e.g., transmit, receive, route, forward) one or more packets (e.g., control information, data) associated with these applications over one or more network interfaces. In some cases, transport of data may be conveyed in accordance with one or more protocols, such as UDP, QUIC, HTTP, etc. In some cases, to support certain applications, the NE may support extensions to headers associated with packets transported in accordance with one or more of these protocols. These extensions may enable one or more of the NE or the UE to provide additional information, facilitating identification of a group of packets (e.g., PDU Set information) by the network and the delivery of these packets with specific Quality of Service (QoS) requirements (e.g., a PDU Set Delay Budget (PSDB)) to the UE. This approach, however, requires that the headers be transmitted unencrypted so that the NE can identify the PDU Set information.

[0034] In some cases, the NE may support fully encrypting packets, including protocol headers. As such, the network may be configured with a framework in which fully encrypted packets from the NE (e.g., an AS) are tunnelled via an encapsulation protocol over a network interface, such as an N6 interface between a User Plane Function (UPF) and an external data network (e.g., the AS). In some cases, for fully encrypted packets received at the NE (e.g., the UPF) over the N6 interface (e.g., tunnelled over the N6 reference point), the NE may retrieve PDU Set information based on Context ID. See Solution #24 in 3GPP TR 23.700-70 vl 9.0.0 (September 2024). However, more details on specific Context ID representation and formats are needed to identify the packets and related PDU Set information tunnelled over the N6 reference point.

[0035] The present disclosure provides techniques for communicating, and arranging to communicate, data that enables identification of payload semantics, formats, and content of, for example, data packets and corresponding payloads between one or more NEs (e.g., one or more ASs and one or more UPFs). When an NE includes one or more identifiers that identify one or more respective semantics of a datagram payload in a packet with the datagram payload, a recipient (e.g., a UPF) of the packet can agree with the sender (e.g., anAS) on an association or correspondence between that identifier and that semantic. Having provided a reliable framework for relating information stored in a header field to a semantic of a payload, aspects of the present disclosure may thereby facilitate communication of payloads having different semantics, and may allow NEs to quickly and easily identify payload semantics even in circumstances where the packet is encrypted.

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

[0037] 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 an LTE 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.

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

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

[0040] 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, a transmitter 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.

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

[0042] 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 accessnetwork 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).

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

[0044] 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 protocol data unit (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).

[0045] 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 otherimplementations, such as in 5G and among other suitable radio access technologies, the NEs 102 and the UEs 104 may support various frame structures (i.e., multiple frame structures). The NEs 102 and the UEs 104 may support various frame structures based on one or more numerologies.

[0046] 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., 120 kHz) 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.

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

[0048] 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 (i.e., / 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 mayinclude 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.

[0049] 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 designations FR1 (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.

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

[0051] In the wireless communication system 100, one or more network entities, including NE 102 and network entities associated with the CN 106 (e.g., a UPF, an AS) may support fully encrypting packets (e.g., UDP packets), including protocol headers. As such, the one or more network entities may be configured with a framework in which fully encrypted packets from the one or more network entities are tunnelled via an encapsulation protocol over a network interface, such as an N6 interface. In some cases, for fully encrypted packets received at the one or more network entities over the N6 interface (e.g., tunnelled over the N6 reference point), the one or more network entities may retrieve PDU Set information based on Context ID. See Solution #24 in 3GPP TR 23.700-70 vl9.0.0 (September 2024), which describes how Context ID as described in IETF RFC 9298 might be used to identify the PDU Set information of a fully encrypted UDP packets tunnelled over N6 reference point. Additionally, Solution #24 in 3GPP TR 23.700-70 vl9.0.0 (September 2024) aims to address Key Issue #2 in 3GPP TR 23.700-70 vl9.0.0. It describes a method for using a connect-udp protocol to tunnel UDP between one or more network entities (e.g., a UPF and an AS), as shown in Figure 2, to exchange information about the QoS requirements of the packets, despite the full encryption of the packets, which also include the protocol header. UDP is a lightweight transport layer protocol that provides source and destination port addressing for the multiplexing and demultiplexing of higher- lay er applications onto the same transport bearer.

[0052] Figure 2 illustrates an example of a framework for proxying encrypted packets. The framework may include one or more of a UE, a Radio Access Network (RAN), an AMF, a Session Management Function (SMF), a Policy Control Function (PCF), an Extended Reality (XR) Application Function (AF), a UPF, or one or more Content Servers may implement or may be implemented by aspects of the wireless communication system 100.

[0053] In the example of Figure 2, a UPF may receive one or more N4-rules from the SMF and according to the N4 rules may establish a UDP tunnel between the UPF and a Content Server (e.g., an XR Video Application Server), in accordance with connect-udp as described in IETF RFC 9298, for communicating (e.g., transmitting, receiving, transporting, forwarding, routing) UDP packets with the Content Server, where the UDP packets may be associated with the UE. Additionally, the UPF may extract PDU Set information and apayload of the UDP packets (one or more encrypted UDP packets) from a received HTTP / 3 datagram payload via the connect-udp session over N6. The UPF may route over a QoS flow with a PSDB requirements and PDU Set Error Rate (PSER) requirements received from the SMF as part of the one or more N4 rules, over the RAN by including the UDP packets in a General Packet Radio Service (GPRS) Tunnelling Protocol (GTP) packet and including the PDU Set information in the GTP-U header.

[0054] The Content Server may identify a semantic of the payload of the HTTP datagram to extract the PDU Set information and the UDP payload, which may be one or more encrypted UDP packets. To identify the semantic of the UDP payload, a particular HTTP extended header field can be defined for a semantic. Upon receipt of the request, the Content Server can identify the semantic by identifying the HTTP extended header field.

[0055] With reference to Solution #24 that addresses Key issue #2 in 3 GPP TR 23.700- 70 vl 9.0.0 describes that the N4 rules may provide information that the UPF establishes a UDP tunnel towards the Content Server (e.g., AS) using the protocol described in IETF RFC 9298. The UPF uses the N4 rules to establish the UDP tunnel for the HTTP datagram stream of QUIC packets containing HTTP / 3 datagrams with a payload as PDU Set marking and one or more encrypted UDP packets according to Figure 3.

[0056] Figure 3 illustrates a PDU set marking and UDP payload within a HTTP / 3 datagram, in accordance with aspects of the present disclosure. QUIC is a UDP based stream- multiplexed and secure transport protocol with integrity protected header and encrypted payload. Unlike the traditional transport protocol stack TCP (Transmission Control Protocol), which resides in the operating system kernel, QUIC can easily be implemented in an application layer.

[0057] Context ID in Figure 3 is defined in IETF RFC 9298 as a 62-bit integer (0 to 2A62-1) and is encoded as variable-length integer as defined in section 16 of IETF RFC 9000. PDU Set marking is defined in clause 4.2.4 of 3GPP TS 26.522 vl8.1.0 (July 2024) as in Figure 8. Figure 8 illustrates a PDU Set marking in accordance with aspects of the present disclosure, containing fields as set out below.

[0058] In Figure 8: E (IBit) (802) represents End PDU of the PDU Set; R (2Bits) (804) represents Reserved; D (IBit) (806)represents End of Data Burst; PS Info (4Bits) (808) represents PDU Set Importance; PSSN (lOBits) (810) represents PDU Set Sequence Number; PSN (6Bits) (812) represents PDU Sequence Number within a PDU Set; PSSize (24Bits) (814) represents PDU Set Size; and the number of PDUs in the PDU Set (NPDS) (16Bits) (816) represents Number of PDUs in the PDU Set.

[0059] According to IETF RFC 9298, registration is the action by which an endpoint informs its peer of the semantics and format of a given Context ID.

[0060] If the registration is for two-way communications, then:1- Peer A allocates the Context ID-1 when transmitting Semantic-1. Upon receipt Peer B registers Context ID-1 for Semantic- 1.2- Peer B allocates the Context ID-2 when sending the same Semantic-1. Upon receipt Peer A registers Context ID-2 for Semantic-1.3- At this point Context ID-1 and Context-ID-2 are marked to be used for Semantic- 1 by Peer A and Peer B for further data transmission.

[0061] If the registration is a one-way communication wherein only Peer A or Peer B is to transmit data, then:1- Peer A allocates the Context ID-1 when transmitting Semantic-1. Upon receipt Peer B registers Context ID-1 for Semantic- 1.2- At this point Context ID-1 is marked to be used for Semantic-1 by Peer A or Peer B for further data transmission by Peer A.

[0062] In a two-way communication, Peer B may need to identify Context ID 2 when transmitting datagrams with Semantic-1. Since the Context ID-1 and Context ID-2 in two- way communications and Context ID-1 in one-way communication are now known to identify specifically Semantic- 1, the Context IDs can be considered to be registered by both Peer A and Peer B for such a semantic.

[0063] 3 GPP Change Request Cl -242421 is titled “Addition of MPQUIC Datagram mode 1 support” and was submitted in respect of 3GPP TS 24.193 vl8.5.0 at TSG-CT WG1 Meeting #148 in Changsha, China, on 15 April 2024. Cl -242421 proposes an HTTP header field for identifying a semantic for the UDP proxying payload of the HTTP datagrams which contains a sequence number. Using the proposed HTTP extended header field is as an identifier of the semantic of pay load of the HTTP datagram.

[0064] According to IEFT RFC 9114:1- Client should not open more than one HTTP / 3 connection to the same proxy. However, the client may establish multiple tunnels for that connection if the authority or the host is different for each tunnel.2- Client may have multiple HTTP / 3 connections to the same proxy, if using different TLS configurations.

[0065] For the Key issue #2 in 3GPP TR 23.700-70 vl9.0.0, the client is the UPF which may use different certificates for different UEs' TLS configurations to reuse the same connection towards the proxy which is the AS. In this document, it is assumed there is only one connection between the UPF and the AS in Key issue #2 in 3GPP TR 23.700-70 vl9.0.0, where the UPF is client and the AS is the proxy using the CONNECT method connect-udp as they are defined in IETF RFC 9298 for such a connection. The CONNECT method establishes the UDP tunnel over a single HTTP datagram stream as IETF RFC 9114 says: “In HTTP / 2 and HTTP / 3, the CONNECT method is used to establish a tunnel over a single stream.”

[0066] According to IETF RFC 9000, a UDP datagram may contain one or more QUIC packets with a payload of a sequence of frames, identified with a frame type. IETF RFC 9000 [defines several types of the frame for signalling and the stream data transmission.

[0067] In an embodiment, packets, for example QUIC packets, that are tunnelled via an established UDP tunnel contain the PDU Set marking as the same semantic as shown in Figure 8 where all the fields of the PDU Set marking including the optional fields PSSize and NPDS are included in the PDU Set marking. In an embodiment, one or more of thePSSize and NPDS fields are included. In an embodiment, if values for the optional fields PSSize and NPDS are not available, their values are set to zero.

[0068] In an embodiment, upon establishment of the UDP tunnel, an AS constructs a payload of HTTP datagrams by including a PDU Set marking and one or more encrypted UDP packets. In an embodiment where there is only one semantic for the payload of the HTTP / 3 datagrams, an identifier is assigned a value. In an embodiment, the identifier comprises a Context ID. In an embodiment, the value may be non-zero. In an embodiment, the value may be an odd-numbered value. In an embodiment where the value is an odd- numbered value, the choice of the odd-numbered value indicates the identifier, such as a Context ID, being allocated by the AS which, in an embodiment, acts as a proxy. Figure 9 illustrates an embodiment in which the identifier (902) is a context ID (904) containing a non-zero odd-numbered value (906).

[0069] In an embodiment, the two most significant bits (908) in Figure 9 are set to 11 to indicate that the usable bits represent the Context ID are 62 bits. In an embodiment, upon receipt of a first packet, in an embodiment a QUIC packet, a UPF registers the value of the identifier, in an embodiment a Context ID, as the identifier for the semantic shown in Figure 3. In an embodiment, the UPF ignores any packet, in an embodiment any QUIC packet, with a different identifier, in an embodiment a Context ID, via this UDP tunnel. In an embodiment, the UPF includes the PDU Set information in GTP-U headers and the one or more UDP packets in a GTP packet. In an embodiment. The UPF routes over a QoS flow with PSDB requirements and PSER requirements received from the SMF.

[0070] In an embodiment, packets that are tunnelled via an established UDP tunnel contain the same semantic as shown in Figure 3. The packets may be QUIC packets. In an embodiment, the fields of the PDU Set marking are included in the PDU Set marking. In an embodiment, on or more of the fields PSSize and NPDS contain a flag indicating whether they are included or not. In an embodiment where the values for the fields PSSize and NPDS are not available, then the flags are set to zeros indicating that the fields PSSize and / or NPDS don’t exist; see Figure 10 for an illustration of such embodiments using flags (1018, 1020) in the aforementioned fields. Figure 10 illustrates a PDU Set marking in accordance with aspects of the present disclosure, containing fields as set out below.

[0071] In Figure 10, E (IBit) (1002) represents End PDU of the PDU Set; R (2Bits) (1004) represents Reserved; D (IBit) (1006) represents End of Data Burst; PS Info (4Bits) (1008) represents PDU Set Importance; PSSN (lOBits) (1010) represents PDU Set Sequence Number; PSN (6Bits) (1012) represents PDU Sequence Number within a PDU Set; F (IBit) (1018) represent where the optional PSSize field exists; PSSize (24Bits) (1014) represents PDU Set Size; F (IBit) (1020) represents where the optional NPDS field exists; and NPDS (16Bits) (1018) represents Number of PDUs in the PDU Set.

[0072] In an embodiment, the UDP tunnel is shared with other semantics than the one in Figure 3. In an embodiment, since a payload of a datagrams, in an embodiment an HTTP / 3 datagram, may have other than the one shown in Figure 3, the identifier, in one embodiment a Context ID, is assigned a value which is known by the UPF and the AS. In one embodiment, the values is a) non-zero odd-numbered Context ID-1 when the semantic of HTTP / 3 datagram is a PDU Set marking plus one or more encrypted UDP packets, as shown in Figure 3. In an embodiment where an odd-numbered value for the identifier, in one embodiment a Context ID-1, is chosen, this indicates the value being allocated by the AS which acts as a proxy. Figure 11 illustrates an embodiment wherein the identifier (1102) is a context ID (1104) containing a non-zero odd-numbered Context ID-1 (1106).

[0073] In an embodiment, the two most significant bits (1108) in Figure 11 are set to 11 to indicate that the usable bits represent the Context ID are 62 bits. Upon receipt of a first packet, in an embodiment a QUIC packet, with an identifier, in an embodiment a Context ID as Context ID-1, the UPF includes PDU Set information in the GTP-U headers and the one or more UDP packets in a GTP packet. In an embodiment, the UPF routes over a QoS flow withPSDB requirements and PSER requirements received from the SMF. In an embodiment, the UPF registers the identifier, in an embodiment a Context-ID, as the identifier for that semantic of the payload of the datagram, in an embodiment an HTTP datagram. In an embodiment, the UPF ignores any packet, in an embodiment a QUIC packet, having a different identifier, in an embodiment a Context ID, than Context ID-1.

[0074] In an embodiment, an identifier, in an embodiment a Context ID, is allocated dynamically by adding a dynamic allocated part (1210). In an embodiment, the dynamic part comprises a timestamp. In an embodiment, the timestamp stays the same for the duration ofthe UDP tunnel. In an embodiment, the dynamic part is updated by transmitting a new HTTP / 3 request to reestablish the UDP tunnel. Figure 12 illustrates an embodiment wherein the format of the identifier (1202), in an embodiment a context ID (1204), contains a time stamp (comprising Day, Hour, Minute, and Second fields) (1210) and a non-zero odd- numbered Context ID-1 (1206). In an embodiment, a random value may be used instead of the timestamp. While a random value instead of the time stamp may be used, there is a slight likelihood that two random values are the same whilst two different timestamps won’t be the same. Figure 12 illustrates a PDU Set marking in accordance with aspects of the present disclosure, containing fields as set out below.

[0075] In an embodiment, the two most significant bits (1208) in Figure 12 are set to 11 to indicate that the usable bits to represent the Context ID is 62 bits. In an embodiment, the subsequent timestamp fields are arranged as follows: a 9 bitfield (1212) represents 365 days; a 5 bit field (1214) represents 24 hours; a 6 bit field (1216) represents 60 minutes; and a 6 bit field (1218) represents 60 seconds.

[0076] In an embodiment, upon receipt of a packet, in an embodiment a QUIC packet, with an identifier, in an embodiment the Context ID illustrated in Figure 12 being Context- ID-1, the UPF includes PDU Set information in GTP-U headers and one or more UDP packets in a GTP packet. In an embodiment, the UPD routes over a QoS flow with PSDB requirements and PSER requirements received from the SMF. In an embodiment, the UPF registers the identifier, in an embodiment a Context ID, corresponding to the timestamp as the identifier for that semantic of the pay load of the HTTP datagram. In an embodiment, the UPF ignores any packet, in an embodiment a QUIC packet, with a different identifier, in an embodiment a Context ID, part than Context ID-1.

[0077] In an embodiment, packets, in an embodiment QUIC packets, that are tunnelled via the established UDP tunnel contain the same semantic as shown in Figure 3. In an embodiment, the fields of the PDU Set marking are included in the PDU Set marking. In an embodiment, the fields PSSize and NPDS are included if needed. Therefore, according to embodiments, four different semantics can be created depending on the formats that the PDU Set marking may have, as shown in Figure 13. Figure 13 illustrates four possible PDU Setmarkings in accordance with aspects of the present disclosure, containing fields as set out below.

[0078] In an embodiment, upon establishment of a UDP tunnel, the AS constructs the payload of the datagrams, in an embodiment HTTP datagrams, by including the PDU Set marking and one or more encrypted UDP packets. In an embodiment, since the payload of the datagrams, in an embodiment HTTP / 3 datagrams, may have 4 different semantics due to 4 different formats for the PDU Set marking as shown in Figure 13, the identifier, in an embodiment a Context ID, is assigned one of 4 values which are known by the UPF and the AS., In an embodiment, the identifier comprises a non-zero odd-numbered Context ID-1 when PSU set marking has Format 1. In an embodiment, the identifier comprises a non-zero odd-numbered Context ID-2 when PSU set marking has Format 2. In an embodiment, the identifier comprises anon-zero odd-numbered Context ID-3 when PSU set marking has Format 3. In an embodiment, the identifier comprises a non-zero odd-numbered Context ID- 4 when PSU set marking has Format 4.

[0079] In an embodiment, the choice of odd-numbered values for Context ID-1, Context ID-2, Context ID-3, and / or Context ID-4 is due to the values being allocated by the AS which, in an embodiment, acts as a proxy. Figure 14 illustrates an embodiment wherein the identifier (1402), in an embodiment a context ID (1404), contains non-zero odd-numbered Context ID-1, Context ID-2, Context ID-3, or Context ID-4 (1406).

[0080] In an embodiment, the two most significant bits in Figure 14 (1408) are set to 11 to indicate that the usable bits to represent the identifier, in an embodiment a Context ID, is 62 bits. In an embodiment, upon receipt of the packet, in an embodiment a QUIC packet, with an identifier, in an embodiment a Context ID, corresponding to a format of the PDU Set marking in Figure 13, the UPF includes the PDU Set information in GTP-U headers and one or more UDP packets in a GTP packet. In an embodiment, the UPF routes over a QoS flow with PSDB requirements and PSER requirements received from the SMF. In an embodiment, the UPF registers the identifier, in an embodiment a Context ID, corresponding to the format of the PDU Set marking in Figure 13 as the identifier for that semantic of the pay load of the HTTP datagram. In an embodiment, the UPF ignores any packet, in an embodiment a QUIC packet, with a different identifier, in an embodiment a Context ID, than Context ID-1,Context ID-2, Context ID-3, and Context ID-4 via this UDP tunnel. It is noted that the elements of the formats shown in Figure 13 are numbered similarly to the elements of the format shown in Figure 8 but with appropriately incremented numerals (1302, 1304, 1306, 1308, 1310, 1312, 1314, and 1316).

[0081] The identifier in this embodiment, which may be a Context ID, can be allocated dynamically by adding a dynamic allocated part (1510). In an embodiment, the dynamic allocated part comprises a timestamp. In an embodiment, the timestamp stays the same for the duration of the UDP tunnel. In an embodiment, the dynamic part is updated by transmitting a new HTTP / 3 request to reestablish the UDP tunnel. Figure 15 illustrates an embodiment wherein the format of the identifier (1502), in an embodiment a context ID (1504), contains a time stamp (Day, Hour, Minute, and Second) and non-zero odd-numbered Context ID-1, Context ID-2, Context ID-3, or Context ID-4 (1506). In an embodiment, a random value me be used instead of a timestamp. While random values instead of timestamps may be added, there is a likelihood that two random values are the same whilst two different timestamps are different. Figure 15 illustrates a PDU Set marking in accordance with aspects of the present disclosure, containing fields as set out below.

[0082] In an embodiment, the two most significant bits (1508) in Figure 15 are set to 11 to indicate that the usable bits to represent the identifier, in an embodiment a Context ID, is 62 bits. In an embodiment, the subsequent timestamp fields are arranged as follows: a 9 bit field (1512) represents 365 days; a 5 bit field (1514) represents 24 hours; a 6 bit field (1516) represents 60 minutes; and a 6 bit field (1518) represents 60 seconds.

[0083] In an embodiment, upon receipt of a packet, in an embodiment a QUIC packet, with an identifier, in an embodiment a Context ID part such as that shown in Figure 14 or Figure 15, which corresponds to a format of the PDU Set marking in Figure 13, the UPF includes the PDU Set information in GTP-U headers and one or more UDP packets in a GTP packet. In an embodiment, the UPF routes over a QoS flow with PSDB requirements and PSER requirements received from the SMF. In an embodiment, the UPF registers the identifier, in an embodiment a Context ID, corresponding to the timestamp and the format of the PDU Set marking in Figure 14 of Figure 15 as the identifier for that semantic of the payload of the HTTP datagram. In an embodiment, the UPF ignores any packet, in anembodiment a QUIC packet, with a different identifier, in an embodiment a Context ID, part than Context ID-1, Context ID-2, Context ID-3, and Context ID-4 via this UDP tunnel.

[0084] Figure 4 illustrates a UDP datagram (402) containing a QUIC packet (404) comprising a payload of type Stream (406), where the Stream type is used to transfer stream data (408), in accordance with aspects of the present disclosure.

[0085] IETF RFC 9221 defines frames i.e., datagrams to QUIC which unlike Stream frame type are unreliable. These datagrams are not associated with a stream identifier, see Figure 5, which illustrates a QUIC packet comprising a payload of datagram data with a frame type header.

[0086] The unreliable datagram frame type in IETF RFC 9221 does not have the capability for multiplexing once the Stream type frame is not included. IETF RFC 9227 describes HTTP datagrams for conveying unreliable datagrams inside an HTTP connection with multiplexing capability, see Figure 6.

[0087] Figure 6 illustrates an HTTP datagram (602) according to IETF RFC 9227, where Quarter Stream identifier (ID) (604) is used for multiplexing the HTTP datagrams. Quarter Stream ID is a variable-length integer that contains the value of the client-initiated bidirectional stream that the datagram associated with divided by four. The client initiated bidirectional stream has the least significant bit equal to 00, see IETF RFC 9000, therefore a division by 4 simply removes those two least significant bits. Since QUIC stream ID is defined in IETF RFC 9000 to be is a 62 -bit integer with max value 2A62-1, the Quarter Stream ID is a 60-bit integer with max value 2A60-l.

[0088] IETF RFC 9298 defines the protocol that allows an HTTP client to create a tunnel for UDP communications through an HTTP server that acts as a proxy.

[0089] Figure 7 illustrates that UDP proxying HTTP datagram payload (702) contains Context ID (704) and UDP proxying payload (706) which is a semantic of UDP payload, in accordance with aspects of the present disclosure. The Context ID is defined in IETF RFC 9298 and is to identify the semantic of the UDP payload with the reserved value of 0 for UDP payload. All other non-zero values for context ID are allocated by the clientand the UDP proxy when the UDP proxying payload is augmented UDP payload by some extensions.

[0090] According to Solution #24 in 3GPP TR 23.700-70 vl9.0.0, the HTTP datagram is in HTTP / 3 and the semantic of the UDP proxying payload is PDU Set marking in addition to a UDP pay load containing one or more encrypted UDP packets, see Figure 3.

[0091] Solution #24 in 3GPP TR 23.700-70 vl9.0.0 is based on UDP tunnelling and a QUIC connection between a client and a server starts with a handshake as described in IETF RFC 9000. Figure 17 illustrates an example of a simplified handshake followed by HTTP / 3 request to establish a UDP tunnel to associate with HTTP datagrams.

[0092] Figure 17 shows that the client indicates to the server that the client is willing to receive HTTP / 3 datagrams by sending the SETTINGS H3 DATAGRAM set to value 1, see IETF RFC 9227. Figure 17 also shows the CRYPTO frame is being used to integrate the TLS with QUIC, see IETF RFC 9000. For details of how TLS is integrated within QUIC see IETF RFC 9001.

[0093] Once the handshake is done in Figure 17, the client establishes a UDP tunnel to associate with the HTTP datagrams according to IETF RFC 9298, by an HTTP / 3 request for CONNECT method with the protocol connect-udp and the path identifying the AS address and port number.

[0094] In an embodiment, payloads of different datagrams, in one embodiment HTTP datagrams, contain an extension of a UDP payload. Thus, they belong to different streams of the datagrams. In an embodiment, these streams of the datagrams are multiplexed by using the Quarter Stream ID.

[0095] In an embodiment, identifiers, in one embodiment comprising values of Quarter Stream IDs, and their associations with the semantics of the payload of the HTTP datagram are known in advance by both the UPF and the AS. In embodiments where values are predetermined, semantics may be defined prior to a handshake and negotiation process described above.

[0096] In an embodiment, the semantic of the pay load of the HTTP datagram is identified by assigning a specific value to the Quarter Stream ID, such as follows:Quarter Stream ID value(l) identifies Semantic(l).Quarter Stream ID_value(2) identifies Semantic(2).Quarter Stream ID value(M) identifies Semantic(M).

[0097] In an embodiment, the identifiers of the semantics of the payload of the HTTP datagram, Quarter Stream ID value (k), where k = 1, 2, ...M, are known to both UPF, in one embodiment acting as a client, and AS, in one embodiment acting as a UDP proxy. Thus, the client determines the semantic of the receipt payload of the datagram, in one embodiment an HTTP datagram, by value of the Quarter Stream ID.

[0098] In one embodiment, the UPF and the AS negotiate for the identifiers, in one embodiment comprising values for Quarter Stream IDs or Context IDs and their associations with the semantics of the payload of the HTTP datagram.

[0099] In one embodiment, the identifiers of the semantics of the payload of the datagram, Quarter Stream ID value (k), where k = 1, 2, ...M, are negotiated between the UPF and the AS at the time of handshake, see Figure 18. Figure 18 illustrates a handshake procedure in accordance with aspects of the present disclosure.

[0100] The AS informs the UPF by including SEMANTIC in the initial connection, where SEMANTIC is defined below:SEMANTIC {Type (i) = one Octet value,Length (i),Semantic Data (..), where Semantic Data is:Quarter Stream ID value(l) identifies Semantic(l).Quarter Stream ID_value(2) identifies Semantic(2).Quarter Stream ID value(M) identifies Semantic(M).

[0101] Figure 19 illustrates a further handshake procedure in accordance with aspects of the present invention. The handshake procedure of Figure 19 is different from Key issue #2 in 3GPP TR 23.700-70 vl9.0.0 in the sense that both the client (1904) and the server (1906) transmit data to each other.

[0102] Figure 19 depicts an embodiment in which both the UPF / client (1904) and the AS / server (1906) inform each other about identifiers of the semantics (1902) as certain values for Quarter Stream ID.

[0103] Figure 23 illustrates an embodiment in which the AS multiplexes different semantics (2302) of the payload of the HTTP datagrams if the data to be transmitted comprises more than one semantic. In the illustrated embodiment, the different semantics (2302) are shown multiplexed sequentially and in pairs with respective Quarter Stream ID values (2304) and there are M such pairs.

[0104] In an embodiment, SEMANTIC in the negotiation shown in Figure 19 contains Context ID as defined in IETF RFC 9298; meaning SEMANTIC is defined as shown below.SEMANTIC {Type (i) = one Octet value,Length (i),Semantic Data (..), has Semantic Data which is defined as:Context ID value(l) identifies Semantic(l).Context ID_value(2) identifies Semantic(2).Context ID value(M) identifies Semantic(M).

[0105] The values for Context ID are defined in IETF RFC 9298 as being non-zero 62- bit integers (1 to 2A62-1) if the semantic is an extension to the defined semantic in IETF RFC 9298, which is UDP payload. Furthermore, the allocated values for the ContextID by the client are even, whilst the allocated values for the Context ID by the server are odd. Upon completion of the handshake, once both the client and the server have allocated the values for the Context IDs of the semantics for the payload of the HTTP datagram and informs each other about this allocation, the allocated values of the Context ID are registered for the UDP tunnel. Note that the registration of the values for the Context ID is required by IETF RFC 9298.

[0106] Figure 24 illustrates an embodiment in which the AS may transmit different semantics (2402) of the payload of the HTTP datagrams via one UDP tunnel if the data to be transmitted comprises more than one semantic. In the illustrated embodiment, the different semantics (2402) are shown multiplexed sequentially and in pairs with respective Context ID values (2404) and there are M such pairs.

[0107] It should be noted that the procedure for UDP tunnelling described herein is readily expandable to apply to IP tunnelling as described in IETF RFC 9484 and Ethernet tunnelling.

[0108] For instance, Figure 20 illustrates an embodiment similar to that illustrated in Figure 19, comprising a client (2004) and server (2006) communicating a semantic (2002), wherein the server (2006) is an IP proxy (see IETF RFC 9484) and connect-ip protocol is used for CONNECT method.

[0109] Figure 21 illustrates a further handshake procedure in accordance with aspects of the present disclosure, in which an embodiment is shown similar to that illustrated in Figure 19, comprising a client (2104) and server (2106) communicating a semantic (2102), wherein the server is an Ethernet proxy and connect-ethernet protocol is used for CONNECT method.

[0110] In an embodiment, to multiplex different semantics for QUIC frames of type Stream as shown in Figure 4 within a QUIC connection, Stream ID is used. Figure 22 depicts a further handshake procedure in accordance with the present disclosure, in which an embodiment of the negotiation is illustrated. In Figure 22, SEMANTIC (2202) communicated between client (2202) and server (2204) in Figure 22 is defined as follows: SEMANTIC {Type (i) = one Octet value,Length (i),has Semantic Data which is defined as:Stream-ID value(l) identifies Semantic(l). Stream ID_value(2) identifies Semantic(2).Stream ID value(M) identifies Semantic(M).

[0111] Figure 25 illustrates an embodiment in which several stream data with different semantics (2502) for the QUIC Stream frame are multiplexed if the data to be transmitted comprises more than one semantic. In the illustrated embodiment, the different semantics (2502) are shown multiplexed sequentially and in pairs with respective Stream ID values (2504) and there are M such pairs.

[0112] In an embodiment, it is possible to refer to several semantics within the same tunnel for the HTTP CONNECT method. In an embodiment, it is possible to have several UDP tunnels for the HTTP CONNECT method by negotiating the SEMANTIC of Figure 23 to contain a Context ID as defined in IETF RFC 9298 for multiple UDP tunnels.

[0113] In an embodiment, SEMANTIC is defined as follows: SEMANTIC {Type (i) = one Octet value,Length (i),Semantic Data (..), has Semantic Data which is defined as:Context ID value(l) identifies Semantic(l) for Quarter Stream ID value(k). Context ID_value(2) identifies Semantic(2) for Quarter Stream ID value(k).Context ID value(M) identifies Semantic(M) for Quarter Stream ID value(k).Quarter Stream ID value(k) may be the same for one or more Context ID values and the related Semantics. For instance, Context ID value(l) identifying Semantic (1) may be the same as Context ID value (2) identifying Semantic (2) for two different QuarterStream ID Values. This is due to the fact that Quarter Stream ID values refer to different tunnels (in one embodiment UDP tunnels) for the same HTTP CONNECT method.

[0114] Values for Context ID are defined in IETF RFC 9298 as being non-zero 62 -bit integers (1 to 2A62-1), if the semantic is an extension to the defined semantic in IETF RFC 9298 [8], which is UDP payload. Values for the Context ID allocated by the clientare even, whilst the allocated values for the Context ID by the server, are odd. Upon completion of the handshake, once both the client and the server have allocated values for the Context IDs of the semantics for the payload of the HTTP datagram and informed each other about this allocation, the allocated values of the Context ID are registered for the UDP tunnel.

[0115] Figure 25b illustrates an embodiment wherein the AS multiplexes different semantics of the payload of the HTTP datagrams via different UDP tunnels if the data to be transmitted comprises more than one semantic. As Figure 24b shows, the ContextlD Value(l) (2504b) refers to Semantic(l) (2502b) in one tunnel identified by Quarter Stream ID Value(l) (2506b), while it may refer to Semantic(2) (2508b) in another tunnel identified by Quarter Stream ID_Value(2) (2510b).

[0116] Referring to Figure 16, which illustrates communications between network entities including a UE (1602), UPF (1604), SMF (1606), Policy Control Function (PCF) (1608), Application Function (AF) (1610), and AS (1612): In an embodiment, the following communications and actions take place.

[0117] (1614). An AF, when requesting an AF session towards the 3GPP network(PCF / NEF), includes additional information indicating to the 3 GPP network that the UPF needs to establish a QUIC / connect-udp session with a HTTP / 3 proxy and indicates that the UPF can identify PDU Set information by inspecting PDU Set information contained within HTTP datagrams. The AF also including the address of a HTTP / 3 proxy server where the UPF will need to establish a QUIC session.

[0118] (1616). The PCF in the 3GPP network provides PCC rules where the PCC rules include the information provided by the AF in step 1.

[0119] (1618). The SMF constructs N4 rules based on the PCC rules where the N4 rules include uplink and downlink Packet Detection Rules indicating to the UPF that: a. for uplink packets sent from a specific UE (or any UE) to a specific AS, the UPF would need to establish a QUIC / connect-udp session and route the packet within a HTTP datagram to the AS address.b. For downlink packets received from the QUIC connection by the UPF over N6, include configuration information indicating the UPF to: i. Extract the UDP packet from the received HTTP datagram. ii. Enable PDU Set identification and retrieve PDU Set information from HTTP datagram. The HTTP datagram includes a new Context ID indicating PDU Set information. iii. Route the extracted PDU Set marking and one or more UDP packets over a QoS flow with PSDB requirements and PSER requirements towards the RAN.

[0120] (1620). The SMF sends the N4 rules to the UPF that supports an HTTP / 3 client to establish a QUIC connection to create a tunnel for UDP communications with an HTTP / 3 server when a data packet is received that matches the PDR provided by the SMF.

[0121] (1622). Upon the receipt of the N4 rule, the UPF acting as the client, constructs the UDP tunnelling request to be transmitted to the AS) acting as the UDP proxy. The UDP tunnelling request identifies connect-udp and the exact location of data transmission. In an embodiment, this step is performed if the one or more semantics of the pay load of the HTTP datagram are predetermined by the client (UPF) and the AS and those semantics are identified by the values for a Context ID. In an embodiment, this step is performed if the one or more semantics of the payload of the HTTP datagram are predetermined by the client (UPF) and the server (AS) and those semantics are identified by the values for a Quarter Stream ID. In an embodiment, if the one or more semantics of the payload of the HTTP datagram are not predetermined by the client (UPF) and the server (AS), those semantics are communicated as SEMANTIC (1802) in the handshake between client (1804) and server (1806) shown in Figure 18. In an embodiment, SEMANTIC has a configuration according to paragraph

[0105] , In an embodiment, SEMANTIC has a configuration according to paragraph

[0109] ,(1624). Upon the receipt of the UDP tunnelling request and identifying the target, the AS acting as UDP proxy transmits the successful status code towards the UPF to confirm the establishment of the UDP tunnel. Alternatively, upon completing the handshake, the client requests to establish the UDP tunnel as shown in Figure 18, and the AS acting as UDP proxytransmits the successful status code towards the UPF to confirm the establishment of the UDP tunnel.(1626). Upon establishment of the UDP tunnel between the UPF and the AS, the AS includes PDU Set marking and one or more encrypted UDP packets within an HTTP datagram that carry different semantic from the payload of a UDP packet, defined having the Context ID field set to zero. The AS encodes the PDU Set marking and the one or more encrypted UDP packets by using the HTTP datagrams with the Context ID field set to a nonzero odd-numbered value that is obtained in accordance with one or more embodiments described above. The Context ID value is odd-numbered since the AS acts as the UDP proxy. Upon receipt of the QUIC packets, the UPF may act according to embodiments described above.(1628). The encrypted packets are transmitted via a QoS flow with PSDB requirements and PSER requirements.

[0122] Figure 26 illustrates an example of a processor 2600 in accordance with aspects of the present disclosure. The processor 2600 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 2600 may include a controller 2602 configured to perform various operations in accordance with examples as described herein. The processor 2600 may optionally include at least one memory 2604, which may be, for example, an L1 / L2 / L3 cache. Additionally, or alternatively, the processor 2600 may optionally include one or more arithmetic-logic units (AEUs) 2606. 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).

[0123] The processor 2600 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 2600) 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).

[0124] The controller 2602 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 2600 to cause the processor 2600 to support various operations in accordance with examples as described herein. For example, the controller 2602 may operate as a control unit of the processor 2600, generating control signals that manage the operation of various components of the processor 2600. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating timing of operations.

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

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

[0127] The memory 2604 may store computer-readable, computer-executable code including instructions that, when executed by the processor 2600, cause the processor 2600 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 2602 and / or the processor 2600 may be configured to execute computer-readable instructions stored in the memory 2604 to cause the processor 2600 to perform various functions. For example, the processor 2600 and / or the controller 2602 may be coupled with or to the memory 2604, the processor 2600, the controller 2602, and the memory 2604 may be configured to perform various functions described herein. In some examples, the processor 2600 may include multiple processors and the memory 2604 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.

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

[0129] The processor 2600 may support wireless communication in accordance with examples as disclosed herein. The processor 2600 may be configured to or operable to support a means for determining at least one identifier that identifies a respective at least one semantic of a datagram payload, constructing a packet comprising a datagram payloadcomprising at least one such identifier, and transmitting, to a first network entity, the constructed packet. Alternatively, the processor 2600 may be configured to or operable to support a means for receiving a packet constructed by a second network entity and determining, from at least one identifier in a datagram payload of the packet, a semantic of the datagram payload.

[0130] Figure 27 illustrates an example of a NE 2700 in accordance with aspects of the present disclosure. The NE 2700 may include a processor 2702, a memory 2704, a controller 2706, and a transceiver 2708. The processor 2702, the memory 2704, the controller 2706, or the transceiver 2708, 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.

[0131] The processor 2702, the memory 2704, the controller 2706, or the transceiver 2708, 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.

[0132] The processor 2702 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 2702 may be configured to operate the memory 2704. In some other implementations, the memory 2704 may be integrated into the processor 2702. The processor 2702 may be configured to execute computer-readable instructions stored in the memory 2704 to cause the NE 2700 to perform various functions of the present disclosure.

[0133] The memory 2704 may include volatile or non-volatile memory. The memory 2704 may store computer-readable, computer-executable code including instructions when executed by the processor 2702 cause the NE 2700 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 2704 or another type of memory. Computer-readable media includes both non- transitory computer storage media and communication media including any medium thatfacilitates 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.

[0134] In some implementations, the processor 2702 and the memory 2704 coupled with the processor 2702 may be configured to cause the NE 2700 to perform one or more of the functions described herein (e.g., executing, by the processor 2702, instructions stored in the memory 2704). For example, the processor 2702 may support wireless communication at the NE 2700 in accordance with examples as disclosed herein. The NE 2700 may be configured to support a means for determining at least one identifier that identifies a respective at least one semantic of a datagram payload, constructing a packet comprising a datagram payload comprising at least one such identifier, and transmitting, to a first network entity, the constructed packet. Alternatively, the NE 2700 may be configured to or operable to support a means for receiving a packet constructed by a second network entity and determining, from at least one identifier in a datagram payload of the packet, a semantic of the datagram payload.

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

[0136] In some implementations, the NE 2700 may include at least one transceiver 2708. In some other implementations, the NE 2700 may have more than one transceiver 2708. The transceiver 2708 may represent a wireless transceiver. The transceiver 2708 may include one or more receiver chains 2710, one or more transmitter chains 2712, or a combination thereof.

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

[0138] A transmitter chain 2712 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 2712 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 2712 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 2712 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0139] Figure 28 illustrates a flowchart of a method 2800 in accordance with aspects of the present disclosure. The operations of the method may be implemented by a NE as described herein. In some implementations, the NE may execute a set of instructions to control the function elements of the UE to perform the described functions.

[0140] At 2802, the method 2800 may include determining at least one identifier that identifies a respective at least one semantic of a datagram payload. The operations of 2802 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2802 may be performed by a NE as described with reference to Figure 27.

[0141] At 2804, the method 2800 may include constructing a packet comprising a datagram payload comprising at least one such identifier. The operations of 2804 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2804 may be performed by a UE as described with reference to Figure 27.

[0142] At 2806, the method 2800 may include transmitting, to a first network entity, the constructed packet. The operations of 2806 may be performed in accordance with examplesas described herein. In some implementations, aspects of the operations of 2806 may be performed a UE as described with reference to Figure 27.

[0143] It should be noted that the method 2800 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.

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

[0145] At 2902, the method 2900 may include receiving a packet constructed by a second network entity. The operations of 2902 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2902 may be performed by a NE as described with reference to Figure 27.

[0146] At 2904, the method 2900 may include determining, from at least one identifier in a datagram payload of the packet, a semantic of the datagram payload. The operations of 2904 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2904 may be performed by a NE as described with reference to Figure 27.

[0147] Figure 30 illustrates a flowchart of a method 3000 in accordance with aspects of the present disclosure. The operations of the method 3000 may be implemented by a NE as described herein. In some implementations, the NE may execute a set of instructions to control the function elements of the NE to perform the described functions.

[0148] At 3002, the method 3000 may include receiving, from a second network entity, at least one semantic, or indication thereof, for a datagram payload and at least one first identifier for identifying a respective one of the at least one semantic. The operations of 3002 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 3002 may be performed by a NE as described with reference to Figure 27.

[0149] The present disclosure provides a second network entity for wireless communication, comprising: at least one memory; and at least one processor coupled with at least one memory and configured to cause the second network entity to: determine at least one identifier associated with at least one semantic of a datagram payload; construct a packet comprising a datagram payload that includes the at least one identifier; and transmit, to a first network entity, the constructed packet.

[0150] The at least one identifier being associated with at least one semantic of a datagram payload may comprise the at least one identifier identifying at least one semantic of a datagram payload. The at least one identifier may identify a respective at least one semantic of a datagram payload.

[0151] A datagram may be described as a basic transfer unit associated with a packet- switched network. A datagram may be structured in header and payload sections.

[0152] A semantic may be an arrangement, order, and / or format of data which confers additional information than that provided by the data itself and / or adds further meaning to the data. The additional information and / or further meaning may be identifiable and / or derivable from the semantic or from a combination of the semantic and the data.

[0153] An identifier may be or comprise data which enables and / or facilitates the identification of other data. At least one identifier may comprise a number. The number may be non-zero. The number may be an odd number. The number may be a 62 -bit integer. The number may be in the range 0 to 2A62 - 1.

[0154] Placing one or more identifiers that identify one or more respective semantics of a datagram payload into a packet with the datagram payload may allow a recipient to agree with the sender on an association or correspondence between that identifier and that semantic. This may facilitate communication of payloads having different semantics.

[0155] At least one identifier may comprise a context identifier value. The datagram payload may comprise a User Datagram Protocol, UDP, proxying payload. Constructing the packet may comprise arranging at least one identifier in a context identifier field of the UDP proxying payload.

[0156] This may enable the repurposing of the existing context identifier field to improve the capability to identify different semantic payloads. The UDP proxying payload may be or comprise a semantic of UDP payload.

[0157] At least one identifier may comprise a quarter stream identifier value. The datagram payload may be a hypertext transfer protocol, HTTP, datagram payload. Constructing the packet may comprise arranging at least one identifier in a quarter stream identifier field of the HTTP datagram payload. The number may be a 60-bit integer. The number may be in the range 0 to 2A60 - 1.

[0158] A quarter stream identifier may comprise an encoded identifier that supports independent multiplexed datagram flows.

[0159] This may enable the repurposing of the existing quarter stream identifier field to improve the capability to identify different semantic payloads.

[0160] Both the quarter stream identifier field and the context identifier field may contain at least one identifier. This may provide redundancy in the event that one of the fields is unidentifiable due to, for example, data corruption or similar communication errors.

[0161] The at least one semantic may be associated with or identify a protocol data unit, PDU Set format.

[0162] The at least one processor may be configured to cause the second network entity to assign the at least one identifier to the at least one semantic prior to determining the identifier. In other words, the second network entity may establish an association between one or more identifiers and one or more semantics prior to sending a packet. In subsequent communications, the second entity is therefore capable of referring to its earlier-established association to identify a semantic of a datagram payload or to determine an appropriate identifier for constructing a packet.

[0163] The at least one identifier, the at least one semantic, and an association between the at least one identifier and the at least one semantic may be predetermined.

[0164] At least one identifier may comprise an odd value.

[0165] The at least one processor may be configured to cause the second network entity to include in the identifier at least one dynamic portion.

[0166] The at least one processor may be configured to cause the second network entity to receive a request for UDP tunnel establishment, at least one processor may be configured to cause the second network entity to update the at least one dynamic portion in response to the request for UDP tunnel establishment.

[0167] The request for establishment may be or comprise a request for reestablishment.

[0168] The dynamic portion may comprise a timestamp. The dynamic portion may comprise a random value.

[0169] Dynamic portions, such as timestamps and randomly generated values, tend to provide additional information that further improve the capability to identify payload semantics, not least by enabling an identifier value to be different at different values of the dynamic portion and still correspond to the same semantic. This may have security advantages, such as enabling continual updating of the semantic identification procedure with new identifier values.

[0170] The constructed packet may be transmitted via a UDP tunnel.

[0171] The constructed packet may be a quick UDP internet connection, QUIC, packet.

[0172] Constructing the packet may comprise encoding a PDU Set format and one or more encrypted packets with an identifier field comprising at least one identifier. The PDU Set format may comprise a PDU Set marking.

[0173] The present disclosure provides a first network entity for wireless communication, comprising: at least one memory; and at least one processor coupled with at least one memory and configured to cause the first network entity to: receive a packet; and determine, based at least in part on an identifier in a datagram payload of the packet, a semantic of the datagram payload. The packet may be constructed by a second network entity.

[0174] The present disclosure provides a method for wireless communication performable by a second network entity, comprising: determining at least one identifier associated with at least one semantic of a datagram payload; constructing a packet comprisinga datagram payload comprising the at least one identifier; and transmitting, to a first network entity, the constructed packet.

[0175] The at least one identifier being associated with at least one semantic of a datagram payload may comprise the at least one identifier identifying at least one semantic of a datagram payload. The at least one identifier may identify a respective at least one semantic of a datagram payload.

[0176] A datagram may be described as a basic transfer unit associated with a packet- switched network. A datagram may be structured in header and payload sections.

[0177] A semantic may be an arrangement, order, and / or format of data which confers additional information than that provided by the data itself and / or adds further meaning to the data. The additional information and / or further meaning may be identifiable and / or derivable from the semantic or from a combination of the semantic and the data.

[0178] An identifier may be or comprise data which enables and / or facilitates the identification of other data. At least one identifier may comprise a number. The number may be non-zero. The number may be an odd number. The number may be a 62 -bit integer. The number may be in the range 0 to 2A62 - 1.

[0179] Placing one or more identifiers that identify one or more respective semantics of a datagram payload into a packet with the datagram payload may allow a recipient to agree with the sender on an association or correspondence between that identifier and that semantic. This may facilitate communication of payloads having different semantics.

[0180] At least one identifier may comprise a context identifier value. The datagram payload may comprise a User Datagram Protocol, UDP, proxying payload. Constructing the packet may comprise arranging at least one identifier in a context identifier field of the UDP proxying payload.

[0181] This enables the repurposing of the existing context identifier field to improve the capability to identify different semantic payloads. The UDP proxying payload may be or comprise a semantic of UDP payload.

[0182] At least one identifier may comprise a quarter stream identifier value. The datagram payload may be a hypertext transfer protocol, HTTP, datagram payload. Constructing the packet may comprise arranging at least one identifier in a quarter stream identifier field of the HTTP datagram payload. The number may be a 60-bit integer. The number may be in the range 0 to 2A60 - 1.

[0183] A quarter stream identifier may comprise an encoded identifier that supports independent multiplexed datagram flows.

[0184] This may enable the repurposing of the existing quarter stream identifier field to improve the capability to identify different semantic payloads.

[0185] Both the quarter stream identifier field and the context identifier field may contain at least one identifier. This provides redundancy in the event that one of the fields is unidentifiable due to, for example, data corruption or similar communication errors.

[0186] The at least one semantic may relates to and / or identify a protocol data unit, PDU, set format.

[0187] The method may comprise assigning the identifier to the semantic prior to determining the identifier. In other words, an association may be established between one or more identifiers and one or more semantics prior to sending a packet. In subsequent communications, a reference may be made to the earlier-established association to identify a semantic of a datagram payload or to determine an appropriate identifier for constructing a packet.

[0188] The at least one identifier, the at least one semantic, and an association between the at least one identifier and the at least one semantic may be predetermined.

[0189] At least one identifier may comprise an odd value.

[0190] The method may comprise including in the identifier at least one dynamic portion.

[0191] The method may comprise receiving a request for UDP tunnel establishment. The method may comprise updating the at least one dynamic portion in response to the received request for UDP tunnel establishment.

[0192] The request for establishment may be or comprise a request for reestablishment.

[0193] The dynamic portion may comprise a timestamp. The dynamic portion may comprise a random value.

[0194] Dynamic portions, such as timestamps and randomly generated values, tend to provide additional information that further improve the capability to identify payload semantics, not least by enabling an identifier value to be different at different values of the dynamic portion and still correspond to the same semantic. This may have security advantages, such as enabling continual updating of the semantic identification procedure with new identifier values.

[0195] The method may include transmitting the constructed packet via a UDP tunnel.

[0196] The constructed packet may be a quick UDP internet connection, QUIC, packet.

[0197] Constructing the packet may comprise encoding a PDU Set format and one or more encrypted packets with an identifier field comprising at least one identifier. The PDU Set format may comprise a PDU Set marking.

[0198] The present disclosure provides a method for wireless communication performable by a first network entity, comprising: receiving a packet; and determining, based at least in part on an identifier in a datagram pay load of the packet, a semantic of the datagram payload. The packet may be constructed by a second network entity

[0199] 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: determine at least one identifier associated with at least one semantic of a datagram payload; construct a packet comprising a datagram payload comprising the at least one identifier; and transmit, to a first network entity, the constructed packet.

[0200] The at least one identifier being associated with at least one semantic of a datagram payload may comprise the at least one identifier identifying at least one semantic of a datagram payload. The at least one identifier may identify a respective at least one semantic of a datagram payload.

[0201] A datagram may be described as a basic transfer unit associated with a packet- switched network. A datagram may be structured in header and payload sections.

[0202] A semantic may be an arrangement, order, and / or format of data which confers additional information than that provided by the data itself and / or adds further meaning to the data. The additional information and / or further meaning may be identifiable and / or derivable from the semantic or from a combination of the semantic and the data.

[0203] An identifier may be or comprise data which enables and / or facilitates the identification of other data. At least one identifier may comprise a number. The number may be non-zero. The number may be an odd number. The number may be a 62 -bit integer. The number may be in the range 0 to 2A62 - 1.

[0204] Placing one or more identifiers that identify one or more respective semantics of a datagram payload into a packet with the datagram payload may allow a recipient to agree with the sender on an association or correspondence between that identifier and that semantic. This may facilitate communication of payloads having different semantics.

[0205] At least one identifier may comprise a context identifier value. The datagram payload may comprise a User Datagram Protocol, UDP, proxying payload. Constructing the packet may comprise arranging at least one identifier in a context identifier field of the UDP proxying payload.

[0206] This may enable the repurposing of the existing context identifier field to improve the capability to identify different semantic payloads. The UDP proxying payload may be or comprise a semantic of UDP payload.

[0207] At least one identifier may comprise a quarter stream identifier value. The datagram payload may be a hypertext transfer protocol, HTTP, datagram payload. Constructing the packet may comprise arranging at least one identifier in a quarter stream identifier field of the HTTP datagram payload. The number may be a 60-bit integer. The number may be in the range 0 to 2A60 - 1.

[0208] A quarter stream identifier may comprise an encoded identifier that supports independent multiplexed datagram flows.

[0209] This may enable the repurposing of the existing quarter stream identifier field to improve the capability to identify different semantic payloads.

[0210] Both the quarter stream identifier field and the context identifier field may contain at least one identifier. This provides redundancy in the event that one of the fields is unidentifiable due to, for example, data corruption or similar communication errors.

[0211] The semantic may be associated with or identify a protocol data unit, PDU, set format.

[0212] The at least one controller may be configured to cause the processor to assign the identifier to the semantic prior to determining the identifier. In other words, the processor may establish an association between one or more identifiers and one or more semantics prior to sending a packet. In subsequent communications, the processor is therefore capable of referring to its earlier-established association to identify a semantic of a datagram payload or to determine an appropriate identifier for constructing a packet.

[0213] The at least one identifier, the at least one semantic, and an association between the at least one identifier and the at least one semantic may be predetermined.

[0214] At least one identifier may comprise an odd value.

[0215] The at least one controller may be configured to cause the processor to include in the identifier at least one dynamic portion.

[0216] The at least one controller may be configured to cause the processor to receive a request for UDP tunnel establishment. The at least one controller may be configured to cause the processor to update the at least one dynamic portion in response to the received request for UDP tunnel establishment.

[0217] The request for establishment may be or comprise a request for reestablishment.

[0218] The dynamic portion may comprise a timestamp. The dynamic portion may comprise a random value.

[0219] Dynamic portions, such as timestamps and randomly generated values, tend to provide additional information that further improve the capability to identify payloadsemantics, not least by enabling an identifier value to be different at different values of the dynamic portion and still correspond to the same semantic. This may have security advantages, such as enabling continual updating of the semantic identification procedure with new identifier values.

[0220] The constructed packet may be transmitted via a UDP tunnel.

[0221] The constructed packet may be a quick UDP internet connection, QUIC, packet.

[0222] Constructing the packet may comprise encoding a PDU Set format and one or more encrypted packets with an identifier field comprising at least one identifier. The PDU Set format may comprise a PDU Set marking.

[0223] 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 a packet; and determine, based at least in part on an identifier in a datagram payload of the packet, a semantic of the datagram payload. The packet may be constructed by a second network entity.

[0224] A first network entity may comprise or implement a user plane function.

[0225] A user plane function may act as a client.

[0226] A second network entity may comprise an AS.

[0227] An AS may act as a UDP proxy.

[0228] Solution #24 in 3GPP TR 23.700-70 vl9.0.0 describes how the Context ID as described in IETF RFC 9298 can be used to identify the PDU Set information of a fully encrypted UDP packets tunnelled over N6 reference point. However, it is needed to identify the communicated packets tunnelled over N6 reference point. The present disclosure may use the Context ID which is a part of a HTTP datagram or a UDP proxying HTTP datagram of a QUIC packet for such an identification. The present disclosure may use the Quarter Stream ID which is a part of a HTTP datagram of a QUIC packet for such an identification. The Context ID and / or Quarter Stream ID may be fully or partially allocated as a predefined value which is known by the peers in the packets communications, that the value refers tosemantic of the payload of the HTTP Datagram being of PDU Set information and one or more encrypted PDU packets.

[0229] The present disclosure also provides a negotiation for the values for the Quarter Stream ID or Context ID to identify the semantic of the payload of the HTTP datagram. The identifiers as values for the Quarter Stream ID or Context ID may be predetermined by the peers or shared at the time of handshake for QUIC connection. In addition, predetermined values for the Quarter Stream ID may be shared by the peers by other means than negotiation.

[0230] There is further provided a method comprising: receiving by a first network entity from a third network entity a message comprising: one or more rules to establish a UDP tunnel for transmission of a data; transmitting by the first network entity to a second network entity, a request comprising at least: a CONNECT method, wherein the CONNECT method uses connect-udp protocol; and a path, wherein the path is a target at the second network entity receiving by the first network entity from the second network entity, a response, wherein the response confirms establishment of the UDP tunnel; receiving by the first network entity from the second network entity, via the UDP tunnel a QUIC packet, wherein the QUIC packet comprising an HTTP datagram comprising: a first Context ID, wherein the first Context ID is randomly chosen by the second network entity since the payload of the HTTP datagram is according to one semantic due to the one or more rules; or a second Context ID, wherein the second Context ID: is predetermined by the first network entity and the second network entity; and corresponds to a predetermined semantic for the payload of the HTTP datagram.

[0231] The second Context ID may comprise a predetermined part and a dynamic part.

[0232] The dynamic part may comprise a timestamp or a random value.

[0233] The first network entity may be a UPF. The second network entity may be an AS. The third network entity may be an SMF.

[0234] The one or more rules may be N4 rules.

[0235] There is further provided a method comprising: a handshake procedure comprising: sending by a client to a server a first message comprising at least one or morefirst identifiers; receiving by the client from the server a second message comprising at least one or more second identifiers; and establishing by the client a UDP, IP, or Ethernet tunnel towards the server for transmission of a data via the tunnel, wherein the data comprises one or more datagram payloads multiplexed as one or more streams, wherein: if sent by the client, semantics of the one or more datagram payloads are identified by the one or more first identifiers; and if sent by the server, semantics of the one or more datagram payloads are identified by the one or more second identifier.

[0236] The one or more first identifiers and the one or more second identifiers may identify the semantic of the datagram payloads in relation to: the one or more datagram streams; or one or more context identifiers.

[0237] There is further provided a method comprising: a handshake procedure; and establishing by the client a UDP, IP, or Ethernet tunnel towards the server for transmission of a data via the tunnel, wherein the data comprises one or more datagram payloads multiplexed as one or more streams, wherein: the one or more streams corresponds to one or more values to identify semantics of the one or more datagram payloads.

[0238] The one or more values for the one or more streams may be predetermined.

[0239] It should be noted that the methods described herein describe possible implementations, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0240] 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, the disclosure 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.

[0241] 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 TrafficSteering, Switching, Splitting; AS: Application Server; BRID: Broadcast Remote Identification; BVLOS: Beyond Visual Line of Sight; C2: Command and Control; CAA: Civil Aviation Administration; DCN: Dedicated Core Network; DNN: Data Network Name; DNS: Domain Name System; ePDG: evolved Packet Data Gateway; ePCO: Extended Protocol Configuration Options; EDN: Edge Data Network; 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; HPLMN: Home PLMN; HSS: Home Subscriber Server; IE: Information Element; IMSI: International Mobile Subscriber Identity; IP: Internet Protocol; 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 Error Rate; PS Info: PDU Set Information; 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; SGW: Serving Gateway; 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 EnablementServer; 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; 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 second network entity for wireless communication, comprising: at least one memory; and at least one processor coupled with at least one memory and configured to cause the second network entity to: determine at least one identifier associated with at least one semantic of a datagram payload; construct a packet comprising a datagram payload that includes the at least one identifier; and transmit, to a first network entity, the constructed packet.

2. The second network entity of claim 1 , wherein the at least one identifier comprises a context identifier value, wherein the datagram payload comprises a User Datagram Protocol, UDP, proxying payload, and wherein to construct the packet, the at least one processor is configured to cause the second network entity to arrange the at least one identifier in a context identifier field of the UDP proxying payload.

3. The second network entity of claim 1 or claim 2, wherein the at least one identifier comprises a quarter stream identifier value, wherein the datagram payload comprises a hypertext transfer protocol, HTTP, datagram payload, and wherein to construct the packet, the at least one processor is configured to cause the second network entity to arrange the at least one identifier in a quarter stream identifier field of the HTTP datagram payload.

4. The second network entity of any preceding claim, wherein the at least one semantic is associated with or identifies a protocol data unit, PDU, set marking format.

5. The second network entity of any preceding claim, wherein the at least one processor is configured to cause the second network entity to, , assign the at least one identifier to the at least one semantic prior to determining the at least one identifier.

6. The second network entity of any preceding claim, wherein the at least one identifier, the at least one semantic, and an association between the at least one identifier and the at least one semantic are predetermined.

7. The second network entity of any preceding claim, wherein the at least one identifier comprises an odd value.

8. The second network entity of any preceding claim, wherein the at least one processor is configured to cause the second network entity to include in the at least one identifier at least one dynamic portion.

9. The second network entity of claim 8, wherein the at least one processor is configured to cause the second network entity to: receive a request for UDP tunnel establishment; and update the at least one dynamic portion in response to the received request for UDP tunnel establishment.

10. The second network entity of claim 8 or claim 9, wherein the dynamic portion comprises a timestamp or a randomly generated value.

11. The second network entity of any preceding claim, wherein the constructed packet is transmitted via a UDP tunnel.

12. The second network entity of any preceding claim, wherein the constructed packet is a quick UDP internet connection, QUIC, packet.

13. The second network entity of any preceding claim, wherein to construct the packet, the at least one processor is configured to cause the second network entity to encode a PDU Set marking and one or more encrypted packets with an identifier field comprising the at least one identifier.

14. The second network entity of any preceding claim, wherein the first network entity comprises a user plane function, UPF.

15. The second network entity of any preceding claim, wherein the second network entity comprises an application server.

16. A first network entity for wireless communication, comprising: at least one memory; and at least one processor coupled with at least one memory and configured to cause the first network entity to: receive a packet; and determine, based at least in part on an identifier in a datagram payload of the received packet, a semantic of the datagram payload.

17. A method for wireless communication performable by a second network entity, comprising: determining at least one associated with at least one semantic of a datagram payload; constructing a packet comprising a datagram payload that includes the at least one identifier; and transmitting, to a first network entity, the constructed packet.

18. A method for wireless communication performable by a first network entity, comprising: receiving a packet; and determining, based at least in part on an identifier in a datagram payload of the received packet, a semantic of the datagram payload.

19. A processor for wireless communication, comprising: at least one controller coupled with at least one memory and configured to cause the processor to: determine at least one identifier associated with at least one semantic of a datagram payload;construct a packet comprising a datagram payload that includes the at least one identifier; and transmit, to a first network entity, the constructed packet.

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 a packet; and determine, based at least in part on an identifier in a datagram payload of the packet, a semantic of the datagram payload.

Images