PDU set definition in wireless communication network

Abstract

A method is provided that includes receiving a QoS rule configuration of QoS requirements for an XR application, and applying the received QoS rule configuration to a packet filter. The method also includes processing a plurality of packet data units (PDUs) of the XR application with a packet filter. The method further includes determining a plurality of PDU sets, wherein each PDU set groups a sequence of one or more PDUs encapsulating an information unit of the XR application; and transmitting the plurality of PDU sets to a radio access network, wherein the specific QoS rule configuration is applied to each PDU in the PDU sets.

Description

Technical Field

[0001] The subject matter disclosed herein generally relates to the field of implementing PDU set definition in a wireless communication network.This document defines methods and nodes in a wireless communication network. Background Art

[0002] Herein, extended reality (XR) is used as an umbrella term for different types of reality, of which virtual reality, augmented reality, and mixed reality are examples.

[0003] XR application services are subject to strict bandwidth and latency constraints in order to provide appropriate quality of service and quality of experience to end users of XR services. Such strict bandwidth and latency constraints may make the delivery of XR application services over wireless communication networks challenging. Summary of the invention

[0004] In the context of XR media services, the 3GPP SA2 working group recently introduced the concept of "PDU sets" to group a series of PDUs that carry information units at the application level. Therefore, each PDU within a PDU set can be processed according to the same set of QoS requirements and associated constraints on delay budget and error rate, while providing support to the RAN 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-rate transmission with a short delay budget).

[0005] Two problems arise from this latter activity. On the one hand, determining the PDU sets and the PDUs that compose them, i.e. identifying the PDU set boundaries, and on the other hand, classifying the PDU set importance levels necessary to map them to QoS requirements and associate them with QFIs and DRBs. These problems need to be solved efficiently in real time with low signaling / control overhead to enable the performance benefits based on the PDU set concept.

[0006] A solution is proposed herein to the problem of determining the boundaries of a PDU set based on a reference XR protocol stack and its deployment within a 5GS or similar wireless communication system that combines a core network (CN) and a RAN for accessing and communicating with a data network (DN) hosting XR specific applications (e.g., XR messaging, CG gaming, XR conferencing, XR streaming, etc.). A solution is also provided for determining the importance of a PDU set.

[0007] Disclosed herein is a process for PDU set definition in a wireless communication network. The process may be implemented by a method and a node in a wireless communication network.

[0008] Therefore, a method is provided, which includes receiving a QoS rule configuration of a QoS requirement of an XR application, and applying the received QoS rule configuration to a packet filter. The method also includes processing multiple packet data units (PDUs) of the XR application using the packet filter. The method also includes determining multiple PDU sets, each PDU set grouping a sequence of one or more PDUs that encapsulate an information unit of the XR application; and sending multiple PDU sets to a radio access network, wherein a specific QoS rule configuration is applied to each PDU in the PDU set.

[0009] A node in a wireless communication network is also provided, the node comprising: an interface and a processor. The interface is arranged to receive a QoS rule configuration of the QoS requirements of an XR application. The processor is arranged to: apply the received QoS rule configuration to a packet filter; process multiple packet data units (PDUs) of the XR application using the packet filter; and determine multiple PDU sets, wherein each PDU set groups a sequence of one or more PDUs that encapsulate an information unit of the XR application. The interface is also arranged to send multiple PDU sets to a radio access network, wherein a specific QoS rule configuration is applied to each PDU in the PDU set. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to describe the manner in which the advantages and features of the present disclosure can be obtained, the description of the present disclosure is presented 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 of the present disclosure. For clarity, the drawings may have been simplified and are not necessarily drawn to scale.

[0011] A method and apparatus for PDU set definition 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 Embodiments of a wireless communication system for PDU set definition in a wireless communication network are described;

[0013] Figure 2 depicting a user equipment device;

[0014] Figure 3 further details of the network nodes are depicted;

[0015] Figure 4 illustrates the method presented in this article;

[0016] Figure 5 An overview of the core network XRM architecture for processing PDU aggregation is shown;

[0017] Figure 6 Provides an overview of the RTP and RTCP stacks;

[0018] Figure 7 Diagram showing an overview of the WebRTC stack;

[0019] Figure 8 illustrates the packet format and header information for both RTP packets and SRTP packets;

[0020] Fig. 9 illustrates a PDU aggregation packet filter including hierarchical processing;

[0021] Fig.10 illustrates the application of packet filtering in XRM services across 5GS in both DL and UL;

[0022] Fig.11 is an illustration of applying a level 0 processing PDU aggregate packet filter to an RTP stream (RTP stream) that carries a payload of a video coded bit stream and is mapped to a PDU aggregate;

[0023] Fig.12 illustrates the application of level 0 and level 1 filtering processes to a PDU stream; and

[0024] Fig.13 is an illustration of at most level 2 processing applying a PDU aggregation packet filter to an RTP stream carrying a payload of a video coded bitstream. DETAILED DESCRIPTION

[0025] Those skilled in the art will appreciate that aspects of the present disclosure may be embodied as systems, devices, methods or program products. Therefore, the arrangements described herein may be implemented in full hardware form, full software form (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, etc. 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] In addition, the method 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 a signal. In some arrangements, the storage device employs only a signal 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 of the foregoing.

[0029] More specific examples of storage devices (a non-exhaustive list) include: an electrical connection having one or more conductors, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. 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 conjunction with an instruction execution system, apparatus, or device.

[0030] Throughout this specification, references to examples or similar language of a particular method or device mean that the specific features, structures or characteristics described in conjunction with the example are included in at least one implementation of the methods and devices described herein. Therefore, unless otherwise expressly provided, references to features of examples or similar language of a particular method or device may, but not necessarily, all refer to the same example, but mean "one or more but not all examples". Unless otherwise expressly provided, the terms "including", "comprising", "having" and their variants mean "including but not limited to". Unless otherwise expressly provided, an enumerated list of items does not imply that any or all items are mutually exclusive. Unless otherwise expressly provided, the terms "one", "a kind of" and "the" also refer to "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, and does not include a combination of A, B, and C. As used herein, "a member selected from a group including A, B, and C" includes one and only one of A, B, or C, and 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 described herein may be combined in any suitable manner. In the following description, many specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a comprehensive understanding of the present disclosure. However, those skilled in the relevant art will recognize that the disclosed methods and apparatus may be practiced without one or more of the specific details, or may be practiced using other methods, components, materials, etc. In other instances, 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 devices are described below with reference to schematic flow charts and / or schematic block diagrams of methods, devices, systems, and program products. It will be understood that each frame of the schematic flow chart and / or schematic block diagram, and the combination of frames in the schematic flow chart and / or schematic block diagram 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, so that instructions executed by a processor of a computer or other programmable data processing device create components for implementing the functions / actions specified in the schematic flow chart and / or schematic block diagram.

