WIRELESS COMMUNICATION SYSTEM

Field

[0001] The subject matter disclosed herein relates generally to the field of implementing Internet Protocol version signaling in a wireless communication system. This document defines a first apparatus for wireless communication and a method in said first apparatus, and an apparatus in a wireless communication network and a method in said apparatus.

Introduction

[0002] In the context of XR media traffic, 3GPP System Architecture WG recently considered the concept of an XR multimedia session with protocol data unit (PDU) Set marking whereby one or more PDUs corresponding to an application data unit are virtually grouped and marked as a PDU Set. Usually, the PDU Set marking is performed by the real-time protocol (RTP) stack of an RTP sender (e.g., an Application Server (AS)), and the 3GPP PDU Set marking information comprises, among other fields, also of PDU Set Size information in bytes. This information may convey the size of a PDU Set in bytes including Internet Protocol (IP) header encapsulation overhead to better support lower layers (e.g., NG-RAN Layer 2) with resource allocation and scheduling strategies.

Summary

[0003] In some deployments of PDU Set marking, the PDU Set Size may become inaccurate over the course of the PDU Set transport, particularly when there is an IP version change at a network level incurred via typical Network Address Translation (NAT) and tunneling. These may be employed, for instance, across heterogeneous networks with different support for protocols IPv4 and IPv6. As such, it may well be the case that a sender supporting only IPv4 (or IPv6) calculates the PDU Set Size based on the latter, yet during transport the IP NAT translation leads the 3GPP core network to ingest at the PDU Session Anchor (PSA) user-plane function (UPF) a PDU Set encapsulated with a mismatched IP version, i.e., IPv6 (or Ipv4), respectively. This is undesirable owing to the impact on the beforementioned resource allocation and scheduling strategies. [0004] Consequently, considering such scenarios and catering for signaling in support of detecting and potentially correcting the PDU Set Size information for any IP mismatches at the UPF is necessary.

[0005] Disclosed herein are procedures for IP version signaling in a wireless communication system. Said procedures may be implemented by a first apparatus for wireless communication, and, an apparatus in a wireless communication network.

[0006] There is provided a first apparatus for wireless communication, comprising: a processor; and a memory coupled with the processor, the processor configured to cause the first apparatus to: determine an origin internet protocol (IP) version of a media session, the media session being configured with protocol data unit (PDU) set marking including PDU set size information, wherein the origin IP version corresponds to an IP version used by a second apparatus to encapsulate traffic of the second apparatus for transport, in the media session, over one or more wireless communication networks; determine a first indication, corresponding to the origin IP version, for supporting the processing of the PDU set size information during transport over the one or more wireless communication networks; and signal, to a third apparatus of the one or more wireless communication networks, the first indication.

[0007] There is further provided an apparatus in a wireless communication network, comprising: a processor; and a memory coupled with the processor, the processor configured to cause the apparatus to: receive a first configuration for processing traffic of a media session, the media session being configured with protocol data unit (PDU) set marking including PDU set size information, wherein the first configuration comprises a first indication of an origin internet protocol (IP) version used by a second apparatus to encapsulate the traffic for transport, in the media session, over the wireless communication network; receive a plurality of PDUs of a PDU set of the traffic; compare the received plurality of PDUs to the first configuration, to determine whether the first indication of the origin IP version matches an IP version of the received plurality of PDUs; process the PDU set size information that is available for the plurality of PDUs of the PDU set based on a second configuration, by correcting the PDU set size information and/or skipping the PDU set size information, if the comparison determines a mismatch between the origin IP version and the IP version of the received plurality of PDUs; route, to a radio access network, the plurality of PDUs and the processed PDU set size information. [0008] There is further provided, a method in a first apparatus, comprising: determining an origin internet protocol (IP) version of a media session, the media session being configured with protocol data unit (PDU) set marking including PDU set size information, wherein the origin IP version corresponds to an IP version used by a second apparatus to encapsulate traffic of the second apparatus for transport, in the media session, over one or more wireless communication networks; determining a first indication, corresponding to the origin IP version, for supporting the processing of the PDU set size information during transport over the one or more wireless communication networks; and signaling, to a third apparatus of the one or more wireless communication networks, the first indication.

[0009] There is further provided, a method in an apparatus, the apparatus in a wireless communication network, the method comprising: receiving a first configuration for processing traffic of a media session, the media session being configured with protocol data unit (PDU) set marking including PDU set size information, wherein the first configuration comprises a first indication of an origin internet protocol (IP) version used by a second apparatus to encapsulate the traffic for transport, in the media session, over the wireless communication network; receiving a plurality of PDUs of a PDU set of the traffic; comparing the received plurality of PDUs to the first configuration, to determine whether the first indication of the origin IP version matches an IP version of the received plurality of PDUs; processing the PDU set size information that is available for the plurality of PDUs of the PDU set based on a second configuration, by correcting the PDU set size information and/ or skipping the PDU set size information, if the comparing determines a mismatch between the origin IP version and the IP version of the received plurality of PDUs; routing, to a radio access network, the plurality of PDUs and the processed PDU set size information.

Brief description of the drawings

[0010] In order to describe the manner in which advantages and features of the disclosure can be obtained, a description of the disclosure is rendered by reference to certain apparatus and methods which are illustrated in the appended drawings. Each of these drawings depict only certain aspects of the disclosure and are not therefore to be considered to be limiting of its scope. The drawings may have been simplified for clarity and are not necessarily drawn to scale. [0011] Methods and apparatus for IP version signaling in a wireless communication system will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 depicts an embodiment of a wireless communication system for IP version signaling in a wireless communication system;

Figure 2 depicts a user equipment apparatus that may be used for implementing the methods described herein;

Figure 3 depicts further details of a network node that may be used for implementing the methods described herein;

Figure 4 depicts an overview of the RTP and RTCP stack;

Figure 5 depicts an overview of the WebRTC stack;

Figures 6a and 6b depict a packet format and header information for an RTP packet and an SRTP packet, respectively;

Figure 7 depicts RTP/SRTP header extension format and syntax;

Figure 8 depicts an overview of a core network XRM architecture handling of PDU Sets;

Figures 9a to 9d depict 5GS PDU Set-aware QoS handling framework description of PDU Set to QoS flow to DRB mappings;

Figures 10a and 10b depict one-byte and two-byte RTP Header Extension for the marking of PDU Set information, respectively;

Figure 11 depicts a CN XRM architecture and handling of PDU sets with PSSize fields and origin IP version information;

Figure 12 depicts an information flow showing the origin IP version signaling by the AF for a session to a core network;

Figure 13 depicts an embodiment of a method in a first apparatus; and Figure 14 depicts a further embodiment of a method in an apparatus, the apparatus in a wireless communication network.

Detailed description

[0012] Prior to delving further into the details of the techniques presented herein, note that, as will be appreciated by one skilled in the art, aspects of this disclosure may be embodied as a system, apparatus, method, or program product. Accordingly, arrangements described herein may be implemented in an entirely hardware form, an entirely software form (including firmware, resident software, micro-code, etc.) or a form combining software and hardware aspects.

[0013] For example, the disclosed methods and apparatus may be implemented as a hardware circuit comprising custom very-large-scale integration (“VLSI”) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed methods and apparatus may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. As another example, the disclosed methods and apparatus may include one or more physical or logical blocks of executable code which may, for instance, be organized as an object, procedure, or function.

[0014] Furthermore, the methods and apparatus may take the form of a program product embodied in one or more computer readable storage devices storing machine readable code, computer readable code, and/ or program code, referred hereafter as code. The storage devices may be tangible, non-transitory, and/ or non-transmission. The storage devices may not embody signals. In certain arrangements, the storage devices only employ signals for accessing code.

[0015] Any combination of one or more computer readable medium may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device storing the code. The storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

[0016] More specific examples (a non-exhaustive list) of the storage device would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random-access memory (“RAM”), a read-only memory (“ROM”), an erasable programmable read-only memory (“EPROM” or Flash memory), a portable compact disc read-only memory (“CD-ROM”), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store, a program for use by or in connection with an instruction execution system, apparatus, or device.

[0017] Reference throughout this specification to an example of a particular method or apparatus, or similar language, means that a particular feature, structure, or characteristic described in connection with that example is included in at least one implementation of the method and apparatus described herein. Thus, reference to features of an example of a particular method or apparatus, or similar language, may, but do not necessarily, all refer to the same example, but mean “one or more but not all examples” unless expressly specified otherwise. The terms “including”, “comprising”, “having”, and variations thereof, mean “including but not limited to”, unless expressly specified otherwise. An enumerated listing of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise. The terms “a”, “an”, and “the” also refer to “one or more”, unless expressly specified otherwise.

[0018] As used herein, a list with a conjunction of “and/ or” includes any single item in the list or a combination of items in the list. For example, a list of A, B and/ or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C. As used herein, a list using the terminology “one or more of’ includes any single item in the list or a combination of items in the list. For example, one or more of A, B and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C. As used herein, a list using the terminology “one of’ includes one, and only one, of any single item in the list. For example, “one of A, B and C” includes only A, only B or only C and excludes combinations of A, B and C. As used herein, “a member selected from the group consisting of A, B, and C” includes one and only one of A, B, or C, and excludes combinations of A, B, and C.” As used herein, “a member selected from the group consisting of A, B, and C and combinations thereof’ includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C.

[0019] Furthermore, the described features, structures, or characteristics described herein may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of the disclosure. One skilled in the relevant art will recognize, however, that the disclosed methods and apparatus may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well- known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the disclosure. [0020] Aspects of the disclosed method and apparatus are described below with reference to schematic flowchart diagrams and/or schematic block diagrams of methods, apparatuses, systems, and program products. It will be understood that each block of the schematic flowchart diagrams and/ or schematic block diagrams, and combinations of blocks in the schematic flowchart diagrams and/or schematic block diagrams, can be implemented by code. This code may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions /acts specified in the schematic flowchart diagrams and/or schematic block diagrams.

