Handling datagrams with sequential internet protocol packets in a wireless communication network

Abstract

Various aspects of the present disclosure relate to a method (1500) performed by a UE, the method (1500) comprising: transmitting (1502), to a first network entity of a wireless communication network, a data flow of a multi-access protocol data unit (MA PDU) session, wherein the data flow comprises one or more datagrams, each datagram comprising: an Internet protocol (IP) data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets.

Description

HANDLING DATAGRAMS WITH SEQUENTIAL INTERNET PROTOCOL PACKETS IN A WIRELESS COMMUNICATION NETWORKTECHNICAL FIELD

[0001] The subject matter disclosed herein relates generally to the field of implementing handling datagrams with sequential Internet Protocol (IP) packets in a wireless communication network. In particular, this document defines a user equipment (UE) for wireless communication, a processor for wireless communication, a first network entity for wireless communication, and methods performed by a UE, processor and first network entity.BACKGROUND

[0002] A wireless communications system may include one or multiple network communication devices, such as base stations, which may support 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 usedherein, 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 B without 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] There is provided an user equipment (UE) for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: transmit, to a first network entity of a wireless communication network, a data flow of a multi-access protocol data unit (MA PDU) session, wherein the data flow comprises one or more datagrams, each datagram comprising: an Internet protocol (IP) data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets.

[0005] There is further provided a processor for wireless communication, comprising: at least one controller coupled with at least one memory and configured to cause the processor to: output a data flow for a MA PDU session, wherein the data flow comprises one or more datagrams, each datagram comprising: an IP data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets.

[0006] There is further provided a first network entity for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the first network entity to: receive, from a UE, a data flow of a MA PDU session, wherein the data flow comprises one or more datagrams, each datagram comprising: an IP data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets; and forward, to a target, the IP data packets of the one or more datagrams.

[0007] There is further provided a method performed by a UE, the method comprising: transmitting, to a first network entity of a wireless communication network, a data flow of a MA PDU session, wherein the data flow comprises one or more datagrams, each datagram comprising: an IP data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets.

[0008] There is further provided a method performed by a processor, comprising: outputting a data flow for a MA PDU session, wherein the data flow comprises one or more datagrams, each datagram comprising: an IP data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets.

[0009] There is further provided a method performed by a first network entity, comprising: receiving, from a UE, a data flow of a MA PDU session, wherein the data flow comprises one or more datagrams, each datagram comprising: an IP data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets; and forwarding, to a target, the IP data packets of the one or more datagrams.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 2A illustrates an example of a user plane (UP) protocol stack when multipath quick user datagram protocol internet connection (MPQUIC) functionality is applied in accordance with aspects of the present disclosure.

[0012] Figure 2B illustrates a further example of an UP protocol stack when MPQUIC functionality is applied in accordance with aspects of the present disclosure.

[0013] Figure 3 illustrates an example of a user datagram protocol (UDP) datagram containing one QUIC packet with STREAM frame in accordance with aspects of the present disclosure.

[0014] Figure 4 illustrates an example of a QUIC packet with STREAM frame including a hypertext transfer protocol (HTTP) data frame in accordance with aspects of the present disclosure.

[0015] Figure 5 illustrates an example of an UDP datagram containing one QUIC packet with a datagram frame.

[0016] Figure 6 illustrates an example of a context ID determining a semantic of a transmitted UDP in accordance with aspects of the present disclosure.

[0017] Figure 7 illustrates an example of a new semantic of IP packets proxying HTTP datagrams in accordance with aspects of the present disclosure.

[0018] Figure 8 illustrates an example of a new semantic of IP packets encapsulating protocol packets in accordance with aspects of the present disclosure.

[0019] Figure 9 illustrates an example of MA PDU session establishment in accordance with aspects of the present disclosure.

[0020] Figure 10A illustrates an example of a use case of load balancing multiple accesses in accordance with aspects of the present disclosure.

[0021] Figure 10B illustrates an example of a connect method in accordance with aspects of the present disclosure.

[0022] Figure 11 A illustrates an example of a further use case of a setup to proxy sequential UDP packets in accordance with aspects of the present disclosure.

[0023] Figure 1 IB illustrates an example of a further connect method in accordance with aspects of the present disclosure.

[0024] Figure 12 illustrates an example of a user equipment (UE) 1200 in accordance with aspects of the present disclosure.

[0025] Figure 13 illustrates an example of a processor 1300 in accordance with aspects of the present disclosure.

[0026] Figure 14 illustrates an example of a network equipment (NE) 1400 in accordance with aspects of the present disclosure.

[0027] Figure 15 illustrates a flowchart of a method 1500 performed by a UE in accordance with aspects of the present disclosure.

[0028] Figure 16 illustrates a flowchart of a method 1600 performed by a processor in accordance with aspects of the present disclosure.

[0029] Figure 17 illustrates a flowchart of a method 1700 performed by a NE in accordance with aspects of the present disclosure.DETAILED DESCRIPTION

[0030] One or more nodes, such as a user equipment (UE), a base station, and / or a network entity of a core network may support multipath quick user datagram protocol internet connection (MPQUIC) functionality. MPQUIC may enable steering, switching and splitting of user datagram protocol (UDP) traffic, for example, between the UE and the network entity of the core network (e.g., a user plane function (UPF)). The one or more nodes may support steering, switching and splitting of UDP traffic according to access traffic steering switching and splitting (ATSSS). In some cases, the one or more nodes may enable the MPQUIC functionality for proxying (e.g., processing, monitoring, ordering, routing, forwarding) IP packets in HTTP datagrams, specifically in HTTP / 3 datagrams. One or more IP packet tunnels (e.g., channels) may be established using MPQUIC functionality, and can have utility with, for instance, the establishment of a virtual private network (VPN).

[0031] A set of IP data packets may be associated with a sequence. The sequence may correspond to an order of the set of IP data packets and may be used for reordering of the IP data packets, among other examples. In some cases, the set of IP data packets may be proxied in HTTP datagrams (e.g., in HTTP / 3). In these cases, the set of IP data packets may be part of a data flow of a multiaccess protocol data unit (MA PDU) session, encapsulated within HTTP datagrams over MPQUIC. In some cases, sequence information associated with the set of IP data packets may be lost. The ability to reorder the IP data packets according to the sequence becomes important where the network entity is functioning (e.g., operating) as an IP proxy. Some example use cases include remote access VPN, site-to-site VPN, secure point-to-point communications, or for general purpose packet tunnelling.

[0032] The disclosure herein provides an approach for encapsulating IP data packets in a datagram when the IP data packets (e.g., or their contents) are intended to be in a sequence (e.g., an order). More specifically, the disclosure herein provides for including a sequence number with each IP data packet prior to proxying the IP data packets in datagrams (e.g., a sequence number is provided with the IP data packet in a given datagram). If the datagrams encapsulate IP data packets which themselves further encapsulate data packets of a sequence having protocol other than IP, the IP data packets may themselves further encapsulate the sequence number.

[0033] A first network entity receiving the datagrams and acting (e.g., functioning) as an IP proxy may be able to reorder the IP data packets using the sequence number, or forward the data packets encapsulated within the IP data packets along with their associated sequence number for reordering by a target entity (e.g., a UE, a base station, and / or other network entities). Furthermore, the first network entity receiving the datagrams may be able to detect and eliminate (e.g., discard) duplicate IP data packets based on the sequence number. In addition, in cases where load balancing is being applied for an MA PDU session (e.g., according to ATSSS and N4 rules), the first network entity receiving the datagrams may be able to determine whether a UE has applied the load balancing correctly, by evaluating between the IP data packets received via the various accesses of the MA PDU session and expected IP data packets based on the N4 rules available to the first network entity and the sequence number.

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

[0035] 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 (LIE- 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.

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

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

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

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

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

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

[0042] 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 application server. In some implementations, one or more UEs 104 may communicate with the application server. 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 application server 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).

[0043] In the wireless communications system 100, the NEs 102 and the UEs 104 may use resources of the wireless communications system 100 (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communications). In some implementations, the NEs 102 and the UEs 104 may support different resource structures. For example, the NEs 102 and the UEs 104 may support different frame structures. In some implementations, such as in 4G, the NEs 102 and the UEs 104 may support a single frame structure. In some other implementations, such as in 5 G 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.

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

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

[0046] 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 may include a number (e.g., quantity) of symbols (e.g., OFDM symbols). In some implementations, the number (e.g., quantity) of slots for a subframe may depend on a numerology. For a normal cyclic prefix, a slot may include 14 symbols. For an extended cyclic prefix (e.g., applicable for 60 kHz subcarrier spacing), a slot may include 12 symbols. The relationship between the number of symbols per slot, the number of slots per subframe, and the number of slots per frame for a normal cyclic prefix and an extended cyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g., / r=0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

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

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