[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 work 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 may also be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operating steps are 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 figure illustrate the possible implementation architectures, functions and operations of the apparatus, system, method and program product. In this regard, each box in the schematic flow chart and / or schematic block diagram may represent a module, segment or portion of code, which includes one or more executable instructions for implementing the code of (multiple) specified logical functions.

[0037] It should also be noted that in some alternative implementations, the functions shown in the blocks may not appear in the order shown in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order, depending on the functions involved. Other steps and methods that are equivalent in function, logic, or effect to one or more blocks or portions thereof of the illustrated figures are contemplated.

[0038] The description of elements in each figure may refer to elements of subsequent figures. The same reference numerals refer to the same elements in all figures.

[0039] Figure 1 An embodiment of a wireless communication system 100 for PDU set definition 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. The remote unit 102 may include a user equipment device 200, UE 535, or UE 1035 as described herein. The base station unit 104 may include a network node 300, UPF 540, or UPF 1040 as described herein.

[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 smart phone, 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), a 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. In addition, 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 side link 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, 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, maintenance, 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 enablement architecture layer (SEAL) functions, vertical application enablement servers, edge enablement servers, edge configuration servers, mobile edge computing platform functions, mobile edge computing applications, application data analysis enablement 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 generally 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 generally communicatively coupled to one or more core networks, which may 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 illustrated, but are generally known to those of ordinary skill in the art.

[0042] In one implementation, the wireless communication system 100 complies with the New Radio (NR) protocol standardized in 3GPP, wherein the network unit 104 transmits on the downlink (DL) using an orthogonal frequency division multiplexing (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. However, more generally, the wireless communication system 100 may implement some other open or proprietary communication protocol, such as WiMAX, IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA2000, ZigBee, Sigfoxx, etc. The present disclosure is not intended to be limited to any particular wireless communication system architecture or protocol implementation.

[0043] The network unit 104 can serve multiple remote units 102 within a service area (eg, 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 is according to one or more of the user equipment devices described in the embodiments herein. The user equipment device 200 may include a remote unit 102, a UE 535, or a UE 1035 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 may 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 may include one or more of 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 base station units. 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. In addition, the transceiver 225 can support at least one network interface 240 and / or application interface 245. (Multiple) application interface 245 can support one or more APIs. (Multiple) network interface 240 can support 3GPP reference points such as Uu, N1, PC5, etc. As understood by those 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 a volatile computer storage medium. For example, the memory 210 may include a RAM including a dynamic RAM (DRAM), a synchronous dynamic RAM (SDRAM), and / or a static RAM (SRAM). The memory 210 may include a non-volatile computer storage medium. For example, the memory 210 may include a hard drive, a flash memory, or any other suitable non-volatile computer storage device. The memory 210 may include both a volatile computer storage medium and a non-volatile computer storage medium.

[0050] The memory 210 may store data related to implementing a traffic category field as described herein. The memory 210 may also store program code and related data, such as an operating system or other controller algorithms operating on the 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 signals, auditory signals, 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, etc. to a user. As another non-limiting example, the output device 220 may include a wearable display that is separate from the rest of the user device apparatus 200 but communicatively coupled to the rest, such as a smart watch, smart glasses, a head-up display, etc. 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, etc.

[0053] Output device 220 may include one or more speakers for producing sound. For example, output device 220 may produce an audible alarm or notification (e.g., a beep or buzzer). Output device 220 may include one or more tactile devices for producing vibration, motion, or other tactile feedback. All or part of output device 220 may be integrated with input device 215. For example, input device 215 and output device 220 may form a touch screen or similar touch-sensitive display. Output device 220 may be located near 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 send 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 part thereof) at a specific time to send messages 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 the base station unit of the wireless communication network. Similarly, one or more receivers 235 can be used to receive downlink communication signals from the base station 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, (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 through a licensed radio spectrum, and a second transmitter / receiver pair for communicating with a mobile communication network through 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 be used to communicate with a mobile communication network via an unlicensed radio spectrum can be combined into a single transceiver unit, for example, 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 the transceivers 225, transmitters 230, and receivers 235 can be implemented as physically separate components that access shared hardware resources and / or software resources, such as, for example, a 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 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. Transmitters 230 and receivers 235 can be logically configured as transceivers 225 using one or more common control signals, or can be configured as modular transmitters 230 and receivers 235 implemented in the same hardware chip or multi-chip module.

[0058] Figure 3 Further details of a network node 300 that may be used to implement the methods described herein are depicted. The network node 300 may include a base unit 104, UPF 540, or UPF 1040 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] The input device 315 and the output device 320 may be combined into a single device, such as a touch screen. In some implementations, the network node 300 does not include any input device 315 and / or output device 320. The network node 300 may include one or more of a processor 305, a memory 310, and a transceiver 325, and may not include an input device 315 and / or an output device 320.

[0060] As depicted, the transceiver 325 includes at least one transmitter 330 and at least one receiver 335. Here, the transceiver 325 communicates with one or more remote units 200. In addition, the transceiver 325 can support at least one network interface 340 and / or an application interface 345. The (multiple) application interface 345 can support one or more APIs. The (multiple) network interface 340 can support 3GPP reference points such as Uu, N1, N2, and N3. As understood by those of ordinary skill in the art, other network interfaces 340 can be supported.

[0061] The processor 305 may include any known controller capable of executing computer-readable instructions and / or capable of performing logical operations. For example, the processor 305 may be a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, 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] The memory 310 may be a computer-readable storage medium. The memory 310 may include a volatile computer storage medium. For example, the memory 310 may include a RAM including a dynamic RAM (DRAM), a synchronous dynamic RAM (SDRAM), and / or a static RAM (SRAM). The memory 310 may include a non-volatile computer storage medium. For example, the memory 310 may include a hard drive, a flash memory, or any other suitable non-volatile computer storage device. The memory 310 may include both a volatile computer storage medium and a non-volatile computer storage medium.

[0063] The memory 310 may store data related to establishing a multipath unicast link and / or mobile operation. For example, as described herein, the memory 310 may store parameters, configurations, resource assignments, 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 signals, auditory signals, 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 the rest of network node 300 but communicatively coupled to the rest, such as a smart watch, smart glasses, a head-up display, etc. In addition, output device 320 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, etc.

[0066] Output device 320 may include one or more speakers for producing sound. For example, output device 320 may produce an audible alarm or notification (e.g., a beep or buzzer). Output device 320 may include one or more tactile devices for producing 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. One or more transmitters 330 can be used to communicate with the UE, as described herein. Similarly, 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 illustrated, the network node 300 can have any suitable number of transmitters 330 and receivers 335. In addition, the (multiple) transmitters 330 and (multiple) receivers 335 can be any suitable type of transmitter and receiver.

[0068] Figure 4The method 400 presented herein is illustrated. The method includes receiving 410 a QoS rule configuration of a QoS requirement of an XR application, and applying 420 the received QoS rule configuration to a packet filter. The method also includes processing 430 a plurality of packet data units (PDUs) of the XR application using a packet filter. The method also includes determining 440 a plurality of PDU sets, wherein each PDU set groups a sequence of one or more PDUs that encapsulate an information unit of the XR application; and sending 450 a plurality of PDU sets to a radio access network, wherein a particular QoS rule configuration is applied to each PDU in the PDU set.

[0069] The above approach tends to map XR application information units to PDU sets. Therefore, XR application services can take advantage of the benefits of delivery via PDU sets, because the PDU sets can be processed according to the same set of QoS requirements and associated constraints of delay budget and error rate, while providing support for differentiated QoS processing at the PDU set level for the RAN. This tends to improve the granularity of the traditional 5G QoS flow framework, allowing the RAN to optimize the mapping between QoS flows and data radio bearers (DRBs) to meet strict XR media requirements, such as high-rate transmission with a short delay budget.

[0070] Essentially, the determination of PDU sets allows the RAN and associated QoS processing to go beyond current best effort processes and optimize transmission and resource allocation at the granularity of PDU sets while achieving the QoS requirements of the application (e.g., meeting delay budget / error rate).

[0071] The method may also include classifying importance levels for at least one of the plurality of PDU sets; and using the importance level of the at least one PDU set to identify a specific QoS rule configuration to be applied to each PDU in the at least one PDU set.

[0072] This tends to allow prioritization of such PDU aggregate level processes according to importance categories. This may be useful for multimodal traffic flows with similar QoS treatment, or traffic flows that may contain PDU aggregates carrying information of various importance levels for an application (e.g. I-frames vs. P-frames in a video stream).

[0073] The method may also include determining one or more PDU sets within the PDU set using metadata provided by the application for each of a plurality of PDUs within the PDU set, and classifying importance of each of the one or more PDU sets.

[0074] The information unit of the XR application may include a video frame, a video slice, or a video layer. The metadata may be provided by the application via an RTP PDU extension header.

[0075] The determined PDU set may represent at least one of: a video coding frame, a video coding frame partition as a video coding slice, a video coding temporal layer, and a video coding spatial layer.

[0076] The packet filter that processes the plurality of PDUs may include a baseline processing stage, a first processing stage, and a second processing stage. The baseline processing stage may include a zeroth processing stage. The baseline processing stage may include level 0 processing. The first processing stage may include level 1 processing. The second processing stage may include level 2 processing.

[0077] The QoS rule configuration may define a set of importance categories for classifying the importance level of each PDU set.

[0078] The determination of the PDU set may include determining a PDU set boundary, wherein the PDU set boundary is determined by means of at least one of: an RTP / SRTP packet header check and an RTP / SRTP packet extension header check.

[0079] The method may further include using at least one of the following for determination of PDU set boundaries: an RTP / SRTP packet header, an M-bit flag field, a sequence number field, a payload type field, a timestamp field, and a synchronization source (SSRC) field.

[0080] The classification of the importance level for each PDU set may include using at least one of: a QoS rule configuration, an XR application configuration of a video codec coding profile, a determined PDU set size, and RTP / SRTP extension header information.

[0081] Video codecs may include H.264, H.265, H.266, AV1, etc.

[0082] The PDU aggregate size may be measured in bytes / octets, bits, or an equivalent metric.

[0083] Classifying the importance level for each PDU set may also include utilizing information comprising at least one of: an importance category determined by a QoS rule; a media bandwidth requirement; a video codec encoding constant bit rate configuration; a video codec encoding upper limit variable bit rate configuration; a video codec encoding expected bit rate configuration; a video codec encoding constant rate factor configuration; a video codec encoding maximum frame size configuration; and a video codec encoding expected frames per second.

[0084] The classification of importance level for each PDU set may be obtained by means of SDP signaling or AF signaling to the PCF.

[0085] A node in a wireless communication network is also provided, the node comprising: an interface and a processor. The interface is arranged to receive a QoS rule configuration of the QoS requirements of an XR application. The processor is arranged to: apply the received QoS rule configuration to a packet filter; process multiple packet data units (PDUs) of the XR application using the packet filter; and determine multiple PDU sets, wherein each PDU set groups a sequence of one or more PDUs that encapsulate an information unit of the XR application. The interface is also arranged to send multiple PDU sets to a radio access network, wherein a specific QoS rule configuration is applied to each PDU in the PDU set.

[0086] The node may be a wireless communication device. The wireless communication device may be a user equipment (UE). The node may include a remote unit 102, a user equipment apparatus 200, a UE 535, or a UE 1035 as described herein. The interface may be a radio transceiver.

[0087] The node may be a network device. The network device may be a user plane function (UPF). The node may include a base station unit 104, a network node 300, a UPF 540, or a UPF 1040 as described herein. The interface may be a network interface.

[0088] The information unit of the XR application may include a video frame, a video slice, or a video layer. In operation, the above-mentioned nodes tend to map the XR application information unit to a PDU set. Therefore, the XR application service can take advantage of the benefits of delivery via a PDU set, because the PDU set can be processed according to the same set of QoS requirements and the associated constraints of the delay budget and error rate, while providing the RAN with support for differentiated QoS processing at the PDU set level. This tends to improve 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, such as high-rate transmission with a short delay budget.

[0089] Essentially, the determination of PDU sets allows the RAN and associated QoS processing to go beyond current best effort processes and optimize transmission and resource allocation at the granularity of PDU sets while achieving the QoS requirements of the application (e.g., meeting delay budget / error rate).

[0090] The processor may be further arranged to classify importance levels for at least one of the plurality of PDU sets and to use the importance level of the at least one PDU set to identify a specific QoS rule configuration to be applied to each PDU in the at least one PDU set.

[0091] This tends to allow prioritization of such PDU set level processes according to importance categories. This may be useful for multimodal traffic flows with similar QoS treatment, or traffic flows that may contain PDU sets carrying information of various importance levels for an application (e.g., I-frames vs. P-frames in a video stream).

[0092] The processor may be further arranged to determine one or more PDU sets within the PDU set using metadata provided by the application for each of a plurality of PDUs within the PDU set, and to classify an importance of each of the one or more PDU sets.

[0093] Metadata may be provided by the application via the RTP PDU extension header.

[0094] The determined PDU set may represent at least one of: a video coding frame, a video coding frame partition as a video coding slice, a video coding temporal layer, and a video coding spatial layer.

[0095] A packet filter that processes a plurality of PDUs may include a baseline processing stage, a first processing stage, and a second processing stage.

[0096] The baseline processing stage may include a zeroth processing stage. The baseline processing stage may include level 0 processing. The first processing stage may include level 1 processing. The second processing stage may include level 2 processing.

[0097] The determination of PDU sets and the classification of the importance of PDU sets can be further filtered by a second processing stage, which is assisted by metadata provided by the application for each of multiple PDUs within the PDU set to determine one or more PDU sets within the PDU set and classify the importance of each PDU set in the one or more PDU sets.

[0098] Metadata may be provided by the application via the RTP PDU extension header.

[0099] The QoS rule configuration may define a set of importance categories for categorizing the importance level of each PDU set.

[0100] The determination of the PDU set may include determining a PDU set boundary, wherein the PDU set boundary is determined by means of at least one of: an RTP / SRTP packet header check and an RTP / SRTP packet extension header check.

[0101] The determination of the PDU set boundary may use at least one of the following: an RTP / SRTP packet header, an M-bit flag field, a sequence number field, a payload type field, a timestamp field, and a synchronization source (SSRC) field.

[0102] The classification of the importance level for each PDU set may include using at least one of: a QoS rule configuration, an XR application configuration of a video codec coding profile, a determined PDU set size, and RTP / SRTP extension header information.

[0103] Video codecs may include H.264, H.265, H.266, AV1, etc.

[0104] The PDU aggregate size may be measured in bytes / octets, bits, or an equivalent metric.

[0105] Classifying the importance level for each PDU set may also include utilizing information comprising at least one of: an importance category determined by a QoS rule; a media bandwidth requirement; a video codec encoding constant bit rate configuration; a video codec encoding upper limit variable bit rate configuration; a video codec encoding expected bit rate configuration; a video codec encoding constant rate factor configuration; a video codec encoding maximum frame size configuration; and a video codec encoding expected frames per second.

[0106] The classification of importance level for each PDU set may be obtained by means of SDP signaling or AF signaling to the PCF.

[0107] The transmission of multiple PDU sets can encapsulate at least one of the following information in a user plane GPRS Tunneling Protocol (GTP-U) header field for each PDU set in the PDU sets: one or more boundaries of the PDU set, an indication of the importance of the PDU set, and an indication of the size of the PDU set.

[0108] The PDU aggregate size may be measured in bytes / octets, bits, or an equivalent metric.

[0109] In the 3GPP technical standard version 18, the 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 a finer granularity beyond the possibility of 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.

[0110] In addition, the PDU set is associated with the 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)). The PDU set delay budget (PSDB) defines an upper limit on the time that the PDU set can be delayed between the N6 endpoint at the UE and the UPF. The PSDB is applied to the DL PDU set received by the UPF through the N6 interface and the UL PDU set sent by the UE, respectively. The PDU set error rate (PSER) defines an upper limit on the ratio of a PDU set (e.g., a set of IP packets constituting a PDU set) that has been processed by the sender of the link layer protocol (e.g., RLC in a RAN accessed by 3GPP), but in which all PDUs in the PDU set are not successfully delivered to the upper layer (e.g., PDCP in a RAN accessed by 3GPP) by the corresponding receiver. The PSER can be used to determine an upper limit on the non-congestion related packet loss rate.

