Protocol data unit set signaling with application layer forward error correction in wireless communication networks

Abstract

Various aspects of this disclosure relate to an application server (AS) for wireless communication, comprising: at least one memory; and at least one processor coupled to the at least one memory and configured such that the AS: receives application data units (ADUs) of a multimedia application; decodes at least one ADU among the ADUs based at least in part on an application layer forward error correction (AL-FEC) configuration, wherein the set of PDUs includes at least one PDU; marks at least one PDU header of the set of PDUs to indicate the AL-FEC configuration applied to the set of PDUs; and transmits the set of PDUs.

Description

Technical Field

[0001] The subject matter disclosed herein generally relates to the field of implementing Protocol Data Unit (PDU) set signaling with Application Layer Forward Error Correction (AL-FEC) in wireless communication networks. Specifically, this document defines an application server (AS), a user equipment (UE), a processor, and a method performed by a means for wireless communication. Background Technology

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

[0003] The article “a(a)” preceding an element is not limited and should be understood to mean “at least one” or “one or more” of those elements. The terms “a,” “at least one,” “one or more,” and “at least one of one or more” are interchangeable. As used herein (included in the claims), “or” as used in a list of items (for example, a list of items followed by phrases such as “at least one of…” or “one or more of…” or “one or both of…”) indicates a list of inclusion, 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). Furthermore, as used herein, the phrase “based on” should not be construed as a reference to a set of closed conditions. For example, an exemplary step described as “based on condition A” could be based on both condition A and condition B without departing from the scope of this disclosure. In other words, as used herein, the phrase “based on” should be interpreted in the same manner as the phrase “at least partially based on.” Furthermore, as used herein (included in the claims), a “set” may contain one or more elements.

[0004] Therefore, this document provides an AS for wireless communication, comprising: at least one memory; and at least one processor coupled to the at least one memory and configured such that the AS: receives application data units (ADUs) of a multimedia application; generates at least one set of PDUs based at least in part on decoding at least one ADU of the ADUs by applying an AL-FEC configuration, wherein the set of PDUs includes at least one PDU; marks at least one PDU header of the set of PDUs to indicate the AL-FEC configuration applied to the set of PDUs; and transmits the set of PDUs.

[0005] A UE for wireless communication is further provided, comprising: at least one memory; and at least one processor coupled to the at least one memory and configured such that the UE: receives an ADU of a multimedia application; generates at least one PDU set based at least in part on decoding at least one ADU of the ADUs by applying an AL-FEC configuration, wherein the PDU set includes at least one PDU; marks at least one PDU header of the PDU set to indicate the AL-FEC configuration applied to the PDU set; and transmits the PDU set.

[0006] A further provided processor for wireless communication includes: at least one controller coupled to at least one memory and configured to: receive an ADU of a multimedia application; generate at least one PDU set based at least in part on decoding at least one ADU of the ADUs by applying an AL-FEC configuration, wherein the PDU set includes at least one PDU; mark at least one PDU header of the PDU set to indicate the AL-FEC configuration applied to the PDU set; and transmit the PDU set.

[0007] Further, a method performed by a device for wireless communication is provided, the method comprising: receiving an ADU of a multimedia application; generating at least one PDU set based at least in part on decoding at least one ADU of the ADUs by applying an AL-FEC configuration, wherein the PDU set includes at least one PDU; marking at least one PDU header of the PDU set to indicate the AL-FEC configuration applied to the PDU set; and transmitting the PDU set. Attached Figure Description

[0008] Figure 1 Illustrated examples of wireless communication systems according to various aspects of this disclosure.

[0009] Figure 2 Provides an overview of the Real-Time Transport Protocol (RTP) and Real-Time Transport Control Protocol (RTCP) stack.

[0010] Figure 3 This diagram illustrates an overview of the Web Real-Time Communication (WebRTC) stack.

[0011] Figure 4a and 4b The diagrams illustrate the packet format and header information for RTP packets and Secure RTP (SRTP) packets, respectively.

[0012] Figure 5 This diagram illustrates an overview of the core network extended reality and media (XRM) architecture used to handle PDU sets.

[0013] Figure 6 The diagram illustrates the 1-byte RTP header extension used for PDU set marking by AS.

[0014] Figure 7 The diagram illustrates the 2-byte RTP header extension used for PDU set marking by AS.

[0015] Figures 8a to 8d A diagram illustrating the 5G system (5GS) PDU set-aware Quality of Service (QoS) handling framework for mapping PDU sets to QoS flow to Data Radio Bearer (DRB).

[0016] Figure 9 This section presents the function of FEC frames (FECFRAME) and the application of various FEC decoding schemes.

[0017] Figure 10 Illustrated examples of implementing the core network XRM architecture described in this article.

[0018] Figure 11 A diagram illustrating the 1-byte RTP header extension used for PDU sets and AL-FEC information marking.

[0019] Figure 12 A diagram illustrating the 2-byte RTP header extension used for PDU sets and AL-FEC information marking.

[0020] Figure 13 Illustrated examples of UE 1300 according to various aspects of this disclosure.

[0021] Figure 14 Illustrated examples of processor 1400 according to various aspects of this disclosure.

[0022] Figure 15 Illustrated examples of the NE 1500 according to various aspects of this disclosure.

[0023] Figure 16 The diagram illustrates a flowchart of a method performed by a UE according to various aspects of this disclosure. Detailed Implementation

[0024] Wireless communication systems that include network communication devices (e.g., AS) and user communication devices (e.g., UE) can support grouping one or more logically related PDUs into PDU sets. A PDU set may contain the content of an ADU. One or more PDUs in a PDU set can be processed according to the same set of QoS parameters (e.g., requirements, constraints) (e.g., latency budget and error rate), while providing improved support for the radio access network (RAN) to achieve differentiated quality of service (QoS processing at the PDU set level and application-level content awareness). By enabling wireless communication systems to support processing these PDUs in a PDU set according to the same set of QoS parameters, wireless communication systems can improve the granularity of the 5G QoS flow framework, thereby allowing the RAN to improve the mapping between QoS flows and DRBs to meet the requirements of XR media requirements (e.g., high-rate transmission with shorter latency budgets).

[0025] Some wireless communication systems can support the delivery of immersive and interactive media content, such as in cloud gaming (CG) and virtual reality (VR), by applying over-forward error correction (FEC) or, alternatively, AL-FEC. By applying FEC or AL-FEC, these wireless communication systems can provide robust multimedia content delivery with reduced latency, thereby enabling applications with high bandwidth utilization (e.g., CG, VR, etc.) by avoiding higher-layer retransmissions and addressing network losses.

[0026] Various aspects of this disclosure relate to enabling one or more of a network communication device (e.g., AS) or a user communication device (e.g., UE) to output (e.g., transmit) or receive (e.g., receive) configuration and signals (e.g., notifications, indications) to the network to support QoS streaming using integrated PDU set processing and AL-FEC. For example, the configuration may include AL-FEC information and information elements (IEs) that extend PDU set processing to dynamic information containing redundant information added by the AL-FEC encoder and provide said dynamic information to the network (e.g., 5GS) to better process AL-FEC content under challenging network conditions (e.g., network congestion events, network service capacity interruptions, etc.).

[0027] Various aspects of this disclosure are described in the context of wireless communication systems.

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

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

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

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

[0032] UE 104 may be able to support direct wireless communication with other UE 104 via a communication link. For example, UE 104 may support direct wireless communication with another UE 104 via a device-to-device (D2D) communication link. In some implementations, 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, UE 104 may support direct wireless communication with another UE 104 via a PC5 interface.

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

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

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

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

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

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

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

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

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

[0042] The wireless communication system 100 can support various applications and services, in which multimedia streams are multiplexed within a single network application session related to XR (e.g., a 5-tuple containing a source Internet Protocol (IP) address, a destination IP address, a source network port, a destination network port, and a protocol number as an identifier). These applications and services are defined in 3GPP Technical Report (TR) 26.928v17.0.0 (April 2022), entitled “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 based on an RTP (RFC 3550) / SRTP (RFC 3711) protocol stack can include one or more video and audio streams multiplexed via a single application data network session with control and feedback metadata and application metadata (e.g., user gesture information, user input actions, etc.).

[0043] It should be noted that while some of the examples described herein relate to XR-related services and applications, it should be readily apparent that aspects of this disclosure are more generally applicable and can be used in a wide variety of other types of services and applications, including transport and network protocol stacks (e.g., Fast User Datagram Protocol Internet Connection (QUIC), WebRTC, WebTransport). Furthermore, XR can encompass one or more different types of reality; VR, Augmented Reality (AR), and Mixed Reality (MR) are examples.

[0044] VR involves a rendered version of a delivered visual and auditory scene. In this case, the rendering is designed to mimic the visual and auditory sensory stimuli of the real world as naturally as possible to the observer or user as they move within a range defined by the application. VR typically (but not necessarily) requires the user to wear a head-mounted display (HMD) to completely replace the user's field of vision with simulated visual components, and headphones to provide accompanying audio. Some form of head and motion tracking may be required in VR to allow updates to the simulated visual and auditory components, ensuring that objects and sound sources appear consistent with the user's movement from their perspective. In some implementations, additional means of interacting with virtual reality simulations may be provided, but this is not always necessary.

[0045] AR involves providing users with additional information or artificially generated items (e.g., objects), or content overlaid on their current environment. This additional information or content can be visual and / or auditory, and their observation of their current environment can be direct, without intermediate sensing, processing, and rendering, or it can be indirect, where their perception of their environment is transmitted via sensors and can be enhanced or processed. MR involves a higher form of AR in which virtual elements are inserted into a physical scene with the intention of providing the illusion that these elements are part of the real scene.

[0046] XR refers to all real-virtual environments and human-computer interactions created by computer technology and wearable devices. It includes representative forms such as AR, MR, and VR, as well as their interdisciplinary applications. The level of virtuality ranges from partial sensory input to fully immersive VR. In some cases, a key aspect of XR is considered an extension of human experience, particularly those related to presence (represented by VR) and cognitive acquisition (represented by AR).

[0047] XR video services can consist of multiple downlink (DL) and / or uplink (UL) video streams with high resolution (e.g., typically 1080p dual-buffered), frames per second (e.g., 60+ fps), and high bandwidth (e.g., 20 Mbps to 30 Mbps). These streams need to be transmitted across the network with minimal latency (e.g., within 10 ms to 15 ms) to maintain reduced end-to-end application round-trip latency and enable immersive digital world experiences. These latency-critical requirements are crucial given the dependencies of XR applications on cloud / edge processing (e.g., content download / distribution, viewport configuration, generation and updating, media encoding / transcoding, viewport rendering, etc.).

[0048] To support the latency-critical requirements inherent in high-bandwidth real-time communications (e.g., XR video streaming), the envisioned higher-layer protocol for delivering immersive XR multimedia applications is RTP. In some implementations, secure RTP variants, such as standard SRTP or web browser-based WebRTC stacks, can be used to serve XR applications across mobile communication networks (e.g., 5GS, etc.). RTP is a media codec-independent network protocol with application-layer framing for real-time delivery of multimedia (e.g., audio, video, etc.) over IP networks. It is used in conjunction with associated protocols for controlling RTCP to provide end-to-end features such as jitter compensation, packet loss and out-of-order delivery detection, synchronization, and source-stream multiplexing.

[0049] Figure 2 This provides an overview of the RTP and RTCP stacks. IP layer 205 carries signaling from data plane 210 and control plane 250. Data plane 210 stack may include one or more functions such as User Datagram Protocol (UDP) 212, RTP 216, RTCP 214, one or more media codecs 220, and quality control 222. Control plane 250 stack may include one or more functions such as UDP 252, Transmission Control Protocol (TCP) 254, Session Initiation Protocol (SIP) 262, and Session Description Protocol (SDP) 264.

