PDU set marking

Abstract

Various aspects of the present disclosure relate to a first network node for wireless communication, the first network node configured to: receive, from a second network node, a plurality of Protocol Data Units, PDUs, the plurality of PDUs comprising one or more marked PDUs that have been marked by the second network node with PDU set information, and one or more unmarked PDUs that have not been marked by the second network node with PDU set information; mark each of the one or more unmarked PDUs with PDU set information; and send the plurality of PDUs to a third network node, the PDU set information of each PDU being comprised within an encapsulation protocol header extension container; wherein the encapsulation protocol header extension container comprises an indication for distinguishing whether the PDU set information originates from marking by the first network node.

Description

PDU SET MARKINGTECHNICAL FIELD[1] The present disclosure relates to wireless communications, and more specifically to signalling an origin of protocol data unit set marking.BACKGROUND[2] 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[3] An article “a” before an element is unrestricted and understood to refer to “at least one” of those elements or “one or more” of those elements. The terms “a,” “at least one,” “one or more,” and “at least one of one or more” may be interchangeable. As used herein, including in the claims, “or” as used in a list of items (e.g., a list of items prefaced by a phrase such as “at least one of’ or “one or more of’ or “one or both of’) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Also, as used herein, the phrase “based on” shall not be constmed 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, asused 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.[4] Some implementations of the method and apparatuses described herein may further includea network node for wireless communication, hereinafter referred to as a first network node, the first network node comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the first network node to: receive, from a second network node, a plurality of Protocol Data Units, PDUs, the plurality of PDUs comprising one or more marked PDUs that have been marked by the second network node with PDU set information, and one or more unmarked PDUs that have not been marked by the second network node with PDU set information; mark each of the one or more unmarked PDUs with PDU set information; and send the plurality of PDUs to a third network node, the PDU set information of each PDU being comprised within an encapsulation protocol header extension container; wherein the encapsulation protocol header extension container comprises an indication for distinguishing whether the PDU set information originates from marking by the first network node.[5] In some implementations of the method and apparatuses described herein, the network node may comprise a User Plane Function, UPF.[6] The indication may be comprised as a bit field in a user plane protocol PDU set information frame. The PDU set information frame may comprise at least one bit field for at least one of: a PDU Type; an End of Data Burst, EDB; an End PDU of the PDU Set, EPDU; a PDU Set Size Indicator, PSSI; a QoS Flow Identifier, QFI; a PDU Set Sequence Number, PSSN; a PDU Set Importance, PSI; a PDU Sequence Number, PSN, of PDUs part of the PDU Set; a PDU Set Size, PSSize; spare bits reserved for future use; and padding for 32-bit alignment.[7] The indication may be appended to the PSSN field. The indication and the PSSN may form an aggregate bit field comprising an Extended PDU Set Sequence Number, EPSSN, the EPSSN disjointly partitioning the PDUs with PDU Set information originating from unmarked PDUs from the PDUs with PDU Set information originatingfrom marked PDUs. The indication bit field may correspond to a least significant bit of the EPSSN.[8] A set of odd-valued EPSSNs may map to PDUs with PDU Set information originating from unmarked PDUs and a set of even-valued EPSSNs may map to the PDUs with PDU Set information originating from marked PDUs; or a set of even-valued EPSSNs may map to PDUs with PDU Set information originating from unmarked PDUs and a set of odd-valued EPSSNs may map to PDUs with PDU Set information originating from marked PDUs.[9] The user plane protocol PDU set information frame may correspond to a downlink, DL, frame comprising a non-zero PDU Type field, the non-zero PDU Type field further comprising the indication. The DL frame comprising the non-zero PDU Type field may be a DL LONE PDU SET INFORMATION frame.

[0010] The DL frame comprising the non-zero PDU Type field may further comprise at least one bit field for at least one of: a QoS Flow Identifier, QFI; an End PDU of the PDU Set, EPDU; a PDU Set Sequence Number, PSSN; and a PDU Set Importance, PSI.

[0011] The DL frame comprising the non-zero PDU Type field may not comprise bit fields for some or all of : an End of Data Burst, EDB; a PDU Set Size Indicator, PSSI; a PDU Sequence Number, PSN, of PDUs part of the PDU Set; and a PDU Set Size, PSSize.

[0012] The encapsulation protocol may be GPRS Tunneling Protocol for User Plane, GTP-U.

[0013] The second network node may comprise at least one of an Application Server and a media source encoder, the media source encoder generating media content payloads of the plurality of PDUs.

[0014] Some implementations of the method and apparatuses described herein may further include a processor for wireless communication in a network node, comprising: at least one controller coupled with at least one memory and configured to cause the processor to: receive a plurality of Protocol Data Units, PDUs, from a second network node, the plurality of PDUs comprising one or more marked PDUs that have been markedby the second network node with PDU set information, and one or more unmarked PDUs that have not been marked by the second network node with PDU set information; mark each of the one or more unmarked PDUs with PDU set information; and send the plurality of PDUs to a third network node, the PDU set information comprised within an encapsulation protocol header extension container; wherein the encapsulation protocol header extension container comprises an indication for distinguishing whether the PDU set information originates from marking by the network node.

[0015] Some implementations of the method and apparatuses described herein may further include a network node for wireless communication, hereinafter referred to as a third network node, the third network node comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the third network node to: receive a plurality of PDUs from a first network node with PDU set information comprised within an encapsulation protocol header extension container, wherein the encapsulation protocol header extension container further comprises an indication identifying whether the PDU set information originates from the first network node or a second network node; and determine whether the PDU set information originates from the first network node based upon the indication.

[0016] Some implementations of the method and apparatuses described herein may further include a method performed by a first network node, the method comprising: receiving a plurality of Protocol Data Units, PDUs, from a second network node, the plurality of PDUs comprising one or more marked PDUs being PDUs that have been marked by the second network node with PDU set information, and one or more unmarked PDUs being PDUs that have not been marked by the second network node with PDU set information; marking each of the one or more unmarked PDUs with PDU set information; and sending the plurality of PDUs to a third network node, the PDU set information comprised within an encapsulation protocol header extension container; wherein the encapsulation protocol header extension container comprises an indication for distinguishing whether the PDU set information originates from marking by the first network node.

[0017] In some implementations of the method and apparatuses described herein the first network node comprises a User Plane Function, UPF. The third network node may be a radio access network, RAN, node, and the second network node may comprise at least one of an Application Server, AS, and a media source encoder, the media source encoder generating media content payloads of the plurality of PDUs.BRIEF DESCRIPTION OF THE DRAWINGS

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

[0019] Figure 2 illustrates a Core Network extended reality media architecture.

[0020] Figure 3 illustrates a one-byte RTP header extension for PDU set marking.

[0021] Figure 4 illustrates a two-byte RTP header extension for PDU set marking.

[0022] Figure 5 illustrates an RTC functional architecture.

[0023] Figure 6 illustrates an RTP & RTCP Protocol Stack.

[0024] Figure 7 illustrates RTP / SRTP packet formats and header information.

[0025] Figure 8 illustrates a WebRTC protocol stack.

[0026] Figure 9 illustrates an RTP / SRTP header extension format and syntax.

[0027] Figure 10 illustrates a DL PDU SET INFORMATION Format.

[0028] Figure 11 illustrates a DL PDU SET INFORMATION Format with an indication of a source of PDU Set Information marking.

[0029] Figure 12 illustrates a DL PDU SET INFORMATION Format with an indication of a source of PDU Set Information marking.

[0030] Figure 13 illustrates a DL LONE PDU SET INFORMATION Format.

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

[0032] Figure 15 illustrates an example of a processor 1500 in accordance with aspects of the present disclosure.

[0033] Figure 16 illustrates an example of a network equipment (NE) 1600 in accordance with aspects of the present disclosure.

