Signaling application layer forward error correction configurations in a wireless communication network

Abstract

Various aspects of the present disclosure relate to a method (2200) performed by a first network function, comprising: determining (2202) a provisioning configuration comprising an indexed application layer forward error correction 'AL-FEC' configuration, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; and generating (2204), based at least in part on one or more AL-FEC configuration elements of the indexed AL-FEC configuration, a quality of service 'QoS' configuration for a media session, the media session comprising at least one AL-FEC encoded protocol data unit 'PDU' set.

Description

SIGNALING APPLICATION LAYER FORWARD ERROR CORRECTION CONFIGURATIONS IN A WIRELESS COMMUNICATION NETWORKTECHNICAL FIELD

[0001] The subject matter disclosed herein relates generally to the field of implementing signaling of application layer forward error correction (AL-FEC) configurations in a wireless communication network. In particular, this document defines a first network function for wireless communication, an application server for wireless communication, a user equipment for wireless communication, a processor for wireless communication, and methods performed by a first network function, application server, user equipment and processor.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 prefacedby 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 a first network function for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the first network function to: determine a provisioning configuration comprising an indexed application layer forward error correction (AL-FEC) configuration, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; and generate, based at least in part on one or more AL- FEC configuration elements of the indexed AL-FEC configuration, a quality of service (QoS) configuration for a media session, the media session comprising at least one AL-FEC encoded protocol data unit (PDU) set.

[0005] There is further provided an application server for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the application server to: receive one or more application data units (ADUs) of a media application; select, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; generate at least one protocol data unit (PDU) set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU; mark at least one header of the at least one PDU set to indicate a respective value for the index of the selected AL-FEC configuration element; and transmit the at least one PDU set to a network entity.

[0006] There is further provided a user equipment (UE) for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the user equipment to: receive one or more application data units (ADUs) of a media application; select, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; generate at least one protocol data unit (PDU) set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU; mark at least one header of the at least one PDU set to indicate a respective value for the index of the selected AL-FEC configuration element; and transmit the at least one PDU set to a network entity.

[0007] There is further provided a processor for wireless communication, comprising: at least one controller coupled with at least one memory and configured to cause the processor to: access one or more application data units (ADUs) of a media application; select, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; output at least one protocol data unit ‘PDU’ set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU; and output at least one header of the at least one PDU set to indicate a respective value for the index of the selected AL-FEC configuration element.

[0008] There is provided a method performed by a first network function, comprising: determining a provisioning configuration comprising an indexed application layer forward error correction (AL-FEC) configuration, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; and generating, based at least in part on one or more AL-FEC configuration elements of the indexed AL-FEC configuration, a quality of service (QoS) configuration for a media session, the media session comprising at least one AL-FEC encoded protocol data unit (PDU) set.

[0009] There is further provided a method performed by an application server, comprising: receiving one or more application data units (ADUs) of a media application;selecting, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; generating at least one protocol data unit (PDU) set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU; marking at least one header of the at least one PDU set to indicate a respective value for the index of the selected AL-FEC configuration element; and transmitting the at least one PDU set to a network entity.

[0010] There is further provided a method performed by a user equipment (UE) comprising: receiving one or more application data units (ADUs) of a media application; selecting, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; generating at least one protocol data unit (PDU) set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU; marking at least one header of the at least one PDU set to indicate a respective value for the index of the selected AL-FEC configuration element; and transmitting the at least one PDU set to a network entity.

[0011] There is further provided a method performed by a processor, comprising: accessing one or more application data units (ADUs) of a media application; selecting, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; outputting at least one protocol data unit (PDU) set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU; and outputting at least one header of the at least one PDU set to indicate a respective value for the index of the selected AL-FEC configuration element.BRIEF DESCRIPTION OF THE DRAWINGS

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

[0013] Figure 2 provides an overview of the RTP and RTCP stack in accordance with aspects of the present disclosure.

[0014] Figure 3 illustrates an overview of the WebRTC stack in accordance with aspects of the present disclosure.

[0015] Figures 4a and 4b illustrate a packet format and header information for a Real- Time Transport (RTP) packet and for a Secure Real-Time Transport (SRTP) packet respectively, in accordance with aspects of the present disclosure.

[0016] Figure 5 illustrates an overview of a core network extended reality media architecture handling of Protocol Data Unit (PDU) Sets, in accordance with aspects of the present disclosure.

[0017] Figure 6 illustrates a 1-byte RTP header extension for PDU Set marking by an application server, in accordance with aspects of the present disclosure.

[0018] Figure 7 illustrates a 2-byte RTP header extension for PDU Set marking by an application server, in accordance with aspects of the present disclosure.

[0019] Figures 8a to 8d illustrate 5GS PDU Set-aware QoS handling framework description of PDU Set to QoS flow to Data Radio Bearer (DRB) mappings, in accordance with aspects of the present disclosure.

[0020] Figure 9 presents the role of FECFRAME and application of various FEC coding schemes, in accordance with aspects of the present disclosure.

[0021] Figure 10 illustrates an RTC reference architecture for RTC media delivery, in accordance with aspects of the present disclosure.

[0022] Figure 11 illustrates a signaling workflow of dynamic selection of AL-FEC redundancy level based on an indexed AL-FEC configuration, in accordance with aspects of the present disclosure.

[0023] Figure 12 illustrates a 1-byte RTP header extension for PDU set marking including a PDU set redundancy index, in accordance with aspects of the present disclosure.

[0024] Figure 13 illustrates a 2-byte RTP header extension for PDU set marking including a PDU set redundancy index, in accordance with aspects of the present disclosure.

[0025] Figure 14 illustrates a PRI-bitmasked based PSI signaling of a PDU set redundancy index, in accordance with aspects of the present disclosure.

[0026] Figure 15 illustrates an example of a 1-byte RTP header extension for PDU set marking with PRI indication corresponding to an indexed AU-FEC configuration.

[0027] Figure 16 illustrates an example of a 2-byte RTP header extension for PDU set marking with PRI indication corresponding to an indexed AU-FEC configuration.

[0028] Figure 17 illustrates an example of a user equipment (UE) 1700 in accordance with aspects of the present disclosure.

[0029] Figure 18 illustrates an example of a processor 1800 in accordance with aspects of the present disclosure.

[0030] Figure 19 illustrates an example of a network equipment (NE) 1900 in accordance with aspects of the present disclosure.

[0031] Figure 20 illustrates a flowchart of a method 2000 performed by a UE in accordance with aspects of the present disclosure.

[0032] Figure 21 illustrates a flowchart of a method 2100 performed by a processor in accordance with aspects of the present disclosure.

[0033] Figure 22 illustrates a flowchart of a method 2200 performed by a NE in accordance with aspects of the present disclosure.

[0034] Figure 23 illustrates a flowchart of a method 2300 performed by a NE in accordance with aspects of the present disclosure.DETAILED DESCRIPTION

[0035] Application layer forward error correction (AL-FEC) is a technique that tends to enable robust transmission of data over a lossy network. The use of AL-FEC is particularly beneficial where a round-trip time (RTT) for transmission of data over a network exceedsan application or service requirement. An example is where data for an extended reality (XR) application or service is being transmitted with a particular delay budget, but the RTT for a network exceeds the delay budget. AL-FEC tends to enable such delay budgets to be met, even for increased RTT, by proactively adding redundancy to combat potential linklosses in the transmission path.

[0036] The efficiency of AL-FEC can be degraded in networks offering quality of service (QoS) guarantees in relation to meeting delay budgets and error rates. By way of example, the redundancy added by AL-FEC tends to consume available bandwidth in networks that would otherwise be available to an application, service or user group. Despite this, modern networks being of a heterogeneous nature (and partly unmanaged) cannot always be guaranteed to provide adequate service. Accordingly, AL-FEC is necessary despite the potential impact on QoS.

[0037] Accordingly, there is a requirement to dynamically control the additional bandwidth utilised by AL-FEC. This may be referred to herein as dynamically controlling the content-ratio or redundancy ratio of a media session using AL-FEC encoded content over a data flow.

[0038] The disclosure herein provides for an indexed signaling of available mapped and provisioned AL-FEC configurations. The AL-FEC indexed configurations that may be applied by an application function for a session may be provisioned in the control plane by an application server provider (ASP) to an application function (AF) as part of a provisioned policy template, or, as part of general provisioning session configuration for a service. The AF can decide based on the dynamic data traffic characteristics and observed network conditions at a given time, which AL-FEC configuration to use. The exposure of this information to a radio access network (RAN) through header information for a PDU set of a media session tends to allow the RAN to drop unnecessary or obsolete AL-FEC PDUs. In effect, this tends to enable an optimized and dynamic transmission of content by a RAN, improving overall system efficiency.

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

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

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

[0042] 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 someimplementations, 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.

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

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

[0045] 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).

[0046] The CN 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. The CN 106 may be anevolved 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.

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

[0048] 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 5 G 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.

[0049] 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 firstnumerology (e.g., / r=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., / r=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one slot per subframe. A second numerology (e.g., / r=l) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g., / r=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., / r=3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g., / r=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.

[0050] 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 1 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.

[0051] 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., / r=0, jU=l, / r=2, jU=3, / r=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 extendedcyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g., fi=O) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

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

[0053] 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., / r=0), which includes 15 kHz subcarrier spacing; a second numerology (e.g., jU=l), which includes 30 kHz subcarrier spacing; and a third numerology (e.g., / r=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., / r=2), which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g., / z=3 ), which includes 120 kHz subcarrier spacing.

[0054] The 3 GPP is currently studying enhancements to XR services support over the 3GPP network as part of the Release 19 study (FS XRM). For instance, XR and media service is discussed in the 3GPP Specification TR 23.700-70 Release 19 titled, “Study on architecture enhancement for Extended Reality and Media service (XRM); Phase 2”. One of the key issues currently in scope of the study is to determine the benefits of Application Layer Forward Error Correction (AL-FEC) awareness in the 5GS for XR traffic delivery.

[0055] The concept of a Protocol Data Unit Set (PDU Set) has been used to group a series of PDUs logically related by comprising the content of an application data unit (ADU). A PDU Set can thus be treated according to a same set of QoS requirements and associated constraints of delay budget and error rate while providing enhanced support to a radio access network (RAN) for differentiated Quality of Service (QoS) handling at PDU set level and with application-level content awareness. This improves the granularity of the legacy 5G QoS flow framework allowing the RAN to optimize the mapping between QoS flows and DRBs to meet challenging extended reality (XR) / cloud gaming (CG) media requirements (e.g., high-rate transmissions with short delay budgets).

[0056] A common content delivery approach of immersive and interactive media, such as in CG or virtual reality (VR), is the application of over-the-top Forward Error Correction (FEC), or alternatively AL-FEC. This allows for robust multimedia content delivery with low latency, enabling interactive applications with high bandwidth usage by avoiding higher layer retransmissions and combating proactively network losses.

[0057] There is a requirement for the configuration, signaling and control associated with the dynamic adaptation of media content ratio, or alternatively AL-FEC redundancy ratio, for the benefit of overall quality of experience (QoE) in dynamic wireless network multimedia communications. The dynamic control of content ratio is therefore a relevant and important problem both from the application, as well as the network perspective. The signaling necessary to realize efficiently said dynamic control with low overhead is a problem yet to be addressed.

[0058] The disclosure herein addresses the aspects of selecting and adapting an AL- FEC content ratio based on the real-time communications (RTC) endpoints involved in a RTC session signaling over the user plane the currently used content ratio, or alternatively redundancy ratio information, based on a provisioned indexed content ratio configuration for the RTC service. The content ratio configuration may be provided by an Application Service Provider (ASP) upon establishing an RTC session for one or more RTC endpoints and maps the index used in signaling to a desired content ratio for any of the PDU Sets of the RTC session.

[0059] 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 defined in the 3 GPP 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 (i.e., WebRTC 1.0: Real-Time Communication Between Browsers (w3.org)), or alternatively, on RTP (RFC 3550) / SRTP (RFC 3711) 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 Signalling” 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.

[0060] 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).

[0061] Furthermore, XR is referred to hereafter as an umbrella term for different types of realities (as indicated in the 3GPP Specification TR 23.700-60 (v0.0.3 May 2022) titled, “Study on XR (Extended Reality) and media services”, of which Virtual Reality, Augmented Reality, and Mixed Reality are examples.

[0062] 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 asimulated 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.

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

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

[0065] 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).

[0066] The XR video traffic is mainly composed of multiple DL / UL video streams of high resolution (e.g., at least 1080p dual-eye buffer usually), frames-per-second (e.g., 60+ fps) and high bandwidth (e.g., usually at least 20-30 Mbps) which need to be transmitted across a network with minimal delay (typically upper bounded by 10-15 ms) to maintain a reduced end-to-end application round-trip interaction delay and enable digital world immersion. The latter requirements are of critical importance given the XR application dependency on cloud / edge processing (e.g., content downloading / distribution, viewportconfiguration, generation and updates, media encoding / transcoding, viewport rendering etc.).