[0050] SRTP is a secure version of RTP and provides encryption (e.g., payload confidentiality), message authentication and integrity (e.g., header and payload signing), and / or replay attack protection. As an associated protocol of SRTP, SRTCP supports the same functionality as RTCP. Thus, in SRTP, RTP header information remains accessible but not modifiable, while the payload is encrypted. For this reason, SRTP can be used in WebRTC stacks, ensuring secure RTC multimedia communication via web browser interfaces.

[0051] exist Figure 3This section provides an overview of the WebRTC stack. The IP layer carries signaling from the data plane and control plane. The data plane stack includes UDP, Interactive Connection Establishment (ICE), Datagram Transport Layer Security (DTLS), SRTP, SRTCP, media codecs, quality control, and Stream Control Transport Protocol (SCTP) functionality. ICE can use the Session Traversal Utilities for NAT (STUN) protocol and Traversal Using Relays around NAT (TURN) to handle real-time media content delivery across heterogeneous networks and NAT rules. Regarding real-time information delivery, data carried via SCTP can be non-time-critical, while SRTP, SRTCP, media codecs, and quality control data can be time-critical.

[0052] like Figure 3 The diagram illustrates that IP layer 305 carries signaling from data plane 310 and control plane 350. Data plane stack 310 includes functions such as UDP 312, Interactive Connection Establishment (ICE) 324, Datagram Transport Layer Security (DTLS) 326, SRTP 317, SRTCP 315, media codec 320, quality control 322, and SCTP 328. ICE 324 can use the NAT Session Traversal Utility (STUN) protocol and NAT traversal using relays (TURN) to address real-time media content delivery across heterogeneous networks, NAT rules, and firewalls. SCTP data plane 728 is primarily dedicated to application data channels and can be non-time-critical. SRTP-based stack 317 and control elements (i.e., SRTCP 315), encoding (i.e., media codec), and Quality of Service (QoS) (i.e., quality control) are dedicated to time-critical deliveries. The control plane 350 stack includes the functionality of TCP 354, Transport Layer Security (TLS) 356, Hypertext Transfer Protocol (HTTP) 358, WebSocket 366, SIP 362, SDP 364, Server Send Event (SSE) 368, and Extensible Message Delivery and Presence Protocol (XMPP) 370.

[0053] Regarding both RTP and SRTP, header information can be used for inspection and processing. An overview and brief descriptions of individual fields are provided in Figure 4 below. Figure 4a and 4b The RTP / SRTP header information can be summarized as consisting of a fixed header information of the first 12 bytes containing header information, additional header information about the contributor source (CSRC) identifier of the media stream, and optional RTP extension headers.

[0054] Figure 4a The diagram illustrates the packet format and header information for RTP packet 430. Figure 4b The diagram illustrates the packet format and header information for SRTP packet 460. The following section further discusses individual fixed header information and the complete header information (including header extensions) for RTP / SRTP packets. Note that the fixed header information includes "V" 432, 462, "P" 433, 463, "X" 434, 464, "CC" 436, 466, "M" 438, 468, "PT" 440, 470, "Serial Number" 442, 472, "Timestamp" 444, 474, "Synchronization Source (SSRC) Identifier" 446, 476, and "Contribution Source (CSRC) Identifier" 448, 478.

[0055] The fixed header information includes “V” 432, 462, “P” 433, 463, “X” 434, 464, “CC” 436, 466, “M” 438, 468, “PT” 440, 470, “Serial Number” 442, 472, “Timestamp” 444, 474, “Synchronization Source (SSRC) Identifier” 446, 476, and “Contribution Source (CSRC) Identifier” 448, 478.

[0056] “V”432 and 462 are two bits that indicate the protocol version used.

[0057] “P”433, 463 is a 1-bit field that indicates the presence of one or more zero-padding octets at the end of the payload, thereby (among other things) padding may be necessary for fixed-size encrypted blocks or for carrying multiple RTP / SRTP packets on lower-level protocols.

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

[0059] “CC” 436, 466 are 4-bit fields that indicate the number of contributing media sources (CSRC) that follow the fixed header.

[0060] “M” 438, 468 is a 1-bit symbol intended to mark the boundaries of information frames in the packet stream. Its behavior is precisely specified by the RTP profile (e.g., H.264, H.265, H.266, AV1, etc.).

[0061] “PT” 440, 470 are 4 bits that indicate the payload type. In the case of video profiles, they are dynamic and negotiated with the aid of SDP (e.g., 96 for H.264, 97 for H.265, 98 for AV1, etc.).

[0062] The "sequence number" 442 and 472 are 16 bits, which indicate the sequence number and increment by 1 within the session with each RTP packet sent.

[0063] The "timestamp" 444 and 474 are 32 bits. They indicate the timestamp in the number of ticks of the payload type clock and reflect the sampling time of the first octet of the RTP packet (for video streams, associated with the video frame). The first timestamp of the first RTP packet is randomly selected.

[0064] The “Synchronization Source (SSRC) Identifier” 446 and 476 are 32-bit fields that indicate a random identifier of the source of an RTP packet stream that forms part of the same timing and sequence number space, allowing the receiver to group packets based on the synchronization source for playback.

[0065] "Contribution Source (CSRC) Identifier" 448, 478 is a list of up to 16 32-bit CSRC entries, each CSRC entry giving the amount of CSRC mixed by the RTP mixer within the current payload, as signaled by the CC bit; given the CSRC identifier of the contribution source, the list identifies the contribution source of the payload contained in this packet.

[0066] Complete header information (including header extensions) includes "RTP header extensions" 448 and 478.

[0067] "RTP Header Extension" 448, 478 is a variable-length field, which exists if an X-bit is marked; the header extension is appended to the RTP fixed header information (if present) after the CSRC list; the RTP header extension is 32-bit aligned and consists of the following fields:

[0068] • A 16-bit extended identifier defined by a brief and typically negotiated and determined via the SDP signaling mechanism;

[0069] • A 16-bit length field describing the extended header length in multiples of 32 bits, wherein the extended header length does not include the first 32 bits corresponding to the 16-bit extended identifier and the 16-bit length field itself; and

[0070] • A 32-bit aligned header extension raw data field formatted according to the format specified by a certain RTP header extension identifier.

[0071] In this document, a video frame may be referred to as a video-decoded representation of a still image presented in a sequence comprising a video stream. Alternatively, a video frame may consist of one or more video segments. A video segment is a decoded video representation of a segmented region of a still image portion of a video sequence. In some embodiments, a video segment may be referred to as a rectangular segment (e.g., an image patch) of a still image (e.g., H.266, AV1), thereby in other embodiments, a video segment may be a raster-scanned segment of a still image (e.g., H.264, H.265, H.266, etc.). Similarly, we refer to a video layer as a video-decoded element, either as a temporal video layer designed to increase the frame-per-second resolution and temporal detail level of a video sequence, or as a spatial video layer designed to increase the number of video-decoded pixels and the spatial resolution of individual video frames. The abstract concepts of video frames, video segments, and / or video layers apply to modern hybrid video codecs of the MPEG family (i.e., H.264 / H.265 / H.266), as well as other open video codecs such as AV1 or VP9. The encapsulation format for video decoded data into RTP / SRTP payloads is specified by Internet standards for each individual video codec. For example, it is specified by RFC 6184 for H.264, by RFC 7798 for H.265, and by the RTP payload format for AV1 (aomediacodec.github.io) for AV1.

[0072] Note that for XR applications, the media codecs used and their configuration / configuration updates depend on the application implementation, and these are typically negotiated between the transmitter and receiver immediately after session establishment / update (e.g., RTP / SRTP). For this purpose, Session Description Protocol (SDP) signaling is used either as a standalone signaling procedure or as part of SIP.

[0073] 3GPP Release 18 introduced the concept of a PDU set in the XR Media (XRM) feature at the CN layer, enabling finer-grained handling of QoS requirements for XRM applications and flows beyond the 5GRel-17 QoS flow possibilities. Thus, according to 3GPP Technical Report TR 23.700-60 (v0.0.3), a PDU set consists of one or more PDUs carrying the payload of a single information element (e.g., a frame or video segment for XRM services) generated at the application layer. In some implementations, the application layer requires all PDUs in the PDU set to use the corresponding information element. In other implementations, the application layer can recover some or all of the information elements even if some PDUs are lost.

[0074] Additionally, PDU sets are associated with QoS requirements regarding latency budget and error rate, which can be defined as the PDU set latency budget (PSDB) and / or the PDU set error rate (PSER), as defined in 3GPP Technical Report TR 23.700-60 (v0.0.3-May 2022) entitled "Study on XR (Extended Reality) and media services" and 3GPP Technical Specification TS 23.501 (v18.1.0-April 2023) entitled "System architecture for the 5G System (5GS)". The PDU set latency budget (PSDB) defines the upper limit of the time that a PDU set may be delayed between the UE and the N6 terminal point at the UPF. The PSDB applies to DL PDU sets received by the UPF via the N6 interface and UL PDU sets transmitted by the UE. The PDU Set Error Rate (PSER) defines an upper limit on the ratio of PDU sets (e.g., the set of IP packets that make up the PDU set) that have been processed by a transmitter of a link-layer protocol (e.g., an RLC in a 3GPP-accessible RAN). The PSER can be used to determine an upper limit on the ratio of non-congestion-related packet loss.

[0075] In addition, the PDU set for each QoS flow can be configured with PDU Set Integration Handling Information (PSIHI), which indicates whether all PDUs in the PDU set of the flow are required for use by XR applications, see 3GPP Technical Specification TS 23.501 (v18.4.0 – December 2023) System Architecture for 5G Systems (5GS).

[0076] Figure 5 This diagram illustrates an overview of the core network (CN) XRM architecture for handling PDU sets. Figure 5 The demonstration system 500 includes Extended Reality Media Application Functions (XRM AF) 510, Policy and Control Functions (PCF) 515, Session Management Functions (SMF) 520, Access and Mobility Functions (AMF) 525, Radio Access Network (RAN) 530, User Equipment (UE) 535, User Plane Functions (UPF) 540, and Extended Reality Applications 545. The operation of System 500 will now be described with an example of downlink service; a similar process can be performed for uplink service.

[0077] At position 580, XRM AF 510 determines the PDU set requirements.

[0078] At position 581, XRM Application Function 510 provides PCF 515 with QoS requirements for packets in the PDU set, as well as information for identifying the application (i.e., a 5-tuple or application ID). QoS requirements may include PSDB and PSER. XRM AF 510 may also include importance parameters for the PDU set and information that enables the core network to identify packets belonging to the PDU set.

[0079] At position 582, PCF 515 exports QoS rules for XR applications and specific QoS requirements for PDU sets, and configures SMF 520. The QoS rules can use the 5G QoS Identifier (5QI) for XR media services. PCF 515 sends the QoS rules to SMF 520. PCF 515 may include PCC rules based on the importance of the PDU set in its communications to SMF 520. PCC rules may be exported based on information received from XRM AF 510 or based on operator configuration.

[0080] At position 583, the SMF 520 establishes a QoS flow based on the QoS rules of the PCF 515 and configures the UPF to route XR application packets to the QoS flow. Additionally, PDU set processing is enabled. The SMF 520 also provides a QoS profile containing PDU set QoS requirements to the RAN 530 via the AMF 525. The AMF 525 can provide a QoS profile containing PDU set QoS requirements to the RAN 530 in the N2 SM container. Furthermore, the AMF 525 can provide QoS rules to the UE 535 in the N1 SM container.