[0034] Figure 17 illustrates a flowchart of a method performed by a network equipment in accordance with aspects of the present disclosure.

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

[0036] 3 GPP established in Release 18 the concept of a protocol data unit (PDU) set to enable cross-layer optimizations of extended reality (XR) traffic transport over cellular networks. A PDU set is one or more PDUs carrying the payload of one unit of information generated at the application level (e.g. a frame or video slice for XR media (XRM) Services). The application is not limited to XR implementations and applies to any form of transmission using PDU sets.

[0037] XR is referred to hereafter as an umbrella term for different types of realities, such as Virtual Reality (VR), Augmented Reality (AR), and Mixed Reality (MR).

[0038] VR is a rendered version of a delivered visual and audio scene. The rendering is designed to mimic the visual and audio sensory stimuli of the real world as naturally as possible to an observer or user as they move within the limits defined by the application. Virtual reality usually, but not necessarily, requires a user to wear a head mounted display (HMD), to completely replace the user's field of view with a simulated visual component, and to wear headphones, to provide the user with the accompanying audio. Some form of head and motion tracking of the user in VR is usually also implemented to allow the simulated visual and audio components to be updated to ensure that, from the user's perspective, items and sound sources remain consistent with the user's movements. In some implementations additional means to interact with the virtual reality simulation may be provided but are not strictly necessary.

[0039] AR is when a user is provided with additional information or artificially generated items, or content overlaid upon their current environment. Such additional information or content will usually be visual and / or audible and their observation of their current environment may be direct, with no intermediate sensing, processing, and rendering, or indirect, where their perception of their environment is relayed via sensors and may be enhanced or processed.

[0040] MR is an advanced form of AR where some virtual elements are inserted into the physical scene with the intent to provide the illusion that these elements are part of the real scene.

[0041] XR refers to all real-and-virtual combined environments and human-machine interactions generated by computer technology and wearables. It includes representative forms such as AR, MR and VR and the areas interpolated among them. The levels of virtuality range from partially sensory inputs to fully immersive VR. An aspect of XR is the extension of human experiences especially relating to the senses of existence (represented by VR) and the acquisition of knowledge (represented by AR).

[0042] When transmitting XR data, an XR application marks the PDUs it generates with PDU Set Information that may be used by the core and access networks for optimized content delivery and fulfilling Quality of Service (QoS) guarantees (e.g., latency, based on PDU Set Delay Budget requirements from the application server, reliability, based on PDU Set Error Rate requirements from the application server etc.). The PDU Set Information may include one or more of: indications of the PDU Set boundaries (start and end), sequencing, importance, and a PDU Set Size (PSSize). However, as PDU Set marking is only possible atop of real-time protocol (RTP), there are cases where PDU Set marking may not be possible (e.g., for RTCP control packets on the same flow with the media) at the application source encoder, or alternatively, may not be desired (e.g., for audio packets multiplexed with video packets, where audio packets size is comparable with PDU Set marking overhead). In such instances the PDUs are referred to as lone PDUs. As such, for QoS flows with PDU Set handling enabled (i.e., where all PDUs need to be part of a PDU Set and marked accordingly with PDU Set information), the core network, i.e., a user plane function (UPF), additionally determines and marks PDU Set information for unmarked individual PDUs, or alternatively, lone PDUs. For interoperable marking by the UPF andlow complexity handling by a next-generation radio access network (NG-RAN) of PDU Set information of lone PDUs, care needs to be taken in handling the PDU Set Sequence Number and avoid collisions between the application sourced PDU Sets and the lone PDUs’ PDU Sets. The subject matter therein provides a solution to this extent by marking the source of the PDU Sets to the NG-RAN in path to N3 protocol headers, i.e., using general packet radio service (GPRS) tunnelling protocol user plane (GTP-U) protocol headers for PDU Set information. The solution can indicate explicitly to a radio access network (RAN) the type, or alternatively, origin of PDU Set marking. The problem of PDU Set marking for lone PDUs is addressed for QoS flows with PDU Set handling enabled containing both PDU Sets marked at the application server (AS) and PDU Sets marked at the UPF (i.e., lone PDUs). In particular, the problem solved is collision avoidance of PDU Set Sequence Numbers (PSSN) across the two types of PDU Sets. This problem arises given that UPF handling of lone PDUs is underspecified and left to UPF implementations which may incorrectly assign PSSNs to lone PDUs that collide with other PSSNs of PDU Sets in-flight marked by the media source encoder. This problem has impacts on NG-RAN implementations which use the PSSN to distinguish among PDU Sets and schedule them appropriately according to the QoS flow’s PDU Set QoS parameters.

[0043] According to aspects of the present disclosure, an indication is introduced for downlink (DL) transmissions between the UPF and NG-RAN at the PDU Set Information User Plane Protocol comprised within the GTP-U extension headers. The indication has the role of differentiating between the PDU Sets originating from lone PDUs (i.e., determined by the UPF when left unmarked by the media source encoder), and the PDU Sets originating from the media source encoder. The indication may a single bit which may be encoded as either part of an existing PDU Type DL PDU SET INFORMATION frame, doubling the PDU Set Sequence Number and avoiding collisions between lone PDU Sets and application server (AS)-marked PDU Sets by set partitioning. Alternatively, the indication may be encoded as a new PDU Type DL ‘LONE PDU SET INFORMATION’ frame specific for lone PDU Sets.

[0044] Aspects of the present disclosure advantageously avoid leaving details of PSSN determination between lone PDU Sets (i.e., marked by the UPF based on lone PDUdetermination) and regular PDU Sets (i.e., marked by the AS) to UPF vendor implementations. This has the benefit of fixing signalling and avoiding implementationspecific solutions to PSSN collision avoidance issues which may create problems, including inter-operation between different NG-RAN and UPF vendors.

[0045] The present disclosure also provides advantages over alternative solutions such as partitioning the PSSN namespace at the media source encoder for PDU Set marking. Such an approach assumes different behaviours of sender, network node and RAN nodes to the values and partitioning scheme the PSSN field will have to take. This breaks backwards compatibility between Release-19 and Release-18 of 3GPP and replaces the existing semantics of the PSSN field for PDU Set marking across 5G System, 5GS. Aspects of the solution proposed herein maintain backwards compatibility between Release-19 and Release-18 of 3GPP and yet solves the highlighted problem of PDU Set marking for lone PDUs. Aspects of the present disclosure are described in the context of a wireless communications system.

[0046] Figure 1 illustrates an example of a wireless communications system 100 in accordance with aspects of the present disclosure. The wireless communications system100 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.

[0047] 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 signaling, transmit signaling) over a Uu interface.

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

[0049] 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 Intemet-of-Everything (loE) device, or machine-type communication (MTC) device, among other examples.

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

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

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

[0053] 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). ThePDU 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).

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

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

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

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

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

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

[0060] The XRM feature in 3 GPP Release 18 at the core network (CN) level introduced the concept of a PDU Set to handle QoS requirements of XRM applications and streams with a better granularity beyond 5GRel-17 QoS flow possibilities. As such, a PDU set is composed of one or more PDUs carrying the payload of one unit of information generated at the application level (e.g. a frame or video slice for XRM Services). In some implementations all PDUs in a PDU Set are needed by the application layer to use the corresponding unit of information. In other implementations, the application layer can still recover parts or all of the information unit, when some PDUs are missing. In addition, the PDU set is associated with QoS requirements in terms of delay budget and error rate.

[0061] A PDU Set Delay Budget (PSDB) defines an upper bound for the time that a PDU-Set may be delayed between the UE and the N6 termination point at the UPF. PSDB applies to the DL PDU-Set received by the UPF over the N6 interface, and to the UL PDU- Set sent by the UE, and respectively.

