PDU set importance marking in QoS flows within wireless communication networks

Abstract

A method is provided which is performed by a User Plane Function (UPF), the method comprising: receiving a configuration, the configuration comprising a protocol description including one or more media stream components and at least one default PDU set importance value; and receiving a protocol data unit (PDU) in the downlink direction, the received PDU undergoing PDU set processing according to the configuration. The method further comprises determining whether the received PDU does not necessarily match all components of the received configuration, or whether the received PDU matches the protocol description of the information but the received PDU is not part of a PDU set; and determining a PDU set importance information value, the determination being based on at least one default PDU set importance value. The method further comprises creating a header for the received PDU, wherein, in cases where the received PDU does not necessarily match all components of the received configuration, or where the received PDU matches the protocol description of the received configuration but the received PDU is not part of a PDU set, the header includes PDU set information and a determined PDU set importance information value, and routing the received PDU and header to the radio access network. Figure 13 will be published along with the summary.

Description

Technical Field

[0001] The subject matter disclosed in this specification generally relates to the field of performing PDU set importance marking in QoS flows in a wireless communication network. This specification defines user plane functions, methods performed by user plane functions, application functions, and methods performed by application functions.

Background Art

[0002] In the context of XR media traffic, the 3GPP (Registered Trademark) System Architecture WG recently considered the concept of XR multimedia sessions including multiplexed media streams. One or more PDUs corresponding to one or more media streams may not be marked by an application server (AS) with the 3GPP PDU set marking information required for QoS processing of XR traffic that recognizes application data units on 5GS. After receiving such unmarked PDUs, the user plane function (UPF) marks the individual unmarked PDUs as if they were the sole members of their own PDU sets, and can supplement the lack of PDU set information for the unmarked PDUs by adding the corresponding PDU set information, namely the PDU set sequence number, the PDU sequence number within the PDU set, the last PDU indication of the PDU set, and the PDU set importance.

[0003] PDU set importance information marks the relative importance of a PDU set to other PDU sets transported over 5GS under the same QoS flow using the same PDU set requirements. Therefore, the PDU set importance information of UPF-marked PDU sets is of significant value for 5GS processing of XR traffic, as NG-RAN can commonly use the importance value to determine prioritization and dropping strategies for resource allocation under congestion on 5GS air interfaces. [Prior art documents] [Patent Documents]

[0004] [Patent Document 1] U.S. Provisional Patent Application No. 63 / 428,026 [Patent Document 2] PCT Application No. PCT / EP2022 / 077327 [Non-patent literature]

[0005] [Non-Patent Document 1] Traffic Models and Quality Evaluation Methods for Media and XR Services in 5G Systems, 3GPP Technical Report TR26.926 (v1.3.0 - January 2023) [Non-Patent Document 2] System architecture for the 5G System (5GS), 3GPP technical specification TS23.501 (v18.1.0 - April 2023) [Non-Patent Document 3] IETF Standard RFC3550 - RTP: A Transport Protocol for Real-Time Applications [Non-Patent Document 4] IETF Standard RFC3711 - The Secure Real-time Transport Protocol (SRTP) [Non-Patent Document 5] WebRTC 1.0: Real-Time Communication Between Browsers, w3.org [Non-Patent Document 6] IETF RFC3550 - RTP: A Transport Protocol for Real-Time Applications [Non-Patent Document 7] RFC:8285: A General Mechanism for RTP Header Extensions (rfc-editor.org) [Non-Patent Document 8] Study on XR (Extended Reality) and media services, 3GPP Technical Report TR23.700-60 (v0.0.3 - May 2022) [Overview of the Initiative] [Problems that the invention aims to solve]

[0006] The problem associated with assigning default severity values ​​to PDU sets marked by UPF is that it could hinder the benefits of QoS flow PDU set processing across 5GS as a whole and on Next Generation Radio Access Networks (NG-RAN). [Means for solving the problem]

[0007] A procedure for PDU set importance marking in a QoS flow within a wireless communication network is disclosed herein. The procedure may be implemented by a user plane function, a method performed by a user plane function, an application function, and a method performed by an application function.

[0008] Accordingly, a user plane function (UPF) is provided, comprising a processor and memory coupled to the processor, wherein the memory includes instructions executable by the processor, which cause the UPF to receive a configuration, the configuration comprising a protocol description including one or more media stream components and at least one default PDU set importance value, and to receive a protocol data unit (PDU) in the downlink direction, the received PDU undergoing PDU set processing according to the configuration. The UPF may further cause the UPF to determine whether the received PDU does not necessarily match all components of the received configuration, or whether the received PDU matches the protocol description of the information but is not part of a PDU set, and to determine a PDU set importance information value, the determination being based on at least one default PDU set importance value. UPF can further create a header for the received PDU, which includes PDU set information and determined PDU set importance information values, in cases where the received PDU does not necessarily match all components of the received configuration, or where the received PDU matches the protocol description of the received configuration but the received PDU is not part of a PDU set, and can route the received PDU and header to the radio access network.

[0009] A method is further provided that is performed by a User Plane Function (UPF), the method comprising: receiving a configuration, the configuration comprising a protocol description including one or more media stream components and at least one default PDU set importance value; and receiving a protocol data unit (PDU) in the downlink direction, the received PDU undergoing PDU set processing according to the configuration. The method further comprises determining whether the received PDU does not necessarily match all components of the received configuration, or whether the received PDU matches the protocol description of the information but the received PDU is not part of a PDU set; and determining a PDU set importance information value, the determination being based on at least one default PDU set importance value. The method further comprises creating a header for the received PDU, wherein, in cases where the received PDU does not necessarily match all components of the received configuration, or where the received PDU matches the protocol description of the received configuration but the received PDU is not part of a PDU set, the header includes PDU set information and a determined PDU set importance information value; and routing the received PDU and header to the radio access network.

[0010] The application functionality is further provided, comprising a processor and memory coupled to the processor, the memory including instructions executable by the processor, which cause the AF to determine a configuration for a service data flow session for an application server (AS) having PDU set processing based on at least one request for at least one protocol description including one or more media stream components and a default PDU set importance value; to set at least one requested default PDU set importance value as either a value common to each of the one or more media stream components of the protocol description, or a separate value for each of the one or more media stream components of the protocol description; and to communicate the determined configuration to one of the policy control function (PCF) and network exposure function (NEF) to establish a service data flow session by PDU set processing on the mobile core network.

[0011] A method is further provided that is performed by an Application Function (AF), the method comprising: determining a configuration for a service data flow session for an Application Server (AS) having PDU set processing based on at least one protocol description including one or more media stream components and at least one request for a default PDU set importance value; setting at least one requested default PDU set importance value as either a value common to each of one or more media stream components of the protocol description, or a separate value for each of one or more media stream components of the protocol description; and communicating the determined configuration to one of the Policy Control Function (PCF) and Network Exposure Function (NEF) to establish a service data flow session by PDU set processing on the mobile core network.

[0012] To explain 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 several apparatuses and methods shown in the accompanying drawings. Each of these drawings merely shows some aspects of the present disclosure and should not be regarded as limiting its scope. The drawings may be simplified for clarity and are not necessarily drawn to scale.

[0013] A method and apparatus for PDU set importance marking in a QoS flow in a wireless communication network are next described merely as an example with reference to the accompanying drawings.

Brief Description of the Drawings

[0014] [Figure 1] FIG. is a diagram showing an embodiment of a wireless communication system for PDU set importance marking in a QoS flow in a wireless communication network. [Figure 2] FIG. is a diagram showing a user equipment apparatus that can be used to implement the method described herein. [Figure 3] FIG. is a diagram showing further details of a network node that can be used to implement the method described herein. [Figure 4] FIG. is a diagram showing an overview of an RTP stack and an RTCP stack. [Figure 5] FIG. is a diagram showing an overview of a WebRTC stack. [Figure 6a] FIG. is a diagram showing a packet format and header information for an RTP packet. [Figure 6b] FIG. is a diagram showing a packet format and header information for an SRTP packet. [Figure 7] FIG. is a diagram showing an RTP / SRTP header extension format and syntax. [Figure 8] FIG. is a diagram showing an overview of the core network XRM architecture processing of a PDU set. [Figure 9a]This figure illustrates the 5GS PDU Set-aware QoS processing framework for PDU set-versus-QoS flow-versus-DRB mapping. [Figure 9b] This figure illustrates the 5GS PDU set-aware QoS processing framework for PDU set vs. QoS flow vs. DRB mapping. [Figure 9c] This figure illustrates the 5GS PDU set-aware QoS processing framework for PDU set vs. QoS flow vs. DRB mapping. [Figure 9d] This figure illustrates the 5GS PDU set-aware QoS processing framework for PDU set vs. QoS flow vs. DRB mapping. [Figure 10a] This figure shows a 1-byte RTP header extension for marking PDU set information. [Figure 10b] This figure shows a 2-byte RTP header extension for marking PDU set information. [Figure 11] This figure shows an example scenario with different AF sessions for XR video applications and non-XR applications to be multiplexed by 5GS. [Figure 12] This figure illustrates an exemplary scenario with one AF session for an XR application served via WebRTC or a similar protocol, where audio and video are transmitted multiplexed over a single RTP session for the XR application. [Figure 13] This diagram shows the method in the user plane functionality. [Figure 14] This diagram shows the methods used in application functionality. [Modes for carrying out the invention]

[0015] A problem associated with assigning default severity values ​​to PDU sets marked by UPF is that it could hinder the benefits of QoS flow PDU set processing across 5GS as a whole and on next-generation radio access networks (NG-RAN).

[0016] Before delving further into the details of the techniques presented herein, it should be noted, as will be understood by those skilled in the art, that aspects of this disclosure may be embodied as systems, apparatus, methods, or program products. Accordingly, the configurations described herein may be implemented entirely in hardware form, entirely in software form (including firmware, resident software, microcode, etc.), or in a combination of software and hardware forms.

[0017] For example, the disclosed methods and apparatus may be implemented as custom very large-scale integrated ("VLSI") circuits or as hardware circuits comprising off-the-shelf semiconductors such as gate arrays, logic chips, transistors, or other discrete components. The disclosed methods and apparatus may also be implemented within programmable hardware devices such as field-programmable gate arrays, programmable array logic, or programmable logic devices. As another example, the disclosed methods and apparatus may include one or more physical or logical blocks of executable code, which may be organized as objects, procedures, or functions, for example.