[0111] Figure 5 An overview of the Core Network (CN) XRM architecture for processing PDU aggregation is illustrated. Figure 5 A system 500 is shown, which includes an extended reality media application function (XRM AF) 510, a policy and control function (PCF) 515, a session management function (SMF) 520, an access and mobility function (AMF) 525, a radio access network (RAN 530), a user equipment (UE) 535, a user plane function (UPF) 540, and an extended reality application 545. The UE 535 may include a remote unit 102, a user equipment device 200, or a UE 1035 as described herein. The UPF 540 may include a base station unit 104, a network node 300, or a UPF 1040 as described herein. The operation of the system 500 will now be described in the example of downlink traffic, and similar processes may operate for uplink traffic.

[0112] At 580, the XRM AF 510 determines the PDU setup requirements.

[0113] At 581, the XRM application function 510 provides the QoS requirements for the packets of the PDU set and information (i.e., 5-tuple or application id) to identify the application to the PCF 515. The QoS requirements may include PSDB and PSER. The XRM AF 510 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.

[0114] At 582, the PCF 515 derives QoS rules for the XR application and specific QoS requirements for the PDU set. The QoS rules may use a 5G QoS identifier (5QI) for the XR media service. The PCF 515 sends the QoS rules to the SMF 520. The PCF 515 may include policy and charging control (PCC) rules in the communication to the SMF 520 for the importance of the PDU set. The PCC rules may be derived based on information received from the XRM AF 510 or based on operator configuration.