[0062] A PDU Set Error Rate (PSER) defines an upper bound for the rate of PDU Sets (e.g. set of IP packets constituting a PDU-Set) that have been processed by the sender of a link layer protocol (e.g. RLC in RAN of a 3GPP access) but where all of the PDUs in the PDU Set are not successfully delivered by the corresponding receiver to the upper layer (e.g. a PDCP in a RAN of a 3GPP access). The PSER is used to determine an upper bound for a rate of non-congestion-related packet losses.

[0063] Figure 2 illustrates an example of CN XRM architecture and handling of PDU sets in accordance with aspects of the present disclosure.

[0064] The general processing steps for DL traffic are:

[0065] In step 1, the Application Function (AF) provides QoS requirements for packets of a PDU set to the PCF (i.e. PSDB and PSER) and information to identify the application (i.e. 5-tuple or application id). The AF may also include an importance parameter for a PDU set and information for the core network to identify packets belonging to a PDU set.

[0066] In step 2, the PCF derives QoS rules for the XR application (e.g. by using a 5QI for XR media traffic) and specific QoS requirements for the PDU set and configures a session management function (SMF). The PCF may include PCC rules per importance of a PDU set (according to information received from the AF or based on operator configuration).

[0067] In step 3, the SMF establishes a QoS flow according to the QoS rules by the PCF and configures the UPF to route packets of the XR application to a QoS flow, and, in addition, to enable PDU set handling. The SMF also provides the QoS profile containing PDU set QoS requirements to the RAN via the AMF.

