PDU set tagging in QoS flow in wireless communication network

Abstract

A user plane function (UPF) receives protocol data units (PDUs) in a downlink direction, the received PDUs being subject to PDU set processing according to configuration information received from a session management function (SMF), and the configuration information including a protocol description. The UPF determines whether the received PDU does not match all components of the configuration information, or whether the received PDU does match a protocol description of the configuration information, and the received PDU is not part of a set of PDUs. If the received PDU does not match all components of the configuration information, or the received PDU does match a protocol description of the configuration information, and the received PDU is not part of a PDU set, the UPF creates a header for the received PDU, the header including PDU set information. The UPF routes the received PDU and header to a radio access network.

Description

[0001] Related applications

[0002] This application claims priority to U.S. Application No. 18 / 340,730, filed on June 23, 2023, entitled “PDU Set Marking in QoS Flows in a Wireless Communication Network,” the disclosure of which is incorporated herein by reference in its entirety. U.S. Application No. 18 / 340,730 claims priority to Greek Application Serial No. 2413-0004699645, filed on May 2, 2023, entitled “PDU Set Marking in QoS Flows in a Wireless Communication Network,” the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The subject matter disclosed herein generally relates to the field of implementing PDU set marking in QoS flows in wireless communication networks.User plane functions and methods in user plane functions are defined herein. Background Art

[0004] In the context of XR media services, the 3GPP SA2 WG recently introduced the concept of end-of-burst indication (EOBI) for signaling the end of a data burst of multiple PDUs for XR media services to the Next Generation Radio Access Network (NG-RAN). EOBI is optional and is intended to help the RAN determine the data burst completion event and enable low-level radio resource allocation and connected state discontinuous reception (C-DRX) optimization to improve energy saving. Therefore, the application server (AS) needs to indicate EOBI to the 5G system (5GS), whose XR services and associated XR service characteristics are given.

[0005] In addition, the 3GPP SA2 WG also determined the concept of PDU sets for XR media services (XRM) to group a series of PDUs that carry information units at the application level. Therefore, PDU sets can be processed according to the same set of QoS requirements and associated constraints of delay budget and error rate, while providing the radio access network (RAN) with support for differentiated QoS processing at the PDU set level. This improves the granularity of the traditional 5G QoS flow framework, allowing the RAN to optimize the mapping between QoS flows and DRBs to meet strict XR media requirements (e.g., high-speed transmission with a short delay budget). Summary of the Invention

[0006] If both packets marked with PDU set information and unmarked packets are sent via such a QoS flow, the complexity at the RAN increases because the RAN will need to provide scheduling resources for the PDUs of the PDU set based on the PDU set delay budget (PDSB), and for the unmarked PDU set packets based on the traditional PDB of the QoS flow, where the PDSB value is higher than the traditional PDB. The solution proposed in this article involves implementing a policy that all PDUs in the downlink direction of a QoS flow enabled with PDU set marking must be marked with PDU set information when ingested into the 5GS via the UPF via the N6 interface. This policy, in turn, results in a QoS flow enabled with PDU set marking always containing only packets marked with PDU set information.

[0007] This document discloses a process for PDU set marking in a QoS flow in a wireless communication network. The process can be implemented by a user plane function and a method in the user plane function.

[0008] Accordingly, a user plane function (UPF) is provided, the UPF comprising a processor and a memory coupled to the processor, the memory containing instructions that, when executed by the processor, cause the UPF to: receive a protocol data unit (PDU) in a downlink direction, the received PDU being subject to PDU set processing according to configuration information received from a session management function (SMF), wherein the configuration information includes a protocol description; and determine whether: the received PDU does not match all components of the configuration information received from the SMF; or whether the received PDU does match the protocol description of the configuration information, but the received PDU is not part of the PDU set. The UPF is further caused to create a header for the received PDU, the header including PDU set information, if either: the received PDU does not match all components of the configuration information received from the SMF; or the received PDU does match the protocol description of the configuration information, but the received PDU is not part of the PDU set. The processor is further caused to route the received PDU and the header to a radio access network.

[0009] A method performed by a user plane function (UPF) is also provided, the method comprising: receiving a protocol data unit (PDU) in a downlink direction, the received PDU being subject to PDU set processing according to configuration information received from a session management function (SMF), wherein the configuration information includes a protocol description; and determining: whether the received PDU does not match all components of the configuration information received from the SMF; or whether the received PDU does match the protocol description of the configuration information, but the received PDU is not part of the PDU set. The method also comprises creating a header for the received PDU, the header including PDU set information, in either of the following cases: the received PDU does not match all components of the configuration information received from the SMF; or the received PDU does match the protocol description of the configuration information, but the received PDU is not part of the PDU set. The method also comprises routing the received PDU and the header to a radio access network. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to illustrate the manner in which the advantages and features of the present disclosure can be obtained, the present disclosure is described by reference to certain devices and methods shown in the accompanying drawings. Each of these drawings depicts only certain aspects of the present disclosure and, therefore, should not be considered as limiting the scope thereof. For the sake of clarity, the drawings may have been simplified and are not necessarily drawn to scale.

[0011] A method and apparatus for PDU set marking in a QoS flow in a wireless communication network will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0012] Figure 1 An embodiment of a wireless communication system for PDU set marking in a QoS flow in a wireless communication network is described;

[0013] Figure 2 depicts a user equipment apparatus that may be used to implement the methods described herein;

[0014] Figure 3 depicts further details of a network node that may be used to implement the methods described herein;

[0015] Figure 4 Provides an overview of the RTP and RTCP stacks;

[0016] Figure 5 Diagram showing an overview of the WebRTC stack;

[0017] Figure 6a and Figure 6b The diagrams illustrate the packet format and header information for RTP packets and SRTP packets respectively;

[0018] Figure 7Illustrate the RTP / SRTP header extension format and syntax;

[0019] Figure 8 The diagram shows an overview of the core network XRM architecture for processing PDU sets;

[0020] Figures 9a to 9d The diagram shows the 5GS PDU set-aware QoS processing framework description of PDU set to QoS flow to DRB mapping;

[0021] Figure 10 An example of a scenario is shown, which includes different AF sessions of an XR video application and a non-XR application multiplexed by the 5GS;

[0022] Figure 11 illustrates an example scenario including the same AF session of an XR application served over WebRTC, where audio and video are sent in a multiplexed manner over one RTP stream of the XR application; and

[0023] Figure 12 A method in user plane functionality is illustrated. DETAILED DESCRIPTION

[0024] If both packets marked with PDU set information and unmarked packets are sent via such a QoS flow, the complexity at the RAN increases because the RAN will need to provide scheduling resources for the PDUs of the PDU set based on the PDU set delay budget (PDSB), and for the unmarked PDU set packets based on the traditional PDB of the QoS flow, where the PDSB value is higher than the traditional PDB. The solution proposed in this article involves implementing a policy that all PDUs in the downlink direction of a QoS flow enabled with PDU set marking must be marked with PDU set information when ingested into the 5GS via the UPF via the N6 interface. This policy, in turn, results in a QoS flow enabled with PDU set marking always containing only packets marked with PDU set information.

[0025] Before delving further into the details of the techniques presented herein, it is noted that those skilled in the art will appreciate that aspects of the present disclosure may be embodied as systems, apparatuses, methods, or program products. Thus, the arrangements described herein may be implemented entirely in hardware, entirely in software (including firmware, resident software, microcode, etc.), or in a combination of software and hardware aspects.

[0026] For example, the disclosed methods and apparatus may be implemented as hardware circuits, including custom very large scale integrated (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, and the like. As another example, the disclosed methods and apparatus may include one or more physical or logical blocks of executable code, which may be organized, for example, as objects, procedures, or functions.

[0027] 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, hereinafter referred to as code. The storage device may be tangible, non-transitory, and / or non-transmitting. The storage device may not embody signals. In some arrangements, the storage device utilizes only signals for accessing the code.

[0028] Any combination of one or more computer-readable media 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 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 thereof.

[0029] More specific examples of storage devices (a non-exhaustive list) would include the following: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), a portable compact disk 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.

[0030] In this specification, references to examples of particular methods or devices or similar language indicate that the specific features, structures or characteristics described in conjunction with the examples are included in at least one implementation of the methods and devices described herein. Therefore, unless otherwise expressly provided, references to features of examples of particular methods or devices or similar language may, but do not necessarily, all refer to the same examples, but rather to "one or more but not all examples". Unless otherwise expressly provided, the terms "including", "comprising", "having" and their variations mean "including but not limited to". Unless otherwise expressly provided, a list of enumerated items does not mean that any or all items are mutually exclusive. Unless otherwise expressly provided, the terms "a", "an" and "the" also mean "one or more".