[0081] At position 584, UPF 540 examines the packet and determines that it belongs to the PDU set. This determination may be based on a given UPF implementation (e.g., by examining the RTP packet header), as described in 3GPP Technical Specification 23.501 v18.2.2 (June 2023) entitled "System Architecture for 5G Systems (5GS)", or on PDU set information with AS markings transmitted via RTP PDU set header extensions, as described in 3GPP TS 23.501 v18.2.2 and 3GPP Technical Specification 26.522 v0.1.1 (September 2023) entitled "5G Real-time Media Transport Protocol Configurations" (i.e., urn:3gpp:pdu-set-marking:rel-18). Packet inspection may include examining RTP packets. When the UPF 540 detects a packet belonging to a PDU set, it marks the packet as belonging to the PDU set within the GTP-U header. The GTP-U header information includes the PDU set sequence number and the size of the PDU set. The UPF 540 can also determine the importance of the PDU set based on the UPF 540 implementation method, information provided by the XRM AF 510, or information provided as metadata from the XRM application server. Based on the importance of the PDU set, the UPF 540 can route traffic to the corresponding QoS flow 1 (according to rules received from the SMF 520) or include the importance of the PDU set in the GTP-U header. QoS flow 1 may include GTP-U headers, which may contain PDU set information.

[0082] At 585, RAN 530 identifies packets belonging to a PDU set (based on GTP-U tags) and handles the packets according to the QoS requirements of the PDU set provided by SMF 520. In one implementation, the RAN 530 node may use different radio bearers with higher QoS requirements (based on PDU set PSDB / PSER) to guarantee the delivery of packets for the PDU set, while using different radio bearers based on the 5QI for QoS flows of non-PDU set packets.

[0083] The above examples pertain to downlink (DL) services. Reciprocal processing applies to uplink (UL) services, where the role of UPF540 packet inspection is undertaken by UE 535. The UE is expected to inspect uplink packets, determine packets belonging to the PDU set, and accordingly signal the PDU set to RAN 530 for scheduling and resource allocation corresponding to the associated DRB that meets the PDU set's QoS requirements (i.e., PSDB and PSER). The low-level signaling mechanism associated with UL UE-RAN information transmission depends on the RAN signaling procedure specifications and implementation.

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

[0085] The PDU set information includes:

[0086] • PDU set sequence number.

[0087] • Indication of the end of the PDU set.

[0088] • PDU sequence number within the PDU set.

[0089] • Size of the PDU set in bytes.

[0090] • PDU set importance, which identifies the relative importance of a PDU set compared to other PDU sets within a QoS flow.

[0091] Then, the PDU set information is used by NG-RAN for QoS processing based on the PDU set, as described above.

[0092] In the event of congestion, NG-RAN can use priority levels across QoS flows and the importance of PDU sets within a QoS flow to perform packet drop at the PDU set level. Such priority levels are described in Clause 5.7.3.3 of 3GPP TS 23.501 v18.2.2.

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

[0094] The protocol description indicates the transport protocol used by the service data stream (e.g., RTP, SRTP) and additional information, such as:

[0095] • RTP or SRTP;

[0096] • RTP or SRTP with RTP header extensions, which include:

[0097] • RTP header extensions for PDU set marking, as defined in RFC 3550 - RTP: A Transport Protocol for Real-Time Applications (ietf.org) and as in Figure 6 or Figure 7 As shown in the figure, it will be discussed in detail below.

[0098] • Other RTP header extensions based on the RFC 8285 format;

[0099] • RTP or SRTP that does not have an RTP header extension but shares the same RTP payload format (e.g., H.264 or H.265);

