Supporting dynamic changes in traffic characteristics in wireless communication networks

Abstract

Various aspects of the disclosure relate to a first network function for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and arranged to cause the first network function to: receive, from a second network function, a set of rules for inspecting a set of protocol data units (PDU set) and identifying a change in PDU set size between at least two PDU sets; receive a set of packets that satisfy at least one rule of the set of rules, the set of packets including a plurality of PDU sets; identify a change in PDU set size between a first PDU set and a second PDU set of the plurality of PDU sets; and route, by a network interface, the set of packets to a base station, wherein the set of packets include PDU set information including an indication that the PDU set size is to change with the second PDU set.

Description

Technical Field

[0001] The topics disclosed herein generally relate to the field of supporting dynamic changes in service characteristics in wireless communication networks. Specifically, this document defines a first network function, a method performed by the first network function, a base station, and a method performed by the base station. Background Technology

[0002] A wireless communication system may include one or more network communication devices, such as a base station, that support wireless communication with one or more user communication devices, which may also be referred to as user equipment (UE) or other suitable terms. The wireless communication system can support wireless communication with one or more user communication devices by utilizing the resources of the wireless communication system (e.g., time resources (e.g., symbols, time slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers, or the like)). Furthermore, the wireless communication system may support wireless communication across various radio access technologies, including third-generation (3G), fourth-generation (4G), fifth-generation (5G), and other suitable radio access technologies beyond 5G (e.g., sixth-generation (6G)). Summary of the Invention

[0003] The article “a” preceding an element is not limited and should be understood to refer to “at least one” or “one or more” of those elements. The terms “a,” “at least one,” “one or more,” and “at least one of one or more” are interchangeable. As used herein (including in the claims), “or” as used in a list of items (e.g., a list of items beginning with phrases such as “at least one of…”, “one or more of…”, or “one or both of…”) indicates a list of inclusion, such that a list of at least one of, for example, A, B, or C represents A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Furthermore, as used herein, the phrase “based on” should not be construed as referring to a closed set of conditions. For example, an example step described as “based on condition A” may be based on both condition A and condition B without departing from the scope of this disclosure. In other words, as used herein, the phrase “based on” should be interpreted in the same manner as the phrase “at least partially based on.” Furthermore, as used herein (including in the claims), a “set” may contain one or more elements.

[0004] This document provides a first network function for wireless communication, comprising: at least one memory; and at least one processor coupled to and arranged such that the first network function: receives from a second network function a set of rules for examining a set of Protocol Data Units (PDUs) and identifying a change in PDU set size between at least two PDU sets; receives a set of packets satisfying at least one of the rules in the set of rules, the set of packets comprising a plurality of PDU sets; identifies a change in PDU set size between a first PDU set and a second PDU set in the plurality of PDU sets; and routes the set of packets to a base station via a network interface, wherein the set of packets contains PDU set information, the PDU set information including an indication that the PDU set size will change with the second PDU set.

[0005] A method performed by a first network function is further provided, the method comprising: receiving from a second network function a set of rules for inspecting a set of Protocol Data Units (PDUs) and identifying a change in the size of a PDU set between at least two PDU sets; receiving a set of packets satisfying at least one of the rules in the set of rules, the set of packets comprising a plurality of PDU sets; identifying a change in the size of a PDU set between a first PDU set and a second PDU set in the plurality of PDU sets; and routing the set of packets to a base station via a network interface, wherein the set of packets contains PDU set information, the PDU set information including an indication that the size of the PDU set will change with the second PDU set.

[0006] A base station for wireless communication is further provided, comprising: at least one memory; and at least one processor coupled to and arranged such that the base station: receives from a second network function a first request for processing a set of PDUs for a QoS flow; determines a first scheduling resource to transmit the PDUs of the QoS flow to a user equipment (UE) according to the first request; receives from the first network function a first set of PDUs as a series of IP packets for the QoS flow via a network interface, the first set of PDUs including an indication of an upcoming second set of PDUs having a size different from that of the first set of PDUs; determines a second scheduling resource to accommodate the size of the second set of PDUs; receives the second set of PDUs from the first network function; and transmits the second set of PDUs to the UE according to the second scheduling resource.

[0007] A method performed by a base station is further provided, the method comprising: receiving a first request from a second network function to process a set of PDUs for a QoS flow; determining a first scheduling resource to transmit the PDUs of the QoS flow to a user equipment (UE) based on the first request; receiving a first set of PDUs from the first network function as a series of IP packets for the QoS flow via a network interface, the first set of PDUs including an indication that an upcoming second set of PDUs has a size different from that of the first set of PDUs; determining a second scheduling resource to accommodate the size of the second set of PDUs; receiving the second set of PDUs from the first network function; and transmitting the second set of PDUs to the UE based on the second scheduling resource. Attached Figure Description

[0008] Figure 1 Examples of wireless communication systems according to aspects of this disclosure are described.

[0009] Figure 2 This section provides an overview of the core network XRM architecture handling for PDU sets.

[0010] Figure 3 This describes the 1-byte RTP header extension used for PDU set marking by AS.

[0011] Figure 4 This describes the 2-byte RTP header extension used for PDU set marking by AS.

[0012] Figure 5 illustrates how two sets of PDUs with different importance and characteristics are mapped to QoS streams and, respectively, to some options of data radio bearers.

[0013] Figure 6 This describes a UPF that identifies dynamic changes in the business characteristics of XR services.

[0014] Figure 7 This is an explanation Figure 6 The system operation is illustrated in the message passing diagram.

[0015] Figure 8 Explain the RTP sender awareness and signaling for dynamic PDU set size.

[0016] Figure 9 This is an explanation Figure 8 The system operation is illustrated in the message passing diagram.

[0017] Figure 10 This describes the instance header information for interdependent PDU sets that have dynamic business characteristics.

[0018] Figure 11 An example of a user equipment (UE) 1100 according to aspects of this disclosure is described.

[0019] Figure 12 An example of processor 1200 according to aspects of this disclosure is described.

[0020] Figure 13 Examples of network equipment (NE) 1300 according to aspects of this disclosure are described.

[0021] Figure 14 A flowchart illustrating a method performed by a first network function according to aspects of this disclosure.

[0022] Figure 15 A flowchart illustrating a method performed by a base station according to aspects of this disclosure. Detailed Implementation

[0023] As part of its 19th edition research, 3GPP is currently investigating ways to enhance XR service support on 3GPP networks. One of the key issues within the current research scope is supporting use cases where the service characteristics of XR services change dynamically. For example, when a user moves the progress bar of a streaming video, the size of the media segment can change dynamically, requiring more bandwidth to buffer a set of initial video frames to allow streaming applications to buffer enough data to support smooth video playback.

[0024] This paper proposes a solution that includes providing information to the gNB scheduler, allowing the gNB scheduler to be aware of this dynamic change in the PDU set size and schedule network resources accordingly.

[0025] This disclosure is described in the context of wireless communication systems.

[0026] Figure 1This describes an example of a wireless communication system 100 according to aspects of this disclosure. The wireless communication system 100 may include one or more NEs 102, one or more UEs 104, and a core network (CN) 106. The wireless communication system 100 may support various radio access technologies. In some embodiments, the wireless communication system 100 may be a 4G network, such as an LTE network or an advanced LTE (LTE-A) network. In some other embodiments, the wireless communication system 100 may be an NR network, such as a 5G network, an advanced 5G (5G-A) network, or a 5G ultra-wideband (5G-UWB) network. In other embodiments, the wireless communication system 100 may be a combination of 4G and 5G networks, or other suitable radio access technologies, including IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), and IEEE 802.20. The wireless communication system 100 may support radio access technologies beyond 5G, such as 6G. In addition, the wireless communication system 100 can support technologies such as Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), or Code Division Multiple Access (CDMA).

[0027] One or more NEs 102 may be distributed throughout a geographic area to form a wireless communication system 100. One or more of the NEs 102 described herein may be, include, or be referred to as a network node, base station, network element, network function, network entity, radio access network (RAN), NodeB, eNodeB (eNB), next-generation NodeB (gNB), or other suitable terms. NEs 102 and UEs 104 may communicate via a communication link, which may be a wireless or wired connection. For example, NEs 102 and UEs 104 may perform wireless communication (e.g., receive signaling, transmit signaling) via a Uu interface.

[0028] NE 102 can provide a geographic coverage area, for which NE 102 can support services of one or more UE 104s within the geographic coverage area. For example, NE 102 and UE 104 can support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcasting, etc.) according to one or more radio access technologies. In some embodiments, NE 102 can be mobile, for example, a satellite associated with a non-terrestrial network (NTN). In some embodiments, different geographic coverage areas associated with the same or different radio access technologies may overlap, but different geographic coverage areas may be associated with different NE 102s.

[0029] One or more UEs 104 may be distributed throughout the geographic area of ​​the wireless communication system 100. UE 104 may include or be referred to as a remote unit, mobile device, wireless device, remote device, subscriber device, transmitter device, receiver device, or some other suitable term. In some embodiments, UE 104 may be referred to as a unit, station, terminal, or client, and other instances. Alternatively or additionally, UE 104 may be referred to as an Internet of Things (IoT) device, an Internet of Everything (IoE) device, or a Machine-Type Communication (MTC) device, and other instances.

[0030] UE 104 may be able to support direct wireless communication with other UE 104 via a communication link. For example, UE 104 may support direct wireless communication with another UE 104 via a device-to-device (D2D) communication link. In some implementations (e.g., vehicle-to-vehicle (V2V) deployment, vehicle-to-everything (V2X) deployment, or cellular V2X deployment), the communication link may be referred to as a sidelink. For example, UE 104 may support direct wireless communication with another UE 104 via a PC5 interface.

[0031] NE 102 may support communication with CN 106 or another NE 102, or both. For example, NE 102 may interface with other NE 102 or CN 106 via one or more backhaul links (e.g., S1, N2, N2, or network interfaces). In some embodiments, NE 102 may communicate directly with each other. In other embodiments, NE 102 may communicate with each other or indirectly (e.g., via CN 106). In some embodiments, one or more NE 102 may include sub-components, such as access network entities, which may be instances of access node controllers (ANCs). The ANC may communicate with one or more UEs 104 via one or more other access network transport entities, which may be referred to as wireless heads, smart wireless heads, or transmit-receive points (TRPs).

[0032] CN 106 can support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. CN 106 can be an evolved packet core (EPC) or a 5G core (5GC), which may include control plane entities that manage access and mobility (e.g., a mobility management entity (MME), access and mobility management functions (AMF)) and user plane entities that route packets to or interconnect to external networks (e.g., a serving gateway (S-GW), a packet data network (PDN) gateway (P-GW), or a user plane function (UPF)). In some implementations, the control plane entities may manage non-access stratum (NAS) functions of one or more UEs 104 served by one or more NEs 102 associated with CN 106, such as mobility, authentication, and bearer management (e.g., data bearers, signaling bearers, etc.).

[0033] CN 106 can communicate with the packet data network via one or more backhaul links (e.g., via S1, N2, N2, or another network interface). The packet data network may contain an application server. In some implementations, one or more UEs 104 can communicate with the application server. UE 104 can establish a session (e.g., a Protocol Data Unit (PDU) session or the like) with CN 106 via NE 102. CN 106 can use the established session (e.g., an established PDU session) to route services (e.g., control information, data, and the like) between UE 104 and the application server. A PDU session may be an instance of a logical connection between UE 104 and CN 106 (e.g., one or more network functions of CN 106).