[0031] As used herein, a list with the conjunction "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 term "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 term "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, but does not include a combination of A, B, and C. As used herein, "a member selected from the group including A, B, and C" includes one and only one of A, B, or C, but does not include a combination 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.

[0032] In addition, the features, structures or characteristics of the descriptions described herein may be combined in any suitable manner. In the following description, many specific details (such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc.) are provided to provide a comprehensive understanding of the present disclosure. However, those skilled in the art will recognize that the disclosed methods and apparatus can be practiced without one or more specific details, or can be practiced using other methods, components, materials, etc. In other cases, well-known structures, materials or operations are not shown or described in detail to avoid confusing aspects of the present disclosure.

[0033] Aspects of the disclosed methods and apparatus are described below with reference to schematic flow charts and / or schematic block diagrams of methods, apparatuses, systems, and program products. It will be understood that each block of the schematic flow charts and / or schematic block diagrams, and combinations of blocks in the schematic flow charts and / or schematic block diagrams, can be implemented by code. The code can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine such that instructions executed by the processor of the computer or other programmable data processing device can create components for implementing the functions / actions specified in the schematic flow charts and / or schematic block diagrams.

[0034] The code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other device to operate in a specific manner so that the instructions stored in the storage device produce an article of manufacture that includes instructions for implementing the functions / actions specified in the schematic flowchart and / or schematic block diagram.

[0035] The code can also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operating steps to be executed on the computer, other programmable apparatus or other device, thereby producing a computer-implemented process, so that the code executed on the computer or other programmable apparatus provides a process for implementing the functions / actions specified in the schematic flowchart and / or schematic block diagram.

[0036] The schematic flow charts and / or schematic block diagrams in the figures illustrate the architecture, functions and operations of possible implementations of devices, systems, methods and program products. In this regard, each box in the schematic flow charts 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 (multiple) specific logical functions.

[0037] It should also be noted that in some alternative implementations, the functions shown in the blocks may not occur in the order shown 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 on the functionality involved. Other steps and methods are contemplated that are equivalent in function, logic, or effect to one or more blocks, or portions thereof, of the illustrated figures.

[0038] The description of an element in each figure may refer to an element in a subsequent figure. The same numbers refer to the same elements throughout the drawings.

[0039] Figure 1 An embodiment of a wireless communication system 100 for PDU set marking in a QoS flow in a wireless communication network is depicted. In one embodiment, the wireless communication system 100 includes a remote unit 102 and a network unit 104. Although Figure 1 A specific number of remote units 102 and network units 104 are depicted in the figure, but those skilled 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. A wireless communication system may include 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 include at least one network node. A network node may be a network unit.

[0040] In one embodiment, the remote unit 102 may include a computing device such as a desktop computer, a laptop computer, a personal digital assistant (PDA), a tablet computer, a smartphone, a smart TV (e.g., a TV connected to the Internet), a set-top box, a game console, a security system (including a security camera), an in-vehicle computer, a network device (e.g., a router, a switch, a modem), an aircraft, a drone, etc. In some embodiments, the remote unit 102 includes a wearable device such as a smart watch, a fitness band, an optical head-mounted display, etc. Furthermore, the remote unit 102 may be referred to as a subscriber unit, a mobile station, a mobile station, a user, a terminal, a mobile terminal, a fixed terminal, a subscriber station, a UE, a user terminal, a device, or other terms used in the art. The remote unit 102 may communicate directly with one or more of the network units 104 via UL communication signals. In some embodiments, the remote unit 102 may communicate directly with other remote units 102 via sidelink communications.

[0041] The network elements 104 may be distributed over a geographical area. In some embodiments, the network elements 104 may also be referred to as access points, access terminals, base stations, base stations, node Bs, eNBs, gNBs, home node Bs, relay nodes, devices, core networks, air servers, radio access nodes, APs, NRs, network entities, access and mobility management functions (AMFs), unified data management functions (UDMs), unified data repositories (UDRs), UDM / UDRs, policy control functions (PCFs), radio access networks (RANs), network slice selection functions (NSSFs), operations, administration, and management (OAMs), session management functions (SMFs), user plane functions (UPFs), application functions, authentication server functions (AUSFs), security anchor functions (SEAFs), trusted non-3GPP gateway functions (TNGFs), application functions, service enabler architecture layer (SEAL) functions, vertical application enabler servers, edge enabler servers, border configuration servers, mobile edge computing platform functions, mobile edge computing applications, application data analysis enabler servers, SEAL data delivery servers, middleware entities, network slice capability management servers, or any other terminology used in the art. The network elements 104 are typically part of a radio access network that includes one or more controllers communicatively coupled to one or more corresponding network elements 104. The radio access network is typically communicatively coupled to one or more core networks, which can be coupled to other networks, such as the Internet and a public switched telephone network. These and other elements of the radio access network and core network are not shown but are generally familiar to those of ordinary skill in the art.

[0042] In one implementation, the wireless communication system 100 conforms to the New Radio (NR) protocol standardized in 3GPP, wherein the network unit 104 transmits on the downlink (DL) using an orthogonal frequency division multiple access (OFDM) modulation scheme, and the remote unit 102 transmits 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, such as WiMAX, an IEEE 802.11 variant, GSM, GPRS, UMTS, an LTE variant, CDMA2000, ZigBee, Sigfox, LoraWAN, etc. The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol.

[0043] The network unit 104 can serve a number of remote units 102 within a service area (e.g., a cell or cell sector) via wireless communication links. The network unit 104 sends DL communication signals to serve the remote units 102 in the time, frequency, and / or spatial domains.

[0044] Figure 2 A user equipment device 200 is depicted that can be used to implement the methods described herein. The user equipment device 200 is used to implement one or more of the solutions described herein. The user equipment device 200 conforms to one or more of the user equipment devices described in the embodiments herein. Specifically, the user equipment device 200 may include a remote unit 102, a UE 835, 1035, or 1135 as described herein. The user equipment device 200 includes a processor 205, a memory 210, an input device 215, an output device 220, and a transceiver 225.

[0045] The input device 215 and the output device 220 can be combined into a single device, such as a touch screen. 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 can include one or more of the following: a processor 205, a memory 210, and a transceiver 225, and may not include an input device 215 and / or an output device 220.

[0046] As depicted, the transceiver 225 includes at least one transmitter 230 and at least one receiver 235. The transceiver 225 can communicate with one or more cells (or wireless coverage areas) supported by one or more network elements. The transceiver 225 can be operable on an unlicensed spectrum. In addition, the transceiver 225 can include multiple UE panels supporting one or more beams. Additionally, the transceiver 225 can support at least one network interface 240 and / or application interface 245. The application interface(s) 245 can support one or more APIs. The network interface(s) 240 can support 3GPP reference points such as Uu, N1, PC5, etc. As will be appreciated by one of ordinary skill in the art, other network interfaces 240 can be supported.

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

[0048] Processor 205 may control user equipment device 200 to implement the user equipment device behaviors described herein. Processor 205 may include an application processor (also referred to as a main processor) that manages application domain and operating system (OS) functions, and a baseband processor (also referred to as a baseband radio processor) that manages radio functions.

[0049] 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 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 drive, flash memory, or any other suitable non-volatile computer storage device. The memory 210 may include both volatile computer storage media and non-volatile computer storage media.

[0050] Memory 210 may store data related to implementing the traffic class field as described herein.Memory 210 may also store program code and related data, such as an operating system or other controller algorithms operating on device 200.

[0051] Input device 215 may include any known computer input device, including a touchpad, buttons, keyboard, stylus, microphone, etc. Input device 215 may be integrated with output device 220, for example, as a touch screen or similar touch-sensitive display. Input device 215 may include a touch screen so that text can be entered using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. Input device 215 may include two or more different devices, such as a keyboard and a touchpad.

[0052] The output device 220 may be designed to output visual, auditory, and / or tactile 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 a similar display device capable of outputting images, text, and the like to a user. As another non-limiting example, the output device 220 may include a wearable display that is separate from but communicatively coupled to the rest of the user device apparatus 200, such as a smart watch, smart glasses, a head-up display, and the like. In addition, the output device 220 may be a component of a smart phone, a personal digital assistant, a television, a desktop computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, and the like.

[0053] The output device 220 may include one or more speakers for generating sound. For example, the output device 220 may generate an audible alarm or notification (e.g., a beep or buzzer). The output device 220 may include one or more haptic devices for generating vibration, motion, or other tactile feedback. All or part of the output device 220 may be integrated with the input device 215. For example, the input device 215 and the output device 220 may form a touch screen or similar touch-sensitive display. The output device 220 may be located near the input device 215.