[0049] MPQUIC functionality is a type of higher layer steering functionality that can be used to enable steering, switching, and splitting of UDP traffic between an UE and an UPF in the Access Traffic Steering, Switching, Splitting (ATSSS) feature of 3GPP (see the 3GPP Specification TS 23.501 titled, “System architecture for the 5G System (5GS); Stage 2”). Release 18 of ATSSS describes MPQUIC functionality proxying the UDP packets in the HTTP datagrams as described in the IETF Standard RFC 9298 titled, “Proxying UDP in HTTP This is described as being achieved by introducing transport modes referred to as ‘Datagram mode 1 ’ and ‘Datagram mode 2’. Release 19 of ATSSS in the 3GPP Specification TR 23.700-54 titled, "Study on Multi-Access (DualSteer and ATSSS_Ph4)", further describes how to implement an IP packet tunnel over QUIC, such as for a Virtual Private Network (VPN), by using MPQUIC steering functionality proxying the IP packets in the HTTP datagrams as described in the IETF Standard RFC 9484 and titled, “Proxying IP in HTTP ” . For the latter, within the HTTP Datagram payload of the HTTP Datagram,the parameter context ID is used to determine the semantic of the payload of the HTTP Datagram payload.

[0050] However, the design of the sequences of the IP packets for different use cases remains to be explored. Examples of such use cases include remote access VPN, site-to-site VPN, secure point-to-point communication, or general-purpose packet tunneling.

[0051] The 3GPP Specification TS 23.501 has defined a steering functionality as multipath QUIC (MPQUIC) as defined in the IETF Draft titled “Multipath extension for QUIC”. This includes the following transport modes for MA PDU sessions: stream mode; datagram mode 1 ; and datagram mode 2. The MA PDU sessions include simultaneous communication over multiple paths such as 3GPP access or non-3GPP access. In Figure 5.32.6.2.2-1 of the 3GPP Specification TS 23.501 the protocol stack of the user plane is defined for when the MPQUIC functionality is applied for the connect protocol ‘connect- UDP’. In Figure 6.2.4.2-4 of the 3GPP Report TR 23.700-54 titled, “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on Multi-Access (DualSteer and ATSSS Ph4) ”, the protocol stack of the user plane is proposed for when the MPQUIC functionality is applied for the connect protocol ‘connect- IP’. The protocol stacks are shown respectively in Figures 2A-2B as background useful for understanding aspects of the disclosure herein.

[0052] Figure 2A illustrates an example 200 of an UP protocol stack when MPQUIC functionality is applied for the connect protocol ‘connect-UDP’.

[0053] The example 200 shows an UP protocol stack across a UE 210, a 5G-AN 220, a UPF 230, a UPF as PDU session anchor 240 and a remote host 250. The example shows the N3 interface between the 5G-AN 220 and UPF 230, the N9 interface between the UPF 230 and UPF as PDU session anchor 240, and the N6 interface between the UPF as PDU session anchor 240 and the remote host 250.

[0054] The UE 210 has a protocol stack comprising PDU 211, HTTP / 3 (connect-UDP) 212, MPQUIC (including TLS) 213, UDP 214, IP 215, 5G-AN protocol layers 216. The 5G-AN protocol layers 216 may be for 3GPP access and non-3GPP access.

[0055] The 5G-AN 220 has a protocol stack comprising 5G-AN protocol layers 221 (again which may be for 3GPP access and non-3GPP access), relay 222, GTP-U 223, UDP / IP 224, L2 225 and LI 226.

[0056] The UPF 230 has a protocol stack comprising relay 232, GTP-U 233a and 233b, UDP / IP 234a and 234b, L2 235a and 235b, and LI 236a and 236b.

[0057] The UPF as PDU session anchor 240 has a protocol stack comprising HTTP / 3 (connect-udp) 241, MPQUIC (including TLS) 242, UDP 243, IP 244, GTP-U 245, UDP / IP 246, L2 247, LI 248 and N6 protocol layers 249.

[0058] The remote host 250 has a protocol stack comprising PDU 251, N6 protocol layers 252.

[0059] As shown, the UE 210 and remote host 250 may communicate with each other using the PDU protocol 211, 251. The UE 210 and the UPF as PDU session anchor 240 may communicate with each other using the HTTP / 3 protocol 212, 241 or using MPQUIC (including TLS) 213, 242, or using UDP 214, 243, or using IP 215, 244. The UE 210 and the 5G-AN 220 may communicate with each other using 5G-AN protocol layers 216, 221.

[0060] The 5G-AN 220 and UPF 230 may communicate with each other using GTP-U 223, 233a, or using UDP / IP 224, 234a, or using L2225, 235a, or using LI 226, 236a.

[0061] The UPF 230 and the UPF as PDU session anchor 240 may communicate with each other using GTP-U 233b, 245, or using UDP / IP 234b, 246, or using L2 235b, 247, or using LI 236b, 248.

[0062] The UPF as PDU session anchor 240 and the remote host 250 may communicate with each other over N6 protocol layers 249, 252.

[0063] As Figure 2 A shows, the MPQUIC layer 213, 242 is only for the transport layer between the UE 210 and the UPF 240 within the 3 GPP network.

[0064] Figure 2B illustrates an example 200’ of an UP protocol stack when MPQUIC functionality is applied for the connect protocol ‘connect-IP’.

[0065] The example 200’ shows a UP protocol stack across a UE 210’, a 5G-AN 220’, a UPF 230’, a UPF as PDU session anchor 240’ and a remote host 250’. The example shows the N3 interface between the 5G-AN 220’ and UPF 230’, the N9 interface between the UPF 230’ and UPF as PDU session anchor 240’, and the N6 interface between the UPF as PDU session anchor 240’ and the remote host 250’.

[0066] The UE 210’ has a protocol stack comprising PDU 211’, HTTP / 3 (connect-IP) 212’, MPQUIC (including TLS) 213’, UDP 214a’, IP 215a’, 5G-AN protocol layers 216’. The 5G-AN protocol layers 216’ may be for 3GPP access and non-3GPP access.

[0067] The 5G-AN 220’ has a protocol stack comprising 5G-AN protocol layers 221 ’ (again which may be for 3GPP access and non-3GPP access), relay 222’, GTP-U 223’, UDP / IP 224’, L2225’ and LI 226’.

[0068] The UPF 230’ has a protocol stack comprising relay 232’, GTP-U 233a’ and 233b’, UDP / IP 234a’ and 234b’, L2235a’ and 235b’, and LI 236a’ and 236b’.

[0069] The UPF as PDU session anchor 240’ has a protocol stack comprising HTTP / 3 (connect-ip) 241’, MPQUIC (including TLS) 242’, UDP 243’, IP 244a’, GTP-U 245’, UDP / IP 246’, L2247’, LI 248’ and N6 protocol layers 249’.

[0070] The remote host 250’ has a protocol stack comprising PDU 251’, N6 protocol layers 252’.

[0071] In contrast to Figure 2A, the UE 210’ has in the protocol stack UDP 214b’ and IP 215b’. Furthermore, the UPF as PDU session anchor 240’ has in the protocol stack IP 244b’. In addition, the remote host 250’ has in the protocol stack UDP 253’ and IP 254’.

[0072] As shown, the UE 210’ and remote host 250’ may communicate with each other using the PDU protocol 211’, 251’ or using the UDP protocol 214b’, 253’. The UE 210’ and the UPF as PDU session anchor 240’ may communicate with each other using the HTTP / 3 protocol 212’, 241’ or using MPQUIC (including TLS) 213’, 242’, or using UDP 214a’, 243’, or using IP 215a’, 244a’, or using IP 215b’, 244b’. The UE 210’ and the 5G- AN 220’ may communicate with each other using 5G-AN protocol layers 216’, 221’.

[0073] The 5G-AN 220’ and UPF 230’ may communicate with each other using GTP- U 223’, 233a’, or using UDP / IP 224’, 234a’, or using L2225’, 235a’, or using LI 226’, 236a’.

[0074] The UPF 230’ and the UPF as PDU session anchor 240’ may communicate with each other using GTP-U 233b’, 245’, or using UDP / IP 234b’, 246’, or using L2 235b’, 247’, or using LI 236b’, 248’.

[0075] The UPF as PDU session anchor 240’ and the remote host 250’ may communicate with each other over N6 protocol layers 249’, 252’ or using IP 244b’, 254’.

[0076] As Figure 2B shows, the MPQUIC layer 213’, 242’ is only for the transport layer between the UE 210’ and the UPF 240’ within the 3GPP network.

[0077] QUIC as defined in the IETF Standard RFC 9000 titled, “QUIC: A UDP-Based Multiplexed and Secure Transport” , is a UDP-based multiplexed and secure transport protocol. Peers communicate in QUIC by exchanging QUIC packets, which usually contain frames with control information or data. QUIC packets are carried in UDP datagrams to better facilitate deployment in existing systems and networks. One or more QUIC packets can be encapsulated in a single UDP datagram. Figure 3 illustrates an example of an UDP datagram containing one QUIC packet with STREAM frame in accordance with aspects of the present disclosure.

[0078] The example shows an IP packet 300 comprising an IP header 302 and a payload 304. The payload 304 encapsulates a UDP packet 310 comprising a UDP header 312 and a UDP payload 314. The UDP pay load 314 encapsulates a QUIC packet 320 comprising a QUIC packet header 322 and a QUIC packet payload 324. The QUICK packet payload 324 may be referred to as a frame. The QUIC packet payload 324 includes a Frame Type 324a, a Stream ID 324b, an Offset 324c if OFF=1, a Length 324d if LEN=1, and a stream data 324e.