[0067] To support such stringent delay-critical requirements specific to real-time communications (RTC) with high bandwidth (e.g., XR video streams) an envisioned higher-layer protocol for delivery of XR immersive multimedia applications is RTP, as noted in the 3GPP Specification TR 26.928 (vl 7.0.0 April 2022) titled, “Extended Reality (XR) in 5G”. In some implementations, secured RTP variants such as vanilla SRTP or web browser based WebRTC stacks may be used to serve XR applications across mobile communications networks such as 5G System (5GS) and alike.

[0068] RTP is a media codec agnostic network protocol with application-layer framing used to deliver multimedia (e.g., audio, video etc.) in real-time over IP networks, cf. RFC 3550 - RTP: A Transport Protocol for Real-Time Applications (ietf.org). It is used in conjunction with a sister protocol for control RTCP to provide end-to-end features such as jitter compensation, packet loss and out-of-order delivery detection, synchronization and source streams multiplexing.

[0069] Figure 2 provides an overview of the RTP and RTCP stack. An IP layer 205 carries signalling from the data plane 210 and from the control plane 250. The data plane 210 stack comprises functions for a User Datagram Protocol (UDP) 212, RTP 216, RTCP 214, Media codecs 220 and quality control 222. The control plane 250 stack comprises functions for UDP 252, Transmission Control Protocol (TCP) 254, Session Initiation Protocol (SIP) 262 and Session Description Protocol (SDP) 264.

[0070] SRTP is a secured version of RTP, cf. RFC 3711 - The Secure Real-time Transport Protocol (SRTP) (ietf.org), providing encryption (payload confidentiality), message authentication and integrity (header and payload signing), replay attack protection. Similarly, the SRTP sister protocol SRTCP provides the same functions to the RTCP counterpart. As such, in SRTP, the RTP header information is still accessible but non- modifiable, whereas the payload is encrypted. SRTP is used for this reason in the WebRTC stack which ensures secure RTC multimedia communications over web browser interfaces.

[0071] An overview of the WebRTC stack is provided in Figure 3. As illustrated, an IP layer 305 carries signalling from the data plane 310 and the control plane 350. The data plane 310 stack comprises functions for User Datagram Protocol (UDP) 312, Interactive Connectivity Establishment (ICE) 324, Datagram Transport Layer Security (DTLS) 326, SRTP 317, SRTCP 315, media codecs 320, Quality Control 322 and Stream Control Transmission Protocol (SCTP) 328. ICE 324 may use the Session Traversal Utilities for NAT (STUN) protocol and Traversal Using Relays around NAT (TURN) to address realtime media content delivery across heterogeneous networks and NAT rules and firewalls. Regarding real time transport of information the data carried over the SCTP 328 data plane is mainly dedicated as an application data channel and may be non-time critical. The SRTP 317 based stack and elements of control, i.e., SRTCP 315, encoding, i.e., media codecs, and Quality of Service (QoS), i.e., Quality Control, are dedicated to time-critical transport. The control plane 350 stack comprises functions for Transmission Control Protocol (TCP) 354, Transport Layer Security (TLS) 356, Hypertext Transfer Protocol (HTTP) 358, WebSocket 366, Session Initiation Protocol (SIP) 362, Session Description Protocol (SDP) 364, Server- sent Events (SSE) 368 and Extensible Messaging and Presence Protocol (XMPP) 370.

[0072] As for both RTP and SRTP the header information is available for inspection and processing, an overview is provided below in Figure 4 together with a brief description of the individual fields. Figures 4a and 4b outlines the RTP / SRTP header information as being comprised of a fixed header information containing of first 12 bytes of the header information, and an additional header information about Contributing Source (CSRC) identifiers of the media flow and optional RTP extension headers.

[0073] Figure 4a illustrates a packet format and header information for an RTP packet 430 and Figure 4b illustrates a packet format and header information for an SRTP packet 460. The individual fixed header information and complete header information (including header extensions) is discussed for the RTP / SRTP packets further below. It can be noted that the Fixed Header Info comprises “V” 432, 462, “P” 433, 463, “X” 434, 464, “CC” 436, 466, “M” 438, 468, “PT” 440, 470, “Sequence number” 442, 472, “Timestamp” 444, 474, “Synchronization Source (SSRC) identifier” 446, 476, and “Contributing Source (CSRC) identifier” 448, 478.

[0074] ‘V” 432, 462 is 2 bits indicating the protocol version used.

[0075] “P” 433, 463 is a 1 bit field indicating that one or more zero-padded octets at the end of the payload are present, whereby, among others, the padding may be necessary for fixed-sized encrypted blocks or for carrying multiple RTP / SRTP packets over lower layer protocols.

[0076] “X” 434, 464 is a 1 bit indicating that the standard fixed RTP / SRTP header will be followed by an RTP header extension usually associated with a particular data / profile that will carry more information about the data (e.g., the frame marking RTP header extension for video data (as defined in IETF RFC 3711 - The Secure Real-time Transport Protocol (SRTP)), or generic RTP header extensions such as the RTP / SRTP extended protocol (as defined by w3.org in WebRTC 1.0: Real-Time Communication Between Browsers)).

[0077] ‘CC” 436, 466 is a 4 bit field indicating number of contributing media sources (CSRC) that follow the fixed header

[0078] ‘M” 438, 468 is 1 bit intended to mark an information frame boundary in the packet stream, whose behaviour is exactly specified by RTP profiles (e.g., H.264, H.265, H.266, AVI etc.)

[0079] “PT” 440, 470 is 4 bits indicating the payload type, which in case of video profiles is dynamic and negotiated by means of SDP (e.g., 96 for H.264, 97 for H.265, 98 for AVI etc.)

[0080] “Sequence number” 442, 472 is 16 bits indicating the sequence number which increments by one with each RTP data packet sent over a session.

[0081] “Timestamp” 444, 474 is 32 bits indicating timestamp in ticks of the payload type clock reflecting the sampling instant of the first octet of the RTP data packet (associated for video stream with a video frame), whereas the first timestamp of the first RTP packet is selected at random.

[0082] “Synchronization Source (SSRC) identifier” 446, 476 is a 32 bit field indicating a random identifier for the source of a stream of RTP packets forming a part of the sametiming and sequence number space, such that a receiver may group packets based on synchronization source for playback.

[0083] “Contributing Source (CSRC) identifier” 448, 478 is a list of up to 16 CSRC items of 32 bits each given the amount of CSRC mixed by RTP mixers within the current payload as signalled by the CC bits; the list identifies the contributing sources for the payload contained in this packet given the SSRC identifiers of the contributing sources.

[0084] The complete Header Information (incl. header extensions) comprises “RTP header extension” 448, 478.

[0085] “RTP header extension” 448, 478 is a variable length field present if the X bit is marked; the header extension is appended to the RTP fixed header information after the CSRC list if present; the RTP header extension is 32-bit aligned and formed of the following fields:

[0086] A 16-bit extension identifier defined by a profile and usually negotiated and determined via the Session Description Protocol (SDP) signalling mechanism;

[0087] A 16-bit length field describing the extension header length in 32-bits multiples excluding the first 32 bits corresponding to the 16 bits extension identifier and the 16 bits length fields itself; and

[0088] A 32-bit aligned header extension raw data field formatted according to some RTP header extension identifier specified format.

[0089] Herein a video frame may be referred to as a video coded representation of a still image presented in a sequence composing a video stream. On the other hand, a video frame may be composed of one or more video slices. A video slice is a coded video representation of a partition of a still image part of a video sequence. In some implementations video slices may be referred to as rectangular partitions (e.g., tiles) of the still image (e.g., H.266, AVI), whereby in other implementations video slices may be raster scan partitions of the still image (e.g., H.264, H.265, H.266 etc.). Similarly, we refer to a video layer as a video coding element either as a temporal video layer meant to increase the frames per second resolution and temporal level of details of a video sequence or as aspatial video layer meant to increase the number of video coded pixels and spatial resolution of individual video frames of a video sequence. The abstract concepts of video frame, video slice and / or video layers are applicable to MPEG family of modern hybrid video codecs (i.e., H.264 / H.265 / H.266), as well as other open video codecs such as AVI or VP9. The encapsulation format of video coded data to RTP / SRTP payloads is specified by Internet Standards for each individual video codec, e.g., H.264 by RFC 6184, H.265 by RFC 7798, AVI by RTP Payload Format For AVI (aomediacodec.github.io).

[0090] Note that for an XR application the media codecs used, and their configuration / configuration updates depend on the application implementation, and these are usually negotiated between a sender and a receiver upon session establishment / session update (e.g., RTP / SRTP). To this end, Session Description Protocol (SDP) signalling is used either as standalone signalling procedure or as part of the Session Initiation Protocol (SIP).

[0091] The XR Media (XRM) feature in 3 GPP 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 5GRel-17 QoS flow possibilities. As such, according to 3 GPP Technical Report TR 23.700-60 (v0.0.3 May 2022) titled, “Study on XR (Extended Reality) and media services” and 3GPP Technical Report TR 23.501 (vl8.4.0 December 2023) titled, “System Architecture for the 5G System”, 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.

[0092] 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 the 3GPP Technical Report TR 23.501 (vl8.4.0 December 2023) titled, “System Architecture for the 5G System”. 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-Setreceived 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.

[0093] Furthermore, per QoS flow PDU Sets may be configured with a PDU Set Integrated Handling Information (PSIHI), which indicates whether all the PDUs of the PDU Sets of the flow are needed for the usage of the PDU Set by the XR application, cf. 3GPP Technical Report TR 23.501 (vl8.4.0 December 2023) titled, “System Architecture for the 5G System”.

[0094] Figure 5 illustrates an overview of a core network (CN) XRM architecture handling of PDU Sets. Figure 5 shows a system 500 comprising an Extended Reality Media Application Function (XRM AF) 510, a Policy and Control Function (PCF) 515, a Session Management Function (SMF) 520, an Access and Mobility Function (AMF) 525, a Radio Access Network (RAN) 530, a User Equipment (UE) 535, a User Plane Function (UPF) 540, and an Extended Reality Application 545. The operation of system 500 will now be described in the example of downlink traffic, a similar process may operate for uplink traffic.

[0095] At 580, the XRM AF 510 determines PDU-set requirements.

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

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

[0098] At 583, the SMF 520 establishes a QoS flow according to the QoS rules by the PCF 515 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 520 also provides the QoS profile containing PDU Set QoS requirements to the RAN 530 via the AMF 525. The AMF 525 may provide the QoS profile containing PDU Set QoS requirements to the RAN 530 in an N2 SM container. Further, the AMF 525 may provide the QoS rules to the UE 535 in an N 1 SM container.