[0021] The code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the storage device produce an article of manufacture including instructions which implement the function/ act specified in the schematic flowchart diagrams and/or schematic block diagrams.

[0022] The code may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to produce a computer implemented process such that the code which executes on the computer or other programmable apparatus provides processes for implementing the functions /acts specified in the schematic flowchart diagrams and/ or schematic block diagram.

[0023] The schematic flowchart diagrams and/ or schematic block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatuses, systems, methods, and program products. In this regard, each block in the schematic flowchart diagrams and/or schematic block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions of the code for implementing the specified logical function(s). [0024] It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more blocks, or portions thereof, of the illustrated Figures.

[0025] The description of elements in each figure may refer to elements of proceeding Figures. Like numbers refer to like elements in all Figures.

[0026] Figure 1 depicts an embodiment of a wireless communication system 100 for IP Version signaling in a wireless communication system. In one embodiment, the wireless communication system 100 includes remote units 102 and network units 104. Even though a specific number of remote units 102 and network units 104 are depicted in Figure 1, one of skill in the art will recognize that any number of remote units 102 and network units 104 may be included in the wireless communication system 100. The wireless communication system may comprise a wireless communication network and at least one wireless communication device. The wireless communication device is typically a 3GPP User Equipment (UE). The wireless communication network may comprise at least one network node. The network node may be a network unit.

[0027] In one embodiment, the remote units 102 may include computing devices, such as desktop computers, laptop computers, personal digital assistants (“PDAs”), tablet computers, smart phones, smart televisions (e.g., televisions connected to the Internet), set-top boxes, game consoles, security systems (including security cameras), vehicle onboard computers, network devices (e.g., routers, switches, modems), aerial vehicles, drones, or the like. In some embodiments, the remote units 102 include wearable devices, such as smartwatches, fitness bands, optical head-mounted displays, or the like. Moreover, the remote units 102 may be referred to as subscriber units, mobiles, mobile stations, users, terminals, mobile terminals, fixed terminals, subscriber stations, UE, user terminals, a device, or by other terminology used in the art. The remote units 102 may communicate directly with one or more of the network units 104 via UL communication signals. In certain embodiments, the remote units 102 may communicate directly with other remote units 102 via sidelink communication.

[0028] The network units 104 may be distributed over a geographic region. In certain embodiments, a network unit 104 may also be referred to as an access point, an access terminal, a base, a base station, a Node-B, an eNB, a gNB, a Home Node-B, a relay node, a device, a core network, an aerial server, a radio access node, an AP, NR, a network entity, an Access and Mobility Management Function (“AMF”), a Unified Data Management Function (“UDM”), a Unified Data Repository (“UDR”), a UDM/UDR, a Policy Control Function (“PCF”), a Radio Access Network (“RAN”), a Network Slice Selection Function (“NSSF”), an operations, administration, and management (“OAM”), a session management function (“SMF”), a user plane function (“UPF”), an application function (“AF”), an authentication server function (“AUSF”), security anchor functionality (“SEAF”), trusted non-3GPP gateway function (“TNGF”), an application function, a service enabler architecture layer (“SEAL”) function, a vertical application enabler server, an edge enabler server, an edge configuration server, a mobile edge computing platform function, a mobile edge computing application, an application data analytics enabler server, a SEAL data delivery server, a middleware entity, a network slice capability management server, or by any other terminology used in the art. The network units 104 are generally part of a radio access network that includes one or more controllers communicably coupled to one or more corresponding network units 104. The radio access network is generally communicably coupled to one or more core networks, which may be coupled to other networks, like the Internet and public switched telephone networks, among other networks. These and other elements of radio access and core networks are not illustrated but are well known generally by those having ordinary skill in the art.

[0029] In one implementation, the wireless communication system 100 is compliant with New Radio (NR) protocols standardized in 3GPP, wherein the network unit 104 transmits using an Orthogonal Frequency Division Multiplexing (“OFDM”) modulation scheme on the downlink (DL) and the remote units 102 transmit on the uplink (UL) using a Single Carrier Frequency Division Multiple Access (“SC-FDMA”) scheme or an OFDM scheme. More generally, however, the wireless communication system 100 may implement some other open or proprietary communication protocol, for example, WiMAX, IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA2000, Bluetooth®, ZigBee, Sigfox, LoraWAN among other protocols. The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol.

[0030] The network units 104 may serve a number of remote units 102 within a serving area, for example, a cell or a cell sector via a wireless communication link. The network units 104 transmit DL communication signals to serve the remote units 102 in the time, frequency, and/ or spatial domain.

[0031] Figure 2 depicts a user equipment apparatus 200 that may be used for implementing the methods described herein. The user equipment apparatus 200 is used to implement one or more of the solutions described herein. The user equipment apparatus 200 is in accordance with one or more of the user equipment apparatuses described in embodiments herein. In particular, the user equipment apparatus 200 may comprise a first apparatus for wireless communication. The user equipment apparatus 200 may comprise UE 835 in Figure 8, the UE 1135 in Figure 11, the UE 1220 in Figure 12. The user equipment apparatus 200 includes a processor 205, a memory 210, an input device 215, an output device 220, and a transceiver 225.

[0032] The input device 215 and the output device 220 may be combined into a single device, such as a touchscreen. In some implementations, the user equipment apparatus 200 does not include any input device 215 and/ or output device 220. The user equipment apparatus 200 may include one or more of: the processor 205, the memory 210, and the transceiver 225, and may not include the input device 215 and/ or the output device 220.

[0033] As depicted, the transceiver 225 includes at least one transmitter 230 and at least one receiver 235. The transceiver 225 may communicate with one or more cells (or wireless coverage areas) supported by one or more base units. The transceiver 225 may be operable on unlicensed spectrum. Moreover, the transceiver 225 may include multiple UE panels supporting one or more beams. Additionally, the transceiver 225 may support at least one network interface 240 and/ or application interface 245. The application interface(s) 245 may support one or more APIs. The network interface(s) 240 may support 3GPP reference points, such as Uu, Nl, PC5, etc. Other network interfaces 240 may be supported, as understood by one of ordinary skill in the art.

[0034] The processor 205 may include any known controller capable of executing computer-readable instructions and/ or capable of performing logical operations. For example, the processor 205 may be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field programmable gate array (“FPGA”), or similar programmable controller. The processor 205 may execute instructions stored in the memory 210 to perform the methods and routines described herein. The processor 205 is communicatively coupled to the memory 210, the input device 215, the output device 220, and the transceiver 225. [0035] The processor 205 may control the user equipment apparatus 200 to implement the user equipment apparatus behaviors described herein. The processor 205 may include an application processor (also known as “main processor”) which manages application-domain and operating system (“OS”) functions and a baseband processor (also known as “baseband radio processor”) which manages radio functions. [0036] The memory 210 may be a computer readable storage medium. The memory 210 may include volatile computer storage media. For example, the memory 210 may include a RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and/ or static RAM (“SRAM”). The memory 210 may include non-volatile computer storage media. For example, the memory 210 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. The memory 210 may include both volatile and non-volatile computer storage media.

[0037] The memory 210 may store data related to implement a traffic category field as described herein. The memory 210 may also store program code and related data, such as an operating system or other controller algorithms operating on the apparatus 200. [0038] The input device 215 may include any known computer input device including a touch panel, a button, a keyboard, a stylus, a microphone, or the like. The input device 215 may be integrated with the output device 220, for example, as a touchscreen or similar touch-sensitive display. The input device 215 may include a touchscreen such that text may be input using a virtual keyboard displayed on the touchscreen and/ or by handwriting on the touchscreen. The input device 215 may include two or more different devices, such as a keyboard and a touch panel.

[0039] The output device 220 may be designed to output visual, audible, and/ or haptic signals. The output device 220 may include an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 220 may include, but is not limited to, a Liquid Crystal Display (“LCD”), a Light- Emitting Diode (“LED”) display, an Organic LED (“OLED”) display, a projector, or similar display device capable of outputting images, text, or the like to a user. As another, non-limiting, example, the output device 220 may include a wearable display separate from, but communicatively coupled to, the rest of the user equipment apparatus 200, such as a smart watch, smart glasses, a heads-up display, or the like. Further, the output device 220 may be a component of a smart phone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.

[0040] The output device 220 may include one or more speakers for producing sound. For example, the output device 220 may produce an audible alert or notification (e.g., a beep or chime). The output device 220 may include one or more haptic devices for producing vibrations, motion, or other haptic feedback. All, or portions, of the output device 220 may be integrated with the input device 215. For example, the input device 215 and output device 220 may form a touchscreen or similar touch-sensitive display. The output device 220 may be located near the input device 215.

[0041] The transceiver 225 communicates with one or more network functions of a mobile communication network via one or more access networks. The transceiver 225 operates under the control of the processor 205 to transmit messages, data, and other signals and also to receive messages, data, and other signals. For example, the processor 205 may selectively activate the transceiver 225 (or portions thereof) at particular times in order to send and receive messages.

[0042] The transceiver 225 includes at least one transmitter 230 and at least one receiver 235. The one or more transmitters 230 may be used to provide uplink communication signals to a base unit of a wireless communication network. Similarly, the one or more receivers 235 may be used to receive downlink communication signals from the base unit. Although only one transmitter 230 and one receiver 235 are illustrated, the user equipment apparatus 200 may have any suitable number of transmitters 230 and receivers 235. Further, the trans mi tter(s) 230 and the receiver(s) 235 may be any suitable type of transmitters and receivers. The transceiver 225 may include a first transmitter/receiver pair used to communicate with a mobile communication network over licensed radio spectrum and a second transmitter/receiver pair used to communicate with a mobile communication network over unlicensed radio spectrum.

[0043] The first transmitter/ receiver pair may be used to communicate with a mobile communication network over licensed radio spectrum and the second transmitter/ receiver pair used to communicate with a mobile communication network over unlicensed radio spectrum may be combined into a single transceiver unit, for example a single chip performing functions for use with both licensed and unlicensed radio spectrum. The first transmitter/receiver pair and the second transmitter/receiver pair may share one or more hardware components. For example, certain transceivers 225, transmitters 230, and receivers 235 may be implemented as physically separate components that access a shared hardware resource and/ or software resource, such as for example, the network interface 240.