[0018] Furthermore, the methods and apparatus may take the form of a program product embodied in one or more computer-readable storage devices that store machine-readable code, computer-readable code, and / or program code, which are referred to below as code. The storage devices may be tangible, non-temporary, and / or non-transmitting. The storage devices may not embody signals. In some configurations, the storage devices employ signals only for accessing the code.

[0019] Any combination of one or more computer-readable media may be used. The computer-readable media may be computer-readable storage media. The computer-readable storage media may be a storage device that stores code. The storage device may be, for example, but not limited to, a system, apparatus, or device of electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor, or any suitable combination thereof.

[0020] More specific examples (a non-exclusive list) of storage devices include, namely, electrical connections having one or more wires, portable computer diskettes, hard disks, random access memory ("RAM"), read-only memory ("ROM"), erasable programmable read-only memory ("EPROM") or flash memory, portable compact disk read-only memory ("CD-ROM"), optical storage devices, magnetic storage devices, or any suitable combination of the above. In the context of this specification, a computer-readable storage medium may be any tangible medium on which a program for use by or related to an instruction execution system, apparatus, or device may be stored or stored.

[0021] Any reference throughout this Specification to an example of a particular method or apparatus, or similar language, means that the particular feature, structure, or characteristic described in relation to that example is included in at least one implementation of the methods and apparatus described herein. Thus, any reference to an example of a particular method or apparatus, or similar language, means "one or more, but not all, examples," unless otherwise specified, and may or may not refer to all of the same example. The terms "including," "comprising," "having," and their variations mean "including, but not limited to," unless otherwise specified. Listings of items do not imply that any or all of the items are mutually exclusive unless otherwise specified. The terms "a," "an," and "the" also mean "one or more," unless otherwise specified.

[0022] As used herein, a list with the conjunction "and / or" includes any single item in the list, or any combination of items in the list. For example, the list A, B, and / or C includes A only, B only, C only, 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 any combination of items in the list. For example, one or more of A, B, and C includes A only, B only, C only, 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 unique single item from any single item in the list. For example, "one of A, B, and C" includes A only, B only, or C only, and excludes the combination of A, B, and C. When used herein, “members selected from the group consisting of A, B, and C” includes one unique individual of A, B, or C, but excludes combinations of A, B, and C. When used herein, “members selected from the group consisting of A, B, and C, and combinations thereof” includes A only, B only, C only, 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.

[0023] Furthermore, the features, structures, or properties described herein may be combined in any preferred manner. The following description provides numerous specific details, such as examples of programming, software modules, user selection, network transactions, database queries, database structures, hardware modules, hardware circuits, and hardware chips, in order to provide a full understanding of the disclosure. However, those skilled in the art will recognize that the disclosed methods and apparatus may be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not illustrated or described in detail to avoid obscuring aspects of the disclosure.

[0024] The methods and apparatuses disclosed are described below with reference to schematic flowcharts and / or schematic block diagrams of the methods, apparatuses, systems, and program products. It will be understood that each block in the schematic flowcharts and / or schematic block diagrams, as well as combinations of blocks in the schematic flowcharts and / or schematic block diagrams, can be implemented by code. This code may be provided to a general-purpose computer, a dedicated computer, or a processor of another programmable data processing device to generate a machine such that instructions executed via the processor of the computer or other programmable data processing device create means for performing the functions / operations specified in the schematic flowcharts and / or schematic block diagrams.

[0025] The code may also be stored in a storage device that can target a computer, other programmable data processing device, or other device to function in a particular way, such as to produce a product containing instructions that perform functions / operations specified in a schematic flowchart and / or schematic block diagram.

[0026] In order to generate a process to be performed by a computer, such that the code to be executed on a computer or other programmable device provides a process for performing a function / action specified in a schematic flowchart and / or schematic block diagram, the code may also be loaded onto a computer, another programmable device, or another device to cause the computer, another programmable device, or another device to perform a series of operational steps.

[0027] The schematic flowcharts and / or schematic block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of devices, systems, methods, and program products. In this regard, each block in the schematic flowcharts and / or schematic block diagrams may represent a module, segment, or portion of code containing one or more executable instructions of code for performing a specified logical function.

[0028] It should also be noted that in some alternative implementations, the functions mentioned within a block may be performed in a different order than those shown in the diagram. For example, two blocks shown consecutively may actually be executed substantially in parallel, or blocks may sometimes be executed in reverse order depending on the functions involved. Other steps and methods may be devised that are equivalent in function, logic, or effect to one or more blocks or parts of the illustrative diagram.

[0029] The descriptions of elements in each drawing may refer to elements in preceding drawings. Similar numbers refer to the same elements across all drawings.

[0030] Figure 1 shows one embodiment of a wireless communication system 100 for PDU set importance marking in a QoS flow within a wireless communication network. In one embodiment, the wireless communication system 100 includes a remote unit 102 and a network unit 104. While a specific number of remote units 102 and network units 104 are shown in Figure 1, 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 wireless communication system may comprise a wireless communication network and at least one wireless communication device. The wireless communication device is typically a 3GPP user equipment (UE). The wireless communication network may comprise at least one network node. The network node may be a network unit.

[0031] In one embodiment, the remote unit 102 may include computing devices such as desktop computers, laptop computers, personal digital assistants ("PDAs"), tablet computers, smartphones, smart televisions (e.g., Internet-connected televisions), set-top boxes, game consoles, security systems (including security cameras), in-vehicle computers, network devices (e.g., routers, switches, modems), aerial vehicles, and drones. In some embodiments, the remote unit 102 includes wearable devices such as smartwatches, fitness bands, and optical head-mounted displays. Furthermore, the remote unit 102 may be referred to as a subscriber unit, mobile, mobile station, user, terminal, mobile terminal, fixed terminal, subscriber station, UE, user terminal, device, or by 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 communication.

[0032] The network unit 104 may be distributed across geographical areas. In some embodiments, the network unit 104 may include access points, access terminals, bases, base stations, node B, eNB, gNB, home node B, relay nodes, devices, core network, airborne servers, radio access nodes, APs, NRs, network entities, access and mobility management functions ("AMF"), integrated data management functions ("UDM"), integrated data repository ("UDR"), UDM / UDR, policy control functions ("PCF"), radio access network ("RAN"), network slice selection functions ("NSSF"), operation, administration, and management ("OAM"), session management functions ("SMF"), user plane functions ("UPF"), and applications. The network unit 104 is generally part of a radio access network, which includes one or more controllers commutably coupled to one or more corresponding network units 104. The radio access network is generally commutably coupled to one or more core networks, which may be coupled to other networks such as the Internet and public switched telephone networks. These and other elements of the radio access and core networks are not illustrated but are generally well known to those skilled in the art.

[0033] In one implementation, the wireless communication system 100 conforms to the New Radio (NR) protocol standardized by 3GPP, with the network unit 104 transmitting on the downlink (DL) using orthogonal frequency division multiplexing ("OFDM") modulation, and the remote unit 102 transmitting on the uplink (UL) using single-carrier frequency division multiple access ("SC-FDMA") or OFDM. However, more generally, the wireless communication system 100 may implement several other open or proprietary communication protocols, such as WiMAX, IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA2000, Bluetooth®, ZigBee, Sigfox, and LoraWAN. This disclosure is not intended to limit to any particular wireless communication system architecture or protocol implementation.

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

[0035] Figure 2 shows a user device 200 that may be used to carry out the method described herein. The user device 200 is used to carry out one or more of the solutions described herein. The user device 200 is one or more of the user devices described in the embodiments herein. In particular, the user device 200 may include a remote unit 102, UE835, 1035, or 1135 as described herein. The user device 200 includes a processor 205, memory 210, input device 215, output device 220, and transceiver 225.

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

[0037] As shown in the figure, the transceiver 225 includes at least one transmitter 230 and at least one receiver 235. The transceiver 225 may communicate with one or more cells (or wireless coverage areas) supported by one or more base units. The transceiver 225 may be capable of operating on unlicensed spectrum. Furthermore, the transceiver 225 may include multiple UE panels supporting one or more beams. In addition, the transceiver 225 may support at least one network interface 240 and / or application interface 245. The application interface 245 may support one or more APIs. The network interface 240 may support 3GPP reference points such as Uu, N1, PC5, etc. Other network interfaces 240 may be supported as will be understood by those skilled in the art.

[0038] The processor 205 may include any known controller capable of executing computer-readable instructions and / or logical operations. For example, the processor 205 may be a microcontroller, microprocessor, central processing unit ("CPU"), graphics processing unit ("GPU"), auxiliary processing unit, field-programmable gate array ("FPGA"), or similar programmable controller. The processor 205 may execute instructions stored in memory 210 to perform the methods and routines described herein. The processor 205 is communicatively coupled to memory 210, input device 215, output device 220, and transceiver 225.

[0039] The processor 205 may control the user device 200 to perform the user device behavior described herein. The processor 205 may include an application processor (also called the "main processor") that manages application domain and operating system ("OS") functions, and a baseband processor (also called the "baseband radio processor") that manages radio functions.

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

[0041] Memory 210 may store data relating to the implementation of traffic category fields as described herein. Memory 210 may also store program code and related data, such as an operating system or other controller algorithms running on device 200.

[0042] The input device 215 may include any known computer input device, including touch panels, buttons, keyboards, styluses, microphones, etc. The input device 215 may be integrated with the output device 220, for example, as a touchscreen or similar touch-sensitive display. The input device 215 may include a touchscreen on which text can be entered using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. The input device 215 may include two or more different devices, such as a keyboard and a touchscreen.

[0043] The output device 220 may be designed to output visual signals, acoustic signals, and / or tactile signals. The output device 220 may include an electronically controllable display or display device capable of outputting visual data to the 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 the user. As another non-limiting example, the output device 220 may include a wearable display, such as a smartwatch, smart glasses, or a head-up display, that is separate from the rest of the user equipment device 200 but communicatively coupled to it. Furthermore, the output device 220 may be a component of a smartphone, personal digital assistant, television, table computer, notebook (laptop) computer, personal computer, vehicle dashboard, etc.

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

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

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

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

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

[0049] Figure 3 shows further details of a network node 300 that may be used to implement the method described herein. The network node 300 may be one implementation of an entity in a wireless communication network, for example, in one or more of the wireless communication networks described herein. The network node 300 may include network units 104 or user plane functions (UPFs) as described herein, such as UPFs 1040 and 1140. The network node 300 includes a processor 305, memory 310, input device 315, output device 320, and transceiver 325.

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