[0054] The transceiver 225 communicates with one or more network functions of the 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 receives messages, data, and other signals. For example, the processor 205 can selectively activate the transceiver 225 (or portions thereof) at specific times to transmit and receive messages.

[0055] The transceiver 225 includes at least one transmitter 230 and at least one receiver 235. One or more transmitters 230 can be used to provide uplink communication signals to a base unit of a wireless communication network. Similarly, one or more receivers 235 can be used to receive downlink communication signals from the base unit. Although only one transmitter 230 and one receiver 235 are shown, the user equipment device 200 can have any suitable number of transmitters 230 and receivers 235. In addition, the (multiple) transmitters 230 and (multiple) receivers 235 can be any suitable type of transmitter and receiver. The transceiver 225 may include a first transmitter / receiver pair for communicating with a mobile communication network via a licensed radio spectrum, and a second transmitter / receiver pair for communicating with a mobile communication network via an unlicensed radio spectrum.

[0056] A first transmitter / receiver pair that can be used to communicate with a mobile communication network via a licensed radio spectrum and a second transmitter / receiver pair that can communicate with a mobile communication network via an unlicensed radio spectrum can be combined into a single transceiver unit, such as a single chip that performs functions for use with both the licensed radio spectrum and the unlicensed radio spectrum. The first transmitter / receiver pair and the second transmitter / receiver pair can share one or more hardware components. For example, some of transceivers 225, transmitter 230, and receiver 235 can be implemented as physically separate components that access shared hardware resources and / or software resources, such as network interface 240.

[0057] One or more transmitters 230 and / or one or more receivers 235 can be implemented and / or integrated into a single hardware component, such as a multi-transceiver chip, a system on a chip, an application-specific integrated circuit (ASIC), or other types of hardware components. One or more transmitters 230 and / or one or more receivers 235 can be implemented and / or integrated into a multi-chip module. Other components such as a network interface 240 or other hardware components / circuits can be integrated into a single chip with any number of transmitters 230 and / or receivers 235. The transmitters 230 and receivers 235 can be logically configured as transceivers 225 using one or more common control signals, or as modular transmitters 230 and receivers 235 implemented in the same hardware chip or multi-chip module.

[0058] Figure 3 10. Further details of a network node 300 that can be used to implement the methods described herein are depicted. The network node 300 can be one implementation of an entity in a wireless communication network (e.g., one or more of the wireless communication networks described herein). The network node 300 can include a network element 104 or user plane function (UPF), including 840, 104, and 1140, as described herein. The network node 300 includes a processor 305, a memory 310, an input device 315, an output device 320, and a transceiver 325.

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

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

[0061] The processor 305 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, the processor 305 may be a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, or a 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.

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

[0063] The memory 310 may store data related to establishing a multipath unicast link and / or mobile operations. For example, as described herein, the memory 310 may store parameters, configurations, resource allocations, policies, etc. 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.

[0064] Input device 315 may include any known computer input device, including a touchpad, buttons, keyboard, stylus, microphone, etc. Input device 315 may be integrated with output device 320, for example, as a touch screen or similar touch-sensitive display. Input device 315 may include a touch screen so that text can be entered using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. Input device 315 may include two or more different devices, such as a keyboard and a touchpad.

[0065] Output device 320 may be designed to output visual, auditory, and / or tactile signals. Output device 320 may include an electronically controllable display or display device capable of outputting visual data to a user. For example, output device 320 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or a similar display device capable of outputting images, text, etc. to a user. As another non-limiting example, output device 320 may include a wearable display that is separate from but communicatively coupled to the rest of network node 300, such as a smartwatch, smart glasses, a head-up display, or the like. In addition, output device 320 may be a component of a smartphone, a personal digital assistant, a television, a desktop computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.

[0066] Output device 320 may include one or more speakers for generating sound. For example, output device 320 may generate an audible alarm or notification (e.g., a beep or buzzer). Output device 320 may include one or more haptic devices for generating vibration, motion, or other tactile feedback. All or part of output device 320 may be integrated with input device 315. For example, input device 315 and output device 320 may form a touch screen or similar touch-sensitive display. Output device 320 may be located near input device 315.

[0067] The transceiver 325 includes at least one transmitter 330 and at least one receiver 335. The one or more transmitters 330 can be used to communicate with the UE, as described herein. Similarly, the one or more receivers 335 can 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 shown, the network node 300 can have any suitable number of transmitters 330 and receivers 335. Furthermore, the transmitter(s) 330 and the receiver(s) 335 can be any suitable type of transmitter and receiver.

[0068] In the context of XR media services, the 3GPP SA2 WG recently introduced the concept of end-of-burst indication (EOBI) for signaling the end of a data burst of multiple PDUs for XR media services to the Next Generation Radio Access Network (NG-RAN). EOBI is optional and is intended to help the RAN determine the data burst completion event and enable low-level radio resource allocation and connected state discontinuous reception (C-DRX) optimization to improve energy saving. Therefore, the application server (AS) needs to indicate EOBI to the 5G system (5GS), whose XR services and associated XR service characteristics are given.

[0069] In addition, the 3GPP SA2 WG also determined the concept of PDU sets for XR media services (XRM) to group a series of PDUs that carry information units at the application level. Therefore, PDU sets can be processed according to the same set of QoS requirements and associated constraints of delay budget and error rate, while providing the radio access network (RAN) with support for differentiated QoS processing at the PDU set level. This improves the granularity of the traditional 5G QoS flow framework, allowing the RAN to optimize the mapping between QoS flows and DRBs to meet strict XR media requirements (e.g., high-speed transmission with a short delay budget).

[0070] A related issue with the latter activity is how to communicate PDU set information (i.e., PDU set boundaries, PDU set importance) between the application and the 5GS. This document addresses this issue from an application-centric perspective, where the application (i.e., the application logic on the UE device or the application server of the application provider) determines the PDU set information and signals it to the 5GS core network. This signaling is provided in real time with low signaling / control overhead to achieve the QoS performance benefits based on the PDU set concept.

[0071] Extended reality (XR) has since been used as an umbrella term for different types of reality (virtual reality, augmented reality, and mixed reality being examples).

[0072] Virtual Reality (VR) is a rendered version of a delivered visual and audio scene. In this case, the rendering is designed to mimic the visual and auditory stimuli of the real world as naturally as possible as the observer or user moves within the limits defined by the application. Virtual Reality typically (but not necessarily) requires the user to wear a head-mounted display (HMD) that completely replaces the user's field of view with simulated visual components, and wear headphones to provide the user with incidental audio. In VR, some form of head and motion tracking of the UE is also typically required to allow the simulated visual and audio components to be updated to ensure that, from the user's perspective, objects and sound sources are aligned with the user's movements. In some implementations, additional means of interacting with the virtual reality simulation may be provided, but are not strictly necessary.

[0073] Augmented reality (AR) refers to a situation where a user is provided with additional information or artificially generated items, or content superimposed on their current environment. Such additional information or content is typically visual and / or auditory, and their observation of their current environment can be direct, without intervening sensing, processing, and rendering, or indirect, where their perception of their environment is relayed via sensors and can be augmented or processed.

[0074] Mixed reality (MR) is an advanced form of AR in which some virtual elements are inserted into the physical scene with the aim of providing the illusion that these elements are part of the real scene.

[0075] XR refers to all combined real and virtual environments and human-computer interactions generated by computer technology and wearable devices. It encompasses representative modalities such as AR, MR, and VR, as well as areas in between. Virtuality levels range from partial sensory input to fully immersive VR. In some circles, a key aspect of XR is considered an extension of the human experience, particularly those related to presence (represented by VR) and cognitive acquisition (represented by AR).

[0076] In 3GPP Release 17, SA4 analyzed the XR business model as described in the 3GPP Technical Report TR 26.926 (v1.3.0-January 2023) entitled "Business Models and Quality Assessment Methods for Media and XR Services in 5G Systems" and summarized the QoS requirements in terms of delay budget, data rate and error rate required to obtain a satisfactory experience at the application level. This resulted in 4 additional 5QIs for 5GS XR QoS flows, such as the delay-critical GBR 5QI with values ​​of 87-90. These are described in the 3GPP Technical Specification TS 23.501 (v18.1.0-April 2023) entitled "System Architecture for 5G Systems (5GS)", and in particular in Table 5.7.4-1. The latter applies to XR video streams and the control metadata required to provide immersive and interactive XR experiences.

