WO2024170239A1

WO2024170239A1 - Signalling awareness of dynamic traffic size changes in a wireless communication network

Info

Publication number: WO2024170239A1
Application number: PCT/EP2024/051656
Authority: WO
Inventors: Razvan-Andrei Stoica; Dimitrios Karampatsis; Joachim Löhr
Original assignee: Lenovo Singapore Pte Ltd
Current assignee: Lenovo Singapore Pte Ltd
Priority date: 2023-12-22
Filing date: 2024-01-24
Publication date: 2024-08-22
Anticipated expiration: 2026-06-22

Abstract

There is provided herein a Real-time Transport Protocol, RTP, sender for wireless communication, the RTP sender comprising: at least one memory; and at least one processor coupled with the at least one memory and arranged to cause the RTP sender to: receive a Protocol Data Unit, PDU, set size threshold value, the PDU Set size threshold value determining a PDU Set size traffic characteristic for a service data flow; apply the PDU Set size threshold value to PDU Sets of the service data flow, the applying comprising identifying a PDU Set size change between a first PDU Set and a second PDU Set of the PDU Sets of the service data flow, wherein the second PDU Set size satisfies the PDU Set size threshold value; and transmit the first PDU Set, the second PDU Set, and an indication of a dynamic PDU Set size change.

Description

SIGNALLING AWARENESS OF DYNAMIC TRAFFIC SIZE CHANGES IN A WIRELESS COMMUNICATION NETWORK

TECHNICAL FIELD

[0001] The subject matter disclosed herein relates generally to the field of implementing signalling awareness of dynamic traffic size changes in a wireless communication network. In particular, there is disclosed herein a Real-time Transport Protocol (RTP) sender, a method performed by an RTP sender, a base station, and a method performed by a base station.

BACKGROUND

[0002] A wireless communications system may include one or multiple network communication devices, such as base stations, which may support wireless communications for one or multiple user communication devices, which may be otherwise known as user equipment (UE), or other suitable terminology. The wireless communications system may support wireless communications with one or multiple user communication devices by utilizing resources of the wireless communication system (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers, or the like). Additionally, the wireless communications system may support wireless communications across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, among other suitable radio access technologies beyond 5G (e.g., sixth generation (6G)).

SUMMARY

[0003] An article “a” before an element is unrestricted and understood to refer to “at least one” of those elements or “one or more” of those elements. The terms “a,” “at least one,” “one or more,” and “at least one of one or more” may be interchangeable. As used herein, including in the claims, “or” as used in a list of items (e.g., a list of items prefaced by a phrase such as “at least one of’ or “one or more of’ or “one or both of’) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Also, as used herein, the phrase “based on” shall not be construed as a reference to a closed set of conditions. For example, an example step that is described as “based on condition A” may be based on both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be construed in the same manner as the phrase “based at least in part on. Further, as used herein, including in the claims, a “set” may include one or more elements.

[0004] There is provided herein a Real-time Transport Protocol, RTP, sender for wireless communication, the RTP sender comprising: at least one memory; and at least one processor coupled with the at least one memory and arranged to cause the RTP sender to: receive a Protocol Data Unit, PDU, set size threshold value, the PDU Set size threshold value determining a PDU Set size traffic characteristic for a service data flow; apply the PDU Set size threshold value to PDU Sets of the service data flow, the applying comprising identifying a PDU Set size change between a first PDU Set and a second PDU Set of the PDU Sets of the service data flow, wherein the second PDU Set size satisfies the PDU Set size threshold value; and transmit the first PDU Set, the second PDU Set, and an indication of a dynamic PDU Set size change.

[0005] There is further provided a method performed by an RTP sender, the method comprising: receiving a Protocol Data Unit, PDU, set size threshold value, the PDU Set size threshold value determining a PDU Set size traffic characteristic for a service data flow; applying the PDU Set size threshold value to PDU Sets of the service data flow, the applying comprising identifying a PDU Set size change between a first PDU Set and a second PDU Set of the PDU Sets of the service data flow, wherein the second PDU Set size satisfies the PDU Set size threshold value; and transmitting the first PDU Set, the second PDU Set, and an indication of a dynamic PDU Set size change.

[0006] There is provided herein a base station 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 base station to: receive, from a second network function, information that indicates a set of quality of service, QoS, requirements for handling protocol data unit, PDU, Sets for a QoS flow; determine a first set of resources, for transmission of the PDU Sets to a user equipment, UE, based at least in part on the set of QoS requirements; receive, from a first network function, a first PDU Set as a series of IP packets over a network interface for the QoS flow, the first PDU Set including an indication that an upcoming second PDU Set has a second PDU Set size, wherein the second PDU Set size is different to the first PDU Set size; determine a second set of resources, for transmission of the second PDU Set to the UE, based at least in part on the set of QoS requirements, wherein the second set of resources support the second PDU Set size; receive the second PDU Set from the first network function; and transmit the second PDU Set to the UE according in part to the second set of resources.

[0007] There is further provided herein a method performed by a base station, the method comprising: receiving, from a second network function, information that indicates a set of quality of service, QoS, requirements for handling protocol data unit, PDU, Sets for a QoS flow; determining a first set of resources, for transmission of the PDU Sets to a user equipment, UE, based at least in part on the set of received QoS requirements; receiving, from a first network function, a first PDU Set as a series of IP packets over a network interface for the QoS flow, the first PDU Set including an indication that an upcoming second PDU Set has a second PDU Set size, wherein the second PDU Set size is different to the first PDU Set size; determining a second set of resources, for transmission of the second PDU Set to the UE, based at least in part on the set of QoS requirements, wherein the second set of resources support the second PDU Set size; receiving the second PDU Set from the first network function; and transmitting the second PDU Set to the UE according in part to the second set of resources..

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 illustrates an example of a wireless communications system in accordance with aspects of the present disclosure.

[0009] Figure 2 illustrates an overview of a core network XRM architecture handling of PDU Sets.

[0010] Figure 3 illustrates a 1-byte RTP header extension for PDU Set marking by the AS. [0011] Figure 4 illustrates a 2-byte RTP header extension for PDU Set marking by the AS.

[0012] Figure 5 illustrates some options where two PDU Sets of different importance and characteristics are mapped to QoS flows and respectively to Data Radio Bearers (DRBs).

[0013] Figure 6 illustrates a UPF identifying dynamic changes in traffic characteristics of an XR service.

[0014] Figure 7 is a messaging diagram illustrating the operation of the system illustrated in Figure 6.

[0015] Figure 8 illustrates an RTP sender awareness and signalling of dynamic PDU Set size.

[0016] Figure 9 is a messaging diagram illustrating the operation of the system illustrated in Figure 8.

[0017] Figure 10 illustrates an example header information for the inter-dependent PDU Sets with dynamic traffic characteristic indication.

[0018] Figure 11 illustrates an example of a user equipment (UE) 1100 in accordance with aspects of the present disclosure.

[0019] Figure 12 illustrates an example of a processor 1200 in accordance with aspects of the present disclosure.

[0020] Figure 13 illustrates an example of a network equipment (NE) 1300 in accordance with aspects of the present disclosure.

[0021] Figure 14 illustrates a flowchart of a method performed by an RTP sender in accordance with aspects of the present disclosure.

[0022] Figure 15 illustrates a flowchart of a method performed by a base station in accordance with aspects of the present disclosure. DETAILED DESCRIPTION

[0023] Some wireless communications systems may support extended reality (XR) services. Such XR services may comprise XR applications. In some cases, traffic characteristics of an XR service may change dynamically, which may impact user experience or the like. For example, the size of a media segment may change dynamically when a user moves a progress bar of a streaming video. This change may require more bandwidth to buffer an initial set of video frames, allowing the streaming video to buffer sufficient data for smooth video playback. The buffering may comprise accumulating sufficient data for smooth video playback. The buffering may comprise collecting sufficient data for smooth video playback.

[0024] There is presented herein a solution that includes providing information to a network entity scheduler that allows the network entity scheduler to be aware (e.g., indicated) of such dynamic changes to a PDU Set size, and to schedule resources accordingly. The network entity scheduler may comprise a base station. The network entity scheduler may comprise a base station scheduler. The base station may comprise a gNB. The network entity scheduler may comprise a gNB scheduler.

[0025] Aspects of the present disclosure are described in the context of a wireless communications system.

[0026] Figure 1 illustrates an example of a wireless communications system 100 in accordance with aspects of the present disclosure. The wireless communications system 100 may include one or more NE 102, one or more UE 104, and a core network (CN) 106. The wireless communications system 100 may support various radio access technologies. In some implementations, the wireless communications system 100 may be a 4G network, such as an LTE network or an LTE-Advanced (LTE-A) network. In some other implementations, the wireless communications system 100 may be a NR network, such as a 5G network, a 5G-Advanced (5G-A) network, or a 5G ultrawideband (5G-UWB) network. In other implementations, the wireless communications system 100 may be a combination of a 4G network and a 5G network, or other suitable radio access technology including Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20. The wireless communications system 100 may support radio access technologies beyond 5G, for example, 6G. Additionally, the wireless communications system 100 may support technologies, such as time division multiple access (TDMA), frequency division multiple access (FDMA), or code division multiple access (CDMA), etc.

[0027] The one or more NE 102 may be dispersed throughout a geographic region to form the wireless communications system 100. One or more of the NE 102 described herein may be or include or may be referred to as a network node, a base station, a network element, a network function, a network entity, a radio access network (RAN), a NodeB, an eNodeB (eNB), a next-generation NodeB (gNB), or other suitable terminology. An NE 102 and a UE 104 may communicate via a communication link, which may be a wireless or wired connection. For example, an NE 102 and a UE 104 may perform wireless communication (e.g., receive signalling, transmit signalling) over a Uu interface.

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

[0029] The one or more UE 104 may be dispersed throughout a geographic region of the wireless communications system 100. A UE 104 may include or may be referred to as a remote unit, a mobile device, a wireless device, a remote device, a subscriber device, a transmitter device, a receiver device, or some other suitable terminology. In some implementations, the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples. Additionally, or alternatively, the UE 104 may be referred to as an Internet-of-Things (loT) device, an Internet-of-Everything (loE) device, or machine-type communication (MTC) device, among other examples. [0030] A UE 104 may be able to support wireless communication directly with other UEs 104 over a communication link. For example, a UE 104 may support wireless communication directly with another UE 104 over a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular-V2X deployments, the communication link may be referred to as a sidelink. For example, a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.

[0031] An NE 102 may support communications with the CN 106, or with another NE 102, or both. For example, an NE 102 may interface with other NE 102 or the CN 106 through one or more backhaul links (e.g., SI, N2, N2, or network interface). In some implementations, the NE 102 may communicate with each other directly. In some other implementations, the NE 102 may communicate with each other or indirectly (e.g., via the CN 106. In some implementations, one or more NE 102 may include subcomponents, such as an access network entity, which may be an example of an access node controller (ANC). An ANC may communicate with the one or more UEs 104 through one or more other access network transmission entities, which may be referred to as a radio heads, smart radio heads, or transmission-reception points (TRPs).

[0032] The CN 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. The CN 106 may be an evolved packet core (EPC), or a 5G core (5GC), which may include a control plane entity that manages access and mobility (e.g., a mobility management entity (MME), an access and mobility management functions (AMF)) and a user plane entity that routes packets or interconnects 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 entity may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signal bearers, etc.) for the one or more UEs 104 served by the one or more NE 102 associated with the CN 106.

[0033] The CN 106 may communicate with a packet data network over one or more backhaul links (e.g., via an SI, N2, N2, or another network interface). The packet data network may include an application server. In some implementations, one or more UEs 104 may communicate with the application server. A UE 104 may establish a session (e.g., a protocol data unit (PDU) session, or the like) with the CN 106 via an NE 102. The CN 106 may route traffic (e.g., control information, data, and the like) between the UE 104 and the application server using the established session (e.g., the established PDU session). The PDU session may be an example of a logical connection between the UE 104 and the CN 106 (e.g., one or more network functions of the CN 106).

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