[0034] In the wireless communication system 100, NE 102 and UE 104 can use the resources of the wireless communication system 100 (e.g., time resources (e.g., symbols, time slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communication). In some embodiments, NE 102 and UE 104 may support different resource structures. For example, NE 102 and UE 104 may support different frame structures. In some embodiments, such as in 4G, NE 102 and UE 104 may support a single frame structure. In some other embodiments, such as in 5G and other suitable radio access technologies, NE 102 and UE 104 may support various frame structures (i.e., multiple frame structures). NE 102 and UE 104 may support various frame structures based on one or more parameter sets.

[0035] The wireless communication system 100 may support one or more parameter sets, and the parameter sets may include subcarrier spacing and cyclic prefixes. A first parameter set (e.g., μ=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a regular cyclic prefix. In some embodiments, the first parameter set (e.g., μ=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one time slot per subframe. A second parameter set (e.g., μ=1) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a regular cyclic prefix. A third parameter set (e.g., μ=2) may be associated with a third subcarrier spacing (e.g., 60 kHz) and a regular cyclic prefix or an extended cyclic prefix. A fourth parameter set (e.g., μ=3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a regular cyclic prefix. A fifth parameter set (e.g., μ=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a regular cyclic prefix.

[0036] Time intervals for resources (e.g., communication resources) can be organized according to frames (also known as radio frames). Each frame may have a certain duration, for example, 10 milliseconds (ms). In some embodiments, each frame may contain multiple subframes. For example, each frame may contain 10 subframes, and each subframe may have a certain duration, for example, 1 ms. In some embodiments, each frame may have the same duration. In some embodiments, each subframe of a frame may have the same duration.

[0037] Alternatively, the time intervals of resources (e.g., communication resources) can be organized according to time slots. For example, a subframe may contain a certain number (e.g., quantity) of time slots. The number of time slots in each subframe may also depend on one or more parameter sets supported in the wireless communication system 100. For example, the first, second, third, fourth, and fifth parameter sets (i.e., μ=0, μ=1, μ=2, μ=3, μ=4) associated with corresponding subcarrier intervals of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single time slot per subframe, two time slots per subframe, four time slots per subframe, eight time slots per subframe, and 16 time slots per subframe, respectively. Each time slot may contain a certain number (e.g., quantity) of symbols (e.g., OFDM symbols). In some embodiments, the number (e.g., quantity) of time slots in a subframe may depend on the parameter set. For a conventional cyclic prefix, a time slot may contain 14 symbols. For an extended cyclic prefix (e.g., applicable to a 60 kHz subcarrier spacing), a time slot may contain 12 symbols. The relationship between the number of symbols per time slot for the regular cyclic prefix and the extended cyclic prefix, the number of time slots per subframe, and the number of time slots per frame may depend on the parameter set. It should be understood that a reference to the first parameter set (e.g., μ=0) associated with the first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and time slots.

[0038] In the wireless communication system 100, the electromagnetic (EM) spectrum can be divided into various categories, frequency bands, channels, etc., based on frequency or wavelength. For example, the wireless communication system 100 may support one or more operating frequency bands, such as frequency range names FR1 (410 MHz to 7.125 GHz), FR2 (24.25 GHz to 52.6 GHz), FR3 (7.125 GHz to 24.25 GHz), FR4 (52.6 GHz to 114.25 GHz), FR4a or FR4-1 (52.6 GHz to 71 GHz), and FR5 (114.25 GHz to 300 GHz). In some embodiments, NE 102 and UE 104 can perform wireless communication through one or more of the operating frequency bands. In some embodiments, FR1 can be used by NE 102 and UE 104, as well as other equipment or devices, for cellular communication services (e.g., control information, data). In some implementations, FR2 can be used by NE 102 and UE 104, as well as other equipment or devices, for short-range, high data rate capabilities.

[0039] FR1 may be associated with one or more parameter sets (e.g., at least three parameter sets). For example, FR1 may be associated with a first parameter set containing a 15 kHz subcarrier spacing (e.g., μ=0); a second parameter set containing a 30 kHz subcarrier spacing (e.g., μ=1); and a third parameter set containing a 60 kHz subcarrier spacing (e.g., μ=2). FR2 may be associated with one or more parameter sets (e.g., at least two parameter sets). For example, FR2 may be associated with a third parameter set containing a 60 kHz subcarrier spacing (e.g., μ=2); and a fourth parameter set containing a 120 kHz subcarrier spacing (e.g., μ=3).

[0040] As part of its 19th edition research, 3GPP is currently investigating ways to enhance XR service support on 3GPP networks. One of the key issues within the current research scope is supporting use cases where the service characteristics of XR services change dynamically. For example, when a user moves the progress bar of a streaming video, the size of the media segment can change dynamically, requiring more bandwidth to buffer a set of initial video frames to allow streaming applications to buffer enough data to support smooth video playback.

[0041] In another instance, the size of data bursts in an XR service can dynamically change during video scene transitions. In this case, the encoder creates a new video I-frame with a packet size significantly larger than that of the previous I-frame. Such scenarios can pose challenges for the RAN scheduler because the PDU set size of the new I-frame will be much larger than that of the previous frame (P-frame). To ensure the delivery of such large data bursts within the PSDB of the QoS stream, QoS parameters (e.g., Guaranteed Flow Bit Rate (GFBR) or Maximum Data Burst Value (MDBV)) need to be set based on the potential maximum burst value in the current QoS mechanism. This results in wasted network resources and reduced user capacity during normal operation.

[0042] This paper proposes a solution that includes providing information to the gNB scheduler, allowing the gNB scheduler to be aware of this dynamic change in the PDU set size and schedule network resources accordingly.

[0043] A large number of applications and services that multiplex multimedia streams within a single network application session (i.e., a 5-tuple containing the source IP address, destination IP address, source network port, destination network port, and a protocol number as an identifier) ​​fall under the domain of Extended Reality (XR). Such XR applications and services are defined in 3GPP Technical Report TR 26.928 v17.0.0 (April 2022), entitled "Extended Reality (XR) in 5G". As an example, WebRTC-based or alternatively RTP / SRTP protocol stack-based XR applications may contain one or more video and audio streams multiplexed through a single application data network session with control and feedback metadata and application metadata (e.g., user gesture information, user input actions, etc.). Consider such arrangements in the applicants’ co-pending applications: U.S. Provisional Application 63 / 428,026, entitled “PDU SET-AWARE MULTIMEDIA APPLICATIONS AND ASSOCIATED SIGNALING,” by Stoitsa et al., with applicant reference number SMM920220198-US-PSP; and U.S. Provisional Application 63 / 478,932, entitled “MULTIMEDIA SUBPROTOCOLS OVER REAL TIME PROTOCOL,” by Stoitsa et al., with applicant reference number SMM920220218-US-PSP.

[0044] It should be noted that although some examples and discussions in the following text use "XR" as a reference use case or an application family of solutions proposed in this paper, it should be readily apparent to the reader that the proposed solutions are more general and can be adopted in various types of transport and network protocol stacks (e.g., QUIC, WebRTC, WebTransport, to name just a few).

[0045] Furthermore, XR will be referred to as a general term for different types of reality in the following text, including virtual reality, augmented reality, and mixed reality.

[0046] Virtual reality (VR) is a rendered version of a delivered visual and auditory scene. In this case, the rendering is designed to mimic real-world visual and auditory sensory stimuli as naturally as possible as an observer or user moves within boundaries defined by the application. Virtual reality typically, but does not necessarily, require the user to wear a head-mounted display (HMD) that completely replaces the user's field of vision with simulated visual components, and headphones to provide accompanying audio. Some form of head and movement tracking is usually also required in VR to allow updates to the simulated visual and auditory components to ensure that objects and sound sources appear consistent with the user's movement from their perspective. In some implementations, additional means for interacting with the virtual reality simulation may be provided, but these are not strictly necessary.

[0047] Augmented reality (AR) is the provision of additional information or artificially generated objects, or content, to users overlaid on their current environment. This additional information or content is typically visual and / or auditory, and the user's observation of their current environment can be direct, without intermediate sensing, processing, and rendering, or it can be indirect, where the user's perception of their environment is relayed through sensors and can be augmented or processed.

[0048] Mixed Reality (MR) is an advanced form of AR in which virtual elements are inserted into a physical scene with the intention of providing the illusion that these elements are part of the real scene.

[0049] XR refers to all combinations of real and virtual environments and human-computer interactions generated by computer technology and wearable devices. XR includes representative forms such as AR, MR, and VR, as well as areas interspersed within them. The level of virtuality ranges from partial sensory input to fully immersive VR. In some circles, key aspects of XR are seen as an extension of human experience, particularly related to presence (represented by VR) and cognitive acquisition (represented by AR).

[0050] In 3GPP Release 18, the concept of a PDU set was introduced at the Core Network (CN) level for XR Media (XRM) features to handle the QoS requirements of XRM applications and flows at a granularity exceeding the 5G Rel-17 QoS flow possibilities. Therefore, according to: 3GPP Technical Report TR 23.700-60 v0.0.3 (May 2022) entitled "Study on XR (Extended Reality) and media services"; and 3GPP Technical Specification TS 23.501 v18.2.2 (June 2023) entitled "System architecture for the 5G System (5GS)", a PDU set consists of one or more PDUs carrying a payload (e.g., a frame or video slice for XRM services) of a single information element generated at the application layer. In some implementations, the application layer requires all PDUs in the PDU set to use the corresponding information element. In other implementations, when some PDUs are lost, the application layer can still recover part or all of the information units.

[0051] Additionally, PDU sets are associated with QoS requirements regarding delay budget and error rate, which can be defined as PDU set delay budget (PSDB) and / or PDU set error rate (PSER), as defined in 3GPP technical report TR 23.700-60 v0.0.3 (May 2022), titled "Study on XR (Extended Reality) and media services." The PDU set delay budget (PSDB) defines the upper limit of the time a PDU set may be delayed between the UE and the N6 termination point at the UPF. The PSDB applies to DL PDU sets received by the UPF via the N6 interface and UL PDU sets transmitted by the UE. The PDU set error rate (PSER) defines the upper limit of the rate of a PDU set (e.g., the set of IP packets constituting the PDU set) that has been processed by the sender of the link layer protocol (e.g., the RLC in a 3GPP-accessible RAN). The PSER can be used to determine the upper limit of the non-congestion-related packet loss rate.

[0052] A PDU set may contain packets that the gNB must transmit to the UE using specific scheduling resources. A PDU set may contain packets for a specific service. The specific service may be a streaming service. A PDU set may contain service packets of a specific type. The specific type of service packet may be an I-frame, such as a video service. A PDU set may include a single PDU or multiple PDUs.

[0053] Figure 2 This section provides an overview of the core network (CN) XRM architecture handling for PDU sets. Figure 2 System 200 is described, comprising Extended Reality Media Application Function (XRM AF) 210, Policy and Control Function (PCF) 215, Session Management Function (SMF) 220, Access and Mobility Function (AMF) 225, Radio Access Network (RAN) 230, User Equipment (UE) 235, User Plane Function (UPF) 240, and Extended Reality Application 245. The UE described herein may include Remote Unit 102, UE 235, 635, 835, or 1000 as described herein. The UPF described herein may include User Plane Functions (UPFs) as described herein, such as UPF 240, 640, 740, 840, 940; or Network Equipment 1200. The operation of System 200 will now be described in the context of downlink services; a similar procedure may be performed for uplink services.

[0054] At position 280, XRM AF 210 determines the PDU set requirements.

[0055] At 281, XRM application function 210 provides PCF 215 with QoS requirements for packets in the PDU set and information for identifying the application (i.e., a 5-tuple or application ID). QoS requirements may include PSDB and PSER. XRM AF 210 may also include importance parameters for the PDU set and information for enabling the core network to identify packets belonging to the PDU set.

[0056] At position 282, PCF 215 exports the QoS rules for the XR application and the specific QoS requirements for the PDU set, and configures SMF 220. The QoS rules can use the 5G QoS identifier (5QI) for XR media services. PCF 215 sends the QoS rules to SMF 220. PCF 215 can include PCC rules based on the importance of the PDU set in its communications to SMF 220. PCC rules can be derived based on information received from XRMAF 210 or based on operator configuration.

[0057] At position 283, SMF 220 establishes a QoS flow based on the QoS rules of PCF 215 and configures UPF to route packets for XR applications to the QoS flow. Additionally, PDU set processing is enabled. SMF 220 also provides a QoS profile containing PDU set QoS requirements to RAN 230 via AMF 225. AMF 225 can provide a QoS profile containing PDU set QoS requirements to RAN 230 in the N2 SM container. Furthermore, AMF 225 can provide QoS rules to UE 235 in the N1 SM container.

[0058] At position 284, UPF 240 checks the packet and determines that the packet belongs to the PDU set. Packet inspection can be based on a UPF implementation scheme; for example, by inspecting the RTP packet header (according to U.S. Provisional Application 63 / 428,026 entitled "PDU SET-AWARE MULTIMEDIA APPLICATIONS AND ASSOCIATED SIGNALING" by Stoitsa et al., applicant reference number SMM920220198-US-PSP; and / or 3GPP Technical Specification TS23.501 v18.2.2 (June 2023) entitled "System architecture for the 5G System (5GS)"), or based on AS-tagged PDU set information transmitted via RTP PDU set header extensions (according to: Stoitsa et al. entitled "PDU SET-AWAREMULTIMEDIA APPLICATIONS AND ASSOCIATED"). U.S. Provisional Application 63 / 428,026, entitled “SIGNALING,” with applicant reference number SMM920220198-US-PSP; 3GPP technical specification TS 23.501 v18.2.2 (June 2023), entitled “System architecture for the 5G System (5GS)”; and / or 3GPP technical specification TS 26.522 v0.2.0 (November 2023), entitled “5G Real-time Media Transport Protocol Configurations,” i.e., urn:3gpp:pdu-set-marking:rel-18. When the UPF 240 detects packets of a PDU set, the UPF 240 marks the packets belonging to the PDU set in the GTP-U header. The GTP-U header information includes the PDU set sequence number and the size of the PDU set. UPF 240 can also determine the importance of a PDU set based on the UPF 240 implementation, information provided by XRM AF 210, or information provided as metadata from the XRM application server. Based on the importance of the PDU set, UPF 240 can route traffic to the corresponding QoS flow 1 (according to the rules received from SMF 220), or include the importance of the PDU set in the GTP-U header. QoS flow 1 may include GTP-U headers, and these GTP-U headers may contain PDU set information.

[0059] At 285, RAN 230 identifies packets belonging to a PDU set (based on GTP-U tags) and handles these packets according to the QoS requirements of the PDU set provided by SMF 220. In one implementation, the RAN 230 node may use different radio bearers with higher QoS requirements (based on the PDU set PSDB / PSER) to guarantee the delivery of packets for the PDU set, while using different radio bearers based on the 5QI of the QoS flow for non-PDU set packets. RAN 230 may receive the QFI and QoS profile of the QoS flow from SMF 220 (via AMF 225) during PDU session establishment / modification that includes PDSB and PSER. RAN 230 checks the GTP-U header and ensures that all packets from the same PDU set are handled according to the QoS profile. This may include packets from the PDU set in the radio bearer carrying QoS flow 1. This may also include packets not belonging to the PDU set being transmitted in different radio bearers carrying QoS flow 2.

[0060] However, in XRM version 18, the 3GPP technical specification TS 23.501 v18.2.2 (June 2023) entitled "System architecture for the 5G System (5GS)", once PDU set QoS integration processing is enabled, the PSA UPF identifies the PDUs belonging to the PDU set and determines the following PDU set information to be sent to the NG-RAN in the GTP-U header for each PDU set.

[0061] PDU set information includes: PDU set sequence number, indication of the end PDU of the PDU set, PDU sequence number within the PDU set, PDU set size (in bytes), and PDU set importance. The PDU set importance identifies the relative importance of the PDU set compared to other PDU sets within the QoS flow.

[0062] Next, NG-RAN uses PDU set information to perform QoS processing based on the PDU set, as described above.

[0063] NG-RAN can drop PDU set-level packets in the event of congestion, and the importance of PDU sets across QoS flows and within QoS flows can be prioritized as given in clause 5.7.3.3 of the 3GPP technical specification TS 23.501 v18.2.2 (June 2023) entitled "System architecture for the 5G System (5GS)".

[0064] 3GPP TS 23.501 v18.2.2 also specifies that the PSA UPF identifies PDUs belonging to a PDU set, and if the UPF receives PDUs that do not belong to the PDU set based on the protocol description identified by the PDU set (e.g., not yet marked with PDU set information by the AS), then the UPF still maps the PDUs to the PDU set and determines the PDU set information, as described above. This ensures that for QoS flows with PDU sets enabled, all PDUs belong to the PDU set. Therefore, if the PSA UPF receives PDUs that do not belong to the PDU set, it is assumed that the UPF determines the PDU set importance value based on a pre-configured default importance in some embodiments and based on a default importance signaled by the AS / AF in other embodiments.

[0065] In some embodiments, the AS PDU set information listed above is provided via: a single-byte RTP header extension for identifying the PDU set (U.S. Provisional Application 63 / 478,932, entitled "MULTIMEDIA SUBPROTOCOLS OVER REAL TIME PROTOCOL," by Stoica et al., reference number SMM920220218-US-PSP); and as defined in 3GPP technical specification TS 26.522v0.2.0 (November 2023), entitled "5G Real-time Media Transport Protocol Configurations." Figure 2 The sudden end as described in the document.

[0066] Figure 3 This describes a 1-byte RTP header extension used by the AS for PDU set marking according to 3GPP TS 26.522 v0.2.0.

[0067] Similarly, Figure 4 This describes the 2-byte RTP header extension used by AS for PDU set marking according to 3GPP TS 26.522 v0.2.0.

[0068] Figure 3 and Figure 4 The semantics of the fields used to mark PDU sets and the RTP header extensions for burst termination are as follows.

[0069] The last PDU in the PDU set [E] (1-bit field) 332 and 432 are flags that the last PDU in the PDU set is set to 1 and all other PDUs in the PDU set are set to 0.

[0070] Reserved [R] (2-bit field) 333 and 433 are reserved fields for future use.

[0071] Data burst end [D] (1-bit field) 334, 434 indicates a data burst end that is set to a non-zero value when a data burst end exists, otherwise it is set to 0.

[0072] PDU Set Importance [PSI] (4-bit field): 335 and 435 indicate the importance of a PDU set compared to other PDU sets within the same QoS flow. Lower values ​​indicate higher importance PDU sets, with the highest importance PDU set being 0 and the lowest importance PDU set being 15.

[0073] PDU Set Sequence Number [PSSN] (10-bit field) 336, 436 encodes the sequence number of the PDU set to which the current PDU belongs. The sequence number acts as a 10-bit numeric identifier for the PDU set and wraps around at 1023.

[0074] The PDU sequence number [PSN] (6-bit field) within the PDU set indicates the sequence number of the current PDU within the set, with values ​​337 and 437. The PSN is set to 0 for the first PDU in the set and monotonically increments for each PDU in the set in the order it was transmitted from the sender. The PSN wraps around at position 63.

[0075] PDU Set Size [PSSize] (24-bit field) 338, 438 indicates the total size of all PDUs in the PDU set to which this PDU belongs. This field is optional and subject to SDP signaling provide / response negotiation, where the AS can indicate whether it will be able to provide the size of the PDU set for that RTP flow. If not enabled, this field does not exist. If enabled, but the AS cannot determine the PDU set size for a particular PDU set, it should set the value to 0 for all PDUs in that PDU set. PSSize indicates the size of the PDU set, including the RTP / UDP / IP header encapsulation overhead of its corresponding PDUs. PSSize is expressed in bytes.

[0076] Number of PDUs in PDU Set [NPDS] (16 bits) 339, 439 indicates the total number of PDUs in the PDU set. This field is optional and subject to SDP signaling provide / response negotiation, where the RTP sender can indicate whether it will be able to provide the number of PDUs in the PDU set for that RTP stream. When the PDU set size field exists, it is recommended to add the number of PDUs to the PDU set field.

[0077] The above examples pertain to downlink (DL) services. The reverse processing applies to uplink (UL) services, where the UPF240 packet inspection role is assumed by the UE 235. The UE 235 is expected to inspect uplink packets, determine packets belonging to the PDU set, and accordingly signal the RAN 230 set to the PDUs for scheduling and resource allocation corresponding to the associated DRB implementations (i.e., PSDB and PSER) that meet the QoS requirements of the PDU set. The low-level signaling mechanisms associated with UL UE-RAN information transmission depend on the specifications and implementation scheme of the RAN signaling process.

[0078] Figures 5a to 5d This describes a 5GS PDU set-aware QoS handling framework for mapping PDU sets to QoS flows to DRBs. Depending on the QoS flow mapping and RAN process, several alternative PDU set-to-QoS flow-to-DRB mappings are possible given two dissimilar PDU sets with different PDU set attributes (e.g., PDU set importance). Figure 5 illustrates some options where two PDU sets 510 of different importance and characteristics are mapped to QoS flows 520 and respectively mapped to Data Radio Bearers (DRBs) 530. In this example, consider a high-importance PDU set 1 with strict QoS requirements (i.e., PSDB, PSER, etc.) and a low-importance PDU set 2 with potentially lower QoS requirements (i.e., PSDB, PSER, etc.) than PDU set 1. As illustrated in Figure 5, depending on the QoS flow policy and Layer 2 RAN process, the PDU set 510 to QoS flow 520 to DRB 530 can be illustrated as follows:

[0079] Figure 5a Explanation 1:1:1 mapping: This involves separating QoS flows 520 and DRBs 530 between high and low importance PDU sets 510, thereby finely optimizing radio and network resources on a per PDU set basis.

[0080] Figure 5b Explanation of M:M:1 mapping: where separation between high and low importance PDU sets 510 is performed only at the QoS flow level, and the same DRB 530 is used for over-the-air transmission of both PDU sets 510. This may result in over-supply of radio resources to the low importance PDU set 510, but requires lower RAN complexity and management overhead.

[0081] Figure 5cExplanation of M:1:1 mapping: There is no separation between QoS flows 520 and DRB 530 for PDU sets 510 of different importance, and the QoS requirements of higher importance PDU sets are prioritized when handling QoS management across both CN and RAN. This may result in over-supplying resources to the low importance PDU set 510 in both CN and RAN implementations, but requires lower overhead and control within the 5GS QoS framework.

[0082] Figure 5d Explanation of M:1:M mapping: There is no separation of QoS flows 520 across PDU set importance levels, but different DRBs 530 are used to meet individual requirements of different importance levels; this increases the complexity of QoS flow management and uses PDU set information to filter PDU sets 510 on different DRBs 530 in order to better match RAN-level QoS requirements and optimize resource allocation according to individual PDU set requirements.

[0083] Figure 6 This describes a UPF that identifies dynamic changes in the business characteristics of XR services. Figure 6 The demonstration system 600 includes Extended Reality Media Application Functions (XRM AF) 610, Policy and Control Functions (PCF) 615, Session Management Functions (SMF) 620, Access and Mobility Functions (AMF) 625, Radio Access Network (RAN) 630, User Equipment (UE) 635, User Plane Functions (UPF) 640, and Extended Reality Applications 645. The UE described herein may include Remote Unit 102, UE 235, 635, 835, or 1000 as described herein. The UPF described herein may include User Plane Functions (UPFs) as described herein, such as UPF 240, 640, 740, 840, or 940; or Network Equipment 1200.

[0084] exist Figure 6 In the diagram, data associated with I-frames of video content is displayed as dashed lines, data associated with P-frames of video content is displayed as hash patterns, and data associated with B-frames of video content is displayed as striped patterns. The operation of System 600 will now be described in the context of a downlink service example; a similar process can be performed for uplink services.

[0085] When requesting an AF session from a 3GPP network (NEF), AF 610 includes additional information indicating dynamic changes in the service characteristics that the XR service may have. AF 610 may also include information indicating the maximum and / or minimum and / or average expected PDU set size for the XR service. It should be noted that this assumes the third-party provider of the AF and the 3GPP network have an SLA agreement to include information regarding service characteristics. For IP flow (5-tuple) PDU set requirements, information indicating that the session may change service characteristics and the maximum expected PDU set size may be included is required.

[0086] In 3GPP networks, PCF 615, which provides PCC rules, determines MDBV to support the service characteristics of XR services. PCF 615 can determine MDBV based on input from the AF or based on operator policies. PCF 615 may also include an indication of a PDU set size threshold. The PDU set size threshold is the incentive for the core network (i.e., UPF 640) to notify the gNB (RAN 630) that the size of the received PDU set exceeds the size threshold. The gNB uses this information to schedule resources accordingly and ensure that the PDU set is delivered to UE 635 within the PDU set QoS requirements. PCF 615 can determine and provide several thresholds in which the gNB needs to be notified; that is, a range of PDU set sizes can be defined. PCF 615 may also include minimum, maximum, and average PDU set size information in the PCC rules. The minimum, maximum, and average values ​​can be provided by the AF. Alternatively, they can be determined by the UPF / SMF. PCF 615 can determine whether UPF 640 needs to detect PDU set size changes above a certain threshold. The threshold can be configured based on operator preferences. PCF 615 passes PCC rules with PSDB requirements to SMF 620, and the PCC rules may include PDU set size change threshold information. The threshold information may include a PDU set size threshold.

[0087] The SMF 620, which constructs QoS rules based on PCC rules, can include an indication of the PDU set size threshold and the minimum, maximum, and average PDU set size information provided to the RAN / gNB within the N2 message.

[0088] The SMF 620 constructs N4 rules based on PCC rules, where N4 rules may contain instructions for enabling the UPF 640 to detect changes in PDU set size between received PDU sets. The SMF may also include a PDU set size threshold. For example, N4 rules may include instructions for detecting changes in PDU set size, as well as threshold information.

[0089] The UPF 640 can perform the following actions.

[0090] If a threshold is provided, the UPF 640 is configured to identify the PDUs in the PDU set and determine whether the PDU set size exceeds the threshold. If the PDU set size is higher than the threshold, the UPF adds a flag indicating that the next PDU set size will exceed the threshold to the previously received PDU set. In another embodiment, before sending a PDU set whose size exceeds the threshold, the UPF includes a dummy packet containing information notifying that the next PDU set size exceeds the threshold. In this embodiment, after receiving the first PDU of a large PDU set (i.e., higher than a predetermined threshold) for the service data stream at the N6 interface, a dummy packet is constructed and sent to the gNB. The UPF may buffer the PDU set until all its PDUs are received, and it may use the PDU set size information or, alternatively, the PDU set tagging information available in the RTP header extension to determine when and how to construct and send the dummy packet to the gNB. In some embodiments, the gNB may discard the dummy packet because it does not carry application logic information.

[0091] In an alternative instance, while still providing a threshold, the UPF 640 is configured to identify the PDUs in the PDU set and determine whether the PDU set size exceeds the threshold. If the PDU set size is higher than the threshold, the UPF adds the PDU set size to the previously received PDU set. In another embodiment, before sending a PDU set whose size exceeds the threshold, the UPF includes a dummy packet containing PDU set information, which includes the size of the next PDU set. In this embodiment, after receiving the first PDU of a large PDU set (i.e., higher than a predetermined threshold) for the service data stream at the N6 interface, a dummy packet is constructed and sent to the gNB. The UPF 640 may buffer the PDU set until all its PDUs are received, and it may use the PDU set size information or, alternatively, the PDU set tagging information available in the RTP header extension to determine when and how to construct and send the dummy packet to the gNB. In some embodiments, the gNB may discard the dummy packet because it does not carry application logic information.

[0092] However, if no threshold is provided, the UPF 640 determines the PDU set size and adds it to the previously received PDU set (e.g., if the PDU set size threshold is not included in the N4 rule). Alternatively, before sending the PDU set to the gNB, the UPF 640 includes a dummy packet containing PDU set information indicating the size of the next PDU set. The gNB may discard the dummy packet because it does not carry application logic information.

[0093] Figure 7 This is an explanation Figure 6 The message passing diagram for the operation of System 600 is described in the document. Figure 7 This describes the process by which gNBs are allowed to detect changes in dynamic service characteristics (700). Figure 7 This section describes gNB 730, Access and Mobility Functions (AMF) 725, User Plane Functions (UPF) 740, Session Management Functions (SMF) 720, Policy and Control Functions (PCF) 715, Network Exposure Functions (NEF) 750, Application Functions (AF) 745, and Application Server (AS) 755.

[0094] Procedure 700 begins at 771, where AF 745 requests the establishment of an AF session with QoS, including PDU settings for XR services, by invoking the Nnef_AFSessionWithQoS create service operation as described in clause 4.15.6.6 of 3GPP TS 23.502 v18.3.0 (September 2023), entitled "Procedures for the 5G System (5GS)". The AF may additionally include information indicating dynamic changes in the service characteristics that the XR service may have. The AF may also include information indicating the maximum and / or minimum and / or average expected PDU set size for the XR service. That is, the AF session request may include protocol descriptions such as the packet's 5-tuple (UE address, content server address, source / destination port, and protocol identifier), PDU set QoS requirements (minimum / maximum PDU set size), and / or indications of dynamic changes in service characteristics.

[0095] Although not shown in the diagram, the NEF 750 authorization request forwards the request to the PCF 715 by invoking the Npcf_PolicyAuthorization_Create request, which contains information provided by the AF 745.

[0096] At 772, PCF 715 creates PCC rules that take into account PDU set QoS parameters, as described in Clause 6.1.3.22 of 3GPP TS 23.503 v18.3.0 (September 2023), entitled "Policy and charging control framework for the 5G System (5GS); Stage 2". PCF 715 determines QoS rules that may include MDBV to support the service characteristics of XR services. PCF 715 may determine this based on input from AF 745 or based on operator policies. PCF 715 may also include an indication of a PDU set size threshold, which the gNB 730 needs to be aware of and schedule resources accordingly when the PDU set size threshold is exceeded.

[0097] At position 773, PCF 715 sends PCC rules to SMF 720. PCC rules may include 5-tuple PDU set QoS, service characteristic awareness indication, and PDU set size threshold.

[0098] At 774, the SMF 720 identifies the PDU session of the affected UE and determines the updated QoS rule. The SMF 720 may include the PDU set size threshold from the updated QoS rule message to the AMF 725 in the updated QoS rule.

[0099] At 775, SMF 720 sends the updated QoS rules to AMF 725 in a Namf message or Nsmf message (in response to PDU session creation / update). The updated QoS rules include a PDU set size threshold.

[0100] At position 776, the AMF 725 forwards the updated QoS rules to the gNB 730 in an N2 message. The N2 message contains the updated QoS rules, which in turn contain a PDU set size threshold.

[0101] At 777, when the SMF 720 receives confirmation from the gNB 730 that it has received the updated QoS rule, the SMF 720 creates a packet detection rule (N4 rule) for the UPF. The SMF includes information used to detect changes in PDU set size between received PDU sets in the PDR. If included in the PCC rule provided by the PCF 715, then the SMF 720 includes a PDU set size threshold.

[0102] At position 778, the SMF 720 sends the N4 rule to the UPF 740. The N4 rule includes the group detection rule, the PDU set size change recognition, and the PDU set size threshold.

[0103] At position 779, the UPF receives and sends a series of PDUs for XR services from the application server. This series of PDUs may be referred to as XR packets. The series of PDUs may include a first PDU set with a PDU set size equal to the normal PDU set size, and a second PDU set with a PDU set size equal to the high PDU set size. The RTP encoder in the application server may include the PDU set information within the RTP extended header.

[0104] At 780, UPF 740 examines the PDUs and determines that a matching N4 / PDR rule exists. Based on the N4 rule, UPF 740 determines that PDU set identification is required and also identifies changes in PDU set size between received PDU sets. The following options may be available for identifying changes in PDU set size.

[0105] The UPF 740 identifies the PDUs in the PDU set and determines whether the PDU set size exceeds a threshold. If the PDU set size is higher than the threshold, the UPF adds a flag indicating that the next PDU set will be larger than the threshold to the previously received PDU set. In another embodiment, before sending a PDU set whose size exceeds the threshold, the UPF includes a dummy packet containing information notifying that the next PDU set will be larger than the threshold.

[0106] The UPF 740 identifies the PDUs in the PDU set and determines whether the PDU set size exceeds a threshold. If the PDU set size exceeds the threshold, the UPF adds the PDU set size to the previously received PDU set. In another embodiment, before sending a PDU set whose size exceeds the threshold, the UPF includes a dummy packet containing PDU set information, which includes the size of the next PDU set.

[0107] • The UPF 740 determines the PDU set size and adds the PDU set size to the previously received PDU set (e.g., if the PDU set size threshold is not included in the N4 rule). In another embodiment, before sending the PDU set, the UPF includes a dummy packet containing PDU set information, which includes the upcoming PDU set size for the next PDU set.

[0108] At 781, UPF 740, based on one of the options described in step 780, sends information indicating a change in the PDU set size to gNB 730 via N3 within the GTP-U. The N3 GTP-U header includes a PDU set size notification for the upcoming PDU set.

[0109] At 782, when gNB 730 receives an indication that the size of the upcoming PDU set is higher than a threshold, gNB adjusts scheduling resources to ensure that the PDU set is sent within the QoS requirements of the QoS flow.

[0110] As Figure 7 In an alternative arrangement shown, the gNB may not receive additional information as part of the QoS requirements for the established QoS flow. Instead, it may receive the PDU set QoS requirements and MDBV value as described in 3GPP TS 23.501 v18.2.2. When the gNB receives an indication that the size of the upcoming PDU set is higher than a threshold, the gNB considers whether the upcoming PDU set has a larger MDBV value than the received QoS requirements. If the upcoming PDU set has a larger MDBV value than the received QoS requirements, the gNB adjusts its scheduling resources to ensure that the PDU set is transmitted within the QoS requirements of the QoS flow.

[0111] The following describes the arrangement that provides support for PDU set size variation at the application server and / or RTP encoder.

[0112] To avoid excessive buffering at the UPF that could consume and impact the PSDB of some PDU sets, the RTP sender (i.e., the AS or alternatively the UE) can additionally support indications of dynamic service characteristics, such as large PDU set sizes exceeding a determined threshold. Based on these indications, the core network (CN) (i.e., the UPF) can determine the dynamic service characteristic indications without additional buffering requirements and further signal this information to the gNB in ​​the data plane via the N3 GTP-U encapsulated tunnel, as previously detailed.

[0113] Figure 8 Explain the RTP sender awareness and signaling for dynamic PDU set size. Figure 8 System 800 is described, comprising Extended Reality Media Application Functions (XRM AF) 810, Policy and Control Functions (PCF) 815, Session Management Functions (SMF) 820, Access and Mobility Functions (AMF) 825, Radio Access Network (RAN) 830, User Equipment (UE) 835, User Plane Functions (UPF) 840, and Extended Reality Applications 845. The UE described herein may include Remote Unit 102, UE 235, 635, 835, or 1000 as described herein. The UPF described herein may include User Plane Functions (UPFs) as described herein, such as UPF 240, 640, 740, 840, or 940; or Network Equipment 1200.

[0114] exist Figure 8 In the diagram, data associated with I-frames of video content is displayed as dashed lines, data associated with P-frames of video content is displayed as hash patterns, and data associated with B-frames of video content is displayed as striped patterns. The operation of System 800 will now be described using a downlink service example; a similar process applies to uplink services.

[0115] At 871, AF 810 requests an AF session from the 3GPP network (PCF / NEF), the AF session containing additional information indicating dynamic changes in the service characteristics that the XR service may have. AF 810 may also include information indicating the maximum and / or minimum and / or average expected PDU set size for the XR service. The AF session request may include PDU set requirements for IP flows (5-tuples) and indications that the session may change service characteristics. The AF session request may further include information on the maximum expected PDU set size. In some example implementations, it may be assumed that the third-party provider of the AF and the 3GPP network have an SLA agreement to include information about service characteristics (e.g., maximum / minimum PDU set size that can be used with PDU set QoS flow guarantees, a set of dedicated applicable PDU set size thresholds for different service levels, etc.).

[0116] At 872, the PCF 815 in the 3GPP network provides PCC rules to the SMF 820. The PCC rules may include PSDB requirements, PDU set size changes, and / or threshold information. The PCC rules determine the MDBV to support the service characteristics of XR services. The PCF 815 may determine the MDBV based on input from the AF or based on operator policies. The PCF 815 may also determine a PDU set size threshold and include an indication of its dynamic handling as a service characteristic. The threshold may be configured based on operator preferences. The PDU set size threshold is an incentive for the RTP sender (e.g., AS or alternatively, peer UE) to assist the gNB in ​​handling application data exceeding the threshold. In the event that an incoming PDU set exceeds the size threshold, the RTP sender may include additional information in the 5GS, or alternatively, schedule the transmission of the PDU set exceeding the threshold into multiple PDU sets not exceeding the threshold. The gNB (e.g., RAN 830) uses this information and / or the generated PDU sets to schedule resources accordingly and ensure that the PDU set is delivered to the UE within the PDU set QoS requirements.

[0117] At 873, the PCF 815, which provides PCC rules and determines the PDU set size threshold, can additionally expose the PDU set size threshold to the AF request for the AF session. This is accomplished through an AF session response sent in response to the AF session request. The PCF 815 sends an AF session response to the AF 815 containing QoS parameters for PDU set handling and the PDU set size threshold information. The AF then informs the RTP sender of the QoS session configuration and the PDU set size threshold, allowing the RTP sender (i.e., the AS or alternatively the UE) to adopt an appropriate transmission strategy. In this example, the XR AF 810 supports sending PDU set size threshold information for dynamic service characteristics; in this example, the PDU set size threshold is 800 KB.

[0118] At position 874, the SMF 820, which constructs QoS rules based on PCC rules, can include an indication of the PDU set size threshold provided to the RAN / gNB within the N2 message. QoS rules can include the PDU set size threshold.

[0119] At 875, the SMF constructs the N4 rule based on the PCC rule, where the N4 rule may contain an indication for enabling the UPF to detect changes in the PDU set size between received PDU sets. The SMF may also include a PDU set size threshold.

[0120] The UPF 840 detects dynamic PDU set size changes based on signaling received from the AS, such as via RTP header extensions. Upon detecting a dynamic PDU set size change, the UPF 840 adds an indication from the GTP-U header to the RAN 830.

[0121] The RTP sender may also implement the following strategies based on the dynamic response and dynamic service characteristics of AF session requests in the 3GPP network.

[0122] For example, when the network provides a threshold for the PDU set size, the RTP sender can perform pacing transmissions by applying the PDU set size threshold response from the 3GPP network to the packet pacing unit, such that the PDU set size threshold is used to limit the pacing of outbound PDU sets (i.e., data bursts) to no more than a certain MBDV. Typically, the RTP pacing sender ensures a smooth flow of service data by applying a finite buffer at the media source. The buffer queues the media before it is transmitted through the network. Pacing can be implemented using a leaky bucket algorithm, ensuring that a maximum-sized data burst, i.e., PDU set, is sent through the 3GPP network. In some implementations, the buffer may contain separate FIFO queues for individual media tracks, where additional priorities based on additional RTP sender strategies (e.g., audio over video, etc.) can be applied, or alternatively, cyclic pacing transmission can be applied to prevent any media stream from blocking other media streams. This RTP sender strategy applies pacing to all packets and PDU sets, thereby ensuring a nearly constant data rate across both short and long time intervals at the cost of increased content latency at the source and logical mismatches between PDU sets and video frames.

[0123] Alternatively, when the network provides a threshold for PDU set size, the RTP sender may buffer at least two consecutive PDU sets, such as those released by the media encoder. The RTP sender checks the size of each PDU set against the PDU set size threshold indicated by the 3GPP network. If, for the current PDU set, the PDU set size exceeds the PDU set size threshold, the RTP sender indicates to the 3GPP network in the previous PDU set that the next PDU set is a large PDU set whose size exceeds the PDU set size threshold. This indication may be part of a PDU set marker as an additional information field, or alternatively, it may be part of a new RTP header extension for dynamic service features. In some embodiments, the indication may only include a flag (e.g., an information bit) indicating that the next PDU set in the sequence of PDU sets for the service data stream is a large PDU set. In other embodiments, the indication may include additional information related to at least one of the PDU set sequence number whose PDU set size exceeds the threshold and the PDU set size exceeding the threshold. This RTP sender strategy ensures that the logical mapping from PDU sets to Application Data Units (ADUs) is preserved, while limiting latency to the time interval of one media frame per second corresponding to the multimedia source.

[0124] The RTP sender may buffer a maximum of one PDU set for each media stream of the service data stream and apply a 3GPP network PDU set threshold to determine whether the PDU set exceeds the 3GPP network PDU set threshold.

[0125] In one embodiment, if the PDU set in the buffer exceeds a PDU set size threshold, the RTP sender may split the PDU set into two PDU sets. The first PDU set contains at least one PDU from the buffered PDU set, and the second PDU set contains the remaining PDUs from the buffered PDU set. If, for the second PDU set, the PDU set size still exceeds the PDU set size threshold, the RTP sender indicates to the 3GPP network from the first PDU set that the next PDU set (i.e., the second PDU set) is a large PDU set whose size exceeds the PDU set size threshold. This indication may be a portion of the PDU set marker as an additional information field in the RTP header extension, or alternatively, a portion of a new RTP header extension for dynamic service features. In some embodiments, the indication may only include a flag (e.g., an information bit) indicating that the next PDU set in the sequence of PDU sets for the service data stream is a large PDU set. In other embodiments, the indication may include additional information related to at least one of the PDU set sequence number whose size exceeds the threshold and the PDU set size exceeding the threshold. The interval between sending the first PDU set and the second PDU set to the 3GPP network can be determined by the RTP sender based on a static low-latency configuration (e.g., a maximum of 1 to 2 ms), the 3GPP network configuration as part of a response signaling a PDU set size threshold, or an SLA between a third-party ASP and the 3GPP network operator. This RTP sender strategy ensures that latency at the source is reduced to a minimum for a single media frame, but it does not preserve the logical mapping of PDU sets to Application Data Units (ADUs) for PDU sets exceeding the PDU set size threshold.

[0126] In an alternative instance, but still where the PDU set in the buffer exceeds a PDU set size threshold, the RTP sender may introduce a dummy PDU set (e.g., without media payload) and use it to indicate to the 3GPP networks in the user plane (i.e., UPF and gNB) that an upcoming large PDU set exceeding the PDU set size threshold is about to arrive. The dummy PDU set may contain a single RTP PDU (e.g., without media payload) carrying 3GPP metadata information indicating the upcoming large PDU set, and is sent before the large PDU set. The indication may be a portion of the PDU set marker on the RTP header extension as an additional information field, or alternatively, a portion of a new RTP header extension for dynamic service features. In some embodiments, the indication may simply include a flag (e.g., an information bit) signaling that the next PDU set in the sequence of PDU sets for the service data stream is a large PDU set. In other embodiments, the indication may include additional information related to at least one of the following: a flag indicating that the current PDU set is a dummy PDU set; a timing interval describing the expected arrival time of an upcoming large PDU set; the sequence number of an upcoming PDU set whose PDU set size exceeds a threshold; and the PDU set size of the upcoming PDU set exceeding the threshold. The interval between sending dummy PDU sets and large PDU sets to the 3GPP network may be determined by the RTP sender based on a static low-latency configuration (e.g., a maximum of 1 to 2 ms), a 3GPP network configuration as part of a response to signaling a PDU set size threshold, or an SLA between a third-party ASP and the 3GPP network operator. This RTP sender strategy ensures that latency at the source is reduced to a minimum for a single media frame while preserving the logical mapping of all PDU sets to Application Data Units (ADUs).

[0127] In a further example, the RTP sender may combine any of the above sender strategies to achieve the desired processing of the media stream within the service data stream based on application-level requirements for latency and PDU set / ADU processing.

[0128] Figure 9 The document details the steps involved in implementing the aforementioned RTP sender strategy. Figure 9 This is an explanation Figure 8 The message passing diagram for the operation of System 800 is described in the document. Figure 9 This describes the process by which gNBs are allowed to detect dynamic changes in service characteristics. (900) Figure 9This section describes gNB 930, Access and Mobility Function (AMF) 925, User Plane Function (UPF) 940, Session Management Function (SMF) 920, Policy and Control Function (PCF) 915, Network Exposure Function (NEF) 950, Application Function (AF) 945, and Application Server (AS) / RTP sender 955.

[0129] Procedure 900 is an example procedure for enabling a gNB to be aware of dynamic service characteristic changes with the support of an RTP sender (e.g., AS). Procedure 900 begins at 971, where AF 945 requests the RTP sender to enable the 3GPP network to establish an AF session with QoS by invoking the Nnef_AFSessionWithQoS create service operation (containing QoS parameters for PDU settings for XR services) as described in Clause 4.15.6.6 of 3GPP TS23.502. The AF may additionally contain information indicating that the XR service may have dynamic changes in service characteristics. The AF may also contain information indicating the maximum and / or minimum and / or average expected PDU set size for the XR service and the RTP sender's capabilities for supporting dynamic service characteristic awareness signaling. For example, the AF session request may include a protocol description including the 5-tuple of the packet (UE address, content server address, source / destination port, and protocol identifier), PDU set QoS requirements (minimum / maximum PDU set size and / or an indication of dynamic changes in service characteristics with the support of the RTP sender).

[0130] Although not shown in the diagram, the NEF 950 authorizes the request by invoking the Npcf_PolicyAuthorization_Create request, which contains information provided by the AF 945, and forwards the request to the PCF 915.

[0131] At 972, PCF 915 creates PCC rules taking into account the PDU set QoS parameters as described in Clause 6.1.3.22 of 3GPP TS 23.503 v18.3.0. PCF 915 determines QoS rules including MDBV to support service characteristics of XR services. PCF can be determined based on input from AF or operator policies. PCF may also include an indication of a PDU set size threshold, when which the gNB needs to be aware of and schedule resources accordingly. For example, PCF 915 may determine to enable service characteristic awareness at gNB 930.

[0132] At 973, AF 945 forwards PCF 915's response to the AF session request in step 971 to RTP sender 955. The response may include acceptance of the AF session request. The response may contain additional new information, including PDU set size threshold information for dynamic service feature support. Alternatively, the PDU set size may be determined by the RTP sender based on an SLA (e.g., based on the requested PSDB or based on the service ID). AF 945 may forward the PDU set size threshold information for service feature support to RTP sender 955. The PDU set size threshold information may be delivered to RTP sender 955 via the AF session response or according to a Service Level Agreement (SLA).

[0133] At position 974, a PCC rule is sent from PCF 915 to SMF 920. The PCC rule may contain a 5-tuple PDU set QoS, a service characteristic awareness indication, and a PDU set size threshold.

[0134] At 975, SMF 920 identifies the PDU sessions of the affected UE and determines the updated QoS rules. SMF 920 may include the PDU set size threshold from the updated QoS rule message to AMF 925 in the updated QoS rules.

[0135] At position 976, the SMF 920 sends the updated QoS rules to the AMF 925 in a Namf message or Nsmf message (in response to PDU session creation / update). The updated QoS rules may include a PDU set size threshold.

[0136] At 977, AMF 925 forwards the updated QoS rules (including the PDU set size threshold) to gNB930 in the N2 message.

[0137] At 978, when the SMF 920 receives confirmation from the gNB 930 that it has received the updated QoS rule, the SMF 920 creates a packet detection rule (N4 rule) for the UPF. The SMF 920 includes information used to detect changes in PDU set size between received PDU sets in the PDR. If included in the PCC rule provided by the PCF 915, then the SMF 920 includes a PDU set size threshold. In this way, the SMF 920 creates an N4 rule for the UPF 940 to identify PDU sets with changing PDU set sizes.

[0138] At position 979, SMF 920 sends an N4 rule to UPF 940. The N4 rule contains additional information about the RTP sender's support for dynamic service feature PDU set size changes (e.g., a protocol description with RTP header extensions and enabled RTP sender support for dynamic PDU set size changes). The N4 rule may include packet detection rules, PDU set size change identification, PDU set size thresholds, and / or RTP sender support for PDU set size changes.

[0139] At 980, the RTP sender 955 (e.g., AS or alternatively peer UE) performs the following processing.

[0140] a. The RTP sender 955 uses the information exposed by the network in step 973 (i.e., at least the PDU set size threshold) to configure and select RTP sender strategies (e.g., full-step transmission, 2-PDU set buffering, large PDU set splitting, dummy PDU set insertion, or a combination thereof) to support dynamic service feature awareness and PDU set size changes.

[0141] b. The RTP sender 955 application selects an RTP sender policy to send and mark dynamic service characteristic changes as needed, based on a PDU set size threshold set by the network. The marking of dynamic PDU set size changes is performed on the UPF in the user plane via the N6 interface, and the information is carried as part of the PDU set marking the RTP header extension, or alternatively as a separate RTP header extension. XR packets may include support for dynamic PDU set size changes, for example, an indication of when the next PDU set of the service data stream exceeds the PDU set size threshold.

[0142] At position 981, UPF 940 examines the incoming PDUs and determines that a matching N4 / PDR rule exists. Based on the N4 rule, the UPF determines that PDU set identification is required and identifies changes in PDU set size between received PDU sets. This is done by the RTP sender signaling portion based on RTP header extensions (e.g., RTO header extensions for PDU set marking or other RTP header extensions). The UPF determines the PDUs in the PDU set and, based on information provided by the RTP sender in the user plane, determines whether the upcoming PDU set size exceeds a threshold. For example, this determination can be made via RTP header extensions based on AS indications in the user plane.

[0143] At 982, UPF 940, based on step 981, sends information indicating a change in the PDU set size to gNB via N3 within the GTP-U. The N3 GTP-U header may include a PDU set size notification for the upcoming PDU set.

[0144] At 983, the gNB 930 adjusts its scheduler to handle PDU sets exceeding a threshold. For example, when the gNB receives an indication that the size of an upcoming PDU set exceeds a threshold, the gNB can adjust scheduling resources to ensure that the MDBV service PDU set is served within the PSDB according to the QoS requirements of the QoS flow. Although the fact is... Figure 9 The stream instance in the reference DL instance is presented, but the RTP sender follows the same process as detailed for both UL and DL service data streams in the above embodiments to mark dynamic service characteristic changes relative to the PDU set size.

[0145] The behavior of an RTP receiver in processing dynamic service characteristic indications as described above will now be described. An RTP receiver may include a RAN, gNB, or UE.

[0146] The RAN and gNB radio resource schedulers can leverage dynamic service characteristic changes relative to the upcoming large PDU set size. Therefore, the gNB can adapt its scheduling routines and policies to proactively reserve radio resources for upcoming large PDU sets based on the previously detailed indications of dynamic service characteristic changes. This provides an advantage in meeting the PSDB and QoS requirements of PDU sets for QoS flows, even for large PDU sets exceeding the PDU set size threshold configured by the core network for a session. To this end, the relevant steps of gNB behavior are as follows, referring to both the downlink (DL) and uplink (UL) directions.

[0147] In the DL direction, the gNB receives an indication as part of the GTP-U header of an upcoming large PDU set, where the PDU set exceeds the PDU set size threshold set for sessions on QoS flows. The PDU set indicated in its GTP-U header is transmitted before the large PDU set within a time interval determined by service characteristics (i.e., media frames per second, service periodicity, and jitter statistics), or alternatively, by a configured timing interval (e.g., pacing intervals for splitting large PDU sets in the network configuration, the time interval for dynamic signaling notifications between dummy PDU sets and the large PDU set, etc.). In some embodiments, the indication of metadata information corresponding to dynamic service characteristics includes at least one of the following.

[0148] • Determine the flags or identifiers for dynamic service characteristic indication types (e.g., dynamic service characteristic changes of a large PDU set);

[0149] • A flag indicating that the PDU set contained in its GTP-U header is a dummy PDU set generated by a 3GPP network (i.e., UPF) and therefore negligible from services on the air interface, a dummy PDU set generated by an RTP sender, or alternatively a split first PDU set generated by an RTP sender from a large PDU set divided into two parts, wherein the first part (i.e., the first PDU set) indicates the second part (i.e., the second PDU set), provided that the second part is still above the PDU set size threshold;

[0150] • Send its GTP-U header containing the timing interval between the indicated PDU set and the indicated upcoming large PDU set;

[0151] • An identifier pointing to an upcoming large PDU set whose size exceeds a threshold; and / or a PDU set sequence number;

[0152] • Signals the size of an upcoming large PDU set that is larger than the PDU set size threshold using the PDU set size field.

[0153] gNB uses indication information to dynamically adjust radio resource scheduling and prepare for upcoming large PDU sets, thereby ensuring that sufficient radio resources (e.g., scheduling time slots and frequency resource blocks) are available to satisfy the large PDU set PSDB associated with its QoS flow.

[0154] When serving a PDU set under the PSDB of a QoS flow, the gNB manages the following three scenarios.

[0155] In the first case, there are two PDU sets corresponding to two different ADUs, where the first PDU set is sent before the second PDU set and the first PDU set indicates the second larger PDU set:

[0156] • Given the PSDB of the associated QoS flows, the first PDU set is served by the gNB based on RAN legacy procedures. The indication contained in the GTP-U header of the first PDU set is used by the gNB as input to the scheduler routine to pre-allocate / prepare radio resources for the second large PDU set.

[0157] When the second PDU set arrives at the gNB, the large PDU set is served according to the resources allocated based on the associated QoS flow PSDB and RAN legacy procedures. In some embodiments, if the second PDU set fails to arrive at the gNB within a statically configured time interval longer than the expected arrival time, the gNB may preempt the pre-allocated radio resources of the second PDU set.

[0158] In the second case, there are two PDU sets, where the first PDU set is sent as a dummy PDU set before the second PDU set, and the dummy PDU set indicates the second largest PDU set:

[0159] • Dummy PDU sets may be discarded by the gNB if they are generated within the 3GPP network (i.e., at the UPF). However, if the dummy PDU set is not generated by the 3GPP network and originates from the RTP sender, the gNB may not discard it. In such instances, given the PSDB of the associated QoS flows, the gNB will serve the dummy PDU set with the lowest PDU set importance (i.e., priority) according to RAN legacy procedures. Regardless of the discarding of the dummy PDU set, the gNB processes the indication carried in its GTP-U header to prepare for radio resource allocation for the upcoming second-largest PDU set.

[0160] When the second PDU set arrives at the gNB, the large PDU set is served according to the resources allocated based on the associated QoS flow PSDB, based on the RAN legacy process. If the second PDU set fails to arrive at the gNB within a statically configured time interval longer than the expected arrival time, the gNB may preempt the pre-allocated radio resources of the second PDU set.

[0161] In the third case, there are two PDU sets corresponding to the same ADU, where the first PDU set is the first part of the ADU (e.g., at least one PDU) and the second PDU set is the remaining part of the ADU, with the first PDU set indicating a second, larger PDU set. In this case, the gNB utilizes the information available in the indication corresponding to the first PDU set to prepare and / or pre-allocate radio resources for the second (i.e., larger) PDU set. However, since the two PDU sets correspond to the same ADU at the application layer, the gNB can further use this information to optimize its service to the PDU sets using conservative or greedy gNB processing under the PSDB of the QoS flow.

[0162] Since the PDU set belongs to the same ADU, it is typically handled by the gNB, for example, by implementing a shared PSDB using a timer. Therefore, the gNB handling is the same as the traditional RAN process for handling a single PDU set, and can be referred to as 'conservative gNB handling'. If the first PDU set exceeds the PSDB or cannot be served by the gNB under PSDB guarantees, and PDU set integrated handling has been configured for this QoS flow / bearer (e.g., PSIHI has been configured), the second PDU set is automatically discarded based on its reference to the first PDU set. This reference is determined based on the GTP-U header indication of the first PDU set (e.g., based on UPF dynamic service characteristic detection or RTP sender signaling determination), thus identifying it as the split first PDU set. Figure 10It provides instance header information for interdependent PDU sets with dynamic business characteristics indications.

[0163] Alternatively, the gNB can leverage the fact that the PDU sets belong to the same ADU and are split by the RTP sender. The gNB independently controls the latency status of the two PDU sets by assigning two separate (PDCP) timers to the two PDU sets, for example, based on the PSDB of the QoS flow. The gNB will serve the first PDU set independently of the second PDU set based on its own timer. When the second PDU set arrives in the gNB buffer and its timer is started, the gNB also resets the timer for the first PDU set. This dynamic timer adjustment of the first PDU set ensures that once both split PDU sets are in the RAN buffer, the gNB processes both split PDU sets together, and therefore does not disadvantage the second largest PDU set. This might be referred to as 'greedy gNB processing'.

[0164] If the first PDU set cannot fulfill its PSDB (e.g., due to exceeding its PSDB, or due to air interface congestion preventing scheduling within the PSDB, or typically when setting PSIHI for this QoS flow, once the loss of a PDU in the first PDU set is known), the gNB will discard both the first and second PDU sets, since the two PDU sets are related and belong to the same ADU. The same behavior applies when the loss of a PDU in the second PDU set is known; for example, the gNB will discard both the first and second PDU sets—assuming PSIHI is set for this QoS flow.

[0165] Figure 10 It is the instance header information of two interdependent PDU sets (i.e., the two PDU sets logically represent the same ADU) with dynamic service characteristics indication, wherein the first PDU set 1010 carries information about the dynamic service size characteristics changes of the second PDU set 1020.

[0166] In some communication schemes, the time interval dt between the start (or alternatively the end) of the first PDU set 1010 and the second PDU set 1020 can be approximately 1 or 2 milliseconds. The header 1015 of the first PDU set 1010 is displayed in a magnified view and includes PDU set marking information 1016 and dynamic service size change information 1017. The PDU set marking information 1016 includes: PDU set sequence number, PDU sequence number, the last PDU in the PDU set, PDU set importance, and PDU set size. The dynamic service size change information 1017 includes: PDU set dummy flags, interdependent PDU set flags, the PDU set sequence number of the large PDU set, and the PDU set size of the large PDU set.

[0167] In the UL direction, the gNB schedules the UE based on the UE scheduling request and the associated UE information. Therefore, even though the strategies and routines detailed above apply similarly, their functionality is split between the UE and the gNB, and indications of dynamic service characteristic changes relative to the PDU set size need to be reported at a lower layer (e.g., the MAC layer). These indications of dynamic service characteristic changes are related to additional information elements added to the Buffered Status Report (BSR) and Delayed Status Report (DSR) procedures.

[0168] In the UL direction, the UE has similar functionality to the UPF and needs to determine dynamic service characteristic changes relative to the PDU set size. The UE configured by the network with a PDU set size threshold can use in-band user plane information from the application layer related to dynamic service characteristic changes (e.g., configured by the modem-specific configuration interface used to configure the application logic of the UE, or alternatively, by means of NAS signaling, e.g., SM container metadata information via the N1 reference point and the UE's 3GPP network configuration).

[0169] A UE configured for dynamic service characteristic changes can detect service data streams marked by an RTP sender (e.g., a UE application) based on its configuration. These service data streams exhibit dynamic service characteristic changes relative to the PDU set size. This configuration can be configured by a modem-specific configuration interface used by the application logic to configure the UE, or alternatively, by means of NAS signaling (e.g., SM container metadata information via an N1 reference point and the UE's 3GPP network configuration). The UE processes metadata information available at the RTP header extension level to determine any dynamic service characteristic changes, such as an upcoming PDU set size exceeding a PDU set size threshold configured by the 3GPP network. As detailed above, the metadata information may include at least one of the following information elements:

[0170] • Flag or equivalent identifier field, which indicates that the indicated PDU set carries information about changes in the dynamic PDU set;

[0171] • Flag field, which indicates whether the PDU set is a dummy PDU set or a split PDU set;

[0172] • Timing field, which indicates the time interval between the indicated set of PDUs and the upcoming large (e.g., the next) set of PDUs;

[0173] • Flag field, which indicates that the next PDU set is a large PDU set that exceeds the PDU set size threshold;

[0174] • PDU set size field, which indicates the PDU set size of the upcoming (e.g., the next large PDU set on the line);

[0175] • Identifier field, which indicates the PDU set sequence number of the upcoming large PDU set; and

[0176] • PDU set size field, which indicates the PDU set size of the upcoming PDU set.

[0177] After the first PDU set is available in the UE's transmission buffer and a PDCP timer has been started for the PDUs / SDUs of the first PDU set, the UE can request scheduling opportunities from the gNB for both the first PDU set carrying an indication of dynamic service characteristic changes relative to the PDU set size and the second largest PDU set exceeding a configured PDU set size threshold. The scheduling request will include the conventional BSR and DSR procedures for the first PDU set, and additionally include a delayed BSR for the second PDU set (e.g., based on a DSR containing future time reference information elements). In the case of a delayed BSR, the UE can use the upcoming large PDU set size information and timing information of the time delay between the transmission intervals of the first and second PDU sets, which is dynamically provided by the RTP sender or semi-statically configured by the UE using or alternatively by the 3GPP network (e.g., via NAS signaling).

[0178] In one instance, the UE triggers a BSR (Browser Response) upon the arrival of information about the first PDU / SDU of the second PDU set or the upcoming second large PDU set, to notify the gNB of the additional UL resources required for the large PDU set. According to this embodiment, a new BSR triggering condition is introduced. According to one implementation, the BSR reports the expected buffer size of the second PDU set, for example, based on PDU set size information provided by a higher layer, rather than the amount of data available for transmission in the UE buffer. Where the UE processes two PDU sets corresponding to the same ADU (where the first PDU set is the first part of the ADU (e.g., at least one PDU) and the second PDU set is the remaining part of the ADU), and the first PDU set indicates the second large PDU set, the UE follows discard logic, which may include 'conservative processing' or 'greedy processing'.

[0179] In conservative processing, the UE typically uses a common PSDB to process interdependent PDU sets (belonging to the same ADU). If the first PDU set exceeds the common PSDB or cannot be served by the RAN under the common PSDB guarantee, the second PDU set is automatically discarded by the UE in the UL, given that the second PDU set references the first PDU set. This reference is determined based on the GTP-U header indication of the first PDU set, thus identifying it as the split first PDU set. In one instance—as specified in the current specification—the UE starts a PDCP discard timer for each SDU / PDU in the PDU set. If pdu-SetDiscard is configured for the PDCP entity / bearer / LCH (e.g., PDU set integrated disposal is configured for QoS flows / bearers), then when the PDCP discard timer expires, the UE discards all PDCP SDUs belonging to the PDU set to which the PDCP SDU belongs, along with their corresponding PDCP data PDUs, and all PDCP SDUs belonging to interdependent PDU sets, along with their corresponding PDCP data PDUs.

[0180] In greedy processing, the UE processes PDU sets (belonging to the same ADU) independently via two separate PSDBs based on QoS flow configuration. Once the first PDU set arrives at the UE's transport buffer, the UE starts the corresponding PDCP discard timer associated with the PDUs in the first PDU set and transmits the first PDU set over the air interface, given the available scheduling clearance received from the RAN. When PDUs from the second PDU set are received in the transport buffer, the UE starts the associated PDCP discard timer accordingly. Additionally, the UE resets the PDCP discard timer associated with the first PDU set and restarts it when the first PDU of the second PDU set arrives—at least if the transmission of the first PDU set is not yet complete. Then, the UE transmits the second PDU set over the air based on pre-allocated radio resources scheduled by the gNB according to an early request for scheduling of the large PDU set.

[0181] If either the first or second PDU set cannot fulfill its PSDB (e.g., due to exceeding its PSDB or due to air interface congestion preventing scheduling within the PSDB), the UE will discard the remaining bytes of the two PDU sets to be transmitted, since the two PDU sets are related and belong to the same ADU. The corresponding UE behavior will be the same as the conservative handling method.

[0182] Figure 11An example of a UE 1100 according to aspects of this disclosure is described. UE 1100 may include a processor 1102, a memory 1104, a controller 1106, and a transceiver 1108. The processor 1102, memory 1104, controller 1106, or transceiver 1108, or various combinations thereof, or various components thereof, may be examples of components for performing the aspects of this disclosure as described herein. These components may be coupled via one or more interfaces (e.g., operational ground, communication ground, functional ground, electronic ground, electrical ground).

[0183] Processor 1102, memory 1104, controller 1106, or transceiver 1108, or various combinations or components thereof, may be implemented in hardware (e.g., a circuit system). The hardware may include processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), or other programmable logic devices, or any combination thereof, configured to or otherwise support elements for performing the functions described in this disclosure.

[0184] Processor 1102 may include intelligent hardware devices (e.g., a general-purpose processor, DSP, CPU, ASIC, FPGA, or any combination thereof). In some embodiments, processor 1102 may be configured to operate memory 1104. In some other embodiments, memory 1104 may be integrated into processor 1102. Processor 1102 may be configured to execute computer-readable instructions stored in memory 1104 to cause UE 1100 to perform various functions of this disclosure.

[0185] Memory 1104 may comprise volatile or non-volatile memory. Memory 1104 may store computer-readable, computer-executable code containing instructions that, when executed by processor 1102, cause UE 1100 to perform various functions as described herein. The code may be stored in a non-transitory computer-readable medium, such as memory 1104 or another type of memory. Computer-readable media includes both non-transitory computer storage media and communication media, wherein the communication media includes any medium that facilitates the transfer of computer programs from one place to another. Non-transitory storage media may be any available medium accessible by a general-purpose or special-purpose computer.

[0186] In some implementations, processor 1102 and memory 1104 coupled to processor 1102 may be configured to cause UE 1100 to perform one or more of the functions described herein (e.g., instructions stored in memory 1104 are executed by processor 1102). For example, processor 1102 may support wireless communication at UE 1100 according to examples disclosed herein.

[0187] Controller 1106 manages the input and output signals of UE 1100. Controller 1106 can also manage peripheral devices not integrated into UE 1100. In some embodiments, controller 1106 may utilize an operating system, such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some embodiments, controller 1106 may be implemented as part of processor 1102.

[0188] In some embodiments, UE 1100 may include at least one transceiver 1108. In other embodiments, UE 1100 may have more than one transceiver 1108. Transceiver 1108 may represent a wireless transceiver. Transceiver 1108 may include one or more receiver chains 1110, one or more transmitter chains 1112, or a combination thereof.

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

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

[0191] Figure 12An example of processor 1200 according to aspects of this disclosure is described. Processor 1200 may be an example of a processor configured to perform various operations according to the examples described herein. Processor 1200 may include a controller 1202 configured to perform various operations according to the examples described herein. Processor 1200 may optionally include at least one memory 1204, which may be, for example, an L1 / L2 / L3 cache. Additionally or alternatively, processor 1200 may optionally include one or more arithmetic logic units (ALUs) 1206. One or more of these components may be electronically communicated or otherwise coupled (e.g., operative ground, communicative ground, functional ground, electronic ground, electrical ground) via one or more interfaces (e.g., buses).

[0192] Processor 1200 may be a processor chipset and includes a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) according to the examples described herein. The processor chipset may include one or more cores, one or more caches (e.g., memory local to the processor chipset (e.g., processor 1200) or contained within the processor chipset (e.g., processor 1200) or other memory (e.g., random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), static RAM (SRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase-change memory (PCM), etc.)).

[0193] Controller 1202 can be configured to manage and coordinate various operations of processor 1200 (e.g., signaling, receiving, acquiring, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, and reading) to enable processor 1200 to support various operations according to examples described herein. For example, controller 1202 can operate as a control unit of processor 1200, thereby generating control signals that manage the operation of various components of processor 1200. These control signals include enabling or disabling functional units, selecting data paths, initiating memory accesses, and coordinating operation timing.

[0194] Controller 1202 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from memory 1204 and determine subsequent instructions to be executed to enable processor 1200 to support various operations according to the examples described herein. Controller 1202 may be configured to track the memory addresses of instructions associated with memory 1204. Controller 1202 may be configured to decode instructions to determine the operations to be performed and the operands involved. For example, controller 1202 may be configured to interpret instructions and determine control signals to be output to other components of processor 1200 to enable processor 1200 to support various operations according to the examples described herein. Alternatively or additionally, controller 1202 may be configured to manage data flow within processor 1200. Controller 1202 may be configured to control data transfers between registers, arithmetic logic unit (ALU), and other functional units of processor 1200.

[0195] Memory 1204 may include one or more caches (e.g., memory local to processor 1200 or included in processor 1200) or other memories, such as RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc. In some embodiments, memory 1204 may reside within or on the processor chipset (e.g., locally to processor 1200). In some other embodiments, memory 1204 may reside outside the processor chipset (e.g., remotely from processor 1200).

[0196] Memory 1204 may store computer-readable, computer-executable code containing instructions that, when executed by processor 1200, cause processor 1200 to perform the various functions described herein. The code may be stored in a non-transitory computer-readable medium, such as system memory or another type of memory. Controller 1202 and / or processor 1200 may be configured to execute the computer-readable instructions stored in memory 1204 to cause processor 1200 to perform various functions. For example, processor 1200 and / or controller 1202 may be coupled to or coupled to memory 1204, and processor 1200, controller 1202, and memory 1204 may be configured to perform the various functions described herein. In some instances, processor 1200 may include multiple processors and memory 1204 may include multiple memories. One or more of the multiple processors may be coupled to one or more of the multiple memories, which may be individually or collectively configured to perform the various functions described herein.

[0197] One or more ALUs 1206 may be configured to support various operations according to the examples described herein. In some embodiments, one or more ALUs 1206 may reside within or on a processor chipset (e.g., processor 1200). In some other embodiments, one or more ALUs 1206 may reside outside the processor chipset (e.g., processor 1200). One or more ALUs 1206 may perform one or more calculations on data, such as addition, subtraction, multiplication, and division. For example, one or more ALUs 1206 may receive input operands and an opcode to determine the operation to be performed. One or more ALUs 1206 may be configured with various logic and arithmetic circuitry, including adders, subtractors, shifters, and logic gates, to process and manipulate data according to the operation. Alternatively, one or more ALU 1206 may support logical operations such as AND, OR, XOR, NOR, and NAND, thereby enabling one or more ALU 1206 to handle conditional operations, comparisons, and bitwise operations.

[0198] Processor 1200 can support wireless communication according to examples disclosed herein.

[0199] Figure 13 An example of NE 1300 according to aspects of this disclosure is described. NE 1300 may include a processor 1302, a memory 1304, a controller 1306, and a transceiver 1308. The processor 1302, memory 1304, controller 1306, or transceiver 1308, or various combinations thereof, or various components thereof, may be examples of components for performing the aspects of this disclosure as described herein. These components may be coupled via one or more interfaces (e.g., operational ground, communication ground, functional ground, electronic ground, electrical ground).

[0200] Processor 1302, memory 1304, controller 1306, or transceiver 1308, or various combinations or components thereof, may be implemented in hardware (e.g., a circuit system). The hardware may include processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), or other programmable logic devices, or any combination thereof, configured to or otherwise support elements for performing the functions described in this disclosure.

[0201] Processor 1302 may include intelligent hardware devices (e.g., a general-purpose processor, DSP, CPU, ASIC, FPGA, or any combination thereof). In some embodiments, processor 1302 may be configured to operate memory 1304. In some other embodiments, memory 1304 may be integrated into processor 1302. Processor 1302 may be configured to execute computer-readable instructions stored in memory 1304 to cause NE 1300 to perform various functions of this disclosure.

[0202] Memory 1304 may comprise volatile or non-volatile memory. Memory 1304 may store computer-readable, computer-executable code containing instructions that, when executed by processor 1302, cause NE 1300 to perform the various functions described herein. The code may be stored in a non-transitory computer-readable medium, such as memory 1304 or another type of memory. Computer-readable media includes both non-transitory computer storage media and communication media, wherein the communication media includes any medium that facilitates the transfer of computer programs from one place to another. Non-transitory storage media may be any available medium accessible by a general-purpose or special-purpose computer.

[0203] In some implementations, processor 1302 and memory 1304 coupled to processor 1302 may be configured to cause NE 1300 to perform one or more of the functions described herein (e.g., processor 1302 executing instructions stored in memory 1304). For example, processor 1302 may support wireless communication at NE 1300 according to examples disclosed herein.

[0204] The NE 1300 can be configured to support components for: receiving packet detection rules from a second network function, the packet detection rules including configuration rules indicating that a check of the Protocol Data Unit (PDU) sets of packets matching the rules be initiated and identifying PDU set size changes between received PDU sets; receiving a series of IP packets from an application server matching the first packet detection rule; determining the PDUs of the PDU sets and identifying PDU set size changes between the first PDU set and the second PDU set; and routing the series of packets to a base station via N3, the series of routed packets containing PDU set information including an indication that the PDU set size will change with the second PDU set.

[0205] The NE 1300 may alternatively be configured to support components for: receiving a first request from a second network function to process a set of PDUs for a QoS flow; determining a first scheduling resource to transmit the PDUs of the QoS flow to a user equipment (UE) based on the first request; receiving a first set of PDUs from the first network function as a series of IP packets for the QoS flow via an N3 interface, the first set of PDUs containing an indication of an upcoming second set of PDUs having a second set size different from the first set size; determining a second scheduling resource to accommodate the size of the second set of PDUs; receiving the second set of PDUs from the first network function; and transmitting the second set of PDUs to the UE based on the second scheduling resource.

[0206] Controller 1306 manages the input and output signals of NE 1300. Controller 1306 can also manage peripheral devices not integrated into NE 1300. In some embodiments, controller 1306 may utilize an operating system such as iOS®, Android®, Windows®, or other operating systems. In some embodiments, controller 1306 may be implemented as part of processor 1302.

[0207] In some embodiments, the NE 1300 may include at least one transceiver 1308. In other embodiments, the NE 1300 may have more than one transceiver 1308. The transceiver 1308 may represent a wireless transceiver. The transceiver 1308 may include one or more receiver chains 1310, one or more transmitter chains 1312, or a combination thereof.

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

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

[0210] Figure 14 A flowchart illustrating a method according to an aspect of this disclosure is provided. The operation of the method may be implemented by a first network function as described herein. In some embodiments, the first network function may execute a set of instructions to control functional elements of the first network function to perform the described functions.

[0211] At 1402, the method may include receiving a set of rules from a second network function for inspecting Protocol Data Unit (PDU) sets and identifying changes in PDU set size between at least two PDU sets. The operation of 1402 may be performed according to the examples described herein. In some embodiments, aspects of the operation of 1402 may be provided by reference to [reference needed]. Figure 13 The first network function described is executed.

[0212] At 1404, the method may include receiving a set of packets satisfying at least one of the set of rules, the set of packets comprising a plurality of PDU sets. The operation of 1404 may be performed according to the examples described herein. In some embodiments, aspects of the operation of 1404 may be as described in references... Figure 13 The first network function described is executed.

[0213] At 1406, the method may include identifying a change in PDU set size between a first PDU set and a second PDU set within the plurality of PDU sets. The operation of 1406 may be performed according to the examples described herein. In some embodiments, aspects of the operation of 1406 may be as described in references... Figure 13 The first network function described is executed.

[0214] At 1408, the method may include routing the set of packets to a base station via a network interface, wherein the set of packets contains PDU set information, the PDU set information including an indication that the PDU set size will vary with a second PDU set. Operation of 1408 may be performed according to the examples described herein. In some embodiments, aspects of operation of 1408 may be as described in references... Figure 13 The first network function described is executed.

[0215] It should be noted that the methods described herein describe possible implementations, and the operations and steps may be rearranged or otherwise modified, and other implementations are also possible.

[0216] Figure 15 A flowchart illustrating a method according to an aspect of this disclosure is provided. The operation of the method can be implemented by a base station as described herein. In some embodiments, the base station can execute a set of instructions to control the functional elements of the base station to perform the described functions.

[0217] At 1502, the method may include receiving a first request from a second network function for the processing of a set of PDUs for a QoS flow. The operation of 1502 may be performed according to the examples described herein. In some embodiments, aspects of the operation of 1502 may be as described in references... Figure 13 The described base station performs the following.

[0218] At 1504, the method may include determining a first scheduling resource to send the PDU of the QoS flow to the User Equipment (UE) according to the first requirement. The operation of 1504 may be performed according to the examples described herein. In some embodiments, aspects of the operation of 1504 may be as described in references... Figure 13 The described base station performs the following.

[0219] At 1506, the method may include receiving a first PDU set from a first network function as a series of IP packets for the QoS flow via a network interface, the first PDU set containing an indication of an upcoming second PDU set having a second PDU set size different from the first PDU set size. Operation of 1506 may be performed according to the examples described herein. In some embodiments, aspects of operation of 1506 may be as described in references... Figure 13 The described base station performs the following.

[0220] At 1508, the method may include determining a second scheduling resource to accommodate the size of the second PDU set; and receiving the second PDU set from the first network function. The operation of 1508 may be performed according to the examples described herein. In some embodiments, aspects of the operation of 1508 may be as described in references... Figure 13 The described base station performs the following.

[0221] At 1510, the method may include receiving the second PDU set from the first network function. The operation of 1510 may be performed according to the examples described herein. In some embodiments, aspects of the operation of 1510 may be described by reference to... Figure 13 The described base station is used to perform this.

[0222] At 1512, the method may include transmitting the second PDU set to the UE according to the second scheduling resource. The operation of 1512 may be performed according to the examples described herein. In some embodiments, aspects of the operation of 1512 may be as described in references... Figure 13 The described base station performs the following.

[0223] It should be noted that the methods described herein describe possible implementations, and the operations and steps may be rearranged or otherwise modified, and other implementations are also possible.

[0224] This description is provided to enable those skilled in the art to make or use this disclosure. Various modifications to this disclosure will be apparent to those skilled in the art, and the general principles defined herein can be applied to other variations without departing from the scope of this disclosure. Therefore, this disclosure is not limited to the examples and designs described herein, but should be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0225] Therefore, a first network function for wireless communication is provided, comprising: at least one memory; and at least one processor coupled to and arranged with the at least one memory such that the first network function: receives from a second network function a set of rules for examining a set of Protocol Data Units (PDUs) and identifying a change in PDU set size between at least two PDU sets; receives a set of packets satisfying at least one of the rules in the set of rules, the set of packets comprising a plurality of PDU sets; identifies a change in PDU set size between a first PDU set and a second PDU set in the plurality of PDU sets; and routes the set of packets to a base station via a network interface, wherein the set of packets contains PDU set information, the PDU set information including an indication that the PDU set size will change with the second PDU set.

[0226] This first network function allows the base station to be aware of dynamic changes in service characteristics by notifying it of increases in the size of consecutive PDU sets. The base station can then adjust its resource allocation based on this notification and ensure that the PDU set is carried in accordance with any requirements for PDU set handling.

[0227] The first network function may additionally add PDU set information to the routed packets. This PDU set information includes an indication that the PDU set size will change with the second PDU set. The first and second PDU sets may be consecutive sets. The indication that the PDU set size will change with the second PDU set may include an indication that the second PDU set is imminent and its size will change.

[0228] The first network function can be the first network entity. The first network function can be a UPF. The second network function can be the second network entity. The second network function can be an SMF. The base station can be a gNB.

[0229] A set of packets satisfying at least one of the rules in the set can be received from an application server that matches a first packet detection rule. The set of packets can be routed to a network interface of the base station, which may include an N3 interface.

[0230] The configuration rules may include a threshold value for the size of the PDU set.

[0231] The at least one processor coupled to the at least one memory may be further arranged such that the first network function determines whether the size of the PDU set associated with each of the plurality of PDU sets exceeds the threshold size value.

[0232] The at least one processor coupled to the at least one memory may be further arranged such that the first network function enables a flag indicating that the size of the second PDU set exceeds the threshold size in the first PDU set, based at least in part on the determination that the size of the second PDU set exceeds the threshold size.

[0233] The at least one processor coupled to the at least one memory may be further arranged such that the first network function adds dummy packets containing PDU set information indicating that the size of the PDU set associated with the second PDU set exceeds the threshold size value, wherein the dummy packets are included in the first PDU set before the second PDU set is transmitted.

[0234] The at least one processor coupled to the at least one memory may be further arranged such that the first network function adds the second PDU set size to the packet carrying the first PDU set if the second PDU set size is higher than the threshold size value.

[0235] The at least one processor coupled to the at least one memory may be further arranged such that the first network function includes a dummy packet containing PDU set information, which includes the size of the next PDU set, before transmitting the second PDU set if the second PDU set size is higher than the threshold size value.

[0236] The at least one processor coupled to the at least one memory may be further arranged to enable the first network function to: determine the PDU set size of the second PDU set; and provide an indication to add the second PDU set size to the first PDU set.

[0237] A method performed by a first network function is further provided, the method comprising: receiving from a second network function a set of rules for inspecting a set of Protocol Data Units (PDUs) and identifying a change in the size of a PDU set between at least two PDU sets; receiving a set of packets satisfying at least one of the rules in the set of rules, the set of packets comprising a plurality of PDU sets; identifying a change in the size of a PDU set between a first PDU set and a second PDU set in the plurality of PDU sets; and routing the set of packets to a base station via a network interface, wherein the set of packets contains PDU set information, the PDU set information including an indication that the size of the PDU set will change with the second PDU set.

[0238] This method allows the base station to be aware of dynamic changes in service characteristics by notifying it of an increase in the size of the PDU set between consecutive received PDU sets. The base station can then adjust its scheduling resources based on this notification and ensure that the PDU set is carried in accordance with any requirements for PDU set handling.

[0239] The method may include adding PDU set information to the routed packets, the PDU set information including an indication that the PDU set size will change with a second PDU set. The first PDU set and the second PDU set may be contiguous sets. The first network function may be a UPF. The second network function may be an SMF. The base station may be a gNB.

[0240] The configuration rules may include a threshold value for the size of the PDU set.

[0241] The method may further include determining whether the size of the PDU set associated with each of the plurality of PDU sets exceeds the threshold size value.

[0242] The method may further include, at least in part, enabling a flag indicating that the size of the second PDU set exceeds the threshold size in the first PDU set, based on the determination that the size of the second PDU set exceeds the threshold size.

[0243] The method may further include adding a dummy packet containing PDU set information, the PDU set information indicating that the size of the PDU set associated with the second PDU set exceeds the threshold size value, wherein the dummy packet is included in the first PDU set before the second PDU set is transmitted.

[0244] The method may further include adding the size of the second PDU set to the group carrying the first PDU set if the size of the second PDU set is greater than the threshold size value.

[0245] The method may further include, if the size of the second PDU set is greater than the threshold size value, including a dummy packet before sending the second PDU set, the dummy packet containing PDU set information, the PDU set information including the size of the next PDU set.

[0246] The method may further include determining the PDU set size of the second PDU set and adding an indication of the second PDU set size to the first PDU set.

[0247] A base station for wireless communication is further provided, comprising: at least one memory; and at least one processor coupled to and arranged such that the base station: receives from a second network function a first request for processing a set of PDUs for a QoS flow; determines a first scheduling resource to transmit the PDUs of the QoS flow to a user equipment (UE) according to the first request; receives from the first network function a first set of PDUs as a series of IP packets for the QoS flow via a network interface, the first set of PDUs including an indication of an upcoming second set of PDUs having a size different from that of the first set of PDUs; determines a second scheduling resource to accommodate the size of the second set of PDUs; receives the second set of PDUs from the first network function; and transmits the second set of PDUs to the UE according to the second scheduling resource.

[0248] This base station allows the gNB to be aware of dynamic changes in service characteristics by notifying the increase in the PDU set size between consecutive received PDU sets. Based on this notification, the gNB can adjust scheduling resources and ensure that PDU sets are sent to the UE according to the QoS requirements of the PDU set for the QoS flow, regardless of the size of the PDU set.

[0249] The second scheduling resource may include the adaptation of the first scheduling resource. The first network function may be UPF. The second network function may be SMF.

[0250] QoS flows can include service data flows. A 'QoS flow' is a 5GS concept that maps data flows to services (i.e., service data flows) to ensure a certain quality of service across the 5GS based on an application's request to the network. Typically, an application or service outputs a service data flow to the 5GS. When this enters the 5GS, it is mapped to a QoS flow based on the application / service request for QoS. Multiple service data flows can be mapped to a single QoS flow. Furthermore, a single service data flow can be mapped to multiple QoS flows. The first requirement may include QoS requirements for PDU set latency budget and maximum data burst size. The first requirement may include one or more ranges of PDU set size thresholds.

[0251] The base station may be further configured to receive an indication of a change in PDU set size when the size of an upcoming PDU set exceeds a PDU set size threshold.

[0252] The PDU set size threshold can be equal to the maximum data burst size (MDBV). The base station may not need to receive any PDU set size threshold information. Indicators included in the first PDU set may include indications that the size of the upcoming PDU set is higher than the MDBV. The PDU set size threshold can be set as the average PDU set size reported by the application function (AF).

[0253] A method performed by a base station is further provided, the method comprising: receiving a first request from a second network function to process a set of PDUs for a QoS flow; determining a first scheduling resource according to the first request to transmit the PDUs of the QoS flow to a user equipment (UE); receiving a first set of PDUs from the first network function as a series of IP packets for the QoS flow via a network interface, the first set of PDUs including an indication of an upcoming second set of PDUs having a size different from that of the first set of PDUs; determining a second scheduling resource to accommodate the size of the second set of PDUs; receiving the second set of PDUs from the first network function; and transmitting the second set of PDUs to the UE according to the second scheduling resource.

[0254] This method allows the gNB to be aware of dynamic changes in service characteristics by notifying the increase in the PDU set size between consecutive received PDU sets. Based on this notification, the gNB can adjust scheduling resources and ensure that PDU sets are sent to the UE according to the QoS requirements of the PDU sets in the QoS flow, regardless of the size of the PDU sets.

[0255] The second scheduling resource may include the adaptation of the first scheduling resource. The first network function may be UPF. The second network function may be SMF.

[0256] QoS flows can include service data flows. A 'QoS flow' is a 5GS concept that maps data flows to services (i.e., service data flows) to ensure a certain quality of service across 5GS based on an application's request to the network. Typically, an application or service will output a service data flow to 5GS. When this enters 5GS, it is mapped to a QoS flow based on the application / service request for QoS. In future versions, service data flows may be mapped to multiple QoS flows.

[0257] The first requirement may include QoS requirements for PDU set latency budget and maximum data burst size. The first requirement may include one or more ranges of PDU set size thresholds.

[0258] The method may further include receiving an indication of a PDU set size change when the PDU set size of an upcoming PDU set is greater than a PDU set size threshold. The PDU set size threshold may be equal to the maximum data burst size (MDBV).

[0259] The base station may not need to receive any PDU set size threshold information. Indicators included in the first PDU set may include indications that the size of the upcoming PDU set is higher than the MDBV. The PDU set size threshold can be set as the average PDU set size reported by the application function AF.

[0260] One of the key issues currently under research by 3GPP is supporting use cases where the business characteristics of XR services can change dynamically.

[0261] For example, in situations where the size of a media segment can dynamically change as a user moves the progress bar of a streaming video, more bandwidth is needed to buffer a set of initial video frames to allow the streaming application to buffer enough data to support smooth video playback. In another instance, the data burst side in an XR service can dynamically change during changes in the video scene. In this case, the encoder creates new video I-frames where the packet size is significantly larger than the previous packet size.

[0262] Since the PDU set size of a new I-frame will be much larger than that of the previous frame (P-frame), such scenarios can introduce complexity to the RAN scheduler. To ensure the transmission of such large data bursts within the PSDB of the QoS stream, QoS parameters (such as GFBR or MDBV) need to be set based on the potential maximum burst value in the current QoS mechanism. This results in wasted network resources and lower user capacity.

[0263] The solution proposed in this paper includes allowing the gNB to be aware of dynamic changes in service characteristics by notifying the gNB of an increase in the size of the received PDU sets. Based on this notification, the gNB can adjust the scheduler and ensure that PDU sets are sent to the UE according to the QoS requirements of the PDU sets in the QoS flow.

[0264] The XR service described in this article will provide the gNB with awareness of changes in business characteristics; this awareness is provided via the user plane.

[0265] Therefore, the UPF can identify dynamic changes in the service characteristics of XR services based on the UPF implementation. Once identified, the dynamic changes are signaled to the gNB in ​​the DL direction via GTP-U header metadata information to provide awareness of dynamic changes in service characteristics relative to the size of the continuous PDU set.

[0266] In a further example, the RTP sender (i.e., the application in the AS or UE) may synchronize the PDU set at the source based on a maximum PDU set size threshold, or alternatively, may use metadata information about dynamic service characteristic changes relative to the PDU set size exceeding the configured PDU set size threshold to mark the PDU set. When a dynamic service characteristic change is marked, the metadata information is provided to mark a portion of the PDU set with an RTP header extension or a portion of a separate in-band RTP header extension on the user plane. This can be used in both the DL (e.g., by the UPF and then by the gNB via GTP-U header information as determined by Embodiment 1) and the UL (e.g., by the UE according to Embodiment 3) to assist the gNB scheduler in allocating radio resources to large PDU sets exceeding the configured PDU set size threshold.

[0267] In a further example, the behavior of the gNB / UE relative to the signaled dynamic service changes may include considering an upcoming large PDU set and pre-allocating / requesting radio resources from / from the gNB scheduler. In the UE's case, the UE can use the provided in-band user plane indication to detect dynamic service size characteristic changes. When a large PDU set is detected, radio resources can be requested in advance to satisfy the PSDB of the large PDU set, even if these PDU sets exceed the configured PDU set size threshold. Additionally, when two interdependent PDU sets are used to signal dynamic changes in service size characteristics—that is, when the first PDU set indicates a second large PDU set and the two PDU sets logically represent the same ADU—the dropping of the PDU set can be enhanced.

[0268] Therefore, this document discloses a method performed by a UPF, the method comprising: receiving a packet detection rule from an SMF, the packet detection rule including a configuration rule instructing the initiation of a PDU set check of packets matching the rule and identifying PDU set size changes between received PDU sets; receiving a series of IP packets from an application server matching a first packet detection rule; determining the PDUs of the PDU sets and determining PDU set size changes between PDU sets; and routing the series of packets to a gNB via an N3, thereby including an indication that an upcoming PDU set size change has occurred within the PDU set information.

[0269] Method configuration rules can include a threshold for the PDU set size.

[0270] The method may further include identifying the PDUs in the PDU set and determining whether the size of the PDU set exceeds a threshold. If the size of the PDU set is higher than the threshold, then the UPF adds a flag indicating that the size of the next PDU set will exceed the threshold to the previously received PDU set.

[0271] The method may further include identifying PDUs in the PDU set and determining whether the size of the PDU set exceeds a threshold. If the size of the PDU set is higher than the threshold, then the UPF includes a dummy packet before sending the PDU set whose size is higher than the threshold. The dummy packet contains information notifying the next PDU set whose size is higher than the threshold.

[0272] The method may further include identifying the PDUs in the PDU set and determining whether the size of the PDU set exceeds a threshold. If the size of the PDU set is higher than the threshold, then the UPF adds the size of this PDU set to the previously received PDU set.

[0273] The method may further include identifying the PDUs in the PDU set and determining whether the size of the PDU set exceeds a threshold. If the size of the PDU set is higher than the threshold, then the UPF contains a dummy packet containing PDU set information, which includes the size of the next PDU set, before sending PDU sets whose size exceeds the threshold.

[0274] The method may further include determining the PDU set size and adding this PDU set size to the previously received PDU set.

Claims

1. A first network function for wireless communication, comprising: At least one memory; and At least one processor, coupled to and arranged to enable the first network function: Receive a set of rules from the second network function for inspecting Protocol Data Unit (PDU) sets and identifying changes in PDU set size between at least two PDU sets; Receive a set of packets that satisfy at least one of the set of rules, the set of packets containing multiple PDU sets; Identify the change in PDU set size between the first PDU set and the second PDU set in the plurality of PDU sets; and The group of packets is routed to the base station via a network interface, wherein the group of packets contains PDU set information, and the PDU set information includes an indication that the size of the PDU set will vary with the second PDU set.

2. The first network function of claim 1, wherein the set of rules includes a configuration of a threshold size value indicating the size of the PDU set.

3. The first network function of claim 2, wherein the at least one processor coupled to the at least one memory is further arranged to enable the first network function to: Determine whether the size of the PDU set associated with each of the plurality of PDU sets exceeds the threshold size value.

4. The first network function according to any one of claims 1 to 3, wherein the at least one processor coupled to the at least one memory is further arranged to enable the first network function to: Based at least in part on the determination that the size of the second PDU set exceeds the threshold size value, a flag indicating that the size of the second PDU set exceeds the threshold size is enabled in the first PDU set.

5. The first network function according to any one of claims 1 to 4, wherein the at least one processor coupled to the at least one memory is further arranged to enable the first network function to: Add a dummy packet containing PDU set information, the PDU set information indicating that the size of the PDU set associated with the second PDU set exceeds the threshold size value, wherein the dummy packet was included in the first PDU set before the second PDU set was transmitted.

6. The first network function according to any one of claims 1 to 5, wherein the at least one processor coupled to the at least one memory is further arranged to enable the first network function to: If the size of the second PDU set is higher than the threshold size, the size of the second PDU set is added to the group carrying the first PDU set.

7. The first network function according to any one of claims 1 to 6, wherein the at least one processor coupled to the at least one memory is further arranged to enable the first network function to: If the size of the second PDU set is higher than the threshold size, a dummy packet is included before sending the second PDU set. The dummy packet contains PDU set information including the size of the next PDU set.

8. The first network function according to any one of claims 1 to 7, wherein the at least one processor coupled to the at least one memory is further arranged to enable the first network function to: Determine the size of the second PDU set; and Add an indication of the size of the second PDU set to the first PDU set.

9. A method performed by a first network function, the method comprising: Receive a set of rules from the second network function for inspecting Protocol Data Unit (PDU) sets and identifying changes in PDU set size between at least two PDU sets; Receive a set of packets that satisfy at least one of the set of rules, the set of packets containing multiple PDU sets; Identify the change in PDU set size between the first PDU set and the second PDU set in the plurality of PDU sets; and The group of packets is routed to the base station via a network interface, wherein the group of packets contains PDU set information, and the PDU set information includes an indication that the size of the PDU set will vary with the second PDU set.

10. The method of claim 9, wherein the configuration rule includes a threshold size value for the PDU set size.

11. The method according to claim 9 or 10, further comprising: Determine whether the size of the PDU set associated with each of the plurality of PDU sets exceeds the threshold size value.

12. The method according to any one of claims 9 to 11, further comprising: Based at least in part on the determination that the size of the second PDU set exceeds the threshold size value, a flag indicating that the size of the second PDU set exceeds the threshold size is enabled in the first PDU set.

13. The method according to any one of claims 9 to 12, further comprising: Add a dummy packet containing PDU set information, the PDU set information indicating that the size of the PDU set associated with the second PDU set exceeds the threshold size value, wherein the dummy packet was included in the first PDU set before the second PDU set was transmitted.

14. A base station for wireless communication, comprising: At least one memory; and At least one processor, coupled to and arranged to enable the base station to: Receive the first request for processing the PDU set of QoS flow from the second network function; Based on the first requirement, a first scheduling resource is determined to send the PDU of the QoS stream to the user equipment (UE); A first PDU set is received from a first network function as a series of IP packets for the QoS flow via a network interface, the first PDU set containing an indication of an upcoming second PDU set having a size different from that of the first PDU set; Determine a second scheduling resource to accommodate the size of the second PDU set; Receive the second PDU set from the first network function; and The second PDU set is transmitted to the UE according to the second scheduling resource.

15. The base station of claim 14, wherein the first requirement includes QoS requirements for PDU set delay budget and maximum data burst size.

16. The base station according to claim 14 or 15, wherein the first requirement comprises one or more ranges of PDU set size thresholds.

17. The base station according to any one of claims 14 to 16, further configured to receive an indication of a change in PDU set size when the PDU set size of an upcoming PDU set is greater than a PDU set size threshold.

18. The base station according to any one of claims 14 to 17, wherein the PDU set size threshold is equal to the maximum data burst size (MDBV).

19. The base station according to any one of claims 14 to 18, wherein the PDU set size threshold is set as the average PDU set size reported by the application function AF.

20. A method performed by a base station, the method comprising: Receive the first request for processing the PDU set of QoS flow from the second network function; Based on the first requirement, a first scheduling resource is determined to send the PDU of the QoS stream to the user equipment (UE); A first PDU set is received from a first network function as a series of IP packets for the QoS flow via a network interface, the first PDU set containing an indication of an upcoming second PDU set having a size different from that of the first PDU set; Determine a second scheduling resource to accommodate the size of the second PDU set; Receive the second PDU set from the first network function; and The second PDU set is transmitted to the UE according to the second scheduling resource.

Images