[0099] At 584, the UPF 540 inspects the packets and determines packets belonging to a PDU Set. Such a determination may be based on UPF implementation given, for instance by inspecting the RTP packet headers , as described in 3GPP Technical Specification 23.501 (vl8.4.0 - December 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 described in 3GPP TS 23.501 vl8.4.0 and 3GPP Technical Specification 26.522 (vO.2.1 Sep 2023) titled "5G Real-time Media Transport Protocol Configurations" i.e., urn:3gpp:pdu-set-marking:rel-18. The packet inspection may comprise inspecting the RTP packets. When the UPF 540 detects packets of a PDU Set the UPF 540 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 540 may also determine the importance of the PDU Set either based on UPF 540 implementation means, information provided by the XRM AF 510 or information provided as metadata from an XRM application server. Based on the importance of the PDU Set the UPF 540 may route the traffic to a corresponding QoS flow 1 (according to the rules received from the SMF 520) 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.

[0100] At 585, the RAN 530 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 520. In one implementation the RAN 530 node may use a different radio bearer with higher QoS requirement (according to thePDU 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.

[0101] However, in XRM Release 18, i.e. 3GPP Technical Specification TS 23.501 vl8.4.0 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.

[0102] 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.• PDU Set Importance, which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS Flow.

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

[0104] The NG-RAN may use Priority Levels as of across QoS Flows and PDU Set Importance within a QoS Flow for PDU Set level packet discarding in presence of congestion. Such Priority Levels are described in 3GPP TS 23.501 vl8.4.0 clause 5.7.3.3.

[0105] It is also specified in 3GPP TS 23.501 vl 8.4.0 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), 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 examples on pre-configuration and in other examples on an AS / AF signalled default importance.

[0106] The Protocol Description indicates the transport protocol used by the service data flow (e.g., RTP, SRTP) and additional information, such as:• RTP or SRTP;• RTP or SRTP with RTP Header Extensions, including:• RTP Header Extensions for PDU Set Marking as defined in RFC 3550 - RTP: A Transport Protocol for Real-Time Applications (ietf.org) and shown in Figure 6 or Figure 7, disucssed in detail below.• Other RTP Header Extensions based on RFC 8285 formats;• RTP or SRTP without RTP Header Extensions, but together with RTP Payload Format (e.g. H.264 or H.265);• RTP or SRTP with RTP Header Extensions for PDU Set Marking as defined in RFC 3550 “RTP: A Transport Protocol for Real-Time Applications” (ietf.org) and shown in Figure 5 or Figure 6, and together with RTP Payload Format (e.g. H.264 or H.265); and / or• RTP or SRTP with other RTP Header Extensions based on RFC8285 formats, and together with RTP Payload Format (e.g. H.264 or H.265).

[0107] When RTP Header Extensions for PDU Set Marking (as defined in RFC 3550 - RTP: A Transport Protocol for Real-Time Applications (ietf.org) or other RTP header extensions based on RFC 8285 are included, the differentiation between different RTP Header Extension Types may be supported. In addition, when RTP Payload Format is included, the differentiation between different RTP Payload Formats may be supported.

[0108] The AS PDU Set information listed above is provided in some embodiments via a RTP Header Extension for the marking of PDU Sets, e.g., US provisional application 63 / 478,932 titled “MULTIMEDIA SUBPROTOCOLS OVER REAL TIME PROTOCOL” by Stoica et al., Applicant’s reference SMM920220218-US-PSP. In addition, the PDU Set information may further include in an End of Data Burst indication, as defined by 3 GPP Technical Specification TS 26.522 vl8.0.0 (Mar 2024), titled “5G Real-time Media Transport Protocol Configurations”.

[0109] Figure 6 illustrates a 1-byte RTP header extension for PDU Set marking by the AS as per 3GPP TS 26.522 v!8.0.0.

[0110] Similarly, figure 7 illustrates a 2-byte RTP header extension for PDU Set marking by the AS as per 3GPP TS 26.522 vl8.0.0.

[0111] The semantics of the fields denoted in Figure 6 and Figure 7 of the RTP Header Extension for the marking of PDU Set and End of Bursts are as follows.

[0112] End PDU of the PDU Set [E] (1 bit field) 632, 732 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.

[0113] Reserved [R] (2 bits field) 633, 733 is reserved for future use.

[0114] End of Data Burst [D] (1 bit field) 634, 734 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.

[0115] PDU Set Importance [PSI] (4 bits field) 635, 735 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 1 and the lowest importance PDU Set of 15. A PSI value of 0 provides no information about the PDU Set importance and may be used when the importance of a PDU Set cannot be determined or is unknown.

[0116] PDU Set Sequence Number [PSSN] (10 bits field) 636, 736 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.

[0117] PDU Sequence Number within a PDU Set [PSN] (6 bits field) 637, 737 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.

[0118] PDU Set Size [PSSize] (24 bits field) 638, 738 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 thesize of a PDU Set including RTP / UDP / IP header encapsulation overhead of its corresponding PDUs. The PSSize is expressed in bytes.

[0119] Number of PDUs in the PDU Set [NPDS] (16 bits) 639, 739 is the number of PDUs within the PDU Set indicates the total number of PDUs belonging to the same PDU Set. This field is optional and subject to an SDP signalling offer / answer negotiation, where the Application Server 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.

[0120] The above examples relate to downlink (DL) traffic. Reciprocal processing is applicable to UL whereas the role of UPF packet inspection is taken by the user equipment (UE) which is expected to inspect packets, determine packets belonging to a PDU Set, and signal accordingly the PDU Set to the RAN for scheduling and resource allocation corresponding to an associated DRB 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 and rely on buffer status reporting (BSR) and delay status reporting (DSR) procedures.

[0121] Figures 8a to 8d 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 8 illustrates some options where two PDU Sets 810 of different importance and characteristics are mapped to QoS flows 820 and respectively to Data Radio Bearers (DRBs) 830. 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 8, the PDU Set 810 to QoS flow 820 to DRB 830 can take the following instantiations depending on QoS flow policies and Layer 2 RAN procedures.

[0122] Figure 8a illustrates 1-to-l-to-l mapping: whereby the separation of QoS flows 820 and DRBs 830 is complete between high and low importance PDU Sets 810 optimizing finely the radio and network resources on a per PDU Set basis.

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

[0124] Figure 8c illustrates M-to-l-to-1 mapping: whereby there is no separation between the QoS flows 820 and DRBs 830 of different importance PDU Sets 810 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 810 in both CN and RAN implementations but requires lower overhead and control within the 5GS QoS framework.

[0125] Figure 8d illustrates M-to-l-to-M mapping: whereby there is no separation across the QoS flows 820 between PDU Set importance levels, yet distinct DRBs 830 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 810 on different DRBs 830 in order to better match the QoS requirements at RAN level and optimize resource allocation according to individual PDU Set needs.

[0126] In various interactive XR applications application-level forward error correction (AL-FEC) might be used as a method to combat congestion and packet loss. This use exploits multicast, broadcast topologies as well as unicast path diversity either at the network routing level or at the physical layer (e.g., in 5GS this would be applicable to dual connectivity (DC), carrier aggregation (CA) as well as multi-TRP transmissions). This applies for instance to 1D / 2D parity check codes (e.g. RFC 8627), Raptor codes (e.g., RFC 5032), RaptorQ codes (e.g., RFC 6330), and LDPC staircase codes (e.g., RFC 6816).

[0127] A generic forward error correction framework (FECFRAME) has been defined by IETF as RFC 6363 which allows for various FEC Schemes to be applied for AL-FEC.FECFRAME specifies source packet and repair packet formats and FEC Scheme configuration procedures for AL-FEC both over transport layer (e.g., UDP), as well as over RTP layer or alike (e.g., WebRTC).

[0128] FECFRAME operates consequently on application data units (ADU), e.g., RTP packets in case RTP is used for encapsulation of media information units.

[0129] Figure 9 presents the role of FECFRAME and application of various FEC coding schemes, and shows the encoding and packetization procedures associated with the FECFRAME framework. Figure 9 provides an illustration of an AL-FEC XR application flow 900 including encoding, packetization and transport. The AL-FEC XR application flow 900 is performed at a sender by an application 910, a FECFRAME block 920, a transport layer 930, and a FEC Scheme 940. The transport layer 930 may use the User Datagram Protocol (UDP).

[0130] In some embodiments, a popular AL-FEC coding scheme given its efficient encoding / decoding is Raptor coding (RFC 5032), or alternatively, in other embodiments, its optimized version RaptorQ coding (RFC 6330). Applied in the context of FECFRAME Raptor / RaptorQ encodes RTP packets as per RFC 6881 and RFC 6882. The FEC Scheme 940 may comprise Raptor, or RaptorQ. The AL-FEC XR application flow 900 comprises the following steps.

[0131] At 971, an application 910 generates a set of one or more ADUs. The ADUs comprise media content. The media content may comprise video, audio, haptic, text or general application data. The media content is served by the application towards a remote endpoint. The remote endpoint may be a receiver. The ADUs may be packetized according to a content delivery protocol. The content delivery protocol may be RTP, or alternatively SRTP, and each ADU may comprise one or more RTP packets.

[0132] At 972, a the ADUs are processed by a 920 FECFRAME sender which determines a set of source packets (e.g., RTP source packets) representing an ADU as a source block, to be protected jointly based on an AL-FEC coding configuration (e.g., the FECFRAME Configuration Information containing• a FEC Scheme identifier,• a maximum source block length (MSBL) or alternatively K max for Raptor / RaptorQ,• an encoding symbol size (i.e., a T parameter for Raptor / RaptorQ coding schemes),• a repair- window duration (i.e., a maximum time in milliseconds and / or microseconds that spans the transmission of the source packets and the corresponding repair packets, whereby the transmission point is considered to be downstream interface ingesting encoded PDUs post-encoding)).

[0133] At 972, the sender further arranges the source packets (e.g., the RTP source packets) to construct a set of same-sized source symbols. The construction of source symbols may comprise partitioning of source data packets into source symbols of a configured size. Each source symbol may have the same configured size. The set of source symbols forms the source block for AL-FEC encoding.

[0134] At 973, the FECFRAME sender 920 inputs the constructed source block to the FEC encoder encoding with the FEC Scheme 940.

[0135] At 974, the sender applies FEC encoding scheme (e.g., Raptor / RaptorQ, Reed- Solomon codes, 2D parity codes etc.) according to the AL-FEC configuration (e.g., FECFRAME Configuration Information) to generate and construct the required number of repair symbols.

[0136] At 975, the repair symbols generated by the FEC Scheme 940 are input to the FECFRAME sender 920 for packetization. The repair symbols are complemented by metadata related to the AL-FEC configuration, representing information elements of the FEC Scheme applied at encoding. The metadata may be FECFRAME specific and may contain source FEC Payload IDs, repair FEC Payload IDs, or alternatively an Encoding Symbol ID (ESI). The metadata may further contain the size of the symbol block, or alternatively the number of source symbols and a common transport object identifier for the source and repair symbols.

[0137] At 976, the sender performs packetization of the repair symbols into repair packets (e.g., RTP repair packets according to RFC 6882) and sends the repair packets and the source packets for transmission over a packet network to a receiver. The sourcesymbols may be repacketized in some implementations into source packets including new metadata related to the AL-FEC configuration. Other implementations may reuse the original source packets and only provide the metadata related to the AL-FEC configuration for the repair packets to aid a receiver to decode the AL-FEC encoded content. As an example, the original RTP packets as the source packets may be transmitted with the corresponding RTP repair packets produced by the AL-FEC encoding. The RTP repair packets may reference the RTP source packets by means of the metadata related to the AL- FEC configuration (e.g., FEC Payload ID, ESI, common transport object identifier, etc.).

[0138] At 977, the FECFRAME sender releases the AL-FEC encoded source and repair packets to a lower transport layer 930 for transmission to a receiver. The AL-FEC encoded source and repair packets may be RTP packets and the lower transport layer may be UDP, or TCP. Under FECFRAME requirements (i.e., RFC 6363), the sender may transmit the source and repair packets in different source and repair flows, e.g., RTP streams, to allow for legacy (non-FEC) applications processing of source packets similar to any systematic code. However, the sender may also use FECFRAME to transmit the source and repair packets jointly within the same data flow (e.g., same RTP session over a single UDP port), multiplexing the source and repair RTP streams.

[0139] The receiver receives over the transport layer source and repair packets.

[0140] If all the source packets are successfully received, no FEC recovery is needed and the FEC repair packets can be discarded.

[0141] If there are however missing source packets the repair packets can be processed and used to recover the lost information within a latency corresponding to at least a repairwindow time configured by the application FEC configuration.

[0142] For example, it may be required that ADU source PDUs (e.g., the source RTP PDUs) contain an additional footer representing a Payload ID. This may then be used on the receiver side to determine if an encoded PDU is lost and to aid selection and usage of proper recovery slot for decoding missing packets based on the encoded available PDUs, i.e., either source or repair PDUs. In many embodiments where RTP / SRTP is used, this information is readily available as part of the RTP / SRTP sequence number which acts as aPayload ID replacement. In such implementations the source RTP / SRTP packets resulting from a FECFRAME encoding are sent unchanged similarly to any systematic coding procedure. This provides backwards compatibility to receivers not supporting AL-FEC for example. For instance, a scheme used to encode the source and repair PDUs as RTP / SRTP packets may be using therefore the sequence number of the original RTP / SRTP source packets as a Pay load ID replacement (e.g., for Raptor / RaptorQ code, in Single Sequenced Flow encoding mode according to RFC 6681). This indicates thus the dependency of encoded repair RTP / SRTP packets to the block of RTP / SRTP source packets jointly encoded aiding the decoder endpoint in efficient decoding.

[0143] Alternatively, other generic AL-FEC based content delivery protocols may be considered in alignment with RFC 5052, i.e., the Forward Error Correction (FEC) Building Block. Similar to the FECFRAME scheme, the Application Data Units (ADUs) are not sent directly to the network but are added to a source block AL-FEC encoder. The encoder systematically encodes and generates packets of equal size, including repair packets, to add redundancy and then distribute the content. The ADU (e.g., a video frame, a video slice, or alternatively a generic object) has assigned some size F and some additional properties (e.g., the type of the ADU - video, audio, etc., its importance, its delay constraints etc.). The ADU is split into a source block with K encoding symbols, each of size T. The encoding symbols form the payloads of the K source packets, whereby each repair packet generated up to a desired set of N-K repair packets include the source block size K, the Encoding Symbol Id (ESI). Each of the repair packets may further include some of the ADU and encoding operation properties (e.g., additional encoding parameters needed to construct a certain repair packet etc.). In addition, the size F of the ADU may be carried as part of the source block. As such, the K source packets, and the N-K repair packets constitute the AL-FEC encoded content of the ADU and may be sent and treated commonly as the same ADU. The source and repair packets would share therefore a common Transport Object Identifier (TOI). Parameters F, K, T and N are AL-FEC encoding parameters.

[0144] The FEC Pay load ID (i.e., the information carried in every packet header), essentially only requires carrying the ESI and the source block size K given T is fixed. Asan example, for RaptorQ as defined in IETF RFC 6330 by M. Luby et al and titled “RaptorQ Forward Error Correction Scheme for Object Delivery” August 2011, the maximum source block size is 56403, i.e., 16 bits are sufficient to encode the size of K. It is also expected that to signal the ESI, 1 or 2 bytes would be sufficient for most applications. Additionally, a TOI may be carried as clarified above, again using 1 or 2 bytes. While the above FEC configuration only serves as one reference, it may be considered as a typical implementation.

[0145] Generally, at a receiver, if one or more packets associated with the ADU are lost a maximum delay of an ADU needs to be set, typically compared to the render time, after which only received packets are processed as part of the ADU. In case of Maximum Distance Separable (MDS) codes, i.e., the ones that meet the Singleton Bound such as Reed-Solomon codes, alternatively the Raptor codes family, if at least K packets are received for an ADU within the time budget, the ADU can be fully recovered. If less than K packets are received, the ADU cannot be recovered and one of the following two error handling modes may be applied upon configuration:• ADU loss: If more than N-K of the packets associated to the ADU are lost, the entire ADU is lost.• Suffix loss: If more than N-K of the packets associated to the ADU are lost, then only the correct prefix preceding the first loss of a source packet is used to generate a partially received ADU.

[0146] Raptor / RaptorQ FEC Scheme recovery properties determine that recovery of K encoded source packets is possible from any K + h coded source or repair packets with a probability 1 —256h+1, whereby an encoded symbol corresponds to an encoded packet. This implies that recovering K encoded source symbols from a set of N encoded source and repair packets where only K + 1 encoded packets have been received is essentially 99.99%, i.e., very large. In other embodiments, whereby an encoded packet corresponds to more than one encoded symbol, a high probability of recovery is maintained also after packetization thus allowing Raptor / RaptorQ codes to achieve strong error correction performance.

[0147] Based on the above, when ADU is systematically AL-FEC encoded, a PDU Set is formed of the source PDUs corresponding to the original, non-encoded ADU, and their corresponding repair PDUs as described for instance in Greek Patent Application Number 20220100751 to Stoica et al., [Applicants ref: SMM920220119-GR-NP] - “Efficient Transmission of PDU Sets in a Wireless Communication Network”. In case of non- systematic AL-FEC schemes, the PDU Set is formed of the AL-FEC encoded ADU, including its parity, or alternatively repair / redundant PDUs.

[0148] If the RAN is PDU Set-aware and AL-FEC-aware the RAN may dynamically optimize system capacity and delivery of PDU Sets comprising AL-FEC encoded ADUs by dropping irrelevant or redundant content. For instance, in case of congestion, or alternatively when activated for a QoS flow, the RAN may drop up to N-K PDUs of an AL- FEC encoded PDU Set up without compromising the recovery of the PDU Set payload. Similarly, the RAN may drop all PDUs of a PDU Set comprising an AL-FEC encoded ADU when it detects it cannot transmit any PDUs accounting to at least K PDUs, wherein K represents the number of sources, or alternatively content, PDUs and N-K represents the number of repair, or alternatively redundant, PDUs. Such RAN policies and associated signaling and procedures are described relative to the 5G system within Greek Patent Application Number 20220100751 [Applicants ref: SMM920220119-GR-NP] and Greek Patent Application Number 20240100017 [Applicants ref: SMM920230182-GR-NP].

[0149] As previously introduced, AL-FEC is a useful tool to robustly transmit data with low-latency over a lossy network when the round-trip time (RTT) exceeds service or application requirements. By way of example, the RTT may be of at least 40 ms, whereas an application, such as CG or immersive XR, may require video delivery with a delay budget of 20 ms. AL-FEC tends to ensure such low delay budgets are met even with increased RTT by proactively adding redundancy to combat any potential link losses on the transmission path between the endpoints. Yet, AL-FEC efficiency decays in managed networks which offer QoS guarantees related to meeting delay budgets and error rates. The redundancy added by AL-FEC consumes, unnecessarily in such networks, available bandwidth that would otherwise be available for other users, or more importantly, for the service or application protected by AL-FEC to improve the QoE of the service.Nonetheless, end-to-end (E2E) modern networks are heterogeneous, partly unmanaged and cannot always provide service guarantees. For instance, this would be applicable to data networks (e.g., CDNs, cloud networks), or alternatively last-mile local networks (e.g., wired / wireless local area networks, personal / body area networks, wired / wireless tethering links). As such, the dynamic control of the content ratio, or alternatively redundancy ratio, associated with AL-FEC encoded content over a data flow is useful to exploit available bandwidth in managed network segments, yet provide enough redundancy to counter potential losses in unmanaged network segments. Efficiently exposing and signaling the dynamic AL-FEC content / redundancy ratio used to a managed RAN such that the latter can optimize transmission over-the-air of the AL-FEC encoded traffic is therefore of interest for overall system efficiency.

[0150] To enable applications to dynamically select and apply different AL-FEC configurations and exploit the available bandwidth to the benefit of optimized QoE, while ensuring RAN awareness of AL-FEC, an indexed signaling out of an available mapped and provisioned AL-FEC configuration is proposed. The AL-FEC indexed configurations that may be applied by an application for the session may be provisioned in the control plane by the ASP to the media AF as part of a policy templates provisioning, or alternatively, of a general provisioning sessions configuration for the service. The application can decide based on the dynamic data traffic characteristics and network conditions observed over the user plane which AL-FEC configuration to use out of the available ones. The exposure of this information to the RAN, allowing the RAN to drop unnecessary (i.e., obsolete) AL- FEC PDUs (e.g., in case of congestion, or alternatively, upon configuration by an MNO) is performed in the user plane by signaling comprised in the RTP HE for PDU Set marking. This enables in effect an application domain dynamic AL-FEC control / controller that can determine the AL-FEC content / redundancy ratio based on dynamic operating conditions and traffic characteristics up to its implementation.

[0151] The disclosure herein provides provisioning configuration and signaling necessary for dynamic AL-FEC control of the AL-FEC redundancy level to the benefit of QoE, whilst still considering any active discarding the RAN may perform given the redundant traffic. The disclosure herein uses an AL-FEC indexed configuration mappingthe AL-FEC configuration elements (such as content ratio or redundancy ratio) of AL-FEC from the RTP source endpoint. The RTP source endpoint can use the mapping to dynamically select and indicate the AL-FEC configuration (i.e., content / redundancy ratio) for on a PDU Set basis based on the available PDU Set marking RTP HE. The AL-FEC content / redundancy ratio signaling in the PDU Set marking RTP HE may be signaled in different ways, i.e., a separate information field within the fixed part of the RTP HE for PDU Set marking, a bitmasked information part of the PSI information field, an information field as an extension to the PDU Set marking.

[0152] Figure 10 illustrates an RTC reference architecture 1000 for RTC media delivery, in accordance with aspects of the present disclosure.

[0153] The general reference architecture comprises a UE 1010 as part of a 5GS. The UE 1010 may comprise an external native web RTC application 1012, an external web application 1014, an RTC media session handler (MSH) 1016 and an RTC access function 1018. The native Web RTC application 1012 interface with the RTC MSH 1016 is shown as ‘RTC-6’ and the interface with RTC access function 1018 is shown as ‘RTC-7’. The web application 1014 interface with the RTC access function 1018 is shown as using a WebRTC API. The RTC MSH 1016 interface with the RTC access function 1018 is shown as ‘RTC- 11’. The RTC access function 1018 comprises a WebRTC framework. The RTC access function 1018 and the RTC MSH 1016 are collectively an RTC endpoint.

[0154] The general reference architecture also includes a PCF 1020, a NEF 1030 and an SMF 1040 as part of the 5GS.

[0155] The general reference architecture also includes an RTC AF 1050. The RTC AF 1050 includes a network support application function (NS-AF) 1052, a configuration function 1054 and a provisioning function 1056. The PCF 1020, NEF 1020 and SMF 1040 interface with the RTC AF 1050. The RTC AF 1050 interfaces with RTC MSH 1016 over an interface shown as ‘RTC-5’.

[0156] The general reference architecture also includes an RTC AS 1060. The RTC AS 1060 comprises an ICE function 1061, a media function (comprising a WebRTC framework) 1062, a transport gateway function 1063, a WebRTC signalling function 1064,an application supporting web function 1065 and an interworking function 1066. The RTC AS 1060 interfaces with the RTC access function 1018, said interface labelled ‘RTC-4’. The RTC AS 1060 is shown as interfacing with itself, said interface labelled ‘RTC- 10’.

[0157] The general reference architecture also includes an external RTC application provider 1070. The RTC application provider 1070 is shown as interfacing with the RTC AF 1050, said interface labelled ‘RTC-1’. The RTC application provider 1070 is also shown as interfacing with the native web RTC application 1012, said interface labelled ‘RTC-8’.

[0158] Exposed APIs are shown as existing at the RTC MSH 1016 RTC-6, RTC-11 interfaces. Exposed APIs are shown as existing at the RTC Access Function 1018 RTC-7, RTC-11 interfaces. Exposed APIs are shown as existing at the RTC AF 1050 RTC-5 and RTC-1 interfaces. The RTC-1, RTC-4, RTC-5, RTC-6, RTC-7, WebRTC API, RTC-11, RTC- 12 interfaces are shown as having RTC scope. The interface between PCF 1020, NEF 1030, SMF 1040 and the RTF AF 1050 is shown as having 5GS scope. The RTC-8 and RTC- 10 interfaces are shown as having application scope.

[0159] The RTC AF 1050, or generally the media AF, may request on behalf of an application a QoS session to the 5GS based on the exposed NEF 1030 and / or PCF 1020 policy service APIs. The AS session with QoS request may be based on the AF 1050 determined configuration considering any ASP provisioning configuration, including AL- FEC indexed configurations as either an information element of the general provision session provisioning, or alternatively, of the policy templates provisioning according to the general media delivery architecture procedures, or alternatively, RTC media delivery procedures, as described in the 3GPP Specifications TS 26.510 or TS 26.113, respectively.

[0160] The additional provisioning information over existing provisioning procedures may comprise the indexed AL-FEC configuration as a data element, e.g., a JSON array of AL-FEC configuration type, mapping for each index (e.g., 0, 1, 2, etc.) of an ASP provisioned AL-FEC configuration. The indexing model may in some implementations be realized as an array, a linked list, hash map and / or key -value pairing data structures, or combinations thereof.

[0161] By way of example, the provisioned indexed AL-FEC configuration may contain the listing shown in Table 1, or similar.Table 1

[0162] The AL-FEC configuration elements of the indexed AL-FEC configuration may comprise additional AL-FEC information elements.

[0163] The AL-FEC information elements may comprise a FEC codec identifier (e.g., a FECEncodingID as per FECFRAME specification of RFC 6363 mapping the AL-FEC codec to a registered FEC codec within a FEC codec registry, e.g., a IANA registered AL- FEC such as Reed-Solomon, Raptor / RaptorQ as per “urn:ietf:rmt:fec:encoding”).

[0164] The AL-FEC information elements may comprise a FEC configuration instance identifier that may be used together with the FEC codec identifier to determine a further set of parameters and properties corresponding to the AL-FEC configuration instance (e.g., a FECInstancelD as per FECFRAME specification of RFC 6363 determined by the IANA registered URNs “urn: ietfrmt: fee: encoding: instance” such that for instance in an example corresponding to RaptorQ AL-FEC codec according to RFC 6330 the FECInstancelD value may be ‘6’ coupled with ‘urn:ietf:rmt:fec:encoding’ to fully specify the RaptorQ configuration applicable).

[0165] The AL-FEC information elements may comprise a (S)RTP payload type corresponding to the PDUs encoded with the AL-FEC configuration instance. The (S)RTP payload type may be used together with the FEC code identifier and FEC configurationinstance identifier elements to parse at any intermediary network node some or all fields of the (S)RTP payload according to the (S)RTP payload format of a specific AL-FEC codec.

[0166] The AL-FEC information elements may comprise a content, or alternatively, a redundancy level, wherein such level may be expressed in percentage and determines the ratio of original uncoded PDUs to the total coded PDUs of an AL-FEC encoded PDU Set, or alternatively, the ratio of parity (i.e., redundant) PDUs to the total coded PDUs of an AL- FEC encoded PDU Set. This level may be expressed in percentage or a non-negative floating-point number.

[0167] The AL-FEC information elements may comprise a Boolean indicator specifying whether the AL-FEC codec is a Maximum Distance Separable (MDS) code wherein the original uncoded payload may be recovered from any combination of necessarily sufficient PDUs successfully received at the receiver (i.e., in case of K source PDUs encoded by AL-FEC to N > K PDUs forming a PDU Set, only K coded PDUs are needed in case of an MDS code to recover the initial K source PDUs).

[0168] In a further example implementation, the AL-FEC is statically determined to belong to a family of MDS codes. The AL-FEC configuration elements of the indexed AL- FEC configuration may comprise just the content, or alternatively, redundancy level in percentage, as shown in Table 2.Table 2

[0169] In a further example, the AL-FEC is not statically determined to belong to a family of MDS codes. The AL-FEC configuration elements of the indexed AL-FEC configuration may comprise the content, or alternatively, redundancy level in percentage, and a Boolean indicator of whether or not the corresponding AL-FEC configuration is MDS, as shown in Table 3.Table 3

[0170] Upon the request from the media AF, or alternatively the RTC AF 1050, for an AS session with QoS including the indexed AL-FEC configuration (i.e., a mapped AL-FEC content, or alternatively, redundancy ratio to a value), the 5GS may enhance the existing QoS policy.

[0171] The QoS policy may be enhanced to comprise the PCF 1020 generating PCC rules based on the received (flow description(s), QoS requirements) and indexed AL-FEC configuration.

[0172] The QoS policy may be enhanced to comprise the SMF 1040 generating a QoS profile for the RAN, e.g., NG-RAN, based on the received mapping information from the PCF 1020.

[0173] The QoS policy may be enhanced to comprise the NG-RAN checking based on the QoS profile and AL-FEC mapping information available from the SMF 1040 the GTP- U header to determine the AL-FEC content, or alternatively, redundancy ratio, wherein the GTP-U header contains the indexed value corresponding to the AS utilized AL-FEC content or redundancy level. The indexed value is determined and copied over by a UPF from the (S)RTP HE for PDU Set marking wherein the RTP source AL-FEC encoder provides the AL-FEC index information according to the ASP provisioned indexed AL- FEC configuration present in the AS session request with QoS that created the QoS flow.

[0174] Figure 11 illustrates a signaling workflow 1100 of dynamic selection of AL- FEC redundancy level based on an indexed AL-FEC configuration, in accordance with aspects of the present disclosure. The Figure shows a UE 1110 comprising an application 1112 and a MSH 1114, a gNB / RAN 1120, a UPF 1130, a PCF 1140, a media AF 1150, an ASP 1160, and application remote endpoint 1170 and a dynamic AL-FEC controller 1180.

[0175] The workflow 1100 associated with the above procedures is outlined end-to-end from provisioning to media delivery and index value change and / or adaptation. The various steps will now be described.

[0176] In step 1100a, the ASP 1160 provisions the Media AF / RTC AF 1150 with the indexed AL-FEC configuration. The AL-FEC configuration may be present as part of the general provisioning sessions provisioning procedure information elements, or alternatively, as part of a policy templates provisioning procedure information elements. The ASP 1160 may configure the Media AF / RTC AF 1150 over the RTC-1 interface and corresponding service APIs.

[0177] In step 1101, the RTC endpoints (e.g., UE 1110 and application remote endpoint 1170 which may be an AS or another UE behind a relaying AS) negotiate media, protocol and format capabilities and establish an RTC session corresponding to the ASP provisioning with the indexed AL-FEC configuration. The establishment of the RTC session / connection may be performed based on SDP signaling and an offer / answer procedure between the two RTC endpoints over the RTC-4 interface.

[0178] In steps 1102a the UE 1110 determines QoS allocation for the RTC session based on the SDP determined 5-typle and media service access information provided by the application client 1112 to the Media Session Handler (MSH) 1114 (e.g., over the RTC-6 interface). Specifically, in step 1102b the MSH 1114 requests (over the RTC-5 interface) QoS assistance from the Media AF 1150 by instantiating a policy template as a dynamic policy. The Media AF 1150 validates the dynamic policy request and in step 1102c requests to the 5GS (i.e., the PCF / SMF 1140) by means of existing N5 / N33 interfaces and associated policy authorization APIs an AS session with QoS on behalf of the RTC session. The QoS request is based on and comprises at least a subset of the indexed AL-FEC configuration. In step 1102d the 5GS (i.e., the PCF / SMF 1140) confirms a successful QoS allocation to media AF 1150 over the N5 / N33 interface. Upon receipt of the successful QOS allocation, in step 1102e the Media AF 1150 notifies the MSH 1114 in the UE 1110 (e.g., via the RTC-5 interface) of the successful QoS allocation. In step 1102f the MSH 1114 notifies the media-aware application 1112 over RTC-6 of the QoS allocation status. Furthermore, over control plane signaling the 5GS configures the QoS flow and NG-RAN QoS profile containing the indexed AL-FEC configuration information and subsequent mapping.

[0179] In steps 1103a- 1103c the media delivery loop starts with DL and UL traffic over RTC-4 interface between the two RTC endpoints 1112 and 1170. In step 1103a, DL RTC content delivery occurs which may include encoding DL RTC content by the RTC sender i.e., the application remote endpoint 1170 (e.g., a media AS) according to the indexed AL- FEC configuration. The used AL-FEC (i.e., content / redundancy ratio level) is signaled as part of the (S)RTP PDU Set marking over RTC-4 and thus exposed to the UPF 1130 at the N6 reference point, or alternatively, to the gNB / RAN 1120 via GTP-U protocol headers atreference point N3. The AL-FEC index may be equal to 0, for instance. As noted herein the DL RTC content delivery may comprise SRTP streams and SRTCP feedback. Based on the QoS profile and the signaling of used AL-FEC content / redundancy ratio level, in step 1103b the RAN 1120 may drop redundant (i.e., obsolete) PDUs out of the PDU Sets that needs to be scheduled over the air-interface (e.g., Uu) to the UE 1110. The dropped PDUs may be obsolete AL-FEC encoded PDUs. In step 1103c, UL RTC content delivery is performed. This may include SRTP streams and SRTCP feedback, for instance.

[0180] In step 1104, AL-FEC redundancy is performed. AL-FEC adaptation may be triggered by a dynamic AL-FEC controller 1180. The dynamic AL-FEC controller logic may be processed at one of the two RTC endpoints i.e., at the UE 1110 or the application remote endpoint 1170 (e.g., at the media AS), or may be processed in a distributed manner by the RTC endpoints. The dynamic AL-FEC controller 1180 may select another AL-FEC content / redundancy level based on the indexed AL-FEC and at least one of the network available resources, RTC endpoint capabilities, QoS requirements (e.g., minimum PSDB, PDB). For instance, the dynamic AL-FEC controller 1180 may trigger the AL-FEC encoder at an RTC sender endpoint 1110, 1170 (e.g., a media AS) to switch from indexed ‘0’ AL- FEC configuration to the ‘ 1 ’ AL-FEC configuration, wherein ‘ 1 ’ index corresponds to a lower level of content / redundancy ratio (e.g., switch from 50% to 30% content / redundancy level).

[0181] The indication and signaling of the AL-FEC content / redundancy ratio level based on the indexed AL-FEC configuration may be embedded into the RTP HE for PDU Set marking. The 2-bit reserved bit field may be used to this end wherein the 2 bits syntax is arranged to represent the PDU Set Redundancy Indication (PRI), as illustrated for both 1- byte example 1200 and 2-byte example 1300 RTP HE formats in Figures 12 and 13, respectively. The PRI may be assigned any of the index values corresponding to the indexed AL-FEC configuration, thus mapping the index PRI indication to the actual AL- FEC configuration used by the RTC endpoint encoder. For example, in alignment with previous examples of indexed AL-FEC configurations, a PRI valued to ‘0’ may indicate that a PDU Set contains 50% redundancy PDUs out of the total number of PDUs (i.e., NPDS). Similarly, a PRI valued to ‘ 1 ’ may indicate that a PDU Set contains 30%redundancy PDUs out of the total number of PDUs (i.e., NPDS). By reversing the indexed AL-FEC configuration mapping, RAN may therefore determine the least amount of PDUs of a PDU Set that need to be successfully transmitted to guarantee recovery of the PDU Set payload. This determination implies applying the rule [f(PRI)-NPDS], wherein the functional f(-) stands for the operation of retrieving the content ratio level from the indexed AL-FEC configuration corresponding to the index value PRI. As an example, for a redundancy level of 50%, a PDU Set of 12 PDUs would require sending 8 PDUs, wherein a PDU Set of 10 PDUs would require sending 7 PDUs.

[0182] Alternatively, the indication and signaling of the AL-FEC content / redundancy ratio level based on the indexed AL-FEC configuration may be embedded into the RTP HE for PDU Set marking as a bitmasked component of the existent 4-bit PSI information field. As AL-FEC encoding is applied to PDU Sets, their PSI indications are diluted by the extra redundancy in the system. Furthermore, the PSI indicator functions currently as a Boolean indicator to the RAN specifying whether or not the PSI is low enough to warrant dropping the PDU Set under air-interface congestion. Hence, to avoid any additional field signaling and not consume the reserved 2-bits field of the RTP HE PDU Set marking, a bitmask may be applied to the PSI when the indexed AL-FEC configuration is provisioned and configured for a QoS flow and a RAN QoS profile. The bitmask may thus separate the PSI syntax into two subcomponents, i.e. the actual PSI value, and the PRI value, respectively. Given the bitmask application, the PSI semantics will be preserved in meaning but reduced in scope, i.e., instead of values from 0 to 15, the PSI value would be reduced to values from 0 to log2(4 - bitdepth(bitmask ) . For instance, the PRI bitmask may be set to 0x1100 such that the 4-bit PSI field is separated into 2-bit PRI field as (0x1100 & PSI), whereas the PSI value is reduced to 2-bit PSI as (-0x1100 & PSI). Hence, the PSI field may only be assigned values from 0 to 4 by an RTC encoder endpoint, with 0 as no information, 1 highest importance and 4 lowest importance. On the other hand, the upper MSB of the original 4-bit PSI syntax correspond to the PRI and may be used to indicate the PRI index corresponding to the used indexed AL-FEC configuration. This bitmasked processing of the existing PSI is illustrated in the example 1400 of Figure 14.

[0183] In another example, the indication and signaling of the AL-FEC content / redundancy ratio level based on the indexed AL-FEC configuration may be embedded into the RTP HE for PDU Set marking may be added as an extensible information field to the existent RTP HE for PDU Set marking syntax. The field PRI may be so optionally added and enabled when the indexed AL-FEC configuration is available and used to establish a QoS session for AL-FEC encoded PDU Sets. To this end an up to 8- bits optional field may be added to both the 1-byte and 2-byte format of the RTP HE for PDU Set marking comprising the value of the index mapping of the used AL-FEC configuration for encoding the PDU Set originated at an RTC AL-FEC encoder. The presence of the optional PRI field in the RTP HE for PDU Set marking needs to be additionally signaled during the SDP procedure, indicating to RTC endpoints, as well as to the UPF (or any intermediary network functions requiring such information), the optional enablement and presence of the PRI information.

[0184] Example realizations of the PRI field as an optional field to the existing 1-byte and 2-byte formats of the RTP HE for PDU Set marking are depicted in the example 1500 of Figure 15 and the example 1600 of Figure 16, respectively. In another example, the presence of the PRI field in the RTP HE for PDU Set marking is indicated by means of SDP signaling as an extension attribute optional property, i.e., “pdu-set-redundancy-index”, PRI, in ABNF notation as: a=extmap:" 1*5DIGIT [" / " direction] SP extensionname SP extensionattributes extensionname = "urn:3gpp:pdu-set-marking:rel-18" extensionattributes = [format SP]"pdu-set-size" [SP] “num-of-pdus” [SP] “pdu-set- redundancy-index” format = "short" / "long"

[0185] The indexed AL-FEC configuration described herein may comprise an index corresponding to an empty, or alternatively, NULL AL-FEC configuration, the empty AL- FEC configuration corresponding to a content ratio of 100%, a redundancy ratio of 0%, or alternatively no AL-FEC coding applied. For example, the NULL, or alternatively, empty AL-FEC configuration may be used in the 5GS in case of marking AL-FEC PRI information of lonely PDUs mapped to a PDU Set. A lonely PDU is any PDU over N6 interface at the UPF that is not mapped to a PDU Set or marked with PDU Set informationby the RTC endpoint. The UPF assigns these lonely PDUs to a PDU Set, e.g., a PDU Set containing a single PDU and provides all the PDU Set information to the 5GS corresponding to the determined PDU Set. Usually, the lonely PDUs may comprise packeted video codec metadata (e.g., non-video coded layer NAL units such as SPS, VPS, PPS) and media delivery metadata (RTCP control packets, SCTP data channel messages or alike), and generally metadata or any type of data that may not be AL-FEC encoded, and hence is mappable to a NULL, or alternatively, empty AE-FEC configuration corresponding to 0% redundancy or 100% content ratio, respectively.

[0186] In addition, the indexed AL-FEC configuration may be encoded in a bit field of maximum The indexed AL-FEC configuration described herein may comprise an index corresponding to an empty, or alternatively, NULL AL-FEC configuration, the empty AL- FEC configuration corresponding to a content ratio of 100%, a redundancy ratio of 0%, or alternatively no AL-FEC coding applied. For example, the NULL, or alternatively, empty AL-FEC configuration may be used in the 5GS in case of marking AL-FEC PRI information of lonely PDUs mapped to a PDU Set. A lonely PDU is any PDU over N6 interface at the UPF that is not mapped to a PDU Set or marked with PDU Set information by the RTC endpoint. The UPF assigns these lonely PDUs to a PDU Set, e.g., a PDU Set containing a single PDU and provides all the PDU Set information to the 5GS corresponding to the determined PDU Set. Usually, the lonely PDUs may comprise packeted video codec metadata (e.g., non-video coded layer NAL units such as SPS, VPS, PPS) and media delivery metadata (RTCP control packets, SCTP data channel messages or alike), and generally metadata or any type of data that may not be AL-FEC encoded, and hence is mappable to a NULL, or alternatively, empty AL-FEC configuration corresponding to 0% redundancy or 100% content ratio, respectively.

[0187] In addition, the indexed AL-FEC configuration may be encoded in a bit field of maximum [log2|# indices |] bits within the RTP HE for PDU Set marking for a lossless efficient, i.e., minimum bit depth, encoding.

[0188] One skilled in the art may note that same processing is applicable for considering content ratios instead of redundancy ratios interchangeably throughout the presented subject matter. Obvious alternative naming, e.g., from PRI to PDU Set ContentIndication (PCI), are therefore applicable interchangeably and follow similar logic as exposed herein.

[0189] Figure 17 illustrates an example of a UE 1700 in accordance with aspects of the present disclosure. The UE 1700 may include a processor 1702, a memory 1704, a controller 1706, and a transceiver 1708. The processor 1702, the memory 1704, the controller 1706, or the transceiver 1708, 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.

[0190] The processor 1702, the memory 1704, the controller 1706, or the transceiver 1708, 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.

[0191] The processor 1702 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 1702 may be configured to operate the memory 1704. In some other implementations, the memory 1704 may be integrated into the processor 1702. The processor 1702 may be configured to execute computer-readable instructions stored in the memory 1704 to cause the UE 1700 to perform various functions of the present disclosure.

[0192] The memory 1704 may include volatile or non-volatile memory. The memory 1704 may store computer-readable, computer-executable code including instructions when executed by the processor 1702 cause the UE 1700 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 1704 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-transitorystorage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.

[0193] In some implementations, the processor 1702 and the memory 1704 coupled with the processor 1702 may be configured to cause the UE 1700 to perform one or more of the functions described herein (e.g., executing, by the processor 1702, instructions stored in the memory 1704). For example, the processor 1702 may support wireless communication at the UE 1700 in accordance with examples as disclosed herein. The UE 1700 may be configured to support a means for perform the method 2000 of Figure 20. The UE 1700 may be the UE 1010 of Figure 10, the UE 1110 of Figure 11, for instance. The UE 1700 may be a UE comprising at least one memory; and at least one processor coupled with the at least one memory and configured to cause the user equipment to: receive one or more application data units (ADUs) of a media application; select, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; generate at least one protocol data unit (PDU) set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU; mark at least one header of the at least one PDU set to indicate a respective value for the index of the selected AL-FEC configuration element; and transmit the at least one PDU set to a network entity.

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

[0195] In some implementations, the UE 1700 may include at least one transceiver 1708. In some other implementations, the UE 1700 may have more than one transceiver 1708. The transceiver 1708 may represent a wireless transceiver. The transceiver 1708 may include one or more receiver chains 1710, one or more transmitter chains 1712, or a combination thereof.

[0196] A receiver chain 1710 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 1710 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 1710 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. The receiver chain 1710 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 1710 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0197] A transmitter chain 1712 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 1712 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 1712 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 1712 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0198] Figure 18 illustrates an example of a processor 1800 in accordance with aspects of the present disclosure. The processor 1800 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 1800 may include a controller 1802 configured to perform various operations in accordance with examples as described herein. The processor 1800 may optionally include at least one memory 1804, which may be, for example, an L1 / L2 / L3 cache. Additionally, or alternatively, the processor 1800 may optionally include one or more arithmetic-logic units (ALUs) 1806. 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).

[0199] The processor 1800 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 1800) 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).