[0079] The stream mode defined in the 3GPP Specification TS 23.501, uses the STREAM frame 324 as shown in Figure 3 is to carry stream data 324e with the type field 324a as ObOOOOIXXX (0x08 thru OxOF). The three least significant bits determine the fields that are in the frame 324.

[0080] An OFF bit (0x04) is to indicate that there is an Offset field 324c present. Value "1" indicates that there is an offset field 324c while value "0" indicates the stream data 324e starts at offset 0.

[0081] A LEN bit (0x02) is to indicate that there is a length field 324d present. Value "1" indicates that there is a length field 324d while value "0" indicates that stream data field 324e extends to the end of the QUIC packet 324.

[0082] A FIN bit (0x01) is to indicate the end of stream. Value " 1 " indicates that the frame 324 marks the end of the stream, otherwise it is set to value "0".

[0083] The IETF Standard RFC 9114 titled, “HTTP / 3 ” defines the mapping of HTTP semantics over QUIC, where the HTTP data frame are transported over QUIC as the part of stream data. Figure 4 illustrates such an example of a QUIC packet with a STREAM frame including an HTTP data frame in accordance with aspects of the present disclosure.

[0084] The example shows an IP packet 400 comprising an IP header 402 and a payload 404. The payload 404 encapsulates a UDP packet 410 comprising a UDP header 412 and a UDP payload 414. The UDP payload 414 encapsulates a QUIC packet 420 comprising a QUIC packet header 422 and a QUIC packet payload 424. The QUIC packet payload 424 encapsulates a Frame Type 424a, a Stream ID 424b, an Offset 424c if OFF=1, a field 424d with Type=0x00 and Stream data 424e. The stream data 424e may be referred to as a data frame. The stream data 424e includes a length 424el and data 424e2.

[0085] In Figure 4, since the data frame 424e includes length 424el for the data 424e2, then there is no need to have length field 324d as per Figure 3, thus, the field 424d (i.e., the LEN bit (0x02)) is set to value "0".

[0086] In addition to the reliable STREAM frame, the IETF Standard RFC 9221 titled, “An Unreliable Datagram Extension to QUIC”, defines a DATAGRAM frame extension for the QUIC protocol to define unreliable frames for transmission. This tends to be due to the reasoning that some applications / services require fast transmission of data. Figure 5 illustrates an example of an UDP datagram containing one QUIC packet with a DATAGRAM frame.

[0087] The example shows an IP packet 500 comprising an IP header 502 and a payload 504. The payload 504 encapsulates a UDP packet 510 comprising a UDP header 512 and a UDP payload 514. The UDP pay load 514 encapsulates a QUIC packet 520 comprising a QUIC packet header 522 and a QUIC packet payload 524. The QUIC packet payload 524 may be referred to as a frame. The QUIC packet payload 524 includes a frame type 524a, a length 524b if UEN = 1 and a datagram data 524c.

[0088] The DATAGRAM frame 524 as shown in Figure 5 is to carry datagram data 524c with the type field 524a as ObOOl 1000X (0x30 or 0x31). The least significant bit determines the field that is in the frame. The EEN bit (0x01) is to indicate that there is a length field 524b present. A value of " 1 " indicates that there is a length field 524b while value "0" indicates that datagram data field 524c extends to the end of the QUIC packet 520.

[0089] The IETF Standard RFC 9297, titled “HTTP Datagrams and the Capsule Protocol” defines the unreliable transmission of HTTP datagrams in HTTP / 3. The IETF Standard RFC 9298 defines how to proxy UDP in HTTP datagrams for the purpose of HTTP client tunnels for UDP communication through an HTTP server acting as a UDP proxy. The IETF Standard RFC 9298 defines an identifier, context ID, whose value determines the semantic of how the UDP is proxying in the HTTP datagram. A context ID with a value "0" is defined in the IETF Standard RFC 9298 as being associated with one UDP proxying in the HTTP datagram. This semantic is defined as ‘datagram mode 2’ according to the 3GPP Specification TS 24.913 titled, “5G System; Access Traffic Steering, Switching and Splitting (ATSSS); Stage 3”. Furthermore, the 3GPP Specification TS 24.913 also defines a ‘datagram mode 1 ’ where a new semantic of the pay load contains a sequence number in addition to one UDP packet. The value for the context ID is other than zero for datagram mode 1. Figure 6 illustrates such an example of a context ID determining a semantic of a transmitted UDP in accordance with aspects of the present disclosure.

[0090] The example shows an IP packet 600 comprising an IP header 602 and a payload 604. The payload 604 encapsulates a UDP packet 610. The UDP packet 610 comprises a UDP header 612 and a UDP payload 614. The UDP payload 614 encapsulates a QUIC packet 620. The QUIC packet 620 comprises a QUIC packet header 622 and aQUIC packet payload 624. The QUIC packet payload 624 may also be referred to as a frame. The QUIC packet payload 624 contains a frame type field 624a, a length field 624b (if LEN=1) and a datagram data 624c. The datagram data 624c is an HTTP datagram (i.e., in HTTP / 3). The HTTP datagram 624c includes a quarter stream ID 624c 1 and an HTTP datagram payload 624c2. The HTTP datagram payload 624c2 includes a context ID 630. The HTTP datagram payload 624c2 may include a UDP packet 650 or a sequence number 641 with an associated UDP packet 642.

[0091] Figure 6 shows that due to the value of the context ID 630, the HTTP datagram payload 624c2 contains either one UDP packet 650 or a sequence number 641 and one UDP packet 642. The sequence number 641 is used to determine the order of transmitted UDP packets encapsulated within the HTTP datagram in HTTP / 3.

[0092] The proxying of IP packets in HTTP datagrams will now be introduced. TheIETF Standard RFC 9484 titled, “Proxying IP in HTTP” defines the proxying of IP packets in HTTP datagrams for tunnelling IP through an HTTP server acting as an IP-specific proxy over HTTP. This can be used for use cases, such as remote access VPN, site-to-site VPN, secure point-to-point communication, or general-purpose packet tunnelling. Similar to the IETF Standard RFC 9298, the IETF Standard RFC 9484 uses the context ID 630 to identify the semantic of how the IP is proxying in the HTTP datagram 624c. A context ID 630 with a value of "0" is defined in the IETF Standard RFC 9484 as indicating that an IP packet is proxying in the HTTP datagram 624c.

[0093] If an HTTP server can act as an IP proxy but not as a UDP proxy, it is possible to use the IETF Standard RFC 9484 for the use case of general-purpose packet tunnelling where a UE requests to establish a forwarding tunnel to a target using the UDP protocol with assigned IP protocol number 17 and receives a remote IP address it can use for transmitting UDP packets. In addition to the establishment of a forwarding tunnel for transmission of the UDP packet, a method is required to implement the case when the client request to establish a forwarding tunnel for sequential UDP packets to a target.

[0094] To implement use cases which benefit from sequential IP packets proxying HTTP datagrams (such as establishing a forwarding tunnel for the sequential UDP packets to a target), a new semantic for IP packets proxying the HTTP datagram, other than the oneidentified by context ID set to value "0" and as described in clause 5 of IETF Standard RFC 9484, is required. According to the present disclosure, it is proposed that IP packets proxying the HTTP datagram are augmented by adding a sequence number which may be 32-bit integer and defines the transmission order for the HTTP datagram payload. The sequence number may be set to zero in the first sequence of the HTTP datagram payload. Then, if the following new HTTP datagram payload does not duplicate the previous one, the new sequence number may be modulo (2A32) of the previous sequence number incremented by 1 for the following new HTTP datagram payload.

[0095] According to the present disclosure, applying the new sequence number according to modulo (2A32) of the previous sequence number incremented by 1, tends to reset the sequence number to value "0" after it reaches its maximum value of 2A32-1.

[0096] Figure 7 illustrates an example of a new semantic of IP packets proxying HTTP datagrams in accordance with aspects of the present disclosure.

[0097] The example shows an IP packet 700 comprising an IP header 702 and a payload 704. The payload 704 encapsulates a UDP packet 710. The UDP packet 710 comprises a UDP header 712 and a UDP payload 714. The UDP payload 714 encapsulates a QUIC packet 720. The QUICK packet 720 comprises a QUIC packet header 722 and a QUIC packet payload 724. The QUIC packet payload 724 may be referred to as a frame. The QUIC packet pay load 724 includes a frame type 724a, a length 724b (if EEN=1) and a datagram data 724c. The datagram data 724c is an HTTP datagram (i.e., in HTTP / 3). The HTTP datagram 724c includes a quarter stream ID 724cl and an HTTP datagram payload 724c2. The HTTP datagram payload 724c2 includes a context ID 730. The HTTP datagram payload 724c2 shown in Figure 7 can contain either one IP packet 750 with context ID 730 set to value "0" as described in the IETF Standard RFC 9484 or the new semantic with sequence number 741 followed by one IP packet 742 with a non-zero value for the context ID 730. For completeness, the IETF Standard RFC 9484, herein incorporated by reference, describes additional rules when choosing a non-zero value for context ID 730.