[0044] One or more transmitters 230 and/ or one or more receivers 235 may be implemented and/ or integrated into a single hardware component, such as a multitransceiver chip, a system-on-a-chip, an Application-Specific Integrated Circuit (“ASIC”), or other type of hardware component. One or more transmitters 230 and/ or one or more receivers 235 may be implemented and/ or integrated into a multi-chip module. Other components such as the network interface 240 or other hardware components/ circuits may be integrated with any number of transmitters 230 and/ or receivers 235 into a single chip. The transmitters 230 and receivers 235 may be logically configured as a transceiver 225 that uses one more common control signals or as modular transmitters 230 and receivers 235 implemented in the same hardware chip or in a multi-chip module.

[0045] Figure 3 depicts further details of the network node 300 that may be used for implementing the methods described herein. The network node 300 may be one implementation of an entity in the wireless communication network, e.g. in one or more of the wireless communication networks described herein. The network node 300 may comprise a first apparatus for wireless communication, or an apparatus in a wireless communication network. For instance the network node 300 may comprise the nodes 810, 815, 820, 825, 830, 835, 840, 845 from Figure 8. The network node 300 may comprise the nodes 1110, 1115, 1120, 1125, 1130, 1135, 1140, 1145 from Figure 11. The network node 300 may comprise the nodes 1220, 1230, 1240, 1250, 1260, 1270, 1280 from Figure 12. The network node 300 includes a processor 305, a memory 310, an input device 315, an output device 320, and a transceiver 325.

[0046] The input device 315 and the output device 320 may be combined into a single device, such as a touchscreen. In some implementations, the network node 300 does not include any input device 315 and/ or output device 320. The network node 300 may include one or more of: the processor 305, the memory 310, and the transceiver 325, and may not include the input device 315 and/ or the output device 320.

[0047] As depicted, the transceiver 325 includes at least one transmitter 330 and at least one receiver 335. Here, the transceiver 325 communicates with one or more remote units 200. Additionally, the transceiver 325 may support at least one network interface 340 and/ or application interface 345. The application interface(s) 345 may support one or more APIs. The network interface(s) 340 may support 3GPP reference points, such as Uu, Nl, N2 and N3. Other network interfaces 340 may be supported, as understood by one of ordinary skill in the art.

[0048] The processor 305 may include any known controller capable of executing computer-readable instructions and/ or capable of performing logical operations. For example, the processor 305 may be a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or similar programmable controller. The processor 305 may execute instructions stored in the memory 310 to perform the methods and routines described herein. The processor 305 is communicatively coupled to the memory 310, the input device 315, the output device 320, and the transceiver 325.

[0049] The memory 310 may be a computer readable storage medium. The memory 310 may include volatile computer storage media. For example, the memory 310 may include a RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and/ or static RAM (“SRAM”). The memory 310 may include non-volatile computer storage media. For example, the memory 310 may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. The memory 310 may include both volatile and non-volatile computer storage media.

[0050] The memory 310 may store data related to establishing a multipath unicast link and/ or mobile operation. For example, the memory 310 may store parameters, configurations, resource assignments, policies, and the like, as described herein. The memory 310 may also store program code and related data, such as an operating system or other controller algorithms operating on the network node 300.

[0051] The input device 315 may include any known computer input device including a touch panel, a button, a keyboard, a stylus, a microphone, or the like. The input device 315 may be integrated with the output device 320, for example, as a touchscreen or similar touch-sensitive display. The input device 315 may include a touchscreen such that text may be input using a virtual keyboard displayed on the touchscreen and/ or by handwriting on the touchscreen. The input device 315 may include two or more different devices, such as a keyboard and a touch panel.

[0052] The output device 320 may be designed to output visual, audible, and/ or haptic signals. The output device 320 may include an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 320 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or similar display device capable of outputting images, text, or the like to a user. As another, non-limiting, example, the output device 320 may include a wearable display separate from, but communicatively coupled to, the rest of the network node 300, such as a smart watch, smart glasses, a heads-up display, or the like. Further, the output device 320 may be a component of a smart phone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.

[0053] The output device 320 may include one or more speakers for producing sound. For example, the output device 320 may produce an audible alert or notification (e.g., a beep or chime). The output device 320 may include one or more haptic devices for producing vibrations, motion, or other haptic feedback. All, or portions, of the output device 320 may be integrated with the input device 315. For example, the input device 315 and output device 320 may form a touchscreen or similar touch-sensitive display. The output device 320 may be located near the input device 315.

[0054] The transceiver 325 includes at least one transmitter 330 and at least one receiver 335. The one or more transmitters 330 may be used to communicate with the UE, as described herein. Similarly, the one or more receivers 335 may be used to communicate with network functions in the PLMN and/ or RAN, as described herein. Although only one transmitter 330 and one receiver 335 are illustrated, the network node 300 may have any suitable number of transmitters 330 and receivers 335. Further, the transmitter(s) 330 and the receiver(s) 335 may be any suitable type of transmitters and receivers.

[0055] In the context of XR media traffic, 3GPP System Architecture WG recently considered the concept of an XR multimedia session with protocol data unit (PDU) Set marking whereby one or more PDUs corresponding to an application data unit are virtually grouped and marked as a PDU Set. Usually, the PDU Set marking is performed by the real-time protocol (RTP) stack of an RTP sender (e.g., an Application Server (AS)), and the 3GPP PDU Set marking information comprises, among other fields, also of PDU Set Size information in bytes. This information may convey the size of a PDU Set in bytes including Internet Protocol (IP) header encapsulation overhead to better support lower layers (e.g., NG-RAN Layer 2) with resource allocation and scheduling strategies.

[0056] Nevertheless, in some deployments, the PDU Set Size may become inaccurate over the course of the PDU Set transport, particularly when there is an IP version change at a network level incurred via typical Network Address Translation (NAT) and tunneling. These may be employed, for instance, across heterogeneous networks with different support for protocols IPv4 and IPv6. As such, it may well be the case that a sender supporting only IPv4 (or IPv6) calculates the PDU Set Size based on the latter, yet during transport the IP NAT translation leads the 3GPP core network to ingest at the PDU Session Anchor (PSA) user-plane function (UPF) a PDU Set encapsulated with a mismatched IP version, i.e., IPv6 (or Ipv4), respectively.

[0057] Consequently, considering such scenarios and catering for signaling in support of detecting and potentially correcting the PDU Set Size information for any IP mismatches at the UPF is necessary. [0058] According to the Third Generation Partnership Project (3GPP) Technical Report TR 26.928 (vl 7.0.0 — April 2022) titled, “Extended Reality (X ) in 5G”, XR is an umbrella term for different types of realities.

[0059] Virtual Reality (VR), for example, is a rendered version of a delivered visual and audio scene. The rendering is in this case 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 necessary 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. [0060] Augmented reality (AR), for example, 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.

[0061] Mixed reality (MR), for example, 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.

[0062] 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. A key aspect of XR is the extension of human experiences especially relating to the senses of existence (represented by VR) and the acquisition of cognition (represented by AR).

[0063] In 3GPP Release 17, SA4 analyzed the XR traffic model, as described in 3GPP Technical Report TR 26.926 (vl.3.0 — Jan 2023) titled “Traffic Models and Quality Evaluation Methods for Media and XR Services in 5G Systems”, 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. These are described at 3GPP Technical Specification TS 23.501 (vl8.1.0 — April 2023) titled “System architecture for the 5G System (5GS)” and in particular Table 5.7.4-1. The latter are applicable to XR video streams and control metadata necessary to provide immersive and interactive XR experiences.

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

[0065] 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 Real-time Transport Protocol (RTP, as defined in IETF standard RFC 3550 — RTP: A Transport Protocol for Real-Time Applications), its securely provisioned Secure Real-time Transport Protocol (SRTP, as defined in IETF standard RFC 3711 — The Secure Real-time Transport Protocol), and its web-targeted stack Web Real-Time Communications WebRTC (defined byw3.org in WebRTC 1.0: Real-Time Communication Between Browsers), respectively.

[0066] 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 Control Protocol (RTCP), to provide end-to-end features such as jitter compensation, packet loss and out-of-order delivery detection, synchronization, and source streams multiplexing.

[0067] Figure 4 provides an overview of the RTP and RTCP stack. An IP layer 405 carries signaling from the data plane 410 and form the control plane 450. The data plane 410 stack comprises functions for a User Datagram Protocol (UDP) 412, RTP 416, RTCP 414, Media codecs 420 and quality control 422. The control plane 450 stack comprises functions for UDP 452, Transmission Control Protocol (TCP) 454, Session Initiation Protocol (SIP) 462 and Session Description Protocol (SDP) 464.

[0068] SRTP is a secured version of RTP, and is defined by the IETF in RFC 3711 “The Secure Real-time Transport Protocol (SRTP)”. SRTP provides 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 to its RTCP counterpart. 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 over the right-hand side of Figure 4. 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.

[0069] Figure 5 illustrates an overview of the WebRTC stack. As illustrated, an IP layer 505 carries signaling from the data plane 510 and the control plane 550. The data plane stack 510 comprises functions for User Datagram Protocol (UDP) 512, Interactive Connectivity Establishment (ICE) 524, Datagram Transport Layer Security (DTLS) 526, SRTP 517, SRTCP 515, media codecs 520, Quality Control 522 and Stream Control Transmission Protocol (SCTP) 528. ICE 524 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 528 is mainly dedicated as an application data channel and may be non-time critical. The SRTP based stack 517 and elements of control, i.e., SRTCP 515, encoding, i.e., media codecs, and Quality of Service (QoS), i.e., Quality Control, are dedicated to time-critical transport. The control plane 550 stack comprises functions for Transmission Control Protocol (TCP) 554, Transport Layer Security (TLS) 556, Hypertext Transfer Protocol (HTTP) 558, WebSocket 566, Session Initiation Protocol (SIP) 562, Session Description Protocol (SDP) 564, Server-sent Events (SSE) 568 and Extensible Messaging and Presence Protocol (XMPP) 570.