[0115] At 583, SMF 520 establishes a QoS flow according to the QoS rules of PCF 515, and configures UPF to route packets of the XR application to the QoS flow, and in addition, configures UPF to enable PDU aggregate processing. SMF 520 also provides a QoS profile containing PDU aggregate QoS requirements to RAN 530 via AMF 525. AMF 525 can provide a QoS profile containing PDU aggregate QoS requirements to RAN 530 in an N2 session management (SM) container. In addition, AMF 525 can provide QoS rules to UE 535 in an N1 SM container.

[0116] At 584, UPF 540 inspects the packets and determines the packets that belong to the PDU set. The packet inspection may include inspecting the RTP packets. When UPF 540 detects packets of the PDU set, UPF 540 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. UPF 540 may also determine the importance of the PDU set based on the UPF 540 implementation, information provided by XRM AF 510, or information provided as metadata from the XRM application server. Based on the importance of the PDU set, UPF 540 may route the service to the corresponding QoS flow 1 (according to the rules received from SMF 520), or include the importance of the PDU set in the GTP-U header. QoS flow 1 may include a GTP-U header, and the GTP-U header may include PDU set information.

[0117] At 585, the RAN 530 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 520. In one implementation, the RAN 530 node may use different radio bearers with higher QoS requirements (according to the PDU set PSDB / PSER) to guarantee the delivery of packets of the PDU set, while using different radio bearers according to the 5QI of the QoS flow for non-PDU set packets. The RAN 530 may receive the QFI, QoS profile (including PDSB and PSER) of the QoS flow from the SMF 520 (via the AMF 525) during the PDU session establishment / modification. The RAN 530 checks 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 the 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.

[0118] The above examples involve downlink (DL) traffic. Reciprocal processing applies to uplink (UL) traffic, where the role of UPF 540 packet inspection is assumed by the UE 535, which is expected to inspect the uplink packets, determine the packets belonging to the PDU set, and accordingly signal the PDU set to the RAN 530 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.

[0119] Herein, extended reality (XR) is used as an umbrella term for different types of reality, of which virtual reality, augmented reality, and mixed reality are examples.

[0120] 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) to completely replace the user's field of view with simulated visual components, and requires the user to wear headphones to provide incidental audio to the user. In VR, some form of head and motion tracking of the user is also typically required to allow the simulated visual and audio components to be updated, thereby ensuring that from the user's perspective, objects and sound sources are consistent with the user's movements. In some implementations, additional means for interacting with the virtual reality simulation may be provided, but are not strictly necessary.

[0121] Augmented reality (AR) is the provision of additional information or artificially generated items to a user, or content superimposed on the user's current environment. Such additional information or content is typically visual and / or auditory, and the user's observation of their current environment may be direct, with no intervening sensing, processing, and rendering, or may be indirect, with their perception of their environment relayed via sensors and may be augmented or processed.

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

[0123] XR refers to all real and virtual environments and human-computer interactions generated by computer technology and wearable devices. XR includes representative forms such as AR, MR and VR and interpolation areas between them. The level of virtuality ranges from partial sensory input to fully immersive VR. In some circles, a key aspect of XR is considered to be an extension of human experience, especially human experience related to presence (represented by VR) and cognitive acquisition (represented by AR).

[0124] In 3GPP Release 17, the 3GPP SA4 working group analyzed the media delivery protocols and XR business models in the technical report TR26.926 (v1.1.0) titled "Business Models and Quality Assessment Methods for Media and XR Services in 5G Systems", and determined the QoS requirements in terms of delay budget, data rate and error rate required for a satisfactory experience at the application level. This resulted in 4 additional 5G QoS Identifiers (5QIs) for 5GS XR QoS flows. These 5QIs are defined in 3GPPTS23.501 (v17.5.0) Table 5.7.4-1 and are presented as delay-critical GBR 5QIs with values ​​of 87-90. The latter applies to XR video streams and the control metadata required to provide immersive and interactive XR experiences.

[0125] XR video services mainly 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-30Mbps), which need to be sent across the network with minimal latency (typically capped at 15-20ms) to maintain reduced end-to-end application round-trip interaction latency. The latter requirement is critical given XR applications' reliance on cloud / edge processing (e.g., content download, viewport generation and configuration, viewport update, viewport rendering, media encoding / transcoding, etc.).

[0126] To support such stringent latency-critical requirements specific to real-time communications (RTC) with high bandwidth (e.g., XR video streaming), the high-level protocol envisioned for delivering XR immersive multimedia applications is the Real-time Transport Protocol (RTP). In this context, reference may be made to the 3GPP Technical Report TR 26.928 (v17.0.0) entitled “Extended Reality (XR) in 5G”. In some implementations, secure RTP variants such as vanilla Secure Real-time Transport Protocol (SRTP) or a web browser-based WebRTC stack may be used to serve XR applications across mobile communication networks such as 5GS.

[0127] RTP is a media codec-independent network protocol with application layer framing for real-time delivery of multimedia (e.g., audio, video, etc.) over IP networks, as defined in the IETF standard RFC 3550 entitled "RTP: A Transport Protocol for Real-Time Applications." RTP is used in conjunction with a sister protocol for control, the RTP 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.

[0128] Figure 6 An overview of the RTP and RTCP stacks is provided. The IP layer 605 carries signaling from the media session data plane 610 and from the media session control plane 650. The data plane 610 stack includes functionality for the User Datagram Protocol (UDP) 612, RTP 616, RTCP 614, media codecs 620, and quality control 622. The control plane 650 stack includes functionality for UDP 652, Transmission Control Protocol (TCP) 654, Session Initiation Protocol (SIP) 662, and Session Description Protocol (SDP) 664.

[0129] 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 (payload confidentiality), message authentication and integrity (header and payload signatures), replay attack protection. Similarly, SRTP sister protocol SRTCP provides the same functionality to its RTCP counterpart. Therefore, in SRTP, the RTP header information remains accessible but unmodifiable, while the payload is encrypted. For this reason, SRTP is used in the WebRTC stack, which ensures secure RTC multimedia communications through a web browser interface.

[0130] Figure 7An overview of the WebRTC stack is illustrated. The IP layer 705 carries signaling from the data plane 710 and the control plane 750. The data plane 710 stack includes functions for UDP 712, interactive connection establishment (ICE) 724, datagram transport layer security (DTLS) 726, SRTP 717, SRTCP 715, media code 720, quality control 722, and SCTP 728. ICE 724 can use the Session Traversal Utilities for NAT (STUN) protocol and Traversal Using Relays Around NAT (TURN) to address real-time media content delivery across heterogeneous networks and NAT rules. SCTP 728 can be non-time critical. SRTP 717, SRTCP 715, media code 720, and quality control 722 can be time critical.