[0200] The controller 1802 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 1800 to cause the processor 1800 to support various operations in accordance with examples as described herein. For example, the controller 1802 may operate as a control unit of the processor 1800, generating control signals that manage the operation of various components of the processor 1800. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating timing of operations.

[0201] The controller 1802 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from the memory 1804 and determine subsequent instruction(s) to be executed to cause the processor 1800 to support various operations in accordance with examples as described herein. The controller 1802 may be configured to track memory address of instructions associated with the memory 1804. The controller 1802 may be configured to decode instructions to determine the operation to be performed and the operands involved. For example, the controller 1802 may be configured to interpret the instruction and determine control signals to be output to other components of the processor 1800 to cause the processor 1800 to support various operations in accordance with examples as described herein. Additionally, or alternatively, the controller 1802 may be configured to manage flow of data within the processor 1800. The controller 1802 may be configured to controltransfer of data between registers, arithmetic logic units (ALUs), and other functional units of the processor 1800.

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

[0203] The memory 1804 may store computer-readable, computer-executable code including instructions that, when executed by the processor 1800, cause the processor 1800 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 1802 and / or the processor 1800 may be configured to execute computer-readable instructions stored in the memory 1804 to cause the processor 1800 to perform various functions. For example, the processor 1800 and / or the controller 1802 may be coupled with or to the memory 1804, the processor 1800, the controller 1802, and the memory 1804 may be configured to perform various functions described herein. In some examples, the processor 1800 may include multiple processors and the memory 1804 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.

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