[0068] In step 4, the UPF inspects the packets and determines packets belonging to a PDU set (e.g., based on a UPF implementation given, for instance inspection of the RTP packet headers, or based on AS-marked PDU set information transmitted over RTP PDU Set header extensions, i.e., as determined based on SDP offer / answer negotiation of the RTP header extension urn: 3gpp:pdu-set-marking:rel-l 8. When the UPF detects packets of a PDU set the UPF marks the packets belonging to a PDU set within a GTP-U header. The GTP-U header information includes a PDU Set sequence number and the size of the PDU Set. The UPF may also determine the importance of the PDU Set either based on UPF implementation means, information provided by the AF or information provided as metadata from the application server. Based on the importance of the PDU set the UPF may route the traffic to a corresponding QoS flow (according to the rules received from the SMF) or include the importance of the PDU Set within a GTP-U header.

[0069] In step 5, the RAN identifies packets belonging to a PDU Set (based on the GTP-U marking) and handles the packets of the PDU Set according to the QoS requirements of the PDU Set provided by the SMF. In one implementation the RAN node may use a different radio bearer with higher QoS requirement (according to the PDU set PSDB / PSER) to guarantee delivery of the packets of the PDU Set, while using a different radio bearer according to the 5QI of the QoS flow for the non-PDU Set packets.

[0070] In XRM Release 18, once enabled the PDU Set QoS integrated handling, the PSA UPF identifies PDUs that belong to PDU Sets and determines for each PDU Set the PDU set information below sent over to the NG-RAN in the GTP-U header. The PDU Set Information may comprise:PDU Set Sequence Number.Indication of End PDU of the PDU Set.PDU Sequence Number within a PDU Set.PDU Set Size in bytes.PDU Set Importance, which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS Flow.

[0071] The PDU Set information is then used by the NG-RAN for PDU Set based QoS handling as described above. The NG-RAN may use Priority Levels as of across QoS Flows and PDU Set Importance within a QoS Flow for PDU Set level packet discarding in presence of congestion.

[0072] A PDU session anchor (PSA)I UPF identifies PDUs that belong to PDU Sets and if the UPF receives a PDU that does not belong to a PDU Set based on Protocol Description for PDU Set identification (e.g., has not been marked with PDU Set information by the AS), then the UPF still maps the PDU to a PDU Set and determines the PDU Set Information as described above. This ensures that for a QoS flow with PDU Set enabled all the PDUs belong to a PDU Set. To this end, if the PSA UPF receives a PDU that does not belong to a PDU Set, it is assumed that the UPF determines the PDU Set Importance value based in some embodiments on pre-configuration and in other embodiments on an AS / AF signaled default importance.

[0073] The multimedia sender (e.g., either at the UE or at the AS) PDU Set information listed above is provided in some embodiments via a one-byte RTP Header Extension for the marking of PDU Sets, and End of Bursts as defined by TS 26.522.

[0074] Figure 3 is a diagram showing a one-byte RTP Header Extension for the marking of PDU Sets by the AS.

[0075] Figure 4 shows a two-byte RTP Header Extension for the marking of PDU Sets, and End of Bursts as defined by TS 26.522 according to another embodiment.

[0076] The semantics of the fields denoted in Figure 3 and Figure 4 of the RTP Header Extension for the marking of PDU Set and End of Bursts are:End PDU of the PDU Set [E] (1 bit field) which is a flag set to 1 for the last PDU of the PDU Set and set to 0 for all other PDUs of the PDU SetEnd of Data Burst [D] (1 bit field) which indicates the end of a Data Burst being set to a non-zero value when the end of data burst is present and 0 otherwisePDU Set Importance [PSI] (4 bits field) which indicates the importance of a PDU Set compared to other PDU Sets within the same QoS flow. Lower values indicate a higher importance PDU Set with the highest importance PDU Set of 1 and the lowest importance PDU Set of 15, while an undetermined / unknown importance of a PDU Set is mapped to 0.PDU Set Sequence Number [PSSN] (10 bits field) which encodes the sequence number of the PDU Set to which the current PDU belongs acting as a 10-bit numerical identifier for the PDU Set and wraps around at 1023.PDU Sequence Number within a PDU Set [PSN] (6 bits field) which indicates the sequence number of the current PDU within the PDU Set. The PSN is set to 0 for the first PDU in the PDU Set and incremented monotonically for every PDU in the PDU set in order of transmission from the sender. PSN wraps around 63.PDU Set Size [PSSize] (24 bits field) which indicates the total size of all PDUs of the PDU Set to which this PDU belongs. This field is optional and subject to an SDP signaling offer / answer negotiation, where the RTP sender may indicate whether it will be able to provide the size of the PDU Set for that RTP stream. If not enabled, the field is not present. If enabled, but the RTP sender (e.g., the UE or AS) is not able to determine the PDU Set Size for a particular PDU Set, it shall set the value to 0 in all PDUs of that PDUSet. The PSSize indicates the size of a PDU Set including RTP / UDP / IP header encapsulation overhead of its corresponding PDUs. The PSSize is expressed in bytes.Number of PDUs in the PDU Set [NPDS] (16 bits field) which indicates the total number of PDUs belonging to the same PDU Set. This field is optional and subject to an SDP signaling offer / answer negotiation, where the RTP sender (e.g., the UE or AS) may indicate whether it will provide the number of PDUs within the PDU Set for that RTP stream. If enabled, but the RTP sender is not able to determine the Number of PDUs in the PDU Set, it shall set the value to 0 in all PDUs of that PDU Set. It is recommended to add the Number of PDUs in the PDU Set field when the PDU Set Size field is present.

[0077] Reciprocal processing is applicable to uplink (UE) transmission whereas the role of UPF packet inspection is taken by the UE which is expected to mark (at application level) packets, inspect packets (at ingress of Layer 2), determine packets belonging to a PDU set, and signal accordingly the PDU set to the RAN (e.g., by means of Buffer Status Reports (BSRs), and / or Delay Status Reports (DSRs) comprising at least in part PDU Sets) for scheduling and resource allocation corresponding to an associated data radio bearer (DRB) fulfilling capable of fulfilling the PDU set QoS requirements (i.e., PSDB and PSER). The low-level signaling mechanism associated with the UL UE-to-RAN information passing are up to the specification and implementations of RAN signaling procedures.

[0078] 3GPP specified a general media delivery architecture in Release 18, unifying concepts from both 5G Media Streaming (MS) (as specified in TS 26.501) and Real-Time Communications (RTC) (as specified in TS 26.506) subsystems under a generic media delivery architecture introduced in TS 26.501. The 5GRTC realization of the generic media delivery architecture aims at enabling media delivery services for RTC such as XR, AR conversational, mobile cloud gaming, and alike.

[0079] The media delivery is setup and exchanged between two or more RTC endpoints over a 5G System (5GS) and is based on the WebRTC Framework comprised in the RTC endpoints. Examples of RTC endpoints are typically UEs, or RTC AS, possibly deployed as an edge computing server or within an ASP data network domain. The ASP provides therefore a RTC Application on the UE to make use of the RTC endpoint and networkfunctions using interfaces and APIs as defined in TS 26.506 and illustrated in the functional block diagram of Figure 5, which instantiates the generic media delivery architecture over 5GS for RTC services.

[0080] Figure 5 shows a 5G RTC functional architecture and block diagram. With reference to Figure 5, the 5G RTC exposed APIs by corresponding functional blocks are named in italics, the solid lines are reference points and interfaces part of the 5G RTC subsystem, dashed lines are in scope of 5GS (e.g., as specified in general 5GS architecture of TS 23.501), and dotted lines are in scope of the ASP and may be customized to match requirements of various services / applications deployed over 5G RTC architecture.

[0081] The following RTC functional blocks are illustrated in Figure 5:RTC AF: An AF dedicated to RTC Media Delivery corresponding.RTC AS: An AS dedicated to RTC Media Delivery.RTC Client: A UE Media Client internal function dedicated to RTC Media Delivery comprising:RTC Media Session Handler: An entity on the UE that communicates with the RTC AF to configure, control and support delivery of an RTC media session.RTC Access Function: An entity on the UE that communicates with an RTC AS, or another RTC Access Function in a peer UE, to access and deliver media content. The media access function for example may be further sub-divided into content delivery protocols, codecs, media types and metadata representation.WebRTC Framework: A well-defined subset of the WebRTC protocol stack for data transport and data framing that supports real-time media communication between an RTC endpoint and its peer(s) within the scope of an RTC session.

[0082] The following reference points are illustrated in Figure 5:RTC-1 : Reference point between the RTC Application Provider and the RTC AF for the provisioning of Media Delivery sessions.RTC-3 : Reference point between the RTC AF and the RTC AS for the purposes of RTC AS configuration and / or for media session handling (e.g., QoS / QoE reporting, and / or reconfiguration) in relation to Media Delivery.RTC-4: Reference point used to exchange the WebRTC media traffic (i.e., (S)RTP, RTCP, data channel application data or other application data) between the RTC Access Function and the Media Function of the RTC AS, as well as to exchange signalling information (i.e., SDP offer-answer procedure) relating to the WebRTC session with the RTC AS such as WebRTC Signalling Function.RTC-5: Reference point RTC-5 used to convey configuration information from the RTC AF to the RTC Media Session Handler and is used by the RTC Media Session Handler to request media session handling support from the RTC AF for RTC sessions (e.g., media configurations recommendations, ICE negotiation and configuration of STUN / TURN servers location, QoS allocation, QoE metrics reporting configuration and QoE / media consumption metrics reporting, etc.)RTC-6: Reference point used as Client API exposing RTC Media Session Handler functionality to RTC Application.RTC-7: Reference point used as Client interface to provide the capabilities of RTC Access Function as API to RTC Application (e.g., Native WebRTC App, W3C-defined JavaScript APIs for WebRTC etc.)RTC-8: Proprietary reference point between the RTC Application and the RTC Application Provider, which may be used to exchange configuration information related to the RTC session or the application.RTC-10: Reference point between one instance of the Media AS and another for the purpose of distributed service chaining over multiple RTC AS instances (e.g., using different functions hosted by different RTC AS instances).RTC-11 : Reference point used by the RTC Access Function to configure media session handling in the RTC Media Session Handler and / or used by the RTC Media Session Handler to configure media access in the RTC Access Function. This reference point may be internal only to an implementation and not exposed as API externally to RTC Application developers.RTC-12: Reference point used for peer-to-peer media delivery over WebRTC traffic between RTC Access Functions in different UEs when the 5GS permits peer- to-peer media transport. The protocols supported at this reference point shall be a subset of those RTC 4 for media delivery, i.e., WebRTC.

[0083] In Release 17 SA4 analyzed for instance the XR traffic model, and concluded the QoS requirements in terms of delay budget, data rate and error rate necessary for a satisfactory experience at the application level. These led to 4 additional 5QIs for the 5GS XR QoS flows as delay-critical GBR 5QIs valued 87-90. The latter are applicable to XR video streams and control metadata necessary to provide the immersive and interactive XR experiences.

[0084] The XR video traffic is mainly composed of multiple DL / UL video streams of high resolution (e.g., at least 1080p dual-eye buffer usually), frames-per-second (e.g., 60+ fps) and high bandwidth (e.g., usually at least 20-30 Mbps) which needs to be transmitted across a network with minimal delay (typically upper bounded by 15-20 ms) to maintain a reduced end-to-end application round-trip interaction delay. The latter requirements are of critical importance given the XR application dependency on cloud / edge processing (e.g., content downloading, viewport generation and configuration, viewport update, viewport rendering, media encoding / transcoding etc.). Furthermore, XR traffic also includes one or more audio streams, as well as user interaction metadata (e.g., user actions, user inputs, user pose), or alternatively, feedback and control metadata (actions, XR space metadata, as well as transport control and feedback messages over RTCP for instance).

[0085] The traffic of immersive and interactive XR applications as the ones described above require often real-time suited transport architectures and protocols. As part of the latter, the state of art is represented by the RTP, its securely provisioned Secure Real-time Transport Protocol (SRTP), and its web-targeted stack Web Real-Time Communications WebRTC, respectively.

[0086] RTP is a media codec agnostic network protocol with application-layer framing used to deliver multimedia (e.g., audio, video etc.) data in real-time over IP networks. It is used in conjunction with a sister protocol for control, i.e., Real-time Transport ControlProtocol (RTCP), to provide end-to-end features such as jitter compensation, packet loss and out-of-order delivery detection, synchronization, and source streams multiplexing.

[0087] An overview of the RTP and RTCP stack is shown in Figure 6. SRTP is a secured version of RTP, providing encryption (mainly by means of payload confidentiality), message authentication and integrity protection (by means of PDU, i.e., headers and payload, signing), as well as replay attack protection. Similarly to RTP, the SRTP sister protocol is SRTCP. This provides the same functions as its RTCP counterpart.

[0088] The RTP and SRTP header information share the same format as shown in Figure 7. As such, in vanilla SRTP versions, the RTP header information is still accessible but non-modifiable, whereas the payload is encrypted. These security provisions are illustrated in part in the right-hand side of Figure 7. Furthermore, the key exchange and additional security parameters necessary to use SRTP are based upon the Datagram Transport Layer Security (DTLS) key exchange procedure. SRTP is used for these reasons as the transport protocol for media in the WebRTC stack which ensures secure RTC multimedia communications over web browser interfaces.

[0089] An overview of the WebRTC stack is provided in Figure 8. As illustrated, an IP layer carries signaling from the data plane and the control plane. The data plane stack comprises functions for User Datagram Protocol (UDP), Interactive Connectivity Establishment (ICE), Datagram Transport Layer Security (DTLS), SRTP, SRTCP, media codecs, Quality Control and SCTP. ICE may use the Session Traversal Utilities for NAT (STUN) protocol and Traversal Using Relays around NAT (TURN) to address real-time media content delivery across heterogeneous networks and NAT rules and firewalls. The SCTP data plane is mainly dedicated as an application data channel and may be non-time critical, whereas the SRTP based stack including elements of control, i.e., SRTCP, encoding, i.e., media codecs, and Quality of Service (QoS), i.e., Quality Control, is dedicated to time-critical transport.

[0090] The data plane is usually established over a single application session (i.e., a 5- tuple) multiplexing the transport of media (i.e., video, audio, haptic media codec pay loads), of user plane quality control and feedback based on RTCP messages and of WebRTC datachannels (i.e., application data such as user chat messages, notifications, user inputs, user actions, user pose etc.) over SCTP / DTLS.

[0091] The RTP / SRTP fixed header information and complete header information (including header extensions) with reference to Figure 7 is as follows:Fixed Header Info• V - 2 bits indicating the protocol version used• P - 1 bit field indicating that one or more zero-padded octets at the end of the payload are present, whereby, among others, the padding may be necessary for fixed-sized encrypted blocks or for carrying multiple RTP / SRTP packets over lower layer protocols.• X - 1 bit indicating that the standard fixed RTP / SRTP header will be followed by an RTP header extension usually associated with a particular data / profile that will carry more information about the data (e.g. generic RTP header extensions framework for RTP / SRTP)• CC - 4 bits indicating number of contributing media sources (CSRC) that follow the fixed header• M - 1 bit intended to mark an information frame boundary in the packet stream, whose behavior is exactly specified by RTP profiles (e.g., H.264, H.265, H.266, AVI etc.)• PT - 7 bits indicating the payload type, which in case of video profiles is dynamic and negotiated by means of SDP (e.g., 96 for H.264, 97 for H.265, 98 for AVI etc.)• Sequence number - 16 bits indicating the sequence number which increments by one with each RTP data packet sent over a session• Timestamp - 32 bits indicating timestamp in ticks of the payload type clock reflecting the sampling instant of the first octet of the RTP data packet (associated for video stream with a video frame), whereas the first timestamp of the first RTP packet is selected at random• Synchronization Source (SSRC) identifier - 32 bits field indicating a random identifier for the source of a stream of RTP packets forming a part of the sametiming and sequence number space, such that a receiver may group packets based on synchronization source for playback.• Contributing Source (CSRC) identifier - list of up to 16 CSRC items of 32 bits each given the amount of CSRC mixed by RTP mixers within the current payload as signaled by the CC bits; the list identifies the contributing sources for the payload contained in this packet given the SSRC identifiers of the contributing sources.Complete Header Information (incl. header extensions)• RTP header extension - a variable length field present if the X bit is marked; the header extension is appended to the RTP fixed header information after the CSRC list if present; the RTP header extension is 32-bit aligned and formed of the following fields:-A 16-bit extension identifier defined by a profile and usually negotiated and determined via the Session Description Protocol (SDP) signaling mechanism-A 16-bit length field describing the extension header length in 32-bits multiples excluding the first 32 bits corresponding to the 16 bits extension identifier and the 16 bits length fields itself- A 32-bit aligned header extension raw data field formatted according to some RTP header extension identifier specified format.

[0092] Figure 9 shows a RTP / SRTP header extension format and syntax. The RTP header extension format and syntax are like the ones of SRTP. In addition, in both RTP and SRTP only one RTP extension header may be appended to the fixed header information. However, for both RTP and SRTP, extensions to the base protocols exist to allow for multiple RTP header extensions of predetermined types to be appended to the fixed header information of the protocols. In some embodiments, RTP header extensions produced at the source may be ignored by the destination endpoints that do not have the knowledge to interpret and process the RTP header extensions transmitted by the source endpoint.

[0093] RTCP is the control sister protocol associated with RTP and similarly, SRTCP is the secured (i.e., integrity protected and authenticated) control sister protocol associated with SRTP. The format and syntax of RTCP packets are defined in various InternetEngineering Task Force (IETF) requests for comments (RFCs), among which the core RTCP messages include as defined in IETF RFC 3550:Sender Reports (SRs) with PT=200, providing quality feedback to the peer RTP endpoint on a per SSRC basis, including additional 20 bytes of information describing the RTP endpoint from which the report originates from;Receiver Reports (RRs) with PT=201, providing same information as SRs except the additional 20 bytes of information describing the RTP endpoint from which the report originates from;Source Description (SDES) with PT=202, providing chunked information describing and identifying the SSRCs / CSRCs items of the RTP media sources (e.g., CNAME, NAME, EMAIL, PHONE, LOC, TOOL as well as private extensions);Goodbye (BYE) RTCP packets with PT=203, indicating that one or more RTP media sources are no longer available in the RTP session;Application-defined (APP) RTCP packets with PT=204, providing an experimental enabler for new applications and new features as they are developed without requiring PT value registration.

[0094] In addition, two major RTCP frameworks are available for extending the RTCP feedback messages, i.e.: the extended audio-video RTP profile for RTCP-based feedback as defined in RFC 4585 providing an extensible framework to register new RTCP messages with transport-level feedback as well as payload-specific feedback. the RTCP extended reporting (RTCP-XR) as defined in RFC 3611 providing an extensible framework for carrying customized feedback report blocks as part of a RTCP-XR similar in approach to canonical SRs or RRs, respectively.

[0095] When multiplexing media flows over RTP, or RTCP with one or more media flows, as per WebRTC protocol, there are PDUs which may not be able to be marked with PDU Set information (e.g., RTCP control and feedback messages), or alternatively, are not desired to be marked with PDU Set information at the source encoder (e.g., small audio packets comparable in size with the PDU Set information), i.e., the RTP sender. Release 18 architecture for XR services in 3 GPP specifies for the DL direction that the PSA UPFidentifies PDUs that belong to PDU Sets (e.g., based on received PDU Set marking in path to N6 from the AS) and marks them accordingly in N3 path over GTP-U to the NG-RAN over the GTP-U protocol headers for PDU Set Information. If the PSA UPF receives a PDU that does not belong to a PDU Set based on Protocol Description for PDU Set identification (i.e., marked by the sender at the AS), then the PSA UPF still maps the PDU to a PDU Set and determines the PDU Set Information (i.e., PDU Set Sequence Number, Indication of End PDU of the PDU Set, PDU Sequence Number within a PDU Set (PSSN), PDU Set Size in bytes, PDU Set Importance). The PDU Set consisting of a single PDU as determined by the UPF is termed a lone PDU Set. The PSA UPF marking of PDU Set Importance for a lone PDU Set value may be based on pre-configuration (e.g., MNO policies configuration). The DL PDU SET INFORMATION frame is the content of the PDU Set Information Container carried over GTP-U header extension for conveying PDU Set Information to NG-RAN.

[0096] A diagram of the DL PDU SET INFORMATION frame is shown in Figure 10, and contains the following syntax and semantics:PDU Type (4 bits): The PDU Type indicates the structure of the PDU Set user plane frame. The field takes the value of the PDU Type it identifies; i.e. "0" for PDU Type 0, as shown in Figure 9. Other values (1-15) are reserved for future PDU Type.Spare (0-2An-l bits): The spare field is set to "0" by the sender and should not be interpreted by the receiver. This field is reserved for later versions.QoS Flow Identifier (QFI) (6 bits). When present this parameter indicates the QoS Flow Identifier of the QoS flow to which the transferred packet belongs.PSSI (PDU Set Size Indicator) (1 bit). This parameter indicates the presence of PDU Set Size (PSSize), i.e., 0 = PSSize not present, and 1= PSSize presentEnd PDU of the PDU Set (EPDU) (1 bit). This parameter indicates whether the current PDU is the last PDU of the PDU set, i.e., 0 = all other PDUs of the PDU Set, 1 = last PDU of the PDU set.End of Data Burst (EDB) (1 bit). This parameter indicates the end of a Data Burst, i.e., 0 = all other PDUs, 1= the last PDU of a data burst.PDU Set Importance (PSI) (4 bits). This parameter indicates the importance of the current PDU Set compared to other PDU Sets within the same QoS flow. Lower values shall indicate a higher importance with the exception that value “0” means sender cannot define importance. PDU Set with the highest importance PDU Set is indicated by 1 and the lowest importance PDU Set is indicated by 15.PDU Set Sequence Number (PSSN) (10 bits). This parameter indicates the sequence number of the PDU Set to which the current PDU belongs acting as an identifier for the PDU Set.PDU Sequence Number within a PDU Set (PSN) (8 bits). This parameter indicates the sequence number of the current PDU within the PDU Set. The PSN shall be set to 0 for the first PDU in the PDU Set and incremented monotonically for every PDU in the PDU set in order of transmission from the sender.PDU Set Size (PSSize) (24 bits, if present). This parameter indicates the total size of all PDUs in bytes of the PDU Set to which the current PDU belongs.

[0097] One concern with Release 18 treatment of a lone PDU Set by the UPF is the handling of PDU Set Information relative to both existing PDU Sets marked by the AS and other adjacent lone PDU Sets on the same QoS flow. A particular issue is the handling of PSSN and avoidance of collisions with existing PSSNs of marked in-flight PDU Sets on the same QoS flow. The latter helps RAN processing in handling PDU Sets of a QoS flow without complexity increase and with interoperability between different RAN and UPF nodes vendors.

[0098] A proposal to disambiguate the PSSN sequencing namespace in Release 19 of 3GPP has been to reduce the PSSN bit space from 10 to 9 and repurpose the most significant bit to separate the sequences for lone PDU Sets, i.e., set MSB for PDU Sets of lone PDUs determined by the UPF to value ' 1'. However, this impacts the Release 18 encoding and treatment of PSSN across the AS (i.e., sender), UPF and NG-RAN, by altering the design of PSSN of the existing RTP header extension for PDU Set marking. In addition, a PSSN reduced from 10 bits to 9 bits reduces the maximum number of video slices supported for a video frame by the PDU Set marking encoding. This is undesirablewhen compared with the maximum number of slices allowed by specification of modern video codecs such as H.264 / H.265 / H.266. It is therefore advisable to find backwards compatible solutions which do not alter the existing PSSN design across the network, nor affect the ability of PDU Set marking for large number of slices should the use arise.

[0099] According to an aspect of the present disclosure, there is introduced an implicit indication in a path to N3 corresponding to distinguishing the lone PDUs mapped to a PDU Set by the UPF. This indication may be used in an interoperable manner and with low overhead and complexity by NG-RAN nodes to determine whether the PDU Set is sourced at the UPF or at the AS, and / or corresponds to a lone PDU, and consequently separate and avoid PSSN collisions between PDU Sets marked by different sources, i.e., the RTP sender or media source encoder (e.g., an AS), and UPF as the core network user plane gateway and a GTP-U tunnel endpoint. The indication is added by the UPF in the path to N3 over GTP- U header extensions for PDU Set information. The indication may be comprised within the existing DL PDU SET INFORMATION frame or complementary to it, e.g., forming a new non-zero PDU Type for PDU SET INFORMATION in GTP-U header extensions as of DL LONE PDU SET INFORMATION frame, specific for lone PDUs treated on a QoS flow enabled with PDU Set handling.First Embodiment

[0100] According to a first embodiment, an indication is added into the DL PDU SET INFORMATION frame. The indication may indicate that the origin of the PDU set information (e.g. PDU Type (=0) DL PDU SET INFORMATION) is a first network node (network equipment), for example, the UPF. In such circumstances, the UPF determines that the PDU does not include PDU set information from a second network node (network equipment), for example, an AS or media source encoder, and marks the content of the DL PDU SET INFORMATION associated with the PDU Set carried over GTP-U. Such a PDU is referred to as an unmarked PDU. The indication may alternatively indicate that the origin of the PDU Type (=0) DL PDU SET INFORMATION is the AS, or alternatively, the media source encoder (according to some embodiments, the media source encoder may be a part of the application server). Such a PDU is referred to as a marked PDU. The UPF thus identifies the PDU Set based on the AS PDU Set marking (e.g., based on processing theRTP header extension for PDU Set marking sent by the AS), and accordingly indicates that the PDU Set information in an encapsulation protocol header extension (e.g. GTP-U protocol header extension), transmitted over N3 to an NG-RAN, for the PDU Set (e.g., as part of the DL PDU SET INFORMATION frame) originates from the AS.

[0101] According to the first embodiment, the indication is appended to the PSSN field of the PDU Type (=0) DL PDU SET INFORMATION frame of the GTP-U header extension. The indication may be comprised as a bit field in a user plane protocol PDU set information frame. In an example realization, corresponding to Figure 11, the indication, e.g., a UPF Marked PDU Set (UMPS) indication may be a bit field corresponding to an information element indicating whether the origin of the PDU Set determination and marking was the UPF in the core network or not. The UMPS bitfield may be formed of a single bit. As a further example, the lone PDUs determined and marked by the UPF as belonging to lone PDU Sets would include in the GTP-U header extension of the DL PDU SET INFORMATION, the UMPS bit field set to a value ‘ 1’, whereas the PDU Sets determined and marked at the media source encoder (e.g., RTP sender), would be processed by the UPF to include in their GTP-U header extension of DL PDU SET INFORMATION, the UMPS set to a value of ‘0’ (i.e. unset), or vice versa. An alternative design applies in conjugate wherein the UMPS indication is replaced by a Source Marked PDU Set (SMPS) considered to indicate whether the origin of the PDU Set determination and marking was the media AS, or alternatively, the media source encoder (e.g., the RTP sender in the media AS, or alternatively a peer RTP endpoint such as a peer UE), or not.

[0102] According to the first embodiment, the appended indication to the PSSN field (e.g., UMPS or alternatively SMPS) may further expand the PSSN field by a bit field corresponding to a least significant bit, as shown in Figure 12. The aggregate PSSN and indication bitfield may further comprise as a result an Expanded PSSN (EPSSN), as highlighted for example in grey within Figure 12, wherein the combination of PSSN and of the appended indication ensures that EPSSN is uniquely identifiable to the NG-RAN for all PDU Sets in-flight and there are no collisions possible between sequences of PDU Sets marked at the origin vs. PDU Sets marked at the UPF, such as lone PDUs mapped to lone PDU Sets. In effect, in some embodiments wherein the appended indication (e.g., UMPS,SMPS) field corresponds to a single bit, the EPSSN is partitioned in two equal disjoint parts wherein the odd integer sequences belong to the UPF marked PDU Sets and the even integer sequences belong to the media source encoder marked PDU Sets, or alternatively, vice versa. The EPSSN numbering space is assumed to loop back circularly based on the PSSN sequencing and provide 2A10, i.e., 1024, possible sequences for in-flight PDU Sets of each category, e.g., 1024 possible values for in-flight PDU Sets marked by a media source encoder, and respectively, 1024 possible values for in-flight PDU Sets corresponding to lone PDUs as determined and marked by the UPF.

[0103] In some embodiments, the added indication to the DL PDU SET INFORMATION frame may be not directly appended to the PSSN field, but placed in another available resource bit mask, such as any Spare bit mask as per Figure 10, that accommodates the bit field width of the added indication information element.

[0104] In some embodiments, the indication may alternatively indicate and distinguish between a Tone PDU Set’, i.e., a PDU Set mapped to a single lone PDU as determined by the UPF, and a ‘regular PDU Set’ (or alternatively ‘other PDU Sets’), irrespective whether the regular PDU Set has been determined by the UPF or the media source encoder. In such embodiments the indication does not point to the origin of the PDU Set, yet it may indicate the PDU Set type between two or more alternatives, one of which corresponds to a Tone PDU Set’. However, in these embodiments such an indication would be functionally and syntactically encoded the same way as the above variants (e.g., UMPS, SMPS).

[0105] The first embodiment proposes that an indication be placed in the DL PDU SET INFORMATION GTP-U frame. The indication (1 bit determining whether PDU Set is a lone PDU Set originating at UPF or not) may be appended to existing PDU Set Sequence Number (PSSN) field. The PSSN and the indication fields may be further aggregated to form an extended PSSN field comprising the indication as least significant bits and partitioning the sequencing numbers space into two disjoint sets, one for the lone PDU Sets and another for the rest. This ensures no collisions are possible for PSSNs of mixed PDU Sets while maintaining backwards compatibility with Release 18 work.Second Embodiment

[0106] According to a second embodiment, a separate PDU Type (i.e., different than ‘0’) is used to indicate a different PDU Set user plane frame over GTP-U transport than the existent DL PDU SET INFORMATION with PDU Type = 0. In this embodiment, a PDU Type with a non-zero value, e.g., value ‘ 1 ’, may be used to determine a new PDU Set Information frame for user plane protocol atop of GTP-U transport as part of the GTP-U header extensions PDU Set Information container.

[0107] According to another aspect, a separate PDU Type (i.e., different than ‘0’) is used to indicate a different PDU Set user plane frame over GTP-U transport than the existent DL PDU SET INFORMATION with PDU Type = 0. In this embodiment, a PDU Type with a non-zero value, e.g., value ‘ 1 ’, may be used to determine a new PDU Set Information frame for user plane protocol atop of GTP-U transport as part of a GTP-U header extensions PDU Set Information container.

[0108] The new PDU Type frame may be in some embodiments specific to a lone PDU mapped to its own lone PDU Set, formed only of the lone PDU as identified by the UPF. In some embodiments, the lone PDU corresponding PDU Set Information is determined and marked by the UPF, correspondingly marked with a PDU Type (e.g., = ‘ 1 ’) of a DL LONE PDU SET INFORMATION frame. In an embodiment the DL LONE PDU SET INFORMATION frame content may be same as for DL PDU SET INFORMATION frame content except for the different PDU Type value, which differs from the value ‘O’.

[0109] According to another aspect, the DL LONE PDU SET INFORMATION frame content may differ from the content of the DL PDU SET INFORMATION frame. In one embodiment, the DL LONE PDU SET INFORMATION may exclude the PSN, PSSize, PSSI and / or EDB fields since these are not of relevant information to lone PDUs. In particular, following changes may be applicable individually or in aggregate relative to the existing DL PDU SET INFORMATION frame of PDU Type = 0 presented earlier as baseline in Figure 10:PSN is always ‘0’ for a lone PDU Set comprising a single PDU, hence the PSN field may be discarded from the DL LONE PDU SET INFORMATION frame to enable 1 byte signaling savings;PSSize is always equal to the lone PDU size of the lone PDU Set, and since the NG-RAN needs to buffer and schedule the PDU of the lone PDU Set anyways, the PSSize may be discarded from the DL LONE PDU SET INFORMATION frame to enable up to 3 bytes signaling savings;PSSI is not needed if PSSize is not present and hence can be omitted and / or its bit repurposed for future usage / reserved;EDB may optionally be excluded (i.e., set to Spare), or alternatively be set always to ‘0’ since an end of a data burst cannot be determined by a UPF reliably without increased complexity and delay (i.e., without intentional packet buffering).

[0110] An example realization of a new DL LONE PDU SET INFORMATION Frame for the user plane protocol atop the GTP-U transport PDU Set Information Container header extension is displayed in Figure 13. The example DL LONE PDU SET INFORMATION frame in Figure 13 sets PDU Type to ‘ 1 ’, marks appropriately EDB to ‘O’, EPDU to ‘ 1’, and removes PSN, PSSize, PSSI to gain 4 octets savings compared with the DL PDU SET INFORMATION while still conveying similar PDU Set related information elements for the case of lone PDU Sets. With reference to Figure 13, the PSSI in Figure 10 has been replaced with a Spare bit field, whereas the PSN and PSSize fields have been removed. As a result, 32-bit alignment is achieved and no padding bits are further necessary, achieving a net saving of up to 5 bytes relative to DL PDU SET INFORMATION frame.

[0111] Since the PDU Type of the DL PDU SET INFORMATION frame and DL LONE PDU SET INFORMATION frame differ, the NG-RAN may, in some embodiments, use this to separate the two encodings corresponding to the two PDU Set types and hence avoid any collisions and ambiguity related to PSSNs of PDU Sets in-flight.

[0112] The second embodiment introduces a new PDU Type frame for PDU Set Information in GTP-U header extensions, namely the DL LONE PDU SET INFORMATION Frame. The DL LONE PDU SET INFORMATION Frame comprises a non-zero PDU Type (PDU Type = 0 is the DL PDU SET INFORMATION frame) specific only for lone PDU Sets marked at the UPF. This distinguishes from the rest of the PDU Sets which can reuse the DL PDU SET INFORMATION Frame. In addition, the DL LONEPDU SET INFORMATION frame may be optimized to remove some of the fields from the DL PDU SET INFORMATION, in particular PDU Set Size, PDU Set Size Indicator, PDU Sequence Number since these are not of relevant importance to lone PDU Sets which contain a single PDU, wherein PDU Set Size is identical to PDU Size and PDU Sequence Number is always 0. Such optimizations may lead up to 5 octets of savings and may not require padding anymore for DL LONE PDU SET INFORMATION for 32-bit alignment.

[0113] Figure 14 illustrates an example of a network equipment 1400 in accordance with aspects of the present disclosure. The network equipment 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.

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

[0115] 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). In some 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 network equipment 1400 to perform various functions of the present disclosure.