[0131] Figure 8 Illustrated are packet formats and header information for both RTP packets 830 and SRTP packets 860. The header information is available for inspection and processing, and an overview is provided below, including a brief description of certain fields of interest in the header portion of the RTP / SRTP packet format.

[0132] “X” 834, 864 is 1 bit, indicating that the standard fixed RTP / SRTP header will be followed by an RTP header extension that is typically associated with specific data / profile and will carry more information about the data (e.g., a frame marking RTP header extension for video data, as defined in RTP Frame Marking RTP Header Extension (November 2021) - draft-ietf-avtext-framemarking-13).

[0133] "CC" 836, 866 is 4 bits and indicates the number of contributing media sources (CSRC) following the header.

[0134] "M" 838, 868 is 1 bit and is intended to mark the information frame boundary in the packet stream. The behavior of this "M" is precisely specified by the RTP profile (e.g., H.264, H.265, H.266, AV1, etc.)

[0135] "PT" 840, 870 is 7 bits indicating the payload type, which in the case of a video profile is dynamic and negotiated with the aid of SDP (e.g., 96 for H.264, 97 for H.265, 98 for AV1, etc.).

[0136] "Sequence Number" 842, 872 is 16 bits and indicates a sequence number that is incremented by 1 with each RTP packet sent on the session.

[0137] "Timestamp" 844, 874 is 32 bits, indicating a timestamp in ticks of the payload type clock, which reflects the sampling moment of the first octet of the RTP data packet (associated with the video frame for a video stream), and the first timestamp of the first RTP packet is randomly selected.

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

[0139] In the following, we refer to a video frame as a video encoding representation of a still image presented in a sequence that makes up a video stream. On the other hand, a video frame may consist of one or more video slices. A video slice is an encoded video representation of a partition of a still image portion of a video sequence. In some implementations (e.g., H.266, AV1), a video slice may refer to a rectangular partition (e.g., tile) of a still image, while in other implementations (e.g., H.264, H.265, H.266, etc.), a video slice may be a raster scan partition of a still image. Similarly, we refer to video layers as video coding elements, or as temporal video layers, meaning to increase the resolution of frames per second and the temporal level of detail of a video sequence; or as spatial video layers, meaning to increase the number of video encoding pixels and spatial resolution of individual video frames of a video sequence. The abstract concepts of video frames, video slices, and / or video layers apply to modern hybrid video codecs of the MPEG family (i.e., H.264 / H.265 / H.266), as well as other open video codecs (such as AV1 or VP9). The encapsulation format of video encoded data into RTP / SRTP payload is specified by Internet standards for each individual video codec, such as H.264 specified by RFC 6184, H.265 specified by RFC 7798, AV1 as specified by RTP Payload Format for AV1 (aomediacodec.github.io).

[0140] Note that for XR applications, the media codec used and its configuration / configuration update depends on the application implementation, and the configuration / configuration update is usually negotiated between the sender and the receiver at session establishment / session update (e.g., RTP / SRTP). To this end, Session Description Protocol (SDP) signaling is used as a separate signaling process or as part of Session Initiation Protocol (SIP).

[0141] Determining PDU sets and managing XR QoS flows implies solving two problems: determining PDU set boundaries (PSB); and, given an XR application, classifying PDU set importance (PSI) according to some importance category and / or associated priority. Although there are certain benefits to only determining set boundaries without classifying the determined sets.

[0142] These two issues will be solved at the UPF level for DL ​​or at the UE level for UL, and as described in the previous article, the processed results are used in DL to set, configure and map the PDU set to the appropriate QoS rules with the help of QoS flow. On the other hand, in UL, the UE will use the processed results to map the PDU set to the appropriate DRB accordingly, which is then remapped to the QoS flow by the RAN through N3 with the help of SDAP processing. Then, the UPF should route the UL to the application server according to the QoS rules configured by the PCF and the QoS flow established by the SMF.

[0143] The current solutions discussed in the context of XRM Release 18 SI target PSB determination mainly rely on 2 strategies: deep packet inspection; and RTP header information parsing. The disadvantage of the first solution space (i.e., deep packet inspection) is that it is computationally expensive to train and deploy, which makes its application in the UL direction for UE processing infeasible.

[0144] Solutions involving the use of the RTP packet format utilize a combination of one or more of the RTP timestamp, sequence number, and M-bit markers to determine video frame boundaries. In some solutions, this information is supplemented by additional information extracted from application-specific and / or profile-specific D RTP header extensions (e.g., draft-ietf-avtext-framemarking-13), or from parsing the RTP payload header (e.g., the RTP payload header of the video coded NAL unit in the H.26x codec). The last collected information is then used to extract some classification / estimate of the importance of the detected PDU set (e.g., some solutions are listed in 3GPP TR 23.700-60 (v0.0.3) entitled "Study on XR (Extended Reality) and Media Services").

[0145] However, it is not always possible to extract such additional information from the RTP payload (e.g., in SRTP or WebRTC, the payload is encrypted), while application-specific / profile-specific RTP extension headers need to be handled uniformly across various video codecs and profiles (e.g., draft-ietf-avtext-framemarking-13) and, according to RFC3550, should be considered a last resort.

[0146] In addition, it should be noted that 3GPP TR23.700-60 (v0.0.3), entitled "Study on XR (Extended Reality) and Media Services", describes the use of RTP packet formats to determine video frame boundaries using a combination of one or more of RTP timestamps, sequence numbers, and M-bit markers. In some solutions, this information is supplemented by additional information extracted from application-specific and / or profile-specific RTP header extensions (e.g., draft-ietf-avtext-framemarking-13), or from parsing RTP payload headers (e.g., RTP payload headers of video coded NAL units in H.26x codecs). The last collected information is then used to extract some classification / estimate of the importance of the detected PDU set.

[0147] In contrast, the solution presented herein uses a hierarchical filtering scheme that is configurable based on operator and / or AF configuration for determining the PSB and / or PSI. The zeroth filter stage (baseline) determines the PSB based on the RTP / SRTP fixed header. The first filter stage uses the AF codec configuration to classify the importance of the detected PDU sets based on the PDU set size and the video codec configuration (e.g., video codec constant bit rate (CBR) configuration, video codec variable capped bit rate (cVBR) configuration, and / or video media bandwidth requirements), given the XR application QoS requirements. The second filter stage is an application auxiliary filter that refines the first two stages using application metadata (e.g., RTP extension headers) and decomposes the PDU sets from frame to time / space / slice PDU set mapping and reclassifies the importance of smaller PDU sets.

[0148] The proposed solution consists of mapping XR application information units to PDU sets. According to some examples presented herein, this is performed through the principle of packet filtering, where packet filtering consists of hierarchical processing of RTP packets encapsulating XR application information. Conversely, the mapping of XR application data to PDU sets can be processed by RTP packets (or RTP packets encapsulated by a transport protocol (e.g., UDP)) as follows:

[0149] Received over the N6 interface for DL ​​transmission, where the processing is performed by a packet filtering instance within the UPF; and

[0150] • Received at the UE for UL transmission, where the processing is performed by a packet filtering instance before SDAP layer processing.

[0151] Filtering is configured based on the session media codec (e.g. video) configuration established by the application's PDUs negotiated via SDP offer / answer during PDU session initialization / update, where the latter configuration together with other AF information signaling (e.g. 5-tuple describing the service endpoint, bandwidth / PDSB / PSER requirements, application / protocol information, etc.) further determines the QoS rules derived by the PCF.

[0152] The configuration of the packet filter controls the hierarchical processing. The hierarchical processing may include a baseline processing level, a first processing level, and a second processing level. The baseline processing level may include a zeroth processing level. The baseline processing level may include level 0 processing. The first processing level may include level 1 processing. The second processing level may include level 2 processing.