[0098] In another example, an IP packet may encapsulate another protocol packet which itself is intended to be sequential with other protocol packets. This may happen if, for example, a UE requests the UPF acting as IP proxy to establish an IP flow forwarding toa target, such as for forwarding to an application server protocol packets such as UDP. The UPF (the IP proxy) may remove the sequence number priori to passing the protocol packets towards the target. The new IP packets proxying the HTTP datagram may encapsulate the sequence number which may be a 32-bit integer and further encapsulate the protocol packets to define the transmission order for the HTTP datagram payload. The transmission order may comprise the sequence number being set to zero in the first instance of the HTTP datagram payload of a sequence; and if the following new HTTP datagram payload does not duplicate the previous one, the new sequence number is modulo (2A32) of the previous sequence number incremented by 1 for the following new HTTP datagram payload.

[0099] Again, the setting of the new sequence number in this manner tends to reset the sequence number to value "0" after it reaches its maximum value of 2A32-1. Figure 8 illustrates an example of such a new semantic of IP packets encapsulating protocol packets in accordance with aspects of the present disclosure.

[0100] The example shows an IP packet 800 comprising an IP header 802 and a payload 804. The payload 804 encapsulates a UDP packet 810. The UDP packet 810 comprises a UDP header 812 and a UDP payload 814. The UDP pay load 814 encapsulates a QUIC packet 820. The QUIC packet 820 comprises a QUIC packet header 822 and a QUIC packet payload 824. The QUIC packet payload 824 may be referred to as a frame. The QUIC packet pay load 824 includes a frame type 824a, a length 824b (if LEN=1) and a datagram data 824c. The datagram data 824c is an HTTP datagram (i.e., in HTTP / 3). The HTTP datagram 824c includes a quarter stream ID 824cl and an HTTP datagram payload 824c2. The HTTP datagram payload 824c2 includes a context ID 830. The HTTP datagram payload 824c2 further includes an IP packet 840. The IP packet 840 encapsulates the sequence number 841 and a protocol packet 842 for a protocol other than IP. The IP packet 840 further includes an IP header 843. The HTTP datagram payload 824c2 shown in Figure 8 has a non-zero value for the context ID 830 which may be determined as described in the IETF Standard RFC 9484.

[0101] Figure 9 illustrates an example 900 of MA PDU session establishment in accordance with aspects of the present disclosure. More specifically, Figure 9 shows UE- requested PDU session establishment, with the assumption that the UE is already registeredto the network. This is a simplified version of the procedure in clause 4.22.2 of the 3 GPP Specification TS 23.502 titled, “Procedures for the 5G System (5GS); Stage 2

[0102] The example 900 shows a UE 920, an AMF 930, a SMF 940, a PCF 950 and a UPF 960. The various message flows 901-911 will now be described.

[0103] In a first step 901, the UE 920 initiates the UE-requested PDU session establishment procedure by including several information elements within a NAS message for the PDU session establishment procedure. More specifically, a PDU session establishment request is transmitted by the UE 920 to the AMF 930.

[0104] In a further step 902, upon determining the SMF 940, the AMF 930 constructs a Nsmf PDUSession CreateSMContext request with information elements to create an SM context. The AMF 930 transmits the request to the SMF 940.

[0105] In a further step 903, upon creating the SM context, the SMF 940 informs theAMF 930 by transmitting a Nsmf_PDUSession_CreateSMContext response to the AMF 930 to provide the SM context ID.

[0106] In a further step 904, the SMF 940 requests to the PCF 950 to establish an SM Policy Association by transmitting the information about the PDU session via a Npcf_SMPolicyControl_Create message.

[0107] In a further step 905, the PCF 950 provides the SMF policy information as PCC rules via an Npcf SMPolicyControl Create response. This response is provided to the SMF 940. The PCC rules include MPQUIC steering functionality, transport mode, and connect- ip protocol and possibly the "ipproto" and "target" parameters associated with connect-ip, (see the 3GPP Specification TR 23.700-54).

[0108] In a further step 906, from the received PCC rules, the SMF 940 derives (a)ATSSS rules, which will be sent to the UE 920 for controlling the traffic steering, switching and splitting in the uplink direction and (b) N4 rules, which will be sent to UPF 960 for controlling the traffic steering, switching and splitting in the downlink direction.

[0109] In a further step 907, the SMF 940 initiates the N4 Session establishment procedure with the UPF 960 by sending N4 rules derived by the SMF 940 for the MA PDUsession to instruct the UPF 960 to activate the MPQUIC functionality for this MA PDU Session. More specifically the SMF 940 transmits to the UPF 960 a N4_Session_establishment request message.

[0110] In further step 908, the UPF 960 allocates the UE 920 "MPQUIC link-specific multipath" addresses / prefixes and sends the "MPQUIC link-specific multipath" addresses / prefixes and MPQUIC proxy information to the SMF 940 in a N4_Session_establishment response message.

[0111] In further step 909, the SMF 940 includes an "MA PDU session Accepted" indication in an Namf_Communication_NlN2MessageTransfer message to the AMF 930 and indicates to the AMF 930 that the N2 SM Information included in this message should be sent to the UE 920. The AMF 930 marks this PDU session as an MA PDU session based on the received "MA PDU session Accepted" indication.

[0112] In a further step 910, the UE 920 receives a PDU session establishment accept message from the AMF 930, which indicates to the UE 920 that the requested MA PDU session was successfully established. This message includes the ATSSS rules for the MA PDU session, which were derived by the SMF 940 and the "MPQUIC link-specific multipath" addresses / prefixes of the UE 920 and the MPQUIC proxy information.

[0113] In a further step 911, the uplink and downlink data are established for the MA PDU session. The UE 920 follows the ATSSS rules to establish the UDP flow. According to the ATSSS rules, the UE 920 is to use the MPQUIC steering functionality with connect- ip protocol which may mean the UPF 960 can act as IP proxy for the service.

[0114] In one example use case the ATSSS rules may contain load balancing rules where the UDP flow is to be divided over the multiple accesses to the network. This may be a case when the multiple accesses include a 3 GPP access such as a 5G system and they are associated with two subscriptions / SUPIs for DualSteer (see for example 3GPP Specification TR 23.700-54). Alternatively the multiple accesses may comprise a non- 3GPP and a 3GPP access such as a 5G system.

[0115] Figure 10A illustrates such an example 1000 of a use case of load balancing multiple accesses in accordance with aspects of the present disclosure. The example 1000shows a UE (client) 1010 and a UPF 1020 (IP proxy). The load balancing of the UDP flow is such that 30% of the UDP flow is transmitted via access 1 and 70% via access 2. The UE 1010 may receive "target" and "ipproto" as the ATSSS rules, to provide the target hostname as an application server (application.server.com) and internet protocol for IP as 0.

[0116] In the setup in Figure 10A, the UPF 1020 (IP proxy) assigns the UE 1010 (client) a local IPV6 address, 2001 :db8: 1234: :a, and a remote IPV6 address, 2001:db8:3456::b, for transmitting IPV6 packets. The UPF 1020 uses the hostname and depending on the format, may perform DNS on behalf of the client to allocate the IP address for the host which is the application server. The UPF 1020 (IP Proxy) allocates in addition an outbound socket for the UE (client) 1010 to complete the connection, which is the CONNECT method shown in Figure 10B.

[0117] During the transmission, the UE 1010 uses the new semantic for IP packets proxying the HTTP datagrams as described herein. The sequential numbers allow the UE 1010 to divide the transmission of the IPV6 packets on access 1 and access 2 according to the load balancing rules received in the ATSSS rules. The UPF 1020 (IP proxy) is able to use the sequence numbers for reordering and / or detection of duplication or absence of the IP packets prior to forwarding them to the target. Since the UPF 1020 (IP Proxy) has also received the same load balancing ratio as the UE 1010 received via the ATSSS rules, but via N4 rules, the UPF 1020 can compute whether the UE 1010 has performed the load balancing properly by considering the number of received unrepeated and uncorrelated IP packets via access 1 and access 2 with respect to the sequence number.

[0118] In a further example of a use case, if a UE is to forward the sequential UDP packets, the UE can establish a forwarding tunnel to a target using the UDP protocol with assigned IP protocol number 17 and receives a remote IP address it can use for transmitting UDP packets. The UE can use the new semantic for IP packets proxying the HTTP datagrams as described herein.

[0119] Figure 11A illustrates an example 1100 of such a further use case of a setup to proxy sequential UDP packets in accordance with aspects of the present disclosure. The example 1100 shows a UE (client) 1110 and an UPF (IP Proxy) 1120. The UE 1110 requests to establish a forwarding tunnel to an application server (application.server.com)using the UDP (assigned IP protocol 17) and receives a local IPV6 address, 2001:db8:1234::a, and a remote IPV6 address, 2001:db8:3456::b, for transmitting the packets.

[0120] In the setup in Figure 11 A, a "target" and "ipproto" that the UE 1110 may have received as the ATSSS rules, are used to provide the target hostname and the assigned internet protocol for UDP of 17. The UPF 1120 uses the hostname and depending on the format, may perform DNS on behalf of the UE (client) 1110 to allocate the IP address for the host which is the application server. The UPF (IP Proxy) 1120 allocates in addition an outbound socket for the UE (client) 1110 to complete the connection, which is the CONNECT method shown in Figure 1 IB.