[0116] 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 network equipment 1400 to perform variousfunctions 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.In some implementations, the processor 1402 and the memory 1404 coupled with the processor 1402 may be configured to cause the network equipmentl400 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 network equipment 1400 in accordance with examples as disclosed herein. The network equipment 1400 may comprise a first network node configured to support a means for receiving, from a second network node, a plurality of Protocol Data Units, PDUs, the plurality of PDUs comprising one or more marked PDUs that have been marked by the second network node with PDU set information, and one or more unmarked PDUs that have not been marked by the second network node with PDU set information; marking each of the one or more unmarked PDUs with PDU set information; and sending the plurality of PDUs to a third network node, the PDU set information of each PDU being comprised within an encapsulation protocol header extension container; wherein the encapsulation protocol header extension container comprises an indication for distinguishing whether the PDU set information originates from marking by the first network node.

[0117] The controller 1406 may manage input and output signals for the network equipment 1400. The controller 1406 may also manage peripherals not integrated into the network equipment 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.

[0118] In some implementations, the network equipment 1400 may include at least one transceiver 1408. In some other implementations, the network equipment 1400 may havemore 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.

[0119] 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 (LNA)) 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.

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

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

[0122] The processor 1500 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 1500) or other memory (e.g., random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), static RAM (SRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase change memory (PCM), and others).

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

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

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

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

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