[0077] XR video services primarily consist of multiple DL / UL video streams with high resolution (e.g., typically at least 1080p binocular buffer), frames per second (e.g., 60+ fps), and high bandwidth (e.g., typically at least 20-30 Mbps). These streams need to be sent over the network with minimal latency (typically capped at 15-20 ms) to maintain reduced end-to-end application round-trip latency. The latter requirement is crucial given XR applications' reliance on cloud / edge processing (e.g., content download, viewport generation and configuration, viewport updates, viewport rendering, media encoding / transcoding, etc.).

[0078] The aforementioned immersive and interactive XR applications often require real-time transport architectures and protocols. As part of the latter, existing technologies include the Real-Time Transport Protocol (RTP, as defined in the IETF standard RFC 3550 - RTP: Transport Protocol for Real-Time Applications), its secure provisioning, the Secure Real-Time Transport Protocol (SRTP, as defined in the IETF standard RFC 3711 - Secure Real-Time Transport Protocol), and the web-oriented Web Real-Time Communication stack, WebRTC (defined by w3.org in WebRTC 1.0: Real-Time Communication between Browsers).

[0079] RTP is a media codec-independent network protocol with application layer frames for real-time delivery of multimedia (e.g., audio, video, etc.) data over IP networks. It is used in conjunction with its sister protocol for control, the 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 stream multiplexing.

[0080] Figure 4 An overview of the RTP and RTCP stacks is provided. The IP layer 405 carries signaling from the data plane 410 and from the control plane 450. The data plane 410 stack includes functionality for the User Datagram Protocol (UDP) 412, RTP 416, RTCP 414, media codecs 420, and quality control 422. The control plane 450 stack includes functionality for UDP 452, Transmission Control Protocol (TCP) 454, Session Initiation Protocol (SIP) 462, and Session Description Protocol (SDP) 464.

[0081] SRTP is a secure version of RTP and is defined by the IETF in RFC 3711 "Secure Real-time Transport Protocol (SRTP)". SRTP provides encryption (primarily through payload confidentiality), message authentication and integrity protection (through PDU, i.e. header and payload, signatures), and replay attack protection. Similar to RTP, the sister protocol of SRTP is SRTCP. This provides the same functionality as its RTCP counterpart. Therefore, in the plain SRTP version, the RTP header information remains accessible but cannot be modified, while the payload is encrypted. These security provisions are partially illustrated in Figure 3 In addition, the key exchange and additional security parameters required for the use of SRTP are based on the Datagram Transport Layer Security (DTLS) key exchange process. For these reasons, SRTP is used as the transport protocol for media in the WebRTC stack to ensure secure RTC multimedia communication through the web browser interface.

[0082] Figure 5The diagram shows an overview of the WebRTC stack. As shown, the IP layer 505 carries signaling from the data plane 510 and the control plane 550. The data plane stack 510 includes functions for the 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 SCTP 528. ICE 524 can use the Session Traversal Utilities for NAT (STUN) protocol and Traversal Using Relays Around NAT (TURN) to solve the problem of real-time media content delivery across heterogeneous networks and NAT rules and firewalls. The SCTP data plane 728 is primarily dedicated to application data channels and can be non-time-critical. The SRTP-based stack 517 and control elements (i.e., SRTCP 515), encoding (i.e., media codecs), and quality of service (QoS) (i.e., quality control) are dedicated to time-critical transmission. The control plane 550 stack includes functionality 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.

[0083] Figure 6a illustrates the packet format and header information for an RTP packet 630, and Figure 6b Illustrated is the packet format and header information for an SRTP packet 660. The individual fixed header information and the complete header information (including header extensions) for an RTP / SRTP packet are briefly summarized below.

[0084] The fixed header information includes: “V” 632, 662, “P” 633, 663, “X” 634, 664, “CC” 636, 666, “M” 638, 668, “PT” 640, 670, “Sequence Number” 642, 672, “Time Stamp” 644, 674, “Synchronization Source (SSRC) Identifier” 646, 676, and “Contribution Source (CSRC) Identifier” 648, 678.

[0085] "V" 632, 662 is 2 bits that indicate the protocol version used.

[0086] "P" 633, 663 is a 1-bit field that indicates the presence of one or more zero-padded octets at the end of the payload, where the padding is necessary for, among other things, fixed-size encryption blocks or for carrying multiple RTP / SRTP packets through lower layer protocols.