[0205] The processor 1800 may support wireless communication in accordance with examples as disclosed herein. The processor 1800 may be configured to support a means for performing the method 2100 of Figure 21 for a UE. The processor 1800 may comprise at least one controller coupled with at least one memory and configured to cause the processor 1800 to: access one or more application data units (ADUs) of a media application; select, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; output at least one protocol data unit ‘PDU’ set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU; and output at least one header of the at least one PDU set to indicate a respective value for the index of the selected AL- FEC configuration element. The processor 1800 may alternatively be configured to or operable to support a means for performing a method for a first network function such as the method 2200 of Figure 22. The processor 1800 may be configured to cause the first network function to determine a provisioning configuration comprising an indexed application layer forward error correction (AL-FEC) configuration, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; and generate, based at least in part on one or more AL-FEC configuration elements of the indexed AL-FEC configuration, a quality of service (QoS) configuration for a media session, the media session comprising at least one AL-FEC encoded protocol data unit (PDU) set. The processor 1800 may alternatively be configured to or operable to support a means for performing a method for an application server, such as the method 2300 of Figure 23. The processor 1800 may be configured to cause the application server to receive one or more application data units (ADUs) of a media application; select, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; generate at least one protocol data unit (PDU) set based at least in part on coding at least one ADUof the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU; mark at least one header of the at least one PDU set to indicate a respective value for the index of the selected AU-FEC configuration element; and transmit the at least one PDU set to a network entity.