[0100] • Has RTP header extensions for PDU set marking (as defined in [Ref-6] and as in Figure 5 or Figure 6 RTP or SRTP (as shown in the image) that both have an RTP payload format (e.g., H.264 or H.265); and / or

[0101] • RTP or SRTP with other RTP header extensions based on the RFC 8285 format and sharing the same RTP payload format (e.g., H.264 or H.265).

[0102] When RTP header extensions for PDU set marking are included (such as those defined in RFC 3550 - RTP: Transport Protocol for Real-Time Applications (ietf.org)) or other RTP header extensions based on RFC 8285, differentiation between different RTP header extension types is supported. Additionally, when RTP payload formats are included, differentiation between different RTP payload formats is supported.

[0103] In some embodiments, the AS PDU set information listed above is provided via a single-byte RTP header extension for identifying the PDU set, see U.S. Provisional Application 63 / 428,026 entitled "PDU Set-Aware Multimedia Applications and Associated Signaling" by Stoica et al., Applicant's Reference SMM920220198-US-PSP, and as in the above-mentioned... Figure 6 The diagram illustrates the burst termination as defined in 3GPP technical specification TS 26.522 v0.1.1 (September 2023).

[0104] Figure 6 The diagram illustrates the 1-byte RTP header extension used by the AS for PDU set marking according to 3GPP TS 26.522 v0.1.1.

[0105] Similarly, Figure 7 The diagram illustrates the 2-byte RTP header extension used by the AS for PDU set marking according to 3GPP TS 26.522 v0.1.1.

[0106] RTP header extensions used to mark PDU sets and burst termination are in Figure 6 and Figure 7 The semantics of the fields represented in the document are as follows.

[0107] The last PDU in the PDU set [E] (1-bit field) 632 and 732 are flags that set the last PDU in the PDU set to 1 and all other PDUs in the PDU set to 0.

[0108] Reserved fields [R] (2-bit fields) 633 and 733 are reserved fields for future use.

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

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

[0111] PDU Set Serial Number [PSSN] (10-bit field) 636, 736 encodes the serial number of the PDU set to which the current PDU belongs, and is used as a 10-bit numeric identifier of the PDU set, wrapping around at 1023.

[0112] The PDU Sequence Number [PSN] (6-bit field) within the PDU set indicates the sequence number of the current PDU within the PDU set. The PSN is set to 0 for the first PDU in the set and monotonically increments for each PDU in the set in the order it was transmitted from the transmitter. The PSN wraps around at position 63.

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

[0114] The PDU count in the PDU set [NPDS] (16-bit) 639 and 739 represent the number of PDUs within the PDU set, indicating the total number of PDUs belonging to the same PDU set. This field is optional and subject to SDP signaling proposal / response negotiation, where the application server can indicate whether it will be able to provide the number of PDUs within the PDU set for the RTP stream. When the PDU set size field exists, it is recommended to add the PDU count to the PDU set field.

[0115] The above examples pertain to downlink (DL) services. Reciprocity processing applies to the UL, while the role of UPF packet inspection is undertaken by the User Equipment (UE). The UE is expected to inspect packets, determine packets belonging to the PDU set, and accordingly signal the PDU set to the RAN for scheduling and resource allocation corresponding to the associated DRB that meets the QoS requirements of the PDU set (i.e., PSDB and PSER). The low-level signaling mechanisms associated with UL UE-RAN information transfer depend on the specifications and implementation of the RAN signaling procedures and rely on Buffer Status Report (BSR) and Delay Status Report (DSR) procedures.

[0116] Figures 8a to 8dFigure 8 illustrates a 5GS PDU set-aware QoS handling framework for mapping PDU sets to QoS flows to DRBs. Depending on the QoS flow mapping and RAN procedures, given two different PDU sets with different PDU set attributes (e.g., PDU set importance), several alternative PDU set-to-QoS flow-to-DRB mappings are possible. Figure 8 illustrates some options where two PDU sets 810 of different importance and characteristics are mapped to QoS flows 820 and respectively mapped to Data Radio Bearers (DRBs) 830. In this example, PDU set 1 is considered to have high importance with strict QoS requirements (i.e., PSDB, PSER, etc.), and PDU set 2 is considered to have low importance with potentially lower QoS requirements than PDU set 1 (i.e., PSDB, PSER, etc.). As illustrated in Figure 8, depending on the QoS flow policy and Layer 2 RAN procedures, the PDU set 810 to QoS flow 820 to DRB 830 can be illustrated as follows.

[0117] Figure 8a The diagram illustrates the 1-to-1 mapping: Thus, the separation of QoS flows 820 and DRB 830 between high-importance PDU sets 810 and low-importance PDU sets 810 is complete, thereby finely optimizing radio and network resources on a per-PDU-set basis.

[0118] Figure 8b The diagram illustrates the M-to-M-to-1 mapping: This separates the high-importance PDU set 810 from the low-importance PDU set 810 only at the QoS flow level, while the same DRB 830 is used for over-the-air transmission of both PDU sets 810. This may result in over-provisioning of radio resources for the low-importance PDU set 810, but requires lower RAN complexity and management overhead.

[0119] Figure 8c The diagram illustrates the M-to-1 mapping: As a result, there is no separation between the QoS flows 820 and DRB 830 of different importance PDU sets 810, and when handling QoS management across both CN and RAN, the QoS requirements of higher importance PDU sets are given priority; this may result in over-provisioning of resources for low importance PDU sets 810 in CN and RAN implementations, but requires lower overhead and control within the 5GS QoS framework.

[0120] Figure 8dThe diagram illustrates the M-to-1-to-M mapping: Thus, there is no separation across QoS flows 820 between the importance levels of each PDU set, but different DRBs 830 are used to meet the individual requirements of different importance levels; this compromises the complexity of QoS flow management and uses PDU set information to filter PDU sets 810 on different DRBs 830 to better match RAN-level QoS requirements and optimize resource allocation based on individual PDU set needs.

[0121] In various interactive XR applications, AL-FEC can be used as a method to address congestion and packet loss. This use leverages multicast, broadcast topology, and unicast path diversity at the network routing level or physical layer (e.g., in 5GS, this would be applicable to dual connectivity (DC), carrier aggregation (CA), and multiple TRP transmissions). This is applicable to, for example, 1D / 2D parity check codes (e.g., RFC 8627), Raptor codes (e.g., RFC 5032), RaptorQ codes (e.g., RFC 6330), and LDPC ladder codes (e.g., RFC 6816).

[0122] The General Forward Error Correction Framework (FECFRAME) has been defined by the IETF as RFC 6363, which allows various FEC schemes to be applied to AL-FEC. FECFRAME specifies the source packet and repair packet formats and FEC scheme configuration procedures for AL-FEC at the transport layer (e.g., UDP) and at the RTP layer or similar layers (e.g., WebRTC).

[0123] Figure 9 This paper presents the role of FECFRAME and the application of various FEC decoding schemes. Figure 9 This provides a diagrammatic illustration of the AL-FEC XR application flow 900, which includes encoding, packetization, and transmission. Flow 900 is executed by the application 910, FECFRAME 920, AL-FEC generation block, transport layer 930, and FEC scheme 940. Transport layer 930 can use UDP.

[0124] In some embodiments, the popular AL-FEC decoding scheme is Raptor decoding (RFC 5032) due to its efficient encoding / decoding, or alternatively, in other embodiments, its optimized version, RaptorQ decoding (RFC 6330). Applied to the context of FECFRAME, Raptor / RaptorQ encodes RTP packets according to RFC 6881 and RFC 6882. FEC scheme 940 may include Raptor or RaptorQ. Process 900 includes the following steps.

[0125] At 971, the transmitter identifies a set of source packets (e.g., RTP source packets) representing an ADU as a source block and performs joint protection on the source block based on AL-FEC decoding configuration, such as FECFRAME configuration information, which includes:

[0126] • FEC scheme identifier,

[0127] • Maximum source block length (MSBL) of Raptor / RaptorQ, or alternatively K_max,

[0128] • Code symbol size (i.e., the T parameter used in the Raptor / RaptorQ decoding scheme),

[0129] • Repair window duration (i.e., the maximum time, in milliseconds and / or microseconds, for the transmission across the source packet and the corresponding repair packet, where the transmission point is considered the downstream interface of the received encoded PDU).

[0130] At 972, the transmitter arranges the source packet (e.g., an RTP source packet) into a set of source symbols of the same size (which can represent smaller segments of source symbols of a configured size that can represent the source packet data).

[0131] At 973, the transmitter applies an FEC coding scheme (e.g., Raptor / RaptorQ / Reed-Solomon / 2D parity code) based on the AL-FEC configuration (e.g., FECFRAME configuration information) to produce the required number of repair symbols.

[0132] At 974, the transmitter performs the action of splitting the repair symbol into repair packets (e.g., RTP repair packets according to RFC 6882) and sending the repair packets and source packets to the receiver.

[0133] According to the FECFRAME requirement (i.e., RFC 6363), the transmitter should transmit source packets and repair packets in separate source and repair streams (e.g., RTP streams) to allow for legacy (non-FEC) application processing of source packets similar to any system code.

[0134] At position 975, the receiver receives the source packet and the repair packet.

[0135] If all source packets are successfully received, then FEC recovery is not required and the FEC repair package can be discarded.

[0136] However, if a source packet is missing, a repair packet can be processed and used to recover the lost information within a waiting period corresponding to at least the repair window time configured by the application FEC configuration.

[0137] For example, the source PDU (e.g., source RTP PDU) may be required to contain an additional suffix indicating the payload ID. This can then be used on the receiver side to determine whether the encoded PDU is lost and, based on the available encoded PDUs (i.e., the source PDU or the repair PDU), to help select and use the correct recovery slot to decode the lost packet. In many embodiments where RTP / SRTP is used, this information is readily available as part of the RTP / SRTP sequence number, which acts as the payload ID replacement. In such embodiments, similar to any system decoding procedure, the source RTP / SRTP packet generated by FECFRAME encoding is transmitted without modification. For example, this provides backward compatibility for receivers that do not support AL-FEC. For example, a scheme for encoding the source PDU and repair PDU into RTP / SRTP packets may therefore use the sequence number of the original RTP / SRTP source packet as the payload ID replacement (e.g., for Raptor / RaptorQ codes, in the single-sequence stream encoding mode according to RFC 6681). Therefore, this indicates that encoding the repair of the dependencies of RTP / SRTP packets on the jointly encoded RTP / SRTP source packet blocks helps the decoder endpoint to perform efficient decoding.

[0138] Alternatively, other general AL-FEC-based content delivery protocols consistent with RFC 5052 (i.e., the Forward Error Correction (FEC) building block) can be considered. Similar to the FECFRAME scheme, Application Data Units (ADUs) are not sent directly to the network but are added to the source block AL-FEC encoder. The encoder systematically encodes and produces packets of equal size (containing repair packets) to add redundancy before distributing the content. ADUs (e.g., video frames, video clips, or alternatively general objects) are assigned a size F and some additional properties (e.g., the type of the ADU—video, audio, etc., its importance, its latency constraints, etc.). ADUs are divided into source blocks with K coded symbols, each of size T. The coded symbols form the payload of K source packets, resulting in at most one set of NK desired repair packets, each repair packet containing the source block size K and the coded symbol Id (ESI). Each repair packet may further contain some ADUs and encoding operation properties (e.g., additional encoding parameters required to construct a particular repair packet, etc.). Additionally, the size F of the ADU can be carried as part of the source block. Thus, K source packets and NK repair packets constitute the AL-FEC encoded content of the ADU and can be sent and processed as a single ADU. Therefore, the source packets and repair packets will share a common Transport Object Identifier (TOI). Parameters F, K, T, and N are AL-FEC encoding parameters.

[0139] The FEC payload ID (i.e., the information carried in the header of each packet) essentially only needs to carry the ESI, and the source block size K is fixed for a given T. As an example, for RaptorQ as defined in RFC 6330 RTP Frame Marking RTP Header Extension (November 2021) - draft-ietf-avtext-framemarking-13, the maximum source block size is 56403, meaning 16 bits are sufficient to encode the size K. It is also expected that signaling the ESI, 1 or 2 bytes will be sufficient for most applications. Alternatively, the TOI can be carried as described above, again using 1 or 2 bytes. Although the above FEC configuration is used for reference only, it can be considered a typical implementation.

[0140] Typically, at the receiver, if one or more packets associated with an ADU are lost, a maximum delay for the ADU needs to be set (usually compared to the rendering time). After this, only received packets are processed as part of the ADU. In the case of Maximum Distant Separable (MDS) codes (i.e., codes that satisfy the Singleton Bound, such as Reed-Solomon codes or alternatively, the Raptor code family), the ADU can be fully recovered if at least K packets are received for the ADU within the time budget. If fewer than K packets are received, the ADU cannot be recovered, and one of the following two error handling modes can be applied immediately after configuration:

[0141] • ADU Loss: If more than NK packets associated with an ADU are lost, then the entire ADU is lost.

[0142] • Suffix loss: If more than NK packets are lost in the packets associated with the ADU, then only the correct prefix prior to the first loss of the source packet is used to generate a partially received ADU.

[0143] The recovery properties of the Raptor / RaptorQ FEC scheme are determined by probability from any K + h decoded source packets or repair packets. K encoded source packets are recovered, where each encoded symbol corresponds to an encoded packet. This means that the probability of recovering K encoded source symbols (where only K+1 encoded packets are received) from a set of N encoded source packets and a repair packet is essentially 99.99%, which is very high. In other embodiments, the encoded packet corresponds to more than one encoded symbol, maintaining a high recovery probability even after packet splitting, thus allowing Raptor / RaptorQ codes to achieve strong error correction performance.

[0144] Based on the above, when ADUs are systematically AL-FEC encoded, the PDU set consists of the source PDU corresponding to the original uncoded ADU and its corresponding repair PDU, as described, for example, in Greek Patent Application No. 20220100751 by Stoyka et al. [Applicant Reference No.: SMM920220119-GR-NP]—“Efficient Transmission of PDU Sets in a Wireless Communication Network”. In the case of a non-systematic AL-FEC scheme, the PDU set is formed by AL-FEC encoded ADUs, including their parity check or alternative repair / redundant PDUs.

[0145] If the RAN is PDU set-aware and AL-FEC-aware, it can dynamically optimize system capacity and delivery of PDU sets, including AL-FEC-coded ADUs, to meet DRB QoS requirements by discarding irrelevant or redundant content. For example, in a congested situation, the RAN may discard some, up to NK, PDUs from the PDU set, excluding some repair PDUs or alternatively redundant PDUs. Similarly, when the RAN detects that it cannot transmit any PDUs sufficient to constitute at least K coded PDUs, it may discard all PDUs from the PDU set, including AL-FEC-coded ADUs, where K represents the number of source PDUs and NK represents the number of repair / redundant PDUs. These RAN policies, along with associated signaling and procedures, are described in Greek Patent Application No. 20220100751.

[0146] The radio layer needs to understand the instantaneous decoding overhead on a per-PDU set basis in order to perform radio-level optimization in terms of resource allocation, as described in Greek Patent Application No. 20220100751, for example, discarding unnecessary PDUs in the AL-FEC-coded PDU set, or dropping the AL-FEC-coded PDU set, etc., in congestion situations or when ADUs cannot be recovered. The UPF can signal this information to the RAN via the GTP-U header (i.e., in the DL direction), or alternatively, the UE can identify and determine the PDU set information regarding the service entry at the access layer (i.e., in the UL direction), as described in Greek Patent Application No. 20220100750 [Applicant Reference No.: SMM920220118-GR-NP] entitled "Signalling PDU Sets with Application Layer Forward Error Correction in a Wireless Communication Network" by Stoyka et al. However, relying on the UPF or alternatively the UE to determine the PDU set based solely on the UPF / UE implementation can lead to complex and inefficient UPF / UE processing and requires significant configuration overhead to achieve UPF-specific and UE-specific PDU set identification.

[0147] The solution proposed in this paper uses an AL-FEC information source, namely a multimedia transmitter or, alternatively, an RTP transmitter / AL-FEC encoder, to provide the necessary AL-FEC information to the RAN, thereby enabling RAN optimization and efficient processing. Such a solution can be implemented using low-complexity UPF and UE nodes. The solution presented in this paper has the added benefit that the AL-FEC decoder is placed at the application layer, and provided the AL-FEC decoding scheme is an MDS (e.g., Reed-Solomon codes) or has asymptotic MDS characteristics (e.g., Raptor / RaptorQ codes, or a family of random linear network codes (RLNC) with at least 2^8 letters), the RAN and core network only require information about the PDU set boundaries and the redundancy level of the PDU set to operate efficiently, as described in Greek Patent Application No. 20220100751. Therefore, this MDS assumption simplifies the necessary configuration for efficient AL-FEC support on 5GS and is actually more common for the extensive erasure error correction decoding schemes typical of AL-FEC (e.g., Reed-Solomon, Raptor / RaptorQ, and some recent RLNC codes). In addition to the multimedia transmitter labeling the PDU set with PDU set information associated with the AL-FEC encoded PDU set content, 5GS networks can enable support for AL-FEC features. This can be done through simple configuration options (e.g., at least marking an AL-FEC enabled flag), which are embedded as part of the protocol description associated with the user plane content distribution protocol (e.g., RTP / SRTP, WebRTC) used by the multimedia transmitter.

[0148] Figure 10 Illustrated examples of implementing the core network XRM architecture described in this article. Figure 10 This document demonstrates a DL implementation of a generally proposed solution for QoS flows, where the AS identifies the PDU set with PDU set information and AL-FEC within the Content Delivery Protocol header, and the UPF relays the information to the gNB via the GTP-U header across 5GS, given the AL-FEC information element of the protocol description associated with the QoS flow, as configured by the SMF. The protocol description can be configured via application logic (e.g., at the UE) through requests to the Media Session Handler Dynamic Policy API.

[0149] Figure 10 The advanced illustration of the solution presented is based on DL services (i.e., from AS to UE). Those skilled in the art should understand that the PDU set identification method from the UPF (i.e., Figure 10The PDU set module (highlighted in the image) can be applied to the UE, where UE-to-gNB communication does not directly indicate the PDU set and / or AL-FEC information (e.g., GTP-U tunnels directly indicate the PDU set and / or AL-FEC information via the N3 interface between the UPF and gNB). Instead, it relies on a UE Delay Status Report (DSR) / Buffer Status Report (BSR) procedure to inform the gNB about the delay / buffer status associated with the PDU set of the DRB, or alternatively, the QoS flow, and accordingly, to inform about the UE discard procedure for AL-FEC, which, for example, utilizes the redundancy level identified in each PDU set to discard PDUs for efficient radio resource utilization, based on the PDU discarding solution described in Greek Patent Application No. 20220100751. In the DL direction, the gNB can determine (e.g., similar to the UE) a discarding strategy associated with the QoS flow and its QoS requirements based on the implementation scheme.

[0150] Figure 10 The demonstration system 1000 includes Extended Reality Media Application Functions (XRM AF) 1010, Policy and Control Functions (PCF) 1015, Session Management Functions (SMF) 1020, Access and Mobility Functions (AMF) 1025, Radio Access Network (RAN) 1030, User Equipment (UE) 1035, User Plane Functions (UPF) 1040, and Extended Reality Applications 1045.

[0151] In System 1000, the AL-FEC encoded data associated with I-frames of video content is displayed as a striped pattern, the data associated with P-frames of video content is displayed as a grid (hash) pattern, and the data associated with B-frames of video content is displayed as a dotted pattern. The operation of System 1000 will now be described in an example of downlink service; a similar process can be performed for uplink service.

[0152] At 1070: AF (e.g., as...) Figure 10 The XR AF 1010 illustrated in the diagram requests an AS session with QoS requirements from the network via the PCF / NEF N5 / N33 interface and associated API. QoS requirements can be mapped to a specific 5-tuple / IP flow (i.e., consisting of source / destination IP addresses, source / destination ports, and protocol) and may include application-specific requirements for latency budget and rate allocation. The AF request may further include information elements (e.g., protocol descriptions) associated with the corresponding AS (e.g., such as...). Figure 10The PDU set tagging configuration and AL-FEC configuration described in the XR video application (AS) with AL-FEC enabled are related. The AF indication that the session may contain AL-FEC encoded PDU sets may include information about the AL-FEC decoding configuration used.

[0153] At 1071: PCF 1015 determines QoS rules given an AF request and corresponding configuration for an AS QoS session. PCF 1015 can determine whether UPF 1040 needs to detect PDU set size changes exceeding a certain threshold. This threshold can be configured based on operator preferences. QoS rules may include PCC rules and are partly based on the requested QoS session parameters and / or operator configuration to accommodate the application's PSDB / PSER requirements. PCC rules contain and provide information (e.g., protocol descriptions of the protocols used, PDU set tags, and AL-FEC enabled configuration) and are signaled to the SMF. PCC rules may include PSDB, PSER, and PSIHI requirements, as well as AL-FEC awareness and support.

[0154] At 1072: SMF 1020 establishes QoS flows based on QoS rules provided by PCF 1015.

[0155] At 1072a.: SMF 1020 further configures UPF 1040 to route packets from XR applications to the established QoS flow, and additionally, enables PDU set handling with AL-FEC support based on the PDU set marked by AS and AL-FEC information. For example, the N4 rule can define how to detect PDU set and AL-FEC dynamic information.

[0156] At 1072b.: SMF 1020 also provides RAN 1030 with a QoS profile containing QoS requirements for a set of PDUs via AMF 1025, and also indicates to the AMF that the source will provide an AL-FEC encoded set of PDUs. The QoS profile may indicate that the AL-FEC feature is enabled.

[0157] At step 1073: AMF 1025 signals to the radio layer the QoS profile of the SMF necessary to meet the application QoS requirements. AMF 1025 further instructs the source corresponding to the QoS flow to apply AL-FEC coding. In step 1073a, this is instructed to RAN 1030 (e.g., gNB) to allow RAN to perform radio resource optimization using AL-FEC awareness (e.g., based on an indication of a GTP-U header field containing AL-FEC information for the PDU set used for the QoS flow). AMF 1025 may signal to RAN 1030 using an N2 SM container. AMF 1025 may signal the QoS profile with / PDSB requirements and signal that AL-FEC is enabled. In step 3b, AMF 1025 further instructs the source corresponding to the QoS flow to further apply AL-FEC coding to UE 1035. For UL QoS flows, UE 1035 can use this information to determine its transmission behavior relative to the AL-FEC-encoded PDU set in its buffer, and more specifically, to determine any discard and / or prioritization mechanisms related to AL-FEC UL transmissions. AMF 1025 can signal to UE 1035 using the N1 SM container. AMF 1025 can signal QoS profile w / PDSB requirements and signal that AL-FEC is enabled.

[0158] At 1074: AS 1045 (e.g., as...) Figure 10 The XR video AS depicted delivers encoded content to the UPF 1040 over an IP stream configured by an AF request to the network. The service data stream content corresponds to an AL-FEC encoded PDU set. The AS further marks each PDU set with information about its corresponding AL-FEC encoding in the header information field of the transport protocol (e.g., within an RTP header extension for PDU set labeling that includes additional AL-FEC encoding information elements).

[0159] At 1075: The UPF 1040 applies the SMF 1020 signaling protocol description, including information about PDU sets and AL-FEC information marking by the AS. The UPF 1040 extracts the AL-FEC information for each PDU set (e.g., the number of repair / redundant PDUs in the total number of PDUs in the PDU set, the quota of repair / redundant PDUs in the PDU set, the number of PDUs that can be discarded without losing the corresponding ADU, etc.) and marks the AL-FEC information along with other PDU set information (e.g., PDU set end marker, PDU set sequence number, PDU sequence number, PDU set size, PDU set importance) in the GTP-U tunnel header information of the corresponding PDU in each PDU set. The PDU sets of the QoS flow are routed to RAN1030 via the N3 / GTP U tunnel.

[0160] At 1076: RAN 1030 processes the GTP-U header information regarding PDU sets and AL-FEC and applies the determined PDU set and AL-FEC information for each PDU set of the QoS flow. The AL-FEC information is used by RAN 1030 to perform optimized radio resource allocation (e.g., PDU / PDU set discarding behavior) using AL-FEC awareness. Therefore, AL-FEC support is enabled, and RAN 1030 applies RAN discard / retransmission policies using dynamic AL-FEC awareness when needed (e.g., in congestion, link loss conditions).

[0161] The protocol description can be configured based on application requirements for QoS flows with integrated PDU set handling. The application, at the UE or alternatively at the Application Service Provider (ASP) domain, sends a request to the Application AF for dynamic policies for QoS flows with PDU set and AL-FEC enabled. In one implementation, the UE (e.g., a mobile terminal, XR HMD, etc.) performs the configuration via a Media Session Handler (MSH). The MSH provides an API to the UE or alternatively, a multimedia application residing on the UE, for requesting dynamic policies for its service data flows or alternatively QoS flows (containing PDU set features and enabled AL-FEC). The MSH publishes the dynamic policy request from the application to the corresponding AF (e.g., via the M5_DynamicPolicies API, or alternatively, the RTC-5 equivalent API). In another implementation, the Application Service Provider may provision a set of dynamic policy templates containing QoS requirements to the AF (e.g., via the M1_PolicyTemplatesProvisioning API, or alternatively, the RTC-1 equivalent API), which includes further configuration for PDU set features and AL-FEC support enabled. Dynamic policies from MSH can be selected at AF based on a set of dynamic policies pre-configured by the ASP for the application.

[0162] Information elements including AL-FEC configuration information (e.g., AL-FEC redundancy level) and PDU set marking configuration information may be common and may include both PDU set and AL-FEC information elements. PDU set and AL-FEC marking information may be included within the same resource and object. For example, the resource may be a DynamicPolicy resource, and the object may be a QoSSpecification, or alternatively an RTCQoSSpecification. In another instance, the configuration object may be a PDUSetMarking object. PDUSetMarking may be part of a QoSSpecification (or an RTCQoSSpecification object) as part of a DynamicPolicy resource. An exemplary data model for a PDUSetMarking configuration object is shown in Table 1 below. Table 1 illustrates an extended PDUSetMarking data model for PDU set marking and AL-FEC configuration, containing information elements for determining the status and presence of AL-FEC information in the PDU set marking header originating from a multimedia transmitter (e.g., an RTP transmitter that enables / disables AL-FEC capability).

[0163]

[0164]

[0165] Table 1: PDUsetMarking Extended Data Model for AL-FEC Configuration

[0166] The AL-FEC redundancy information field (e.g., appLayerFecActive) indicates that the PDU set tag in the RTP header extension includes information about the AL-FEC redundancy level of the PDU set.

[0167] Information elements including AL-FEC configuration information (e.g., AL-FEC decoding scheme configuration, AL-FEC media type) can be separately included in the DynamicPolicy data model as one or more independent elements. For example, when the FEC decoding scheme is registered with IANA as a valid RTP payload type (e.g., flexfec decoding scheme, Raptor / RaptorQ decoding scheme), the media identifier type of the DynamicPolicy resource can be assigned to the IANA-registered payload type (e.g., video / flexfec, audio / flexfec, application / flexfec, text / flexfec, video / raptorfec, audio / raptorfec, application / raptorfec, text / raptorfec, etc.). In another instance, an FEC decoding scheme can be identified by means of the FEC encoding ID or a combination of the FEC encoding ID and the FEC instance ID as one of the following: a fully specified decoding scheme (i.e., a formally specified encoding scheme that allows an independent implementer to implement both the encoder and decoder according to the IETF RFC specification); an insufficiently specified decoding scheme (a decoding scheme for which no IETF RFC specification is available, or a decoding scheme for which a party possesses the encoding scheme but is unwilling to disclose the codec algorithm / specification); or a decoding scheme belonging to IANA or an alternatively standardized (e.g., by 3GPP, IETF, etc.) encoding registry (e.g., the IANA FECFRAME registry for encoding IDs), as classified by the IETF.

[0168] In another example, AL-FEC's FEC decoding redundancy can be further described as either 'dynamic' or 'static'. A dynamic quantizer marks a decoding redundancy level that can be dynamically modified from one PDU set to another based on the AL-FEC encoder's (i.e., the multimedia source application's) decision. For all PDU sets of a QoS flow, a static quantizer marks a decoding redundancy level that may not be dynamically modified and is static (e.g., 30% redundant PDUs per PDU set), or alternatively, a fixed number (e.g., 2) of redundant PDUs per PDU set. In the case of a static redundancy level, the policy request for an AS QoS session may further include a static redundancy level. This could be a fixed redundancy quota, or alternatively, a fixed number of redundant / repair PDUs per PDU set. For example, examples of the independent AL-FEC configuration information elements included in the DynamicPolicy data model are listed in Table 2 below. Table 2 shows an example of the configuration data model for AL-FEC configuration information, which includes information elements that identify the AL-FEC coding scheme, the AL-FEC redundancy level type, and the corresponding AL-FEC static redundancy level (if applicable).

[0169]

[0170]

[0171] Table 2: Configuration Data Model for AL-FEC Configuration Information

[0172] An AS (which may be a multimedia RTP transmitter) may include an AL-FEC encoder. The AS transmitter then determines the ADU corresponding to the application's multimedia data stream and performs packet fragmentation for transmission over the network. The resulting PDUs corresponding to the same ADU are further encoded based on the AL-FEC configuration and grouped into a PDU set. Therefore, the PDU set includes all PDUs carrying the data of one ADU. The AS may further label the output encoded PDU set with the PDU set and AL-FEC information. The AL-FEC information may include AL-FEC redundancy level information elements. These information elements may be:

[0173] • An information element indicating the number of PDUs in the encoded PDU set, which may be discarded on the communication link (e.g., by the RAN, or alternatively by the UE) without discarding the original ADU information content; typically, for MDS decoding schemes (e.g., Reed-Solomon, Raptor / RaptorQ, etc.), this is equal to the number of redundant / repaired PDUs added;

[0174] • Information elements indicating the number of redundant / repaired PDUs and the total number of PDUs in the coded PDU set with AL-FEC; and / or

[0175] • An information element indicating the quota of redundant / repaired PDUs in the total number of PDUs in an AL-FEC encoded PDU set.

[0176] Furthermore, the AL-FEC redundancy level information element can be included within the RTP header extension used for PDU set marking. The AL-FEC redundancy level can be added as an optional field, thereby extending the existing urn:3gpp:pdu-set-marking:rel-18 RTP header extension in its 1-byte and 2-byte formats. For example, the RTP header extension can additionally include a byte field called the AL-FEC Redundancy Level (AFRL). The AFRL can be formed by 8 bits and includes the number of redundant / repaired PDUs added by the AL-FEC encoder at the multimedia source to the AL-FEC encoded PDU set (i.e., the number of PDUs that can be lost from the PDU set without losing the PDU set payload in the case of MDS code). In an instance where the PDU set consists of 28 encoded PDUs, each containing a 1200-byte payload, the AFRL can indicate 6 redundant / repaired PDUs. The remaining 22 PDUs are the source PDUs corresponding to the unencoded ADUs associated with the PDU set. (See reference) Figure 11 and 12 The 1-byte and 2-byte format of the RTP header extension urn:3gpp:pdu-set-marking:rel-18 provides instances of the AFRL field. In other implementations of the AFRL field, the AFRL field may consist of another number of bits (e.g., 4 bits, 16 bits, 24 bits, 32 bits, etc.).

[0177] Figure 11 The diagram illustrates the 1-byte RTP header extension 1100 used for PDU set and AL-FEC information marking, which includes the optional additional field AL-FEC Redundancy Level (AFRL, 1111). In this example, AFRL is an 8-bit field that captures the number of redundant PDUs that can be discarded from the PDU set without losing the corresponding PDU set payload / ADU information in the AL-FEC. Figure 11 The semantics associated with the PDU set information field in the RTP header extension syntax outlined herein correspond to those in the reference above. Figure 6 The semantics described.

[0178] Figure 12The diagram illustrates the 2-byte RTP header extension 1200 used for PDU set and AL-FEC information marking, which includes the optional additional field AL-FEC Redundancy Level (AFRL, 1211). In this example, AFRL is an 8-bit field that captures the number of redundant PDUs that can be discarded from the PDU set without losing the corresponding PDU set payload / ADU information in the AL-FEC. Figure 12 The semantics associated with the PDU set information field in the RTP header extension syntax outlined herein correspond to those in the reference above. Figure 6 and Figure 7 The semantics described.

[0179] The presence of the AFRL field in the RTP header extension of a PDU set indicates that AL-FEC may have been used on the PDU set. An AFRL set to 0 indicates that the PDU set does not contain any redundant / repair PDUs. This may mean that the PDU set was not encoded and that AL-FEC was not used. Furthermore, depending on the dynamic encoding of the AL-FEC for the PDU set, the AFRL can vary from one PDU set to another.

[0180] The presence of the AFRL field in the PDU set tag RTP header extension can be indicated by means of an SDP proposal / response procedure. An SDP proposer (e.g., an RTP transmitter / RTP peer) may indicate an SDP proposal to an SDP responder (e.g., an RTP receiver / another RTP peer). The SDP proposal may contain signaling indicating that the AFRL has been added to the fixed PDU set tag RTP header extension, and the SDP may further contain a set of AL-FEC encoding configurations. The SDP responder repeats the proposal parameters, including acceptable AL-FEC encoding and AFRL field configurations. For example, in the case where the SDP responder supports the AFRL field and an AL-FEC encoding configuration, the SDP responder will repeat and indicate the AFRL field and an AL-FEC encoding configuration to the SDP proposer. The presence of the AFRL field in the PDU set tag RTP header extension can be indicated by means of an optional extension attribute property. The following is an exemplary implementation of the ABNF syntax for a possible implementation of the optional extension attribute property, where the AFRL extension attribute property al-fec-redundancy-level indicates the presence of the AFRL field.

[0181] ```

[0182] a=extmap:" 1 5DIGIT [" / " direction] SP extensionname SPextensionattributes

[0183] extensionname = "urn:3gpp:pdu-set-marking:rel-18"

[0184] extensionattributes = [format SP] "pdu-set-size" [SP] "num-of-pdus" [SP] "al-fec-redundancy-level"

[0185] format = "short" / "long"

[0186] ```

[0187] As an example, when PDU sets and AL-FEC are enabled for a QoS flow (e.g., based on MDS decoding schemes such as Reed-Solomon, Raptor / RaptorQ, etc.) and the multimedia source marks each PDU set with PDU set information and AL-FEC information, the dynamic AL-FEC information for each PDU set can help the radio layer determine optimized radio resource allocation and discarding behavior given the QoS parameters of a given QoS flow (e.g., PSDB / PSER, PSIHI). For example, when the PDU Set Integration Disposal Indicator (PSIHI) is enabled for a QoS flow, the RAN scheduler can determine, through implementation, that it cannot send the entire PDU set within the available PSDB. For example, the RAN can decide to discard PDUs that cannot be successfully scheduled within the duration of the PSDB. If the number of discarded PDUs exceeds the number of redundant PDUs marked for the PDU set, then the RAN can decide to discard the entire PDU set. However, if the number of PDUs to be discarded is less than or equal to the number of PDUs marked for the PDU set, then the RAN may decide not to discard the entire PDU set and transmit the remaining PDUs.

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

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

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

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

[0192] In some implementations, processor 1302 and memory 1304 coupled to processor 1302 may be configured to cause UE 1300 to perform one or more of the functions described herein (e.g., instructions stored in memory 1304 are executed by processor 1302). For example, according to the examples disclosed herein, processor 1302 may support wireless communication at UE 1300. UE 1300 may be configured to support components for performing the following operations: receiving application data units (ADUs) of a multimedia application; decoding at least one of the ADUs based at least one of the ADUs using an application layer forward error correction (AL-FEC) configuration to generate at least one set of protocol data units (PDUs), wherein the set of PDUs includes at least one PDU; marking at least one PDU header of the set of PDUs to indicate the AL-FEC configuration applied to the set of PDUs; and transmitting the set of PDUs.

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

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

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

[0196] Transmitter chain 1312 can be configured to generate and transmit signals (e.g., control information, data, packets). Transmitter chain 1312 may include at least one modulator for modulating data onto a carrier signal, thereby 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). Transmitter chain 1312 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over a wireless medium. Transmitter chain 1312 may also include one or more antennas for transmitting the amplified signal over the air or in the wireless medium.

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

[0198] Processor 1400 may be a processor chipset and includes a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, and reading) according to the examples described herein. The processor chipset may include one or more cores, one or more cache memories (e.g., memory native to or contained within the processor chipset (e.g., processor 1400), or other memories (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)).

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

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

[0201] Memory 1404 may include one or more cache memories (e.g., memory native to or contained therein of processor 1400, or other memory such as RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc.). In some embodiments, memory 1404 may reside within or on the processor chipset (e.g., native to processor 1400). In some other embodiments, memory 1404 may reside external to the processor chipset (e.g., remote from processor 1400).

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

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

[0204] According to the examples disclosed herein, processor 1400 may support wireless communication. Processor 1400 may be configured or operable to support components for performing the following operations: receiving application data units (ADUs) of a multimedia application; decoding at least one ADU from the ADUs based at least in part on an application layer forward error correction (AL-FEC) configuration, wherein the PDU set includes at least one PDU; marking at least one PDU header of the PDU set to indicate the AL-FEC configuration applied to the PDU set; and transmitting the PDU set.

[0205] Figure 15 The illustration depicts an example of an NE 1500 according to various aspects of this disclosure. The NE 1500 may include a processor 1502, a memory 1504, a controller 1506, and a transceiver 1508. The processor 1502, memory 1504, controller 1506, or transceiver 1508, or various combinations thereof, or various components thereof, may be examples of components for performing the various aspects of this disclosure as described herein. These components may be coupled via one or more interfaces (e.g., operational ground, communication ground, functional ground, electronic ground, electrical ground).

[0206] Processor 1502, memory 1504, controller 1506, or transceiver 1508, or various combinations or components thereof, may be implemented in hardware (e.g., a circuit system). The hardware may include a processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof, configured to or otherwise supporting components for performing the functions described in this disclosure.

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

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

[0209] In some embodiments, processor 1502 and memory 1504 coupled to processor 1502 may be configured to cause NE 1500 to perform one or more of the functions described herein (e.g., processor 1502 executing instructions stored in memory 1504). For example, according to the examples disclosed herein, processor 1502 may support wireless communication at NE 1500. NE 1500 may be configured to support components for performing: receiving application data units (ADUs) of a multimedia application; decoding at least one ADU among the ADUs based at least in part on an application layer forward error correction (AL-FEC) configuration, wherein the PDU set includes at least one PDU; marking at least one PDU header of the PDU set to indicate the AL-FEC configuration applied to the PDU set; and transmitting the PDU set.

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

[0211] In some embodiments, the NE 1500 may include at least one transceiver 1508. In other embodiments, the NE 1500 may have more than one transceiver 1508. The transceiver 1508 may represent a wireless transceiver. The transceiver 1508 may include one or more receiver chains 1510, one or more transmitter chains 1512, or a combination thereof.

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

[0213] Transmitter chain 1512 can be configured to generate and transmit signals (e.g., control information, data, packets). Transmitter chain 1512 may include at least one modulator for modulating data onto a carrier signal, thereby 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). Transmitter chain 1512 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over a wireless medium. Transmitter chain 1512 may also include one or more antennas for transmitting the amplified signal over the air or in the wireless medium.