[0128] The processor 1500 may support wireless communication in accordance with examples as disclosed herein. The processor 1500 may be configured to or operable to support a means for receiving, from a second network node, a plurality of Protocol Data Units, PDUs, the plurality of PDUs comprising one or more marked PDUs that have been marked by the second network node with PDU set information, and one or more unmarked PDUs that have not been marked by the second network node with PDU set information; marking each of the one or more unmarked PDUs with PDU set information; and sending the plurality of PDUs to a third network node, the PDU set information of each PDU being comprised within an encapsulation protocol header extension container; wherein the encapsulation protocol header extension container comprises an indication for distinguishing whether the PDU set information originates from marking by the first network node.

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

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

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

[0132] The memory 1604 may include volatile or non-volatile memory. The memory 1604 may store computer-readable, computer-executable code including instructions when executed by the processor 1602 cause the NE 1600 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 1604 or another type of memory. Computer-readable media includes both non- transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.In some implementations, the processor 1602 and the memory 1604 coupled with the processor 1602 may be configured to cause the NE 1600 to perform one or more of the functions described herein (e.g., executing, by the processor 1602, instructions stored in the memory 1604). For example, the processor 1602 may support wireless communication at the NE 1600 in accordance with examples as disclosed herein. The NE 1600 may comprise a third network node configured to support a means for receiving a plurality of PDUs from a first network node with PDU set information comprised within an encapsulation protocol header extension container, wherein the encapsulation protocol header extension container further comprises an indication identifying whether the PDU set information originates from the first network node or a second network node; and determining whether the PDU set information originates from the first network node based upon the indication.

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

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

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

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

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