[0087] "X" 634, 664 is 1 bit, which indicates that the standard fixed RTP / SRTP header will be followed by an RTP header extension, which is usually associated with a specific data / profile that will carry more information about the data (for example, marking a frame for an RTP header extension for video data (as defined in IETF RFC 3711 - Secure Real-time Transport Protocol (SRTP)); or it will be a generic RTP header extension such as the RTP / SRTP Extension Protocol (as defined by w3.org in WebRTC 1.0: Real-time Communication between Browsers).

[0088] "CC" 636, 666 is a 4-bit field that indicates the number of contributing media sources (CSRC) following the fixed header.

[0089] "M" 638, 668 is 1 bit that is intended to mark an information frame boundary in a packet stream, the behavior of which is exactly specified by the RTP profile (e.g., H.264, H.265, H.266, AV1, etc.).

[0090] “PT” 640 , 670 is 7 bits that indicate the payload type, which in the case of a video profile is dynamic and negotiated through SDP (e.g., 96 for H.264, 97 for H.265, 98 for AV1, etc.).

[0091] "Sequence Number" 642, 672 is 16 bits that indicate a sequence number that is incremented by one for each RTP data packet sent through the session.

[0092] "Timestamp" 644, 674 is 32 bits, which indicates the timestamp of the payload type clock, reflecting the sampling moment of the first octet of the RTP data packet (associated with the video stream of the video frame), and the first timestamp of the first RTP packet is randomly selected.

[0093] "Synchronization Source (SSRC) Identifier" 646, 676 is a 32-bit field that indicates a random identifier of the source of an RTP packet stream forming part of the same timing and sequence number space so that a receiver can group packets based on the synchronization source for playback.

[0094] "Contributing Source (CSRC) Identifiers" 648, 678 is a list of up to 16 CSRC items, each 32 bits, the number of CSRCs mixed by the RTP mixer in the current payload being given, as signaled by the CC bits; the list identifies the contributing sources of the payload contained in this packet for the given contributing source's SSRC identifier.

[0095] The complete header information (including header extension) includes “RTP header extension” 648 , 678 .

[0096] "RTP Header Extension" 648, 678 is a variable length field that is present if X bits are 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 consists of the following fields:

[0097] A 16-bit extension identifier, defined by the profile and typically negotiated and determined via the Session Description Protocol (SDP) signaling mechanism;

[0098] A 16-bit length field that describes the length of the extension header in multiples of 32 bits, excluding the first 32 bits corresponding to the 16-bit extension identifier and the 16-bit length field itself; and

[0099] • A 32-bit aligned header extension raw data field, formatted according to some RTP header extension identifier specific format.

[0100] Figure 7 The RTP / SRTP header extension format and syntax 700 are shown. The RTP header extension format and syntax are similar to the SRTP header extension format and syntax. Figure 7 As shown, a draft of the format and syntax of these header extensions is generally provided. Furthermore, in both RTP and SRTP, only one RTP extension header can 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, according to RFC 8285: Generic Mechanism for RTP Header Extensions (rfc-editor.org), there are extensions to the base protocol that allow multiple RTP header extensions of predetermined types to be appended to the protocol's fixed header information.

[0101] In some embodiments, an RTP header extension generated at a source may be ignored by a destination endpoint that does not know how to interpret and process the RTP header extension sent by the source endpoint.

[0102] 3GPP technical standard version 18's study of XR media (XRM) at the CN level introduced the concept of PDU sets to handle the QoS requirements of XRM applications and flows with better granularity than is possible with QoS flows. Therefore, according to the 3GPP technical report TR 23.700-60 (v0.0.3), a PDU set consists of one or more PDUs that carry the payload of an information unit generated at the application level (e.g., a frame or video slice for an XRM service). In some implementations, the application layer requires all PDUs in the PDU set to use the corresponding information unit. In other implementations, when some PDUs are lost, the application layer can still recover some or all of the information units.

[0103] In addition, PDU sets are associated with QoS requirements in terms of delay budget and error rate, which can be defined as PDU set delay budget (PSDB) and / or PDU set error rate (PSER), as defined in 3GPP Technical Report TR 23.700-60 (v0.0.3-May 2022) entitled "XR (Extended Reality) and Media Services Research" and 3GPP Technical Specification TS 23.501 (v18.1.0-April 2023) entitled "System Architecture for 5G System (5GS)". The PDU set delay budget (PSDB) defines an upper limit on the time that a PDU set can be delayed at the UPF, between the UE and the N6 endpoint. The PSDB applies to DL PDU sets received by the UPF over the N6 interface and UL PDU sets sent by the UE, respectively. The PDU Set Error Rate (PSER) defines an upper limit on the rate at which a PDU set (e.g., the set of IP packets that make up a PDU set) is processed by the sender of a link layer protocol (e.g., RLC in a RAN with 3GPP access). The PSER can be used to determine an upper limit on the non-congestion-related packet loss rate.

[0104] Figure 8 The diagram shows an overview of the Core Network (CN) XRM architecture that processes PDU sets. Figure 8A system 800 is shown, which includes 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 include a remote unit 102, a user equipment device 200, a UE 1035, or 1135 as described herein. The UPF 840 may include a network element 104, a network node 300, or a user plane function (UPF) such as UPFs 1040 and 1140 as described herein. The operation of the system 800 will now be described in the example of downlink traffic, and similar operations may be used for uplink traffic.

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

[0106] At 881, the XRM application function 810 provides the QoS requirements of the packets of the PDU set in the packet and information identifying the application (i.e., 5-tuple or application ID) to the PCF 815. The QoS requirements may include PSDB and PSER. The XRM AF 810 may also include an importance parameter for the PDU set and information for the core network to identify the packets belonging to the PDU set.

[0107] At 882, the PCF 815 derives QoS rules for the XR application and specific QoS requirements for the PDU set, and configures the SMF 820. The QoS rules may use the 5G QoS identifier (5QI) for the XR media service. The PCF 815 sends the QoS rules to the SMF 820. The PCF 815 may include per-importance PCC rules for the PDU set in the communication to the SMF 820. The PCC rules may be derived based on information received from the XRM AF 810 or based on operator configuration.

[0108] At 883, the SMF 820 establishes a QoS flow based on the QoS rules of the PCF 815 and configures the UPF to route packets of the XR application to the QoS flow and, in addition, enables PDU set processing. The SMF 820 also provides the QoS profile containing the PDU set QoS requirements to the RAN 830 via the AMF 825. The AMF 825 may provide the QoS profile containing the PDU set QoS requirements to the RAN 830 in the N2 SM container. In addition, the AMF 825 may provide the QoS rules to the UE 835 in the N1 SM container.

[0109] At 884, the UPF 840 inspects the packets and determines the packets that belong to the PDU set. The packet inspection may include inspecting the RTP packets. When the UPF 840 detects the packets of the PDU set, the UPF 840 marks the packets that belong to the PDU set in the GTP-U header. The GTP-U header information includes the PDU set sequence number and the size of the PDU set. The UPF 840 may also determine the importance of the PDU set based on the UPF 840 implementation means, information provided by the XRM AF 810, or information provided as metadata from the XRM application server. Based on the importance of the PDU set, the UPF 840 may route the service to the corresponding QoS flow 1 (according to the rules received from the SMF 820), or include the importance of the PDU set in the GTP-U header. QoS flow 1 may include GTP-U headers, and these headers may include PDU set information.

[0110] At 885, the RAN 830 identifies packets belonging to the PDU set (based on the GTP-U marking) and processes 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 a 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 non-PDU set packets. The RAN 830 may receive the QFI, the QoS profile of the QoS flow, from the SMF 820 (via the AMF 825) during the PDU session establishment / modification including the PDSB and PSER. The RAN 830 inspects the GTP-U header and ensures that all packets of the same PDU set are processed according to the QoS profile. This may include packets of the PDU set in a radio bearer carrying QoS Flow 1. This may also include sending packets that do not belong to the PDU set in a different radio bearer carrying QoS Flow 2.

[0111] The above examples relate to downlink (DL) traffic. Reciprocal processing applies to uplink (UL) traffic, where the role of UPF 840 packet inspection is assumed by the UE 835, which is expected to inspect the uplink packets, determine the packets belonging to a PDU set, and accordingly signal the PDU set to the RAN 830 for scheduling and resource allocation corresponding to the associated DRBs that can meet the PDU set QoS requirements (i.e., PSDB and PSER). The low-level signaling mechanisms associated with the UL UE to RAN information transfer depend on the specification and implementation of the RAN signaling procedures.

[0112] Figures 9a to 9dA 5GS PDU set-aware QoS processing framework description of PDU set to QoS flow to DRB mapping is illustrated. Depending on the QoS flow mapping and RAN procedures, there may be several alternative PDU set to QoS flow to DRB mappings given two different PDU sets with different PDU set attributes (such as PDU set importance). Figure 9 illustrates some options, where two PDU sets 910 with different importance and characteristics are mapped to QoS flows 920 and data radio bearers (DRBs) 930, respectively. In this example, consider that PDU set 1 has high importance and has strict QoS requirements (i.e., PSDB, PSER, etc.), and PDU set 2 has low importance and potentially has lower QoS requirements than PDU set 1 (i.e., PSDB, PSER, etc.). As shown in Figure 9, depending on the QoS flow policy and layer 2 RAN procedures, the PDU sets 910 to QoS flows 920 to DRBs 930 may take the following instances:

[0113] Figure 9a A 1-to-1-to-1 mapping is illustrated where the separation of QoS flows 920 and DRBs 930 is done between high importance PDU sets 910 and low importance PDU sets 910, thereby finely optimizing radio and network resources on a per PDU set basis.

[0114] Figure 9b An M-to-M-to-1 mapping is illustrated: where the separation between the high-importance PDU set 910 and the low-importance PDU set 910 is performed only at the QoS flow level, and the same DRB 930 is used for over-the-air transmission of both PDU sets 910, which may result in over-provisioning of radio resources for the low-importance PDU set 910, but requires lower RAN complexity and management overhead.

[0115] Figure 9c An M-to-1-to-1 mapping is illustrated: there is no separation between QoS flows 920 and DRBs 930 for PDU sets 910 of different importance, and when handling QoS management across both CN and RAN, priority is given to QoS requirements of PDU sets of higher importance; this may result in over-provisioning 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.

[0116] Figure 9d An M-to-1-to-M mapping is illustrated: where there is no separation of QoS flows 920 between PDU set importance levels, but different DRBs 930 are used to meet the individual requirements of different importance levels; this reduces the complexity of QoS flow management, and uses PDU set information to filter PDU sets 910 on different DRBs 930 to better match RAN level QoS requirements and optimize resource allocation based on individual PDU set needs.

[0117] The determination of PDU sets is a prerequisite for controlling the flow of PDU sets through 5GS and implicitly controlling the QoS flow to DRB mapping within the 5GS framework. Therefore, to support QoS processing based on PDU sets, the PDU Session Anchor (PSA) UPF identifies the PDUs belonging to the PDU set and determines the PDU set information it sends to the NG-RAN in the GTP-U header. As mentioned above, the PDU set information is used by the NG-RAN for QoS processing based on PDU sets.

[0118] PDU set information includes:

[0119] PDU Set Sequence Number (PSSN).

[0120] Indication of the end PDU (E) of the PDU set.

[0121] The PDU sequence number (PSN) within the PDU set.

[0122] • PDU Set Size (PSS) in bytes.

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

[0124] The RAN lower layers can also utilize the PDU set importance marked within a QoS flow for PDU set level packet discarding in the presence of congestion on the radio air interface. In addition, the interrelationships between PSIs across multiple QoS flows can be considered.

[0125] The SMF instructs the PSA UPF to perform PDU set marking and may provide the PSA UPF with a protocol description provided by a 5-tuple (i.e., a tuple consisting 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). The 5-tuple or application ID indicates 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 a PCC rule based on information provided by the AF or by a PCF local policy.

[0126] Thus, the PSA UPF may identify the PDU set information on the RTP header extension for PDU set information using the protocol description and the received RTP / SRTP header (indicated by the UPF), (e.g., as described in U.S. Provisional Patent Application 63 / 428,026 filed on November 25, 2022 [Applicant No.: SMM920220198-US-PSP], which is incorporated herein by reference). Alternatively, the PSA UPF may identify the PDU set information by using UPF implementation-specific means (e.g., as described in PCT application PCT / EP2022 / 077327 filed on September 30, 2022 [Applicant No.: SMM920220109-GR-NP], which is incorporated herein by reference), wherein at least the RTP / SRTP timestamp, synchronization source identifier, and M-bit frame end marker are used to determine the boundaries of the PDU set, and the PDU set size is used to determine the PDU set importance based on the available application service and codec configuration information. Therefore, for each DL PDU received from the SMF on N6 (for which PDU set based QoS treatment is indicated), the PSA UPF applies the rules for the PDU set identification and provides the PDU set information available to the RAN in the GTP-U header.

[0127] However, the currently defined architecture lacks the technical details needed to address QoS flows that must transport both PDU set marked traffic and non-PDU set marked traffic. There are multiple possible scenarios: Figure 10 Scenario 1 (different AF sessions) is illustrated in FIG; and Figure 11 Scenario #2 (same AF session) is illustrated in FIG.

[0128] Scenario #1 involves different AF sessions. A QoS flow established using the PDU set QoS parameter configuration (e.g., via the Nnef_AFsessionWithQoS service) can also satisfy the QoS requirements of another AF session (whether or not belonging to the same XR application) that has a similar PDB and PER as the PDUs included in the PDU set. In this case, the operator's general policies and PCC rules can allocate PDU set-tagged PDUs and non-PDU set-tagged PDUs on the same QoS flow.

[0129] Figure 10 The diagram illustrates an example of a scenario comprising different AF sessions for XR video applications and non-XR applications, which are multiplexed by 5GS on the same QoS flow under the current PCF policy and PCC rules, i.e., QoS flow 1 that meets both the PSDB and PSER requirements for XR service traffic with PDU set marking, and the PDB and PER for non-XR service traffic with non-PDU set marking.

[0130] Figure 10 Scenario #1 is illustrated, which represents two different AF sessions combining PDU set-tagged PDUs and non-PDU set-tagged PDUs on a QoS flow with the same QoS parameters. The illustrated system 1000 includes a PCF 1015, an SMF 1020, a UPF 1040, a RAN 1030, a UE 1035, an XR video application 1045, and a non-XR video application 1047. The UE 1035 may include a remote unit 102, a user equipment device 200, a UE 835, or 1135 as described herein. The UPF 1040 may include a network element 104, a network node 300, or a user plane function (UPF) such as UPF 840 and 1140 as described herein. The XR video application 1045 sends I frames as multiple PDUs, which are grouped to form PDU sets. The XR video application 1045 also sends P frames as multiple PDUs, which are also grouped to form PDU sets. The non-XR application 1047 sends other data as multiple PDUs, which are grouped to form additional PDU sets. The UPF 1040 is arranged to receive PDUs from both the XR video application 1045 and the non-XR video application 1047 and send the PDUs (with QoS flows required by PDSB / PSER) to the RAN 1030. The UPF 1040 includes PDU set information for the PDUs from the XR video application 1045. The UPF 1040 does not include PDU set information for the PDUs from the non-XR application 1047. The RAN 1030 sends the PDUs to the UE 1035 via the Uu radio bearer.

[0131] Scenario #2 involves the same AF session. QoS flows established with PDU set QoS parameter configuration (e.g., via the Nnef_AFsessionWithQoS service) can be exposed to both PDU set tagged and non-PDU set tagged services. For example, this may occur in the case of a WebRTC service, where multiple media streams are multiplexed on a single RTP stream provided through one AF session instance. Alternatively, this may also happen with media streams belonging to the same XR application (i.e., sharing an application ID), which are mapped to the same QoS stream given their 5-tuple and QoS requirements. For example, multiple camera capture systems for 360 degree surround video, or alternatively at least two cameras for 2D+depth video information, may be used concurrently on different RTP streams. In any of these examples, a common use case is that at least one of the media streams does not contain a PDU set tag. In an example, this may be because the PDU set may not support a specific video codec specification (e.g., VP8, VP9, ​​AV1), a specific audio codec specification (e.g., OPUS), a specific multimedia codec specification (e.g., haptic codec), or alternatively any multimedia codec specification other than video (e.g., audio codec, haptic codec, etc.).

[0132] Figure 11 An example scenario is illustrated that includes the same AF session for an XR application provided over WebRTC, where audio (e.g., OPUS encoded bitstream) and video (e.g., H.264 Constrained Baseline encoded bitstream) are sent in a multiplexed manner on one RTP stream for the XR application.

[0133] Figure 11Scenario #2 is illustrated, which represents one AF session multiplexing PDUs with PDU set marking and non-PDU set marking on a QoS flow with the same QoS parameters. The illustrated system 1100 includes a PCF 1115, an SMF 1120, a UPF 1140, a RAN 1130, a UE 1135, and an XR video application 1145. The XR video application 1145 includes a WebRTC application. The UE 1135 may include a remote unit 102, a user equipment device 200, a UE 835, or 1035 as described herein. The UPF 1140 may include a network unit 104, a network node 300, or a user plane function (UPF) such as UPF 840 and 1040 as described herein. The XR video application 1145 sends an I frame as multiple PDUs, which are grouped to form a PDU set. The XR video application 1145 also sends P frames as multiple PDUs, which are also grouped to form PDU sets. The XR application 1145 also sends non-video frame information as multiple PDUs, which are grouped to form additional PDU sets. For example, non-video frame information may include audio OPUS codec and / or AR metadata that are not marked with PDU set information. The UPF 1140 is arranged to receive PDUs from the XR video application 1145 and send PDUs (with QoS flows required by PDSB / PSER) to the RAN 1130. The UPF 1140 includes PDU set information for PDUs including video information from the XR video application 1145. The UPF 1140 does not include PDU set information for PDUs related to non-video frame information from the XR video application 1145. The RAN 1130 sends the PDUs to the UE 1135 via the Uu radio bearer.

[0134] References Figure 10 and Figure 11 The two scenarios described show that on a DRB mapped to a QoS flow for XR applications with the PDU Set feature enabled, the RAN may receive a mix of packets, i.e., some of them are marked with PDU Set information and some of them are not. The packets not marked with PDU Set information (i.e., PDUs) may be referred to as "legacy packets." Nevertheless, these legacy packets are still processed under the same QoS characteristics of the QoS flow (i.e., at least PSDB, PSER, PER, and PDB, respectively). Consequently, RAN complexity increases as packets belonging to the same QoS flow require different radio resource processing and scheduling.

[0135] In addition, 3GPP RAN has decided to Figure 9dThe mapping M-1-M shown is taken from the scope of another standard specification to eliminate this complexity at the lower layers in 5GS, where packets for a QoS flow are split across multiple DRBs. Therefore, different treatment of packets for the same QoS flow at the radio level is currently not possible. Therefore, QoS policies and PDU set marking features within 5GS also need to alleviate this issue while keeping complexity low at the RAN level and achieving a good complexity-performance tradeoff at the system level.

[0136] This paper proposes a solution to these problems, in which a strategy is introduced to handle XR application services and the PDU set feature is supported in the above two scenarios.

[0137] This document describes the unified handling of both marked and unmarked PDU set packets when they are mapped to appropriate QoS flows established to support the PDU set QoS requirements requested by third-party applications. The current protocol is to enhance existing QoS flows (with legacy QoS requirements, such as PDB) to support the QoS requirements of PDU sets (PDU set delay budget, PDU set error rate). If both packets marked with PDU set information and unmarked packets are sent via such a QoS flow, the complexity at the RAN increases because the RAN will need to provide scheduling resources for the PDUs of the PDU set based on the PDU set delay budget (PDSB) and for the unmarked PDU set packets based on the legacy PDB of the QoS flow, where the PDSB value is higher than the legacy PDB. The solution proposed in this document includes implementing a policy whereby a QoS flow enabled with PDU set marking must mark all PDUs in the downlink direction with PDU set information when it is ingested into the 5GS through the UPF via the N6 interface. This policy results in that a QoS flow enabled with PDU set marking will always contain only packets marked with PDU set information.

[0138] The mandatory policy can be stated as "For any packet in the downlink direction that is determined based on SMF instructions to be sent via a QoS flow with a PDU Set Information marking, the UPF shall include the PDU Set Information within the GTP-U header."

[0139] Some examples of this policy and its representation within the 5GS are presented herein. These are example instances of the policy and should not be considered in any way as limiting the core intent of the policy.

[0140] For example, the policy may include ensuring that a QoS flow with a PDU set requirement only includes packets marked with PDU set information. In such an arrangement, the UPF receives N4 rules from the SMF. The N4 rules include information that helps the UPF identify how packets received in the downlink direction need to be routed on an established QoS flow and whether PDU set information needs to be added for any packets sent on a QoS flow with a specific PDU set QoS requirement.

[0141] The SMF determines the N4 rules based on the PCC rules provided by the PCF. The PCF determines the PCC rules based on the PDU set QoS requirements of the application user plane session (AF session) to the UE via the 3GPP network provided by the application function.

[0142] The AF session PDU set QoS requirements include the PDU set delay budget, PDU set error rate, and PDU set integrated processing indicator (PSIHI), as described in section 5.7.7 of 3GPP TS 23.501 (v18.1.0-April 2023), entitled "System Architecture for 5G System (5GS)". In addition, the AF provides a protocol description that indicates the protocol (e.g., RTP / SRTP) and payload type (e.g., H.264) used by the service data flow that needs to support the specific PDU set QoS requirements on the 3GPP network.

[0143] When the UPF receives a packet in the downlink direction (over the N6 reference point), the UPF checks whether the packet matches any of the N4 rules provided by the UE's PCF / SMF.

[0144] If the UPF determines that a PDU set check needs to be performed on a received packet in the downlink direction (based on the N4 rule), the PSA UPF may use the protocol description and the received RTP / SRTP header or use implementation specific means to identify the PDU set information. The UPF then determines and adds all or some combination of the following information when the packet is sent to the NG-RAN within the GTP-U header:

[0145] PDU set sequence number.

[0146] Indication of the end PDU of a PDU set.

[0147] The PDU sequence number within the PDU set.

[0148] The PDU set size in bytes.

[0149] • PDU Set Importance, which identifies the relative importance of a PDU Set within a QoS Flow compared to other PDU Sets.

[0150] If a packet received in the downlink direction matches the protocol description in rule N4, two additional options need to be considered:

[0151] Option 1: The received packet may not have any additional RTP header extension including PDU set information (e.g., PDU set size). In this scenario, the UPF determines the PDU set information based on its implementation.

[0152] Option 2: Some received packets include an RTP header extension with additional information containing PDU set information provided by the application server. In this scenario, the UPF must include the information contained in the RTP header extension in the corresponding information in the PDU set information in the GTP-U header. Here, it is recommended that if the received packet does not have any PDU set information in the RTP header extension, the UPF include the PDU set information in the GTP-U header for each packet (PDU) when the packet is sent to the NG-RAN.

[0153] If a packet received in the downlink direction does not match the protocol description in the N4 rule, but the N4 rule includes an indication to perform a PDU set check, then for each received packet that does not match the protocol description, the UPF includes the default PDU set information within the GTP-U header when the packet is sent to the NG-RAN, instead of the UPF sending an untagged packet / PDU on a QoS flow with a PDU set QoS requirement. In this case, the size of the PDU set will correspond to the size of the received packet.

[0154] Accordingly, a user plane function (UPF) is provided, the UPF comprising a processor and a memory coupled to the processor, the memory containing instructions that, when executed by the processor, cause the UPF to: receive a protocol data unit (PDU) in a downlink direction, the received PDU being subject to PDU set processing according to configuration information received from a session management function (SMF), wherein the configuration information includes a protocol description; and determine whether: the received PDU does not match all components of the configuration information received from the SMF; or whether the received PDU does match the protocol description of the configuration information, but the received PDU is not part of the PDU set. The UPF is further caused to create a header for the received PDU, the header including PDU set information, if either: the received PDU does not match all components of the configuration information received from the SMF; or the received PDU does match the protocol description of the configuration information, but the received PDU is not part of the PDU set. The processor is further caused to route the received PDU and the header to a radio access network.

[0155] The received PDU may be a PDU belonging to a PDU set. The method may be suitable for routing packets on a QoS flow according to a PDU set requirement. The PDU set requirement may be defined by PDU set control information. The radio access network may include an NG-RAN. The radio access network may include a 5GS.

[0156] The methods and apparatus described herein tend to improve the marking of PDUs in the downlink direction. To ensure normal operation of the radio access network, all PDUs in the downlink direction should be marked with PDU set information when a QoS flow with PDU set marking is ingested into the radio access network.

[0157] The protocol description may indicate PDU set handling. The received PDU may also include at least one protocol extension header. The protocol extension header may contain PDU set information.

[0158] The PDU and header are routed to a radio access network. The radio access network may include an NG-RAN. The received PDU may be sent to the NG-RAN via the GTP-U protocol. The header may be a GTP-U header. The received PDU may be sent to the NG-RAN, and the PDU set information may be included in the GTP-U header of the GTP-U protocol PDU set information.

[0159] The processor can also be arranged to cause the UPF to: determine whether the received PDU includes a protocol extension header; determine whether the protocol extension header includes PDU set information; and if the received PDU includes a protocol extension header and if the protocol extension header does not include PDU set information, the processor is also arranged to include the PDU set information in the header.

[0160] The processor may also be arranged to cause the UPF to determine whether the received PDU includes a protocol extension header; and if the received PDU does not include a protocol extension header, the processor may be further arranged to cause the UPF to determine whether the PDU is part of a PDU set based on implementation.

[0161] If the PDU is not part of a PDU set, the processor may further be arranged to cause the UPF to: create a header for the received PDU. Configuration information may be received from the SMF in rule N4. The received PDU may be received in the downlink direction via N6. The header may include PDU set information including the PDU set size. The protocol description may include information on the protocol and payload type contained within the received PDU.

[0162] The processor may be further arranged to cause the UPF to: determine whether the received PDU does not include the PDU set information; and if the received PDU does not include the PDU set information, create a header to include the PDU set information.

[0163] A protocol description can be provided to a PDU by an application function. The protocol description can indicate the protocol and payload type. The protocol can include, for example, RTP or SRTP. The payload type can include, for example, H.264. The protocol and payload type can be used by a service data flow. A service data flow can support a specific set of PDU QoS requirements on a 3GPP network.

[0164] The PDU set information included in the header may include at least one of the following: a PDU set sequence number; an indication of the last PDU of the PDU set; a PDU sequence number within the PDU set; a PDU set size in bytes; and PDU set importance. The PDU set importance may identify the relative importance of the PDU set compared to other PDU sets within the QoS flow.

[0165] Figure 12 A method 1200 performed by a user plane function (UPF) is illustrated, the method 1200 comprising: receiving 1210 a protocol data unit (PDU) in a downlink direction, the received PDU being subject to PDU set processing according to configuration information received from a session management function (SMF), wherein the configuration information includes a protocol description; and determining 1220 whether the received PDU does not match all components of the configuration information received from the SMF; or whether the received PDU does match the protocol description of the configuration information, but the received PDU is not part of the PDU set. The method 1200 also comprises creating 1230 a header for the received PDU, the header including PDU set information, if either: the received PDU does not match all components of the configuration information received from the SMF; or the received PDU does match the protocol description of the configuration information, but the received PDU is not part of the PDU set. The method 1200 also comprises routing 1240 the received PDU and the header to a radio access network.

[0166] In some embodiments, the method 1200 may be performed by a processor that executes program code, such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, or the like.

[0167] The received PDU may be a PDU belonging to a PDU set. The method may be suitable for routing packets on a QoS flow according to a PDU set requirement. The PDU set requirement may be defined by PDU set control information. The radio access network may include an NG-RAN. The radio access network may include a 5GS.

[0168] This method tends to improve the marking of PDUs in the downlink direction. To ensure normal operation of the radio access network, all PDUs in the downlink direction should be marked with PDU set information when a QoS flow with PDU set marking is ingested into the radio access network.

[0169] The protocol description may indicate PDU set handling. The received PDU may also include at least one protocol extension header. The protocol extension header may contain PDU set information.

[0170] The PDU and header are routed to a radio access network. The radio access network may include an NG-RAN. The received PDU may be sent to the NG-RAN via the GTP-U protocol. The header may be a GTP-U header. The received PDU may be sent to the NG-RAN, and the PDU set information may be included in a GTP-U header of the GTP-U protocol PDU set information.

[0171] The method may further include determining whether the received PDU includes a protocol extension header; determining whether the protocol extension header includes PDU set information; and including the PDU set information in the header if the received PDU includes the protocol extension header and if the protocol extension header does not include the PDU set information.

[0172] The method may further include determining whether the received PDU includes a protocol extension header; and if the received PDU does not include a protocol extension header, determining based on implementation whether the PDU is part of a PDU set.

[0173] If the PDU is not part of a PDU set, the method may further include creating a header for the received PDU.

[0174] Configuration information may be received from the SMF in rule N4. The received PDU may be received in the downlink direction via N6. The header may include PDU set information including the PDU set size. The protocol description may include the protocol and payload type of the information contained within the received PDU.

[0175] The method may further include determining whether the received PDU does not include the PDU set information; and creating a header to include the PDU set information if the received PDU does not include the PDU set information.

[0176] A protocol description can be provided to a PDU by an application function. The protocol description can indicate the protocol and payload type. The protocol can include, for example, RTP or SRTP. The payload type can include, for example, H.264. The protocol and payload type can be used by a service data flow. A service data flow can support a specific set of PDU QoS requirements on a 3GPP network.

[0177] The PDU set information included in the header may include at least one of the following: a PDU set sequence number; an indication of the last PDU of the PDU set; a PDU sequence number within the PDU set; a PDU set size in bytes; and PDU set importance. The PDU set importance may identify the relative importance of the PDU set compared to other PDU sets within the QoS flow.

[0178] Therefore, this paper proposes a method for the UPF to perform a PDU set check when the received packets in the downlink direction do not match the protocol description in the N4 rule. This paper also proposes a method for the UPF to perform a PDU set check when the received packets in the downlink direction match the protocol description in the N4 rule, but some received packets do not contain PDU set information in the RTP header extension.

[0179] Enhance existing QoS flows (with legacy QoS requirements, such as PDB) to support the QoS requirements of PDU sets (PDU set delay budget, PDU set error rate). The problem with this arrangement is that if both packets marked with PDU set information and unmarked packets are sent via such a QoS flow, the complexity at the RAN increases because the RAN will need to provide scheduling resources for the PDUs of the PDU set based on the PDU set delay budget (PDSB), and provide scheduling resources for the unmarked PDU set packets based on the legacy PDB of the QoS flow, where the PDSB value is higher than the legacy PDB.

[0180] This paper proposes a solution that includes implementing a policy whereby a QoS flow enabled with PDU set marking must mark all PDUs in the downlink direction with PDU set information when ingested into the 5GS via the UPF via the N6 interface. This policy requires that a QoS flow enabled with PDU set marking will always contain only packets marked with PDU set information.

[0181] This solution tends to improve existing arrangements, i.e., the UPF can use proprietary implementation means to determine the PDU set information for any received packet that matches the protocol description. Any packet that does not match the protocol description needs to be sent by the UPF through an unmarked QoS flow, which increases the complexity at the RAN.

[0182] This document provides a PDU set check process by the UPF in the case where the received packets in the downlink do not match the protocol description in the N4 rule. This document also provides a PDU set check process by the UPF in the case where the received packets in the downlink direction match the protocol description in the N4 rule, but some of the received packets do not contain PDU set information in the RTP header extension.

[0183] A received packet may not match the protocol description. A method is provided herein in which a UPF determines that a packet is to be routed on a QoS flow with a PDU set requirement and applies a PDU set check for PDUs received in a downlink direction (over N6) according to configuration information received from an SMF, wherein the configuration information includes a protocol description; determines to include PDU set information for any received PDU that does not match all components of the configuration information received from the SMF; and routes the received PDU to the NG-RAN and includes the PDU set information including the PDU set size within a GTP-U header.

[0184] The configuration information received from the SMF may be included in the N4 rule. The protocol description may include the protocol and payload type of the information contained in the received PDU. If the received PDU does not contain the protocol and payload type information according to the protocol description in the configuration information received from the SMF, the UPF may determine to include the PDU set information.

[0185] A method is also provided in which the UPF determines that a packet is to be routed on a QoS flow with a PDU set requirement, and applies a PDU set check to PDUs received in the downlink direction (via N6) according to configuration information received from the SMF, wherein the configuration information includes a protocol description; determines to include PDU set information for any received PDU that matches the protocol description of the configuration rule, but the received PDU does not include PDU set information within a protocol extension header; and routes the received PDU to the NG-RAN and includes PDU set information including the PDU set size within GTP-U header information. The configuration information received from the SMF may be included in the N4 rule.

[0186] It should be noted that the above-described methods and apparatus illustrate rather than limit the present 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, and "a" or "an" does not exclude a plurality, and a single processor or other unit may perform the functions of several units recited in a claim. Any reference signs in a claim should not be construed as limiting its scope.

[0187] Furthermore, while examples have been given in the context of specific communication standards, these examples are not intended to limit the communication standards to which the disclosed methods and apparatus may be applied. For example, while specific examples have been given in the context of 3GPP, the principles disclosed herein may also be applied to other wireless communication systems, and indeed any communication system that uses routing rules.

[0188] 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), etc., causes the processor to perform the above-described method.