[0121] If the pay load of the datagram has the format of encapsulated UDP over sequential IP packet, then the UPF (IP proxy) 1120 can use the sequence number for reordering and / or detection for duplication or absence of the IP packets.

[0122] If the pay load of the datagram has the format of encapsulated sequential UDP over IP packet, then the UPF 1120 which is the IP proxy may not be able to use the sequence numbers for reordering and / or detection of duplication or absence of the UDP packets prior to forwarding them to the target. The sequence numbers together with the UDP packet may be forwarded to the target. Thus in such a scenario the QUIC steering functionality is not only used between the UE 1110 and the UPF 1120.

[0123] For either of the use cases shown in Figures 10 and 11, at the time of establishment of the MA PDU session, the UPF 1020, 1120 may receive the same PCC rules as N4 rules for this service, as the UE 1010, 1110 receives as ATSSS rules. Thus, for the same service / application the same "target" and "ipproto" are received by the UE 1010, 1110 and the UPF 1020, 1120. Therefore, it may be optional for the UE 1010, 1110 to communicate the "target" and "ipproto" parameters with the UPF 1020, 1120, if there are other factors which can be used to determine the service / application when the UE 1010, 1110 requests to establish a forwarding tunnel.

[0124] The context ID can be determined according to the IETF Standard RFC 9484, however, since the PCC rules determine the semantic of the IP packet proxying the HTTPdatagrams for the service, the context ID can be chosen as any non-zero value. In this case, any value for the context ID may be considered as being implicitly registered, thus any change of context ID during the PDU flow may be ignored and the received IP packets may be treated as being part of the PDU flow for the service / application.

[0125] Figure 12 illustrates an example of a UE 1200 in accordance with aspects of the present disclosure. The UE 1200 may include a processor 1202, a memory 1204, a controller 1206, and a transceiver 1208. The processor 1202, the memory 1204, the controller 1206, or the transceiver 1208, 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.

[0126] The processor 1202, the memory 1204, the controller 1206, or the transceiver 1208, 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.

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

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

[0129] In some implementations, the processor 1202 and the memory 1204 coupled with the processor 1202 may be configured to cause the UE 1200 to perform one or more of the functions described herein (e.g., executing, by the processor 1202, instructions stored in the memory 1204). For example, the processor 1202 may support wireless communication at the UE 1200 in accordance with examples as disclosed herein. The UE 1200 may be configured to support a means for transmitting, to a first network entity of a wireless communication network, a data flow of a multi-access protocol data unit (MA PDU) session, wherein the data flow comprises one or more datagrams, each datagram comprising: an IP data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets.

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

[0131] In some implementations, the UE 1200 may include at least one transceiver 1208. In some other implementations, the UE 1200 may have more than one transceiver 1208. The transceiver 1208 may represent a wireless transceiver. The transceiver 1208 may include one or more receiver chains 1210, one or more transmitter chains 1212, or a combination thereof.

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

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

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