[0138] At 1702, the method may include receiving, from a second network node, a plurality of Protocol Data Units, PDUs, the plurality of PDUs comprising one or more marked PDUs that have been marked by the second network node with PDU set information, and one or more unmarked PDUs that have not been marked by the second network node with PDU set information. 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 network equipment as described with reference to Figure 14.

[0139] At 1704, the method may include marking each of the one or more unmarked PDUs with PDU set information. 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 network equipment as described with reference to Figure 14.

[0140] At 1706, the method may include sending the plurality of PDUs to a third network node, the PDU set information of each PDU being comprised within an encapsulation protocol header extension container; wherein the encapsulation protocol header extension container comprises an indication for distinguishing whether the PDU set information originates from marking by the first network node. The operations of 1706 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1706 may be performed by a network equipment as described with reference to Figure 14.

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

[0142] Figure 18 illustrates a flowchart of a method in accordance with aspects of the present disclosure. The operations of the method may be implemented by a NE comprising a third network node 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.

[0143] At 1802, the method may include receiving a plurality of PDUs from a first network node with PDU set information comprised within an encapsulation protocol header extension container, wherein the encapsulation protocol header extension container further comprises an indication identifying whether the PDU set information originates from the first network node or a second network node. The operations of 1802 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1802 may be performed by a NE as described with reference to Figure 16.