[0189] 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 present invention is therefore indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalence of the claims are intended to be included within their scope.

[0190] The following abbreviations are relevant to the areas covered 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; DL, downlink; NAL, network abstraction layer; 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.

Claims

1. A user plane function (UPF), comprising: at least one memory; as well as at least one processor coupled to the at least one memory and configured to cause the UPF to: receiving protocol data units (PDUs) in a downlink direction, the received PDUs being subject to PDU set processing according to configuration information received from a session management function (SMF), the configuration information including a protocol description; determining whether the received PDU does not match all components of the configuration information received from the SMF, or whether the received PDU does match the protocol description of the configuration information and the received PDU is not part of a PDU set; If the received PDU does not match all the components of the configuration information received from the SMF, or if the received PDU does match the protocol description of the configuration information and the received PDU is not part of the PDU set, creating a header for the received PDU, the header including PDU set information; as well as The received PDU and the header are routed to a radio access network.

2. The UPF of claim 1 , wherein the at least one processor is configured to cause the UPF to: determining whether the received PDU includes a protocol extension header; determining whether the protocol extension header includes the PDU set information; as well as If the received PDU includes the protocol extension header and if the protocol extension header does not include the PDU set information, the PDU set information is included in the header.

3. The UPF of claim 1 , wherein the at least one processor is configured to cause the UPF to: determining whether the received PDU includes a protocol extension header; and If the received PDU does not include the protocol extension header, determining whether the PDU is part of the PDU set is based at least in part on an implementation.