[0051] As shown in the figure, the transceiver 325 includes at least one transmitter 330 and at least one receiver 335, where the transceiver 325 communicates with one or more remote units 200. In addition, the transceiver 325 may support at least one network interface 340 and / or application interface 345. The application interface 345 may support one or more APIs. The network interface 340 may support 3GPP reference points such as Uu, N1, N2, N3, and N6. Other network interfaces 340 may be supported as will be understood by those skilled in the art.

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

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

[0054] Memory 310 may store data relating to establishing a multipath unicast link and / or mobile operation. For example, memory 310 may store parameters, configurations, resource allocations, policies, etc., as described herein. Memory 310 may also store program code and related data, such as operating systems or other controller algorithms running on network node 300.

[0055] The input device 315 may include any known computer input device, including touch panels, buttons, keyboards, styluses, microphones, etc. The input device 315 may be integrated with the output device 320, for example, as a touchscreen or similar touch-sensitive display. The input device 315 may include a touchscreen on which text can be entered using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. The input device 315 may include two or more different devices, such as a keyboard and a touchscreen.

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

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

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

[0059] In the context of XR media traffic, the 3GPP System Architecture WG recently considered the concept of an XR multimedia session involving multiplexed media streams. One or more PDUs corresponding to one or more media streams may not be marked by the Application Server (AS) with the 3GPP PDU set marking information necessary for QoS processing of XR traffic that recognizes application data units on 5GS. Upon receiving such unmarked PDUs, the User Plane Function (UPF) can compensate for the lack of PDU set information for unmarked PDUs by marking the individual unmarked PDUs as if they were sole members of their own PDU set, and adding the corresponding PDU set information, namely the PDU set sequence number, PDU sequence number within the PDU set, trailing PDU indication of the PDU set, and PDU set importance.

[0060] PDU set importance information marks the relative importance of a PDU set to other PDU sets transported over 5GS under the same QoS flow using the same PDU set requirements. Therefore, the PDU set importance information of UPF-marked PDU sets is of significant value for 5GS processing of XR traffic, as NG-RAN can commonly use the importance value to determine prioritization and dropping strategies for resource allocation under congestion on 5GS air interfaces.

[0061] As a result, assigning static default importance values ​​to PDU sets marked by UPF is a suboptimal solution that may hinder the benefits of QoS flow PDU set processing across 5GS and next-generation radio access networks (NG-RAN). This problem tends to be solved by the methods and apparatus presented herein using proposed mechanisms and methods for UPF, which should be configured on the fly for XR multimedia sessions, to assign specific, and even optimized, default PDU set importance values ​​for PDU sets marked by UPF.

[0062] In the following, Augmented Reality (XR) will be used as a comprehensive term for different types of reality, such as virtual reality, augmented reality, and mixed reality.

[0063] Virtual reality (VR) is a rendered version of a delivered visual and audio scene. The rendering is designed to mimic real-world visual and audio perceptual stimuli as naturally as possible as the viewer or user moves within the limits defined by the application. Virtual reality typically requires, though not always, the user to wear a head-mounted display (HMD) to completely replace the user's field of view with simulated visual components and headphones to provide the user with accompanying audio. Some forms of head tracking and motion tracking in VR are also typically necessary to ensure, from the user's perspective, that objects and sound sources remain in sync with the user's movements, allowing the simulated visual and audio components to be updated. Some implementations may, but are not strictly required, provide additional means for interacting with the virtual reality simulation.

[0064] Augmented reality (AR) is when additional information or artificially generated objects, or content superimposed on the user's current environment, is provided to the user. Such additional information or content is typically visual and / or acoustic, and the user's observation of the user's current environment may be direct, without intermediate sensing, processing, and rendering, or it may be indirect, where the user's perception of the user's environment is relayed, augmented, or processed via sensors.

[0065] Mixed Reality (MR) is an advanced form of augmented reality in which several virtual elements are inserted into a physical scene with the intention of creating the illusion that these elements are part of the real-world scene.

[0066] XR refers to all real and virtual environments and human-machine interactions generated by computer technology and wearables. XR includes representative forms such as AR, MR, and VR, as well as areas interpolated between them. Levels of virtuality range from partially perceptual input to fully immersive VR. In some areas, the primary aspect of XR is seen as an extension of human experience, particularly related to the perception of presence (represented by VR) and the acquisition of awareness (represented by AR).

[0067] In 3GPP Release 17, SA4 analyzed XR traffic models as described in 3GPP Technical Report TR26.926 (v1.3.0 - January 2023), entitled "Traffic Models and Quality Evaluation Methods for Media and XR Services in 5G Systems," and concluded QoS requirements regarding latency budget, data rate, and error rate necessary for a satisfactory experience at the application level. These resulted in four additional 5Qi for 5GS XR QoS flows, rated as latency-constrained GBR 5Qi between 87 and 90. These are described in 3GPP Technical Specification TS23.501 (v18.1.0 - April 2023), entitled "System architecture for the 5G System (5GS)," and in detail in Table 5.7.4-1. The latter is applicable to XR video streams and controls the metadata necessary to deliver immersive and interactive XR experiences.

[0068] XR video traffic primarily consists of multiple DL / UL video streams with high resolution (e.g., typically at least 1080p with dual-eye buffers), frames per second (e.g., 60+ fps), and high bandwidth (e.g., typically at least 20-30 Mbps), which need to be transmitted across the network with minimal latency (usually capped at 15-20 ms) to maintain reduced end-to-end application round-trip interaction latency. The latter requirement is critically important if there is any XR application dependency on cloud / edge processing (e.g., content download, viewport generation and configuration, viewport updates, viewport rendering, media encoding / transcoding, etc.).

[0069] The traffic of immersive and interactive XR applications, such as those described above, often requires transport architectures and protocols suitable for real-time use. The latter is represented by the following technologies: real-time transport protocols (such as RTP, as defined in IETF standard RFC3550 - RTP: A Transport Protocol for Real-Time Applications), secure real-time transport protocols that are securely provisioned (such as SRTP, as defined in IETF standard RFC3711 - The Secure Real-time Transport Protocol), and web-targeted stack web real-time communication (WebRTC 1.0, as defined by w3.org in Real-Time Communication Between Browsers).

[0070] RTP is a media codec agnostic network protocol with application layer framing used to deliver multimedia data (e.g., audio, video, etc.) in real time over IP networks. RTP is used with its sister protocol for control, namely the Real-Time Transport Control Protocol (RTCP), to provide end-to-end functionality such as jitter compensation, packet loss and out-of-order delivery detection, synchronization, and source stream multiplexing.

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

[0072] SRTP is a secure version of RTP, defined by the IETF in RFC 3711, "The Secure Real-time Transport Protocol (SRTP)". SRTP provides encryption (primarily through payload secrecy), message authentication and integrity protection (by signing the PDU, i.e., the header and payload), and replay attack protection. Like RTP, SRTP's sister protocol is SRTCP, which provides the same functionality as its RTCP counterpart. Therefore, in the simplified SRTP version, RTP header information is still accessible but immutable, while the payload is encrypted. These security provisions are shown in the upper right section of Figure 3. Furthermore, the key exchange and additional security parameters required to use SRTP are based on the Datagram Transport Layer Security (DTLS) key exchange procedure. For these reasons, SRTP is used as the transport protocol for media within the WebRTC stack, ensuring secure RTC multimedia communication over a web browser interface.

[0073] Figure 5 shows an overview of the WebRTC stack. As illustrated, the IP layer 505 carries signaling from the data plane 510 and control plane 550. The data plane stack 510 provides functionality for User Datagram Protocol (UDP) 512, Interactive Connectivity Establishment (ICE) 524, Datagram Transport Layer Security (DTLS) 526, SRTP 517, SRTCP 515, media codecs 520, quality control 522, and SCTP 528. ICE 524 may use the Session Traversal Utilities for NAT (STUN) protocol and Traversal Using Relays around NAT (TURN) to handle real-time media content delivery across heterogeneous networks and NAT rules and firewalls. The SCTP data plane 728 is primarily dedicated as an application data channel and may be non-time critical. The SRTP-based stack 517 and its control elements, namely SRTCP 515, encoding, i.e., media codecs, and quality of service (QoS), i.e., quality control, are dedicated to time-critical transport. The control plane 550 stack provides functionality for Transmission Control Protocol (TCP) 554, Transport Layer Security (TLS) 556, Hypertext Transfer Protocol (HTTP) 558, WebSockets 566, Session Initiation Protocol (SIP) 562, Session Description Protocol (SDP) 564, Server Sending Events (SSE) 568, and Extensible Messaging and Presence Protocol (XMPP) 570.

[0074] Figure 6a shows the packet format and header information for RTP packet 630, and Figure 6b shows the packet format and header information for SRTP packet 660. Individual fixed header information and complete header information (including header extensions) are briefly summarized for RTP / SRTP packets as follows:

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

[0076] The "V" in 632 and 662 are two bits that indicate the protocol version being used.

[0077] "P" 633, 663 is a 1-bit field that indicates the presence of one or more zero-padding octets at the end of the payload, thereby indicating that padding may be necessary, in particular for fixed-size encryption blocks or for carrying multiple RTP / SRTP packets over lower-layer protocols.

[0078] The "X" 634, 664 is a single bit that indicates that an RTP header extension, typically associated with a specific data / profile that carries more information about the data (for example, an RTP header extension for video data (as defined in IETF RFC3711 - The Secure Real-time Transport Protocol (SRTP)) or a frame that marks a comprehensive RTP header extension such as an RTP / SRTP extension protocol (as defined by w3.org in WebRTC 1.0: Real-Time Communication Between Browsers)), follows a standard fixed RTP / SRTP header.

[0079] "CC" 636, 666 are 4-bit fields that indicate the number of contributing media sources (CSRCs) following the fixed header.

[0080] The "M" bits 638 and 668 are single bits intended to mark information frame boundaries within a packet stream, and their behavior is strictly specified by the RTP profile (e.g., H.264, H.265, H.266, AV1, etc.).

[0081] "PT" 640, 670 are 7 bits (e.g., 96 for H.264, 97 for H.265, 98 for AV1, etc.) that are dynamic in the case of video profiles and indicate the payload type negotiated by SDP.

[0082] The "sequence numbers" 642 and 672 are 16 bits that represent sequence numbers that increment by 1 each time an RTP data packet is sent through the session.

[0083] The "timestamp" 644, 674 is a 32-bit timestamp in tick units of the payload type clock, reflecting the sampling moment of the first octet of the RTP data packet (associated with a video frame for a video stream), and the first timestamp of the first RTP packet is randomly selected.

[0084] The "Synchronization Source (SSRC) Identifiers" 646 and 676 are 32-bit fields that represent random identifiers for the source of a stream of RTP packets that form part of the same timing and sequence number space, allowing the receiver to group packets based on the synchronization source for playback.