[0206] Figure 19 illustrates an example of a NE 1900 in accordance with aspects of the present disclosure. The NE 1900 may include a processor 1902, a memory 1904, a controller 1906, and a transceiver 1908. The processor 1902, the memory 1904, the controller 1906, or the transceiver 1908, 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.

[0207] The processor 1902, the memory 1904, the controller 1906, or the transceiver 1908, 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.

[0208] The processor 1902 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 1902 may be configured to operate the memory 1904. In some other implementations, the memory 1904 may be integrated into the processor 1902. The processor 1902 may be configured to execute computer-readable instructions stored in the memory 1904 to cause the NE 1900 to perform various functions of the present disclosure.

[0209] The memory 1904 may include volatile or non-volatile memory. The memory 1904 may store computer-readable, computer-executable code including instructions when executed by the processor 1902 cause the NE 1900 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 1904 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.

[0210] In some implementations, the processor 1902 and the memory 1904 coupled with the processor 1902 may be configured to cause the NE 1900 to perform one or more of the functions described herein (e.g., executing, by the processor 1902, instructions stored in the memory 1904). For example, the processor 1902 may support wireless communication at the NE 1900 in accordance with examples as disclosed herein. The NE 1900 may be configured to support a means for performing the method 2200 of Figure 22. The NE 1900 may be a first network function comprising at least one memory; and at least one processor coupled with the at least one memory and configured to cause the first network function to: determine a provisioning configuration comprising an indexed application layer forward error correction (AL-FEC) configuration, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; and generate, based at least in part on one or more AL-FEC configuration elements of the indexed AL-FEC configuration, a quality of service (QoS) configuration for a media session, the media session comprising at least one AL-FEC encoded protocol data unit (PDU) set. The NE 1900 may be configured to support a means for performing the method 2300 of Figure 23. The NE 1900 may be an application server comprising at least one memory; and at least one processor coupled with the at least one memory and configured to cause the application server to: receive one or more application data units (ADUs) of a media application; select, from an indexed AL- FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; generate at least one protocol data unit (PDU) set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU; mark at least one header of the at least one PDU set to indicate a respective value for the index of the selected AL-FEC configuration element; and transmit the at least one PDU set to a network entity. The NE 1900 may be an RTC AF 1050 of Figure 10, an RTC application provider 1070 of Figure 10, an RTC AS 1060 of Figure 10, agNB / RAN 1120, a UPF 1130, a PCF / SMF 1140, a media AF 1150, an ASP 1160 or an application remote endpoint 1170, for instance, of Figure 11.

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

[0212] In some implementations, the NE 1900 may include at least one transceiver 1908. In some other implementations, the NE 1900 may have more than one transceiver 1908. The transceiver 1908 may represent a wireless transceiver. The transceiver 1908 may include one or more receiver chains 1910, one or more transmitter chains 1912, or a combination thereof.

[0213] A receiver chain 1910 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 1910 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 1910 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. The receiver chain 1910 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 1910 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0214] A transmitter chain 1912 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 1912 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 1912 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitablefor transmission over the wireless medium. The transmitter chain 1912 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

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

[0216] At 2002, the method 2000 may include receiving one or more application data units ‘ ADUs’ of a media application. The operations of 2002 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2002 may be performed by a UE as described with reference to Figure 17.

[0217] At 2004, the method 2000 may include selecting, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index. The operations of 2004 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2004 may be performed by a UE as described with reference to Figure 17.

[0218] At 2006, the method 2000 may include generating at least one protocol data unit ‘PDU’ set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU. The operations of 2006 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2006 may be performed a UE as described with reference to Figure 17.

[0219] At 2008, the method may include marking at least one header of the at least one PDU set to indicate a respective value for the index of the selected AL-FEC configuration element. The operations of 2008 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2008 may be performed by a UE as described with reference to Figure 17.

[0220] At 2010, the method may include transmitting the at least one PDU set to a network entity. The operations of 2010 may be performed in accordance with examples asdescribed herein. In some implementations, aspects of the operations of 2010 may be performed by a UE as described with reference to Figure 17.

[0221] It should be noted that the method 2000 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.

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

[0223] At 2102, the method 2100 may include accessing one or more application data units ‘ ADUs’ of a media application. The operations of 2102 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2102 may be performed by a processor as described with reference to Figure 18.

[0224] At 2104, the method 2100 may include selecting, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index. The operations of 2104 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2104 may be performed by a processor as described with reference to Figure 18.

[0225] At 2106, the method 2100 may include outputting at least one protocol data unit ‘PDU’ set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU. The operations of 2106 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2106 may be performed by a processor as described with reference to Figure 18.

[0226] At 2108, the method 2100 may include outputting at least one header of the at least one PDU set to indicate a respective value for the index of the selected AL-FECconfiguration element. The operations of 2108 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2108 may be performed by a processor as described with reference to Figure 18.

[0227] It should be noted that the method 2100 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.

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

[0229] At 2202, the method 2200 may include determining a provisioning configuration comprising an indexed application layer forward error correction ‘AL-FEC’ configuration, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index. The operations of 2202 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2202 may be performed by a NE as described with reference to Figure 19.

[0230] At 2204, the method 2200 may include generating, based at least in part on one or more AL-FEC configuration elements of the indexed AL-FEC configuration, a quality of service ‘QoS’ configuration for a media session, the media session comprising at least one AL-FEC encoded protocol data unit ‘PDU’ set. The operations of 2204 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2204 may be performed by a NE as described with reference to Figure 19.

[0231] It should be noted that the method 2200 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.

[0232] Figure 23 illustrates a flowchart of a method 2300 in accordance with aspects of the present disclosure. The operations of the method 2300 may be implemented by a NE as described herein, for instance by an application server. In some implementations, the NEmay execute a set of instructions to control the function elements of the NE to perform the described functions.

[0233] At 2302, the method 2300 may include receiving one or more application data units ‘ ADUs’ of a media application. The operations of 2302 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2302 may be performed by a NE as described with reference to Figure 19.

[0234] At 2304, the method 2300 may include selecting, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index. The operations of 2304 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2304 may be performed by a NE as described with reference to Figure 19.