[0070] Figure 6a illustrates a packet format and header information for an RTP packet 630 and Figure 6b illustrates a packet format and header information for an SRTP packet 660. The individual fixed header information and complete header information (including header extensions) is briefly summarized for the RTP / SRTP packets as follows.

[0071] Fixed Header Info comprises “V” 632, 662, “P” 633, 663, “X” 634, 664, “CC” 636, 666, “M” 638, 668, “PT” 640, 670, “Sequence number” 642, 672, “Timestamp” 644, 674, “Synchronization Source (SSRC) identifier” 646, 676, and “Contributing Source (CSRC) identifier” 648, 678.

[0072] “V” 632, 662 is 2 bits indicating the protocol version used.

[0073] “P” 633, 663 is a 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.

[0074] “X” 634, 664 is a 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., the frame marking RTP header extension for video data (as defined in IETF RFC 3711 — The Secure Real-time Transport Protocol (SRTP)), or generic RTP header extensions such as the RTP/SRTP extended protocol (as defined byw3.org in WebRTC 1.0: Real-Time Communication Between Browsers)).

[0075] “CC” 636, 666 is a 4 bit field indicating number of contributing media sources (CSRC) that follow the fixed header.

[0076] “M” 638, 668 is 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.).

[0077] “PT” 640, 670 is 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.)

[0078] “Sequence number” 642, 672 is 16 bits indicating the sequence number which increments by one with each RTP data packet sent over a session.

[0079] “Timestamp” 644, 674 is 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.

[0080] “Synchronization Source (SSRC) identifier” 646, 676 is a 32 bit field indicating a random identifier for the source of a stream of RTP packets forming a part of the same timing and sequence number space, such that a receiver may group packets based on synchronization source for playback.

[0081] “Contributing Source (CSRC) identifier” 648, 678 is a 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. [0082] Complete Header Information (incl. header extensions) comprises “RTP header extension” 648, 678.

[0083] “RTP header extension” 648, 678 is 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; and

• A 32-bit aligned header extension raw data field formatted according to some RTP header extension identifier specified format.

[0084] Figure 7 illustrates RTP/SRTP header extension format and syntax 700. The RTP header extension format and syntax are like the ones of SRTP. A sketch of these is thus commonly provided as shown in Figure 7. In addition, in both RTP and SRTP only one RTP extension header may be appended to the fixed header information, as defined in IETF RFC 3550 - RTP: A Transport Protocol for Real-Time Applications. 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, as per RFC 8285: A General Mechanism for RTP Header Extensions (rfc-editor.org).

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

[0086] The study of XR Media (XRM) at the CN level in Release 18 of the 3GPP technical standards introduced the concept of a PDU Set to handle QoS requirements of XRM applications and streams with a better granularity beyond QoS flow possibilities.

As such, according to 3GPP Technical Report TR 23.700-60 (v0.0.3), 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.

[0087] In addition, the PDU Set is associated with QoS requirements in terms of delay budget and error rate, which may be defined as PDU Set Delay Budget (PSDB), and/ or as a PDU Set Error Rate (PSER) as defined in 3GPP Technical Report TR 23.700-60 (v0.0.3 — May 2022) titled “Study on XR (Extended Reality) and media services” and 3GPP Technical Specification TS 23.501 (vl8.1.0 — April 2023) titled “System architecture for the 5G System (5GS)”. The 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. The 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. RFC 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.

PDCP in RAN of a 3GPP access). Whereas the PSER may be used to determine an upper bound for a rate of non-congestion-related packet losses.

[0088] Figure 8 illustrates an overview of a core network (CN) XRM architecture handling of PDU Sets. Figure 8 shows a system 800 comprising an Extended Reality Media Application Function (XRM AF) 810, a Policy and Control Function (PCF) 815, a Session Management Function (SMF) 820, an Access and Mobility Function (AMF) 825, a Radio Access Network (RAN) 830, a User Equipment (UE) 835, a User Plane Function (UPF) 840, and an Extended Reality Application 845. The UE 835 may comprise a remote unit 102, a user equipment apparatus 200 as described herein. The UPF 840 may comprise a network unit 104, a network node 300 as described herein. The operation of system 800 will now be described in the example of downlink traffic, a similar process may operate for uplink traffic.

[0089] At 880, the XRM AF 810 determines PDU-set requirements.

[0090] At 881, the XRM Application Function 810 provides QoS requirements for packets of a PDU Set to the PCF 815 and information to identify the application (i.e. 5- tuple or application id). The QoS requirements may comprise PSDB and PSER. The XRM AF 810 may also include a default importance parameter for a PDU Set and information (e.g. a protocol description) for the core network to identify packets belonging to a PDU Set. [0091] At 882, the PCF 815 derives policy charging and control (PCC) rules and QoS rules for the XR application based on the AF specific QoS requirements for the PDU Set and configures the SMF 820. The QoS rules may use a 5G QoS identifier (5QI) for XR media traffic. The PCF 815 sends the QoS rules to the SMF 820. The PCF 815 may include in the communication to the SMF 820 PCC rules per importance of a PDU Set. The PCC rules may be derived according to information received from the XRM AF 810 or based on an operator configuration.

[0092] At 883, the SMF 820 establishes a QoS flow according to the QoS rules by the PCF 815 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 820 also provides the QoS profile containing PDU Set QoS requirements to the RAN 830 via the AMF 825. The AMF 825 may provide the QoS profile containing PDU Set QoS requirements to the RAN 830 in an N2 SM container. Further, the AMF 825 may provide the QoS rules to the UE 835 in an N1 SM container.

[0093] At 884, the UPF 840 inspects the packets and determines packets belonging to a PDU Set. The packet inspection may comprise inspecting the RTP packets. When the UPF 840 detects packets of a PDU Set the UPF 840 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 in bytes. The UPF 840 may also determine the importance of the PDU Set either based on UPF 840 implementation means, information provided by the XRM AF 810 or information provided as metadata (e.g., via RTP header extensions for PDU Set marking) from an XRM application server. Based on the importance of the PDU Set the UPF 840 may route the traffic to a corresponding QoS flow 1 (according to the rules received from the SMF 820) or include the importance of the PDU Set within a GTP-U header. QoS flow 1 may comprise GTP-U headers, and these may include PDU Set information.

[0094] At 885, the RAN 830 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 820. In one implementation the RAN 830 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. RAN 830 may receive QFIs, QoS profile of QoS flow from SMF 820 (via AMF 825) during PDU session establishment/ modification which includes PDSB and PSER. RAN 830 inspects GTP-U headers and ensures all packets of the same PDU Set are handled according to the QoS profile. This may include packets of PDU-set in a radio bearer carrying QoS flow 1. This may also include sending packets not belonging to the PDU-set in a different radio bearer carrying QoS flow 2.

[0095] The above example relates to downlink (DL) traffic. Reciprocal processing is applicable to uplink (UL) traffic wherein the role of UPF 840 packet inspection is taken by the UE 835 which is expected to inspect uplink packets, determine packets belonging to a PDU Set, and signal accordingly the PDU Set to the RAN 830 for scheduling and resource allocation corresponding to an associated 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.

[0096] Figures 9a to 9d illustrate 5GS PDU Set-aware QoS handling framework description of PDU Set to QoS flow to DRB mappings. Depending on the QoS flow mappings and RAN procedures, several alternative PDU Set to QoS flow to DRB mappings are possible given two distinct PDU Sets with different PDU Set attributes, such as PDU Set importance. Figure 9 illustrates some options where two PDU Sets 910 of different importance and characteristics are mapped to QoS flows 920 and respectively to Data Radio Bearers (DRBs) 930. Consider in this example PDU Set 1 to be of high importance with strict QoS requirements (i.e., PSDB, PSER etc.) and PDU Set 2 to be of low importance with potentially lower QoS requirements (i.e., PSDB, PSER etc.) than PDU Set 1. As illustrated in Figure 9, the mapping of PDU Set 910 to QoS flow 920 to DRB 930 can take the following instantiations depending on QoS flow policies and Layer 2 RAN procedures:

[0097] Figure 9a illustrates 1-to-l-to-l mapping: whereby the separation of QoS flows 920 and DRBs 930 is complete between high and low importance PDU Sets 910 optimizing finely the radio and network resources on a per PDU Set basis.

[0098] Figure 9b illustrates M-to-M-to-1 mapping: whereby the separation between high and low importance PDU Sets 910 is performed only at QoS flow level, whereas the same DRB 930 is used for the over-the-air transmission of both PDU Sets 910, which may lead to overprovisioning of radio resources for low importance PDU Sets 910 yet require a lower overhead of RAN complexity and management.

[0099] Figure 9c illustrates M-to-l-to-1 mapping: whereby there is no separation between the QoS flows 920 and DRBs 930 of different importance PDU Sets 910 and the higher importance PDU Set QoS requirements are prioritized in handling the QoS management across both CN and RAN; this may lead to overprovisioning of resources for low importance PDU Sets 910 in both CN and RAN implementations but requires lower overhead and control within the 5GS QoS framework.

[0100] Figure 9d illustrates M-to-l-to-M mapping: whereby there is no separation across the QoS flows 920 between PDU Set importance levels, yet distinct DRBs 930 are used to cater for the individual requirements of the distinct importance levels; this compromises the QoS flow management complexity and uses PDU Set information to filter the PDU Sets 910 on different DRBs 930 in order to better match the QoS requirements at RAN level and optimize resource allocation according to individual PDU Set needs.

[0101] In addition, RAN Layer 2 procedures may use the PDU Set importance attribute and associated information for prioritization of PDU Sets. In one instance the prioritization strategy may take the form of dropping PDU Sets of lower importance in the presence of RAN congestion. In other instances, the RAN may use alternative prioritization strategies in resource allocation as required per different gNB implementations, whereby the PDU Set importance information is leveraged to determine the resource allocation strategy for PDU Sets of varying importance.