[0214] Figure 16 The diagram illustrates flowcharts illustrating methods according to various aspects of this disclosure. The operation of the methods can be implemented by a UE or AS as described herein. In some embodiments, the UE or AS can execute a set of instructions to control functional elements of the UE or AS to perform the described functions.

[0215] At 1602, the method may include receiving an application data unit (ADU) of a multimedia application. The operation of 1602 may be performed according to the examples described herein. In some embodiments, aspects of the operation of 1602 may be referenced from... Figure 13 The UE described herein shall perform this action. In other embodiments, aspects of the operation of 1602 may be described in reference to [reference needed]. Figure 15 The NE described is used to execute.

[0216] At 1604, the method may include generating at least one set of Protocol Data Units (PDUs) by decoding at least one ADU in an ADU using an application layer forward error correction (AL-FEC) configuration, at least in part, wherein the set of PDUs includes at least one PDU. The operation of 1604 may be performed according to the examples described herein. In some embodiments, aspects of the operation of 1604 may be referenced from... Figure 13 The UE described herein shall perform this action. In other embodiments, aspects of the operation of 1604 may be described in reference to [reference needed]. Figure 15 The NE described is used to execute.

[0217] At 1606, the method may include at least one PDU header marking the PDU set to indicate the AL-FEC configuration applied to the PDU set. Operation of 1606 may be performed according to the examples described herein. In some embodiments, aspects of operation of 1606 may be referenced from... Figure 13 The UE described herein shall perform this action. In other embodiments, aspects of the operation of 1606 may be described in reference to [reference needed]. Figure 15 The NE described is used to execute.