[0153] Level 0 processing includes determining rough PDU set boundaries. In any case, this may include an initial rough estimate of the PDU set boundaries. The packet filter processes only the RTP fixed header information (e.g., at least the M-bit flag and the sequence number of the RTP packet) to determine the sequence of PDUs that form the PDU set. The output of level 0 processing is a PDU set, where the PDU set is determined by its PSB. The result of level 0 processing can result in an output of a PDU set that is mapped to a video frame / single video slice (e.g., as in the H.264 specification, the H.265 specification, the H.266 specification, the AV1 specification).

[0154] Level 1 processing includes a rough determination of PDU set boundaries and importance determination. After level 0 processing is completed, the packet filter additionally processes the determined PDU set size and determines the importance of the PDU set using the PDU session codec configuration information provided by the PCF, where the determined importance corresponds to some predefined PCF importance levels given the AF configuration and QoS requirements. The predefined importance levels may include HIGH and LOW, or alternatively HIGH, MEDIUM and LOW. Adding more predefined importance levels improves the granularity of the importance classification.

[0155] In some embodiments, the resulting output of level 1 processing is mapped to a set of PDUs of video frames or video slices (similar to level 0 processing), with an additional indication of an estimate of the absolute importance of the video frame / video slice to the served XR application.

[0156] Level 2 processing includes refined PDU set boundary and importance determination. After level 1 processing is completed, the determined PDU sets and importance (i.e., PSB and PSI) are further refined to handle additional application-specific / media codec-specific information (e.g., RTP extension headers, which carry information about media coding information units encapsulated by RTP and / or SDP, including media codec-related information). The output of level 2 can be a more fine-grained PSB and associated PSI, which splits the PSB and PSI of level 1 into one or more PDU sets given the application / media codec-specific information.

[0157] In the case where XR application support is enabled for level 2 (e.g., by means of a standardized RTP extension header and / or by means of operator configuration), additional processing maps a PDU set to one of a video frame, video slice, or video layer. In such an implementation, the processing parses the application / video codec metadata (e.g., a standardized RTP extension header) to determine finer PDU set boundaries for a finer level of QoS controlled by the CN. In some implementations, the application may additionally indicate the importance of the individually determined PDU sets through an RTP extension header field.

[0158] Fig. 9 A PDU aggregation packet filter 900 is illustrated, which includes hierarchical processing in the form of level 0 (910), level 1 (911), and level 2 (912). Input 920 receives QoS rules via the N4 interface. PDU inlet port 930 receives PDUs via the N6 interface. PDUs can be received at the filter 900 via RTP or UDP. The output of the filter is a PDU aggregation egress port 940, which outputs PDU aggregation via RTP using interface N3 and UDP tunneled via the GTP-U protocol.

[0159] Fig.10 Illustrated is the application of packet filtering in XRM services across 5GS in both DL and UL. Fig.10A system 1000 is shown, which includes an extended reality media application function (XR AF) 1010, a policy and control function (PCF) 1015, a session management function (SMF) 1020, an access and mobility function (AMF) 1025, a radio access network (RAN 1030), a user equipment (UE) 1035, a user plane function (UPF) 1040, and an extended reality application service (XR AS) 1045. The UE 1035 may include a remote unit 102, a user equipment device 200, or a UE 535 as described herein. The UPF 1040 may include a base station unit 104, a network node 300, or a UPF 540 as described herein.

[0160] The operation of system 1000 will now be described in the example of downlink traffic, and a similar process can be operated for uplink traffic. PCF 1015 determines the PCC rules for the QoS flow and the processing level of the PDU set based on the requirements provided by the XR AF or based on the operator configuration. The PCC rules include information for enabling PDU set detection for packets (identified by a 5-tuple) of the service data flow and corresponding processing level information. The PCC rules are sent to SMF 1020, which in turn establishes a QoS flow and provides N4 rules to UPF 1040, thereby instructing UPF 1040 to perform PDU set detection and marking on the identification packets of the PDU set within the GTP-U header of the QoS flow of RAN 1030 through the N3 reference point. SMF 1020 also provides RAN1030 with the QoS profile information required by the PDU set.

[0161] Filter level 0 includes a coarse PDU set determination. Level 0 processing derives a baseline PDU set determination given the processing of basic fixed header information available in the RTP / SRTP payload conveying the XR media stream (e.g., a video encoding stream). Since this header information is always available in the UDP payload at the UPF (in DL) or UE (in UL), in some examples, the processing of this header information requires parsing and evaluation of at least 12 octets of information according to version 2 of the RTP protocol.

[0162] The M-bit marker can be used to determine the end of a unit frame of media information. In some examples, the XR implementation serves video coded media (e.g., H.264 / H.265 / H.266), and the M-bit marker in the RTP header determines the end of the video frame, and therefore also determines the end of the PDU set that encapsulates the video frame. In some examples, such a video frame may be an intra-coded video frame (i.e., an I-frame), which may additionally contain various parameter sets (xPS) (e.g., video parameter sets, picture parameter sets, sequence parameter sets) and / or supplemental enhancement information (SEI) at the beginning. In another example, the XR implementation serves video coded media (e.g., AV1 / VP8 / VP9), and the M-bit marker in the RTP similarly marks the end of the video frame.

[0163] The sequence number of the RTP packet and the M-bit flag can be processed and used to determine the sequence of the RTP PDU of one or more frames of media information encapsulating the application. A continuous sequence of encapsulated RTP PDUs (i.e., RTP PDUs with consecutive sequence numbers) forms such a PDU set according to the PDU set definition. The PDU set determined based on this information is delimited by at least one of the start delimiter and the end delimiter to signal its PSB. Alternatively, additional information for processing the PDU set by the lower layer (e.g., PDU set sequence number, PSB, PDU set size) can be encapsulated in a lower layer header (e.g., GTP-U header) for transmission to the RAN through the 5GS and CN tunnels.

[0164] Additional RTP fixed header information (eg, payload type, timestamp, and synchronization source (SSRC)) may additionally be used for better, more accurate PSB identification and PDU set detection associated with media sources and profiles.

[0165] Fig.11 1 is an illustration of applying a level 0 processing PDU aggregate packet filter to an RTP stream carrying a payload of a video coded bitstream and mapped to a PDU aggregate. A series of video frames 1108 are carried by a series of RTP packets 1118. A PDU aggregate packet filter 1112 performs level 0 processing on the RTP packets 118. The output of the PDU aggregate packet filter 1112 is a plurality of PDU aggregates 1128, where each PDU aggregate corresponds to a respective video frame 1108.

[0166] Filter level 1 includes a coarse PDU set and importance determination. Level 1 processing is applied on top of the results from level 0 processing to additionally determine the importance of a set of PDUs given a finite set of importance categories defined by the PCF QoS rules according to the AF QoS requirements. The PCF can configure the set of importance categories (i.e., the number of levels, such as high, medium, low) to better support AF QoS requirements. The operator-controlled PCF can determine the set of importance categories based on the request of the AF under the service level agreement to better serve high-fidelity XR applications and / or advanced XR features.

[0167] For example, given the following QoS requirements for PDU set-enabled communications, the AF may request the PCF to configure the PCC:

[0168] PDU aggregate size < 70000 bytes: PSDB = 20ms, PSER = 2%

[0169] PDU aggregate size ≥ 70000 bytes: PSDB = 15 ms, PSER = 1%.

[0170] Therefore, the PCF can configure the PCC and QoS rules that are mapped to QoS flows that support the minimum requirements of AF services (i.e., PSDB=15ms and PSER=1%). In addition, given the PDU set size, the PCF QoS rules can classify 2 or more levels of importance for the same QoS flow, i.e., high importance for packets with a PDU set size greater than or equal to 70,000 bytes, and default (DEFAULT) importance for packets with a PDU set size less than 70,000 bytes. The UPF then uses the PDU set size threshold (as indicated by the AF) within the determined QoS rules and marks the importance of the PDU set accordingly.