[0102] The determination of PDU Sets is a prerequisite to control the PDU Set flow through the 5GS and implicitly to control the QoS flow to DRB mapping within the QoS 5GS framework. Therefore, to support PDU Set based QoS handling, the PDU session anchor (PSA) UPF identifies PDUs that belong to PDU Sets and determines the PDU Set Information which it sends to the NG-RAN in the GTP-U header. The PDU Set information is used by the NG-RAN for PDU Set based QoS handling as described above.

[0103] The PDU Set Information comprises some combination of:

• PDU Set Sequence Number (PSSN).

• Indication of End PDU (E) of the PDU Set

• PDU Sequence Number (PSN) within a PDU Set

• PDU Set Size (PSSize) in bytes.

• PDU Set Importance (PSI), which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS Flow.

• End of Data Burst (EDB) information, marking the end of a data burst, whereby a data burst is a set of multiple PDUs generated and sent by the application such that there is an idle (i.e., silent, pause, or alternatively non-active) period between two data bursts. Consequently, a Data Burst may be composed of one or multiple PDU Sets.

[0104] The RAN lower layers can further make use of the PDU Set Importance marked within a QoS Flow for PDU Set level packet discarding in presence of congestion over the radio air interface. Furthermore, the interrelation between PSI across multiple QoS flows may be considered.

[0105] The SMF instructs the PSA UPF to perform PDU Set marking and may provide the PSA UPF with the Protocol Description served over a 5 tuple (i.e., a tuple formed of source IP address, destination IP address, source port, destination port, and protocol number) or an application ID (i.e., an identifier of one or more AF sessions associated with an application) indicating the header, extension header (e.g., RTP/SRTP) and payload type (e.g. H.264) used by the service data flow. The Protocol Description may be received in the PCC rule, based on information provided by the AF or by PCF local policies.

[0106] Consequently, the PSA UPF can identify the PDU Set information by using the Protocol Description and the received RTP/SRTP headers, as indicated by an application server (AS), (as for example described in United States provisional patent application 63/428,026, filed 25 November 2022 [Applicants ref: SMM920220198-US- PSP] , incorporated herein by reference) over the user plane based on RTP header extensions for PDU Set information. Alternatively, the PSA UPF can identify the PDU Set information by using UPF implementation specific means, (as for example described in PCT application PCT/EP2022/077327 filed on 30 September 2022 [Applicants ref: SMM920220109-GR-NP], incorporated herein by reference) whereby at least the RTP/SRTP timestamp, synchronization source identifier and M-bit end of frame marker are utilized to determine the boundaries of a PDU Set, and the PDU Set size is utilized to determine the PDU Set importance based on the available application traffic and codec configuration information. As a result, for each DL PDU received on N6 for which PDU Set based QoS handling is indicated from the SMF, the PSA UPF applies the rules for PDU Set identification and provides PDU Set information which is available to the RAN in the GTP-U header.

[0107] In some implementations, a 5GS comprises the PDU Set marking by the AS and its associated information, as previously detailed, in RTP header extensions according to the IETF RFC 8285. This can be either in one-byte or two-byte formats as displayed for example in Figures 10a and Figure 10b according to RTF header extension with urn:3gpp:pdu-set-marking:rel-18.

[0108] Figure 10a illustrates an example of a one-byte RTF Header Extension 1000 for the marking of PDU Set information. Figure 10b illustrates an example of a two-byte RTP Header Extension 1050 for the marking of PDU Set information.

[0109] The semantics associated with the PDU Set information fields of the RTP header extension syntaxes outlined in Figure 10a and Figure 10b are as follows.

[0110] “E” 1032 is a 1 bit representation of a Boolean flag that shall be set to 1 for the last PDU of the PDU Set and set to 0 for all other PDUs of the PDU Set.

[0111] “EDB” 1034 is a 3 bit representation of the end of a Data Burst indication. The 3 bits may encode for example the End of Data Burst indication as per the encoding and guidelines provided in the 3GPP Technical Specification TS 26.522 titled “5G Real-time Media Transport Protocol Configurations”.

[0112] “PSI” 1036 is a 4 bit representation indicating the importance of a PDU Set compared to other PDU Sets within the same RTP stream, or alternatively, session. Lower values shall indicate a higher importance PDU Set, with the highest importance PDU Set indicated by 0 and the lowest importance PDU Set indicated by 15. This field is applicable for various audio/ video codecs supported by a 5GS (e.g., H.264, H.265, HE- AAC etc.).

[0113] “PSSN” 1040 comprises a 10 bit representation encoding the sequence number of the PDU Set to which the current PDU belongs acting as a 10-bit numerical identifier for the PDU Set. PSSN may take a value between 0 and 1023, and even though the value may wrap around 1023 in some examples, a receiver (e.g., UPF) may uniquely distinguish between any PDU Sets using a combination of the RTP packet sequence number and the PSSN.

[0114] “PSN” 1042 is a 6 bit representation of 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. A receiver (e.g., UPF, or alternatively, in some examples a gNB) may use the RTP packet sequence number together with the PSN to distinguish between PDUs within a PDU Set that contains more than 64 PDUs.

[0115] “PSSize” 1044 is a 24 bit representation indicating 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 AS may indicate whether it will be able to provide the size of the PDU Set for an RTP stream, or alternatively, an RTP session. If in some embodiments it is not enabled, the field will not be present. However, if in some embodiments is enabled, but the AS is not able to determine the PDU Size for a particular PDU Set, the AS will set the value to 0 in all PDUs of that PDU Set. The PSSize indicates in some implementations the size of a PDU Set including RTP/UDP/IP header encapsulation overhead of its corresponding PDUs. Alternatively, the PSSize indicates the sum of RTP payload sizes of all PDUs present in a PDU Set. The PSSize is expressed in bytes. As this field is optionally appended to the RTP header extensions, its presence is negotiated and signaled via SDP offer/ answer procedure by means of the “pdu-set-size” extension attribute, as per example: a=extmap : 1 s endonly urn : 3gpp : pdu-s et-marking : rel-18 pdu- set- si ze

[0116] As described herein, the PDU Set Size is determined by an AS RTP sender and to benefit a wireless communications network the PSSize field must indicate the number of bytes in the PDU Set that need to be transported to the receiver. This indication needs to be as accurate as possible to benefit the lower layers, e.g., Layer 2 and Layer 1 of an NG-RAN implementation, in resource allocation and scheduling strategies.

[0117] As detailed in United States provisional patent application 63/428,026, filed 25 November 2022 [Applicants ref: SMM920220198-US-PSP], the AS RTP sender determines the RTP payload size available in the sender buffer and passes it on to the RTP protocol stack implemented in the user space of an Operation System. The AS further enables the PDU Set marking and informs the RTP stack of it requesting addition of PDU Set RTP HE to the RTP packets corresponding to the RTP payload. In some sender configurations one RTP payload (i.e., an application data unit) is mapped 1:1 to a PDU Set, whereas in other configurations one or more RTP payloads are mapped to a PDU Set. When further enabled with the PSSize indication option, the RTP stack determines the PSSize based in part on the RTP payload size. In doing so, the RTP stack performs RTP packet fragmentation based on the link MTU knowledge. The MTU may be statically configured, e.g., to 1280 MTU for RTP payloads as in WebRTC, or alternatively, dynamically determined based on ICMP and MTU path discovery procedures.

[0118] Once the RTP fragmentation is determined, the RTP stack performs packetization and releases the RTP packets corresponding to the RTP payload, i.e., the PDU Set, to the corresponding UDP socket as agreed upon session establishment via the SDP offer/answer procedure. In this flow, the RTP stack is controlling the UDP socket lifecycle and its configuration, being aware of the socket options and underlying IP options and version. As such, an RTP stack can be aware of the UDP/IP header overhead per packet. According to United States provisional patent application 63/428,026, filed 25 November 2022 [Applicants ref: SMM920220198-US-PSP], the RTP stack uses this information in part with the RTP payload size during RTP packet fragmentation and RTP packetization to determine the PSSize field in bytes corresponding to both the size of the RTP payload and the overhead of the UDP/IP headers of the corresponding RTP packets forming the PDU Set. In one example, if UDP/IPv4 is used to transport the RTP packets of the AS sender the RTP stack can determine an overhead of 20 Bytes (IPv4) + 8 Bytes (UDP) = 28 Bytes per RTP packet. In another example, if UDP/IPv6 is used to transport the RTP packets the RTP stack can determine an overhead of 40 Bytes (IPv6) + 8 Bytes (UDP) = 48 Bytes per RTP packet. As a result, the RTP stack can determine the PSSize field in bytes corresponding to the PDU Set Size including the UDP/IP header encapsulation overheads and mark this optionally in band for each PDU Set as part of the PDU Set RTP HE.

[0119] One potential problem that may arise however is related to the mismatch potential of IP versions between sender and receiver given Internet Service Provider (ISP) network configuration, or alternatively, domain networks configurations. In context of 4G/5G and beyond, the core network supports dual stack, including IPv4 and IPv6. As such, an AS sender in the trusted domain of an operator should not experience any IP mismatch being completely under the control of an interoperable ISP-controlled core network. However, when the AS sender is outside of the trusted domain of an operator there are scenarios when the Data Network (DN) domain may not support dual stack IP connectivity. NAT may be configured in such scenarios to configure end-to-end connectivity.

[0120] In an example an AS may be placed in a DN supporting only IPv4. The AS resolves a target UE IPv4 address which is translated by NAT to a target UE IPv6 address. The NAT may be placed within a separate Content Distribution Network (CDN) configured to prefer IPv6 over IPv4 (e.g., a CDN providing ICE candidates for WebRTC services) or within an operators Core Network as part of the N6 LAN of the PSA UPF. The UPF will see therefore as a result an IPv6 flow corresponding to the AS sender traffic originating as an IPv4 flow. Tunneling may be used across the links to support IPv4 to IPv6 conversion and may be out of the control of the AS sender, or alternatively, both the AS sender and the UPF. In such, (potentially mismanaged) configurations of the networks, the determined PSSize by the AS for IPv4 encapsulation may mismatch the IPv6 configuration ingress by the PSA UPF. In another example, a reciprocal case can be considered whereby the AS resides in an IPv6-only network that is translated in the middle to IPv4 before being ingested by a PSA UPF within a CN. The disclosure herein provides support to the UPF to handle such potential mismatches. [0121] The disclosure proposes a method and solutions to signal from the AS the origin IP version to a core network of a wireless communications network. The information is targeted to support the core network and more specifically a packet gateway, e.g., a UPF in a 5G wireless communications system, or similar, to handle PDUs marked with PDU Set information, wherein the PDU Set Size information is contained in bytes corresponding to the size of the payload (e.g., a RTP payload) and the IP encapsulation overhead (e.g., UDP/IP encapsulation headers for all PDUs of the PDU Set).