[0218] At 1608, the method may include transmitting a set of PDUs. The operation of 1608 may be performed according to the examples described herein. In some embodiments, aspects of the operation of 1608 may be referenced. Figure 13 The UE described herein shall perform this action. In other embodiments, aspects of the operation of 1608 may be found in reference to [reference needed]. Figure 15 The NE described is used to execute.

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

[0220] Therefore, an application server (AS) for wireless communication is provided, comprising: at least one memory; and at least one processor coupled to the at least one memory and configured such that the AS: receives application data units (ADUs) of a multimedia application; decodes at least one ADU among the ADUs based at least in part on an application layer forward error correction (AL-FEC) configuration, wherein the set of PDUs includes at least one PDU; marks at least one PDU header of the set of PDUs to indicate the AL-FEC configuration applied to the set of PDUs; and transmits the set of PDUs.

[0221] This approach prioritizes AL-FEC support for QoS flows in wireless communication networks and facilitates integrated processing of PDU sets. AL-FEC information and configuration elements allow wireless communication networks to better handle AL-FEC content in challenging wireless network conditions.

[0222] The processor may be further configured to cause the AS to transmit a request for establishing a Quality of Service (QoS) flow for service data flow, the QoS flow including the AL-FEC encoded PDU set.

[0223] The request to establish a QoS flow may include dynamic policy configuration. The dynamic policy configuration may include at least one of the following: service data flow information; a set of QoS delay budgets and rate requirements; media type information; PDU set tagging information; and a subset of the AL-FEC encoding configuration.