4. The UPF of claim 3, wherein if the received PDU is not part of the PDU set, the at least one processor is configured to cause the UPF to: create the header for the received PDU.

5. The UPF of claim 1, wherein the header includes the PDU set information including a PDU set size.

6. The UPF of claim 1 , wherein the protocol description comprises: The protocol and payload type of the information contained in the received PDU.

7. The UPF of claim 1 , wherein the at least one processor is configured to cause the UPF to: determining whether the received PDU does not include the PDU set information; and If the received PDU does not include the PDU set information, the header is created to include the PDU set information.

8. The UPF of claim 1, wherein the protocol description is provided to the PDU by an application function.

9. The UPF of claim 1, wherein the protocol description indicates a protocol and a payload type.

10. The UPF according to claim 1, wherein the PDU set information included in the header includes at least one of the following items: PDU set sequence number; an indication of the last PDU of the PDU set; The PDU sequence number in the PDU set; PDU set size in bytes; or PDU set importance.

11. A method performed by a user plane function (UPF), the method comprising: receiving protocol data units (PDUs) in a downlink direction, the received PDUs being subject to PDU set processing according to configuration information received from a session management function (SMF), wherein the configuration information includes a protocol description; determining whether the received PDU does not match all components of the configuration information received from the SMF, or whether the received PDU does match the protocol description of the configuration information and the received PDU is not part of a PDU set; If the received PDU does not match all the components of the configuration information received from the SMF, or if the received PDU does match the protocol description of the configuration information and the received PDU is not part of the PDU set, creating a header for the received PDU, the header including PDU set information; as well as The received PDU and the header are routed to a radio access network.