[0171] In addition, support for sub-QoS flows of a QoS flow can be enabled. Each sub-QoS flow of a QoS flow supports different QoS requirements. For example, sub-QoS flow #1 can carry a service consisting of a PDU set with a PSDB of 20ms and a PSER of 2% (i.e., a PDU set size of less than 70,000 bytes), while sub-QoS flow #2 can carry a service corresponding to a PDU set with a size greater than or equal to 70,000 bytes, a PSDB of 15ms, and a PSER of 1%. The UPF then uses the PDU set size threshold (as indicated by the AF to the PCF) within the determined QoS rule to determine the importance of the PDU set accordingly, and maps the PDU set to the corresponding sub-QoS flow within the applied QoS flow.

[0172] Level 1 processing uses the PSB and PDU sets determined by Level 0 to check the PDU set size (e.g., number of bytes / octets, number of bits, or any equivalent measure). Level 1 processing can then use the determined PDU set size and, given the importance class configured by the PCF QoS rule, apply the QoS rule threshold to determine and classify the importance of the PDU set. In one example, a PDU set with a larger size exceeding a threshold (e.g., 70,000 bytes) would be classified as a PDU set with high importance, while a PDU set with a size not exceeding the threshold (e.g., 70,000 bytes) would be classified as a PDU set with low (or default) importance.

[0173] The UPF (in DL) / UE (in UL) additionally filters (i.e., relative to the level 1 filtering process) media session negotiation / update protocol PDUs (e.g., SDP / SIP or SDP offer / answer) belonging to the same application ID / application server as the determined QoS rule. Thus, the UPF (in DL) / UE (in UL) is able to intercept and interpret media stream metadata, such as video codec configuration information, for example, as a combination of video codec type (e.g., H.264, H.265, AV1, etc.), video codec format (e.g., YUV 444, YUV 420, etc.), video frames per second (e.g., 60fps, 90fps, 120fps), maximum video frame size, average rate / bandwidth requirement, video codec constant bit rate configuration, video codec upper variable bit rate configuration, video codec constant rate factor configuration, to extract relevant threshold features for importance characterization of the media stream. The UPF / UE can then utilize the extracted threshold features to determine a set of importance thresholds and associated importance categories. The determined thresholds and categories are then used by the UPF (in DL) / UE (in UL) to classify the PDU set importance levels.

[0174] In some embodiments, the level 1 processing determines an N-1 number of PDU set size thresholds based on the N number of importance categories configured by the PCF QoS rules. The level 1 processing then applies the thresholds to classify the PDU set importance determined by level 0 according to the importance categories configured by the PCF QoS rules. In other embodiments, the N-1 PDU set size thresholds may be signaled directly to the packet filter by the PCF along with the packet filter configuration given the derived QoS rules.

[0175] Fig.12The application of level 0 and level 1 filtering processes to a PDU stream is illustrated. A series of RTP packets 1218 are fed into a PDU aggregate packet filter 1212, which performs level 0 processing and level 1 processing as described herein. The output of the PDU aggregate packet filter 1212 is a plurality of PDU aggregates 1228 classified by importance. Three importance categories are defined, measured by the PDU aggregate size. The first category 1231 is a low importance category, the second category 1232 is a medium importance category, and the third category 1233 is a high importance category. By applying level 0 processing to the PDU aggregate filter 1212 on the RTP stream 1218 carrying the payload of the video coded bitstream followed by application of level 1 processing, the PDU aggregate packet filter 1212 will mark both the PSB and the PSI to determine both the PDU aggregate and the importance of the PDU aggregate given the QoS rule importance category.

[0176] The UPF may include information about the size of the PDU set within the GTP-U header over the N3 reference point. The RAN may implicitly determine the size of the PDU set by receiving the start / end of the PDU set (via the GTP-U header information). Once the RAN determines the size of the PDU set, the RAN acts according to the QoS requirements corresponding to the size of the PDU set received from the SMF within the QoS profile information.

[0177] Level 2 processing includes a refined determination of PDU sets and importance. After processing level 0 and level 1 packet filtering, the determined PDU set will include information that describes only complete video frames. This is a result of the fact that the M-bit marker determines the end of the application information frame, which is applicable to video coding frames (i.e., video encoding representations of still images presented in a sequence that makes up a video stream) in the video profile of modern hybrid video codecs (e.g., H.264, H.265, H.266, VP8, VP9, ​​AV1). For some XR applications and video coding configurations, the latter result is insufficient. This is the case for XR applications that apply slicing in their encoding (i.e., where the video frame is encoded as more than 2 video slices or equivalent partitions). Similar arguments apply to applications using scalable video coding that use temporal or spatial enhancement video coding layers to support a gradual improvement in video quality during transmission.

[0178] Such an application has the advantage of providing improved protection against packet loss, since the video frame is segmented into multiple video coding slices, which form more fine-grained information and provide a higher degree of protection against burst packet loss than the traditional single (non-sliced) video frame representation. Similarly, the argument applies to layered video coding, where enhancement layers are used to gradually improve the video quality of the base layer. In order to take advantage of such advanced coding configurations, the RAN and CN need to know the PDU sets at that level (i.e., video slices, layers, and their interdependencies), and therefore need to perform more refined PDU sets and importance determination than those of level 0 and level 1.

[0179] However, this cannot be achieved in a consistent manner without the help of XR applications, as this information is only available at the level of the video coding NAL unit or equivalently, in the RTP payload. Since in some embodiments this information may be further encrypted (e.g., for SRTP or WebRTC), applications such as NAL unit parsers and specific filters are limited in such embodiments. Therefore, XR applications need to provide media metadata information (finer-grained PSB markers and importance indicators) to benefit from their advanced coding on 5G and other systems.

[0180] The application can signal to the PCF via the AF that the application will provide information such as RTP extension headers and the RTP extension header format used (e.g., RTP Frame Marking RTP Header Extension (November 2021) - draft-ietf-avtext-framemarking-13) as part of its QoS requirements. The PCF then derives QoS rules and importance categories and indicates to the UPF (in DL) / UE (in UL) the configuration used at the UPF (in DL) / UE (in UL) for packet filtering based on the RTP extension header format that enables level 2 processing. In some embodiments, level 0 and level 1 processing are performed as a baseline and supplemented once completed by level 2, while in other embodiments, level 0 and level 1 are skipped and replaced by level 2 processing.

[0181] Level 2 processing may operate to parse the RTP extension header format (e.g., RTP Frame Marking RTP Header Extension (November 2021) - draft-ietf-avtext-framemarking-13) and determine additional information such as slice / temporal layer / spatial layer boundaries, frame / slice / temporal / spatial layer references and dependencies, and at least one of slice importance levels. This additional information is then processed and used to determine the PDU set and importance at the video coding slice level and / or layer level indicated by the RTP extension header of the XR application. The importance level of the PDU set may be explicitly indicated by the application through the RTP extension header, and the UPF / UE packet filtering level 2 processing maps the latter to an importance category determined by the PCF. In other arrangements, the level 2 processing may determine the PSI of the PDU set and classify the PSI given the RTP extension header format and the information included thereby.

[0182] Given an AF request under SLA, level 2 processing may be enabled after operator configuration for supporting high-fidelity XR applications. Alternatively, level 2 processing is enabled only if application RTP extension headers are supported by the network operator's packet filtering implementation.

[0183] Fig.13 13 is an illustration of level 2 processing of applying a PDU aggregation packet filter to an RTP stream carrying a payload of a video coded bitstream. A series of video frames 1308 are carried by a series of RTP packets 1318. The RTP packets 1318 are fed into a PDU aggregation packet filter 1312 which performs level 2 processing as described herein. The output of the PDU aggregation packet filter 1312 is a plurality of PDU aggregations 1328 sorted by importance. As shown in reference Fig.12 As explained, three importance categories are defined. The PDU set packet filter 1312 uses application specific / profile specific RTP header extension metadata to mark both PSB and PSI and thus determine both the PDU set and the importance of that PDU set at a fine granularity (in this case, up to the slice level) given a QoS rule importance category (e.g., high and low).