[0035] One or more numerologies may be supported in the wireless communications system 100, and a numerology may include a subcarrier spacing and a cyclic prefix. A first numerology (e.g., /t=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first numerology (e.g., /t=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one slot per subframe. A second numerology (e.g., //=1) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g., g=2) may be associated with a third subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth numerology (e.g., /t=3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g., /t=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.

[0036] A time interval of a resource (e.g., a communication resource) may be organized according to frames (also referred to as radio frames). Each frame may have a duration, for example, a 10 millisecond (ms) duration. In some implementations, each frame may include multiple subframes. For example, each frame may include 10 subframes, and each subframe may have a duration, for example, a l ms duration. In some implementations, each frame may have the same duration. In some implementations, each subframe of a frame may have the same duration.

[0037] Additionally or alternatively, a time interval of a resource (e.g., a communication resource) may be organized according to slots. For example, a subframe may include a number (e.g., quantity) of slots. The number of slots in each subframe may also depend on the one or more numerologies supported in the wireless communications system 100. For instance, the first, second, third, fourth, and fifth numerologies (i.e., /t=0, /t=l, =2, jtz=3, =4) associated with respective subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single slot per subframe, two slots per subframe, four slots per subframe, eight slots per subframe, and 16 slots per subframe, respectively. Each slot may include a number (e.g., quantity) of symbols (e.g., OFDM symbols). In some implementations, the number (e.g., quantity) of slots for a subframe may depend on a numerology. For a normal cyclic prefix, a slot may include 14 symbols. For an extended cyclic prefix (e.g., applicable for 60 kHz subcarrier spacing), a slot may include 12 symbols. The relationship between the number of symbols per slot, the number of slots per subframe, and the number of slots per frame for a normal cyclic prefix and an extended cyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g., /t=0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

[0038] In the wireless communications system 100, an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands, frequency channels, etc. By way of example, the wireless communications system 100 may support one or multiple operating frequency bands, such as frequency range designations FR1 (410 MHz - 7.125 GHz), FR2 (24.25 GHz - 52.6 GHz), FR3 (7.125 GHz - 24.25 GHz), FR4 (52.6 GHz - 114.25 GHz), FR4a or FR4-1 (52.6 GHz - 71 GHz), and FR5 (114.25 GHz - 300 GHz). In some implementations, the NEs 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands. In some implementations, FR1 may be used by the NEs 102 and the UEs 104, among other equipment or devices for cellular communications traffic (e.g., control information, data). In some implementations, FR2 may be used by the NEs 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.

[0039] FR1 may be associated with one or multiple numerologies (e.g., at least three numerologies). For example, FR1 may be associated with a first numerology (e.g., /t=0), which includes 15 kHz subcarrier spacing; a second numerology (e.g., //=1), which includes 30 kHz subcarrier spacing; and a third numerology (e.g., g=2), which includes 60 kHz subcarrier spacing. FR2 may be associated with one or multiple numerologies (e.g., at least 2 numerologies). For example, FR2 may be associated with a third numerology (e.g., /z=2), which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g., /t=3), which includes 120 kHz subcarrier spacing.

[0040] 3GPP is currently studying enhancements to XR services support over the 3GPP network as part of the Release 19 study. One of the key issues currently in scope of the study is to support use cases where traffic characteristics of an XR service changes dynamically. For example, the size of the media segment could vary dynamically when, e.g., a user moves the progress bar of a streaming video, such that more bandwidth is needed to buffer an initial set of video frames to allow the streaming application to buffer enough data to support smooth video playback.

[0041] In another example, the size of data burst in an XR service could vary dynamically during video scene changes. In such a case the encoder creates a new video I- frame where the packet size is considerably higher as compared to a packet size of previous I-frames. Such scenarios may create problems for the operation of the RAN scheduler, as the PDU Set size of the new I-frame will be much higher than the PDU Set size of the previous frame (a P-frame). In order to ensure such a big burst of data is to be transferred within the PSDB of the QoS flow, the QoS parameters (e.g. Guaranteed Flow Bit Rate (GFBR) or Maximum Data Burst Volume (MDBV)) need to be set according to the potential maximum burst value in current QoS mechanism. This leads to a waste of network resource and lower user capacity during normal operation. [0042] There is presented herein a solution that includes providing information to the gNB scheduler that allows the gNB scheduler to be aware of such dynamic change of PDU Set size, and to schedule network resources accordingly.

[0043] A plethora of application and services where multimedia flows are multiplexed under a single network application session (i.e., a 5-tuple containing a source IP address, a destination IP address, a source network port, a destination network port, and a protocol number as identifier) relates to the domain of extended Reality (XR). Such XR applications and services are defines in 3GPP Technical Report TR 26.928 vl7.0.0 (Apr 2022), titled “Extended Reality (XR) in 5G”. As an example, an XR application based on WebRTC, or alternatively, on RTP/SRTP protocol stack, may contain one or more multiple video streams and audio streams multiplexed with control and feedback metadata and application metadata (e.g., such as user pose information, user input actions etc) over a single application data network session. Such arrangements were contemplated in the Applicant’s co-pending applications: US provisional application 63/428,026 is titled “PDU SET- AWARE MULTIMEDIA APPLICATIONS AND ASSOCIATED SIGNALING” by Stoica et al., Applicant’s reference SMM920220198-US-PSP; and US provisional application 63/478,932 titled “MULTIMEDIA SUBPROTOCOLS OVER REAL TIME PROTOCOL” by Stoica et al., Applicant’s reference SMM920220218-US-PSP.

[0044] It should be noted that while some of the examples and discussion hereafter use “XR” as a reference use case or family of applications for the solutions proposed herein, it should be readily apparent to the reader that that the proposed solutions are more generally applicable and may be employed in various different types of transport and network protocols stacks (e.g., QUIC, WebRTC, WebTransport to name but a few).

[0045] Furthermore, XR is referred to hereafter as an umbrella term for different types of realities, of which Virtual Reality, Augmented Reality, and Mixed Reality are examples.

[0046] Virtual Reality (VR) is a rendered version of a delivered visual and audio scene. The rendering is in this case designed to mimic the visual and audio sensory stimuli of the real world as naturally as possible to an observer or user as they move within the limits defined by the application. Virtual reality usually, but not necessarily, requires a user to wear a head mounted display (HMD), to completely replace the user's field of view with a simulated visual component, and to wear headphones, to provide the user with the accompanying audio. Some form of head and motion tracking of the user in VR is usually also necessary to allow the simulated visual and audio components to be updated to ensure that, from the user's perspective, items and sound sources remain consistent with the user's movements. In some implementations additional means to interact with the virtual reality simulation may be provided but are not strictly necessary.

[0047] Augmented Reality (AR) is when a user is provided with additional information or artificially generated items, or content overlaid upon their current environment. Such additional information or content will usually be visual and/or audible and their observation of their current environment may be direct, with no intermediate sensing, processing, and rendering, or indirect, where their perception of their environment is relayed via sensors and may be enhanced or processed.

[0048] Mixed Reality (MR) is an advanced form of AR where some virtual elements are inserted into the physical scene with the intent to provide the illusion that these elements are part of the real scene.

[0049] XR refers to all real-and-virtual combined environments and human-machine interactions generated by computer technology and wearables. It includes representative forms such as AR, MR and VR and the areas interpolated among them. The levels of virtuality range from partially sensory inputs to fully immersive VR. In some circles, a key aspect of XR is considered to be the extension of human experiences especially relating to the senses of existence (represented by VR) and the acquisition of cognition (represented by AR).

[0050] The XR Media (XRM) feature in 3GPP Release 18 at the core network (CN) level introduced the concept of a PDU Set to handle QoS requirements of XRM applications and streams with a better granularity beyond 5G Rel-17 QoS flow possibilities. As such, according to: 3GPP Technical Report TR 23.700-60 v0.0.3 (May 2022), titled “Study on XR (Extended Reality) and media services”; and 3GPP Technical Specification TS 23.501 V18.2.2 (Jun 2023), titled “System architecture for the 5G System (5GS)”, a PDU Set is composed of one or more PDUs carrying the payload of one unit of information generated at the application level (e.g. a frame or video slice for XRM Services). In some implementations all PDUs in a PDU Set are needed by the application layer to use the corresponding unit of information. In other implementations, the application layer can still recover parts or all of the information unit, when some PDUs are missing.

[0051] In addition, the PDU Set is associated with QoS requirements in terms of delay budget and error rate, which may be defined as PDU Set Delay Budget (PSDB), and/or as a PDU Set Error Rate (PSER) as defined in 3GPP Technical Report TR 23.700-60 v0.0.3 (May 2022), titled “Study on XR (Extended Reality) and media services”. The PDU Set Delay Budget (PSDB) defines an upper bound for the time that a PDU Set may be delayed between the UE and the N6 termination point at the UPF. PSDB applies to the DL PDU Set received by the UPF over the N6 interface, and to the UL PDU Set sent by the UE, and respectively. The PDU Set Error Rate (PSER) defines an upper bound for the rate of PDU Sets (e.g. set of IP packets constituting a PDU Set) that have been processed by the sender of a link layer protocol (e.g. RLC in RAN of a 3GPP access). The PSER may be used to determine an upper bound for a rate of non-congestion-related packet losses.

[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 of a specific service. The specific service may be a streaming service. A PDU Set may contain a specific type of packets of a service. The specific type of packets of a service may be, for example, I- frames of a video service. A PDU Set may comprise a single PDU or a plurality of PDUs.

[0053] Figure 2 illustrates an overview of a core network (CN) XRM architecture handling of PDU Sets. Figure 2 shows a system 200 comprising an Extended Reality Media Application Function (XRM AF) 210, a Policy and Control Function (PCF) 215, a Session Management Function (SMF) 220, an Access and Mobility Function (AMF) 225, a Radio Access Network (RAN 230, a User Equipment (UE) 235, a User Plane Function (UPF) 240, and an Extended Reality Application 245. The UE described here may comprise a remote unit 102, a UE, 235, 635, 835 or 1000 as described herein. The UPF described here may comprise a User Plane Function (UPF) as described herein such as UPF 240, 640, 740 840, 940; or a network equipment 1200. The operation of system 200 will now be described in the example of downlink traffic, a similar process may operate for uplink traffic. [0054] At 280, the XRM AF 210 determines PDU Set requirements.

[0055] At 281, the XRM Application Function 210 provides QoS requirements for packets of a PDU Set to the PCF 215 and information to identify the application (i.e. 5- tuple or application id). The QoS requirements may comprise PSDB and PSER. The XRM AF 210 may also include an importance parameter for a PDU Set and information for the core network to identify packets belonging to a PDU Set.

[0056] At 282, the PCF 215 derives QoS rules for the XR application and specific QoS requirements for the PDU Set and configures the SMF 220. The QoS rules may use a 5G QoS identifier (5QI) for XR media traffic. The PCF 215 sends the QoS rules to the SMF 220. The PCF 215 may include in the communication to the SMF 220 PCC rules per importance of a PDU Set. The PCC rules may be derived according to information received from the XRM AF 210 or based on an operator configuration.

[0057] At 283, the SMF 220 establishes a QoS flow according to the QoS rules by the PCF 215 and configures the UPF to route packets of the XR application to a QoS flow, and, in addition, to enable PDU Set handling. The SMF 220 also provides the QoS profile containing PDU Set QoS requirements to the RAN 230 via the AMF 225. The AMF 225 may provide the QoS profile containing PDU Set QoS requirements to the RAN 230 in an N2 SM container. Further, the AMF 225 may provide the QoS rules to the UE 235 in an N 1 SM container.

[0058] At 284, the UPF 240 inspects the packets and determines packets belonging to a PDU Set. The packet inspection may be based on UPF implementation; for instance by inspecting the RTP packet headers (as per US provisional application 63/428,026 titled “PDU SET-AWARE MULTIMEDIA APPLICATIONS AND ASSOCIATED SIGNALING” by Stoica et al., Applicant’s reference SMM920220198-US-PSP; and/or 3GPP Technical Specification TS 23.501 V18.2.2 (Jun 2023), titled “System architecture for the 5G System (5GS)”) or based on AS-marked PDU Set information transmitted over RTP PDU Set header extensions (as per: US provisional application 63/428,026 titled “PDU SET-AWARE MULTIMEDIA APPLICATIONS AND ASSOCIATED SIGNALING” by Stoica et al., Applicant’s reference SMM920220198-US-PSP; 3 GPP Technical Specification TS 23.501 V18.2.2 (Jun 2023), titled “System architecture for the 5G System (5GS)”; and/or 3GPP Technical Specification TS 26.522 v0.2.0 (Nov 2023), titled “5G Real-time Media Transport Protocol Configurations”) i.e., um:3gpp:pdu-set- marking:rel-18). When the UPF 240 detects packets of a PDU Set the UPF 240 marks the packets belonging to a PDU Set within a GTP-U header. The GTP-U header information includes a PDU Set sequence number and the size of the PDU Set. The UPF 240 may also determine the importance of the PDU Set either based on UPF 240 implementation means, information provided by the XRM AF 210 or information provided as metadata from an XRM application server. Based on the importance of the PDU Set the UPF 240 may route the traffic to a corresponding QoS flow 1 (according to the rules received from the SMF 220) or include the importance of the PDU Set within a GTP-U header. QoS flow 1 may comprise GTP-U headers, and these may include PDU Set information.

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

[0060] However, in XRM Release 18, 3GPP Technical Specification TS 23.501 vl8.2.2 (Jun 2023), titled “System architecture for the 5G System (5GS)”, once the PDU Set QoS integrated handling is enabled, the PSA UPF identifies PDUs that belong to PDU Sets and determines for each PDU Set the PDU Set information below sent over to the NG-RAN in the GTP-U header.

[0061] The PDU Set Information comprises: PDU Set Sequence Number, Indication of End PDU of the PDU Set, PDU Sequence Number within a PDU Set, PDU Set Size in bytes, and PDU Set Importance, which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS Flow.

[0062] The PDU Set information is then used by the NG-RAN for PDU Set based QoS handling as described above.

[0063] The NG-RAN may use Priority Levels as, for example, given in 3GPP Technical Specification TS 23.501 vl8.2.2 (Jun 2023), titled “System architecture for the 5G System (5GS)” at clause 5.7.3.3 thereof, across QoS Flows and PDU Set Importance within a QoS Flow for PDU Set level packet discarding in presence of congestion.

[0064] It is also specified in 3GPP TS 23.501 vl8.2.2 that the PSA UPF identifies PDUs that belong to PDU Sets and if the UPF receives a PDU that does not belong to a PDU Set based on Protocol Description for PDU Set identification (e.g., has not been marked with PDU Set information by the AS). If that is the case, then the UPF still maps the PDU to a PDU Set and determines the PDU Set Information as described above. This ensures that for a QoS flow with PDU Set enabled all the PDUs belong to a PDU Set. To this end, if the PSA UPF receives a PDU that does not belong to a PDU Set, it is assumed that the UPF determines the PDU Set Importance value based in some embodiments on preconfiguration and in other embodiments on an AS/AF signalled default importance.

[0065] The AS PDU Set information listed above is provided in some embodiments via a one-byte RTP Header Extension for the marking of PDU Sets, US provisional application 63/478,932 titled “MULTIMEDIA SUBPROTOCOLS OVER REAL TIME PROTOCOL” by Stoica et al., Applicant’s reference SMM920220218-US-PSP, and End of Bursts as defined by 3GPP Technical Specification TS 26.522 v0.2.0 (Nov 2023), titled “5G Realtime Media Transport Protocol Configurations” and illustrated in Figure 2 above.

[0066] Figure 3 illustrates a 1-byte RTP header extension for PDU Set marking by the AS as per 3GPP TS 26.522 v0.2.0.

[0067] Similarly, figure 4 illustrates a 2-byte RTP header extension for PDU Set marking by the AS as per 3GPP TS 26.522 v0.2.0. [0068] The semantics of the fields denoted in Figure 3 and Figure 4 of the RTP Header Extension for the marking of PDU Set and End of Bursts are as follows.

[0069] End PDU of the PDU Set [E] (1 bit field) 332, 432 is a flag set to 1 for the last PDU of the PDU Set and set to 0 for all other PDUs of the PDU Set.

[0070] Reserved [R] (2 bits field) 333, 433 is a reserved field for future use.

[0071] End of Data Burst [D] (1 bit field) 334, 434 indicates the end of a Data Burst being set to a non-zero value when the end of data burst is present and 0 otherwise.

[0072] PDU Set Importance [PSI] (4 bits field) 335, 435 indicates the importance of a PDU Set compared to other PDU Sets within the same QoS flow. Lower values indicate a higher importance PDU Set with the highest importance PDU Set of 0 and the lowest importance PDU Set of 15.

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

[0074] PDU Sequence Number within a PDU Set [PSN] (6 bits field) 337, 437 indicates the sequence number of the current PDU within the PDU Set. The PSN is set to 0 for the first PDU in the PDU Set and incremented monotonically for every PDU in the PDU Set in order of transmission from the sender. PSN wraps around 63.

[0075] PDU Set Size [PSSize] (24 bits field) 338, 438 indicates the total size of all PDUs of the PDU Set to which this PDU belongs. This field is optional and subject to an SDP signalling offer/answer negotiation, where the AS may indicate whether it will be able to provide the size of the PDU Set for that RTP stream. If not enabled, the field is not present. If enabled, but the AS is not able to determine the PDU Set Size for a particular PDU Set, it should set the value to 0 in all PDUs of that PDU Set. The PSSize indicates the size of a PDU Set including RTP/UDP/IP header encapsulation overhead of its corresponding PDUs. The PSSize is expressed in bytes.

[0076] Number of PDUs in the PDU Set [NPDS] (16 bits) 339, 439 indicates the total number of PDUs within the PDU Set. This field is optional and subject to an SDP signalling offer/answer negotiation, where the RTP Sender may indicate whether it will be able to provide the number of PDUs within the PDU Set for that RTP stream. It is recommended to add the Number of PDUs in the PDU Set field when the PDU Set Size field is present.

[0077] The above example relates to downlink (DL) traffic. Reciprocal processing is applicable to uplink (UL) traffic wherein the role of UPF 240 packet inspection is taken by the UE 235 which is expected to inspect uplink packets, determine packets belonging to a PDU Set, and signal accordingly the PDU Set to the RAN 230 for scheduling and resource allocation corresponding to an associated DRB fulfilling capable of fulfilling the PDU Set QoS requirements (i.e., PSDB and PSER). The low-level signalling mechanism associated with the UL UE-to-RAN information passing are up to the specification and implementations of RAN signalling procedures.

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

[0079] Figure 5a illustrates 1-to-l-to-l mapping: whereby the separation of QoS flows 520 and DRBs 530 is complete between high and low importance PDU Sets 510 optimizing finely the radio and network resources on a per PDU Set basis.

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

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

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

[0083] Figure 6 illustrates a UPF identifying dynamic changes in traffic characteristics of an XR service. Figure 6 shows a system 600 comprising an Extended Reality Media Application Function (XRM AF) 610, a Policy and Control Function (PCF) 615, a Session Management Function (SMF) 620, an Access and Mobility Function (AMF) 625, a Radio Access Network (RAN 630, a User Equipment (UE) 635, a User Plane Function (UPF) 640, and an Extended Reality Application 645. The UE described here may comprise a remote unit 102, a UE, 235, 635, 835 or 1000 as described herein. The UPF described here may comprise a User Plane Function (UPF) as described herein such as UPF 240, 640, 740 840, 940; or a network equipment 1200.

[0084] In figure 6, data associated with I-frames of video content are shown with a dotted pattern, data associated with P-frames of video content are shown with a hash pattern, and data associated with B-frames of video content are shown with a striped pattern. The operation of system 600 will now be described in the example of downlink traffic, a similar process may operate for uplink traffic. [0085] An AF 610 when requesting an AF session towards the 3 GPP network (NEF) includes additional information indicating that the XR service may have dynamic changes in traffic characteristics. The AF 610 may also include information indicating the max and/or min and/or average expected PDU Set size of the XR service. Note that it is assumed that the 3rd party provider of the AF and the 3GPP network have SLA agreement to include information on traffic characteristics. The PDU Set requirements for an IP flow (5-tuple) AF indication that session may change traffic characteristics and may include information of highest expected PDU Set size.

[0086] The PCF 615 in the 3 GPP network providing PCC rules determines the MDBV to support the traffic characteristics of the XR service. The PCF 615 may determine the MDBV based on input from AF or based on operator policies. The PCF 615 may also include an indication of a PDU Set size threshold. The PDU Set size threshold is a trigger for the core network (i.e. UPF 640) to notify the gNB (RAN 630) that the size of a received PDU Set exceeds the size threshold. The gNB uses the information to schedule the resources accordingly and ensure the PDU Set is delivered to the UE 635 within the PDU Set QoS requirements. The PCF 615 may determine and provide several thresholds where the gNB needs to be notified, i.e. PDU Set size ranges could be defined. The PCF 615 may also include the min, max and average PDU Set size information in the PCC rule. The min max average may be provided by the AF. Alternatively, they can be determined by the UPF/SMF. The PCF 615 may determine if the UPF 640 needs to detect PDU Set size change above a certain threshold. The threshold is configurable based on operator preference. The PCF 615 passes to the SMF 620 PCC rules with PSDB requirements, which may include PDU Set size variation threshold information. The threshold information may comprise a PDU Set size threshold value.

[0087] The SMF 620 constructing QoS rules based on the PCC rules may include an indication of PDU Set size threshold and min, max, average PDU Set size information that is provided to the RAN/gNB within an N2 message.

[0088] The SMF 620 constructing N4 rules based on the PCC rules where the N4 rules may include an indication to the UPF 640 to enable detection of PDU Set size changes between received PDU Sets. The SMF may also include a PDU Set size threshold. For example, the N4 rules may comprise an instruction to detect PDU Set size variation, and also threshold information.

[0089] The UPF 640 may carry out the following actions.

[0090] If a threshold is provided, then the UPF 640 is arranged to identify PDUs of a PDU Set and determines if the PDU Set size exceeds the threshold. If the PDU Set size is above the threshold then the UPF adds a flag in a previous received PDU Set that the size of the next PDU Set will be above a threshold. In another embodiment the UPF before sending the PDU Set where the size is above a threshold includes a dummy packet including PDU Set information notifying the size of the next PDU Set is above a threshold. In such an embodiment, the dummy packet is constructed and sent to the gNB after the first PDU of a largely sized PDU Set (i.e., above a pre-determined threshold) is received at N6 interface for the service data flow. 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 marking information available in RTP header extensions to determine when and how to construct and send the dummy packet to the gNB. The gNB may drop in some embodiments the dummy packet as it carries no application logic information.

[0091] In an alternative example, still where a threshold is provided, the UPF 640 is arranged to identify PDUs of a PDU Set and determines if the PDU Set size exceeds the threshold. If the PDU Set size is above the threshold then the UPF adds the PDU Set size of this PDU Set size in a previous received PDU Set. In another embodiment the UPF before sending the PDU Set where the size is above a threshold includes a dummy packet including PDU Set information including the size of the next PDU Set, In such an embodiment, the dummy packet is constructed and sent to the gNB after the first PDU of a largely sized PDU Set (i.e., above a pre-determined threshold) is received at N6 interface for the service data flow. 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 marking information available in RTP header extensions to determine when and how to construct and send the dummy packet to the gNB. The gNB may drop in some embodiments the dummy packet as it carries no application logic information. [0092] However, if a threshold is not provided, then the UPF 640 determines PDU Set size of a PDU Set and adds the PDU Set size in a previous received PDU Set (e.g. if PDU Set size threshold is not included in an N4 rule). Alternatively, the UPF 640 includes a dummy packet including the PDU Set information indicating the size of the next PDU Set before sending the PDU Set to the gNB. The gNB may drop the dummy packet as it carries no application logic information.

[0093] Figure 7 is a messaging diagram illustrating the operation of the system 600 illustrated in Figure 6. Figure 7 illustrated a procedure 700 that allows for the gNB to be aware of dynamic traffic characteristics changes. Figure 7 illustrates a gNB 730, an Access and Mobility Function (AMF) 725, a User Plane Function (UPF) 740, a Session Management Function (SMF) 720, a Policy and Control Function (PCF) 715, a Network Exposure Function (NEF) 750, an Application Function (AF) 745, and an Application Server (AS) 755.

[0094] The process 700 commences at 771, wherein the AF 745 requests to establish an AF session with QoS by invoking the Nnef AFSessionWithQoS Create service operation as described in clause 4.15.6.6 of 3GPP TS 23.502 vl8.3.0 (Sep 2023) titled “Procedures for the 5G System (5GS)” including PDU Set QoS parameters for the XR service. The AF may include additionally information indicating that the XR service may have dynamic changes in traffic characteristics. The AF may also include information indicating the max and/or min and/or average expected PDU Set size of the XR service. That is, the AF session request may comprise a protocol description such as 5 tuple of the packet (address of UE, address of content server, source/destination ports and protocol identifier), PDU Set QoS requirements (Min/Max PDU Set size) and/or an indication of Dynamic change of traffic characteristics.

[0095] Not shown in the Figure the NEF 750 authorizes the request and forwards the request to the PCF 715 by invoking an Npcf PolicyAuthorization C reate request including the information provided by the AF 745.

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

[0097] At 773, the PCC rules are sent by the PCF 715 to the SMF 720. The PCC rules may comprise PDU Set QoS for 5 tuple, Indication of traffic characteristic awareness, and PDU Set size threshold.

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

[0099] At 775, the SMF 720 sends the updated QoS rules to the AMF 725 in an Namf message or in an Nsmf (in response to a PDU session create/update). The updated QoS rules include the PDU Set Size Threshold.

[0100] At 776, the AMF 725 forwards the updated QoS rules to the gNB 730 in an N2 message. The N2 message includes Updated QoS Rules, which in turn include PDU Set size threshold.

[0101] At 777, when the SMF 720 receives acknowledgement that the gNB 730 has received the updated QoS rules, the SMF 720 creates Packet Detection Rules (N4 rules) for the UPF. The SMF includes within PDR information to enable detection of PDU Set size changes between received PDU Sets. The SMF 720 includes a PDU Set size threshold if included in the PCC rule provided by the PCF 715.

[0102] At 778, the N4 rules are sent by the SMF 720 to the UPF 740. The N4 rules comprise packet detection rules, PDU Set size change identification, and PDU Set size threshold.

[0103] At 779, UPF receives from an application server sends a series of PDUs for an XR service. The series of PDUs may be referred to as XR packets. The series of PDUs may comprise a first PDU Set having a PDU Set size=normal PDU Set size, and a second PDU Set having a PDU Set size of=high PDU Set size. The RTP encoder in the application server may include PDU Set information within RTP extension headers.

[0104] At 780, the UPF 740 inspect the PDUs and determines that there is a matching N4/PDR rule. Based on the N4 rule the UPF 740 determines that PDU Set identification needs to take place and also identify PDU Set size change between received PDU Set. The following options for identifying PDU Set size change may take place.

• UPF 740 identifies PDUs of a PDU Set and determines if the PDU Set size exceeds the threshold. If the PDU Set size is above the threshold then the UPF adds a flag in a previous received PDU Set that the size of the next PDU Set will be above a threshold. In another embodiment the UPF before sending the PDU Set where the size is above a threshold includes a dummy packet including PDU Set information notifying the size of the next PDU Set is above a threshold.

• UPF 740 identifies PDUs of a PDU Set and determines if the PDU Set size exceeds the threshold. If the PDU Set size is above the threshold then the UPF adds the PDU Set size of this PDU Set size in a previous received PDU Set. In another embodiment the UPF before sending the PDU Set where the size is above a threshold includes a dummy packet including PDU Set information including the size of the next PDU Set

• UPF 740 determines PDU Set size of a PDU Set and adds the PDU Set size in a previous received PDU Set (e.g. if PDU Set size threshold is not included in an N4 rule). In another embodiment the UPF before sending the PDU Set includes a dummy packet including PDU Set information including the upcoming PDU Set size of the next PDU Set.

[0105] At 781, the UPF 740 sends within GTP-U over N3 and to the gNB 730 information indicating PDU Set size change based on one of the options described in step 780. The N3 GTP-U header comprises PDU Set size notification of upcoming PDU Set.

[0106] At 782, when the gNB 730 receives an indication that the size of an upcoming PDU Set is above a threshold the gNB adapts the scheduling resources to ensure that the PDU Set is sent within the PDU Set QoS requirements of the QoS flow. [0107] As an alternative to the arrangement shown in Figure 7, the gNB may not receive additional information as part of QoS requirements for the QoS flow established but may instead receive PDU Set QoS requirements and MDBV values as described in 3 GPP TS 23.501 V18.2.2. When the gNB receives an indication that the size of an upcoming PDU Set is above the thresholds the gNB considers whether the upcoming PDU Set has a size greater than the MDBV value of the received QoS requirements. If the upcoming PDU Set has a size greater than the MDBV value of the received QoS requirements, then the gNB adapts the scheduling resources to ensure that the PDU Set is sent within the PDU Set QoS requirements of the QoS flow.

[0108] There will now be described an arrangement wherein support of a PDU Set size change is provided at the Application Server and/or RTP encoder.

[0109] To avoid excessive buffering at the UPF that may consume and impact the PSDB of some PDU Sets, the RTP sender, i.e., an AS, or alternatively, a UE, may additionally support indications of dynamic traffic characteristics, such as large PDU Set size above a determined threshold. Based on these indications, the core network (CN) (i.e., the UPF) may determine dynamic traffic characteristics indications without additional buffering needs and further signal this information to the gNB in data plane over N3 GTP- U encapsulation tunnel as previously detailed.

[0110] Figure 8 illustrates an RTP sender awareness and signalling of dynamic PDU Set size. Figure 8 shows a system 800 comprising an Extended Reality Media Application Function (XRM AF) 810, a Policy and Control Function (PCF) 815, a Session Management Function (SMF) 820, an Access and Mobility Function (AMF) 825, a Radio Access Network (RAN) 830, a User Equipment (UE) 835, a User Plane Function (UPF) 840, and an Extended Reality Application 845. The UE described here may comprise a remote unit 102, a UE, 235, 635, 835 or 1000 as described herein. The UPF described here may comprise a User Plane Function (UPF) as described herein such as UPF 240, 640, 740 840, 940; or a network equipment 1200.

[OHl] In figure 8, data associated with I-frames of video content are shown with a dotted pattern, data associated with P-frames of video content are shown with a hash pattern, and data associated with B-frames of video content are shown with a striped pattern. The operation of system 800 will now be described in the example of downlink traffic, a similar process may operate for uplink traffic.

[0112] At 871, the AF 810 requests an AF session towards the 3 GPP network (PCF/NEF) that includes additional information indicating that the XR service may have dynamic changes in traffic characteristics. The AF 810 may also include information indicating the max and/or min and/or average expected PDU Set size of the XR service. The AF session request may comprise PDU Set requirements for an IP flow (5-tuple), and an indication that session may change traffic characteristics. The AF session request may further comprise information of largest expected PDU Set size. It may be assumed in some example implementations that the 3^rd party provider of the AF and the 3 GPP network have SLA agreement to include information on traffic characteristics (e.g., max/min PDU Set sizes serviceable with PDU Set QoS flow guarantees, a dedicated set of applicable PDU Set size threshold for different levels of service etc.)

[0113] 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 variation and/or threshold information. The PCC rules determine the MDBV to support the traffic characteristics of the XR service. The PCF 815 may determine the MDBV based on input from AF or based on operator policies. The PCF 815 may also determine PDU Set size threshold and include it as an indication for dynamic handling of traffic characteristics. The threshold may be configurable based on operator preference. The PDU Set size threshold is a trigger for an RTP sender (e.g., an AS, or alternatively, a peer UE) to aid the gNB in handling application data that exceeds said threshold. An RTP sender may include additional information to the 5GS in case incoming PDU Set exceed the size threshold, or alternatively, pace the sending of a PDU Set exceeding the threshold into multiple PDU Sets not exceeding the threshold. The gNB (e.g. RAN 830) uses the information and/or generated PDU Sets to schedule the resources accordingly and ensure the PDU Sets are delivered to the UE within the PDU Set QoS requirements.

[0114] At 873, the PCF 815 providing the PCC rules and determining the PDU Set size threshold, may additionally expose the PDU Set size threshold to the AF request for an AF session. This may be done by way of an AF session response, sent in response to the AF session request. The PCF 815 sends to the AF 815 the AF session response with QoS parameters of PDU Set handling and PDU Set size threshold information. The AF may in turn let the RTP sender know of the QoS session configuration and the PDU Set size threshold such that the RTP sender (i.e., AS, or alternatively, UE) may adopt the appropriate sending strategy. In this example, the XR AF 810 sends PDU Set size threshold information for dynamic traffic characteristics support, in this example the PDU Set size threshold is 800KB.

[0115] At 874, the SMF 820 constructing QoS rules based on the PCC rules may include an indication of PDU Set size threshold that is provided to the RAN/gNB within an N2 message. The QoS rules may include a PDU Set Size threshold.

[0116] At 875, the SMF constructing N4 rules based on the PCC rules where the N4 rules may include an indication to the UPF to enable detection of PDU Set size changes between received PDU Sets. The SMF may also include a PDU Set size threshold.

[0117] The UPF 840 detects dynamic PDU Set size change based on signalling received from the AS, for example via RTP header extensions. Upon detecting a dynamic PDU Set size change, the UPF 840 adds an indication in GTP-U headers to RAN 830.

[0118] The RTP sender may additionally implement the following strategies based on the 3GPP network response to the AF session request with dynamic with dynamic traffic characteristics.

[0119] For example, when the network provides a threshold for PDU Set size, the RTP sender may perform paced transmissions by applying the threshold PDU Set size response from the 3GPP network to a packet pacer such that the PDU Set size threshold is used to limit the paced of outbound PDU Sets (i.e., data bursts) not to exceed a certain MBDV. Generally, an RTP paced sender ensures a smooth service data flow by applying limited buffering at the media source. The buffer queues the media before its transmission through a network. The pacing may be implemented by a leaky bucket algorithm such that data bursts, i.e., PDU Sets, of certain maximum size are sent over the 3GPP network. In some implementations, the buffer may include separate FIFO queues for individual media tracks whereby additional prioritization as per additional RTP sender policies (e.g., audio prioritized over video, etc.) may be applied, or alternatively, round-robin paced sending is applied to avoid any media stream blocking others. This RTP sender strategy applies pacing to all packets and PDU Sets ensuring an almost constant data rate across both short and long-time intervals at the cost of increased content delay at the source and PDU Sets not being logically matched to a video frame.

[0120] Alternatively, but also when the network provides a threshold for PDU Set size, the RTP sender may buffer at least two consecutive PDU Sets as released by media encoders. The RTP sender checks for each PDU Set its size against the PDU Set size threshold as indicated by the 3 GPP network. If for a current PDU Set the PDU Set size exceeds the PDU Set size threshold, the RTP sender indicates in the previous PDU Set to the 3GPP network that the next PDU Set is a large PDU Set whose size exceeds the PDU Set size threshold set. This indication may be part of the PDU Set marking as an additional information field, or alternatively, may be indicated as part of a new RTP header extension for dynamic traffic characteristics. The indication may include in some embodiments just a flag (e.g., a bit of information) indicating that the next PDU Set in the PDU Set sequence of the service data flow 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 preserving PDU Sets logical mapping to Application Data Units (ADUs) while limiting latency to a time interval corresponding to the media frame per second of a multimedia source.

[0121] The RTP sender may buffer at most one PDU Set for each media stream of the service data flow and applies the 3 GPP network PDU Set threshold to determine if the PDU Set exceeds it.

[0122] In case the PDU Set in the buffer exceeds the PDU Set size threshold, the RTP sender may splits in one embodiment the PDU Set into two PDU Sets. A first PDU Set containing at least one PDU of the buffered PDU Set, and a second PDU Set containing at the rest of the PDUs of 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 in the first PDU Set to the 3 GPP network that the next PDU Set (i.e., the second PDU Set) is a large PDU Set whose size exceeds the PDU Set size threshold set. This indication may be part of the PDU Set marking over RTP header extension as an additional information field, or alternatively, may be indicated as part of a new RTP header extension for dynamic traffic characteristics. The indication may include in some embodiments just a flag (e.g., a bit of information) indicating that the next PDU Set in the PDU Set sequence of the service data flow 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. The interval between sending to the 3 GPP network the first PDU Set and the second PDU Set may be determined by the RTP sender based on at least one of a static low-latency configuration (e.g., max. 1-2 ms), a 3 GPP network configuration as part of the response signalling the PDU Set size threshold, or an SLA between the 3^rd party ASP and a 3GPP network operator. This RTP sender strategy ensures reducing latency at the source to a bare minimum of a single media frame, yet it does not preserve PDU Sets logical mapping to Application Data Units (ADUs) for PDU Sets exceeding the PDU Set size threshold.

[0123] In an alternative example, but still in the case that the PDU Set in the buffer exceeds the PDU Set size threshold, the RTP sender may introduces a dummy PDU Set (e.g., without media payload) and use the dummy PDU Set to indicate to the 3GPP network (i.e., to the UPF and gNB) in user plane that an upcoming large PDU Set exceeding the PDU Set size threshold is about to arrive next. The dummy PDU Set may contain a single RTP PDU (e.g., without a media payload), including 3GPP metadata information carrying an indication of the upcoming large PDU Set and is sent before the large PDU Set. The indication may be part of the PDU Set marking over RTP header extension as an additional information field, or alternatively, may be indicated as part of a new RTP header extension for dynamic traffic characteristics. The indication may include in some embodiments just a flag (e.g., a bit of information) signalling that the next PDU Set in the PDU Set sequence of the service data flow is a large PDU Set. In other embodiments, the indication may include additional information related to at least one of a flag indication marking that the current PDU Set is a dummy PDU Set, a timing interval describing the expected arrival time of upcoming large PDU Set shall arrive, the upcoming PDU Set sequence number whose PDU Set size exceeds the threshold, and the PDU Set size of the upcoming PDU Set exceeding the threshold. The interval between sending to the 3 GPP network the dummy PDU Set and the large PDU Set may be determined by the RTP sender based on at least one of a static low-latency configuration (e.g., max. 1-2 ms), a 3 GPP network configuration as part of the response signalling the PDU Set size threshold, or an SLA between the 3^rd party ASP and a 3GPP network operator. This RTP sender strategy ensures reducing latency at the source to a bare minimum of a single media frame, and preserving all PDU Sets logical mapping to Application Data Units (ADUs).

[0124] In a further example, the RTP sender may combine any of the above sender strategies to reach a desired treatment of media streams within a service data flow based on application-level requirements of latency and PDU Set/ ADUs processing.

[0125] Detailed steps of a procedure embodying above RTP sender strategies are shown in Figure 9. Figure 9 is a messaging diagram illustrating the operation of the system 800 illustrated in Figure 8. Figure 9 illustrated a procedure 900 that allows for the gNB to be aware of dynamic traffic characteristics changes. Figure 9 illustrates a gNB 930, an Access and Mobility Function (AMF) 925, a User Plane Function (UPF) 940, a Session Management Function (SMF) 920, a Policy and Control Function (PCF) 915, a Network Exposure Function (NEF) 950, an Application Function (AF) 945, and an Application Server (AS) / RTP Sender 955.

[0126] The process 900 is an example procedure for gNB to be aware of dynamic traffic characteristics changes with RTP sender (e.g., AS) support. The process 900 commences at 971, where the AF 945 requests for an RTP sender the 3 GPP network to establish an AF session with QoS by invoking the Nnef_AFSessionWithQoS Create service operation as described in clause 4.15.6.6 of 3GPP TS 23.502 including PDU Set QoS parameters for the XR service. The AF may include additionally information indicating that the XR service may have dynamic changes in traffic characteristics. The AF may also include information indicating the max and/or min and/or average expected PDU Set size of the XR service and the RTP sender capability for supporting dynamic traffic characteristics awareness signalling. For example, the AF session request may include a protocol description comprising 5 tuple of the packet (address of UE, address of content server, source/destination ports and protocol identifier), PDU Set QoS requirements (Min/Max PDU Set size and/or indication of dynamic change of traffic characteristics with support from the RTP sender).

[0127] Not shown in the figure, the NEF 950 authorizes the request and forwards the request to the PCF 915 by invoking an Npcf PolicyAuthorization C reate request including the information provided by the AF 945.

[0128] At 972, the PCF 915 creates PCC rules considering the PDU Set QoS parameters as described in clause 6.1.3.22 of 3GPP TS 23.503 vl8.3.0. The PCF 915 determines QoS rules which includes the MDBV to support the traffic characteristics of the XR service. The PCF may determine based on input from AF or based on operator policies. The PCF may also include an indication of a PDU Set size threshold which when is exceeded the gNB needs to be aware to schedule the resources accordingly. For example, the PCF 915 may determine to enable awareness of traffic characteristics at the gNB 930.

[0129] At 973, the AF 945 forwards to the RTP sender 955, the PCF 915 response to the AF session request in step 971. The response may comprise AF session request accepted. The response may contain additional new information including the PDU Set size threshold information for dynamic traffic characteristics support. Alternatively, the PDU Set size may be determined by the RTP sender based on SLA (e.g., based on the PSDB requested or based or the service ID). The AF 945 may forward to the RTP sender 955 PDU Set size threshold information for traffic characteristics support. The PDU Set size threshold information may be delivered to the RTP sender 955 by virtue of the AF session response or from a Service Level Agreement (SLA).

[0130] At 974, the PCC rules are sent from the PCF 915 to the SMF 920. The PCC Rules may include PDU Set QoS for 5 tuple, Indication of traffic characteristic awareness, PDU Set size threshold.

[0131] At 975, the SMF 920 identifies the PDU session of a UE affected and determines updated QoS rules. The SMF 920 may include in the updated QoS rule the PDU Set size threshold in the updated QoS rules message to the AMF 925. [0132] At 976, the SMF 920 sends the updated QoS rules to the AMF 925 in an Namf message or in an Nsmf (in response to a PDU session create/update). The updated QoS rules may comprise the PDU Set Size Threshold.

[0133] At 977, the AMF 925 forwards the updated QoS rules, including the PDU Set size threshold, to the gNB 930 in an N2 message.

[0134] At 978, when the SMF 920 receives acknowledgement that the gNB 930 has received the updated QoS rules, the SMF 920 creates Packet Detection Rules (N4 rules) for the UPF. The SMF 920 includes within PDR information to enable detection of PDU Set size changes between received PDU Sets. The SMF 920 includes a PDU Set size threshold if included in the PCC rule provided by the PCF 915. In this way, the SMF 920 creates N4 rules for the UPF 940 to enable PDU Set identification for PDU Set size change.

[0135] At 979, the N4 rules are sent by the SMF 920 to the UPF 940. It includes the additional information that RTP sender provides support for dynamic traffic characteristic PDU Set size changes (e.g., protocol description containing RTP header extensions information and enabled RTP sender support for dynamic PDU Set size changes). The N4 rules may comprise packet detection rules, PDU Set size change identification, PDU Set size threshold, and/or RTP sender support for PDU Set size changes.

[0136] At 980, the RTP sender 955 (e.g., an AS, or alternatively, a peer UE) performs the following processing. a. The RTP sender 955 uses information exposed by the network in Step 973, i.e., at least the PDU Set size threshold to configure and select an RTP sender strategy (e.g., fully paced sending, 2-PDU Set buffering, large PDU Set splitting, dummy PDU Set insertion, or combinations thereof) in support of dynamic traffic characteristics awareness and PDU Set size changes. b. The RTP sender 955 applies the selected RTP sender strategy to send and mark as necessary the dynamic traffic characteristics changes based on the PDU Set size threshold set by the network. The marking of dynamic PDU Set size changes is performed in user plane over N6 interface to the UPF and the information is carried over RTP header extensions as either part of the PDU Set marking RTP header extension, or alternatively, as a standalone RTP header extension. The XR packets may include support for dynamic PDU Set size change, e.g., indication when PDU Set size threshold is exceeded by the next PDU Set of the service data flow.

[0137] At 981, the UPF 940 inspects the incoming PDUs and determines that there is a matching N4/PDR rule. Based on the N4 rule the UPF determines that PDU Set identification needs to take place and identifies PDU Set size change between received PDU Sets. This is done based on the RTP sender signalling part of the RTP header extensions (e.g., RTO header extension for PDU Set marking or other RTP header extensions). The UPF determines the PDUs of a PDU Set and determines if an upcoming PDU Set size exceeds the threshold based on the RTP sender provided information in the user plane. For example, the determination may be made based on AS indications in user plane over RTP header extensions.

[0138] At 982, the UPF 940 sends within GTP-U over N3 information to the gNB indicating PDU Set size change based on Step 981. The N3 GTP-U header may comprise PDU Set size notification of upcoming PDU Set.

[0139] At 983, the gNB 930 adapts its scheduler to handle a PDU set that exceeds threshold. For example, when the gNB receives an indication that the size of an upcoming PDU Set is above a threshold, the gNB adapts the scheduling resources to ensure that the PDU Set is serviced within the PSDB according to MDBV of the QoS requirements of the QoS flow. Despite the fact that the flow example in Figure 9 is presented with reference to a DL example, an RTP sender follows the same procedures as detailed in the above embodiments for both UL and DL service data flows to mark dynamic traffic characteristic changes with respect to PDU Set size.

[0140] There will now be described RTP receiver behaviour in handling dynamic traffic characteristics indications as described above. The RTP receiver may comprise a RAN, a gNB, or a UE.

[0141] The RAN and the gNB radio resource scheduler can take advantage of the dynamic traffic characteristic changes relative to the size of upcoming large PDU Sets. The gNB can thus adapt its scheduling routine and policies to proactively reserve radio resources for upcoming large PDU Sets based on the dynamic traffic characteristic changes indications detailed previously. This provides advantages in meeting the PDU Set PSDB and QoS requirements of the QoS flow even for large PDU Sets exceeding a PDU Set Size threshold configured for the session by the core network. The relevant steps of the gNB behavior to this end follow below with reference to both downlink (DL) and uplink (UL) directions.

[0142] In the DL direction the gNB receives an indication as part of the GTP-U header of a PDU Set for an upcoming large PDU Set above the PDU Set size threshold set for the session on the QoS flow. The PDU Set whose GTP-U header carries the indication is sent before the large PDU Set within a time interval determined either by traffic characteristics (i.e., media frame per seconds, traffic periodicity and jitter statistics), or alternatively, by a configured timing interval (e.g., network configured pacing interval for a split large PDU Set, dynamically signalled time interval between a dummy PDU Set and the large PDU Set etc.). The indication corresponding to metadata information for dynamic traffic characteristics is in some embodiments comprising at least one of

• a flag or identifier determining the dynamic traffic characteristics indication type (e.g., dynamic traffic characteristic change for large PDU Set);

• a flag indicating that the PDU Set whose GTP-U header includes the indication is one of a dummy PDU Set generated by the 3GPP network, i.e., the UPF, and thus may be ignored from service over the air-interface, a dummy PDU Set generated by the RTP sender, or alternatively, a split first PDU Set generated by the RTP sender from a large PDU Set split into two parts whereby the first part, i.e., first PDU Set, indicates the second part, i.e., the second PDU Set, if the second part is still above the PDU Set Size threshold;

• a timing interval between sending the PDU Set whose GTP-U header includes the indication and the large upcoming PDU Set being indicated;

• an identifier PDU Set Sequence Number pointing to the upcoming large PDU Set whose size is above the PDU Set size threshold; and/or

• a PDU Set Size field signalling the size of the upcoming large PDU Set whose size is above the PDU Set size threshold. [0143] The gNB uses the indication information to adapt dynamically the radio resource scheduling and prime it for the future an upcoming large PDU Set, ensuring 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.

[0144] In servicing the PDU Sets under the PSDB of the QoS flow, the gNB manages the following three cases.

[0145] In a first case, two PDU Sets corresponding to two different ADUs with first PDU Set sent before the second PDU Set and the first PDU Set indicating second large PDU Set:

• The first PDU Set is serviced by the gNB based on RAN legacy procedures given the PSDB of the associated QoS flow. The indication included 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 in advance radio resources for the large second PDU Set.

• When the second PDU Set arrives at the gNB, the large PDU Set is serviced according to the allocated resources based on RAN legacy procedures given the PSDB of the associated QoS flow. In case the second PDU Set fails to arrive at the gNB within a statically configured time interval greater than the expected arrival time, the gNB may pre-empt in some embodiments the pre-allocated radio resources of the second PDU Set.

[0146] In a second case, two PDU Sets, with first PDU Set as a dummy PDU Set sent before the second PDU Set and the dummy PDU Set indicating the second large PDU Set:

• The dummy PDU Set may be discarded by the gNB where the dummy PDU Set is generated inside the 3GPP network, i.e., at the UPF. However, if the dummy PDU Set is not generated by the 3GPP network and it originates at the RTP sender, then the gNB may not discard the dummy PDU Set. In such examples, the gNB will serve the dummy PDU Set with lowest PDU Set importance (i.e., priority) according to RAN legacy procedures given the PSDB of the associated QoS flow. Irrespective of the discarding of the dummy PDU Set, the gNB processes the indication carried by its GTP-U header to prepare the radio resource allocation for the upcoming large second PDU Set. • When the second PDU Set arrives at the gNB, the large PDU Set is serviced according to the allocated resources based on RAN legacy procedures given the PSDB of the associated QoS flow. In case the second PDU Set fails to arrive at the gNB within a statically configured time interval greater than the expected arrival time, the gNB may pre-empt the pre-allocated radio resources of the second PDU Set.

[0147] In a third case, two PDU Sets corresponding to the same ADU, with first PDU Set as first part of an ADU (e.g., at least one PDU) and second PDU Set as the remaining part of the ADU, the first PDU Set indicating the second large PDU Set. In such a case, the gNB leverages the information available in the indication corresponding to the first PDU Set to prime and/or pre-allocate radio resources for the second (i.e., large) PDU Set. Yet since the two PDU Sets correspond to the same ADU at the application level, the gNB may use further this information to optimize its servicing of the PDU Sets under PSDB of the QoS flow using either Conservative gNB processing or Greedy gNB processing.

[0148] Since the PDU Sets belong to the same ADU, they are treated by the gNB commonly, e.g. using one timer enforcing the common PSDB, fulfilling a common PSDB. The gNB processing is thus same to legacy RAN procedures of handling a single PDU Set, and may be referred to as ‘conservative gNB processing’. In case the first PDU Set exceeds the PSDB or cannot be serviced under the PSDB guarantee by the gNB, the second PDU Set is automatically discarded based on its reference to the first PDU Set when PDU Set integrated handling has been configured for this QoS flow/bearer, e.g. PSIHI has been configured. The reference is determined based on the GTP-U header indication (as determined based either on UPF dynamic traffic characteristics detection or based on RTP sender signalling) of the first PDU Set identifying it as a split first PDU Set. An example header information for the inter-dependent PDU Sets with dynamic traffic characteristic indication is provided in Figure 10.

[0149] Alternatively, the gNB may take advantage of the fact that the PDU Sets belong to the same ADU and are split by the RTP sender. The gNB controls the delay status of the two PDU Sets separately by e.g. assigning two separate (PDCP) timer to the two PDU Sets in accordance with the PSDB of the QoS flow. The gNB will service 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 the second PDU Set timer is started, the gNB resets the timer of the first PDU Set as well. This dynamic timer adaptation of the first PDU Set ensures that the gNB treats commonly the two split PDU Sets once they are both in the RAN buffers and so does not penalize the second large PDU Set. This may be referred to as ‘Greedy gNB processing’.

[0150] Where the first PDU Set cannot fulfil its PSDB (e.g., either by exceeding its PSDB or by not being able to be scheduled within the PSDB given air-interface congestion or generally when the PSIHI is set for this QoS flow, as soon as one PDU of the first PDU Set is known to be lost), the gNB will discard both the first PDU Set and the second PDU Set since the two PDU Sets are related and belong to the same ADU. The same behaviour applies also when a PDU of the second PDU Set is known to be lost, e.g. gNB would discard the entire first and second PDU Set - assuming the PSIHI is set for this QoS flow.

[0151] Figure 10 is an example header information for two inter-dependent PDU Sets (i.e., both PDU Sets logically represent the same ADU) with dynamic traffic characteristic indication, wherein a first PDU Set 1010 carries information about the dynamic traffic size characteristic change of a second PDU Set 1020.

[0152] A time interval dt between the start (or alternatively, the end) of the first PDU Set 1010 and the second PDU Set 1020 may be of the order of 1 or 2 milliseconds in some communication schemes. The header 1015 of the first PDU Set 1010 is shown in expanded view and comprises PDU Set Marking Information 1016, and Dynamic Traffic Size Change Information 1017. The PDU Set Marking Information 1016 comprises: PDU Set sequence number, PDU sequence number, PDU Set end PDU, PDU Set importance, and PDU Set size. The Dynamic Traffic Size Change Information 1017 comprises: PDU Set dummy flag, inter-dependent PDU Set flag, PDU Set sequence number of large PDU Set, and PDU Set size of the large PDU Set.

[0153] In the UL direction the gNB schedules a UE based on the UE scheduling requests and associated UE provided information. As such, even though the policies and routines detailed above are similarly applicable, their functionality is split between the UE and gNB, and the indications of dynamic traffic characteristics changes relative to PDU Set size needs to be reported at lower layers, e.g., MAC layer. These indications of dynamic traffic characteristics changes relate to additional information elements added to Buffer Status Reporting (BSR) and Delay Status Reporting (DSR) procedures.

[0154] In the UL direction, the UE takes on similar functionality to the UPF and needs to determine the dynamic traffic characteristics changes relative to the PDU Set size. A UE configured by the network with a PDU Set size threshold may use in-band user plane information (e.g., either as configured by modem specific configuration interfaces used by the application logic for configuration of the UE, or alternatively, by means of NAS signalling, e.g., SM container metadata information via N1 reference point and 3GPP network configuration of the UE) coming from application layer related to dynamic traffic characteristics changes.

[0155] A configured UE for dynamic traffic characteristics changes may detect, based on configuration the service data flows marked by an RTP sender (e.g., a UE application) with dynamic traffic characteristics changes relative to PDU Set size. The configuration may be configured by modem specific configuration interfaces used by the application logic for configuration of the UE, or alternatively, by means of NAS signalling, e.g., SM container metadata information via Nl reference point and 3 GPP network configuration of the UE. The UE processes the metadata information available at the level of RTP header extensions to determine any dynamic traffic characteristics changes, such as an upcoming PDU Set size exceeding a PDU Set size threshold configured by the 3 GPP network. The metadata information may include as detailed above at least one of the following information elements:

• a flag, or equivalently an identifier, field indicating that the PDU Set comprising the indication carries information of a dynamic PDU Set change;

• a flag field indicating that the PDU Set comprising the indication is a dummy PDU Set or a split PDU Set;

• a timing field indicating the time interval between sending the PDU Set comprising the indication and an upcoming large (e.g., next) PDU Set

• a flag field indicating that a next PDU Set is a the large PDU Set exceeding the PDU Set size threshold; • a PDU Set size field indicating the PDU Set size field of the upcoming (e.g., next on the wire) large PDU Set;

• an identifier field indicating a PDU Set Sequence Number of an upcoming large PDU Set; and

• a PDU Set size field indicating the PDU Set size field of an upcoming PDU Set.

[0156] The UE may request scheduling occasions to the gNB for both a first PDU Set carrying the indication of dynamic traffic characteristics changes relative to PDU Set size, as well as to a second large PDU Set exceeding the configured PDU Set size threshold after the first PDU Set is available in the transmit buffer of the UE and the PDCP timer has been started for the PDUs/SDUs of the first PDU Set. The scheduling request will include the legacy BSR and DSR procedures for the first PDU Set, and in addition, a delayed BSR (e.g., based on a DSR including a future time reference information element) for the second PDU Set. In the case of the delayed BSR, the UE may use the upcoming large PDU Set size information as well as the timing information of the time delay between the first PDU Set and the second PDU Set transmission interval as dynamically provided by the RTP sender, or semi-statically configured by the UE application, or alternatively, the 3 GPP network (e.g., via NAS signalling).

[0157] In one example, the UE will trigger a BSR upon arrival of the first PDU /SDU of the second PDU Set or the information of the upcoming large second PDU Set in order to notify gNB about the additional UL resources required for the large PDU Set. A new BSR trigger condition is introduced according to this embodiment. According to one implementation, the BSR reports the expected buffer size of the second PDU Set, e.g. based on PDU Set size information provided by higher layer, not the amount data which is available for transmission in the UE buffer. In a situation where the UE processes two PDU Sets corresponding to the same ADU (with first PDU Set as first part of an ADU (e.g., at least one PDU) and second PDU Set as the remaining part of the ADU), the first PDU Set indicating the second large PDU Set, the UE follows discarding logic which may comprise either ‘conservative processing’ or ‘greedy processing’.

[0158] In Conservative processing, the UE treats the inter-dependent PDU Sets (that belong to the same ADU) commonly using a common PSDB. In case the first PDU Set exceeds the common PSDB or cannot be serviced under the common PSDB guarantee by the RAN, the second PDU Set is automatically discarded by the UE in UL given the second PDU Set reference to the first PDU Set. The reference is determined based on the GTP-U header indication of the first PDU Set identifying it as a split first PDU Set. In one example UE starts - as specified in the current specification - a PDCP discard timer for each of the SDUs/PDUs of the PDU Sets. If pdu-SetDiscard is configured for the PDCP entity/bearer/LCH, e.g. PDU Set integrated handling is configured for the QoS flow/bearer, UE discards all PDCP SDUs belonging to the PDU Set to which the PDCP SDU belongs along with the corresponding PDCP Data PDUs as well as all PDCP SDUs belonging to the inter-dependent PDU Set along with the corresponding PDCP Data PDUs upon expiry of a PDCP discard timer.

[0159] In Greedy processing, the UE treats the PDU Sets (that belong to the same ADU) separately by two separate PSDB based on the QoS flow configuration. Once the first PDU Set arrives at the UE transmit buffers the corresponding PDCP discard timers associated with the PDUs of the first PDU Set are started by the UE and the first PDU Set is transmitted over the air-interface given the available scheduling grants received from the RAN. When the PDUs of the second PDU Set are received in the transmit buffers, UE starts correspondingly the associated PDCP discard timers. Additionally, the UE resets the PDCP discard timers associated with the first PDU Set and restarts the PDCP discard timers upon arrival of the first PDU of the second PDU Set- at least for cases when the first PDU Set transfer has not been yet completed. The second PDU Set is next transmitted by the UE over the air based on the pre-allocated radio resources scheduled by the gNB based on the early request for scheduling occasions for the large PDU Set.

[0160] In case the first PDU Set or second PDU Set cannot fulfill their PSDB (e.g., either by exceeding its PSDB or by not being able to be scheduled within the PSDB given air-interface congestion), the UE will discard both PDU Sets remaining bytes to be transferred since the two PDU Sets are related and belong to the same ADU. The corresponding UE behaviour would be same as for the conservative processing approach.

[0161] There is provided herein a Real-time Transport Protocol, RTP, sender for wireless communication, the RTP sender comprising: at least one memory; and at least one processor coupled with the at least one memory and arranged to cause the RTP sender to: receive a Protocol Data Unit, PDU, set size threshold value, the PDU Set size threshold value determining a PDU Set size traffic characteristic for a service data flow; apply the PDU Set size threshold value to PDU Sets of the service data flow, the applying comprising identifying a PDU Set size change between a first PDU Set and a second PDU Set of the PDU Sets of the service data flow, wherein the second PDU Set size satisfies the PDU Set size threshold value; and transmit the first PDU Set, the second PDU Set, and an indication of a dynamic PDU Set size change.

[0162] A first network function may receive PDU Sets from the RTP sender. The PDU Sets may be for a base station. The first network function may be a UPF. Such an RTP sender allows the base station to be aware of the dynamic change of traffic characteristics by notifying of a PDU Set size increase between received consecutive PDU Sets. Based on this notification the base station can adapt the scheduling resources and ensure that the PDU Sets are sent to the UE according to the PDU Set QoS requirements of the QoS flow regardless of PDU Set size.

[0163] The base station may be a gNB. The RTP sender may be an application server (AS), and the AS may further comprise in some deployments application function (AF) functionality. The RTP receiver may be a user equipment (UE). In contrast, the RTP sender may be a UE and the RTP receiver may be another UE or an AS.

[0164] The second PDU Set may be sent subsequent to the first PDU Set.

[0165] The service data flow may comprise a QoS flow. ‘QoS flow’ is a 5GS concept mapping to a data flow of a service (i.e., service data flow) in order to ensure a certain level of Quality of Service across the 5GS based on an application's request to the network. Typically, an application or service will output a service data flow to a 5GS. When this enters the 5GS it is mapped to a QoS flow based on the application/service request for QoS. A service data flow may be mapped to a plurality of QoS flows in future releases.

[0166] The identifying of a PDU Set size change may be performed based upon the PDU Set size threshold value. The service data flow may be sent towards an RTP receiver. The second PDU Set size satisfying the PDU Set size threshold value may comprise the second PDU Set size exceeding the PDU Set size threshold value.

[0167] To apply the PDU Set size threshold value to the PDU Sets of the service data flow, the at least one processor may be further arranged to cause the RTP sender to: buffer at least one PDU Set and determine if the buffered PDU Set satisfies the PDU Set size threshold value; or pace one or more PDU Set transmissions, wherein each PDU Set determined by the RTP sender does not satisfy the PDU Set size threshold value.

[0168] A PDU Set that has a size which satisfies the PDU Set size threshold value may be characterized as a large PDU Set.

[0169] Pacing one or more PDU Set transmissions may comprise making the pattern of PDU Set transmission less bursty. Bursty traffic can lead to higher queuing delays, more packet losses and lower throughput. PDU Set pacing may comprise spreading bursts of data transmission and evenly spacing data transmissions across a round-trip time.

[0170] To apply the PDU Set size threshold value to the PDU Sets of the service data flow, the at least one processor may be further arranged to cause the RTP sender to: buffer at least two PDU Sets of the PDU Sets of the service data flow and determine if each buffered PDU Set satisfies the PDU Set size threshold value.

[0171] The at least one processor may be further arranged to cause the RTP sender to: indicate a dynamic PDU Set size change upon determining that a buffered PDU Set satisfies the PDU Set size threshold value, the indicating comprising at least one of: split a PDU Set that satisfies the PDU Set size threshold value into two PDU Subsets, whereby the first PDU Subset contains of at least one PDU of the PDU Set and the second PDU Subset contains the remaining PDUs of the PDU Set; signal in the first PDU Set the indication of the dynamic PDU Set size change corresponding to the second PDU Set satisfying the PDU Set size threshold value, the first PDU Set being sent by the RTP sender before the second PDU Set is sent; and signal in a dummy PDU Set the indication of the dynamic PDU Set size change corresponding to the second PDU Set satisfying the PDU Set size threshold value, the dummy PDU Set being sent by the RTP sender before the second PDU Set is sent. [0172] PDU Subsets may be alternatively referred to as dependent PDU Sets. The dependent PDU Sets carry payload corresponding logically to the same Application Data Unit (ADU) and may be treated commonly at the application level.

[0173] The time interval between sending the indication of the dynamic PDU Set size change and the second PDU Set, is determined based on at least one of: a network exposed time interval configuration for the RTP sender; an RTP sender timing configuration based on multimedia service data flow characteristics; and/or a Service Level Agreement for the service data flow.

[0174] The indication of the dynamic PDU Set size change may comprise a PDU Set, the PDU Set further comprising at least one of: a flag field indicating that the PDU Set comprising the indication is a dummy PDU Set; a flag field indicating that the PDU Set comprising the indication is a PDU Subset; a timing field indicating the time interval between sending the PDU Set comprising the indication and the second PDU Set; a flag field indicating that the PDU Set comprising the indication carries information of the dynamic PDU Set size change; a flag field indicating that a next PDU Set has a PDU Set size that satisfies the PDU Set size threshold value; a PDU Set size field indicating the PDU Set size field of the next PDU Set, wherein the next PDU Set has a PDU Set size that satisfies the PDU Set size threshold value; an identifier field indicating a PDU Set Sequence Number of an upcoming PDU Set that has a PDU Set size that satisfies the PDU Set size threshold value; and a PDU Set size field indicating the PDU Set size field of the upcoming PDU Set that has a PDU Set size that satisfies the PDU Set size threshold value.

[0175] The PDU Subset may comprise a dependent PDU Set. Dependent PDU Sets carry payload corresponding logically to the same Application Data Unit (ADU) and may be treated commonly at the application level.

[0176] The indication of the dynamic PDU Set size change may be included in at least one of: an RTP header extension field for PDU Set marking; and/or an RTP header extension for dynamic traffic characteristics change.

[0177] The PDU Set size threshold value may be based on at least one of: a Service Level Agreement of the service data flow; a response to an Application Function request for a Session with Quality of Service, QoS, and dynamic traffic characteristics support posted on behalf of the RTP sender to a Policy Control Function, wherein the response comprises an acceptance of the Application Function request and additional information including the PDU Set size threshold for determining dynamic traffic characteristics change; or an RTP sender configuration based on at least one of a set of available bit rates of a multimedia source of the PDU Sets, a maximum data burst value expected for the PDU Sets, and expected average and variance of PDU Sets; or a combination thereof.

[0178] The service data flow of an application, or alternatively, a service may be mapped by some networks, like 3GPP 5G system, or alike, to one or more QoS flows to ensure the level of Quality of Service requirements for the service data flow. The Quality of Service requirements may be defined as any of latency, bit rate, reliability etc.

[0179] There is further provided a method performed by an RTP sender, the method comprising: receiving a Protocol Data Unit, PDU, set size threshold value, the PDU Set size threshold value determining a PDU Set size traffic characteristic for a service data flow; applying the PDU Set size threshold value to PDU Sets of the service data flow, the applying comprising identifying a PDU Set size change between a first PDU Set and a second PDU Set of the PDU Sets of the service data flow, wherein the second PDU Set size satisfies the PDU Set size threshold value; and transmitting the first PDU Set, the second PDU Set, and an indication of a dynamic PDU Set size change.

[0180] A first network function may receive PDU Sets from the RTP sender. The PDU Sets may be for a base station. The first network function may be a UPF. Such a method allows the base station to be aware of the dynamic change of traffic characteristics by notifying of a PDU Set size increase between received consecutive PDU Sets. Based on this notification the base station can adapt the scheduling resources and ensure that the PDU Sets are sent to the UE according to the PDU Set QoS requirements of the QoS flow regardless of PDU Set size.

[0181] The base station may be a gNB. The RTP sender may be an application server (AS), and the AS may further comprise in some deployments application function (AF) functionality. The RTP receiver may be a user equipment (UE). In contrast, the RTP sender may be a UE and the RTP receiver may be another UE or an AS. [0182] The second PDU Set may be sent subsequent to the first PDU Set.

[0183] The service data flow may comprise a QoS flow. ‘QoS flow’ is a 5GS concept mapping to a data flow of a service (i.e., service data flow) in order to ensure a certain level of Quality of Service across the 5GS based on an application's request to the network.

Typically, an application or service will output a service data flow to a 5GS. When this enters the 5GS it is mapped to a QoS flow based on the application/service request for QoS. A service data flow may be mapped to a plurality of QoS flows in future releases.

[0184] Applying the PDU Set size threshold value to the PDU Sets of the service data flow may comprise: buffering at least one PDU Set and determining if the buffered PDU Set satisfies the PDU Set size threshold value; or pacing one or more PDU Set transmissions, wherein each PDU Set determined by the RTP sender does not satisfy the PDU Set size threshold value.

[0185] Pacing one or more PDU Set transmissions may comprise making the pattern of PDU Set transmission less bursty. Bursty traffic can lead to higher queuing delays, more packet losses and lower throughput. PDU Set pacing may comprise spreading bursts of data transmission and evenly spacing data transmissions across a round-trip time.

[0186] A PDU Set that has a size which satisfies the PDU Set size threshold value may be characterized as a large PDU Set.

[0187] Applying the PDU Set size threshold value to the PDU Sets of the service data flow may further comprise buffering at least two PDU Sets of the PDU Sets of the service data flow and determining if each buffered PDU Set satisfies the PDU Set size threshold value.

[0188] The method may further comprise indicating the dynamic PDU Set size change upon determining that a buffered PDU Set satisfies the PDU Set size threshold value, the indicating comprising at least one of splitting a PDU Set that satisfies the PDU Set size threshold value into two PDU Subsets, whereby the first PDU Subset contains of at least one PDU of the PDU Set and the second PDU Subset contains the remaining PDUs of the PDU Set; signalling in the first PDU Set the indication of the dynamic PDU Set size change corresponding to the second PDU Set satisfying the PDU Set size threshold value, the first PDU Set being sent by the RTP sender before the second PDU Set is sent; and signalling in a dummy PDU Set the indication of the dynamic PDU Set size change corresponding to the second PDU Set satisfying the PDU Set size threshold value, the dummy PDU Set being sent by the RTP sender before the second PDU Set is sent.

[0189] PDU Subsets may be alternatively referred to as dependent PDU Sets. The dependent PDU Sets carry payload corresponding logically to the same Application Data Unit (ADU) and may be treated commonly at the application level.

[0190] A time interval between sending the indication of the dynamic PDU Set size change and the second PDU Set, may be determined based on at least one of: a network exposed time interval configuration for the RTP sender; an RTP sender timing configuration based on multimedia service data flow characteristics; and/or a Service Level Agreement for the service data flow.

[0191] The indication of the dynamic PDU Set size change may comprise a PDU Set, the PDU Set further comprising at least one of: a flag field indicating that the PDU Set comprising the indication is a dummy PDU Set; a flag field indicating that the PDU Set comprising the indication is a PDU Subset; a timing field indicating the time interval between sending the PDU Set comprising the indication and the second PDU Set; a flag field indicating that the PDU Set comprising the indication carries information of the dynamic PDU Set size change; a flag field indicating that a next PDU Set has a PDU Set size that satisfies the PDU Set size threshold value; a PDU Set size field indicating the PDU Set size field of the next PDU Set, wherein the next PDU Set has a PDU Set size that satisfies the PDU Set size threshold value; an identifier field indicating a PDU Set Sequence Number of an upcoming PDU Set that has a PDU Set size that satisfies the PDU Set size threshold value; and a PDU Set size field indicating the PDU Set size field of the upcoming PDU Set that has a PDU Set size that satisfies the PDU Set size threshold value.

[0192] The PDU Subset may comprise a dependent PDU Set. Dependent PDU Sets carry payload corresponding logically to the same Application Data Unit (ADU) and may be treated commonly at the application level. [0193] The indication of the dynamic PDU Set size change may be included in at least one of: an RTP header extension field for PDU Set marking; and/or an RTP header extension for dynamic traffic characteristics change.

[0194] The PDU Set size threshold value may be based on at least one of: a Service Level Agreement of the service data flow; a response to an Application Function request for a Session with Quality of Service, QoS, and dynamic traffic characteristics support posted on behalf of the RTP sender to a Policy Control Function, wherein the response comprises an acceptance of the Application Function request and additional information including the PDU Set size threshold for determining dynamic traffic characteristics change; or an RTP sender configuration based on at least one of a set of available bit rates of a multimedia source of the PDU Sets, a maximum data burst value expected for the PDU Sets, and expected average and variance of PDU Sets; or a combination thereof.

[0195] The service data flow of an application, or alternatively, a service may be mapped by some networks, like 3GPP 5G system, or alike, to one or more QoS flows to ensure the level of Quality of Service requirements for the service data flow. The Quality of Service requirements may be defined as any of latency, bit rate, reliability etc.

[0196] There is provided herein a base station 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 base station to: receive, from a second network function, information that indicates a set of quality of service, QoS, requirements for handling protocol data unit, PDU, Sets for a QoS flow; determine a first set of resources, for transmission of the PDU Sets to a user equipment, UE, based at least in part on the set of QoS requirements; receive, from a first network function, a first PDU Set as a series of IP packets over a network interface for the QoS flow, the first PDU Set including an indication that an upcoming second PDU Set has a second PDU Set size, wherein the second PDU Set size is different to the first PDU Set size; determine a second set of resources, for transmission of the second PDU Set to the UE, based at least in part on the set of QoS requirements, wherein the second set of resources support the second PDU Set size; receive the second PDU Set from the first network function; and transmit the second PDU Set to the UE according in part to the second set of resources. [0197] The first network function may be a UPF. The first network function may receive PDU Sets for the base station from an RTP sender. The second network function may be an SMF. The base station may be a gNB. Such a method allows the base station to be aware of a dynamic change of traffic characteristics by notifying of a PDU Set size increase between received consecutive PDU Sets. Based on this notification the base station can adapt the scheduling resources and ensure that the PDU Sets are sent to the UE according to the PDU Set QoS requirements of the QoS flow regardless of PDU Set size. The second scheduling resources may comprise an adaptation of the first scheduling resources.

[0198] The QoS requirements may comprise a PDU Set Delay Budget and a Maximum Data Burst Volume size. The QoS requirements may include one or more ranges of PDU Set size threshold. The network interface may comprise an N3 interface.

[0199] The base station may be further arranged to receive an indication of PDU Set size changes when a PDU Set size of an upcoming PDU Set is above a PDU Set size threshold value.

[0200] There is further still provided herein a method performed by a base station, the method comprising: receiving, from a second network function, information that indicates a set of quality of service, QoS, requirements for handling protocol data unit, PDU, Sets for a QoS flow; determining a first set of resources, for transmission of the PDU Sets to a user equipment, UE, based at least in part on the set of received QoS requirements; receiving, from a first network function, a first PDU Set as a series of IP packets over a network interface for the QoS flow, the first PDU Set including an indication that an upcoming second PDU Set has a second PDU Set size, wherein the second PDU Set size is different to the first PDU Set size; determining a second set of resources, for transmission of the second PDU Set to the UE, based at least in part on the set of QoS requirements, wherein the second set of resources support the second PDU Set size; receiving the second PDU Set from the first network function; and transmitting the second PDU Set to the UE according in part to the second set of resources.

[0201] The first network function may be a UPF. The first network function may receive PDU Sets for the base station from an RTP sender. The second network function may be an SMF. The base station may be a gNB. Such a method allows the base station to be aware of a dynamic change of traffic characteristics by notifying of a PDU Set size increase between received consecutive PDU Sets. Based on this notification the base station can adapt the scheduling resources and ensure that the PDU Sets are sent to the UE according to the PDU Set QoS requirements of the QoS flow regardless of PDU Set size.

[0202] The second scheduling resources may comprise an adaptation of the first scheduling resources. The network interface may comprise an N3 interface.

[0203] The QoS requirements may comprise a PDU Set Delay Budget and a Maximum Data Burst Volume size. The QoS requirements may include one or more ranges of PDU Set size threshold. The method may further comprise receiving an indication of PDU Set size changes when a PDU Set size of an upcoming PDU Set is above a PDU Set size threshold value.

[0204] One of the key issues currently in scope of 3 GPP study is to support use cases where the traffic characteristics of the XR services can change dynamically.

[0205] For example, where the size of a media segment may vary dynamically when, e.g., when a user moves the progress bar of a streaming video more bandwidth is needed to buffer an initial set of video frames to allow the streaming application to buffer enough data to support smooth video playback. In another example, the side of data burst in XR service could vary dynamically during video scene changes. In such a case the encoder creates a new video I-frame where the packet size is considerably higher against a packet size of a previous.

[0206] Such scenarios may create complexity at the RAN scheduler as the PDU Set size of the new 1-frame will be much higher than the PDU Set size of the previous frame (a P-frame). In order to ensure such big burst of data to be transferred within the PSDB of the QoS flow, the QoS parameters (e.g. GFBR or MDB V) need to be set according to the potential maximum burst value in current QoS mechanism. This leads to a waste of network resource and lower user capacity.

[0207] The solution prosed herein comprises allowing the gNB to be aware of dynamic change of traffic characteristics by notifying of a PDU Set size increase between received PDU Set. Based on this notification, the gNB can adapt the scheduler and ensure that the PDU Set is sent to the UE according to the PDU Set QoS requirements of the QoS flow.

[0208] The XR service described herein will provide awareness to the gNB of traffic characteristics change; this awareness provided via the user plane.

[0209] Thus, a UPF may identify dynamic changes in traffic characteristics of the XR service based on UPF implementation. Once determined the dynamic changes are signalled in DL direction to the gNB via GTP-U headers metadata information to provide awareness to the dynamic traffic characteristics changes relative to consecutive PDU Sets sizes

[0210] In further examples, the RTP Sender (i.e., the application either in the AS or in the UE) may pace the PDU Sets at the source based on the maximum PDU Set size threshold, or alternatively, may mark the PDU Sets with metadata information about the dynamic traffic characteristics changes relative to PDU Set size above a configured PDU Set size threshold. When the dynamic traffic characteristics changes are marked, the metadata information is provided as part of the PDU Set marking RTP header extension or as part of a separate RTP header extension in-band over the user plane. This can be utilized both in DL (e.g., by the UPF and then by the gNB via GTP-U headers information as determined by Embodiment 1) and in UL (e.g., by the UE as per Embodiment 3) to aid the gNB scheduler in allocating radio resources to large PDU Sets satisfying the configured PDU Set size threshold.

[0211] In further still examples, the gNB/UE behaviour relative to the signalled dynamic traffic changes may include taking into account upcoming large PDU Sets and pre-allocating/asking for radio resources by/from the gNB scheduler. In the case of the UE, the UE may use the provided in-band user plane indication to detect dynamic traffic size characteristic changes. When a large PDU Set is detected radio resources may be asked for in advance to be able to satisfy the PSDB of large PDU Sets even when these satisfy a configured PDU Set size threshold. In addition, discarding of PDU Sets may be enhanced when two inter-dependent PDU Sets are used to signal the dynamic change in traffic size characteristics, i.e., when a first PDU Set indicates a large second PDU Set and both PDU Sets logically represent same ADU. [0212] There is presented herein a method at an RTP sender wherein: the RTP sender is configured with a Protocol Data Unit (PDU) set size threshold, the threshold determining a PDU Set size traffic characteristic; the RTP sender applies the PDU Set size threshold to process a dynamic PDU Set size change associated with upcoming PDU Sets of one or more media streams of a service data flow; and the RTP sender transmits the PDU Sets of the service data flow in part with an indication of the dynamic PDU Set size change as determined based on the PDU Set size threshold.

[0213] The processing of the dynamic PDU Set size may include at least one of the RTP sender buffering at least a first PDU Set and determining if the PDU Set satisfies the configured PDU Set size threshold to determine a large PDU Set characteristic; and the RTP sender pacing PDU Sets transmissions whereby each PDU Set determined by the RTP sender does not satisfy the configured PDU Set size threshold.

[0214] The processing of the dynamic PDU Set size change may further include: the RTP sender buffering at least a second PDU Set and determining if the PDU Set satisfies the configured PDU Set size threshold to determine the large PDU Set characteristic.

[0215] The RTP sender may indicate the dynamic PDU Set size change upon the determined large PDU Set characteristic based at least on one of: splitting a PDU Set with the large PDU Set characteristic into two PDU Sets, whereby the first PDU Set contains of at least one PDU of the split PDU Set and the second PDU Set contains the remaining PDUs of the split PDU Set with the large PDU Set characteristic; signalling in the first PDU Set the indication of the dynamic PDU Set size change corresponding to the second subsequent PDU Set having the large PDU Set characteristic, the first PDU Set being sent by the RTP sender before the second PDU Set with the large PDU Set characteristic; and signalling in a dummy PDU Set the indication of the dynamic PDU Set size change corresponding to a next subsequent PDU Set having the large PDU Set characteristic, the dummy PDU Set being sent by the RTP sender before the PDU Set with the large PDU Set characteristic.

[0216] The time interval between the RTP sender sending the PDU Set with the indication of the dynamic PDU Set size corresponding to the next PDU Set having the large PDU Set characteristic and the next PDU Set with the large PDU Set characteristic may be determined by the RTP sender based on at least one of: a network exposed time interval configuration for the RTP sender; an RTP sender timing configuration based on multimedia service data flow characteristics; and a Service Level Agreement for the service data flow.

[0217] The indication of the dynamic PDU Set size change may comprise at least one of: a flag field indicating that the PDU Set comprising the indication is a dummy PDU Set or a split PDU Set; a timing field indicating the time interval between sending the PDU Set comprising the indication and a next PDU Set that has the large PDU Set characteristic; a flag field indicating that the PDU Set comprising the indication carries information of a dynamic PDU Set size change; a flag field indicating that a next PDU Set has the large PDU Set characteristic; a PDU Set size field indicating the PDU Set size field of the next PDU Set has the large PDU Set characteristic; an identifier field indicating a PDU Set Sequence Number of an upcoming PDU Set that has the large PDU Set characteristic; and a PDU Set size field indicating the PDU Set size field of an upcoming PDU Set that has the large PDU Set characteristic.

[0218] The indication of the dynamic PDU Set size may be included in at least one of: a RTP header extension field for PDU Set marking; and a RTP header extension for dynamic traffic characteristics change.

[0219] The configured PDU Set size threshold may be determined based on at least one of: the PDU Set size threshold value; a Service Level Agreement of the service data flow; a response to an Application Function request for a Session with Quality of Service (QoS) and dynamic traffic characteristics support posted on behalf of the RTP sender to a Policy Control Function, the response comprising an acceptance of the request and additional information including a PDU Set size threshold for determining dynamic traffic characteristics change.

[0220] Figure 11 illustrates an example of a UE 1100 in accordance with aspects of the present disclosure. The UE 1100 may include a processor 1102, a memory 1104, a controller 1106, and a transceiver 1108. The processor 1102, the memory 1104, the controller 1106, or the transceiver 1108, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0221] The processor 1102, the memory 1104, the controller 1106, or the transceiver 1108, or various combinations or components thereof may be implemented in hardware (e.g., circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

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

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

[0224] In some implementations, the processor 1102 and the memory 1104 coupled with the processor 1102 may be configured to cause the UE 1100 to perform one or more of the functions described herein (e.g., executing, by the processor 1102, instructions stored in the memory 1104). For example, the processor 1102 may support wireless communication at the UE 1100 in accordance with examples as disclosed herein. [0225] The controller 1106 may manage input and output signals for the UE 1100. The controller 1106 may also manage peripherals not integrated into the UE 1100. In some implementations, the controller 1106 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 1106 may be implemented as part of the processor 1102.

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

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

[0228] A transmitter chain 1112 may be configured to generate and transmit signals (e.g., control information, data, packets). The 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 like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The 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 the wireless medium. The transmitter chain 1112 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium. [0229] Figure 12 illustrates an example of a processor 1200 in accordance with aspects of the present disclosure. The processor 1200 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 1200 may include a controller 1202 configured to perform various operations in accordance with examples as described herein. The processor 1200 may optionally include at least one memory 1204, which may be, for example, an L1/L2/L3 cache. Additionally, or alternatively, the processor 1200 may optionally include one or more arithmetic-logic units (ALUs) 1206. One or more of these components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses).

[0230] The processor 1200 may be a processor chipset and include 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) in accordance with examples as described herein. The processor chipset may include one or more cores, one or more caches (e.g., memory local to or included in the processor chipset (e.g., the 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), and others).

[0231] The controller 1202 may be configured to manage and coordinate various operations (e.g., signalling, receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) of the processor 1200 to cause the processor 1200 to support various operations in accordance with examples as described herein. For example, the controller 1202 may operate as a control unit of the processor 1200, generating control signals that manage the operation of various components of the processor 1200. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating timing of operations. [0232] The controller 1202 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from the memory 1204 and determine subsequent instruction(s) to be executed to cause the processor 1200 to support various operations in accordance with examples as described herein. The controller 1202 may be configured to track memory address of instructions associated with the memory 1204. The controller 1202 may be configured to decode instructions to determine the operation to be performed and the operands involved. For example, the controller 1202 may be configured to interpret the instruction and determine control signals to be output to other components of the processor 1200 to cause the processor 1200 to support various operations in accordance with examples as described herein. Additionally, or alternatively, the controller 1202 may be configured to manage flow of data within the processor 1200. The controller 1202 may be configured to control transfer of data between registers, arithmetic logic units (ALUs), and other functional units of the processor 1200.

[0233] The memory 1204 may include one or more caches (e.g., memory local to or included in the processor 1200 or other memory, such RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc. In some implementations, the memory 1204 may reside within or on a processor chipset (e.g., local to the processor 1200). In some other implementations, the memory 1204 may reside external to the processor chipset (e.g., remote to the processor 1200).

[0234] The memory 1204 may store computer-readable, computer-executable code including instructions that, when executed by the processor 1200, cause the processor 1200 to perform 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. The controller 1202 and/or the processor 1200 may be configured to execute computer-readable instructions stored in the memory 1204 to cause the processor 1200 to perform various functions. For example, the processor 1200 and/or the controller 1202 may be coupled with or to the memory 1204, the processor 1200, the controller 1202, and the memory 1204 may be configured to perform various functions described herein. In some examples, the processor 1200 may include multiple processors and the memory 1204 may include multiple memories. One or more of the multiple processors may be coupled with one or more of the multiple memories, which may, individually or collectively, be configured to perform various functions herein.

[0235] The one or more ALUs 1206 may be configured to support various operations in accordance with examples as described herein. In some implementations, the one or more ALUs 1206 may reside within or on a processor chipset (e.g., the processor 1200). In some other implementations, the one or more ALUs 1206 may reside external to the processor chipset (e.g., the processor 1200). One or more ALUs 1206 may perform one or more computations such as addition, subtraction, multiplication, and division on data. For example, one or more ALUs 1206 may receive input operands and an operation code, which determines an operation to be executed. One or more ALUs 1206 be configured with a variety of logical and arithmetic circuits, including adders, subtractors, shifters, and logic gates, to process and manipulate the data according to the operation. Additionally, or alternatively, the one or more ALUs 1206 may support logical operations such as AND, OR, exclusive-OR (XOR), not-OR (NOR), and not-AND (NAND), enabling the one or more ALUs 1206 to handle conditional operations, comparisons, and bitwise operations.

[0236] The processor 1200 may support wireless communication in accordance with examples as disclosed herein.

[0237] Figure 13 illustrates an example of a NE 1300 in accordance with aspects of the present disclosure. The NE 1300 may include a processor 1302, a memory 1304, a controller 1306, and a transceiver 1308. The processor 1302, the memory 1304, the controller 1306, or the transceiver 1308, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0238] The processor 1302, the memory 1304, the controller 1306, or the transceiver 1308, or various combinations or components thereof may be implemented in hardware (e.g., circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

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

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

[0241] In some implementations, the processor 1302 and the memory 1304 coupled with the processor 1302 may be configured to cause the NE 1300 to perform one or more of the functions described herein (e.g., executing, by the processor 1302, instructions stored in the memory 1304). For example, the processor 1302 may support wireless communication at the NE 1300 in accordance with examples as disclosed herein. The NE 1300 may be configured to support a means for receiving a Protocol Data Unit, PDU, set size threshold value, the PDU Set size threshold value determining a PDU Set size traffic characteristic for a service data flow; applying the PDU Set size threshold to PDU Sets of the service data flow, the service data flow being sent towards an RTP receiver, identifying a PDU Set size change between a first PDU Set and a second PDU Set of the service data flow, wherein the identifying is performed based upon the PDU Set size threshold value, wherein the second PDU Set size satisfies the PDU Set size threshold value; and transmitting the first PDU Set, the second PDU Set, and an indication of a dynamic PDU Set size change.

[0242] The NE 1300 may be alternatively configured to support a means for receiving, from a second network function, QoS requirements for PDU Set handling for a QoS flow; determining first scheduling resources to send PDUs of the QoS flow to a user equipment, UE, according to the received QoS requirements; receiving, from a first network function, a first PDU Set as a series of IP packets over an N3 interface for the QoS flow, the first PDU Set including an indication that an upcoming second PDU Set has a second PDU Set size, the second PDU Set size different to the first PDU Set size; receiving the second PDU Set; and determining second scheduling resources to accommodate the size of the second PDU Set and ensure that the second PDU Set is sent to the UE according to the received QoS requirements.

[0243] The controller 1306 may manage input and output signals for the NE 1300. The controller 1306 may also manage peripherals not integrated into the NE 1300. In some implementations, the controller 1306 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 1306 may be implemented as part of the processor 1302.

[0244] In some implementations, the NE 1300 may include at least one transceiver 1308. In some other implementations, 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.

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

[0246] A transmitter chain 1312 may be configured to generate and transmit signals (e.g., control information, data, packets). The 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 like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The 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 the wireless medium. The transmitter chain 1312 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0247] Figure 14 illustrates a flowchart of a method in accordance with aspects of the present disclosure. The operations of the method may be implemented by an RTP sender as described herein. In some implementations, the RTP sender may execute a set of instructions to control the function elements of the RTP sender to perform the described functions.

[0248] At 1402, the method may include receiving a Protocol Data Unit, PDU, set size threshold value, the PDU Set size threshold value determining a PDU Set size traffic characteristic for a service data flow. The operations of 1402 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1402 may be performed by an RTP sender as described with reference to Figure 13.

[0249] At 1404, the method may include applying the PDU Set size threshold value to PDU Sets of the service data flow, the applying comprising identifying a PDU Set size change between a first PDU Set and a second PDU Set of the PDU Sets of the service data flow, wherein the second PDU Set size satisfies the PDU Set size threshold value. The operations of 1404 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1404 may be performed by an RTP sender as described with reference to Figure 13. [0250] At 1406, the method may include transmitting the first PDU Set, the second PDU Set, and an indication of a dynamic PDU Set size change. The operations of 1406 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1406 may be performed an RTP sender as described with reference to Figure 13.

[0251] It should be noted that the method described herein describes A possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0252] Figure 15 illustrates a flowchart of a method in accordance with aspects of the present disclosure. The operations of the method may be implemented by a base station as described herein. In some implementations, the base station may execute a set of instructions to control the function elements of the base station to perform the described functions.

[0253] At 1502, the method may receiving, from a second network function, information that indicates a set of quality of service, QoS, requirements for handling protocol data unit, PDU, Sets for a QoS flow. The operations of 1502 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1502 may be performed by a base station as described with reference to Figure 13.

[0254] At 1504, the method may include determining a first set of resources, for transmission of the PDU Sets to a user equipment, UE, based at least in part on the set of received QoS requirements. The operations of 1504 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1504 may be performed by a base station as described with reference to Figure 13.

[0255] At 1506, the method may include receiving, from a first network function, a first PDU Set as a series of IP packets over a network interface for the QoS flow, the first PDU Set including an indication that an upcoming second PDU Set has a second PDU Set size, wherein the second PDU Set size is different to the first PDU Set size. The operations of 1506 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1506 may be performed a base station as described with reference to Figure 13.

[0256] At 1508, the method may include determining a second set of resources, for transmission of the second PDU Set to the UE, based at least in part on the set of QoS requirements, wherein the second set of resources support the second PDU Set size. The operations of 1508 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1508 may be performed by a base station as described with reference to Figure 13.

[0257] At 1510, the method may include receiving the second PDU Set. The operations of 1510 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1510 may be performed by a base station as described with reference to Figure 13.

[0258] At 1512, the method may include transmitting the second PDU Set to the UE according in part to the second set of resources. The operations of 1512 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1512 may be performed a base station as described with reference to Figure 13.

[0259] It should be noted that the method described herein describes A possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0260] The description herein is provided to enable a person having ordinary skill in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.

Claims

1. A Real-time Transport Protocol, RTP, sender for wireless communication, the RTP sender comprising: at least one memory; and at least one processor coupled with the at least one memory and arranged to cause the RTP sender to: receive a Protocol Data Unit, PDU, set size threshold value, the PDU Set size threshold value determining a PDU Set size traffic characteristic for a service data flow; apply the PDU Set size threshold value to PDU Sets of the service data flow, the applying comprising identifying a PDU Set size change between a first PDU Set and a second PDU Set of the PDU Sets of the service data flow, wherein the second PDU Set size satisfies the PDU Set size threshold value; and transmit the first PDU Set, the second PDU Set, and an indication of a dynamic PDU Set size change.

2. The RTP sender of claim 1, wherein, to apply the PDU Set size threshold value to the PDU Sets of the service data flow, the at least one processor is further arranged to cause the RTP sender to: buffer at least one PDU Set and determine if the buffered PDU Set satisfies the

PDU Set size threshold value; or pace one or more PDU Set transmissions, wherein each PDU Set determined by the RTP sender does not satisfy the PDU Set size threshold value.

3. The RTP sender of claim 1 or 2, wherein to apply the PDU Set size threshold value to the PDU Sets of the service data flow, the at least one processor is further arranged to cause the RTP sender to: buffer at least two PDU Sets of the PDU Sets of the service data flow and determine if each buffered PDU Set satisfies the PDU Set size threshold value.

4. The RTP sender of any of claims 1 to 3, wherein the at least one processor is further arranged to cause the RTP sender to: indicate the dynamic PDU Set size change upon determining that a buffered PDU Set satisfies the PDU Set size threshold value, the indicating comprising at least one of: split a PDU Set that satisfies the PDU Set size threshold value into two PDU Subsets, whereby the first PDU Subset contains of at least one PDU of the PDU Set and the second PDU Subset contains the remaining PDUs of the PDU Set; signal in the first PDU Set the indication of the dynamic PDU Set size change corresponding to the second PDU Set satisfying the PDU Set size threshold value, the first PDU Set being sent by the RTP sender before the second PDU Set is sent; and signal in a dummy PDU Set the indication of the dynamic PDU Set size change corresponding to the second PDU Set satisfying the PDU Set size threshold value, the dummy PDU Set being sent by the RTP sender before the second PDU Set is sent.

5. The RTP sender of claim 4, wherein a time interval between sending the indication of the dynamic PDU Set size change and the second PDU Set, is determined based on at least one of: a network exposed time interval configuration for the RTP sender; an RTP sender timing configuration based on multimedia service data flow characteristics; and/or a Service Level Agreement for the service data flow.

6. The RTP sender of claim 4 or 5, wherein the indication of the dynamic PDU Set size change comprises a PDU Set, the PDU Set further comprising at least one of: a flag field indicating that the PDU Set comprising the indication is a dummy PDU Set; a flag field indicating that the PDU Set comprising the indication is a PDU Subset; a timing field indicating the time interval between sending the PDU Set comprising the indication and the second PDU Set; a flag field indicating that the PDU Set comprising the indication carries information of the dynamic PDU Set size change; a flag field indicating that a next PDU Set has a PDU Set size that satisfies the PDU Set size threshold value; a PDU Set size field indicating the PDU Set size field of the next PDU Set, wherein the next PDU Set has a PDU Set size that satisfies the PDU Set size threshold value; an identifier field indicating a PDU Set Sequence Number of an upcoming PDU Set that has a PDU Set size that satisfies the PDU Set size threshold value; and a PDU Set size field indicating the PDU Set size field of the upcoming PDU Set that has a PDU Set size that satisfies the PDU Set size threshold value.

7. The RTP sender of claim 6, wherein the indication of the dynamic PDU Set size change is included in at least one of: an RTP header extension field for PDU Set marking; and/or an RTP header extension for dynamic traffic characteristics change.

8. The RTP sender of any of claims 1 to 7, wherein the PDU Set size threshold value is based on at least one of: a Service Level Agreement of the service data flow; a response to an Application Function request for a Session with Quality of Service, QoS, and dynamic traffic characteristics support posted on behalf of the RTP sender to a Policy Control Function, wherein the response comprises an acceptance of the Application Function request and additional information including the PDU Set size threshold value for determining dynamic traffic characteristics change; or an RTP sender configuration based on at least one of a set of available bit rates of a multimedia source of the PDU Sets, a maximum data burst value expected for the PDU Sets, and expected average and variance of PDU Sets; or a combination thereof.

9. A method performed by an RTP sender, the method comprising: receiving a Protocol Data Unit, PDU, set size threshold value, the PDU Set size threshold value determining a PDU Set size traffic characteristic for a service data flow; applying the PDU Set size threshold value to PDU Sets of the service data flow, the applying comprising identifying a PDU Set size change between a first PDU Set and a second PDU Set of the PDU Sets of the service data flow, wherein the second PDU Set size satisfies the PDU Set size threshold value; and transmitting the first PDU Set, the second PDU Set, and an indication of a dynamic PDU Set size change.

10. The method of claim 9, wherein applying the PDU Set size threshold value to the PDU Sets of the service data flow comprises: buffering at least one PDU Set and determining if the buffered PDU Set satisfies the PDU Set size threshold value; or pacing one or more PDU Set transmissions, wherein each PDU Set determined by the RTP sender does not satisfy the PDU Set size threshold value.

11. The method of claim 9 or 10, wherein applying the PDU Set size threshold value to the PDU Sets of the service data flow further comprises: buffering at least two PDU Sets of the PDU Sets of the service data flow and determining if each buffered PDU Set satisfies the PDU Set size threshold value.

12. The method of any of claims 9 to 11, further comprising: indicating the dynamic PDU Set size change upon determining that a buffered PDU Set satisfies the PDU Set size threshold value, the indicating comprising at least one of: splitting a PDU Set that satisfies the PDU Set size threshold value into two PDU Subsets, whereby the first PDU Subset contains of at least one PDU of the PDU Set and the second PDU Subset contains the remaining PDUs of the PDU Set; signalling in the first PDU Set the indication of the dynamic PDU Set size change corresponding to the second PDU Set satisfying the PDU Set size threshold value, the first PDU Set being sent by the RTP sender before the second PDU Set is sent; and signalling in a dummy PDU Set the indication of the dynamic PDU Set size change corresponding to the second PDU Set satisfying the PDU Set size threshold value, the dummy PDU Set being sent by the RTP sender before the second PDU Set is sent.

13. The method of claim 12, wherein a time interval between sending the indication of the dynamic PDU Set size change and the second PDU Set, is determined based on at least one of: a network exposed time interval configuration for the RTP sender; an RTP sender timing configuration based on multimedia service data flow characteristics; and/or a Service Level Agreement for the service data flow.

14. The method of claim 12 or 13, wherein the indication of the dynamic PDU Set size change comprises a PDU Set, the PDU Set further comprising at least one of: a flag field indicating that the PDU Set comprising the indication is a dummy PDU Set; a flag field indicating that the PDU Set comprising the indication is a PDU Subset; a timing field indicating the time interval between sending the PDU Set comprising the indication and the second PDU Set; a flag field indicating that the PDU Set comprising the indication carries information of the dynamic PDU Set size change; a flag field indicating that a next PDU Set has a PDU Set size that satisfies the PDU Set size threshold value; a PDU Set size field indicating the PDU Set size field of the next PDU Set, wherein the next PDU Set has a PDU Set size that satisfies the PDU Set size threshold value; an identifier field indicating a PDU Set Sequence Number of an upcoming PDU Set that has a PDU Set size that satisfies the PDU Set size threshold value; and a PDU Set size field indicating the PDU Set size field of the upcoming PDU Set that has a PDU Set size that satisfies the PDU Set size threshold value.

15. The method of claim 14, wherein the indication of the dynamic PDU Set size change is included in at least one of: an RTP header extension field for PDU Set marking; and/or an RTP header extension for dynamic traffic characteristics change.

16. A base station 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 base station to: receive, from a second network function, information that indicates a set of quality of service, QoS, requirements for handling protocol data unit, PDU, Sets for a QoS flow; determine a first set of resources, for transmission of the PDU Sets to a user equipment, UE, based at least in part on the set of QoS requirements; receive, from a first network function, a first PDU Set as a series of IP packets over a network interface for the QoS flow, the first PDU Set including an indication that an upcoming second PDU Set has a second PDU Set size, wherein the second PDU Set size is different to the first PDU Set size; determine a second set of resources, for transmission of the second PDU Set to the UE, based at least in part on the set of QoS requirements, wherein the second set of resources support the second PDU Set size; receive the second PDU Set from the first network function; and transmit the second PDU Set to the UE according in part to the second set of resources.

17. The base station of claim 16, wherein the QoS requirements comprise a PDU Set Delay Budget and a Maximum Data Burst Volume size.

18. The base station of claim 16 or 17, wherein the QoS requirements include one or more ranges of PDU Set size threshold.

19. The base station of any of claims 16 to 18, further arranged to receive an indication of PDU Set size change when a PDU Set size of an upcoming PDU Set is above a PDU Set size threshold value.

20. A method performed by a base station, the method comprising: receiving, from a second network function, information that indicates a set of quality of service, QoS, requirements for handling protocol data unit, PDU, Sets for a QoS flow; determining a first set of resources, for transmission of the PDU Sets to a user equipment, UE, based at least in part on the set of received QoS requirements; receiving, from a first network function, a first PDU Set as a series of IP packets over a network interface for the QoS flow, the first PDU Set including an indication that an upcoming second PDU Set has a second PDU Set size, wherein the second PDU Set size is different to the first PDU Set size; determining a second set of resources, for transmission of the second PDU Set to the UE, based at least in part on the set of QoS requirements, wherein the second set of resources support the second PDU Set size; receiving the second PDU Set from the first network function; and transmitting the second PDU Set to the UE according in part to the second set of resources.