[0224] The request to establish a QoS flow can be sent to an Application Function (AF). The AF may be pre-configured by an Application Service Provider (ASP) for the multimedia application, providing one or more policy templates for dynamic policy configuration. The AF can then pass the request to a second network function. The second network function may include policy control functions. The second network function may include network exposure functions.

[0225] The request to establish a QoS flow may include a dynamic policy configuration, which includes a subset of AL-FEC coding configurations, wherein the subset of AL-FEC coding configurations includes information of at least one of the following: a Forward Error Correction (FEC) Coding Identifier (ID) field, the FEC coding ID partially identifying the AL-FEC coding configuration; an FEC Instance Identifier (ID) field, the FEC instance ID partially identifying the AL-FEC coding configuration and its parameters; and a Maximum Distance Separable (MDS) Indicator field, the MDS indicator determining whether the AL-FEC coding configuration has... It has MDS encoding characteristics; a static redundancy level indicator field, which determines whether the AL-FEC encoding configuration generates a static redundancy mode; a static redundancy PDU level indicator field, which determines that the static redundancy mode consists of a static number of redundant PDUs generated by the AL-FEC encoding configuration for each PDU set; and / or a static redundancy percentage level indicator field, which determines that the static redundancy mode consists of a static quota number of redundant PDUs generated by the AL-FEC encoding configuration for each PDU set for each PDU set.

[0226] The dynamic policy configuration may include a common information element that indicates that the PDU set information contained in the PDU header contains at least the AL-FEC information element.

[0227] The PDU set information within the PDU header may be included in a Real-Time Transport Protocol (RTP) extended header element, wherein the RTP extended header element for the PDU set information includes at least one of the following: a field indicating the total number of PDUs in the PDU set; a field indicating the AL-FEC redundancy level as the number of redundant PDUs in the PDU set; a field indicating the AL-FEC redundancy level as the ratio of redundant PDUs to total PDUs in the PDU set; a field indicating the AL-FEC redundancy level as a threshold of PDUs that can be lost by the network without losing the ADU corresponding to the AL-FEC encoded PDU set; a field indicating the PDU set sequence number; a field indicating the PDU sequence number of the PDUs in the PDU set; a field indicating the end PDU of the PDU set; a field indicating the importance of the PDU set; and / or a field indicating the size of the PDU set in bytes.

[0228] The presence of the AL-FEC redundancy level field in the RTP header extension element used for PDU set marking can be indicated by the RTP extension attribute via the SDP proposal / response procedure.

[0229] A further provision provides a user equipment (UE) for wireless communication, comprising: at least one memory; and at least one processor coupled to the at least one memory and configured such that the UE: receives application data units (ADUs) of a multimedia application; decodes at least one ADU among the ADUs based at least in part on an application layer forward error correction (AL-FEC) configuration to generate at least one set of protocol data units (PDUs), wherein the set of PDUs includes at least one PDU; marks at least one PDU header of the set of PDUs to indicate the AL-FEC configuration applied to the set of PDUs; and transmits the set of PDUs.

[0230] The processor may be further configured to cause the UE to: transmit a request for establishing a Quality of Service (QoS) flow for the service data flow, the QoS flow including the AL-FEC encoded PDU set.

[0231] The request to establish a QoS flow may include dynamic policy configuration. The dynamic policy configuration may include at least one of the following: service data flow information; a set of QoS delay budgets and rate requirements; media type information; PDU set tagging information; and a subset of the AL-FEC encoding configuration.

[0232] The request to establish a QoS flow is sent to a Media Service Handler (MSH). The MSH may be configured to handle dynamic policy configurations for multimedia applications. The MSH may pass the request to a second network function. The second network function may be an Application Function (AF). The AF may be pre-configured by an Application Service Provider (ASP) of the multimedia application with one or more policy templates for dynamic policy configuration. The AF may process the request from the MSH and relay it to a third network function. In this example, the third network function may include a policy control function. Alternatively, in this example, the third network function may include a network exposure function.

[0233] The request to establish a QoS flow may include a dynamic policy configuration, which includes a subset of AL-FEC encoding configurations. The dynamic policy configuration further includes a common information element indicating that the PDU set information contained in the PDU header at least includes an AL-FEC information element. The subset of AL-FEC encoding configurations includes information of at least one of the following: a Forward Error Correction (FEC) encoding identifier (ID) field, where the FEC encoding ID partially identifies the AL-FEC encoding configuration; an FEC instance identifier (ID) field, where the FEC instance ID partially identifies the AL-FEC encoding configuration and its parameters; and a Maximum Distance Separable (MDS) field. S) Indicator field, MDS indicator determines whether the AL-FEC coding configuration has MDS coding characteristics; Static redundancy level indicator field, Static redundancy level indicator determines whether the AL-FEC coding configuration generates a static redundancy mode; Static redundancy PDU level indicator field, Static redundancy PDU level determines that the static redundancy mode consists of a static number of redundant PDUs generated by the AL-FEC coding configuration for each PDU set; and / or Static redundancy percentage level indicator field, Static redundancy percentage level determines that the static redundancy mode consists of a static quota number of redundant PDUs generated by the AL-FEC coding configuration for each PDU set for each PDU set.

[0234] A further provided processor for wireless communication includes: at least one controller coupled to at least one memory and configured to: receive application data units (ADUs) of a multimedia application; decode at least one ADU from the ADUs based at least in part on an application layer forward error correction (AL-FEC) configuration to generate at least one set of protocol data units (PDUs), wherein the set of PDUs includes at least one PDU; mark at least one PDU header of the set of PDUs to indicate the AL-FEC configuration applied to the set of PDUs; and transmit the set of PDUs.

[0235] Further, a method performed by a means for wireless communication is provided, the method comprising: receiving application data units (ADUs) of a multimedia application; decoding at least one ADU among the ADUs based at least in part on an application layer forward error correction (AL-FEC) configuration, wherein the set of PDUs includes at least one PDU; marking at least one PDU header of the set of PDUs to indicate the AL-FEC configuration applied to the set of PDUs; and transmitting the set of PDUs.

[0236] The device may be a user equipment (UE). The device may be an application server (AS). An application data unit (ADU) may be referred to as a received ADU. The ADU may be associated with a multimedia application. The association may include generating the ADU by or for a multimedia application. The generation may include AL-FEC encoding of the ADU using an MDS AL-FEC encoding configuration. In one case, the encoding configuration may include Raptor / RaptorQ or other digital fountain encoding. In another case, the encoding configuration may include Reed-Solomon encoding. In still other cases, the encoding configuration may include flexible parity checking or other random linear network decoding encoding.

[0237] Typically, an ADU is encoded into a PDU set. However, there may be situations where applications aggregate and decode multiple ADUs together into a single PDU set. These multiple ADUs could be small ADUs, such as video codec parameter sets, SEI messages, and / or combinations of video frames / video segments.

[0238] The method may further include labeling the PDU header with information containing characteristics of the PDU set. The PDU set may be transmitted to a network. The PDU set may be transmitted to a network device. The network device may include a User Plane Function (UPF). The UPF may receive AL-FEC encoded ADUs and identify their corresponding encoded PDU sets. The received encoded ADUs may include one or more source PDUs and repair PDUs or alternative redundant PDUs. The UPF may identify the AL-FEC decoding configuration used to encode the ADUs and determine the corresponding encoded PDU set. The identification of each PDU set may be based at least in part on information or alternative metadata associated with the PDU set. The association may include, as part of the information used to label the PDU header, the information including characteristics of the PDU set and AL-FEC encoding information. The UPF may further route and transmit the determined PDU set to another network device. The PDU set may be transmitted to a base station of a wireless communication network.

[0239] The method may further include: transmitting a request to establish a Quality of Service (QoS) stream, wherein the QoS stream for serving the data stream includes the AL-FEC encoded PDU set.

[0240] The request to establish a QoS flow may include dynamic policy configuration. The dynamic policy configuration may include at least one of the following: service data flow information; a set of QoS delay budgets and rate requirements; media type information; PDU set tagging information; and a subset of the AL-FEC encoding configuration.

[0241] The request to establish a QoS flow can be sent to a first network function. The first network function can then pass the request to a second network function. The second network function may include policy control functions. The second network function may include network exposure functions.

[0242] The first network function may include an application function (AF) or a media service handler (MSH). The AF may be pre-configured by an application service provider (ASP) for multimedia applications, providing one or more policy templates for dynamic policy configuration. The MSH may be configured to handle the dynamic policy configuration of multimedia applications.

[0243] The request to establish a QoS flow includes a dynamic policy configuration, which comprises a subset of AL-FEC coding configurations. This subset of AL-FEC coding configurations includes information of at least one of the following: a Forward Error Correction (FEC) Coding Identifier (ID) field, which partially identifies the AL-FEC coding configuration; an FEC Instance Identifier (ID) field, which partially identifies the AL-FEC coding configuration and its parameters; and a Maximum Distance Separable (MDS) Indicator field, which determines whether the AL-FEC coding configuration has... MDS encoding characteristics; Static redundancy level indicator field, which determines whether the AL-FEC encoding configuration generates a static redundancy mode; Static redundancy PDU level indicator field, which determines that the static redundancy mode consists of a static number of redundant PDUs generated by the AL-FEC encoding configuration for each PDU set; and / or Static redundancy percentage level indicator field, which determines that the static redundancy mode consists of a static quota number of redundant PDUs generated by the AL-FEC encoding configuration for each PDU set for each PDU set.

[0244] The dynamic policy configuration may include a common information element that indicates that the PDU set information contained in the PDU header contains at least the AL-FEC information element.

[0245] The PDU set information within the PDU header may be included in Real-Time Transport Protocol (RTP) extended header elements. The RTP extended header elements for the PDU set information may include at least one of the following: a field indicating the total number of PDUs in the PDU set; a field indicating the AL-FEC redundancy level as the number of redundant PDUs in the PDU set; a field indicating the AL-FEC redundancy level as the ratio of redundant PDUs to the total number of PDUs in the PDU set; a field indicating the AL-FEC redundancy level as the threshold of PDUs that can be lost by the network without losing the ADU corresponding to the AL-FEC encoded PDU set; a field indicating the PDU set sequence number; a field indicating the PDU sequence number of the PDUs within the PDU set; a field indicating the end PDU of the PDU set; a field indicating the importance of the PDU set; and / or a field indicating the PDU set size in bytes.

[0246] The presence of the AL-FEC redundancy level field in the RTP header extension element used for PDU set marking can be indicated by the RTP extension attribute via the SDP proposal / response procedure.

[0247] The device may include user equipment (UE) or application server (AS).

[0248] The disclosures herein provide novel configuration and signaling elements that enable AL-FEC support for QoS flows through PDU set integrated processing in wireless communication networks (e.g., 5GS), for example:

[0249] • Signaling configured with AL-FEC, as part of a UE / ASP request for an AS QoS session with PDU set and AL-FEC support;

[0250] • Various configuration options required to describe the AL-FEC encoding of the source to the network (e.g., 5GS);

[0251] • Extend the existing RTP header used for PDU set labeling to include (dynamic) AL-FEC redundancy level information, thereby helping the network better manage redundancy when facing challenging conditions at the air interface (e.g., congestion events, capacity outages, etc.).

[0252] • The proposed signaling and configuration solutions are integrated end-to-end with 5GS and 5G NR.

[0253] Therefore, this document provides a method in a wireless communication apparatus, the method comprising: receiving an application data unit (ADU) of a multimedia application; applying an application layer forward error correction coding configuration corresponding to the multimedia application to encode each ADU into a PDU set, the PDU set including one or more AL-FEC encoded PDUs; marking a PDU header with information including the PDU set and the characteristics of the corresponding AL-FEC of the PDU set, the marked PDU header corresponding to one or more headers of PDUs belonging to the PDU set; and (knownly) transmitting the PDU set having the marked PDU headers to a network.