[0144] At 1804, the method may include determining whether the PDU set information originates from the first network node based upon the indication. The operations of 1804 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1804 may be performed by a NE as described with reference to Figure 16.

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

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

Claims

CLAIMSWhat is claimed is:

1. A network node for wireless communication, hereinafter referred to as a first network node, the first network node comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the first network node to: receive, from a second network node, a plurality of Protocol Data Units, PDUs, the plurality of PDUs comprising one or more marked PDUs that have been marked by the second network node with PDU set information, and one or more unmarked PDUs that have not been marked by the second network node with PDU set information; mark each of the one or more unmarked PDUs with PDU set information; and send the plurality of PDUs to a third network node, the PDU set information of each PDU being comprised within an encapsulation protocol header extension container; wherein the encapsulation protocol header extension container comprises an indication for distinguishing whether the PDU set information originates from marking by the first network node.

2. The network node of claim 1, wherein the network node comprises a User Plane Function, UPF.

3. The network node of claim 1 or 2, wherein the indication is comprised as a bit field in a user plane protocol PDU set information frame.

4. The network node of claim 3, wherein the PDU set information frame comprises at least one bit field for at least one of: a PDU Type; an End of Data Burst, EDB; an End PDU of a PDU set, EPDU; a PDU Set Size Indicator, PSSI; a QoS Flow Identifier, QFI; a PDU Set Sequence Number,PSSN; a PDU Set Importance, PSI; a PDU Sequence Number, PSN, of PDUs part of the PDU Set; a PDU Set Size, PSSize; spare bits reserved for future use; and padding for 32-bit alignment.

5. The network node of claim 4, wherein the indication is appended to the PSSN field.

6. The network node of claim 5, wherein the indication and the PSSN form an aggregate bit field comprising an Extended PDU Set Sequence Number, EPSSN, the EPSSN disjointly partitioning the PDUs with PDU Set information originating from unmarked PDUs from the PDUs with PDU Set information originating from marked PDUs.

7. The network node of claim 6, wherein the indication bit field corresponds to a least significant bit of the EPSSN.

8. The network node of claim 7, wherein either: a set of odd-valued EPSSNs map to PDUs with PDU Set information originating from unmarked PDUs and a set of even-valued EPSSNs map to the PDUs with PDU Set information originating from marked PDUs; or a set of even-valued EPSSNs map to PDUs with PDU Set information originating from unmarked PDUs and a set of odd-valued EPSSNs map to PDUs with PDU Set information originating from marked PDUs.

9. The network node of claim 3, wherein the user plane protocol PDU set information frame corresponds to a downlink, DL, frame comprising a non-zero PDU Type field, the non-zero PDU Type field further comprising the indication.

10. The network node of claim 9, wherein the DL frame comprising the non-zero PDU Type field is a DL LONE PDU SET INFORMATION frame.

11. The network node of claim 9 or 10, wherein the DL frame comprising the nonzero PDU Type field further comprises at least one bit field for at least one of: a QoS Flow Identifier, QFI; an End PDU of a PDU set, EPDU; a PDU Set Sequence Number, PSSN; and a PDU Set Importance, PSI.

12. The network node of claim 11, wherein the DL frame comprising the non-zero PDU Type field does not comprise bit fields for some or all of : an End of Data Burst, EDB; a PDU Set Size Indicator, PSSI; a PDU Sequence Number, PSN, of PDUs part of the PDU Set; and a PDU Set Size, PSSize.

13. The network node of any preceding claim, wherein the encapsulation protocol is GPRS Tunneling Protocol for User Plane, GTP-U.

14. The network node of any preceding claim, wherein the second network node comprises at least one of an Application Server and a media source encoder, the media source encoder generating media content payloads of the plurality of PDUs.

15. A processor for wireless communication in a network node, comprising: at least one controller coupled with at least one memory and configured to cause the processor to: receive a plurality of Protocol Data Units, PDUs, from a second network node, the plurality of PDUs comprising one or more marked PDUs that have been marked by the second network node with PDU set information, and one or more unmarked PDUs that have not been marked by the second network node with PDU set information; mark each of the one or more unmarked PDUs with PDU set information; and send the plurality of PDUs to a third network node, the PDU set information comprised within an encapsulation protocol header extension container;wherein the encapsulation protocol header extension container comprises an indication for distinguishing whether the PDU set information originates from marking by the network node .

16. A network node for wireless communication , hereinafter referred to as a third network node, the third network node comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the third network node to: receive a plurality of PDUs from a first network node with PDU set information comprised within an encapsulation protocol header extension container, wherein the encapsulation protocol header extension container further comprises an indication identifying whether the PDU set information originates from the first network node or a second network node; and determine whether the PDU set information originates from the first network node based upon the indication.

17. A method performed by a first network node, the method comprising: receiving a plurality of Protocol Data Units, PDUs, from a second network node, the plurality of PDUs comprising one or more marked PDUs being PDUs that have been marked by the second network node with PDU set information, and one or more unmarked PDUs being PDUs that have not been marked by the second network node with PDU set information; marking each of the one or more unmarked PDUs with PDU set information; and sending the plurality of PDUs to a third network node, the PDU set information comprised within an encapsulation protocol header extension container; wherein the encapsulation protocol header extension container comprises an indication for distinguishing whether the PDU set information originates from marking by the first network node.

18. The method of claim 17, wherein the first network node comprises a User Plane Function, UPF.

19. The method of claim 17 or 18, wherein the third network node is a radio access network, RAN, node, and the second network node comprises at least one of an Application Server, AS, and a media source encoder, the media source encoder generating media content payloads of the plurality of PDUs.

Images