[0085] The "Contributing Source (CSRC) identifiers" 648, 678 are a list of up to 16 32-bit CSRC entries, each given the amount of CSRC mixed by the RTP mixer in the current payload, as signaled by the CC bit. The list identifies the contributing source for the payload contained in this packet, given the contributing source's CSRC identifier.

[0086] The complete header information (including header extensions) includes "RTP Header Extensions" 648, 678.

[0087] The "RTP Header Extensions" 648 and 678 are variable-length fields that exist if the X bit is marked. The header extensions are appended to the RTP fixed header information, after the CSRC list, if present. The RTP header extensions consist of the following fields: A 16-bit extended identifier defined by the profile and typically negotiated and determined via the Session Description Protocol (SDP) signaling mechanism. A 16-bit length field that describes the extended header length in 32-bit multiples, excluding the first 32 bits corresponding to the 16-bit extended identifier and the 16-bit length field itself, as well as A 32-bit aligned header extension raw data field formatted according to several RTP header extension identifier designation formats. The alignment and formation result in 32 bits.

[0088] Figure 7 shows the RTP / SRTP header extension format and syntax 700. The RTP header extension format and syntax are similar to those of SRTP. These schematics are provided in common as shown in Figure 7. In addition, in both RTP and SRTP, only one RTP extension header may be appended to the fixed header information, as specified in IETF RFC3550 - RTP: A Transport Protocol for Real-Time Applications. However, for both RTP and SRTP, extensions to the base protocol exist to allow multiple RTP header extensions of a given type to be appended to the protocol's fixed header information, as specified in RFC:8285: A General Mechanism for RTP Header Extensions (rfc-editor.org).

[0089] In some embodiments, RTP header extensions generated at the source may be ignored by the destination endpoint, which does not have the knowledge to interpret and process RTP header extensions sent by the source endpoint.

[0090] The consideration of XR media (XRM) at the CN level in Release 18 of the 3GPP technical standards introduced the concept of PDU sets to handle the QoS requirements of XRM applications and streams with a better granularity than QoS flow feasibility. Thus, according to 3GPP Technical Report TR23.700-60(v0.0.3), a PDU set consists of one or more PDUs that carry the payload of a single unit of information generated at the application level (e.g., a frame or video slice for an XRM service). In some implementations, all PDUs in a PDU set are required by the application layer to use the corresponding unit of information. In other implementations, the application layer can still reconstruct some or all of the information unit when some PDUs are missing.

[0091] In addition, PDU sets are associated with QoS requirements with respect to delay budgets and error rates, which may be specified as PDU set delay budgets (PSDB) and / or PDU set error rates (PSER), as defined in 3GPP Technical Report TR23.700-60 (v0.0.3 - May 2022) entitled "Study on XR (Extended Reality) and media services" and 3GPP Technical Specification TS23.501 (v18.1.0 - April 2023) entitled "System architecture for the 5G System (5GS)". The PDU set delay budget (PSDB) specifies the upper limit on the amount of time a PDU set may be delayed between the UE and the N6 termination point in the UPF. The PSDB applies to DL PDU sets received by the UPF via the N6 interface and to UL PDU sets sent by the UE, respectively. The PDU Set Error Rate (PSER) defines an upper limit on the rate of PDU sets (e.g., a set of IP packets that make up a PDU set) being processed by the sender of a link-layer protocol (e.g., the RLC in the RAN of 3GPP access). PSER may also be used to determine an upper limit on the rate of packet loss that is not related to congestion.

[0092] Figure 8 shows an overview of the core network (CN)XRM architecture processing for a PDU set. Figure 8 shows a system 800 comprising an Augmented Reality Media Application Function (XRM AF) 810, a Policy and Control Function (PCF) 815, a Session Management Function (SMF) 820, an Access and Mobility Function (AMF) 825, a Radio Access Network (RAN) 830, a User Equipment (UE) 835, a User Plane Function (UPF) 840, and an Augmented Reality Application 845. The UE 835 may comprise a remote unit 102, a user equipment device 200, and a UE 1035 or 1135 as described herein. The UPF 840 may comprise a network unit 104, a network node 300, or a User Plane Function (UPF) as described herein, such as UPF 1040 and 1140. The operation of system 800 is described next with an example of downlink traffic, and a similar process may operate for uplink traffic.

[0093] In version 880, the XRM AF810 determines the PDU set requirements.

[0094] In 881, the XRM application function 810 provides the PCF 815 with QoS requirements for packets in the PDU set, and information for identifying the application (i.e., a 5-tuple or application ID). The QoS requirements may include PSDB and PSER. The XRM AF 810 may also include severity parameters for the PDU set, and information for the core network to identify packets belonging to the PDU set.

[0095] In 882, PCF815 derives QoS rules for XR applications and specific QoS requirements for PDU sets, configuring SMF820. The QoS rules may use 5G QoS identifiers (5QI) for XR media traffic. PCF815 sends the QoS rules to SMF820. PCF815 may include PCC rules in its communication to SMF820 for each severity level of the PDU set. PCC rules may be derived according to information received from XRM AF810 or based on the carrier configuration.

[0096] In 883, SMF820 configures the UPF to establish a QoS flow according to the QoS rules of PCF815, route XR application packets to the QoS flow, and also enable PDU set processing. SMF820 also provides a QoS profile, including PDU set QoS requirements, to RAN830 via AMF825. AMF825 may provide the QoS profile, including PDU set QoS requirements, to RAN830 within the N2 SM container. Furthermore, AMF825 may provide the QoS rules to UE835 within the N1 SM container.

[0097] In 884, UPF840 inspects packets and determines which packets belong to a PDU set. Packet inspection may include inspecting RTP packets. When UPF840 detects packets belonging to a PDU set, it marks them as belonging to the PDU set in the GTP-U header. The GTP-U header information includes the PDU set sequence number and size of the PDU set. UPF840 may also determine the importance of a PDU set based on information provided by the UPF840 implementation, the XRM AF810, or metadata provided by the XRM application server. Based on the importance of a PDU set, UPF840 may route traffic to the corresponding QoS flow 1 (according to rules received from SMF820), or may include the importance of the PDU set in the GTP-U header. QoS flow 1 may have GTP-U headers, which may include PDU set information.

[0098] In 885, RAN830 identifies packets belonging to a PDU set (based on GTP-U marking) and processes the packets of the PDU set according to the QoS requirements of the PDU set provided by SMF820. In one implementation, a RAN830 node may use different radio bearers with higher QoS requirements (according to PDU set PSDB / PSER) to ensure the delivery of packets of a PDU set, while using different radio bearers for non-PDU set packets according to the 5QI of the QoS flow. RAN830 may receive the QFI and QoS profile of the QoS flow from SMF820 (via AMF825) during PDU session establishment / modification, including PDSB and PSER. RAN830 inspects the GTP-U header to ensure that all packets of the same PDU set are processed according to the QoS profile. This means that packets of a PDU set may be included in the radio bearer carrying QoS flow 1. This also means that packets not belonging to that PDU set may be sent in a different radio bearer carrying QoS flow 2.

[0099] The above example concerns downlink (DL) traffic. The opposing processing is applicable to uplink (UL) traffic, where the role of UPF840 packet inspection is taken over by UE835, which is expected to inspect uplink packets, determine which packets belong to a PDU set, and signal the PDU set accordingly to RAN830 for scheduling and resource allocation in accordance with relevant DRB performance that can fulfill PDU set QoS requirements (i.e., PSDB and PSER). The low-level signaling mechanism related to the information transfer from UL UE to RAN is the responsibility of the specification and implementation of the RAN signaling procedure.

[0100] Figures 9a–9d illustrate the 5GS PDU set-aware QoS processing framework for PDU set-versus-QoS flow-versus-DRB mapping. Given two distinct PDU sets with different PDU set attributes, such as PDU set importance, depending on the QoS flow mapping and RAN procedure, several alternative PDU set-versus-QoS flow-versus-DRB mappings are possible. Figure 9 shows several options where two PDU sets 910 with different importance and characteristics are mapped to a QoS flow 920 and, respectively, to a data radio bearer (DRB) 930. In this example, we consider PDU set 1 to be of high importance with strict QoS requirements (i.e., PSDB, PSER, etc.), and PDU set 2 to be of low importance with potentially lower QoS requirements (i.e., PSDB, PSER, etc.) than PDU set 1. As shown in Figure 9, the mapping of PDU set 910 to QoS flow 920 to DRB 930 can take the following instantiations depending on the QoS flow policy and Layer 2 RAN procedure.

[0101] Figure 9a shows a one-to-one-to-one mapping, which ensures separation between QoS flow 920 and DRB 930 between high-priority PDU set 910 and low-priority PDU set 910, allowing for fine-grained optimization of wireless and network resources for each PDU set.

[0102] Figure 9b shows an M-to-M-to-1 mapping, where separation between high-priority and low-priority PDU sets 910 is performed only at the QoS flow level, but the same DRB930 is used for over-the-air transmission for both PDU sets 910, which can lead to over-provisioning of radio resources for the low-priority PDU sets 910, and may require less RAN complexity and management overhead.

[0103] Figure 9c shows an M-to-1-to-1 mapping, which means there is no separation between the QoS flow 920 and DRB 930 for PDU sets 910 with different levels of importance. When handling QoS management across both CN and RAN, the QoS requirements of the more important PDU set are prioritized. This can lead to over-provisioning of resources for less important PDU sets 910 in both CN and RAN implementations, although it may require less overhead and control within the 5GS QoS framework.

[0104] Figure 9d shows an M-to-1-to-M mapping, where there is no separation across QoS flows 920 between PDU set importance levels, and yet another separate DRB 930 is used to address the individual requirements of each separate importance level. This allows for a compromise in QoS flow management complexity, better alignment with QoS requirements at the RAN level, and optimization of resource allocation according to individual PDU set needs by filtering PDU sets 910 on different DRB 930 using PDU set information.

[0105] In addition, RAN Layer 2 procedures may use PDU set importance attributes and related information to prioritize PDU sets. In one example, the prioritization strategy may take the form of dropping lower-priority PDU sets when RAN congestion exists. In other examples, the RAN may use alternative prioritization strategies in resource allocation as needed for each different gNB implementation, thereby leveraging PDU set importance information to determine resource allocation strategies for PDU sets of varying importance.