[0135] The processor 1300 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 1300) or other memory (e.g., random access memory (RAM), read-only memory (ROM), dynamicRAM (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).

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

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

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

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

[0140] The one or more ALUs 1306 may be configured to support various operations in accordance with examples as described herein. In some implementations, the one or more ALUs 1306 may reside within or on a processor chipset (e.g., the processor 1300). In some other implementations, the one or more ALUs 1306 may reside external to the processor chipset (e.g., the processor 1300). One or more ALUs 1306 may perform one or more computations such as addition, subtraction, multiplication, and division on data. For example, one or more ALUs 1306 may receive input operands and an operation code, which determines an operation to be executed. One or more ALUs 1306 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 1306 may support logical operations such as AND, OR, exclusive-OR (XOR), not-OR (NOR), and not-AND (NAND), enabling the one or more ALUs 1306 to handle conditional operations, comparisons, and bitwise operations.

[0141] The processor 1300 may support wireless communication in accordance with examples as disclosed herein. The processor 1300 may be configured to support a meansfor transmitting, to a first network entity of a wireless communication network, a data flow of a MA PDU session, wherein the data flow comprises one or more datagrams, each datagram comprising: an IP data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets. The processor 1300 may be configured to or operable to support a means for receiving, from a user equipment (UE), a data flow of a MA PDU session, wherein the data flow comprises one or more datagrams, each datagram comprising: an IP data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets; forwarding, to a target, the IP data packets of the one or more datagrams. More generally, the processor 1300 may be configured to or operable to support a means for outputting and / or inputting a data flow for a MA PDU session, wherein the data flow comprises one or more datagrams, each datagram comprising: an IP data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets.

[0142] Figure 14 illustrates an example of a NE 1400 in accordance with aspects of the present disclosure. The NE 1400 may include a processor 1402, a memory 1404, a controller 1406, and a transceiver 1408. The processor 1402, the memory 1404, the controller 1406, or the transceiver 1408, 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.

[0143] The processor 1402, the memory 1404, the controller 1406, or the transceiver 1408, 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.

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

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

[0146] In some implementations, the processor 1402 and the memory 1404 coupled with the processor 1402 may be configured to cause the NE 1400 to perform one or more of the functions described herein (e.g., executing, by the processor 1402, instructions stored in the memory 1404). For example, the processor 1402 may support wireless communication at the NE 1400 in accordance with examples as disclosed herein. The NE 1400 may be configured to support a means for receiving, from a UE, a data flow of a MA PDU session, wherein the data flow comprises one or more datagrams, each datagram comprising: an IP data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets; and forwarding, to a target, the IP data packets of the one or more datagrams.

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

[0148] In some implementations, the NE 1400 may include at least one transceiver 1408. In some other implementations, the NE 1400 may have more than one transceiver 1408. The transceiver 1408 may represent a wireless transceiver. The transceiver 1408 may include one or more receiver chains 1410, one or more transmitter chains 1412, or a combination thereof.

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

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

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

[0152] At 1502, the method 1500 may include transmitting, to a first network entity of a wireless communication network, a data flow of a multi-access protocol data unit session,wherein the data flow comprises one or more datagrams, each datagram comprising: an Internet protocol data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets. The operations of 1502 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1502 may be performed by a UE as described with reference to Figure 12.

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

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

[0155] At 1602, the method 1600 may include outputting a data flow for a multi-access protocol data unit session, wherein the data flow comprises one or more datagrams, each datagram comprising: an internet protocol data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets. The operations of 1602 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1602 may be performed by a processor as described with reference to Figure 13.

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

[0157] Figure 17 illustrates a flowchart of a method 1700 in accordance with aspects of the present disclosure. The operations of the method 1700 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.

[0158] At 1702, the method 1700 may include receiving, from a user equipment, a data flow of a multi-access protocol data unit session, wherein the data flow comprises one ormore datagrams, each datagram comprising: an Internet protocol data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets. The operations of 1702 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1702 may be performed by a NE as described with reference to Figure 14.

[0159] At 1704, the method 1700 may include forwarding, to a target, the IP data packets of the one or more datagrams. The operations of 1704 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1704 may be performed by a NE as described with reference to Figure 14.

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

[0161] There is provided a UE for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: transmit, to a first network entity of a wireless communication network, a data flow of a MA PDU session, wherein the data flow comprises one or more datagrams, each datagram comprising: an IP data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets.

[0162] Multipath quick user datagram protocol internet connection (MPQUIC) functionality is a type of higher layer steering functionality that enables steering, switching and splitting of UDP traffic between a UE and first network function (i.e., a UPF) in ATSSS. The MPQUIC functionality may be used in proxying UDP packets in HTTP datagrams, for instance. IP packet tunnels may also be implemented using MPQUIC functionality which can have utility with, for instance, the establishment of a virtual private network (VPN).

[0163] There are scenarios where IP data packets proxied in HTTP datagrams (i.e., in HTTP / 3) are part of a sequence. When, for instance, the IP data packets are provided in a data flow of an MA PDU session encapsulated within HTTP datagrams over MPQUIC, the sequence information can be lost. The ability to reorder the IP data packets or their contentsinto the sequence tends to be important where the first network entity is acting as an IP proxy. This includes use cases such as remote access VPN, site-to-site VPN, secure point- to-point communications, or for general purpose packet tunnelling.

[0164] The disclosure herein provides an approach for encapsulating IP data packets in a datagram where the IP data packets or their contents are intended to be in a particular sequence / a sequential order. More specifically, the disclosure herein provides for the inclusion of a sequence number with the IP data packets prior to proxying them in a datagram. If the datagram encapsulates IP data packets which themselves further encapsulate data packets of a sequence having protocol other than IP, the IP data packets may themselves encapsulate the sequence number. Accordingly, it will be understood that the sequence number may indicate a position of the IP data packet, or a data packet encapsulated within the IP data packet, in the sequence. Thus the sequence of data packets may be a sequence of the IP data packets across plural datagrams, or may be a sequence of data packets contained within IP data packets across plural datagrams.

[0165] Accordingly, a first network entity receiving the datagrams and acting as an IP proxy tends to be able to reorder the IP data packets using the sequence number, or, forward the data packets encapsulated within the IP data packets along with their associated sequence number for reordering by a target entity. Furthermore, the first network entity receiving the datagrams tends to be able to detect and eliminate duplicate IP data packets based on the additional information provided by the sequence number. In addition, in scenarios where load balancing is being applied for the MA PDU session (for instance through ATSSS and N4 rules), the first network entity receiving the datagrams also tends to be able to determine whether the UE has applied the load balancing correctly, by evaluating the IP data packets received via the various accesses of the MA PDU session against what is expected based on the N4 rules available to the first network entity and the sequence number.

[0166] The IP data packet may further encapsulate the sequence number and another data packet, the another data packet being a data packet for a protocol other than IP.

[0167] The disclosure herein tends to enable data packets having a specific sequence and having protocol other than IP to be encapsulated within IP data packets and proxied indatagrams over an MA PDU session. The sequence information is maintained by encapsulating the data packet with the associated sequence number within the IP data packet.

[0168] The IP data packet and sequence number of the datagram may be further encapsulated within a quick user datagram protocol internet connection (QUIC) packet. The QUIC packet may be encapsulated within a UDP packet. The UDP packet may be encapsulated within a second IP packet.

[0169] The first and second IP packets may be associated with different IP protocols. The IP protocols may be selected from the list consisting of IPv4 and IPv6, for instance.

[0170] The datagram may be a HTTP datagram.

[0171] The HTTP datagram may be an HTTP3 datagram, for instance.

[0172] The sequence number may comprise an integer value. The at least one processor may be configured to cause the UE to: apply an increment between the integer values of datagrams of the one or more datagrams comprising IP data packets that are associated with being sequentially adjacent each other in the sequence.

[0173] The integer value may be a 32bit integer value. The increment may be one. Thus a first datagram may correspond to the first IP data packet in the sequence and be set an integer value of zero. A subsequent datagram corresponding to an IP data packet next in the sequence may be set an integer value of the modulo of the previous sequence number incremented by one.

[0174] Each datagram of the one or more datagrams may comprise an identifier for indicating a semantic of the datagram, wherein the processor is configured to set the identifier to a non-zero value for datagrams including the sequence number.

[0175] The semantic may be related to the proxying in the datagram, for instance the UDP proxying in an HTTP datagram. The identifier may be zero in scenarios where one IP data packet is proxying in the HTTP datagram. The identifier may be non-zero where the datagram comprises a sequence number in addition to an IP data packet thus indicating that the IP data packet is part of a sequence.

[0176] According to the Internet Engineering Task Force (IETF) Standard RFC 9484, titled “Proxying IP in HTTP”, for registering the context ID for the same flow, the context ID which is chosen by the client (e.g., a UE) may be even-numbered while the context ID which is chosen by the first network entity (i.e., the proxy / UPF) may be odd-numbered. Once the registration of the context ID is completed, the client (the UE) and the first network entity (the proxy / UPF) can use any of the even-numbered and odd-numbered values for this flow. However, the IETF Standard RFC 9484 allows for datagrams that are received with any value for context ID other than the registered value to be buffered in case that value becomes registered as a new context ID for the same service data flow (SDF). The registration procedure for a context ID is now, however, defined in RFC 9484.

[0177] In 3 GPP, the transport mode of a UDP flow may be based on policy and charging control (PCC) rules that have been converted to ATSSS rules (transmitted to the UE) and N4 rules (transmitted to the UPF). Since the UDP flow may be initiated by the UE, the UE may ultimately choose any non-zero value for the context ID for the transport mode where IP packets have an associated sequence. That value may thus be implicitly registered for the context ID. Expressed differently, the transport mode is, prior to the UDP flow, known and any non-zero value may have been registered. Thus, the RFC requirement for even-numbered or odd-numbered values for the context ID tends not have to have to be followed. Furthermore, if an HTTP datagram within the same UDP flow (i.e., of the same service data flow, SDF), happens to have any other value for the context ID than the one which was initially implicitly registered, as described above with respect to the RFC Standard 9484, the recipient tends not to drop the datagram but instead can handle and process it.

[0178] The processor may be configured to cause the UE to: receive, from a second network entity, one or more ATSSS rules for transmitting the data flow of the MA PDU session; and transmit the data flow of the MA PDU session in accordance with the one or more ATSSS rules.

[0179] The second network entity may be a session management function (SMF). The SMF may receive one or more policy and charging control (PCC) rules from a policycontrol function (PCF) and then convert the one or more PCC rules to the one or more ATSSS rules.

[0180] For completeness, similarly, the SMF may convert the PCC rules to N4 rules for the first network entity (i.e., the UPF). The SMF may transmit the N4 rules to the first network entity. Whilst the UE may initiate the sending of IP packets to the first network entity for an MA PDU session, the N4 rules tend to enable the first network entity to transmit a data flow to the UE as well. In addition, the N4 rules tend to allow the first network entity to predict MPQUIC steering function, transport mode (i.e., sequential IP packets as the payload of an HTTP datagram for an application or service in an SDP). Given that the first network entity may receive N4 rules and the UE receives ATSSS rules, the context ID may be less important in these examples.

[0181] The one or more ATSSS rules may comprise at least one of: rules for load balancing the data flow of the MA PDU session over a plurality of accesses to the wireless communication network; a target information of a target for the data flow; and an IP information of an IP for forwarding the data flow to the target.

[0182] The plurality of accesses may comprise 3 GPP accesses associated with different subscriptions. The plurality of accesses may comprise a combination of non-3GPP accesses and 3 GPP accesses.

[0183] The processor may be further configured to cause the UE to: transmit, to the first network entity, a request to establish a forwarding tunnel to the target associated with the target information using an IP associated with the IP information.

[0184] The target information may comprise an address or URL. The target may be a server. The IP information may be an IP protocol such as IPv4 or IPv6, for instance.

[0185] The first network entity may be a UPF.

[0186] The first network entity may be an IP proxy.

[0187] There is further provided a processor for wireless communication, comprising: at least one controller coupled with at least one memory and configured to cause the processor to: output a data flow for a MA PDU session, wherein the data flow comprisesone or more datagrams, each datagram comprising: an IP data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets.

[0188] The IP data packet may further encapsulate the sequence number and another data packet, the another data packet being a data packet for a protocol other than IP.

[0189] The IP data packet and sequence number of the datagram may be further encapsulated within a QUIC packet. The QUIC packet may be encapsulated within a UDP packet. The UDP packet may be encapsulated within a second IP packet.

[0190] The datagram may be a hyper-text transfer protocol ‘HTTP’ datagram.

[0191] The sequence number may comprise an integer value. The at least one controller may be configured to cause the processor to: apply an increment between the integer values of datagrams of the one or more datagrams comprising IP data packets that are associated with being sequentially adjacent each other in the sequence.

[0192] The integer value may be a 32bit integer value. The increment may be one. Thus a first datagram may correspond to the first IP data packet in the sequence and be set an integer value of zero. A subsequent datagram corresponding to an IP data packet next in the sequence may be set an integer value of the modulo of the previous sequence number incremented by 1.

[0193] Each datagram of the one or more datagrams may comprise an identifier for indicating a semantic of the datagram. The at least one controller may be configured to cause the processor to output the identifier as a non-zero value for datagrams comprising the sequence number.

[0194] The semantic may be related to the proxying in the datagram, for instance the UDP proxying in an HTTP datagram. The identifier may be zero in scenarios where one IP packet is proxying in the HTTP datagram. The identifier may be non-zero where the datagram comprises a sequence number in addition to an IP data packet thus indicating that the IP data packet is part of a sequence.

[0195] The at least one controller may be configured to cause the processor to: input one or more ATSSS rules for the data flow of the MA PDU session; and output the data flow of the MA PDU session in accordance with the one or more ATSSS rules.

[0196] The one or more ATSSS rules may comprise at least one of: rules for load balancing the data flow of the MA PDU session over a plurality of accesses to the wireless communication network; a target information of a target for the data flow; and an IP information of an IP for forwarding the data flow to the target.

[0197] The at least one controller may be further configured to cause the processor to: output a request to establish a forwarding tunnel to the target associated with the target information using an IP associated with the IP information.

[0198] There is further provided a first network entity for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the first network entity to: receive, from a UE, a data flow of a MA PDU session, wherein the data flow comprises one or more datagrams, each datagram comprising: an IP data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets; forward, to a target, the IP data packets of the one or more datagrams.

[0199] The at least one processor may be configured to cause the first network entity to forward the IP data packets by causing the first network entity to: reorder into the sequence, based on the sequence number, the IP data packets of the one or more datagrams; and forward, to the target, the sequence of IP data packets.

[0200] The at least one processor may be configured to cause the first network entity to: detect and eliminate, based on the sequence number, IP data packets of the one or more datagrams that are duplicates of each other.

[0201] The IP data packet may further encapsulate the sequence number and another data packet, the another data packet being a data packet for a protocol other than IP.

[0202] The first network entity may use the sequence number for reordering and / or detection for duplication or absence of the IP data packets. Alternatively, where the IP datapacket encapsulates the sequence number and another data packet, the first network entity may not be able to use the sequence number for reordering and / or detection of duplication or absence prior to forwarding. This tends to be owing to the further encapsulation. In such examples, the sequence numbers together with the another data packets may be forwarded to the target.

[0203] The IP data packet and sequence number of the datagram may be encapsulated within a QUIC packet. The QUIC packet may be encapsulated within a UDP packet. The UDP packet may be encapsulated within a second IP packet.

[0204] The datagram may be a HTTP datagram.

[0205] The sequence number may comprise an integer value. An increment may have been applied between the integer values of datagrams of the one or more datagrams comprising IP data packets that are associated with being sequentially adjacent each other in the sequence.

[0206] The integer value may be a 32bit integer value. The increment may be one. Thus a first datagram may correspond to the first IP data packet in the sequence and be set an integer value of zero. A subsequent datagram corresponding to an IP data packet next in the sequence may be set an integer value of the modulo of the previous sequence number incremented by one.

[0207] Each datagram of the one or more datagrams may comprise an identifier for indicating a semantic of the datagram. The identifier may have been set to a non-zero value for datagrams including the sequence number.

[0208] The semantic may be related to the proxying in the datagram, for instance the UDP proxying in an HTTP datagram. The identifier may be zero in scenarios where one IP data packet is proxying in the HTTP datagram. The identifier may be non-zero where the datagram comprises a sequence number in addition to the IP data packet.

[0209] The processor may be configured to cause the first network entity to: receive, from a second network entity, one or more N4 rules for the data flow of the MA PDU session.

[0210] The second network entity may be a SMF. The SMF may receive one or more PCC rules from a PCF and then convert the one or more PCC rules to the one or more N4 rules.

[0211] The one or more N4 rules may comprise at least one of: rules for load balancing the data flow of the MA PDU session over a plurality of accesses to the wireless communication network; a target information of the target for the data flow; and an IP information for forwarding the data flow to the target. The IP information may be referred to herein as ‘ipproto’. Alternatively or in addition, the target information and IP information may be received from the UE. The rules for load balancing tend to allow the first network entity to compute whether the UE has performed the load balancing properly by considering the number of received unrepeated and uncorrelated IP data packets via the various accesses with respect to the sequence number.

[0212] Whilst the UE may initiate the sending of IP packets to the first network entity for an MA PDU session, the N4 rules tend to enable the first network entity to transmit a data flow to the UE as well. For example, the at least one processor may be configured to cause the first network entity to transmit, to the UE, a further data flow of a MA PDU session, wherein the further data flow comprises one or more datagrams, each datagram comprising: an IP data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets. In addition, the N4 rules tend to allow the first network entity to predict MPQUIC steering function, transport mode (i.e., sequential IP packets as the payload of an HTTP datagram for an application or service in an SDP), for example. Given that the first network entity may receive N4 rules and the UE receives ATSSS rules, the context ID may be less important in these examples.

[0213] The plurality of accesses may comprise 3 GPP accesses associated with different subscriptions. The plurality of accesses may comprise a combination of non-3GPP accesses and 3 GPP accesses.

[0214] The first network entity may be a user plane function ‘UPF’.

[0215] The first network entity may be an IP proxy.

[0216] There is further provided a method performed by a UE, the method comprising: transmitting, to a first network entity of a wireless communication network, a data flow of a MA PDU session, wherein the data flow comprises one or more datagrams, each datagram comprising: an IP data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets.

[0217] The IP data packet may encapsulate the sequence number and another data packet, the another data packet being a data packet for a protocol other than IP.

[0218] The IP data packet and sequence number of the datagram may be encapsulated within a QUIC packet. The QUIC packet may be encapsulated within a UDP packet. The UDP packet may be encapsulated within a second IP packet.

[0219] The datagram may be a HTTP datagram.

[0220] The sequence number may comprise an integer value. The method may comprise applying an increment between the integer values of datagrams of the one or more datagrams comprising IP data packets that are associated with being sequentially adjacent each other in the sequence.

[0221] The integer value may be a 32bit integer value. The increment may be one. Thus a first datagram may correspond to the first IP data packet in the sequence and be set an integer value of zero. A subsequent datagram corresponding to a IP data packet next in the sequence may be set an integer value of the modulo of the previous sequence number incremented by 1.

[0222] Each datagram of the one or more datagrams may comprise an identifier for indicating a semantic of the datagram. The method may comprise setting the identifier to a non-zero value for datagrams including the sequence number.

[0223] The semantic may be related to the proxying in the datagram, for instance the UDP proxying in an HTTP datagram. The identifier may be zero in scenarios where one IP data packet is proxying in the HTTP datagram. The identifier may be non-zero where the datagram comprises a sequence number in addition to the IP data packet.

[0224] The method may comprise receiving, from a second network entity, one or more ATSSS rules for transmitting the data flow of the MA PDU session; and transmitting the data flow of the MA PDU session in accordance with the one or more ATSSS rules.

[0225] The second network entity may be a SMF. The SMF may receive one or more PCC rules from a PCF and then convert the one or more PCC rules to the one or more ATSSS rules.

[0226] The one or more ATSSS rules may comprise at least one of: rules for load balancing the data flow of the MA PDU session over a plurality of accesses to the wireless communication network; a target information of a target for the data flow; and an IP information for forwarding the data flow to the target.

[0227] The plurality of accesses may comprise 3 GPP accesses associated with different subscriptions. The plurality of accesses may comprise a combination of non-3GPP accesses and 3 GPP accesses.

[0228] The method may comprise transmitting, to the first network entity, a request to establish a forwarding tunnel to the target associated with the target information using an IP associated with the IP information.

[0229] The first network entity may be a user plane function ‘UPF’.

[0230] The first network entity may be an IP proxy.

[0231] There is further provided a method performed by a processor, comprising: outputting a data flow for a MA PDU session, wherein the data flow comprises one or more datagrams, each datagram comprising: an IP data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets.

[0232] The IP data packet may encapsulate the sequence number and another data packet, the another data packet being a data packet for a protocol other than IP.

[0233] The IP data packet and sequence number of the datagram may be encapsulated within a QUIC packet. The QUIC packet may be encapsulated within a UDP packet. The UDP packet may be encapsulated within a second IP packet.

[0234] The datagram may be a hypertext transfer protocol (HTTP) datagram.

[0235] The sequence number may comprise an integer value. The method may comprise applying an increment between the integer values of datagrams of the one or more datagrams comprising IP data packets that are associated with being sequentially adjacent each other in the sequence.

[0236] The integer value may be a 32bit integer value. The increment may be one. Thus a first datagram may correspond to the first IP data packet in the sequence and be set an integer value of zero. A subsequent datagram corresponding to an IP data packet next in the sequence may be set an integer value of the modulo of the previous sequence number incremented by one.

[0237] Each datagram of the one or more datagrams may comprise an identifier for indicating a semantic of the datagram. The method may comprise outputting the identifier as a non-zero value for datagrams comprising the sequence number.

[0238] The semantic may be related to the proxying in the datagram, for instance the UDP proxying in an HTTP datagram. The identifier may be zero in scenarios where one IP data packet is proxying in the HTTP datagram. The identifier may be non-zero where the datagram comprises a sequence number in addition to the IP data packet.

[0239] The method may comprise: inputting one or more ATSSS rules for the data flow of the MA PDU session; and outputting the data flow of the MA PDU session in accordance with the one or more ATSSS rules.

[0240] The one or more ATSSS rules may comprise at least one of: rules for load balancing the data flow of the MA PDU session over a plurality of accesses to the wireless communication network; a target information of a target for the data flow; and an IP information for forwarding the data flow to the target.

[0241] The method may comprise: outputting a request to establish a forwarding tunnel to the target associated with the target information using an IP associated with the IP information.

[0242] There is further provided a method performed by a first network entity, comprising: receiving, from a UE, a data flow of a MA PDU session, wherein the data flow comprises one or more datagrams, each datagram comprising: an IP data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets; and forwarding, to a target, the IP data packets of the one or more datagrams.

[0243] The method may further comprise: reordering into the sequence, based on the sequence number, the IP data packets of the one or more datagrams; and forwarding, to the target, the sequence of IP data packets.

[0244] The method may comprise detecting and eliminating, based on the sequence number, IP data packets of the one or more datagrams that are duplicates of each other.

[0245] The IP data packet may encapsulate the sequence number and another data packet, the another data packet being a data packet for a protocol other than IP.

[0246] The sequence number and IP data packet of the datagram may be encapsulated within a QUIC packet. The QUIC packet may be encapsulated within a UDP packet. The UDP packet may be encapsulated within a second IP packet.

[0247] The datagram may be a HTTP datagram.

[0248] The sequence number may comprise an integer value. An increment may exist between the integer values of datagrams of the one or more datagrams comprising IP data packets that are associated with being sequentially adjacent each other in the sequence.

[0249] The integer value may be a 32bit integer value. The increment may be one. Thus a first datagram may correspond to the first IP data packet in the sequence and be set an integer value of zero. A subsequent datagram corresponding to an IP data packet next in the sequence may be set an integer value of the modulo of the previous sequence number incremented by one.

[0250] Each datagram of the one or more datagrams may comprise an identifier for indicating a semantic of the datagram. The identifier may be a non-zero value for datagrams comprising the sequence number.

[0251] The semantic may be related to the proxying in the datagram, for instance the UDP proxying in an HTTP datagram. The identifier may be zero in scenarios where one IP data packet is proxying in the HTTP datagram. The identifier may be non-zero where the datagram comprises a sequence number in addition to the IP data packet.

[0252] The method may comprise: receiving, from a second network entity, one or more access N4 rules for the data flow of the MA PDU session.

[0253] The second network entity may be a SMF. The SMF may receive one or more PCC rules from a PCF and then convert the one or more PCC rules to the one or more N4 rules.

[0254] The one or more N4 rules may comprise at least one of: rules for load balancing the data flow of the MA PDU session over a plurality of accesses to the wireless communication network; a target information of the target for the data flow; and an IP information for forwarding the data flow to the target. The IP information may be referred to herein as ‘ipproto’. Alternatively or in addition, the target information and IP information may be received from the UE.

[0255] The method may comprise transmitting, to the UE, a further data flow of a MA PDU session, wherein the further data flow comprises one or more datagrams, each datagram comprising: an IP data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets. The transmitting may be based on / in accordance with the N4 rules. In addition, the N4 rules tend to allow for predicting MPQUIC steering functionality, transport mode (i.e., sequential IP packets as the payload of an HTTP datagram for an application or service in an SDP), for example. Given that the first network entity may receive N4 rules and the UE receives ATSSS rules, the context ID may be less important in these examples.

[0256] The plurality of accesses may comprise 3 GPP accesses associated with different subscriptions. The plurality of accesses may comprise a combination of non-3GPP accesses and 3 GPP accesses.

[0257] The first network entity may be a user plane function (UPF).

[0258] The first network entity may be an IP proxy.

[0259] Whilst the disclosure herein may refer to advantages associated with sequence numbers for MPQUIC and MA PDU sessions, it should be noted that the sequential numbering itself does not exclude or prohibit PDU sessions where it is not a MA PDU session but is a single access or ordinary PDU session.

[0260] The disclosure herein describes cases where IP packets proxied in HTTP datagrams in HTTP / 3 are to be in sequential orders. In particular, the disclosure herein describes such cases when MPQUIC steering functionality is applied for an MA PDU session. The disclosure herein provides for a new semantic for the encapsulated IP packets within the HTTP datagram, to be in sequential order. The disclosure herein describes how to add a sequence number to the IP packets prior to proxying it in an HTTP datagram. If the IP encapsulates another protocol packets, the IP packets may be sequentially numbered by numbering the encapsulated protocol packets.

[0261] There is provided, a method comprising: establishing by a device to a first network entity, a PDU session for transmitting an UPD flow, wherein the UPD flow is for a service or an application and is according to one or more rules transmitted to the device and the first network entity by a second network entity via a third network entity; wherein the UDP flow comprises one or more datagrams, the one or more datagrams, each containing: an identifier; a sequence number; and a payload, wherein the payload is an IP packet; and wherein the identifier indicates a semantic of the first payload.

[0262] The first network entity may act as IP proxy and reorder IP packets; and detect and eliminate duplicated IP packets, prior to forwarding them towards a target.

[0263] The first network entity may be a UPF; the second network entity may be an SMF; and the third network entity may be a PCC, wherein the PCF transmits one or more PCC rules to the SMF which converts the one or more PCC rules to one or more ATSSS rules which are sent to the device; wherein the SMF converts the one or more PCC rules to one or more N4 rules which are sent to the UPF.

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

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

[0266] The following abbreviations are relevant in the field addressed by this document: 5GCN, 5G Core Network; 5GS, 5G System; AMF, Access and Mobility Management Function; ANDSP, Access Network Discovery and Selection Policy; API, Application Programming Interface; APN, Access Point Name; ATSSS, Access Traffic Steering, Switching, Splitting; 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; 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, PolicyControl Function; PCO, Protocol Configuration Options; PD, Protocol Discriminator; PDN, Packet Data Network; PDN GW, PDN Gateway; 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; PTI, Procedure Transaction Identity; P-TMSI, Packet Temporary Mobile Subscriber Identity; RAI, Routing Area Identity; 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 Enablement Server; S-NSSAI, Single Network Slice Selection Assistance Information; SSC, Session and Service Continuity; SSID, Service Set Identifier; SUCI, Subscription Concealed Identifier; SUPI, Subscription Permanent Identifier; TA, Tracking Area; TAI, Tracking Area Identity; TAU, Tracking Area Update; TEID, Tunnel Endpoint Identifier; 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; 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; and WLANSP, Wireless Location Area Network Selection Policy.

Claims

CLAIMSWhat is claimed is:

1. A user equipment ‘UE’ for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: transmit, to a first network entity of a wireless communication network, a data flow of a multi-access protocol data unit ‘MA PDU’ session, wherein the data flow comprises one or more datagrams, each datagram comprising: an Internet protocol ‘IP’ data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets.

2. The UE of claim 1, wherein: the IP data packet further encapsulates the sequence number and another data packet, the another data packet being a data packet for a protocol other than IP.

3. The UE of any one of claims 1-2, wherein: the IP data packet and sequence number of the datagram are further encapsulated within a quick user datagram protocol internet connection ‘QUIC’ packet; the QUIC packet is encapsulated within a user datagram protocol ‘UDP’ packet; and the UDP packet is encapsulated within a second IP packet.

4. The UE of any preceding claim, wherein the datagram is a hyper-text transfer protocol ‘HTTP’ datagram.

5. The UE of any preceding claim, wherein the sequence number comprises an integer value, wherein the at least one processor is configured to cause the UE to:apply an increment between the integer values of datagrams of the one or more datagrams comprising IP data packets that are associated with being sequentially adjacent each other in the sequence.

6. The UE of any preceding claim, wherein each datagram of the one or more datagrams comprises an identifier for indicating a semantic of the datagram, wherein the processor is configured to set the identifier to a non-zero value for datagrams including the sequence number.

7. The UE of any preceding claim, wherein the processor is configured to cause the UE to: receive, from a second network entity, one or more access traffic steering switching and splitting ‘ATSSS’ rules for transmitting the data flow of the MA PDU session; and transmit the data flow of the MA PDU session in accordance with the one or moreATSSS rules.

8. The UE of claim 7, wherein the one or more ATSSS rules comprise at least one of: rules for load balancing the data flow of the MA PDU session over a plurality of accesses to the wireless communication network; a target information of a target for the data flow; and an IP information of an IP for forwarding the data flow to the target.

9. The UE of claim 8, wherein the processor is further configured to cause the UE to: transmit, to the first network entity, a request to establish a forwarding tunnel to the target associated with the target information using an IP associated with the IP information.

10. The UE of any preceding claim, wherein the first network entity is a user plane function ‘UPF’.

11. The UE of any preceding claim, wherein the first network entity is an IP proxy.

12. A processor for wireless communication, comprising: at least one controller coupled with at least one memory and configured to cause the processor to: output a data flow for a multi-access protocol data unit ‘MA PDU’ session, wherein the data flow comprises one or more datagrams, each datagram comprising: an Internet protocol ‘IP’ data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets.

13. The processor of claim 12, wherein: the IP data packet further encapsulates the sequence number and another data packet, the another data packet being a data packet for a protocol other than IP.

14. The processor of any one of claims 12-13, wherein the sequence number comprises an integer value, wherein the at least one controller is configured to cause the processor to: apply an increment between the integer values of datagrams of the one or more datagrams comprising IP data packets that are associated with being sequentially adjacent each other in the sequence.

15. The processor of any one of claims 12-14, wherein each datagram of the one or more datagrams comprises an identifier for indicating a semantic of the datagram, wherein the at least one controller is configured to cause the processor to output the identifier as a non-zero value for datagrams comprising the sequence number.

16. The processor of any one of claims 12-15, wherein the at least one controller is configured to cause the processor to: input one or more access traffic steering switching and splitting ‘ATSSS’ rules for the data flow of the MA PDU session; and output the data flow of the MA PDU session in accordance with the one or more ATSSS rules.

17. The processor of claim 16, wherein the one or more ATSSS rules comprise at least one of: rules for load balancing the data flow of the MA PDU session over a plurality of accesses to the wireless communication network; a target information of a target for the data flow; and an IP information of an IP for forwarding the data flow to the target.

18. The processor of claim 17, wherein the at least one controller is further configured to cause the processor to: output a request to establish a forwarding tunnel to the target associated with the target information using an IP associated with the IP information.

19. A first network entity for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the first network entity to: receive, from a user equipment ‘UE’, a data flow of a multi-access protocol data unit ‘MA PDU’ session, wherein the data flow comprises one or more datagrams, each datagram comprising: an Internet protocol ‘IP’ data packet; and a sequence number indicating whether the IP data packet is associated with a position in a sequence of data packets; forward, to a target, the IP data packets of the one or more datagrams.

20. The first network entity of claim 19, wherein the at least one processor is configured to cause the first network entity to forward the IP data packets by causing the first network entity to: reorder into the sequence, based on the sequence number, the IP data packets of the one or more datagrams; and forward, to the target, the sequence of IP data packets.

Images