[0122] The proposed signaling indicates to the CN and a PSA UPF the origin IP version at the AS sender. The AS sender indicates this information to the CN to avoid any IP mismatch between its perceived IP version, as origin IP version, and the IP version ingested by the wireless communications system, e.g., the 5GS, at the PSA UPF. Such mismatches may be due to specific network configurations outside the control of an Application Service Provider (ASP) or Mobile Network Operator (MNO). If not solved, the IP version mismatch may impact the performance of the wireless communications system when PDU Set Size information is optionally used, as the PSSize field may contain inaccurate information regarding the size of a PDU Set, due to the mismatch of IP encapsulation offsets. The AS sender IP version signaling consists of at least one bit of information encoding either IPv4 or IPv6 information and may be indicated either over the control plane via an AF, or alternatively, in-band over the user plane as part of the PDU Set marking RTP HE. Certain embodiments will now be described.

[0123] In some embodiments, an AS determines the public IP address of a remote client endpoint, e.g., a UE, performs SDP offer/ answer procedure, and establishes a session for real-time communications with PDU Set marking. The session may serve real-time media applications traffic, such as XR, and connects a wireless communications network of the corresponding UE via a PSA UPF. The AS further determines the IP version corresponding to the determined session, e.g., IPv4, or alternatively, IPv6, as the origin IP version and indicates this information to the CN of the wireless communications system, e.g., the CN of a 5GS, or similar. In some embodiments this indication corresponds to at least one bit of information, the at least one bit encoding the IPv4 and IPv6 information. For instance, in an example the one bit may encode a ‘0’ to indicate that the origin IP corresponds to IPv4, and respectively, a T to indicate IPv6. In another example, the reciprocal may be applied, wherein a ‘0’ encodes an IPv6 origin indication and a T encodes an IPv4 origin indication.

[0124] In some embodiments, the signaling of the origin IP version at the AS, e.g., the RTP sender, is performed over the control plane via an AF. The AS exchanges the IP version information of the session with the AF. This may happen directly over a direct interface between an AS and an AF (e.g., M3, RTC-3 in 5GS or alike), or alternatively, indirectly over a dedicated real-time communication (RTC) signaling server relaying information between the AS and AF (e.g., WebRTC signaling and/ or ICE server, P- CSCF in IMS etc.). In some examples the RTC signaling server may be complemented by additional NAT functionality (e.g., WebRTC ICE or alike CDN gateways providing NAT functions). In case of indirect communication with the AF, in some embodiments the RTC signaling server may detect the origin IP version in part based on the SDP offer/answer messages exchanged by an RTP sender and an RTP receiver, e.g., an AS and UE, a UE and an AS, or alternatively, two or more UEs.

[0125] In some embodiments, the RTP sender role may be fulfilled by a UE. Some examples may include immersive conferencing and conversational services. In such embodiments, the UE may similarly expose its origin IP version to an AF as described in the above embodiments for an AS. In one embodiment, the origin IP may be signaled directly by the UE to an AF by means of control plane signaling, e.g., via a Media Session Function comprised within the UE over 5GS M5, RTC-5, or similar interfaces. In another embodiment, the AF may indirectly determine, e.g., based on an RTC signaling server and an SDP offer/answer message exchange for session establishment, the origin IP version of the UE.

[0126] In some embodiments, the origin IP version information may be embedded by an RTP sender (e.g., an AS, or alternatively, a UE) into a protocol description further containing details (e.g., application ID, IP source address, IP destination address, IP source port, IP destination port, protocol, media sub-components, media subcomponents codec configuration, PDU Set marking enablement indication, PDU Set marking RTP HE configuration, including optional enablement of the PDU Set Size field) of the media session. As a response, the AF signals the origin IP version information and session configuration to the CN. [0127] In some embodiments, the AF indicates the origin IP version information to the NEF for a 5 tuple (IP source address, IP destination address, IP source port, IP destination port, protocol) or an application ID upon the AF requesting the establishment of a session with specific QoS parameters and PDU Set marking for the AS IP flow and traffic. The NEF relays the information to the PCF which determines a set PCC rules. The PCC rules are further shared with the SMF, including further indication of the IP version signaled by the AF. The SMF derives in effect N4 rules that it shares with the PSA UPF via N4 interface, the N4 rules including further the origin IP version indication. The UPF receives the N4 rules and the origin IP version indication and uses this information in establishing an AS session with QoS parameters based on the PCC rules and processes the incoming traffic from the AS including the PDU Set marking. If the PSSize field of the RTP HE is enabled and present, the UPF may process in some embodiments the PDU Set information further and verify against IP mismatches between the ingress IP version and the origin IP version.

[0128] In some embodiments, the AF is placed in a trusted domain and interfaces directly with the PCF. In such an embodiment, the AF indicates directly to the PCF the origin IP and similar processing flow as before follows, whereby the PCC rules are derived and shared with the SMF, including the origin IP. The SMF generates the N4 rules including the origin IP and exposes them to the PSA UPF which is thus configured with the origin IP version.

[0129] In some embodiments, the AF may be instantiated as a dedicated real-time communications AF, i.e., an RTC AF.

[0130] In some embodiments, the AS, as the RTP sender, may mark in-band over the user plane for each PDU Set the origin IP information. The AS may reuse to this extent the PDU Set marking RTP HE. In some embodiments the AS marks with one bit of information the origin IP as part of the optional PSSize field, wherein the one bit (e.g., as either the MSB or LSB) indicates the origin IP version, and the rest of the bits (e.g., 23 remaining bits as in the RTP HE for 5GS Release 18) indicate the PDU Set Size including the IP header encapsulation. As a result, if the PSSize field of the RTP HE is enabled and present, the UPF may process it in some embodiments further and verify against IP mismatches between the ingress IP version and the origin IP version.

[0131] In some embodiments, the UPF may be configured by the MNO, e.g., via an Operation, Administration and Maintenance (OAM) configuration how to handle erroneous PSSize information due to origin IP mismatch. For instance, some configurations may apply as follows. Provided that the UPF is aware of the IP version (either by means of SMF signaling, or by in-band PDU Set marking), the UPF may in some embodiments potentially correct up to its specific procedures any IP mismatch offsets in the PDU Set Size while translating the PDU Set information to the NG-RAN over GTP-U headers. In an example, this implies the UPF to determine the number of PDUs in the PDU Set given the available origin IP version information and incorrect PSSize, and correct the IP header offset based in part on this information. Alternatively, in other embodiments , if an IP mismatch is determined by the UPF, the UPF may simply discard the PDU Set Size information and not include it in the GTP-U headers over the GTP-U tunneling to the NG-RAN. This may correspond to marking the PDU Set Size with ‘0’ value in the GTP-U header, effectively nulling the information, or alternatively, simply skipping this information field in the GTP-U header.

[0132] An example architecture 1100 supporting the control information flow described herein is depicted in Figure 11. The figure highlights the additional origin IP version information shared with the CN relative to the baseline architecture of Figure 8. Features previously described in detail in relation to Figure 8 will not be described in similar detail again in relation to Figure 11 but remain applicable unless otherwise stated. This includes the steps 1180-1185 which correspond to steps 880-885 as described for Figure 8. This further includes the nodes 1110, 1115, 1120, 1125, 1130, 1135, 1140 and 1145 which represent respectively, an XRM AF, PCF, SMF, AMF, RAN, UE, UPF, XR application.. Certain addition features, useful for the understanding the invention are highlighted as follows.

[0133] The architecture 1100 shows how a protocol description including origin IP version is provided from the XR application 1145 to the XRM AF 1110. Furthermore, the architecture 1100 shows how the PDU-set requirements for an IP flow (5-tuple) and the origin IP version are provided by the XRM AF 1110 to the PCF 1115. Also shown in the architecture 1100 is how the PCC rules (PDU-set related QoS requirements for 5- tuple) and the origin IP version configuration are provided from the PCF 1115 to the SMF 1120. Also shown in the architecture 1100 is how the SMF 1120 provides N4 rules, including the origin IP version configuration, to the UPF 1140. Also shown is that XR application 1145 provides the XR packets to UPF 1140. The AMF 1125 also provides N2 SM container (QoS profile) to RAN 1130. The AMF 1125 also provides N1 SM container (QoS Rules) to UE 1135. UPF 1140 provides a QoS flow 1 with GTP-U header (PDU set information) to RAN 1130. The RAN 1130 provides UE 1135 with RB QoS flow 1 (packets of PDU set) and RB QoS flow 2 (packets not belonging to PDU- set).

[0134] In step 1180, the XRM AF 1110 determines PDU-set requirements.

[0135] In step 1181, PDSB, PSER plus additional parameters, for example the origin IP version, are provided to PCF 1115.

[0136] In step 1182, the PCF 1115 determines QoS rules for PDU-set.

[0137] In step 1183, at SMF 1120, the QoS profile of QoS flow includes the PDSB and PSER information and other parameters, for example the origin IP version information. [0138] In step 1184, the UPF 1140 determines PDU set from XR packets and routes packets to a corresponding QoS flow according to N4 rules received from the SMF 1120. [0139] In step 1185, the RAN 1130 receives QFIs, QoS profile of QoS flow from SMF (via AMF) during PDU session establishment/modification (which includes PDSB and PSER). The RAN 1130 inspects GTP-U headers and ensures all packets of the same PDU set are handling according to the QoS profile.