[0254] By communicating with a second network function via a first network function, the device can indicate to the network a request for establishing a Quality of Service (QoS) flow for a service data flow, the QoS flow comprising an AL-FEC encoded PDU set, the request comprising a dynamic policy configuration including service data flow information, a set of QoS delay budgets and rate requirements, media type information, PDU set tagging information, and a subset of the AL-FEC encoded configuration.

[0255] The first network function may be one of the following: an application function (AF) pre-configured by an application service provider (ASP) of a multimedia application for dynamic policy configuration of one or more policy templates; and a media service handler (MSH) that includes handling dynamic policy configuration of the multimedia application.

[0256] The dynamic policy configuration may include common information elements corresponding to the labeled PDU headers, the common information elements indicating PDU set labels and the AL-FEC information elements available in the labeled PDU headers.

[0257] The marked PDU header can correspond to the Real-Time Transport Protocol (RTP) extension header element used for marking PDU sets.

[0258] The RTP extension header element used for PDU set tagging may include at least one of the following:

[0259] • A destination field indicating the total number of PDUs in the PDU set;

[0260] • The AL-FEC redundancy level is indicated by the field representing the number of redundant PDUs in the PDU set;

[0261] • The AL-FEC redundancy level is indicated by the field representing the quota of redundant PDUs in the PDU set relative to the total PDUs;

[0262] • A field indicating the AL-FEC redundancy level as the threshold of PDUs that can be lost by the network without losing the ADUs corresponding to the AL-FEC encoded PDU set.

[0263] • A field indicating the sequence number of the PDU set;

[0264] • A field indicating the PDU sequence number of the PDUs within the PDU set;

[0265] • A field indicating the end PDU of the PDU set;

[0266] • Fields indicating the importance of a PDU set; and

[0267] • A field indicating the size of the PDU set in bytes;

[0268] The second network function may be one of the following: policy control function; and network exposure function. The AF may be pre-configured by an application service provider (ASP) for multimedia applications, using one or more policy templates for dynamic policy configuration.

[0269] Wireless communication devices may include one of the following: user equipment (UE); and application server (AS).

[0270] The subset of the AL-FEC encoding configuration may include information of at least one of the following:

[0271] • Forward Error Correction (FEC) Encoding Identifier (ID) field; the FEC encoding ID partially identifies the AL-FEC encoding configuration;

[0272] • FEC instance identifier (ID) field; the FEC instance ID partially identifies the AL-FEC encoding configuration and parameters;

[0273] • Maximum Distance Separable (MDS) indicator field; the MDS indicator determines whether the AL-FEC encoding configuration has MDS encoding characteristics;

[0274] • Static redundancy level indicator field, wherein the static redundancy level indicator determines whether the AL-FEC coding configuration generates a static redundancy mode;

[0275] • Static redundancy PDU level indicator field, wherein the static redundancy PDU level determines that the static redundancy mode consists of a static number of redundant PDUs generated for each PDU set through the AL-FEC encoding configuration; and / or

[0276] • Static redundancy percentage level indicator field, wherein the static redundancy percentage level determines that the static redundancy mode consists of redundant PDUs of a static quota number per total number of PDUs generated for each PDU set through the AL-FEC encoding configuration.

[0277] The presence of the AL-FEC redundancy level field in the RTP header extension element used for PDU set marking can be indicated by the RTP extension attribute via the SDP proposal / response procedure.

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

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

Claims

1. An application server AS for wireless communication, comprising: At least one memory; as well as At least one processor, coupled to the at least one memory and configured to cause the AS to: Receives Application Data Units (ADUs) for multimedia applications; At least one set of Protocol Data Units (PDUs) is generated by decoding at least one of the ADUs through an application layer forward error correction (AL-FEC) configuration, at least in part; Mark at least one PDU header of the PDU set to indicate the AL-FEC configuration applied to the PDU set; and Transmit the PDU set.

2. The AS of claim 1, wherein the processor is further configured to cause the AS to: The transmission is a request to establish a Quality of Service (QoS) stream, the QoS stream for which the service data stream includes the AL-FEC encoded PDU set.

3. The AS of claim 2, wherein the request for establishing the QoS flow is sent to the application function AF.

4. The AS of claim 3, wherein the request to establish the QoS flow includes a dynamic policy configuration, the dynamic policy configuration including a subset of AL-FEC encoding configuration, wherein the subset of AL-FEC encoding configuration includes information of at least one of the following: The forward error correction FEC encoding identifier ID field partially identifies the AL-FEC encoding configuration; The FEC instance identifier ID field partially identifies the AL-FEC encoding configuration and parameters; The maximum distance separable MDS indicator field determines whether the AL-FEC encoding configuration has MDS encoding characteristics. The Static Redundancy Level Indicator field determines whether the AL-FEC encoding configuration generates a static redundancy mode. The static redundancy PDU level indicator field determines that the static redundancy mode consists of a static number of redundant PDUs generated for each PDU set through the AL-FEC encoding configuration; and / or The Static Redundancy Percentage Level Indicator field determines that the static redundancy mode consists of redundant PDUs of a static quota number generated per total number of PDUs for each PDU set through the AL-FEC encoding configuration.

5. The AS of claim 4, wherein the dynamic policy configuration includes a common information element indicating that the PDU set information contained in the PDU header contains at least an AL-FEC information element.

6. The AS according to any of the preceding claims, wherein the PDU set information in the PDU header is included in a Real-Time Transport Protocol (RTP) extension header element, and wherein the RTP extension header element for the PDU set information includes at least one of the following: The destination field indicates the total number of PDUs in the PDU set; The AL-FEC redundancy level is indicated by a field representing the number of redundant PDUs in the PDU set; The AL-FEC redundancy level is indicated by a field representing the ratio of redundant PDUs in the PDU set to the total number of PDUs. The AL-FEC redundancy level is a field indicating the threshold of PDUs that can be lost by the network without losing the ADUs corresponding to the AL-FEC encoded PDU set; A field indicating the sequence number of the PDU set; A field indicating the PDU sequence number of the PDUs within the PDU set; A field indicating the end of the PDU set; Fields indicating the importance of a PDU set; and / or A field indicating the size of the PDU set in bytes.

7. A user equipment (UE) for wireless communication, comprising: At least one memory; as well as At least one processor, coupled to and configured to enable the UE to: Receives Application Data Units (ADUs) for multimedia applications; At least one set of Protocol Data Units (PDUs) is generated by decoding at least one of the ADUs through an application layer forward error correction (AL-FEC) configuration, at least in part; Mark at least one PDU header of the PDU set to indicate the AL-FEC configuration applied to the PDU set; and Transmit the PDU set.

8. The UE of claim 7, wherein the processor is further configured to cause the UE to: The transmission is a request to establish a Quality of Service (QoS) stream, the QoS stream for which the service data stream includes the AL-FEC encoded PDU set.

9. The UE of claim 8, wherein the request for establishing the QoS flow is sent to the Media Service Processor MSH.

10. The UE of claim 8, wherein the request to establish a QoS flow includes a dynamic policy configuration, the dynamic policy configuration including a subset of an AL-FEC encoded configuration, wherein the dynamic policy configuration further includes a common information element, the common information element indicating that PDU set information contained in a PDU header contains at least an AL-FEC information element. The subset of the AL-FEC encoding configurations mentioned above includes information on at least one of the following: A forward error correction FEC encoding identifier ID field, wherein the FEC encoding ID partially identifies the AL-FEC encoding configuration; The FEC instance identifier ID field partially identifies the AL-FEC encoding configuration and parameters; The maximum distance separable MDS indicator field determines whether the AL-FEC encoding configuration has MDS encoding characteristics. The Static Redundancy Level Indicator field determines whether the AL-FEC encoding configuration generates a static redundancy mode. The static redundancy PDU level indicator field determines that the static redundancy mode consists of a static number of redundant PDUs generated for each PDU set through the AL-FEC encoding configuration; and / or The Static Redundancy Percentage Level Indicator field determines that the static redundancy mode consists of redundant PDUs of a static quota number generated per total number of PDUs for each PDU set through the AL-FEC encoding configuration.

11. A processor for wireless communication, comprising: At least one controller, coupled to at least one memory and configured to enable the processor to: Receives Application Data Units (ADUs) for multimedia applications; At least one Protocol Data Unit (PDU) set is generated by decoding at least one of the ADUs through an application layer forward error correction (AL-FEC) configuration, at least in part, wherein the PDU set includes at least one PDU; Mark at least one PDU header of the PDU set to indicate the AL-FEC configuration applied to the PDU set; and Transmit the PDU set.

12. A method performed by a means for wireless communication, the method comprising: Receives Application Data Units (ADUs) for multimedia applications; At least one Protocol Data Unit (PDU) set is generated by decoding at least one of the ADUs through an application layer forward error correction (AL-FEC) configuration, at least in part, wherein the PDU set includes at least one PDU; Mark at least one PDU header of the PDU set to indicate the AL-FEC configuration applied to the PDU set; and Transmit the PDU set.

13. The method of claim 12, further comprising: The transmission is a request to establish a Quality of Service (QoS) stream, the QoS stream for which the service data stream includes the AL-FEC encoded PDU set.

14. The method of claim 13, wherein the request for establishing the QoS flow is sent to a first network function.

15. The method of claim 14, wherein the first network function includes application function AF or media service handler MSH.

16. The method of claim 13, wherein the request to establish the QoS flow includes a dynamic policy configuration, the dynamic policy configuration including a subset of AL-FEC encoding configuration, wherein the subset of AL-FEC encoding configuration includes information of at least one of the following: The forward error correction FEC encoding identifier ID field partially identifies the AL-FEC encoding configuration; The FEC instance identifier ID field partially identifies the AL-FEC encoding configuration and parameters; The maximum distance separable MDS indicator field determines whether the AL-FEC encoding configuration has MDS encoding characteristics. The Static Redundancy Level Indicator field determines whether the AL-FEC encoding configuration generates a static redundancy mode. The static redundancy PDU level indicator field determines that the static redundancy mode consists of a static number of redundant PDUs generated for each PDU set through the AL-FEC encoding configuration; and / or The Static Redundancy Percentage Level Indicator field determines that the static redundancy mode consists of redundant PDUs of a static quota number generated per total number of PDUs for each PDU set through the AL-FEC encoding configuration.

17. The method of claim 16, wherein the dynamic policy configuration includes a common information element indicating that the PDU set information contained in the PDU header contains at least an AL-FEC information element.

18. The method according to any one of claims 12 to 17, wherein the PDU set information in the PDU header is included in a Real-Time Transport Protocol (RTP) extension header element.

19. The method of claim 18, wherein the RTP extended header element for PDU set information includes at least one of the following: The destination field indicates the total number of PDUs in the PDU set; The AL-FEC redundancy level is indicated by a field representing the number of redundant PDUs in the PDU set; The AL-FEC redundancy level is indicated by a field representing the ratio of redundant PDUs in the PDU set to the total number of PDUs. The AL-FEC redundancy level is a field indicating the threshold of PDUs that can be lost by the network without losing the ADUs corresponding to the AL-FEC encoded PDU set; A field indicating the sequence number of the PDU set; A field indicating the PDU sequence number of the PDUs within the PDU set; A field indicating the end of the PDU set; Fields indicating the importance of a PDU set; and / or A field indicating the size of the PDU set in bytes.

20. The method according to any one of claims 12 to 19, wherein the apparatus comprises a user equipment (UE) or an application server (AS).

Images