[0106] Determining the PDU set is a prerequisite for controlling the PDU set flow through 5GS and implicitly controlling the QoS flow versus DRB mapping within the QoS 5GS framework. Therefore, to support PDU set-based QoS processing, the PDU session anchor (PSA) UPF identifies the PDUs belonging to the PDU set and determines the PDU set information it sends to the NG-RAN in the GTP-U header. The PDU set information is used by the NG-RAN for PDU set-based QoS processing as described above.

[0107] The PDU set information includes some of the following combinations. • PDU set sequence number (PSSN) • Display of PDU(E) at the end of the PDU set • PDU Sequence Number (PSN) within the PDU set • PDU set size in bytes (PSSize) PDU Set Importance (PSI) identifies the relative importance of a PDU set compared to other PDU sets within a QoS flow. • Data Burst End (EDB) information, which marks the end of a data burst. This means that a data burst is a set of multiple PDUs generated and sent by an application so that there is an idle (i.e., silent, paused, or alternatively inactive) period between two data bursts. As a result, a data burst can consist of one or more sets of PDUs.

[0108] The lower layers of the RAN can further utilize the PDU set importance marked within the QoS flow for PDU set-level packet discarding when congestion exists on the wireless air interface. Furthermore, interrelationships between PSIs across multiple QoS flows may be taken into consideration.

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

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

[0111] In some implementations, 5GS includes the AS marking of the PDU set and related information in the RTP header extension in accordance with IETF RFC 8285, as detailed previously. This can be in either a one-byte or two-byte format, as shown in Figures 10a and 10b.

[0112] Figure 10a shows an example of a 1-byte RTP header extension 1000 for marking PDU set information. Figure 10b shows an example of a 2-byte RTP header extension 1050 for marking PDU set information.

[0113] The semantics associated with the PDU set information field of the RTP header extension syntax, which are schematicly shown in Figures 10a and 10b, are as follows:

[0114] "E" 1032 is a one-bit representation of a Boolean flag that is set to 1 for the last PDU in a PDU set and to 0 for all other PDUs in the PDU set.

[0115] "EDB" 1034 is a 3-bit representation of the data burst suffix. The 3 bits can encode the data burst suffix according to the encoding and guidelines specified in section 4.4.2.6.1 of the 3GPP technical specification TS 26.522, titled "5G Real-time Media Transport Protocol Configurations".

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

[0117] The "PSSN" 1040 contains a 10-bit representation that encodes the sequence number of the PDU set to which the current PDU belongs, serving as a 10-bit numerical identifier for the PDU set. The PSSN may take a value between 0 and 1023, and although in some examples the value may wrap around 1023, a receiver (e.g., UPF) can use the combination of the RTP packet sequence number and the PSSN to uniquely distinguish any PDU set.

[0118] "PSN" 1042 is a 6-bit representation of the sequence number of the current PDU in a PDU set. The PSN is set to 0 for the first PDU in the PDU set and is monotonically incremented for all PDUs in the PDU set in the order of transmission from the sender. The receiver (e.g., UPF, or alternatively, gNB in ​​some examples) may use the RTP packet sequence number along with the PSN to distinguish PDUs in a PDU set containing more than 64 PDUs.

[0119] "PSSize" 1044 is a 24-bit representation indicating the total size of all PDUs in the PDU set to which this PDU belongs. This field is optional and, following offer / answer negotiation in SDP signaling, may indicate whether the AS can provide the size of the PDU set for the RTP stream, or alternatively, for the RTP session. If not enabled in some embodiments, this field does not exist. However, if enabled in some embodiments, and the AS cannot determine the PDU size for a particular PDU set, the AS sets the value to 0 for all PDUs in that PDU set. In some implementations, PSSize indicates the size of the PDU set including the RTP / UDP / IP header encapsulation overhead of its corresponding PDU. Alternatively, PSSize indicates the sum of the RTP payload sizes of all PDUs present in the PDU set. PSSize is expressed in bytes. This field is optional and is appended to the RTP header extension, so its presence is, for example, ``` a=extmap:1 sendonly urn:3gpp:pdu-set-marking:rel-18 pdu-set-size ``` As shown above, the "pdu-set-size" extension attribute is negotiated and signaled via the SDP offer / answer procedure.

[0120] However, the currently defined architecture lacks some of the technical details necessary to resolve QoS flows that must transport both PDU set-marked and non-PDU set-marked traffic. There are two possible scenarios, Scenario #1 (different AF sessions) shown in Figure 11 and Scenario #2 (same AF session) shown in Figure 12.

[0121] Scenario #1 involves different AF sessions. A QoS flow established using a PDU set QoS parameter configuration (for example, by the Nnef_AFsessionWithQoS service) may also satisfy the QoS requirements of another AF session (which may or may not belong to the same XR application) with similar PDBs and PERs to the PDUs enclosed in the PDU set. In such cases, the operator's general policies and PCC rules may assign PDU set marked PDUs and non-PDU set marked PDUs to the same QoS flow.

[0122] Figure 11 shows an example scenario with different AF sessions for XR video applications and non-XR applications being multiplexed by 5GS under current PCF policies and PCC rules via the same QoS flow, i.e., QoS flow 1, which satisfies both the PSDB and PSER requirements for PDU set-marked XR service traffic and the PDB and PER requirements for non-PDU set-marked non-XR service traffic.

[0123] Figure 11 shows Scenario #1, which represents two different AF sessions combining PDU set-marked PDUs and non-PDU set-marked PDUs via a QoS flow having the same QoS parameters. The illustrated system 1100 comprises PCF 1115, SMF 1120, UPF 1140, RAN 1130, UE 1135, XR video application 1145, and non-XR video application 1147. UE 1135 may include a remote unit 102, user equipment device 200, UE 835 or 1235 as described herein. UPF 1140 may include a network unit 104, network node 300, or user plane functions (UPF) as described herein, such as UPF 840 and 1240. XR video application 1145 transmits I frames as multiple PDUs, and the PDUs are grouped to form a PDU set. The XR video application 1145 also transmits P frames as multiple PDUs, and these PDUs are also grouped to form a PDU set. The non-XR application 1147 transmits other data as multiple PDUs, and these PDUs are grouped to form further PDU sets. The UPF 1140 is configured to receive PDUs from both the XR video application 1145 and the non-XR video application 1147 and to transmit PDUs to the RAN 1130, with the QoS flow having PDSB / PSER requirements. The UPF 1140 includes PDU set information in the PDUs from the XR video application 1145. The UPF 1140 does not include PDU set information in the PDUs from the non-XR application 1147. The RAN 1130 transmits the PDUs to the UE 1135 via the Uu radio bearer.

[0124] Scenario #2 involves the same AF session. A QoS flow established using a PDU set QoS parameter configuration (for example, by the Nnef_AFsessionWithQoS service) may be exposed to both PDU set marked traffic and non-PDU set marked traffic. This can occur, for example, in the case of a WebRTC service where multiple media streams are multiplexed over a single RTP stream served through one AF session instance. Alternatively, this can also occur for media streams belonging to the same XR application (i.e., sharing an application ID) that are mapped to the same QoS flow once their 5-tuples and QoS requirements are given. For example, a multi-camera capture system for 360-degree surround video, or alternatively, at least two cameras for 2D+ depth video information, may be used in parallel over different RTP streams. In any of these examples, a common use case is that at least one of the media streams does not contain PDU set markings. For example, this might be because a PDU set may not support certain video codec specifications (e.g., VP8, VP9, ​​AV1), certain audio codec specifications (e.g., OPUS), certain multimedia codec specifications (e.g., tactile codecs), or alternatively, any multimedia codec specifications other than video (e.g., audio codecs, tactile codecs, etc.).

[0125] Figure 12 shows an exemplary scenario with the same AF session for an XR application served via WebRTC, where audio (e.g., OPUS encoded bitstream) and video (e.g., H.264 constrained baseline encoded bitstream) are transmitted multiplexed over a single RTP stream for the XR application.

[0126] Figure 12 shows Scenario #2, which represents a single AF session multiplexing PDU set-marked and non-PDU set-marked PDUs via a QoS flow having the same QoS parameters. The illustrated system 1200 comprises a PCF 1215, SMF 1220, UPF 1240, RAN 1230, UE 1235, and an XR video application 1245. The XR video application 1245 comprises a WebRTC application. The UE 1235 may comprise a remote unit 102, user equipment 200, and UE 835 or 1135 as described herein. The UPF 1240 may comprise a network unit 104, a network node 300, or user plane functions (UPFs) as described herein, such as UPF 840 and 1140. The XR video application 1245 transmits I frames as multiple PDUs, and the PDUs are grouped to form a PDU set. The XR video application 1245 also transmits P-frames as multiple PDUs, and these PDUs are also grouped to form a PDU set. The XR application 1245 further transmits non-video frame information as multiple PDUs, and these PDUs are grouped to form yet another PDU set. The non-video frame information may include, for example, an audio OPUS codec and / or AR metadata that is not marked with PDU set information. The UPF 1240 is configured to receive PDUs from the XR video application 1245 and transmit PDUs to the RAN 1230, and the QoS flow has PDSB / PSER requirements. The UPF 1240 includes PDU set information in PDUs from the XR video application 1245 that contain video information. The UPF 1240 does not include PDU set information in PDUs from the XR video application 1245 that relate to non-video frame information. The RAN 1230 transmits the PDUs to the UE 1235 via the Uu radio bearer.

[0127] Referring to Figures 11 and 12, the two scenarios described above demonstrate that on a DRB mapped to a QoS flow with PDU set functionality enabled for XR applications, the RAN may receive mixed packets, i.e., some of which are marked with PDU set information and some of which are not. Packets not marked with PDU set information (i.e., PDUs) are sometimes called "legacy packets." These legacy packets are still processed under the same QoS characteristics of the QoS flow (i.e., PSDB, PSER, PER, and at least PDB, respectively). As a result, the RAN complexity increases because different processing and scheduling of radio resources are required for packets belonging to the same QoS flow.

[0128] Furthermore, the 3GPP RAN has decided to eliminate such complexity in 5GS at lower layers by taking out mapping M-1-M, shown in Figure 9d, where packets in a QoS flow are thereby divided across multiple DRBs, from the scope of further normative specifications. Different treatment of packets at the radio level in the same QoS flow is not currently possible in this way. Therefore, the QoS policy and PDU set marking functions within 5GS need to be further mitigated while maintaining less complexity at the RAN level and achieving a good trade-off between complexity and performance at the system level.

[0129] Nevertheless, particularly for Scenario #2, the importance value of UPF-marked PDU sets has a very important correlation with 5GS. This value needs to be determined with respect to AS-marked PDU sets mapped to the same QoS flow for the AF session. Therefore, the importance value requires consistency across the entire multiplexed data flow for correlated and consistent processing by gNB and RAN Layer 2 procedures for different RTP multiplexed media streams, or alternatively, all PDU sets belonging to the data session.