[0235] At 2306, the method 2300 may include generating at least one protocol data unit ‘PDU’ set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU. The operations of 2306 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2306 may be performed a NE as described with reference to Figure 19.

[0236] At 2308, the method 2300 may include marking at least one header of the at least one PDU set to indicate a respective value for the index of the selected AL-FEC configuration element. The operations of 2308 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2308 may be performed by a NE as described with reference to Figure 19.

[0237] At 2310, the method 2300 may include transmitting the at least one PDU set to a network entity. The operations of 2310 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2310 may be performed by a NE as described with reference to Figure 19.

[0238] It should be noted that the method 2300 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.

[0239] There is provided a first network function for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the first network function to: determine a provisioning configuration comprising an indexed application layer forward error correction (AL-FEC) configuration, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; and generate, based at least in part on one or more AL- FEC configuration elements of the indexed AL-FEC configuration, a quality of service (QoS) configuration for a media session, the media session comprising at least one AL-FEC encoded protocol data unit (PDU) set.

[0240] AL-FEC tends to enable robust transmission of data over a lossy network. The use of AL-FEC is particularly beneficial where a round-trip time (RTT) for transmission of data over a network exceeds an application or service requirement. An example is where data for an extended reality (XR) application or service is being transmitted with a particular delay budget, but the RTT for a network exceeds the delay budget. AL-FEC tends to enable such delay budgets to be met, even for increased RTT, by proactively adding redundancy to combat potential link-losses in the transmission path.

[0241] However, the efficiency of AL-FEC can decay in networks offering quality of service (QoS) guarantees in relation to meeting delay budgets and error rates. By way of example, the redundancy added by AL-FEC tends to consume available bandwidth in networks that would otherwise be available to an application, service or user group, for improving QoS. Despite this, modern networks being of a heterogeneous nature (and partly unmanaged) cannot always be guaranteed to provide adequate service. Accordingly, AL- FEC is necessary despite the potential impact on QoS.

[0242] Accordingly, there is a requirement to dynamically control the additional bandwidth utilised by the redundancy afforded by AL-FEC. More specifically, there is a requirement to dynamically control the content-ratio (also referred to herein as a redundancy ratio) associated with AL-FEC encoded content over a data flow.

[0243] The disclosure herein provides an indexed signaling out of available mapped and provisioned AL-FEC configurations. The AL-FEC indexed configurations that may be applied by an application for a session are provisioned in the control plane by an application service provider (ASP) to an application function (AF) as part of a provisioned policy template, or, as part of general provisioning session configuration for a service. The AF can decide based on the dynamic data traffic characteristics experienced by, for instance, an application server (AS), and observed network conditions which AL-FEC configuration to use. This tends to allow for a media session that balances the requirement for redundancy with the QoS requirement for an application or service. Expressed differently, this enables in the application-domain the dynamic control of the AL-FEC content ratio based on dynamic operating conditions and traffic characteristics. This tends to lead to optimized transmission of content by a RAN, improving system efficiency.

[0244] The mapping of the one or more AL-FEC configuration elements to the index may be a bijective mapping.

[0245] The provisioning configuration may be determined by the first network function by considering an application service provider configuration, which may be provided as part of a general media session provisioning, as one or more policy templates provisioned according to general media delivery architecture procedures, or as part of RTC media delivery procedures. Application service provider configuration provisioning is discussed generally in the 3GPP Technical Specifications TS 26.510 (titled “Media delivery; interactions and APIs for provisioning and media session handling”) and 26.113 (titled “Real-time media communication; Protocols and APIs”).

[0246] The at least one processor may be further configured to cause the first network function to: transmit, to a second network function, a first request message for a QoS flow for the media session, wherein the first request message comprises the QoS configuration; and receive, from the second network function, a first response message confirming an allocated QoS flow for the media session.

[0247] The second network function may comprise a policy control function (PCF); or a network exposure function (NEF).

[0248] The PCF may derive QoS rules for the media session and specific QoS requirements for PDU sets based at least in part on the first request message (or content thereof). The PCF may configure a SMF as a result. The PCF may derive PCC rules per importance of a PDU set according to information received from the first network function. This may enable the SMF to establish the QoS flow and enable PDU set handling, whilst also configuring a UPF to route packets of the media session. A QoS profile may also be provided to the RAN comprising the PDU set QoS requirements.

[0249] The at least one processor may be further configured to cause the first network function to: expose, to a consumer function, the first response message confirming the allocated QoS flow for the media session.

[0250] The first network function may expose the first response message to the consumer function by forwarding the first response message. Alternatively, the first response message or the content thereof may be repackaged into a further message transmitted by the first network function to the consumer function.

[0251] The consumer function may comprise: a media session handler (MSH) of a user equipment (UE); or a media application server (AS) of the media session.

[0252] The at least one processor may be further configured to cause the first network function to determine the provisioning configuration by causing the first network function to: receive the provisioning configuration as one or more provisioning configuration templates from an application service provider.

[0253] The provisioning configuration may alternatively be provided as part of a general provisioning procedure information.

[0254] The first network function may comprise an application function (AF).

[0255] The application function may be a media application function. Alternatively, the application function may be a real-time communications (RTC) application function.

[0256] The indexed AL-FEC configuration may comprise one or more of: a null AL- FEC configuration; an empty AL-FEC configuration; an AL-FEC configuration associated with no AL-FEC coding.

[0257] The empty or null AL-FEC configuration may correspond to a content ratio of 100% (or a redundancy ratio of 0%). Such a configuration may be used in a 5G system for marking AL-FEC PDU set content ratio indication information of lonely PDUs mapped to a PDU set. Such a ‘lonely’ PDU may be any PDU at the UPF that is not mapped to a PDU set or marked with PDU set information by an RTC endpoint. Such lonely PDUs are assigned to a PDU set by the UPF (i.e., to a PDU set containing only a single PDU). Lonely PDUs typically comprise packeted video codec metadata and media delivery metadata, or generally metadata that is not AL-FEC encoded.

[0258] Each AL-FEC configuration element may comprise one or more information elements, the one or more information elements may comprise at least one of: a FEC encoding identifier field; a FEC instance identifier field; a maximum distance separable ‘MDS’ code indicator field; a redundancy level indicator field; and a content level indicator field.

[0259] The FEC encoding identifier field may be referred to herein as a FEC encoding ID. The FEC encoding identifier field may identify in part the AL-FEC configuration.

[0260] The FEC instance identifier field may be referred to herein as a FEC instance ID field. The FEC instance identifier field may identify in part the AL-FEC configuration and one or more associated parameters.

[0261] The MDS code indicator field may indicate if the AL-FEC configuration has an MDS encoding characteristic.

[0262] The redundancy level indicator field may indicate a redundancy quota of a number of redundant PDUs per number of total PDUs generated by the AL-FEC configuration for a PDU set.

[0263] The content level indicator field may determine the content quota of a number of original source uncoded PDUs per number of total PDUs generated by the AL-FEC configuration for a PDU set.

[0264] There is further provided an application server for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least onememory and configured to cause the application server to: receive one or more application data units (ADUs) of a media application; select, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; generate at least one protocol data unit (PDU) set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU; mark at least one header of the at least one PDU set to indicate a respective value for the index of the selected AL-FEC configuration element; and transmit the at least one PDU set to a network entity.

[0265] The network entity may, for instance, be another application server, a media gateway function, a network gateway function, a User Plane Function (UPF) or a UE.

[0266] An application data unit (ADU) comprises data from an application. A PDU may relate and comprise content of an ADU. PDUs may be grouped into a PDU set which together as the PDU set can be treated according to a particular QoS requirement, for instance.

[0267] By marking the at least one header to indicate the index value of the selected AL-FEC configuration element, the exposure of this information to the radio access network (RAN) tends to allow the RAN to drop unnecessary or obsolete AL-FEC PDUs. In effect, this enables in the application-domain the dynamic control of the AL-FEC content ratio based on dynamic operating conditions and traffic characteristics. This further enables optimized transmission of content by a RAN, improving system efficiency.

[0268] The at least one header of the at least one PDU set may comprise a real-time protocol (RTP) header extension (HE) for PDU set marking.

[0269] The at least one processor may be further configured to cause the application server to mark the at least one header of the at least one PDU set by causing the application server to mark the at least one header within at least one of: a reserved bitfield of the RTP HE for PDU set marking; a subset of bits comprised within a PDU set importance (PSI) bitfield of the RTP HE for PDU set marking; a subset of bits determined by a bitmask; andan optional bitfield of the RTP HE for PDU set marking appended to the RTP HE for PDU set marking.

[0270] The at least one processor may be configured to cause the application server to mark the at least one header of the at least one PDU set within the optional bitfield, wherein the at least one processor is further configured to cause the application server to: signal, the presence of the optional bitfield, using a session description protocol (SDP) offer / answer procedure.

[0271] The at least one processor may be configured to cause the application server to dynamically select the AL-FEC configuration element based on at least one of: an availability of one or more network resources; one or more estimates of available network resources; a capability of the application server; a capability of the network entity; and one or more QoS requirements.

[0272] There is further provided a user equipment (UE) for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the user equipment to: receive one or more application data units (ADUs) of a media application; select, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; generate at least one protocol data unit (PDU) set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU; mark at least one header of the at least one PDU set to indicate a respective value for the index of the selected AL-FEC configuration element; and transmit the at least one PDU set to a network entity.

[0273] The network entity may, for instance, be an application server, a radio access network or another UE.

[0274] The at least one header of the at least one PDU set may comprise a real-time protocol (RTP) header extension (HE) for PDU set marking.

[0275] The at least one processor may be further configured to cause the UE to mark the at least one header of the at least one PDU set by causing the UE to mark the at leastone header within at least one of: a reserved bitfield of the RTP HE for PDU set marking; a subset of bits comprised within a PDU set importance (PSI) bitfield of the RTP HE for PDU set marking; a subset of bits determined by a bitmask; and an optional bitfield of the RTP HE for PDU set marking appended to the RTP HE for PDU set marking.

[0276] The at least one processor may be configured to cause the UE to mark the at least one header of the at least one PDU set within the optional bitfield, wherein the at least one processor is further configured to cause the UE to: signal, the presence of the optional bitfield, using a session description protocol (SDP) offer / answer procedure.

[0277] The at least one processor may be configured to cause the UE to dynamically select the AL-FEC configuration element based on at least one of: an availability of one or more network resources; one or more estimates of available network resources; a capability of the application server; a capability of the network entity; and one or more QoS requirements.

[0278] There is further provided a processor for wireless communication, comprising: at least one controller coupled with at least one memory and configured to cause the processor to: access one or more application data units (ADUs) of a media application; select, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; output at least one protocol data unit ‘PDU’ set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU; and output at least one header of the at least one PDU set to indicate a respective value for the index of the selected AL-FEC configuration element.

[0279] There is provided a method performed by a first network function, comprising: determining a provisioning configuration comprising an indexed application layer forward error correction (AL-FEC) configuration, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; and generating, based at least in part on one or more AL-FEC configuration elements of the indexed AL-FEC configuration, a quality of service (QoS) configuration for a media session, the media session comprising at least one AL-FEC encoded protocol data unit (PDU) set.

[0280] The method may comprise transmitting, to a second network function, a first request message for a QoS flow for the media session, wherein the first request message comprises the QoS configuration; and receiving, from the second network function, a first response message confirming an allocated QoS flow for the media session.

[0281] The second network function may comprise a policy control function (PCF) or a network exposure function (NEF).

[0282] The method may comprise exposing, to a consumer function, the first response message confirming the allocated QoS flow for the media session.

[0283] The consumer function may comprise a media session handler (MSH) of a user equipment (UE); or a media application server (AS) of the media session.

[0284] The method may comprise receiving the provisioning configuration as one or more provisioning configuration templates from an application service provider.

[0285] The first network function may comprise an application function (AF).

[0286] The indexed AL-FEC configuration may comprise one or more of: a null AL- FEC configuration; an empty AL-FEC configuration; an AL-FEC configuration associated with no AL-FEC coding.

[0287] Each AL-FEC configuration element may comprise one or more information elements, the one or more information elements comprising at least one of: a FEC encoding identifier field; a FEC instance identifier field; a maximum distance separable ‘MDS’ code indicator field; a redundancy level indicator field; and a content level indicator field.

[0288] There is further provided a method performed by an application server, comprising: receiving one or more application data units (ADUs) of a media application; selecting, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; generating at least one protocol data unit (PDU) set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU; marking at least one header of the atleast one PDU set to indicate a respective value for the index of the selected AL-FEC configuration element; and transmitting the at least one PDU set to a network entity.

[0289] The at least one header of the at least one PDU set may comprise a real-time protocol (RTP) header extension (HE) for PDU set marking.

[0290] The method may comprise marking the at least one header within at least one of: a reserved bitfield of the RTP HE for PDU set marking; a subset of bits comprised within a PDU set importance (PSI) bitfield of the RTP HE for PDU set marking; a subset of bits determined by a bitmask; and an optional bitfield of the RTP HE for PDU set marking appended to the RTP HE for PDU set marking.