12. The method according to claim 11, further comprising: determining whether the received PDU includes a protocol extension header; determining whether the protocol extension header includes the PDU set information; as well as If the received PDU includes the protocol extension header and if the protocol extension header does not include the PDU set information, the PDU set information is included in the header.

13. The method according to claim 11, further comprising: determining whether the received PDU includes a protocol extension header; as well as If the received PDU does not include the protocol extension header, determining whether the PDU is part of the PDU set is based at least in part on an implementation.

14. The method of claim 13, wherein if the received PDU is not part of the PDU set, the method further comprises creating the header for the received PDU.

15. The method of claim 11, wherein the header includes the PDU set information including a PDU set size.

16. The method of claim 11, wherein the protocol description comprises: The protocol and payload type of the information contained in the received PDU.

17. The method according to claim 11, further comprising: determining whether the received PDU does not include the PDU set information; as well as If the received PDU does not include the PDU set information, the header is created to include the PDU set information.

18. The method of claim 11, wherein the protocol description is provided to the PDU by an application function.

19. The method according to claim 11, wherein the PDU set information included in the header includes at least one of the following: PDU set sequence number; an indication of the last PDU of the PDU set; The PDU sequence number in the PDU set; PDU set size in bytes; or PDU set importance.

20. A processor for wireless communication, comprising: at least one controller coupled to the at least one memory and configured to cause the processor to: receiving protocol data units (PDUs) in a downlink direction, the received PDUs being subject to PDU set processing according to configuration information received from a session management function (SMF), the configuration information including a protocol description; determining whether the received PDU does not match all components of the configuration information received from the SMF, or whether the received PDU does match the protocol description of the configuration information and the received PDU is not part of a PDU set; If the received PDU does not match all the components of the configuration information received from the SMF, or if the received PDU does match the protocol description of the configuration information and the received PDU is not part of the PDU set, creating a header for the received PDU, the header including PDU set information; as well as The received PDU and the header are routed to a radio access network.

Images