[0130] Methods and apparatus that tend to address the above issues by introducing the concept of a common default severity value for one or more multiple data flows, or alternatively, for QoS flows including RTP streams, as part of an AF session are presented herein.

[0131] This specification describes a method and apparatus for providing unified PSI processing for PDU sets originating from one or more data flows multiplexed on a common AF session, mapped to QoS flows by common PDU set QoS requirements, namely, the requirements for PDU set delay budget (PSDB), PDU set error rate (PSER), and PDU set integrated processing indicator (PSIHI), as described in Section 5.7.7 of 3GPP TS 23.501 (v18.1.0, April 2023), entitled "System architecture for the 5G System (5GS)". For this purpose, a default PSI value is defined. The default PSI is applied by the UPF when marking unmarked PDUs in the AF session in the PDU set information.

[0132] The default PSI value may be statically and implicitly determined per QoS flow by the PDU set requirements. Alternatively, the default PSI value may be semi-statically determined by the AF and signaled to 5GS. Furthermore, this value may be common to multiple data flows multiplexed under an AF session; alternatively, each data flow may have a default severity value based on the protocol description.

[0133] UPF may use the default PSI value to mark unmarked PDUs in an AF session in the PDU set information, including the PSI field that is marked with the default PSI value.

[0134] Default PSI values ​​for QoS flows with PDU set requirements are described herein. In one example, the UPF receives an N4 rule from the SMF. The N4 rule contains information to assist the UPF in identifying how packets received in the downlink direction should be routed through an established QoS flow, and whether PDU set information should be added to any packets sent through a QoS flow with a specific PDU set QoS requirement.

[0135] The SMF determines the N4 rules based on the PCC rules provided by the PCF. The PCF determines the PCC rules based on the PDU set QoS requirements for application user plane sessions to the UE via the 3GPP network (i.e., AF sessions). The PDU set QoS requirements are provided in some embodiments by application functions (AFs) that interface with the PCF, for example via the N5 interface and API, or alternatively, with the NEF, for example via the N33 interface and API.

[0136] For example, the QoS requirements for an AF session PDU set may include PSDB, PSER, and PSIHI parameters. In addition, AF provides a protocol description. In some embodiments, the protocol description indicates at least the protocol attributes (e.g., RTP / SRTP) and payload type attributes (e.g., H.264, H.265) of the AF session. Thus, the protocol description used by the service data flow indicates to the UPF, via derived PCC rules and associated N4 SMF rules, that it is necessary to support the QoS requirements for a particular set of PDUs on the 3GPP network.

[0137] In embodiments where the UPF receives packets in the downlink direction (for example, via an N6 reference point), the UPF then checks whether each packet conforms to one of the N4 rules provided by the PCF / SMF for the established AF session with the UE. In some embodiments, the UPF determines that for packets received in the downlink direction, a PDU set check must be performed as indicated by the N4 rules. In some embodiments, the PSA UPF can identify PDU set information using the protocol description and received RTP / SRTP header extension elements corresponding to the PDU set marking by the AS, or alternatively, using UPF implementation-specific means for deriving the PDU set marking. Thus, when a packet is sent to the NG-RAN via a QoS flow having QoS PDU set requirements, the UPF may determine and add at least one or more of the following information fields to the GTP-U header of the packet. • Displaying the PSSN field as the PDU set sequence number. • E-field display as the last PDU in a PDU set. • Displaying the PSN field as the PDU sequence number within the PDU set. • Display the PSSize field as the PDU set size in bytes. • Display the PSI field as PDU set importance, identifying the relative importance of a PDU set compared to other PDU sets within the same QoS flow. • Display the EDB field to signal the end of a data burst.

[0138] If a packet received in the downlink direction conforms to the protocol description in the N4 rule, there are two additional options to consider.

[0139] Option 1: The received packet may not have an additional RTP header extension containing PDU set information. In such an embodiment, the UPF may determine the PDU set information based on its implementation.

[0140] Option 2: Some of the received packets may contain an RTP header extension element that includes PDU set markings and PDU set information provided by the AS. In this case, the UPF must include the information contained in the RTP header extension element in the corresponding PDU set information in the GTP-U header of the PDUs that form the PDU set (for example, by performing a 1:1 mapping, or alternatively by performing a copy). Alternatively, if some of the received packets do not have any PDU set information in the RTP header extension, the UPF will include default PDU set information for each packet (i.e., PDU) using the PDU set markings in the GTP-U header when each packet is sent to the NG-RAN.

[0141] Alternatively, if a packet received in the downlink direction does not conform to the protocol description in the N4 rule, but the N4 rule includes an indication for performing PDU set checking, for each received packet that does not conform to the protocol description (i.e., a PDU on the N6 interface), the UPF maps such a packet to a PDU set and includes default PDU set information in the GTP-U header when the packet is sent to the NG-RAN. Thus, the UPF ensures that all PDUs belong to a PDU set via a QoS flow with QoS requirements for PDU sets. Furthermore, a PDU set containing a single PDU as a result of the UPF's default PDU set marking may have a PDU set size corresponding to the size of a single received packet, or alternatively, may contain a PDU on the N6 interface.

[0142] In one example, the default UPF marking for an AS-unmarked PDU with PDU set information consists of at least one of the following: • Automatically generated PSSN based on the UPF decision sequence of previously identified PSSNs (e.g., by unit increment of the last observed PSSN corresponding to the service data flow of the AF session). • Default value "0" for PDUs including PDU sets, PSN The default value of "1" for the E field, which indicates the last PDU in the PDU set, or alternatively, the marked encoding. The default PSSize is instantiated by the size in bytes of the PDUs (transport protocol overhead, e.g., RTP / UDP / IP) included in the PDU set. In some cases where the default marking of the EDB field by UPF under PCC and N4 rules, i.e., C-DRX enhancement support, is disabled, the EDB field remains unmarked, for example, as "000" or equivalent, and is not used in 5GS. • Default PSI value determined by UPF.

[0143] The default PSI value determined by UPF can be determined according to one of the following three strategies: In the first strategy, the default PSI is statically determined by the PCF given a set of mobile network operators of service level agreement policies associated with AF requests for QoS flows with PDU set QoS requirements. In such scenarios, AF may not need to provide further indication of a preferred default PSI value. In the second strategy, the default PSI value is configured based on AF indications and requests for provisioning QoS flows with PDU set requirements. The default PSI value is included in the PCC and N4 rules generated by the PCF and SMF based on the AF request to provision a service data flow session on 5GS. Thus, AF requests the creation of an AF session with QoS PDU set parameters, including further protocol parameters for provisioning and determining the QoS flow configuration by 5GS. • In the third strategy, the default PSI is determined based on the configuration in UPF. The configuration can be submitted via Operations, Administration, and Management (OAM) procedures.

[0144] An AF request for a QoS flow with PDU set QoS requirements may also include session attributes that describe at least the following: • Protocol identifier for service data flows (for example, an RTP session multiplexing one or more RTP media streams, or alternatively, one or more RTP media streams and an RTCP data flow), • Payload type identifier, or alternatively, subprotocol or subservice data flow identifier (e.g., RTP payload identifiers such as H.264=96, H.265=97, OPUS=112, RTCP message types based on RFC3550 and RFC5761, or alternatively, RFC 8858, etc.) - and default PSI values ​​(for example, a default PSI=8 on a PSI scale where importance 0 is the highest and importance 15 is the lowest, or a default PSI=15 on a PSI scale where importance 0 is the highest and importance 15 is the lowest, or alternatively, a default PSI=0 on a PSI scale where importance 0 is the highest and importance 15 is the lowest).

[0145] An AF request for a QoS flow with PDU set QoS parameters may include common session parameters for all multiplexed media components, media subcomponents, RTP media streams, or alternatively, service data flow subcomponents (e.g., RTCP). For example, the AF instructs the PCF to use a common default PSI value applicable to all media subcomponents.

[0146] In other embodiments, an AF request for a QoS flow having PDU set QoS parameters may include individual session parameters for each multiplexed media component, media subcomponent, RTP media stream, or alternatively, service data flow subcomponent (e.g., RTCP). In one example, the AF would therefore indicate a common default PSI value of 0 (highest) for the audio media subcomponent, or alternatively, the RTP audio stream (e.g., OPUS), a value of 1 (second highest) for the video media subcomponent, or alternatively, the RTP video stream (e.g., H.264), and a value of 8 (intermediate importance) for the RTCP subcomponent of the multiplexed RTP session.

[0147] AF may combine a request for a common default PSI value with individual default PSI values ​​for each individual media subcomponent of an RTP multiplexed stream session. In such cases, the individual default PSI values ​​may take precedence over the common value and act as a fallback.

[0148] When a PCF is presented by a UPF with one or more requested default PSI values, the PCF compares the default PSI values ​​requested by the AF for a given AF session request. The PCF may determine and notify the SMF of a PCC rule, which the SMF then determines an N4 rule containing one or more default PSI values. In such a case, the default PSI values ​​determined by the PCF may differ from those requested by the AF. This may correspond to the PCF determining a lower-priority default PSI value instead of a higher-priority default PSI value requested by the AF, for example. The PCF may make this decision based on at least one of the protocol descriptions, the media subcomponents of a multimedia session (e.g., an RTP multiplexed stream containing marked and unmarked PDUs with PDU set information), and the Mobile Network Operator Service Level Agreement and associated policies for billing and processing traffic for XR applications with PDU set QoS requirements. The SMF N4 rule indicating one or more default PSI values ​​is then used by the UPF to mark any unmarked PDUs, as detailed above.

[0149] Accordingly, a user plane function (UPF) is provided, comprising a processor and memory coupled to the processor, wherein the memory includes instructions executable by the processor, which cause the UPF to receive a configuration, the configuration comprising a protocol description including one or more media stream components and at least one default PDU set importance value, and to receive a protocol data unit (PDU) in the downlink direction, the received PDU undergoing PDU set processing according to the configuration. The UPF may further cause the UPF to determine whether the received PDU does not necessarily match all components of the received configuration, or whether the received PDU matches the protocol description of the information but is not part of a PDU set, and to determine a PDU set importance information value, the determination being based on at least one default PDU set importance value. UPF can further create a header for the received PDU, which includes PDU set information and determined PDU set importance information values, in cases where the received PDU does not necessarily match all components of the received configuration, or where the received PDU matches the protocol description of the received configuration but the received PDU is not part of a PDU set, and can route the received PDU and header to the radio access network.