[0140] Figure 12 depicts an information flow 1200 showing the origin IP version signaling by the AF for a session, to a core network. The figure shows a UE 1220, a SMF 1230, a PCF 1240, an RTC AF 1250, a UPF 1260, a NAT and RTC signaling server 1270, and an AS 1280. The information flow 1200 includes indirect AS to AF communication over the NAT and RTC signaling server 1270. As shown in the figure, the AS 1280 uses IPv4; the UE 1220, SMF 1230, PCF 1240, RTC AF 1250, UPF 1260, all use IPv6; and the NAT and RTC signaling server uses IPv4 and IPv6.

[0141] In a first step 1201 the AS 1280 sends to UE 1220, via NAT & RTC signaling server 1270, an SDP offer for a new RTC session with PDU Set marking.

[0142] In a further step 1202 the UE 1220 responds to signaling server 1270 with an answer.

[0143] In a further step 1203 the signaling server 1270 extracts PDU set marking and origin IP version configuration.

[0144] In a further step 1204, the signaling server 1270 informs the RTC AF 1250 about the session including the PDU set marking and origin IP version (in this instance, IPv4).

[0145] In a further step 1205, the RTC AF 1250 sends a QoS session request to the PCF 1240 for QoS allocation with PDU set (including the origin IP version).

[0146] In a further step 1206, the PCF 1240 determines the QoS and PCC rules.

[0147] In a further step 1207, the PCF 1240 configures the SMF 1230, including the origin IP version. [0148] In a further step 1208, the SMF 1230 provides N4 rules (including the origin IP version) to UPF 1260.

[0149] In a further step 1209, the RTC AF 1250 confirms the QoS allocation and origin IP version configuration to signaling server 1270.

[0150] In a further step 1210, the signaling server 1270 forwards the SDP answer from the UE 1220 to the AS 1280.

[0151] In a further step 1211, the AS 1280 downlinks PDU set marked traffic to UE 1220 via UPF 1260.

[0152] As illustrated in the information flow 1200, the UPF 1260 is configured with the origin IP Version configuration for handling PDU Set marking and PDU Set Size information over the configured session. The connectivity between AS 1280 and NAT & RTC signaling server 1270 is IPv4 based and the connectivity between NAT & RTC Signaling Server 1270 and 5GS (1220, 1230, 1240, 1250, 1260) is IPv6 based. Control plane communications are marked with dotted arrows, User plane communications is marked with regular arrows.

[0153] It will be understood that whilst certain embodiments described herein illustrate certain end points in a certain order, i.e. an AS and a UE, in some embodiments, the endpoints may be switched. For instance, the AS and the UE endpoints may be switched and the UE may act as source of the RTC session, i.e., the RTP sender, whereas the AS is the RTP receiver. In such embodiments the UE will indirectly communicate with the AF via a dedicated signaling server, as illustrated in Figure 12 for the case of the AS. In other embodiments, the UE and AS may both have sender and receiver functionality and support multiple sessions at once. In some embodiments, two or more UEs may communicate with each other. Some examples may include immersive conferencing and conversational services.

[0154] The term “traffic” as used herein may refer to media traffic of a media session. The term “origin IP version” may also be referred to as a “first IP version”.

[0155] Accordingly, there is provided a first apparatus for wireless communication, comprising: a processor; and a memory coupled with the processor, the processor configured to cause the first apparatus to: determine an origin internet protocol (IP) version of a media session, the media session being configured with protocol data unit (PDU) set marking including PDU set size information, wherein the origin IP version corresponds to an IP version used by a second apparatus to encapsulate traffic of the second apparatus for transport, in the media session, over one or more wireless communication networks; determine a first indication, corresponding to the origin IP version, for supporting the processing of the PDU set size information during transport over the one or more wireless communication networks; and signal, to a third apparatus of the one or more wireless communication networks, the first indication. The memory may comprise code, which when executed by the processor, causes the first apparatus to operate according to the invention described herein.

[0156] In some embodiments, the first indication comprises at least one bit of information encoding the origin IP version.

[0157] In some embodiments, the origin IP version is an IP version selected from the list of IP versions consisting of: IPv4; and IPv6.

[0158] In some embodiments, the first indication comprises: a ‘0’ when the origin IP version is IPv4, and a ‘I’ when the origin IP version is IPv6; or a ‘0’ when the origin IP version is IPv6, and a ‘I’ when the origin IP version is IPv4.

[0159] In some embodiments, the processor is configured to embed the first indication within a protocol description of the media session.

[0160] In some embodiments, the processor is further configured to cause the first apparatus to determine the origin IP version based on at least one of: a second indication of the origin IP version received from the second apparatus; a session description protocol (SDP) message corresponding to at least one of an offer and an answer exchanged during establishment of the media session; a detected IP version for the media session. In certain embodiments, where the first and second apparatuses are part of the same apparatus, for instance, the second indication may be the output of an internal procedure/ process, e.g., a media application network configuration indication to a RTP protocol stack. In some embodiments the detected IP version is based on the media session traffic IP encapsulation corresponding to one or more IP headers used to transport PDUs of PDU Sets by the original media sender.

[0161] In some embodiments, the third apparatus is selected from the list of apparatuses consisting of: an application function; a real-time communications (RTC) application function; a network exposure function (NEF); and a policy control function (PCF).

[0162] In some embodiments, the third apparatus is a user plane function (UPF).

[0163] In some embodiments, the processor is configured to cause the first apparatus to signal the first indication within one or more PDU set size information fields of the PDU set marking, wherein the first indication comprises one bit of information within each of the one or more PDU set size information fields. In some embodiments the one bit of information may be the most significant bit (MSB) or the least significant bit (LSB). Remaining bits of information in the PDU set size information field further encode the PDU set size in bytes (for instance the remaining 23 bits of the PDU Set marking RTP header extension urn:3gpp:pdu-set-marking:rel-18 as specified in 3GPP Rel-18 Technical Specification TS 26.522), including the IP header encapsulation.

[0164] In some embodiments, the signaling of the first indication may be performed over the user-plane, in-band, directly to a core network gateway such as a UPF.

[0165] In some embodiments, the first apparatus is selected from the list of apparatuses consisting of: an application server; an application function; and a user equipment. The application function may be an RTC application function.

[0166] The second apparatus may be the original media sending entity i.e. an application server, application function, or user equipment. In some embodiments, the first apparatus and the second apparatus are the same apparatus.

[0167] Figure 13 depicts an embodiment of a method 1300 in a first apparatus.

[0168] A first step 1310 comprises determining an origin internet protocol (IP) version of a media session, the media session being configured with protocol data unit (PDU) set marking including PDU set size information, wherein the origin IP version corresponds to an IP version used by a second apparatus to encapsulate traffic of the second apparatus for transport, in the media session, over one or more wireless communication networks.

[0169] A further step 1320 comprises determining a first indication, corresponding to the origin IP version, for supporting the processing of the PDU set size information during transport over the one or more wireless communication networks.

[0170] A further step 1330 comprises signaling, to a third apparatus of the one or more wireless communication networks, the first indication.

[0171] In certain embodiments, the method 1300 may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

[0172] In some embodiments, the first indication comprises at least one bit of information encoding the origin IP version.

[0173] In some embodiments, the origin IP version is an IP version selected from the list of IP versions consisting of: IPv4; and IPv6. [0174] In some embodiments the first indication comprises: a ‘0’ when the origin IP version is IPv4, and a ‘1’ when the origin IP version is IPv6; or a ‘0’ when the origin IP version is IPv6, and a ‘1’ when the origin IP version is IPv4.

[0175] Some embodiments comprise embedding the first indication within a protocol description of the media session.

[0176] Some embodiments comprise determining the origin IP version based on at least one of: a second indication of the origin IP version received from the second apparatus; a session description protocol (SDP) message corresponding to at least one of an offer and an answer exchanged during establishment of the media session; a detected IP version for the media session.

[0177] In some embodiments, the third apparatus is selected from the list of apparatuses consisting of: an application function; a real-time communications (RTC) application function; a network exposure function (NEF); and a policy control function (PCF). [0178] In some embodiments, the third apparatus is a user plane function (UPF).

[0179] Some embodiments comprise signaling the first indication within one or more PDU set size information fields of the PDU set marking, wherein the first indication comprises one bit of information within each of the one or more PDU set size information fields.

[0180] In some embodiments, the first apparatus is selected from the list of apparatuses consisting of: an application server; an application function; and a user equipment.

[0181] In some embodiments, the first apparatus and the second apparatus are the same apparatus.

[0182] Accordingly, there is provided an apparatus in a wireless communication network, comprising: a processor; and a memory coupled with the processor, the processor configured to cause the apparatus to: receive a first configuration for processing traffic of a media session, the media session being configured with protocol data unit (PDU) set marking including PDU set size information, wherein the first configuration comprises a first indication of an origin internet protocol (IP) version used by a second apparatus to encapsulate the traffic for transport, in the media session, over the wireless communication network; receive a plurality of PDUs of a PDU set of the traffic; compare the received plurality of PDUs to the first configuration, to determine whether the first indication of the origin IP version matches an IP version of the received plurality of PDUs; process the PDU set size information that is available for the plurality of PDUs of the PDU set based on a second configuration, by correcting the PDU set size information and/ or skipping the PDU set size information, if the comparison determines a mismatch between the origin IP version and the IP version of the received plurality of PDUs; route, to a radio access network, the plurality of PDUs and the processed PDU set size information. The memory may comprise code, which when executed by the processor, causes the apparatus to operate according to the invention described herein.

[0183] In some embodiments, at least one of the first configuration and the second configuration is provided for the media session by a Session Management Function (SMF).

[0184] In some embodiments, the second configuration is based on one or more operation administration and maintenance (OAM) procedures.

[0185] In some embodiments, the processor is configured to cause the apparatus to correct the PDU set size information based on at least one of: a PDU set marking; the determined mismatch; the PDU set size information that is available for the plurality of PDUs of the PDU set.