[0291] The method may comprise signaling, the presence of the optional bitfield, using a session description protocol (SDP) offer / answer procedure.

[0292] The method may comprise dynamically selecting the AL-FEC configuration element based on at least one of: an availability of one or more network resources; one or more estimates of available network resources; a capability of the application server; a capability of the network entity; and one or more QoS requirements.

[0293] There is further provided a method performed by a user equipment (UE) comprising: receiving one or more application data units (ADUs) of a media application; selecting, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; generating at least one protocol data unit (PDU) set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU; marking at least one header of the at least one PDU set to indicate a respective value for the index of the selected AL-FEC configuration element; and transmitting the at least one PDU set to a network entity.

[0294] The at least one header of the at least one PDU set may comprise a real-time protocol ‘RTP’ header extension ‘HE’ for PDU set marking.

[0295] The method may comprise marking the at least one header of the at least one PDU set within at least one of: a reserved bitfield of the RTP HE for PDU set marking; asubset of bits comprised within a PDU set importance (PSI) bitfield of the RTP HE for PDU set marking; a subset of bits determined by a bitmask; and an optional bitfield of the RTP HE for PDU set marking appended to the RTP HE for PDU set marking.

[0296] The method may comprise signaling, the presence of the optional bitfield, using a session description protocol (SDP) offer / answer procedure.

[0297] The method may comprise dynamically selecting the AL-FEC configuration element based on at least one of: an availability of one or more network resources; one or more estimates of available network resources; a capability of the application server; a capability of the network entity; and one or more QoS requirements.

[0298] There is further provided a method performed by a processor, comprising: accessing one or more application data units (ADUs) of a media application; selecting, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; outputting at least one protocol data unit (PDU) set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU; and outputting at least one header of the at least one PDU set to indicate a respective value for the index of the selected AL-FEC configuration element.

[0299] The disclosure herein proposes a method to efficiently signal dynamic AL-FEC configuration changes to the 5GS and in particular to the RAN based on an indexed AL- FEC configuration provisioned by an ASP to a media AF. The indexed AL-FEC configuration comprising one or more valid AL-FEC configurations to choose from, which may include a default AL-FEC configuration, or an empty / null AL-FEC configuration. Each AL-FEC configuration may be indexed by a unique, i.e., bijective mapping, index value. Techniques to signal the index value corresponding to a used AL-FEC configuration are also described herein. Such signaling being performed by, for example, a media AS. the signaling techniques include indicating the index value as part of the RTP HE for PDU Set marking. This may be achieved through utilization of the available reserved bit field from the existent RTP HE PDU Set marking design and / or bitmasked repurposing of the PSI field conditioned to the utilization of AL-FEC configuration by the media AF and AS.

[0300] There is provided, a method at a network function, the method comprising applying a provisioning configuration, the provisioning configuration comprising an indexed AL-FEC configuration; generating a Quality of Service (QoS) request configuration for a media session, the QoS request comprising the indexed AL-FEC configuration corresponding to the media session serving at least in part AL-FEC encoded data, the AL-FEC encoded data comprising AL-FEC encoded PDU Sets; requesting from a second network function a QoS flow for the media session based on the QoS request configuration; and exposing the reply of the second network function to the request of the QoS flow to a consumer function.

[0301] The media session used AL-FEC configuration for encoding AL-FEC encoded data may be indicated within the media session, the indication comprised in a real-time protocol (RTP) header extension (HE) for PDU Set marking.

[0302] The provisioning configuration may comprise templates originating at an Application Service Provider.

[0303] The second network function may comprise one of a Policy Control Function (PCF); and a Network Exposure Function (NEF).

[0304] The consumer function may comprise one of a Media Session Handler (MSH); and a media Application Server (AS) of the media session. The MSH may be a networked functionality embedded within a client UE.

[0305] The network function may comprise a media Application Function (AF).

[0306] The indexed AL-FEC configuration may comprise at least an AL-FEC configuration element and an index, the index corresponding to a bijective mapping to the AL-FEC configuration.

[0307] The indexed AL-FEC configuration may comprise at least one index comprising an AL-FEC configuration element as one of a default AL-FEC configuration; a null AL- FEC configuration; an empty AL-FEC configuration; and an AL-FEC configuration corresponding to no AL-FEC coding being applied.

[0308] The AL-FEC configuration element may include at least one information element as a Forward Error Correction (FEC) Encoding identifier (ID) field, the FEC Encoding ID identifying in part the AL-FEC encoding configuration; a FEC Instance identifier (ID) field, the FEC instance ID identifying in part the AL-FEC encoding configuration and parameters; a Maximum Distance Separable (MDS) code indicator field, the MDS indicator determining if the AL-FEC encoding configuration has an MDS encoding characteristic; a redundancy level indicator field, the redundancy level determining the redundancy quota of number of redundant PDUs per number of total PDUs generated by the AL-FEC encoding configuration for each PDU Set; and a content level indicator field, the content level determining the content quota of number of original source uncoded PDUs per number of total PDUs generated by the AL-FEC encoding configuration for each PDU Set;

[0309] There is further provided an Application Server (AS) for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the AS to: receive Application Data Units (ADUs) of a media application; select from an indexed Application Layer Forward Error Correction (AL-FEC) configuration an AL-FEC configuration element, the indexed AL- FEC configuration mapping an AL-FEC configuration element to an index; generate at least one Protocol Data Unit (PDU) Set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU Set comprises at least one PDU; mark at least one PDU header of the PDU Set to indicate the index of the applied AL-FEC configuration element for the PDU Set; and transmit the PDU Set.

[0310] The PDU header may comprise a real-time protocol (RTP) header extension (HE) for PDU Set marking.

[0311] The marking of the index of the applied AL-FEC configuration may be comprised within at least one of: a reserved bitfield of the RTP HE for PDU Set marking; a subset of bits comprised within the PDU Set Importance (PSI) bitfield of the RTP HE for PDU Set marking, the subset of bits being determined by a bitmask; and an optional bitfieldof the RTP HE for PDU Set marking, the optional bitfield appended to the RTP HE for PDU Set marking.

[0312] The presence in the RTP HE for PDU Set marking of the optional bitfield comprising the marking of the index of the applied AL-FEC configuration may be signaled by means of a Session Description Protocol (SDP) offer / answer procedure.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.

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

[0314] The following abbreviations are relevant in the field addressed by this document: 3GPP, 3rd generation partnership project; 5G, fifth generation; 5GS, 5G System; 5QI, 5G QoS Identifier; AF, application function; AL-FEC, application layer forward error correction; AMF, access and mobility function; AR, augmented reality; AS, application server; DL, downlink; HE, header extension; NAL, network abstraction layer; PCF, policy control function; PDU, packet data unit; PPS, picture parameter set; QoE, quality of experience; QoS, quality of service; RAN, radio access network; RTCP, real-time control protocol; RTP, real-time protocol; SDP, session description protocol; SDAP, service data adaptation protocol; SMF, session management function; SRTCP, secure real-time control protocol; SRTP, secure real-time protocol; UE, user equipment; UL, uplink; UPF, user plane function; VCL, video coding layer; VMAF, video multi-method assessment function; VPS, video parameter set; VR , virtual reality; XR, extended reality; XR AS, XR application server; and XRM, XR media.

Claims

CLAIMSWhat is claimed is:

1. A first network function for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the first network function to: determine a provisioning configuration comprising an indexed application layer forward error correction ‘AL-FEC’ configuration, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; and generate, based at least in part on one or more AL-FEC configuration elements of the indexed AL-FEC configuration, a quality of service ‘QoS’ configuration for a media session, the media session comprising at least one AL-FEC encoded protocol data unit ‘PDU’ set.

2. The first network function of claim 1, wherein the at least one processor is further configured to cause the first network function to: transmit, to a second network function, a first request message for a QoS flow for the media session, wherein the first request message comprises the QoS configuration; and receive, from the second network function, a first response message confirming an allocated QoS flow for the media session.

3. The first network function of claim 2, wherein the second network function comprises: a policy control function ‘PCF’; or a network exposure function ‘NEF’.

4. The first network function of any one of claims 2-3, wherein the at least one processor is further configured to cause the first network function to: expose, to a consumer function, the first response message confirming the allocated QoS flow for the media session.

5. The first network function of claim 4, wherein the consumer function comprises: a media session handler ‘MSH’ of a user equipment ‘UE’; or a media application server ‘AS’ of the media session.

6. The first network function of any preceding claim, wherein the at least one processor is further configured to cause the first network function to determine the provisioning configuration by causing the first network function to: receive the provisioning configuration as one or more provisioning configuration templates from an application service provider.

7. The first network function of any preceding claim, wherein the first network function comprises an application function ‘AF’.

8. The first network function of any preceding claim, wherein the indexed AL-FEC configuration comprises one or more of: a null AL-FEC configuration; an empty AL-FEC configuration; an AL-FEC configuration associated with no AL-FEC coding.

9. The first network function of any preceding claim, wherein each AL-FEC configuration element comprises one or more information elements, the one or more information elements comprising at least one of: a FEC encoding identifier field; a FEC instance identifier field; a maximum distance separable ‘MDS’ code indicator field; a redundancy level indicator field; and a content level indicator field.

10. An application server for wireless communication, comprising: at least one memory; andat least one processor coupled with the at least one memory and configured to cause the application server to: receive one or more application data units ‘ADUs’ of a media application; select, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; generate at least one protocol data unit ‘PDU’ set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU; mark at least one header of the at least one PDU set to indicate a respective value for the index of the selected AL-FEC configuration element; and transmit the at least one PDU set to a network entity.

11. The application server of claim 10, wherein the at least one header of the at least one PDU set comprises a real-time protocol ‘RTP’ header extension ‘HE’ for PDU set marking.

12. The application server of claim 11, wherein the at least one processor is further configured to cause the application server to mark the at least one header of the at least one PDU set by causing the application server to mark the at least one header within at least one of: a reserved bitfield of the RTP HE for PDU set marking; a subset of bits comprised within a PDU set importance ‘PSF bitfield of the RTP HE for PDU set marking; a subset of bits determined by a bitmask; and an optional bitfield of the RTP HE for PDU set marking appended to the RTP HE for PDU set marking.

13. The application server of claim 12 wherein the at least one processor is configured to cause the application server to mark the at least one header of the at least one PDU setwithin the optional bitfield, wherein the at least one processor is further configured to cause the application server to: signal, the presence of the optional bitfield, using a session description protocol ‘SDP’ offer / answer procedure.

14. The application server of any one of claims 10-13 wherein the at least one processor is configured to cause the application server to dynamically select the AL-FEC configuration element based on at least one of: an availability of one or more network resources; one or more estimates of available network resources; a capability of the application server; a capability of the network entity; and one or more QoS requirements.

15. A user equipment ‘UE’ for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: receive one or more application data units ‘ ADUs’ of a media application; select, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; generate at least one protocol data unit ‘PDU’ set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU; mark at least one header of the at least one PDU set to indicate a respective value for the index of the selected AL-FEC configuration element; and transmit the at least one PDU set to a network entity.

16. The UE of claim 15, wherein the at least one header of the at least one PDU set comprises a real-time protocol ‘RTP’ header extension ‘HE’ for PDU set marking.

17. The UE of claim 16, wherein the at least one processor is further configured to cause the UE to mark the at least one header of the at least one PDU set by causing the UE to mark the at least one header within at least one of: a reserved bitfield of the RTP HE for PDU set marking; a subset of bits comprised within a PDU set importance ‘PSI’ bitfield of the RTP HE for PDU set marking; a subset of bits determined by a bitmask; and an optional bitfield of the RTP HE for PDU set marking appended to the RTP HE for PDU set marking.

18. The UE of claim 17 wherein the at least one processor is configured to cause the UE to mark the at least one header of the at least one PDU set within the optional bitfield, wherein the at least one processor is further configured to cause the UE to: signal, the presence of the optional bitfield, using a session description protocol ‘SDP’ offer / answer procedure.

19. The UE of any one of claims 15-18 wherein the at least one processor is configured to cause the UE to dynamically select the AL-FEC configuration element based on at least one of: an availability of one or more network resources; one or more estimates of available network resources; a capability of the application server; a capability of the network entity; and one or more QoS requirements.

20. A processor for wireless communication, comprising: at least one controller coupled with at least one memory and configured to cause the processor to: access one or more application data units ‘ADUs’ of a media application;select, from an indexed AL-FEC configuration, an AL-FEC configuration element, the indexed AL-FEC configuration mapping one or more AL-FEC configuration elements to an index; output at least one protocol data unit ‘PDU’ set based at least in part on coding at least one ADU of the ADUs by applying the selected AL-FEC configuration element, wherein each PDU set comprises at least one PDU; and output at least one header of the at least one PDU set to indicate a respective value for the index of the selected AL-FEC configuration element.

Images