[0184] Methods, systems, and apparatus for mapping RTP video coded PDUs to PDU sets in the context of XR media and applications are described herein. The PSB and PSI for the PDU set are determined based on RTP / SRTP packet filtering by: using an extensible framework (applicable to both UPF and UE) for hierarchical filtering to determine the PSB and PSI from a coarse level of information to a fine granular level based on operator and AF configuration; and using the PDU set size to classify the PDU set importance given the PCF configured QoS rules and the determined importance category.

[0185] It should be noted that the above 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 other elements or steps than those listed in the claims, "a" or "an" does not exclude a plurality, and a single processor or other unit may perform the functions of several units described in the claims. Any reference signs in the claims should not be construed as limiting their scope.

[0186] Furthermore, although 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, although specific examples have been given in the context of 3GPP, the principles disclosed herein may also be applied to another wireless communication system, and indeed to any communication system that uses routing rules.

[0187] The method may also be embodied in a set of instructions stored on a computer-readable medium, which, when loaded into a computer processor, a digital signal processor (DSP), etc., causes the processor to perform the above method.

[0188] The described methods and apparatus may be practiced in other specific forms. The described methods and apparatus are considered in all respects to be illustrative only and not restrictive. Therefore, the scope of the present invention is indicated by the appended claims rather than by the foregoing description. All changes within the equivalent meaning and range of the claims should be included within their scope.

[0189] The following abbreviations are relevant to this field: 3GPP, third generation partnership project; 5G, fifth generation; 5GS, 5G system; 5QI, 5G QoS identifier; AF, application function; AMF, access and mobility function; AR, augmented reality; DL, downlink; GTP-U, GPRS tunneling protocol for user plane; 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 method comprising: Receive QoS rule configuration for QoS requirements of XR applications; Applying the received QoS rule configuration to a packet filter; Processing a plurality of packet data units (PDUs) of the XR application using the packet filter; Determining a plurality of PDU sets, wherein each PDU set groups a sequence of one or more PDUs encapsulating information units of the XR application; as well as The plurality of PDU sets are sent to a radio access network, wherein a specific QoS rule configuration is applied to each PDU in the PDU sets.

2. The method according to claim 1, further comprising: classifying an importance level for at least one PDU set of the plurality of PDU sets; The importance level of the at least one PDU set is used to identify the specific QoS rule configuration to be applied to each PDU in the at least one PDU set.

3. The method according to claim 2, further comprising: Using metadata provided by the application for each of the plurality of PDUs within the PDU set, one or more PDU sets within the PDU set are determined, and the importance of each of the one or more PDU sets is classified.

4. The method according to claim 1, 2 or 3, wherein the determined PDU set represents at least one of the following: Video encoding frame, Video coding frame partitions as video coding slices, Video encoding temporal layers, and Video coding spatial layers.

5. The method of any one of the preceding claims, wherein the packet filter that processes the plurality of PDUs comprises a baseline processing stage, a first processing stage, and a second processing stage.

6. The method according to any of the preceding claims, wherein the QoS rule configuration defines a set of importance categories for classifying the importance level for each set of PDUs.

7. The method according to any of the preceding claims, wherein the determination of a PDU set comprises determining a PDU set boundary, wherein the PDU set boundary is determined by means of at least one of: RTP / SRTP packet header inspection, and RTP / SRTP packet extension header inspection.

8. The method of claim 7, further comprising using at least one of the following for the determination of the PDU set boundary: RTP / SRTP packet header, M-bit flag field, Serial number field, Payload Type field, A timestamp field, and Synchronization Source (SSRC) field.

9. The method according to any of the preceding claims, wherein the classification of the importance level for each PDU set comprises using at least one of: The QoS rule configuration, the XR application configuration of the video codec encoding profile, the determined PDU aggregate size, and RTP / SRTP extended header information.

10. The method of claim 9, wherein the categorizing the importance level for each PDU set further comprises utilizing information comprising at least one of: an importance category determined by the QoS rule; Media bandwidth requirements; Video codec encoding constant bitrate configuration; Video codec encoding upper limit variable bit rate configuration; The video codec encoding expected bitrate configuration; Video codec encoding constant rate factor configuration; Video codec encoding maximum frame size configuration; and The video codec encodes the expected number of frames per second.

11. A node in a wireless communication network, the node comprising: an interface arranged to receive a QoS rule configuration of a QoS requirement of an XR application; The processor is arranged as: Applying the received QoS rule configuration to a packet filter; Processing a plurality of packet data units (PDUs) of the XR application using the packet filter; Determining a plurality of PDU sets, wherein each PDU set groups a sequence of one or more PDUs encapsulating information units of the XR application; as well as The interface is further arranged to send the plurality of PDU sets to a radio access network, wherein a specific QoS rule configuration is applied to each PDU in the PDU sets.

12. The node according to claim 11, wherein the processor is further arranged to: classifying an importance level for at least one PDU set of the plurality of PDU sets; and The importance level of the at least one PDU set is used to identify the specific QoS rule configuration to be applied to each PDU in the at least one PDU set.

13. A node according to claim 12, wherein the processor is further arranged to: determine one or more PDU sets within the PDU set using metadata provided by the application for each of the multiple PDUs within the PDU set, and classify the importance of each PDU set in the one or more PDU sets.

14. The node according to claim 11, 12 or 13, wherein the determined set of PDUs represents at least one of the following: Video encoding frame, Video coding frame partitions as video coding slices, Video encoding temporal layers, and Video coding spatial layers.

15. The node according to any one of claims 11 to 14, wherein the packet filter that processes the plurality of PDUs comprises a baseline processing stage, a first processing stage, and a second processing stage.

16. A node according to any one of claims 11 to 14, wherein the determination of the PDU set and the classification of the importance of the PDU set are further filtered by a second processing stage, and the second processing stage is assisted by metadata provided by the application for each of the multiple PDUs within the PDU set to determine one or more PDU sets within the PDU set and classify the importance of each of the one or more PDU sets.

17. The node according to any one of claims 11 to 16, wherein the QoS rule configuration defines a set of importance categories for classifying the importance level for each set of PDUs.

18. The node according to any one of claims 11 to 17, wherein the determination of a PDU set comprises determining a PDU set boundary, wherein the PDU set boundary is determined by means of at least one of: RTP / SRTP packet header inspection, and RTP / SRTP packet extension header inspection.

19. The node of claim 18, further comprising using at least one of the following for the determination of the PDU set boundary: RTP / SRTP packet header, M-bit flag field, Serial number field, Payload Type field, A timestamp field, and Synchronization Source (SSRC) field.

20. The node according to any one of claims 11 to 19, wherein the classification of the importance level for each PDU set comprises using at least one of: The QoS rule configuration, the XR application configuration of the video codec encoding profile, the determined PDU aggregate size, and RTP / SRTP extended header information.

21. The node of claim 20, wherein the classification of the importance level for each PDU set further comprises utilizing information comprising at least one of: an importance category determined by the QoS rule; Media bandwidth requirements; Video codec encoding constant bitrate configuration; Video codec encoding upper limit variable bit rate configuration; The video codec encoding expected bitrate configuration; Video codec encoding constant rate factor configuration; Video codec encoding maximum frame size configuration; and The video codec encodes the expected number of frames per second.

22. The node according to any one of claims 11 to 21, wherein the transmission of the plurality of PDU sets encapsulates, for each of the PDU sets, at least one of the following information within a GPRS Tunneling Protocol for User Plane (GTP-U) header field: one or more boundaries of said PDU set, an indication of the importance of the PDU set, and An indication of the size of the PDU set.

Images