[0186] In some embodiments, the processor is configured to cause the apparatus to skip the PDU set size information by causing the apparatus to: drop the PDU set size information; and/or null the PDU set size information.

[0187] In some embodiments, the apparatus comprises a user-plane function (UPF). [0188] The apparatus may process traffic (for instance media traffic) in an uplink direction, downlink direction, or both. For instance, when facilitating conferencing services, a UPF may route uplink and downlink traffic.

[0189] The second apparatus may be the original media sending entity i.e. an application server or a UE, for instance.

[0190] Figure 14 depicts a further embodiment of a method 1400 in an apparatus, the apparatus in a wireless communication network.

[0191] A first step 1410 comprises, receiving a first configuration for processing traffic of a media session, the media session being configured with protocol data unit (PDU) set marking including PDU set size information, wherein the first configuration comprises a first indication of an origin internet protocol (IP) version used by a second apparatus to encapsulate the traffic for transport, in the media session, over the wireless communication network.

[0192] A further step 1420 comprises, receiving a plurality of PDUs of a PDU set of the traffic. [0193] A further step 1430 comprises, comparing the received plurality of PDUs to the first configuration, to determine whether the first indication of the origin IP version matches an IP version of the received plurality of PDUs.

[0194] A further step 1440 comprises, processing the PDU set size information that is available for the plurality of PDUs of the PDU set based on a second configuration, by correcting the PDU set size information and/ or skipping the PDU set size information, if the comparing determines a mismatch between the origin IP version and the IP version of the received plurality of PDUs.

[0195] A further step 1450 comprises, routing, to a radio access network, the plurality of PDUs and the processed PDU set size information.

[0196] In certain embodiments, the method 1400 may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

[0197] In some embodiments, the method further comprises receiving at least one of the first configuration and the second configuration from a Session Management Function (SMF).

[0198] In some embodiments, the second configuration is based on one or more operation administration and maintenance (OAM) procedures.

[0199] Some embodiments comprise correcting the PDU set size information based on at least one of: a PDU set marking; the determined mismatch; the PDU set size information that is available for the plurality of PDUs of the PDU set.

[0200] Some embodiments comprise skipping the PDU set size information by: dropping the PDU set size information; and/ or nulling the PDU set size information. [0201] In some embodiments, the apparatus comprises a user-plane function (UPF). [0202] The proposed solutions described herein introduce a number of novel elements.

[0203] Firstly, an indication is provided, from the RTP sender, e.g., an application server (AS), or alternatively, a UE, of the origin IP Version, that is signaled to the core network (CN) to support the UPF in processing PDU Set information.

[0204] Furthermore, the indication is conveyed either by C-plane via the AF to PCF to SMF to UPF for a RTC session, or in band using the existing PDU Set RTP HE marking.

[0205] Furthermore, an SMF, or alternatively, an OAM configuration of the UPF is discussed, to cause the UPF to use the provided origin IP version information to handle the PDU Set Size information in case it detects an IP version mismatch. [0206] The disclosure herein provides, from the perspective of a sender or the senderside , a method in assisting communications over a session configured with Protocol Data Unit (PDU) Set marking including PDU Set Size information, the method comprising of: determining an origin Internet Protocol version of a media sender, the origin IP version corresponding to the sender IP version used to encapsulate for transport over one or more networks the media sender session traffic; determining a first indication corresponding to the origin IP version; signaling the first indication to a network function in support of PDU Set Size processing against IP protocol version mismatches.

[0207] The disclosure herein proposes a solution to indicate the sender, e.g., an AS origin IP version for encapsulation of the PDUs of a PDU Set. This supports the UPF decision making in further processing the PDU Set Size information field. Such a solution is not found in for instance, 3GPP Technical Report 23.700-60 (v0.3.0), or PCT/EP2022/077327. In addition, the disclosure herein builds on other patent applications filed by the applicant by additionally considering the signaling IP version indications which may be part of the RTP HE or signaled over the control plane.

[0208] In some embodiments, the determination of the origin IP version is based at least on one of: a second indication of an IP version received from the media sender; a SDP message corresponding to at least one of an offer and an answer exchange during an SDP offer/ answer procedure establishing the session between the media sender and a remote receiver; a detected IP version for the session based on one or more IP headers used by the media sender for the session traffic IP encapsulation.

[0209] In some embodiments, the second indication of the IP version received from the media sender corresponds to the output of an internal procedure. In such embodiments, the media sender may be collocated with the node implementing the method. Hence, the media sender may determine programmatically the IP version (e.g. based on at least one of socket options, socket INET version, app server network configuration, etc).

[0210] In some embodiments, the first indication corresponds to at least one bit of information encoding IPv4 and IPv6 IP versions.

[0211] In some embodiments, the first indication comprises of one of: a ‘0’ corresponding to origin IP version as IPv4 and a T’ corresponding to origin IP version as IPv6; and a T corresponding to origin IP version as IPv4 and a ‘0’ corresponding to origin IP version as IPv6. [0212] In some embodiments, the first indication is further embedded within a protocol description corresponding to the session, the protocol description additionally comprising at least one indication of a media protocol and a media payload type. These embodiments tend to relate to C-plane signaling.

[0213] In some embodiments, the first indication is signaled to a User Plane Function (UPF) within one or more PDU Set Size (PSSize) fields corresponding to the PDU Set marking, the first indication corresponding to one bit of information within the PSSize field, and the remaining bits of information of the PSSize field further encoding the PDU Set Size in bytes. These embodiments tend to relate to U-plane signaling directly to the UPF. The PSSize is essentially in every PDU Set RTP header and hence in every PDU of a PDU set and in all PDU sets. Optionally, the PSSize field is appended to the PDU Set RTP HE information based on AS configuration. The PDU Set Size in Rel-18 of 3GPP RTP HE for PDU Set marking corresponds to 24 bits. Out of these, 1 bit (either least significant bit (LSB) or most significant bit (MSB)) is used to signal origin IP version indication (e.g., a ‘0’ for IPv4 and a T for IPv6), and the rest of the bits are used to encode the PDU Set Size in Bytes, including the IP headers encapsulation overhead.

[0214] In some embodiments the first indication is signaled to the network function corresponding to at least one of: an application function (AF) (which may be necessary for AS to AF direct communications); a real-time communications (RTC) AF (which may be necessary for IMS/WebRTC based communications with NAT/ signaling servers in between an AF and an AS); a network exposure function (NEF); and a policy control function (PCF).

[0215] The above-described methods may be performed at a network node. The network node may comprise an AS, an AF, or a UE.

[0216] The disclosure herein further provides a method performed by a User Plane Function (UPF ), the method comprising of: receiving a configuration, the configuration comprising a protocol description including an origin IP version indication; receiving a protocol data unit (PDU) in a downlink direction wherein the received PDU is subject to PDU Set processing according to the configuration; determining whether: the received PDUs do not match all components of the received configuration, including checking the IP version of the received PDUs against the origin IP version indication; processing available PDU Set Size to avoid mismatch due to difference in IP version between origin IP version indication and the received PDUs IP version; and routing the received PDUs and corresponding PDU Sets to a radio access network. The processed PDU Set Size may be embedded as PDU Set information in the GTP-U headers over the GTP-U tunnel that is used to route the traffic to an NG-RAN.

[0217] In some embodiments, the processing of the available PDU Set Size is based on a configuration of Operations, Administration and Management (OAM) procedures.

[0218] In some embodiments, the processing of the available PDU Set Size comprises of at least one of: a correction of the PDU Set Size based at least on the PDU Set, the determined IP version mismatch between the PDUs of the PDU Set and the origin IP version indication, and the available PDU Set Size (for instance by providing the correct PDU Set Size in the GTP-U header); and a skip of the PDU Set Size information corresponding to at least one of dropping the PDU Set Size information, and nulling the PDU Set Size information in the routing to the radio access network.

[0219] It should be noted that the above-mentioned methods and apparatus illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative arrangements without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

[0220] Further, while examples have been given in the context of particular communication standards, these examples are not intended to be the limit of the communication standards to which the disclosed method and apparatus may be applied. For example, while specific examples have been given in the context of 3GPP, the principles disclosed herein can also be applied to another wireless communication system, and indeed any communication system which uses routing rules. Similarly, while specific examples have been given in the context of XR applications with PDU Set marking, the principles disclosed herein can also be applied to other multimedia applications, and indeed any application which uses PDU Set marking.

[0221] The method may also be embodied in a set of instructions, stored on a computer readable medium, which when loaded into a computer processor, Digital Signal Processor (DSP) or similar, causes the processor to carry out the hereinbefore described methods.

[0222] The described methods and apparatus may be practiced in other specific forms. The described methods and apparatus are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

[0223] Further references as may be relevant to the disclosure herein include: IETF draft titled “Frame Marking RTP Header Extension” published November 2021; US Patent Application 63/428,026 [Applicant’s reference SMM920220198-US-PSP]; PCT Application PCT/IB2022/062496 [Applicant’s reference SMM920210150-WG-PCT ; and Greek Patent Application 20230100361 [Applicant’s reference SMM920230008-GR- NP].

[0224] The following abbreviations are relevant in the field addressed by this document: 3GPP, 3rd generation partnership project; 5G, fifth generation; 5GS, 5G System; 5QI, 5G QoS Identifier; AF, application function; AMF, access and mobility function; AR, augmented reality; AS, application server; CDN, content distribution network; DL, Downlink; DN, data network; NAL, network abstraction layer; NAT, network address translation; PCF, policy control function; PDU, packet data unit; PPS, picture parameter set; QoE, quality of experience; QoS, quality of service; RAN, radio access network;

RTCP, real-time control protocol; RTP, real-time protocol; SDAP, service data adaptation protocol; SMF, session management function; SRTCP, secure real-time control protocol; SRTP, secure real-time protocol; UE, user equipment; UL, Uplink;

UPF, user plane function; VCL, video coding layer; VMAF, video multi-method assessment function; VPS, video parameter set; VR , virtual reality; XR, extended reality; XR AS, XR application server; and XRM, XR media.