[0150] The UPF described herein tends to result in improved marking of PDUs in the downlink direction. To ensure proper operation of the wireless access network, a QoS flow with enabled PDU set marking should have all PDUs in the downlink direction that are marked with PDU set information upon ingestion into the wireless access network. Including PDU set severity information in the marking facilitates the differentiation of quality of service flows and the proper application of quality of service requirements in the network. This configuration can be received from the Session Management Function (SMF).

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

[0152] At least one default PDU set importance value may be configured as either a value common to each of the one or more media stream components of the protocol description, or as a separate value for each of the one or more media stream components of the protocol description.

[0153] The protocol description is provided to the Policy Control Function (PCF) by the Application Function (AF), and at least one default PDU set severity value may be requested by the AF for one or more media stream components of the application service data flow.

[0154] The PCF may verify the default PDU set severity value requested by the AF and determine the default PDU set severity value corresponding to the configuration received based on at least one of the following: the default PDU set severity value requested by the AF, the protocol description and the corresponding one or more media components, and the mobile network operator service level agreement and corresponding policy for billing and control of application service data flows.

[0155] At least one default PDU set importance value may be determined by the PCF based on the Mobile Network Operator Service Level Agreement. At least one default PDU set importance value may be determined by the PCF based on the Mobile Network Operator Service Level Agreement and the corresponding policy for billing and control of application service data flows.

[0156] The UPF may also receive default PDU set severity values ​​based on operational, administration, and management (OAM) procedures. OAM policies and procedures may be enforced by mobile network operators within public or private mobile communication networks. Procedures may be enforced based on a predetermined network operator service level agreement. Alternatively, procedures may be enforced based on a QoS profile for service data flows enabled by the PDU set processing function.

[0157] The UPF may be further configured to receive a configuration from the Session Management Function (SMF) that includes at least one default PDU set importance value.

[0158] The PDU set information included in the header may include at least one of the following: PDU set sequence number (PSSN), indication of the last PDU (E) of the PDU set, PDU sequence number (PSN) within the PDU set, PDU set size in bytes (PSSize), PDU set importance (PSI), and indication of the end of the data burst (EDB).

[0159] The protocol description may further include at least one representation of the protocol and payload type.

[0160] Figure 13 shows a method 1300 performed by a User Plane Function (UPF), the method 1300 comprising: receiving a configuration 1310, the configuration comprising a protocol description including one or more media stream components and at least one default PDU set importance value; and receiving a protocol data unit (PDU) in the downlink direction 1320, the received PDU undergoing PDU set processing according to the configuration. The method 1300 further comprises: determining whether the received PDU does not necessarily match all components of the received configuration, or whether the received PDU matches the protocol description of the information but the received PDU is not part of a PDU set 1330; and determining a PDU set importance information value 1340, the determination being based on at least one default PDU set importance value. Method 1300 further comprises creating a header for the received PDU 1350, where the header includes PDU set information and a determined PDU set importance information value, in cases where the received PDU does not necessarily match all components of the received configuration, or the received PDU matches the protocol description of the received configuration but the received PDU is not part of a PDU set, and routing the received PDU and header to a radio access network 1360.

[0161] In some embodiments, method 1300 may be executed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0162] The method described herein tends to result in improved PDU marking in the downlink direction. To ensure proper operation of the wireless access network, a QoS flow with enabled PDU set marking should have all PDUs in the downlink direction marked with PDU set information upon ingestion into the wireless access network. Including PDU set severity information in the marking facilitates the differentiation of quality of service flows and the proper application of quality of service requirements in the network. This configuration can be received from a Session Management Function (SMF).

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

[0164] At least one default PDU set importance value may be configured as either a value common to each of the one or more media stream components of the protocol description, or as a separate value for each of the one or more media stream components of the protocol description.

[0165] The protocol description may be provided to the Policy Control Function (PCF) by the Application Function (AF), and at least one default PDU set severity value may be requested by the AF for one or more media stream components of the application service data flow.

[0166] The PCF may verify the default PDU set severity value requested by the AF and determine the default PDU set severity value corresponding to the configuration received based on at least one of the following: the default PDU set severity value requested by the AF, the protocol description and the corresponding one or more media components, and the mobile network operator service level agreement and corresponding policy for billing and control of application service data flows.

[0167] At least one default PDU set importance value may be determined by the PCF based on the Mobile Network Operator Service Level Agreement. At least one default PDU set importance value may be determined by the PCF based on the Mobile Network Operator Service Level Agreement and the corresponding policy for billing and control of application service data flows.

[0168] The method may further include receiving default PDU set severity values ​​based on operational, administration, and management (OAM) procedures. OAM policies and procedures may be enforced by mobile network operators within public or private mobile communications networks. Procedures may be enforced based on a predetermined network operator service level agreement. Alternatively, procedures may be enforced based on a QoS profile for service data flows enabled by the PDU set processing function.

[0169] The method may further include receiving a configuration from the Session Management Function (SMF) that includes at least one default PDU set importance value.

[0170] The PDU set information included in the header may include at least one of the following: PDU set sequence number (PSSN), indication of the last PDU (E) of the PDU set, PDU sequence number (PSN) within the PDU set, PDU set size in bytes (PSSize), PDU set importance (PSI), and indication of the end of the data burst (EDB).

[0171] The protocol description may further include at least one representation of the protocol and payload type.

[0172] An application function (AF) is further provided, comprising a processor and memory coupled to the processor, the memory including instructions executable by the processor, which cause the AF to determine a configuration for a service data flow session for an application server (AS) having PDU set processing based on at least one request for at least one protocol description including one or more media stream components and a default PDU set importance value; to set at least one requested default PDU set importance value as either a value common to each of the one or more media stream components of the protocol description, or a separate value for each of the one or more media stream components of the protocol description; and to communicate the determined configuration to one of the policy control function (PCF) and network exposure function (NEF) to establish a service data flow session by PDU set processing on the mobile core network.

[0173] The AF may include any application functionality as described herein, such as XRM AF 810. The protocol description may further include at least one representation of the protocol and payload type.

[0174] Figure 14 shows a method 1400 performed by an application function (AF), which comprises determining a configuration for a service data flow session for an application server (AS) having PDU set processing based on at least one protocol description including one or more media stream components and at least one request for a default PDU set importance value 1410, setting at least one requested default PDU set importance value as either a value common to each of one or more media stream components in the protocol description, or a separate value for each of one or more media stream components in the protocol description 1420, and communicating the determined configuration to one of the policy control function (PCF) and network exposure function (NEF) 1430, and establishing a service data flow session by PDU set processing on the mobile core network.

[0175] In some embodiments, method 1400 may be executed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0176] The protocol description may further include at least one representation of the protocol and payload type.

[0177] Default PDU set importance values ​​for PDUs marked by the UPF in the PDU set information are presented herein, so that such PDUs do not have a PDU set importance value indicated by the AS. Further, a method is provided for the UPF to be configured by the PCF / SMF through the PCC / N4 rules to have a default PDU set importance value for unmarked PDUs when packets received downlink do not conform to the N4 rule protocol description, or alternatively, when packets received downlink conform to the N4 rule protocol description but are not marked by the AS in the PDU set information. Furthermore, a method is provided for the PCF to determine a default PDU set importance value for one or more streams of XR service data flows based on at least one of the default PDU set importance values ​​requested by the AF and the mobile network operator service level agreement for service data flows.

[0178] Accordingly, a method is provided which is performed by a User Plane Function (UPF), the method comprising: receiving a Protocol Data Unit (PDU) in the downlink direction, wherein the received PDU undergoes PDU set processing according to a configuration provided by a Session Management Function (SMF), the configuration further comprising a protocol description including one or more media stream components and at least one default PDU set importance value; determining whether the received PDU does not necessarily match all components of the configuration received from the SMF, or whether the received PDU matches the protocol description of the information but the received PDU is not part of a PDU set; creating a header for the received PDU, wherein in either case the received PDU does not necessarily match all components of the configuration received from the SMF, or the received PDU matches the protocol description of the configuration from the SMF but the received PDU is not part of a PDU set, the header further comprising PDU set information including a PDU set importance information value determined based on at least one default PDU set importance value; and routing the received PDU and header to a radio access network.

[0179] At least one default PDU set importance value may be configured by the SMF as one of a value common to all of at least one or more media stream components of the protocol description, and one of individual values ​​for each of the one or more media stream components of the protocol description.

[0180] The protocol description may be provided to the Policy Control Function (PCF) by the Application Function (AF), and at least one default PDU set severity value is required by the AF for one or more media stream components of the application service data flow.

[0181] The PCF may verify the default PDU set severity value requested by the AF and determine the default PDU set severity value corresponding to the SMF configuration based on at least one of the following: the default PDU set severity value requested by the AF, the protocol description and the corresponding one or more media components, and the mobile network operator service level agreement and corresponding policy for billing and control of application service data flows.

[0182] At least one default PDU set importance value may be determined by the PCF based on the Mobile Network Operator Service Level Agreement and the corresponding policies for billing and control of application service data flows.

[0183] UPF may be indicated by a default PDU set importance value based on operational, administration, and management (OAM) procedures.

[0184] The PDU set information included in the header may include at least one of the following: PDU set sequence number (PSSN), indication of the last PDU (E) of the PDU set, PDU sequence number (PSN) within the PDU set, PDU set size in bytes (PSSize), PDU set importance (PSI), and indication of the end of the data burst (EDB).

[0185] The protocol description may further include at least one indication of the protocol and payload type.

[0186] A method is further provided that is performed by an Application Function (AF), which comprises determining a configuration for a service data flow session for an Application Server (AS) having PDU set processing based on at least one protocol description including one or more media stream components and at least one request for a default PDU set importance value; setting at least one requested default PDU set importance value as at least one of a value common to all of the one or more media stream components of the protocol description and a separate value for each of the one or more media stream components of the protocol description; and communicating the determined configuration to one of the Policy Control Function (PCF) and Network Exposure Function (NEF) to establish a service data flow session by PDU set processing on the mobile core network.

[0187] It should be noted that the methods and apparatus described above are illustrative rather than limiting of the present invention, and that many alternative configurations can be designed by those skilled in the art without departing from the scope of the appended claims. The term “comprising” does not preclude the existence of elements or steps other than those enumerated in the claims, and “a” or “an” does not preclude plural, and the functions of several units described in the claims may be realized by a single processor or other unit. No reference numeral in the claims should be construed as limiting their scope.

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

[0189] This method can also be embodied as a set of instructions stored on a computer-readable medium that, when loaded into a computer processor, digital signal processor (DSP), or similar device, cause the processor to execute the method described above.

[0190] The methods and apparatus described may be practiced in other specific forms. The methods and apparatus described should be considered merely illustrative and not limiting in any respect. Accordingly, the scope of the invention is indicated not by the above description but by the appended claims. All modifications that fall within the equivalent meaning and scope of the claims should be encompassed within those scopes.

[0191] The following abbreviations are used: 3GPP, Third Generation Partnership Project; 5G, Fifth Generation; 5GS, 5G System; 5QI, 5G QoS identifiers; AF, Application Functions; AMF, Access and Mobility Functions; AR, Augmented Reality; AS, Application Server; DL, Downlink; NAL, Network Abstraction Layer; PCF, Policy Control Functions; PDU, Packet Data Unit; PPS, Picture Parameter Set; PSDB, PDU Set Latency Budget; PSER, PDU Set Error Rate; PSI, PDU Set Severity; PSIHI, PDU Set Integrated Processing Indicator; QoE, Perceived Quality; QoS, Quality of Service; RAN, Wireless Access Network; RTCP, Real-Time Control Protocol; RTP, Real-Time Protocol; SDAP, Service Data Adaptation Protocol; SMF, Session Management Functions; SRTCP, Secure Real-Time Control Protocol; SRTP, Secure Real-Time Protocol; UE, User Equipment; UL, Uplink; UPF, User Plane Functions; VCL, Video Coding Layer; VMAF, Video Multiplexing Method Assessment Function; VPS, Video Parameter Set; VR, Virtual Reality; XR, Augmented Reality; XR AS, XR Application Server; and XRM, XR Media are important in the fields addressed herein. [Explanation of Symbols]

[0192] 100 Wireless Communication Systems 102 Remote Unit 104 Network Units 200 User Equipment 205 Processor 210 memory 215 Input Devices 220 Output Devices 225 Transceiver 230 Transmitter 235 Receiver 240 network interfaces 245 Application Interfaces 300 network nodes 305 Processor 310 memory 315 Input Devices 320 Output Devices 325 Transceiver 330 Transmitter 335 Receiver 340 Network Interfaces 345 Application Interfaces 405 IP Layer 410 Media Session Data Plane 412 User Datagram Protocol (UDP) 414 RTCP 416 RTP 420 Media Codecs 422 Quality Control 450 Media Session Control Plane 452 UDP 454 Transmission Control Protocol (TCP) 462 Session Initiation Protocol (SIP) 464 Session Description Protocol (SDP) 505 IP Layer 510 Data Plane 512 UDP 515 SRTCP 517 SRTP 520 Media Codecs 522 Quality Control 524 Interactive Connectivity Establishment (ICE) 526 Datagram Transport Layer Security (DTLS) 528 SCTP 550 Control Plane 554 Transmission Control Protocol (TCP) 556 Transport Layer Security (TLS) 558 Hypertext Transfer Protocol (HTTP) 562 Session Initiation Protocol (SIP) 564 Session Description Protocol (SDP) 566 WebSockets 568 Server-Sent Event (SSE) 570 Extensible Messaging and Presence Protocol (XMPP) 630 RTP packets 632, 662 "V" 633, 663 "P" 634, 664 "X" 636, 666 "CC" 638, 668 "M" 640, 670 "PT" Sequence numbers 642, 672 Timestamps 644, 674 646, 676 Synchronization Source (SSRC) identifiers 648, 678 Contributing Source (CSRC) identifiers, RTP header extensions 700 RTP / SRTP Header Extension Format and Syntax 800 System 810 Augmented Reality Media Application Function (XRM AF) 815 Policy and Control Function (PCF) 820 Session Management Function (SMF) 825 Access and Mobility Function (AMF) 830 Wireless Access Network (RAN) 835 User Equipment (UE) 840 User Plane Function (UPF) 845 Augmented Reality Applications 910 PDU Set 920 QoS Flow 930 Data Wireless Bearer (DRB) 1000 1-byte RTP header extension 1032 "E" 1034 "EDB" 1035 UE 1036 "PSI" 1040 UPF, "PSSN" 1042 "PSN" 1044 "PS Size" 1050 2-byte RTP header extension 1100 System 1115 PCF 1120 SMF 1130 RAN 1135 UE 1140 UPF 1145 XR Video Applications 1147 Non-XR video applications 1200 System 1215 PCF 1220 SMF 1240 UPF 1230 RAN 1235 UE 1245 XR Video Applications 1300 methods 1400 methods

Claims

1. A user plane function (UPF) for wireless communication, At least one memory, The system comprises at least one processor coupled to the at least one memory, and the at least one processor provides the UPF, Receiving a configuration comprising a protocol description including one or more media stream components and at least one default protocol data unit (PDU) set importance value, Receiving a PDU in the downlink direction, wherein the received PDU undergoes PDU setting processing according to the configuration, The received PDU does not match all the components of the received configuration, or Whether the received PDU matches the protocol description of the configuration and is not part of the PDU set To decide whether or not, Determining a PDU set importance information value based on the aforementioned at least one default PDU set importance value, The received PDU does not match all components of the received configuration, or If the received PDU matches the protocol description of the received configuration, and the received PDU is not part of a PDU set, Creating a header for the received PDU, which includes PDU set information and the determined PDU set importance information value, The received PDU and the header are routed to the wireless access network. It is configured to perform the following: UPF.

2. The aforementioned at least one default PDU set importance value is A value common to each of the one or more media stream components of the protocol description, or The UPF according to claim 1, configured as a separate value for each of the one or more media stream components of the protocol description.

3. The UPF according to claim 2, wherein the protocol description is provided to the policy control function (PCF) by the application function (AF), and the at least one default PDU set severity value is requested by the AF for one or more media stream components of the application service data flow.

4. The PCF verifies the default PDU set importance value requested by the AF, The default PDU set importance value requested by the aforementioned AF, The protocol description and one or more corresponding media components, Mobile Network Operator Service Level Agreement and Corresponding Policy for Billing and Control of the Application Service Data Flow The UPF according to claim 3, which determines the default PDU set importance value corresponding to the received configuration based on the above.

5. The UPF according to claim 2, wherein the at least one default PDU set importance value is determined by a policy control function (PCF) based on a mobile network operator service level agreement.

6. The at least one processor is further configured to cause the UPF to receive a default PDU set importance value based on an operation, administration and management (OAM) procedure. The UPF according to claim 1.

7. The at least one processor is further configured to cause the UPF to receive the configuration, including the at least one default PDU set importance value, from the session management function (SMF). The UPF according to claim 1.

8. The PDU set information included in the header is PDU set sequence number (PSSN), The display of the last PDU(E) of the aforementioned PDU set, The PDU sequence number (PSN) within the aforementioned PDU set, PDU set size in bytes (PSSize), PDU set importance (PSI), or End of data burst (EDB) display Equipped with The UPF according to claim 1.

9. The protocol description further includes an indication of the protocol or payload type. The UPF according to claim 1.

10. A method that is performed by a user plane function (UPF), The steps include receiving a configuration comprising a protocol description that includes one or more media stream components and at least one default protocol data unit (PDU) set importance value, A step of receiving a PDU in the downlink direction, wherein the received PDU undergoes PDU set processing according to the configuration, The received PDU does not match all the components of the received configuration, or The received PDU is consistent with the protocol description of the configuration, and the received PDU is not part of a PDU set. What steps will you decide? A step of determining a PDU set importance information value, wherein the determination is based on the at least one default PDU set importance value. The received PDU does not match all components of the received configuration, or If the received PDU matches the protocol description of the received configuration, and the received PDU is not part of a PDU set, A step of creating a header for the received PDU, which includes PDU set information and the determined PDU set importance information value. The steps include routing the received PDU and the header to a wireless access network, method.

11. The aforementioned at least one default PDU set importance value is, A value common to each of the one or more media stream components of the protocol description, or This is configured as a separate value for each of the one or more media stream components of the protocol description. The method according to claim 10.

12. The protocol description is provided to the policy control function (PCF) by the application function (AF), and the at least one default PDU set severity value is requested by the AF for one or more media stream components of the application service data flow. The method according to claim 11.

13. The PCF verifies the default PDU set importance value requested by the AF, The default PDU set importance value requested by the aforementioned AF, The protocol description and one or more corresponding media components, Mobile Network Operator Service Level Agreement and Corresponding Policy for Billing and Control of the Application Service Data Flow Based on this, the default PDU set importance value corresponding to the received configuration is determined. The method according to claim 12.

14. The aforementioned at least one default PDU set importance value is determined by the policy control function (PCF) based on the Mobile Network Operator Service Level Agreement. The method according to claim 10.

15. Further comprising the step of receiving a default PDU set importance value based on an operation, administration and management (OAM) procedure The method according to claim 10.

16. The process further comprises the step of receiving the configuration, including the at least one default PDU set importance value, from the session management function (SMF). The method according to claim 10.

17. The PDU set information included in the header is PDU set sequence number (PSSN), The display of the last PDU(E) of the aforementioned PDU set, The PDU sequence number (PSN) within the aforementioned PDU set, PDU set size in bytes (PSSize), PDU set importance (PSI), or End of data burst (EDB) display Equipped with The method according to claim 10.

18. An application function (AF) for wireless communication, At least one memory, The system comprises at least one processor coupled to the at least one memory, The at least one processor provides the AF with Determining the configuration for a service data flow session for an application server (AS) having PDU set processing, based at least on a protocol description that includes one or more media stream components and at least one request for a default protocol data unit (PDU) set importance value, The aforementioned at least one requested default PDU set importance value is A value common to each of the one or more media stream components of the protocol description, or Individual values ​​for each of the one or more media stream components of the protocol description To set it as, The determined configuration is transmitted to the policy control function (PCF) or network exposure function (NEF) to establish the service data flow session on the mobile core network by PDU set processing. It is configured to perform the following: AF.

19. The protocol description further includes an indication of the protocol or payload type. AF as described in claim 18.

20. A method performed by an application function (AF), A step of determining the configuration for a service data flow session for an application server (AS) having PDU set processing, based at least on one protocol description including one or more media stream components and at least one request for a default protocol data unit (PDU) set importance value, The aforementioned at least one requested default PDU set importance value is A value common to each of the one or more media stream components of the protocol description, or Individual values ​​for each of the one or more media stream components of the protocol description The steps to set it as, The system includes the steps of: transmitting the determined configuration to a policy control function (PCF) or a network exposure function (NEF), and establishing the service data flow session on the mobile core network by PDU set processing. method.

Images