Early termination of transmission of PDU sets generated by AL-FEC in wireless communication network

Abstract

A method in a node of a wireless communication network is provided. The method includes receiving, from an application, a set of protocol data units (PDUs) corresponding to encoded application data units (ADUs), wherein the encoding is based on an application layer forward error correction (AL-FEC) encoding configuration. The method further includes receiving an application layer forward error correction (AL-FEC) encoding configuration used to encode the encoded ADU; and processing the transmission of the set of PDUs. The method further includes determining whether a stop criterion is satisfied, the stop criterion derived from the AL-FEC coding configuration for the set of PDUs, and stopping transmission of the set of PDUs if the stop criterion of the set of PDUs is satisfied.

Description

Technical Field

[0001] The subject matter disclosed herein generally relates to the field of enabling efficient transmission of PDU sets in a wireless communication network. This document defines a method in a node of a wireless communication network, a node in a wireless communication network, a method in a user equipment device of a wireless communication network, and a user equipment device for communicating with a wireless communication network. Background Art

[0002] In this article, extended reality (XR) is used as a general term for different types of reality (of which virtual reality, augmented reality, and mixed reality are examples). XR application services are subject to strict bandwidth and latency constraints in order to deliver appropriate quality of service and quality of experience to end users of XR services. Such strict bandwidth and latency constraints may make the delivery of XR application services over wireless communication networks challenging.

[0003] So far, IETF has defined a generic forward error correction framework (FECFRAME) as IETF RFC 6363, which allows various FEC schemes to be applied to application-level FEC. FECFRAME specifies the source packet format and repair packet format and FEC scheme configuration process for AL-FEC on both the transport layer (e.g., UDP) and the RTP layer (e.g., WebRTC). AL-FEC services include both source PDUs and repair PDUs. Summary of the invention

[0004] In the context of XR media services, the 3GPP SA2 working group recently introduced the concept of "PDU aggregation" to group a series of PDUs that carry information units at the application level. When application layer FEC is applied to PDU aggregation, a situation may arise halfway through the transmission of the PDU aggregation, making the transmission of the remaining PDUs in the PDU aggregation redundant. Identifying such a possibility and stopping the transmission of the PDU aggregation can improve the transmission efficiency of the PDU aggregation in the wireless communication network.

[0005] A process for efficient transmission of a PDU set in a wireless communication network is disclosed herein. The process may be implemented by a method in a node of a wireless communication network, a node of a wireless communication network, a method in a user equipment device of a wireless communication network, and a user equipment device for communicating with a wireless communication network.

[0006] Therefore, a method in a node of a wireless communication network is provided. The method includes receiving a set of protocol data units (PDUs) corresponding to an encoded application data unit (ADU) from an application, wherein the encoding is based on an application layer forward error correction (AL-FEC) encoding configuration. The method also includes receiving an application layer forward error correction (AL-FEC) encoding configuration used to encode the encoded ADU; and processing the transmission of the set of PDUs. The method also includes determining whether a stopping criterion is satisfied, the stopping criterion being derived from the AL-FEC encoding configuration for the set of PDUs, and if the stopping criterion is satisfied for the set of PDUs, then stopping the transmission of the set of PDUs.

[0007] The determination of the AL-FEC encoded PDU set, the associated AL-FEC aware signaling, and the PDU set metadata enable optimization of downstream processing. In an embodiment, the latter information is processed by a RAN node for the purpose of discarding one or more PDUs from the PDU set. Transmission may be stopped when sufficient information is delivered to recover the ADU, or when sufficient information is lost so that the ADU cannot be recovered. In either scenario, further transmission of the PDUs in the PDU set will waste communication bandwidth. Therefore, stopping the transmission of the PDU set when the stopping criteria are met can prevent wasted transmission. This results in more efficient bandwidth usage in the wireless communication network.

[0008] A node in a wireless communication network is also provided, the node comprising a receiver and a processor. The receiver is arranged to receive a set of protocol data units (PDUs) corresponding to an encoded application data unit (ADU) from an application, wherein the encoding is based on an application layer forward error correction (AL-FEC) encoding configuration. The processor is arranged to identify an application layer forward error correction (AL-FEC) encoding configuration used to encode the encoded ADU. The processor is also arranged to process the transmission of the PDU set. The processor is also arranged to determine whether a stop criterion is met, the stop criterion being derived from the AL-FEC encoding configuration for the PDU set, and if the stop criterion is met for the PDU set, the transmission of the PDU set is stopped.

[0009] The node may include a base station (gNB), wherein the PDUs travel in a downlink direction. The node may include a user equipment (UE), wherein the PDUs travel in an uplink direction. The application may include an application server or an application client. Processing the transmission of the PDU set includes sending the PDUs in the PDU set to a transmitter transceiver for transmission.

[0010] A method in a user equipment device of a wireless communication network is also provided. The method includes receiving a subset of protocol data units (PDUs) in a set of PDUs, the PDU set corresponding to an encoded application data unit (ADU) and an application level forward error correction (AL-FEC) coding configuration, wherein the encoding of the encoded ADU is based on the AL-FEC coding configuration. The method also includes sending a delivery confirmation in response to the received PDU, and receiving an indication that no additional PDUs belonging to the PDU set will be sent. The method also includes processing decoding of the encoded ADU based on the received AL-FEC coding configuration and the received subset of PDUs.

[0011] A user equipment device for communicating with a wireless communication network is also provided, the user equipment device comprising a receiver, a transmitter and a processor. The receiver is arranged to receive a subset of protocol data units (PDUs) in a set of PDUs, the PDU set corresponding to an encoded application data unit (ADU) and an application level forward error correction (AL-FEC) coding configuration, wherein the encoding of the encoded ADU is based on the AL-FEC coding configuration. The transmitter is arranged to send a delivery confirmation in response to the received PDU. The receiver is also arranged to receive an indication that no additional PDUs belonging to the PDU set will be sent. The processor is arranged to decode the encoded ADU based on the received AL-FEC coding configuration and the received PDU subset. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to describe the manner in which the advantages and features of the present disclosure can be obtained, a description of the present disclosure is presented by reference to certain devices and methods shown in the accompanying drawings. Each of these drawings depicts only certain aspects of the present disclosure and therefore should not be considered as limiting the scope thereof. For the sake of clarity, the drawings may have been simplified and are not necessarily drawn to scale.

[0013] A method and apparatus for efficient transmission of PDU sets in a wireless communication network will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0014] Figure 1 Embodiments of a wireless communication system for efficient transmission of a set of PDUs in a wireless communication network are described;

[0015] Figure 2 depicts a user equipment device that may be used to implement the methods described herein;

[0016] Figure 3 depicts further details of a network node that may be used to implement the methods described herein;

[0017] Figure 4A method in a node of a wireless communication network is illustrated;

[0018] Figure 5 An overview of the core network architecture for processing a set of PDUs for a content delivery example for XR media is illustrated;

[0019] Figure 6 Provides an overview of the RTP and RTCP stacks;

[0020] Figure 7 Diagram showing an overview of the WebRTC stack;

[0021] Figure 8 illustrates the packet format and header information for both RTP packets and SRTP packets;

[0022] Fig. 9 is a diagram of the AL-FEC XR application flow, including encoding, packetization, and transmission;

[0023] Fig.10 The output of the encoding process is shown for a source stream corresponding to an encoded source PDU, and a repair stream corresponding to an encoded repair PDU;

[0024] Fig.11 The invention illustrates the architecture and process for information exchange determined by the set of AL-FEC coded PDUs supporting DL direction and UL direction;

[0025] Fig.12 illustrates determination of an AL-FEC encoded PDU set consisting of a first subset of source PDUs and a second subset of repair PDUs;

[0026] Fig.13 Figure 5 shows the 5GS GTP-U data plane protocol stack for a PDU session.

[0027] Fig.14 The diagram shows the structure of the GTP-U header;

[0028] Fig.15 An example of a minimum size extension header for an AL-FEC encoded PDU set is presented;

[0029] Fig.16 illustrates three example RAN discard strategies for PDUs in a set of AL-FEC encoded PDUs; and

[0030] Fig.17 A method in a user equipment device of a wireless communication network is illustrated. DETAILED DESCRIPTION

[0031] Those skilled in the art will appreciate that aspects of the present disclosure may be embodied as systems, devices, methods or program products. Therefore, the arrangements described herein may be implemented in full hardware form, full software form (including firmware, resident software, microcode, etc.), or in a combination of software and hardware aspects.

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

[0033] In addition, the method and apparatus may take the form of a program product embodied in one or more computer-readable storage devices storing machine-readable code, computer-readable code, and / or program code, hereinafter referred to as code. The storage device may be tangible, non-transitory, and / or non-transmitting. The storage device may not embody a signal. In some arrangements, the storage device employs only a signal for accessing the code.

[0034] Any combination of one or more computer readable media may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device storing code. The storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

[0035] More specific examples of storage devices (a non-exhaustive list) include the following: an electrical connection having one or more conductors, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the context of this document, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by an instruction execution system, apparatus, or device user in conjunction with the instruction execution system, apparatus, or device.

[0036] Throughout this specification, references to examples or similar language of a particular method or device mean that the specific features, structures or characteristics described in conjunction with the example are included in at least one implementation of the methods and devices described herein. Therefore, unless otherwise expressly provided, references to examples or similar language features of a particular method or device may but do not necessarily all refer to the same example, but mean "one or more but not all examples". Unless otherwise expressly provided, the terms "including", "comprising", "having" and their variants mean "including but not limited to". Unless otherwise expressly provided, an enumerated list of items does not imply that any or all items are mutually exclusive. Unless otherwise expressly provided, the terms "one", "a kind of" and "the" also refer to "one or more".

[0037] As used herein, a list with the conjunction "and / or" includes any single item in the list or a combination of items in the list. For example, a list of A, B, and / or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term "one or more of ..." includes any single item in the list or a combination of items in the list. For example, one or more of A, B, and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term "one of ..." includes one and only one of any single item in the list. For example, "one of A, B, and C" includes only A, only B, or only C, and does not include a combination of A, B, and C. As used herein, "a member selected from a group consisting of A, B, and C" includes one and only one of A, B, or C, and does not include a combination of A, B, and C. As used herein, “a member selected from the group consisting of A, B and C and combinations thereof” includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B and C.

[0038] In addition, the features, structures or characteristics described herein may be combined in any suitable manner. In the following description, many specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a comprehensive understanding of the present disclosure. However, those skilled in the relevant art will recognize that the disclosed methods and apparatus may be practiced without one or more of the specific details, or may be practiced using other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid confusing aspects of the present disclosure.

[0039] Aspects of the disclosed methods and devices are described below with reference to schematic flow charts and / or schematic block diagrams of methods, devices, systems, and program products. It will be understood that each frame of the schematic flow chart and / or schematic block diagram, and the combination of frames in the schematic flow chart and / or schematic block diagram can be implemented by code. The code can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, so that instructions executed by a processor of a computer or other programmable data processing device create components for implementing the functions / actions specified in the schematic flow chart and / or schematic block diagram.

[0040] The code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other device to work in a specific manner so that the instructions stored in the storage device produce an article of manufacture that includes instructions for implementing the functions / actions specified in the schematic flowchart and / or schematic block diagram.

[0041] The code may also be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operating steps are executed on the computer, other programmable apparatus, or other device, thereby producing a computer-implemented process, so that the code executed on the computer or other programmable apparatus provides a process for implementing the functions / actions specified in the schematic flowchart and / or schematic block diagram.

[0042] The schematic flow charts and / or schematic block diagrams in the figure illustrate the possible implementation architectures, functions and operations of the apparatus, system, method and program product. In this regard, each box in the schematic flow chart and / or schematic block diagram may represent a module, segment or portion of code, which includes one or more executable instructions for implementing the code of (multiple) specified logical functions.

[0043] It should also be noted that in some alternative implementations, the functions shown in the blocks may not appear in the order shown in the figures. For example, two blocks shown in succession may, in fact, be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order, depending on the functions involved. Other steps and methods may be envisioned that are equivalent in function, logic, or effect to one or more blocks, or portions thereof, of the illustrated figures.

[0044] The description of the elements in each figure can refer to the elements in the subsequent figures.

[0045] Figure 1 An embodiment of a wireless communication system 100 for efficient transmission of PDU sets in a wireless communication network is depicted. In one embodiment, the wireless communication system 100 includes a remote unit 102 and a network unit 104. Although Figure 1 A specific number of remote units 102 and network units 104 are depicted in the wireless communication system 100, but those skilled in the art will recognize that any number of remote units 102 and network units 104 may be included in the wireless communication system 100. The remote unit 102 may include a user equipment device 200, a sender 900, or a UE 535, UE 1135, UE 1310 as described herein. The base station unit 104 may include a network node 300, or a UPF 540, UPF 1140, UPF 1340 as described herein.

[0046] In one embodiment, the remote unit 102 may include a computing device such as a desktop computer, a laptop computer, a personal digital assistant (PDA), a tablet computer, a smart phone, a smart TV (e.g., a TV connected to the Internet), a set-top box, a game console, a security system (including a security camera), a car computer, a network device (e.g., a router, a switch, a modem), an aircraft, a drone, etc. In some embodiments, the remote unit 102 includes a wearable device such as a smart watch, a fitness band, an optical head-mounted display, etc. In addition, the remote unit 102 may be referred to as a subscriber unit, a mobile device, a mobile station, a user, a terminal, a mobile terminal, a fixed terminal, a subscriber station, a UE, a user terminal, a device, or other terms used in the art. The remote unit 102 can communicate directly with one or more of the network units 104 via UL communication signals. In some embodiments, the remote unit 102 can communicate directly with other remote units 102 via sidelink communication.

[0047] The network elements 104 may be distributed over geographical intervals. In some embodiments, the network elements 104 may also be referred to as access points, access terminals, base stations, base stations, node Bs, eNBs, gNBs, home node Bs, relay nodes, devices, core networks, air servers, radio access nodes, APs, NRs, network entities, access and mobility management functions (AMFs), unified data management functions (UDMs), unified data repositories (UDRs), UDM / UDRs, policy control functions (PCFs), radio access networks (RANs), network slice selection functions (NSSFs), operations, maintenance, and management (OAMs), session management functions (SMFs), user plane functions (UPFs), application functions, authentication server functions (AUSFs), security anchor functions (SEAFs), trusted non-3GPP gateway functions (TNGFs), application functions, service enablement architecture layer (SEAL) functions, vertical application enablement servers, edge enablement servers, edge configuration servers, mobile edge computing platform functions, mobile edge computing applications, application data analysis enablement servers, SEAL data delivery servers, middleware entities, network slice capability management servers, or any other terminology used in the art. The network elements 104 are generally part of a radio access network that includes one or more controllers communicatively coupled to one or more corresponding network elements 104. The radio access network is generally communicatively coupled to one or more core networks, which may be coupled to other networks, such as the Internet and a public switched telephone network, etc. These and other elements of the radio access network and core network are not illustrated, but are generally known to those of ordinary skill in the art.

[0048] In one implementation, the wireless communication system 100 complies with the New Radio (NR) protocol standardized in 3GPP, wherein the network unit 104 transmits on the downlink (DL) using an orthogonal frequency division multiplexing (OFDM) modulation scheme, and the remote unit 102 transmits on the uplink (UL) using a single carrier frequency division multiple access (SC-FDMA) scheme or an OFDM scheme. However, more generally, the wireless communication system 100 may implement some other open or proprietary communication protocol, such as WiMAX, IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA2000, ZigBee, Sigfox, etc. The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol.

[0049] The network unit 104 can serve multiple remote units 102 within a service area (eg, a cell or cell sector) via wireless communication links. The network unit 104 sends DL communication signals to serve the remote units 102 in the time, frequency, and / or spatial domains.

[0050] Figure 2 A user equipment device 200 is depicted that can be used to implement the methods described herein. The user equipment device 200 is used to implement one or more of the solutions described herein. The user equipment device 200 conforms to one or more of the user equipment devices described in the embodiments herein. In particular, the user equipment device 200 may include a remote unit 102, a sender 900, or a UE 535, UE 1135, UE 1310 as described herein. The user equipment device 200 includes a processor 205, a memory 210, an input device 215, an output device 220, and a transceiver 225.

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

[0052] As depicted, the transceiver 225 includes at least one transmitter 230 and at least one receiver 235. The transceiver 225 can communicate with one or more cells (or wireless coverage areas) supported by one or more base station units. The transceiver 225 can be operable on an unlicensed spectrum. In addition, the transceiver 225 can include multiple UE panels supporting one or more beams. Additionally, the transceiver 225 can support at least one network interface 240 and / or application interface 245. (Multiple) application interface 245 can support one or more APIs. (Multiple) network interface 240 can support 3GPP reference points such as Uu, N1, PC5, etc. As understood by those of ordinary skill in the art, other network interfaces 240 can be supported.

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

[0054] Processor 205 may control user equipment device 200 to implement the user equipment device behaviors described herein. Processor 205 may include an application processor (also referred to as a main processor) that manages application domain and operating system (OS) functions and a baseband processor (also referred to as a baseband radio processor) that manages radio functions.

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

[0056] The memory 210 may store data related to implementing the traffic class field as described herein. The memory 210 may also store program code and related data, such as an operating system or other controller algorithms operating on the device 200.

[0057] Input device 215 may include any known computer input device, including a touchpad, buttons, keyboard, stylus, microphone, etc. Input device 215 may be integrated with output device 220, for example, as a touch screen or similar touch-sensitive display. Input device 215 may include a touch screen so that text can be entered using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. Input device 215 may include two or more different devices, such as a keyboard and a touchpad.

[0058] The output device 220 may be designed to output visual signals, auditory signals, and / or tactile signals. The output device 220 may include an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 220 may include, but is not limited to, a liquid crystal display (LCD), a light emitting diode (LED) display, an organic LED (OLED) display, a projector, or a similar display device capable of outputting images, text, etc. to a user. As another non-limiting example, the output device 220 may include a wearable display that is separate from the rest of the user device apparatus 200 but communicatively coupled to the rest, such as a smart watch, smart glasses, a head-up display, etc. In addition, the output device 220 may be a component of a smart phone, a personal digital assistant, a television, a desktop computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, etc.

[0059] Output device 220 may include one or more speakers for producing sound. For example, output device 220 may produce an audible alarm or notification (e.g., a beep or buzzer). Output device 220 may include one or more tactile devices for producing vibration, motion, or other tactile feedback. All or part of output device 220 may be integrated with input device 215. For example, input device 215 and output device 220 may form a touch screen or similar touch-sensitive display. Output device 220 may be located near input device 215.

[0060] The transceiver 225 communicates with one or more network functions of the mobile communication network via one or more access networks. The transceiver 225 operates under the control of the processor 205 to send messages, data, and other signals, and also receives messages, data, and other signals. For example, the processor 205 can selectively activate the transceiver 225 (or part thereof) at a specific time to send and receive messages.

[0061] The transceiver 225 includes at least one transmitter 230 and at least one receiver 235. One or more transmitters 230 can be used to provide uplink communication signals to the base station unit of the wireless communication network. Similarly, one or more receivers 235 can be used to receive downlink communication signals from the base station unit. Although only one transmitter 230 and one receiver 235 are shown, the user equipment device 200 can have any suitable number of transmitters 230 and receivers 235. In addition, (multiple) transmitters 230 and (multiple) receivers 235 can be any suitable type of transmitter and receiver. The transceiver 225 may include a first transmitter / receiver pair for communicating with a mobile communication network on a licensed radio spectrum, and a second transmitter / receiver pair for communicating with a mobile communication network on an unlicensed radio spectrum.

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

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

[0064] Figure 3 Depicted are further details of a network node 300 that may be used to implement the methods described herein. The network node 300 may include a base station unit 104, or a UPF 540, UPF 1140, UPF 1340 as described herein. The network node 300 includes a processor 305, a memory 310, an input device 315, an output device 320, and a transceiver 325.

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

[0066] As depicted, the transceiver 325 includes at least one transmitter 330 and at least one receiver 335. Here, the transceiver 325 communicates with one or more remote units 200. In addition, the transceiver 325 can support at least one network interface 340 and / or application interface 345. (Multiple) application interface 345 can support one or more APIs. (Multiple) network interface 340 can support 3GPP reference points such as Uu, N1, N2, and N3. As understood by those of ordinary skill in the art, other network interfaces 340 can be supported.

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

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

[0069] The memory 310 may store data related to establishing a multipath unicast link and / or mobile operation. For example, as described herein, the memory 310 may store parameters, configurations, resource allocations, policies, etc. The memory 310 may also store program codes and related data, such as an operating system or other controller algorithms operating on the network node 300.

[0070] Input device 315 may include any known computer input device, including a touchpad, buttons, keyboard, stylus, microphone, etc. Input device 315 may be integrated with output device 320, for example, as a touch screen or similar touch-sensitive display. Input device 315 may include a touch screen so that text can be entered using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. Input device 315 may include two or more different devices, such as a keyboard and a touchpad.

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

[0072] Output device 320 may include one or more speakers for producing sound. For example, output device 320 may produce an audible alarm or notification (e.g., a beep or buzzer). Output device 320 may include one or more tactile devices for producing vibration, motion, or other tactile feedback. All or part of output device 320 may be integrated with input device 315. For example, input device 315 and output device 320 may form a touch screen or similar touch-sensitive display. Output device 320 may be located near input device 315.

[0073] The transceiver 325 includes at least one transmitter 330 and at least one receiver 335. One or more transmitters 330 can be used to communicate with the UE, as described herein. Similarly, one or more receivers 335 can be used to communicate with network functions in the PLMN and / or RAN, as described herein. Although only one transmitter 330 and one receiver 335 are illustrated, the network node 300 can have any suitable number of transmitters 330 and receivers 335. In addition, the (multiple) transmitters 330 and (multiple) receivers 335 can be any suitable type of transmitter and receiver.

[0074] Figure 4 A method 400 in a node of a wireless communication network is illustrated. The method includes receiving 410 a set of protocol data units (PDUs) corresponding to an encoded application data unit (ADU) from an application, wherein the encoding is based on an application layer forward error correction (AL-FEC) encoding configuration. The method also includes receiving 420 an application layer forward error correction (AL-FEC) encoding configuration used to encode the encoded ADU; and processing 430 transmission of the set of PDUs. The method also includes determining 440 whether a stopping criterion is satisfied, the stopping criterion being derived for the set of PDUs from the AL-FEC encoding configuration, and stopping transmission of the set of PDUs if the stopping criterion is satisfied for the set of PDUs.

[0075] The determination of the AL-FEC encoded PDU set, the AL-FEC aware related signaling, and the PDU set metadata enable optimization of downstream processing. In an embodiment, the latter information is processed by a RAN node for the purpose of discarding one or more PDUs from the PDU set. Transmission may be stopped when sufficient information is delivered to recover the ADU, or when sufficient information is lost so that the ADU cannot be recovered. In either scenario, further transmission of the PDUs in the PDU set will waste communication bandwidth. Therefore, stopping the transmission of the PDU set when the stopping criteria are met can prevent wasted transmission. This results in more efficient bandwidth usage in the wireless communication network.

[0076] Processing transmission of the PDU set includes sending the PDUs in the PDU set to a transmitter for transmission. Stopping transmission of the PDU set may include sending an indication that no further PDUs belonging to the PDU set are to be sent.

[0077] The received set of PDUs may include both a plurality of source PDUs and a plurality of repair PDUs, wherein the repair PDUs are associated with the source PDUs based on encoding using the AL-FEC coding configuration. The repair PDUs may be recovery PDUs. The stopping criteria may include a threshold of a minimum necessary PDU in the set of coded PDUs required to recover the coded ADUs.

[0078] Determination of the threshold for the minimum required PDU can be based in part on a determined AL-FEC coding scheme configuration, the configuration further comprising at least one of: a coding rate indication; an indication of multiple source PDUs and an indication of multiple repair PDUs; an explicit indication of the minimum number of PDUs within an encoded PDU set that need to be sent for the ADU to be recovered; an associated QoS flow requirement for a PDU error rate; and an associated QoS flow requirement for a PDU set error rate.

[0079] The coding rate indication may include a ratio of the number of source coding symbols included in the source PDU to the total number of coding symbols included in the coded PDU set, a redundancy level corresponding to a percentage of repair PDUs to source PDUs of the coded PDU set, and / or the number of source PDUs and the total number of PDUs contained in the coded PDU set. The indication of the subset of source PDUs and the indication of the subset of repair PDUs may include marking the PDU sets of source PDUs and repair PDUs via a bit field in the GTP-U header.

[0080] The stopping criteria may include the successful transmission of a certain number of PDUs in the PDU set, which number is greater than or equal to a threshold of the minimum necessary PDUs required to recover the ADU. The stopping criteria may correspond to the successful transmission of the ADU information encoded by the PDU set by recovering the ADU information. The stopping criteria may include the successful transmission of a certain number of PDUs in the PDU set, which number is greater than or equal to the total number of PDUs in the PDU set minus a threshold of the maximum number of PDUs that can be lost from the PDU set but still allow the ADU to be recovered. The threshold of the maximum number of PDUs that can be lost from the PDU set but still allow the ADU to be recovered is: the mathematical complement of the threshold of the minimum necessary PDUs required to recover the ADU, relative to the total number of PDUs in the PDU set.

[0081] The stopping criteria may include unsuccessful transmission of a second number of PDUs in the PDU set, wherein the second number of PDUs is greater than or equal to the total number of PDUs in the PDU set minus a threshold of the minimum necessary PDUs required to recover the ADUs. The stopping criteria may correspond to unsuccessful transmission of ADU information encoded by the PDU set. The stopping criteria may include unsuccessful transmission of a certain number of PDUs in the PDU set, which is greater than or equal to a threshold of the maximum number of PDUs that can be lost from the PDU set but still allow the ADUs to be recovered. The threshold of the maximum number of PDUs that can be lost from the PDU set but still allow the ADUs to be recovered is: the mathematical complement of the threshold of the minimum necessary PDUs required to recover the ADUs relative to the total number of PDUs in the PDU set.

[0082] The stopping criteria may include successful transmission of the source PDU. Determining whether the stopping criteria are met may be determined based on a delivery confirmation received by the node. A delivery confirmation may be sent as a reply to each received PDU.

[0083] The determination may be made depending on the number and / or nature of the delivery confirmation. The delivery confirmation may include a hybrid automatic repeat request confirmation and / or an automatic repeat request confirmation. The nature of the delivery confirmation may include delivery confirmed, or delivery not confirmed.

[0084] A node in a wireless communication network is also provided, the node comprising a receiver and a processor. The receiver is arranged to receive a set of protocol data units (PDUs) corresponding to an encoded application data unit (ADU) from an application, wherein the encoding is based on an application layer forward error correction (AL-FEC) encoding configuration. The processor is arranged to identify the application layer forward error correction (AL-FEC) encoding configuration used to encode the encoded ADU. The processor is also arranged to process the transmission of the PDU set. The processor is also arranged to determine whether a stop criterion is met, the stop criterion being derived from the AL-FEC encoding configuration for the PDU set, and if the stop criterion is met for the PDU set, the transmission of the PDU set is stopped.

[0085] The node may include a base station (gNB), wherein the PDUs travel in a downlink direction. The node may include a user equipment (UE), wherein the PDUs travel in an uplink direction. The application may include an application server or an application client. Processing the transmission of the PDU set includes sending the PDUs in the PDU set to a transmitter transceiver for transmission.

[0086] The received set of PDUs may include both a plurality of source PDUs and a plurality of repair PDUs, wherein the repair PDUs are associated with the source PDUs based on encoding using the AL-FEC coding configuration. The repair PDUs may be recovery PDUs. The stopping criteria may include a threshold of a minimum necessary PDU in the set of coded PDUs required to recover the coded ADUs.

[0087] Determination of the threshold for the minimum required PDU can be based in part on a determined AL-FEC coding scheme configuration, which AL-FEC coding scheme configuration also includes at least one of: a coding rate indication; an indication of multiple source PDUs and an indication of multiple repair PDUs; an explicit indication of the minimum number of PDUs within an encoded PDU set that need to be sent for the ADU to be recovered; an associated QoS flow requirement for a PDU error rate; and an associated QoS flow requirement for a PDU set error rate.

[0088] The coding rate indication may include a ratio of the number of source coding symbols included in the source PDU to the total number of coding symbols included in the coded PDU set, a redundancy level corresponding to a percentage of repair PDUs to source PDUs of the coded PDU set, and / or the number of source PDUs and the total number of PDUs contained in the coded PDU set. The indication of the subset of source PDUs and the indication of the subset of repair PDUs may include marking the PDU sets of source PDUs and repair PDUs via a bit field in the GTP-U header.

[0089] The stopping criteria may include the successful transmission of a certain number of PDUs of the PDU set, which number is greater than or equal to a threshold of the minimum necessary PDUs required to recover the ADU. The stopping criteria may correspond to the successful transmission of the ADU information encoded by the PDU set by recovering the ADU information. The stopping criteria may include the successful transmission of a certain number of PDUs in the PDU set, which number is greater than or equal to the total number of PDUs in the PDU set minus a threshold of the maximum number of PDUs that can be lost from the PDU set but still allow the ADU to be recovered. The threshold of the maximum number of PDUs that can be lost from the PDU set but still allow the ADU to be recovered is: the mathematical complement of the threshold of the minimum necessary PDUs required to recover the ADU, relative to the total number of PDUs in the PDU set.

[0090] The stopping criteria may include unsuccessful transmission of a second number of PDUs in the PDU set, wherein the second number of PDUs is greater than or equal to the total number of PDUs in the PDU set minus a threshold of the minimum necessary PDUs required to recover the ADUs. The stopping criteria may correspond to unsuccessful transmission of ADU information encoded by the PDU set. The stopping criteria may include unsuccessful transmission of a certain number of PDUs in the PDU set, which is greater than or equal to a threshold of the maximum number of PDUs that can be lost from the PDU set but still allow the ADUs to be recovered. The threshold of the maximum number of PDUs that can be lost from the PDU set but still allow the ADUs to be recovered is: the mathematical complement of the threshold of the minimum necessary PDUs required to recover the ADUs relative to the total number of PDUs in the PDU set.

[0091] Determining whether the stopping criteria is satisfied can be determined based on the delivery confirmation received by the node. The determination can be made depending on the number and / or nature of the delivery confirmation. The delivery confirmation can include a hybrid automatic repeat request confirmation and / or an automatic repeat request confirmation. The nature of the delivery confirmation can include delivery confirmed, or delivery unconfirmed.

[0092] In the 3GPP technical standard version 18, the study of XR Media (XRM) at the CN level introduced the concept of PDU sets to handle the QoS requirements of XRM applications and flows with a finer granularity beyond the possibility of QoS flows. Therefore, according to the 3GPP technical report TR 23.700-60 (v0.0.3), a PDU set consists of one or more PDUs that carry the payload of an information unit generated at the application level (e.g., a frame or video slice for an XRM service). In some implementations, the application layer requires all PDUs in the PDU set to use the corresponding information unit. In other implementations, when some PDUs are lost, the application layer can still recover some or all of the information units.

[0093] In addition, the PDU set is associated with the QoS requirements in terms of delay budget and error rate (which can be defined as PDU set delay budget (PSDB) and / or PDU set error rate (PSER)). The PDU set delay budget (PSDB) defines the upper limit of the time that the PDU set can be delayed between the N6 termination point at the UE and the UPF. The PSDB is applied to the DL PDU set received by the UPF through the N6 interface and the UL PDU set sent by the UE respectively. The PDU set error rate (PSER) defines the upper limit of the ratio of the PDU set (e.g., the set of IP packets constituting the PDU set) that has been processed by the sender of the link layer protocol (e.g., RLC in the RAN accessed by 3GPP), but in which all PDUs in the PDU set are not successfully delivered to the upper layer (e.g., PDCP in the RAN accessed by 3GPP) by the corresponding receiver. The PSER can be used to determine the upper limit of the non-congestion related packet loss rate.

[0094] Figure 5 An overview of the Core Network (CN) XRM architecture for processing PDU aggregation is illustrated. Figure 5 A system 500 is shown, which includes an extended reality media application function (XRM AF) 510, a policy and control function (PCF) 515, a session management function (SMF) 520, an access and mobility function (AMF) 525, a radio access network (RAN 530), a user equipment (UE) 535, a user plane function (UPF) 540, and an extended reality application 545. The UE 535 may include a remote unit 102, a user equipment device 200, a sender 900, or a UE 1135, UE 1310 as described herein. The UPF 540 may include a base station unit 104, a network node 300, or a UPF 1140, UPF 1340 as described herein. The operation of the system 500 will now be described in the example of downlink traffic, and similar processes may operate for uplink traffic.

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

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

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

[0098] At 583, SMF 520 establishes a QoS flow according to the QoS rules of PCF 515, and configures UPF to route packets of the XR application to the QoS flow, and in addition, configures UPF to enable PDU aggregate processing. SMF 520 also provides a QoS profile containing PDU aggregate QoS requirements to RAN 530 via AMF 525. AMF 525 can provide a QoS profile containing PDU aggregate QoS requirements to RAN 530 in an N2 session management (SM) container. In addition, AMF 525 can provide QoS rules to UE 535 in an N1 SM container.

[0099] At 584, the UPF 540 inspects the packets and determines the packets that belong to the PDU set. The packet inspection may include inspecting the RTP packets. When the UPF 540 detects the packets of the PDU set, the UPF 540 marks the packets that belong to the PDU set in the GTP-U header. The GTP-U header information includes the PDU set sequence number and the size of the PDU set. The UPF 540 may also determine the importance of the PDU set based on the UPF 540 implementation, the information provided by the XRM AF 510, or the information provided as metadata from the XRM application server. Based on the importance of the PDU set, the UPF 540 may route the service to the corresponding QoS flow 1 (according to the rules received from the SMF 520), or include the importance of the PDU set in the GTP-U header. QoS flow 1 may include a GTP-U header, and the header may include PDU set information.

[0100] At 585, the RAN 530 identifies packets belonging to the PDU set (based on the GTP-U marking) and processes the packets of the PDU set according to the QoS requirements of the PDU set provided by the SMF 520. In one implementation, the RAN 530 node may use different radio bearers with higher QoS requirements (according to the PDU set PSDB / PSER) to guarantee the delivery of the packets of the PDU set, while using different radio bearers according to the 5QI of the QoS flow for non-PDU set packets. The RAN 530 may receive the QFI, the QoS profile of the QoS flow (including PDSB and PSER) from the SMF 520 (via the AMF 525) during the PDU session establishment / modification. The RAN 530 checks the GTP-U header and ensures that all packets of the same PDU set are processed according to the QoS profile. This may include packets of the PDU set in the radio bearer carrying QoS flow 1. This may also include sending packets that do not belong to the PDU set in a different radio bearer carrying QoS flow 2.

[0101] The above examples involve downlink (DL) traffic. Reciprocal processing applies to uplink (UL) traffic, where the role of UPF 540 packet inspection is assumed by the UE 535, which is expected to inspect the uplink packets, determine the packets belonging to the PDU set, and accordingly signal the PDU set to the RAN 530 for scheduling and resource allocation corresponding to the associated DRBs that can meet the PDU set QoS requirements (i.e., PSDB and PSER). The low-level signaling mechanisms associated with the UL UE to RAN information transfer depend on the specification and implementation of the RAN signaling procedures.

[0102] Herein, extended reality (XR) is used as an umbrella term for different types of reality, of which virtual reality, augmented reality, and mixed reality are examples.

[0103] Virtual reality (VR) is a rendered version of a delivered visual and audio scene. In this case, the rendering is designed to mimic the visual and auditory stimuli of the real world as naturally as possible as the observer or user moves within the limits defined by the application. Virtual reality typically (but not necessarily) requires the user to wear a head-mounted display (HMD) to completely replace the user's field of view with simulated visual components, and requires the user to wear headphones to provide incidental audio to the user. In VR, some form of head and motion tracking of the user is also typically required to allow the simulated visual and audio components to be updated, ensuring that from the user's perspective, objects and sound sources are consistent with the user's movements. In some implementations, additional means for interacting with the virtual reality simulation may be provided, but are not strictly necessary.

[0104] Augmented reality (AR) is the provision of additional information or artificially generated items to a user, or content superimposed on the user's current environment. Such additional information or content is typically visual and / or auditory, and the user's observation of their current environment can be direct, where there is no intervening sensing, processing, and rendering, or indirect, where their perception of their environment is relayed via sensors and can be augmented or processed.

[0105] Mixed reality (MR) is an advanced form of AR in which some virtual elements are inserted into the physical scene with the aim of providing the illusion that these elements are part of the real scene.

[0106] XR refers to all real and virtual environments and human-computer interactions generated by computer technology and wearable devices. XR includes representative forms such as AR, MR and VR and interpolation areas between them. The level of virtuality ranges from partial sensory input to fully immersive VR. In some circles, a key aspect of XR is considered to be an extension of human experience, especially human experience related to presence (represented by VR) and cognitive acquisition (represented by AR).

[0107] In 3GPP Release 17, the 3GPP SA4 working group analyzed the media delivery protocols and XR business models in the technical report TR 26.926 (v1.1.0) entitled "Business Models and Quality Assessment Methods for Media and XR Services in 5G Systems" and determined the QoS requirements in terms of delay budget, data rate and error rate required for a satisfactory experience at the application level. This resulted in 4 additional 5G QoS Identifiers (5QIs) for 5GS XR QoS flows. These 5QIs are defined in 3GPPTS23.501 (v17.5.0) Table 5.7.4-1 and are presented as delay-critical GBR 5QIs with values ​​of 87-90. The latter applies to XR video streams and the control metadata required to provide immersive and interactive XR experiences.

[0108] XR video services mainly consist of multiple DL / UL video streams with high resolution (e.g., typically at least 1080p binocular buffer), frames per second (e.g., 60+fps), and high bandwidth (e.g., typically at least 20-30Mbps), which need to be sent across the network with minimal latency (typically capped at 15-20ms) to maintain reduced end-to-end application round-trip interaction latency. The latter requirement is critical given XR applications' reliance on cloud / edge processing (e.g., content download, viewport generation and configuration, viewport update, viewport rendering, media encoding / transcoding, etc.).

[0109] To support such stringent latency-critical requirements specific to real-time communications (RTC) with high bandwidth (e.g., XR video streaming), the high-level protocol envisioned for delivering XR immersive multimedia applications is the Real-time Transport Protocol (RTP). In this context, reference may be made to the 3GPP Technical Report TR 26.928 (v17.0.0) entitled “Extended Reality (XR) in 5G”. In some implementations, secure RTP variants such as vanilla Secure Real-time Transport Protocol (SRTP) or a web browser-based WebRTC stack may be used to serve XR applications across mobile communication networks such as 5GS.

[0110] 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, as defined in the IETF standard RFC 3550 entitled "RTP: A Transport Protocol for Real-Time Applications." RTP is used in conjunction with a sister protocol for control, the RTP Control Protocol (RTCP), to provide end-to-end functions such as jitter compensation, packet loss and out-of-order delivery detection, synchronization, and source stream multiplexing.

[0111] Figure 6 An overview of the RTP and RTCP stacks is provided. The IP layer 605 carries signaling from the media session data plane 610 and from the media session control plane 650. The data plane 610 stack includes functionality for the User Datagram Protocol (UDP) 612, RTP 616, RTCP 614, media codecs 620, and quality control 622. The control plane 650 stack includes functionality for UDP 652, Transmission Control Protocol (TCP) 654, Session Initiation Protocol (SIP) 662, and Session Description Protocol (SDP) 664.

[0112] SRTP is a secure version of RTP and is defined by the IETF in RFC 3711 "Secure Real-time Transport Protocol (SRTP)". SRTP provides encryption (payload confidentiality), message authentication and integrity (header and payload signatures), replay attack protection. Similarly, SRTP sister protocol SRTCP provides the same functionality to its RTCP counterpart. Therefore, in SRTP, the RTP header information remains accessible but unmodifiable, while the payload is encrypted. For this reason, SRTP is used in the WebRTC stack, which ensures secure RTC multimedia communications through a web browser interface.

[0113] Figure 7An overview of the WebRTC stack is illustrated. The IP layer 705 carries signaling from the data plane 710 and the control plane 750. The data plane 710 stack includes functions for UDP 712, interactive connection establishment (ICE) 724, datagram transport layer security (DTLS) 726, SRTP 717, SRTCP 715, media codes 720, quality control 722, and SCTP 728. ICE 724 can use the Session Traversal Utilities for NAT (STUN) protocol and traversal using relays around NAT (TURN) to address real-time media content delivery across heterogeneous networks and NAT rules. SCTP 728 can be non-time critical. SRTP 717, SRTCP 715, media codes 720, and quality control 722 can be time critical.

[0114] Figure 8 Illustrated are packet formats and header information for both RTP packets 830 and SRTP packets 860. The header information is available for inspection and processing, and an overview is provided below, including a brief description of certain fields of interest in the header portion of the RTP / SRTP packet format.

[0115] “X” 834, 864 is 1 bit, indicating that the standard fixed RTP / SRTP header will be followed by an RTP header extension that is typically associated with specific data / profile and will carry more information about the data (e.g., a frame marking RTP header extension for video data, as defined in RTP Frame Marking RTP Header Extension (November 2021) - draft-ietf-avtext-framemarking-13).

[0116] "CC" 836, 866 is 4 bits and indicates the number of contributing media sources (CSRC) following the header.

[0117] "M" 838, 868 is 1 bit and is intended to mark the information frame boundary in the packet stream. The behavior of this "M" is precisely specified by the RTP profile (e.g., H.264, H.265, H.266, AV1, etc.)

[0118] "PT" 840, 870 is 7 bits indicating the payload type, which in the case of a video profile is dynamic and negotiated with the aid of SDP (e.g., 96 for H.264, 97 for H.265, 98 for AV1, etc.).

[0119] "Sequence Number" 842, 872 is 16 bits and indicates a sequence number that is incremented by 1 with each RTP packet sent on the session.

[0120] "Timestamp" 844, 874 is 32 bits, indicating a timestamp in ticks of the payload type clock, which reflects the sampling moment of the first eight-bit byte of the RTP data packet (associated with the video frame for a video stream), and the first timestamp of the first RTP packet is randomly selected.

[0121] "Synchronization Source (SSRC) Identifier" 846, 876 is a 32-bit field that indicates a random identifier for the source of the RTP packet stream that forms part of the same timing and sequence number space so that the receiver can group packets based on the synchronization source for playback.

[0122] In the following, we refer to a video frame as a video encoding representation of a still image presented in a sequence that constitutes a video stream. On the other hand, a video frame may consist of one or more video slices. A video slice is an encoded video representation of a partition of a still image portion of a video sequence. In some implementations (e.g., H.266, AV1), a video slice may refer to a rectangular partition (e.g., tile) of a still image, while in other implementations (e.g., H.264, H.265, H.266, etc.), a video slice may be a raster scan partition of a still image. Similarly, we refer to a video layer as a video coding element as either a temporal video layer, meaning to increase the resolution of the number of frames per second of a video sequence and the temporal level of detail; or as a spatial video layer, meaning to increase the number of video encoding pixels and the spatial resolution of a separate video frame of a video sequence. The abstract concepts of video frames, video slices, and / or video layers are applicable 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 of video encoded data into RTP / SRTP payload is specified by Internet standards for each individual video codec, such as H.264 specified by RFC 6184, H.265 specified by RFC 7798, AV1 specified by RTP Payload Format for AV1 (aomediacodec.github.io).

[0123] Note that for XR applications, the media codec used and its configuration / configuration update depends on the application implementation, and the configuration / configuration update is usually negotiated between the sender and the receiver at session establishment / session update (e.g., RTP / SRTP). To this end, Session Description Protocol (SDP) signaling is used as a separate signaling process or as part of Session Initiation Protocol (SIP).

[0124] In various interactive XR applications involving multi-point communication (e.g., conferencing, shared classrooms, etc.), application layer forward error correction (FEC) is used as a method to combat congestion and packet loss. This is also possible in point-to-point communication, where application layer FEC can exploit link path diversity at the network routing level or at the physical layer. For example, in 5GS, link path diversity can be provided by dual connectivity (DC), carrier aggregation (CA), and multi-TRP transmission. This applies, for example, to 1D / 2D parity check codes (e.g., as defined in IETF RFC 8627), Raptor codes (e.g., as defined in IETF RFC 5032), RaptorQ codes (e.g., as defined in IETF RFC 6330), and LDPC ladder codes (e.g., as defined in IETF RFC6816).

[0125] The IETF has defined a Generic Forward Error Correction Framework (FECFRAME) as IETF RFC 6363, which allows various FEC schemes to be applied to application-level FEC. FECFRAME specifies the source packet format and repair packet format for AL-FEC on both the transport layer (e.g., UDP) and the RTP layer (e.g., WebRTC) and the FEC scheme configuration process.

[0126] The forward error correction framework FECFRAME therefore operates on application data units (ADUs), for example on RTP packets in case RTP is used for encapsulation of media information units.

[0127] Fig. 9 Figure 1 is a diagram of the AL-FEC XR application flow, including encoding, packetization and transmission. This shows the role of FECFRAME and the application of various FEC coding schemes. Fig. 9 A sender 900 is shown including an application 910, a FECFRAME 920, an FEC scheme 930, and a transport layer 940. The sender 900 may include a remote unit 102, a user equipment device 200, a UE 535, a UE 1135, a UE 1310, a base station unit 104, a network node 300, or a UPF 540, a UPF 1140, a UPF 1340 as described herein.

[0128] In some embodiments, a popular AL-FEC encoding scheme is Raptor encoding (IETF RFC 5032) in view of its efficient encoding / decoding, or alternatively, in other embodiments, its optimized version RaptorQ encoding (IETF RFC6330). Applied in the context of FECFRAME, Raptor / RaptorQ encodes RTP packets according to IETF RFC 6881 and IETF RFC6882. An example of some general steps of the application flow is described below.

[0129] At 971, the application 910 in the sender 900 determines a set of source packets (eg, RTP source packets) representing the ADU as a source block that is to be jointly protected based on the AL-FEC encoding configuration.

[0130] The AL-FEC encoding configuration may include FECFRAME configuration information containing: an FEC scheme identifier; a maximum source block length (MSBL) or, alternatively, K_max for Raptor / RaptorQ; a coding symbol size (i.e., the T parameter for the Raptor / RaptorQ encoding scheme); and a repair window duration (i.e., the maximum time spanning the transmission of a source packet and a corresponding repair packet, in milliseconds and / or microseconds, where the transmission point is considered to be a downstream interface that ingests the encoded PDU after encoding).

[0131] At 972, the sender arranges source packets (eg, RTP source packets) into sets of source symbols of the same size (which may represent smaller partitions in the source symbols of the configured size of the source packet data).

[0132] At 973 and 974, the sender applies the FEC scheme 930 (eg, Raptor / RaptorQ / 2D parity check code) according to the AL-FEC configuration (eg, FECFRAME configuration information) to generate the required number of repair symbols.

[0133] At 975 , the sender performs packetization of the repair symbols into repair packets (eg, RTP repair packets in accordance with IETF RFC 6882) and sends 976 the repair packets and source packets to the receiver via transport layer 940 .

[0134] According to FECFRAME requirements (ie, IETF RFC 6363), the sender should send source packets and repair packets in different source and repair streams, eg, RTP streams, to allow legacy (non-FEC) applications to process the source packets similar to any systematic code.

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

[0136] However, if there are lost source packets, repair packets may be processed and used to recover the lost information within a delay corresponding to at least the repair window time configured by applying the FEC configuration.

[0137] The Raptor / RaptorQ FEC scheme recovery properties determine that K coded source packets can be recovered from any K+h coded sources, or a packet can be repaired with a probability of 1-1 / 256^(h+1), where the coded symbol corresponds to the coded packet. This implies that recovery of K coded source symbols from a set of N coded source packets and repair packets (where only K+1 coded packets are received) is guaranteed to have a probability substantially exceeding 99.99%, i.e., very high. In other embodiments, where the coded packet corresponds to more than one coded symbol, the high recovery probability is also maintained after packetization, thus allowing the Raptor / RaptorQ codes to achieve strong error correction performance.

[0138] In an embodiment of FECFRAME for general streams, the ADU source PDU (e.g., source RTP PDU) is required to contain an additional footer indicating a payload ID. This is used on the receiver side to determine whether the encoded PDU is lost, and to help select and use the appropriate recovery slot for decoding the lost packet based on the encoded available PDU (i.e., source PDU or repair PDU). In many embodiments using RTP / SRTP, this information is easily available as part of the RTP / SRTP sequence number, which acts as a payload ID replacement. In such an embodiment, similar to any system encoding process, the source RTP / SRTP packet derived from the FECFRAME encoding is sent unchanged. For example, this provides backward compatibility for receivers that do not support AL-FEC. In one embodiment, the FEC encoding scheme for encoding the source PDU and the repair PDU into RTP / SRTP packets therefore uses the sequence number of the original RTP / SRTP source packet as a payload ID replacement (e.g., for Raptor / RaptorQ codes, in the single sequence stream encoding mode according to IETF RFC 6681). Therefore, this shows that the encoded repair RTP / SRTP packets are dependent on blocks of jointly encoded RTP / SRTP source packets, facilitating efficient decoding by a decoder endpoint.

[0139] Processing PDU sets for XR QoS flows implies solving the problem of mapping the application's traffic flows to PDU sets. This corresponds to determining PDU set boundaries (PSBs) (ie, the start PSB and / or end PSB of a PDU set).

[0140] This problem can be solved at the UPF for DL ​​services or at the UE for UL services. The result is then used in the DL as described in the previous article to set, configure and map the PDU set to the appropriate QoS rules with the help of the QoS flow. On the other hand, in the UL, the UE will use the determined PDU set to map the PDU set to a specific DRB, which is then mapped to the QoS flow by the RAN through N3 with the help of SDAP processing. The UPF should then route the UL to the application server according to the QoS rules configured by the PCF and the QoS flow established by the SMF.

[0141] PSB determination considered in the prior art is mainly performed in one or both of the following two ways: deep packet inspection and RTP header information parsing. However, deep packet inspection is computationally heavy and has training and deployment requirements, which makes its application in UL direction for UE processing infeasible.

[0142] Solutions involving the use of the RTP packet format utilize a combination of one or more of the RTP timestamp, sequence number, payload type, and M-bit markers to determine video frame boundaries. In some solutions, this information is supplemented by additional information extracted from application-specific and / or profile-specific RTP header extensions (e.g., draft-ietf-avtext-framemarking-13), or from parsing the RTP payload header (e.g., the RTP payload header of the video coding NAL unit in the H.26x codec), as detailed in the 3GPP Technical Report TR 23.700-60v0.0.3 entitled "Study on XR (Extended Reality) and Media Services".

[0143] However, these solutions do not consider AL-FEC traffic, but only non-encoded XR application traffic. Nevertheless, according to the 3GPP SA4 Working Group (specifically the 3GPP Liaison Statement from 3GPP SA4WG to 3GPP SA2 WG, S4-220505 from SA4 Meeting #118e, April 6-12, 2022), a PDU set may contain source PDUs and repair PDUs of AL-FEC encoded source blocks, as is typical in multicast / broadcast defined in 3GPP TS26.246v17.0.0 entitled “Transparent end-to-end packet switched streaming service (PSS); 3GPP SMIL language profile”, or in conversational applications described in 3GPP TS26.114v17.5.0 entitled “IP Multimedia Subsystem (IMS); Multimedia Telephony; Media Processing and Interaction”. This further facilitates determining a set of PDUs for XR traffic encoded by the AL-FEC configuration and the associated encoded PDUs.

[0144] RAN PDU discard has been discussed in the solution space for XR service processing in 5G for cases where a PDU belonging to a scheduled XR ADU whose delay budget has expired is discarded, or a PDU that depends on another ADU whose delay budget has expired (e.g., a P frame that depends on an I frame reference) (e.g., see 3GPP discussion document R1-2111787 entitled “Discussion on Enhancements for XR” submitted by Ericsson at RAN1#107e in November 2021).

[0145] Although these solutions may work for PDU aggregation, the solution is not AL-FEC aware and only reacts to expiration of the delay budget or higher layer indications that the information is out of date.

[0146] Provided herein is a proactive solution that utilizes AL-FEC awareness to discard PDUs in a coded PDU set, where the PDUs either carry unnecessary redundant information to the receiver (e.g., the receiver has received enough packets to decode the expected ADU information) or carry outdated information to the receiver (e.g., the receiver can no longer recover the expected ADU information because too many PDU erasures have occurred).

[0147] Additionally, note that 3GPP TR 23.700-60 (v0.0.3), entitled "Study on XR (Extended Reality) and Media Services", describes the use of RTP packet formats to utilize a combination of one or more of RTP timestamps, sequence numbers, and M-bit markers to determine video frame boundaries. In some solutions, this information is supplemented by additional information extracted from application-specific and / or profile-specific RTP header extensions (e.g., draft-ietf-avtext-framemarking-13), or from parsing RTP payload headers (e.g., RTP payload headers of video coded NAL units in H.26x codecs). This last collected information is then used to extract some classification / estimate of the importance of the detected PDU set.

[0148] The solution presented in this article uses the same strategy, i.e., using the RTP header to determine some information of the encoded PDU, but compared with the prior art, this method uses the AL-FEC configuration and the knowledge of the encoded application service to determine the PDU set, which also contains 2 subsets representing the encoded source PDU and the encoded repair PDU as a common PDU set. Therefore, the commonly dependent source PDU and repair PDU are grouped together as a PDU set.

[0149] The solution presented herein tends to provide processing and discarding of AL-FEC encoded PDU sets at the RAN using AL-FEC RAN awareness.

[0150] Three example strategies may be applied to determine when a PDU in an AL-FEC coded PDU set will be discarded. RAN discarding is motivated by optimization of radio resource usage and allocation, and increasing system capacity by stopping transmission processing of PDUs in a coded PDU set. This tends to provide more efficient transmission of PDU sets in a wireless communication network.

[0151] The PDUs discarded are:

[0152] Unnecessarily redundant - i.e. the receiver has received enough PDUs belonging to the coded PDU set to decode the desired ADU information; or

[0153] • Obsolete - that is, the receiver can no longer recover the expected ADU information because too many PDU erasures have occurred.

[0154] The solution is enabled by receiving, determining and / or identifying an application layer forward error correction (AL-FEC) encoding configuration for encoding the encoded ADU and processing the transmission of the PDU set accordingly. In certain embodiments, this can be facilitated by mapping the AL-FEC encoded ADU to the PDU set and signaling of the AL-FEC encoding configuration information and the PDU set metadata. Therefore, the determined RAN PDU discard policy applicable to the AL-FEC encoded PDU set is determined based on a threshold of the minimum necessary PDU for recovering the encoded ADU information and is based on the structure of the PDU set including a first source PDU subset and a second repair PDU subset, respectively.

[0155] AL-FEC is used to encode the XR application ADU, resulting in an encoded source PDU and a repair PDU. In one embodiment, this can be obtained as a result of FECFRAME (i.e., IETF RFC 6363) processing, given an AL-FEC configuration with at least:

[0156] The configured source block size,

[0157] AL-FEC coding schemes (e.g., Raptor / RaptorQ, 1D / 2D flexible parity check, ladder LDPC coding, etc.),

[0158] The coding rate and / or redundancy level, and

[0159] ·Encoded symbol size.

[0160] The source block determines the maximum ADU data size that can be encoded at one time. In some embodiments, for ADUs smaller than the configured source block, padding bits are used to supplement the ADU data until the size of the source block. In other embodiments, for ADUs larger than the source block, the ADU is split into multiple partitions with a size less than or equal to the AL-FEC configured source block.

[0161] In some embodiments, the encoding symbol size is configured to match the maximum transmission unit (MTU) corresponding to the PDU, so that one encoding symbol is contained in one PDU as a source PDU or a repair PDU. In such embodiments, padding is applied to source PDUs whose size is smaller than the encoding symbol size in both encoding and decoding to match the encoding symbol size. Padding bits are not sent because, given the AL-FEC configuration, both the AL-FEC encoder and the AL-FEC decoder know the value and / or number of padding bits.

[0162] In other embodiments, the encoding symbol size is configured to be smaller than the MTU of the PDU. In such embodiments, one or more encoding symbols comprise a PDU, either as a source PDU or a repair PDU. In such embodiments, padding is applied to source PDUs whose size is smaller than a minimum integer number of encoding symbols whose size is greater than or equal to the source PDU. Padding is applied to the source PDU in order to match the integer number of encoding symbols in both encoding and decoding. Padding bits are not sent because, given the AL-FEC configuration, both the AL-FEC encoder and the AL-FEC decoder know the value and / or number of padding bits.

[0163] AL-FEC encoding and packetization generates multiple encoded source PDUs and multiple repair PDUs for each encoded ADU. In some embodiments, the number of encoded source PDUs is determined by the number of source PDUs representing the ADU input (e.g., the number of RTP packets in the source block corresponding to the ADU), and the number of repair PDUs is determined by the AL-FEC encoding configuration, respectively by the AL-FEC coding rate and / or the redundancy level. In the example, K number of source PDUs are encoded as K number of encoded source PDUs that are the same as the source PDUs, and NK>0 number of encoded repair PDUs corresponding to the coding rate K / N<1 or equivalently corresponding to the redundancy level (NK) / K%.

[0164] Fig.10 A diagram of the encoding process 1000 of a source stream 1010 corresponding to an encoded source PDU 1015 and a repair stream 1030 corresponding to an encoded repair PDU 1035 is shown. The incoming RTP PDUs of the application are encoded and packetized by a system encoding. In such an embodiment, the source RTP PDUs remain unchanged after encoding to form the system codewords of the encoded source PDUs. In the same embodiment, a block code including an FEC scheme encoder 1020 is used to encode the repair symbols up to the size of the encoding symbol configuration and packetize them in the repair PDUs 1035 on the repair stream 1030. Fig.10 Also illustrated is an encoding delay 1092 between an input encoded source PDU 1015 and a corresponding encoded repair PDU 1035. The repair window 1092 represents the time after the encoded source PDU 1015 within which the corresponding encoded repair PDU 1035 may be used.

[0165] Source stream 1010 and repair stream 1030 can be sent on different RTP sessions (i.e., different source IP, source port addresses). In such an embodiment, according to IETF RFC 5956 and IETF RFC 6364, the co-dependent source stream and repair stream are associated at the media session level by FEC grouping. The co-dependent source stream and repair stream are one or more streams, so that the repair stream contains redundant combination information of the source stream, which depends on the latter. In a similar manner, the source stream depends on the repair stream in the event of an error, wherein the information of the redundant repair stream portion can be used to restore the source stream information.

[0166] The FEC grouping is negotiated by the XR application during the SDP offer / answer process. In the example listing, the grouping of source and repair streams within the SDP offer is determined as,

[0167] …

[0168] a=group:FEC-FR S1 R1

[0169] m = video 42420RTP / AVP 100

[0170] c=IN IP4 233.252.0.1 / 127

[0171] a=rtpmap:100H264 / 90000

[0172] a=fec-source-flow:id=0

[0173] a=mid:S1

[0174] m = application 42420UDP / FEC

[0175] c=IN IP4 233.252.0.2 / 127

[0176] a=fec-repair-flow:encoding-id=6; fssi=Kmax:50,T:1280

[0177] a=repair-window:15ms

[0178] a=mid:R1

[0179] …

[0180] In the above example, a group (S1, R1) is created. The S1 stream represents the fec source stream identified by ID=0, and the R1 stream represents the fec repair stream described by its encoding scheme (i.e., encoding id=6 as described in IETF RFC 6681, which corresponds to RaptorQ for single sequence source streams) and parameters T=1280 bytes of encoding symbols, while the maximum length of the source block contained is K_max=50 symbols. Therefore, the two co-dependent streams are logically grouped at the media session level, despite being delivered over two different RTP sessions.

[0181] In other embodiments, the same source stream and repair stream as described above are sent by an RTP multiplexer on a common RTP session, where the different SSRCs of the two streams are multiplexed together as part of the ssrc group defined in IETF RFC 5956 at the SDP protocol level. In such an example, the source stream and repair stream described above would be described in the SDP offer / answer process defined in IETF RFC 6682 as

[0182] …

[0183] m=video 42420RTP / AVP 100 110

[0184] c=IN IP4 233.252.0.1 / 127

[0185] a=rtpmap:100H264 / 90000

[0186] a=rtpmap:110raptorfec / 90000

[0187] a=fmtp:110raptor-scheme-id=6; Kmax=50; T=1280; repair-window=15000

[0188] a=ssrc:1000000

[0189] a=ssrc:1000110

[0190] a=ssrc-group:FEC-FR 1000000 1000110

[0191] a=mid:FECGroup1

[0192] …

[0193] In the above example, the source stream (SSRC=1000000 and payload type=100) and the repair stream (SSRC=1000110 and payload type=110) are multiplexed on the same RTP session, but the encoding parameters are the same as in the previous example.

[0194] In some embodiments, therefore, the AL-FEC encoded and co-dependent media streams are determined by the 5GS by monitoring the SDP offer / answer process associated with the XR application, where the proposing endpoint initiates an SDP offer to the answering endpoint. The answering endpoint replies to the SDP offer with an SDP answer agreeing to a specific set of media streams, attributes and parameters (the AL-FEC configuration is also included). In one embodiment, the co-dependent grouping of the source stream and the repair stream is determined based on the "group" SDP attribute, while in another implementation, the co-dependent grouping is determined based on the "ssrc-group" SDP attribute, where RTP SSRC multiplexing is applied.

[0195] In other embodiments, the AL-FEC encoding configuration may be signaled by the XR application's AF to the NEF Packet Flow Description Function (PFDF) API as part of a set of one or more Packet Flow Description (PFD) objects identifying the various AL-FEC configurations based on at least one of the following:

[0196] A triplet, including the protocol, server-side IP address, and server-side port address;

[0197] A set of rules for the important parts of the URL to be matched;

[0198] The rule set matching criteria for the domain name; and

[0199] • Information encapsulation protocol configuration (e.g., AL-FEC configuration, such as coding rate, redundancy level, coding scheme, source block size, coding symbol size, repair window, etc.).

[0200] In such an embodiment, the AF of the XR application will implicitly signal the AL-FEC configuration description that will be applicable to the encoded PDU service at the PDU session level through the control plane interface (e.g., NEF PFDF API). Therefore, the signaled information is managed by the SMF according to the PFD management process. The SMF notifies the UPF of the PFD rules, and the SMF also notifies the UPF of the PCC rules and QoS rules for the XR application service determined by the PCF and the coding configuration associated with the AL-FEC. The UPF can then apply appropriate packet inspection and filtering to determine a PDU set that contains the encoded co-dependent source PDUs as a subset and contains the repair PDU as another subset.

[0201] Fig.11 The architecture and process for information exchange to support AL-FEC encoded PDU set determination for both DL and UL directions are illustrated. Fig.11 A system 1100 is shown that includes an extended reality media application function (XRM AF) 1110, which is part of an XR application 1145. The XR application 1145 includes an XR application service (AS) 1147. The system 1100 also includes a network exposure function (NEF) 1105, which includes a packet flow description function (PFDF) 1107. The system 1100 also includes a policy and control function (PCF) 1115, a session management function (SMF) 1120, an access and mobility function (AMF) 1125, a radio access network (RAN) 1130, a user equipment (UE) 1135, and a user plane function (UPF) 1140. The UE 1135 includes a client XR application 1137 and a PDU aggregation packet filter 1132. The UPF 1140 includes a PDU aggregation packet filter 1142. Interfaces between certain components are additionally illustrated. UE 1135 may include remote unit 102, or user equipment device 200, sender 900, or UE 535, UE 1310 as described herein. UPF 1140 may include base station unit 104, or network node 300, or UPF 540, UPF 1340 as described herein.

[0202] Similarly, in another embodiment for UL transmission, the SMF may inform the UE via the AMF of the PFD rules and QoS rules for XR application services. The UE may then apply appropriate packet inspection and filtering for UL transmission to determine a PDU set containing the encoded co-dependent source PDU as a subset and a repair PDU as another subset.

[0203] In some embodiments, the PDU set, the encoded source PDU subset, and the encoded repair PDU subset are determined by inspecting the RTP and / or SRTP fixed header information at the UPF for DL ​​transmission or at the UE for UL transmission. This contains at least the following RTP / SRTP header fields, which can be used to determine the boundaries of the encoded ADUs that span the source PDU subset and the repair PDU subset:

[0204] M-bit flag field,

[0205] Payload Type field,

[0206] SSRC field,

[0207] A sequence number field, and

[0208] Timestamp field.

[0209] The M-bit flag field may indicate the end boundary of the information of the ADU (ie, video frame) by a bit value of "1", which identifies the end of the source ADU and thus the end of the encoded source PDU subset.

[0210] Alternatively, the M-bit flag field may indicate, by a bit value of "1", the end of the repair PDU associated with the source block corresponding to the source ADU, and thus indicate the end of the encoded source PDU.

[0211] The Payload Type field may indicate the type of each payload carried by the RTP PDU as one of a source PDU media payload type (e.g., H264, HEVC, etc.) or a repair PDU type (e.g., corresponding to a configured AL-FEC encoded stream). In the examples of any of the SDP configurations presented previously, the source PDU has a payload type of "100" and the repair PDU has a payload type of "110".

[0212] The SSRC identifier may also indicate the primary synchronization source for each RTP PDU, where source PDUs and repair PDUs may be multiplexed within the same stream and thus supplement the payload type field when indicating the encoded source PDUs and repair PDUs. In an example, for the "ssrc group" SDP grouping configuration for co-dependent source and repair streams, the SSRC for the source PDU is "1000000" and the SSRC for the repair PDU is "1000110".

[0213] The sequence number field may tag the PDUs in sequence and may provide a means for ordering the PDUs in a PDU set based on an original sampling of the PDUs, thus enabling a logical separation of a first subset of PDUs as source PDUs of the PDU set and a second subset of PDUs as repair PDUs of the PDU set. However, in an embodiment, given a particular AL-FEC coding scheme configuration, the source PDUs and repair PDUs may be interleaved. In another embodiment, the source PDUs and repair PDUs of a PDU set are not interleaved with the first subset of source PDUs transmitted followed by a second subset of repair PDUs that are co-dependent.

[0214] The timestamp field can help with synchronization of the PDUs and indicates the sampling timestamp of each PDU within the PDU set. In some embodiments, the timestamps of the source PDU and the repair PDU are the same, while in other embodiments, the timestamp of the source PDU is set to a timestamp "t0" corresponding to the sampling of the source ADU (e.g., a video frame captured by a capture input device and stored in memory), and the timestamp of the repair PDU is set to a timestamp "t1" corresponding to the timestamp "t0" plus the encoding delay caused by the AL-FEC encoding process. The encoding delay is less than or equal to the repair window AL-FEC configuration. In an embodiment, the encoding delay and the repair window are determined by the XR application server based at least on the maximum end-to-end content delivery delay requirement and / or the end-to-end application delay requirement.

[0215] Fig.12 The determination 1200 of an AL-FEC encoded PDU set 1250 consisting of a first subset of source PDUs 1215 and a second subset of repair PDUs 1235 is illustrated. The PDU set is determined using an M-bit flag, a payload type, and / or SSRC based on the SDP session information configured for AL-FEC. In addition, the first subset of the PDU set 1250 is determined to include the source PDUs 1215, and the second subset of the PDU set 1250 is determined to include the repair PDUs 1235, and the identification of the two subsets is based on the payload type and / or SSRC RTP header fields. It should be noted that the same process can be performed for SRTP services with the same results.

[0216] In order to benefit from the determined AL-FEC encoded PDU set and the encoded source PDU subset and repair PDU subset in downstream transmission and low-layer processing, the obtained PDU set information can be signaled to the RAN within the 5GS, etc. The backhaul transmission within the 5GS is the tunneling of the PDU session traffic flow through the internal UDP / IP stack. The latter is performed by the GTP-U tunneling protocol, which includes an external IP network stack and relays the PDU session to one or more RAN endpoints according to the internal IP routing rules established for the PDU session on the control plane of the 5GS.

[0217] The GTP-U tunnel mechanism carries user data traffic via UDP transport on the N3 and N9 interfaces. The GTP-U tunnel between two corresponding GTP-U nodes separates traffic into different communication flows. The local tunnel endpoint identifier (TEID), IP address, and UDP port uniquely identify the tunnel endpoint in each node, where the TEID assigned by the receiving entity is used for communication. In the example of 5GS CN, a GTP-U tunnel is established by providing a TEID and IP address between the RAN and the SMF. This is signaling between the SMF and AMF over HTTP / 2 and between the AMF and the RAN over the Next Generation Application Protocol (NGAP).

[0218] Fig.13 The 5GS GTP-U data plane protocol stack of a PDU session 1300 is illustrated. The system includes a UE 1310, a 5GAN 1320, a UPF 1330, and a UPF 1340. The UE 1310 may include a remote unit 102, a user equipment device 200, a sender 900, or a UE 535, UE 1135 as described herein. The UPF 1340 may include a base station unit 104, a network node 300, or a UPF 540, UPF 1140 as described herein. The GTP-U header is a 4-byte aligned structure, which in some embodiments is formed of at least 8 bytes, followed by at least 4 additional bytes, depending on the contents of the mandatory first 8 bytes. In one embodiment, the GTP-U header may have one or more 4-byte aligned extension headers, which are chained together as a list by the next extension header type octet of the prefix.

[0219] Fig.14The structure of the GTP-U header 1400 is illustrated. The GTP-U header includes: a 3-bit version field (Ver) 1402; a 1-bit protocol type field (P) 1404, which indicates a "1" value for GTP-U; a reserved bit field (R) 1406 with a value of "0"; an extended header flag (E) 1408-bit field indicating the presence of an optional extended header field; a sequence number flag (S) 1410-bit field indicating the presence of an optional sequence number field; an N-PDU number flag (N) 1412-bit field indicating the presence of an optional N-PDU number field; a message type octet field 1414 indicating the type of GTP-U message (e.g., "255" for G-PDU, indicating a transport PDU); an octet field 1416 indicating the length of the payload in bytes; and a 32-bit TEID 1418; an optional (incrementing) sequence number octet field 1420, which exists if any of E, S, or N is switched, but is processed only if S is switched; an optional N-PDU number octet field 1422, which exists if any of E, S, or N is switched, but is processed only if N is switched; and an optional next extended header type octet field 1424, which exists if any of E, S, or N is switched, but is processed only if E is switched.

[0220] In some embodiments, information of the AL-FEC encoded PDU set is communicated to or from the RAN by means of a GTP-U extension header. In one embodiment, such an extension header includes information of at least one of the following:

[0221] an indication of the boundaries of a PDU set (e.g., a start and / or stop indication bit field, and / or a PDU set sequence number or identifier field),

[0222] An indication of the boundaries of a source PDU subset of a PDU set (e.g., a start and / or stop indication bit field corresponding to the source PDU subset)

[0223] An indication of the boundaries of a repair PDU subset of a PDU set (e.g., a start and / or stop indication bit field corresponding to a repair PDU subset)

[0224] An indication of the size of the PDU set size (e.g. as the number of all coded PDUs forming the PDU set)

[0225] An indication of the size of the source PDU subset of the PDU set (e.g. as the number of source PDUs forming the source PDU subset)

[0226] An indication of the size of the repair PDU subset of the PDU set (e.g. as the number of repair PDUs forming the repair PDU subset)

[0227] An indication of the code rate for the AL-FEC configuration (e.g., as a bit field containing a tabulate index indicating a code rate with a given granularity between a minimum code rate (e.g., 0.25) and 1 (i.e., no coding), where the chosen granularity occupies -log2(1 / granularity) bits, or alternatively, the number of source PDUs within a PDU set and the number of total coded PDUs)

[0228] • An indication of the minimum number of PDUs (ie, source PDUs or repair PDUs) in the set of coded PDUs that need to be successfully sent to a receiver to enable the receiver to apply the AL-FEC coding configuration when decoding and successfully recovering the ADU encoded information.

[0229] In some embodiments, an indication of the minimum number of necessary PDUs for ADU recovery is signaled as a percentage of the total number of PDUs in the coded PDU set that need to be sent. In one example, the minimum number of necessary PDUs for ADU recovery of the coded PDU set (i.e., m) is signaled as a quantized percentage value q' that solves the problem:

[0230]

[0231] Where N represents the number of total PDUs within the coded PDU set, and Q represents a set of quantization percentage levels, for example, Q = {10, 20, 30, 40, 45, 50, 55, 60, 65, 70, 75, 80, 85, 90, 95, 100}. In this example, any percentage level of Q can be quantized to 4 bits. Therefore, the original m value signaled by q' can be recovered by inverse mapping:

[0232]

[0233] Fig.15An example of a minimum (i.e., the minimum number of bytes possible) extended header 1500 for an AL-FEC encoded PDU set is presented. The example extended header 1500 includes: an octet (Extended Header Length, 1530) indicating the length of the extended header in units of 4 bytes; a nibble containing a PDU set sequence number (PDU set SN, 1532) as a PDU set identifier modulo 2^4, incremented for each PDU set sequence number; another nibble signaling the minimum number of necessary PDUs for PDU set information recovery (Minimum N-PDU, 1534) given the AL-FEC encoding configuration and the example signaling described above , where q=10% is represented as "0000" and q=100% is represented as "1111", with values ​​in between represented as monotonically increasing; a 7-bit field PDU sequence number (PDUSN, 1536) for each PDU in the PDUs within the PDU set; a 1-bit field indicating the type (T, 1538) for each PDU in the PDUs, for example, a value of "0" for the source PDU and a value of "1" for the repair PDU; and a last byte (Next Extension Header, 1540) that signals that no other extension headers follow. In this case, given the PDU type tag and PDU SN within the PDU set, the coding rate of the AL-FEC of the PDU set is implicit, while an indication of the minimum number of necessary PDUs for recovering the encoded PDU set information is explicitly signaled. Fig.15 In the example of , a PDU set formed by 10 PDUs (of which 6 source PDUs and 4 repair PDUs) is represented by means of the GTP-U extension header of each PDU, as described above. Therefore, given the AL-FEC coding configuration of the RaptorQ code, with coding id=6 (i.e., RaptorQ corresponding to a single-sequence source RTP stream), coding symbols of T=1280 bytes, and a source block with a maximum length of K_max=50 symbols, the minimum number of PDUs necessary to recover the PDU set information with a certainty greater than 99.99% is m=7. This maps to q'=70, represented as "1001" as a half byte.

[0234] In some embodiments, AL-FEC encoding configuration information associated with a plurality of PDU sets is signaled via a control plane mechanism for downstream processing (e.g., by one or more RAN endpoints). In one embodiment, the AL-FEC encoding configuration information comprises, in part: a coding scheme; a coding rate; and / or a minimum percentage of PDUs in the coded PDU set (i.e., any source of repair PDUs) required to guarantee recovery of ADU information given a set of QoS rules.

[0235] The AL-FEC encoding configuration information is indicated by the SMF to the RAN via the AMF N2 interface. In another embodiment, the same information is signaled by the SMF to the UE via the AMF N1 interface for UL-related AL-FEC encoded PDU set services. In the example, the application indicates to the NEF and PCF via its AF: the corresponding set of PFD service descriptors and QoS requirements associated with the AL-FEC configuration used to encode the application ADU into a PDU set. The PCF generates PCC rules and configures the SMF with a corresponding set of QoS rules, which includes an indication of the minimum percentage of PDUs (i.e., source PDUs or repair PDUs) in the encoded PDU set corresponding to the AL-FEC configuration that need to be transmitted given the QoS requirements of the application.

[0236] Consider an example of an application with a QoS requirement of ADU error rate / PSER of 1e-2, which uses the AL-FEC RaptorQ system coding scheme (e.g., coding scheme id=6 according to IETF RFC6681) to encode the ADU into a set of PDUs, and any K source PDUs for a source block have a configured redundancy level This requires at least K+1 PDUs to recover the ADU information, of which at least 99.99% correspond to the QoS requirements, and therefore the defined QoS rules indicate at least the following percentages:

[0237]

[0238] A PDU among any N PDUs in the encoded PDU set satisfies the PSER QoS requirement of the application.

[0239] Fig.16RAN discard of PDUs in a PDU set coded with AL-FEC is illustrated. Three examples are illustrated: (A), (B) and (C). In each example, a PDU set 1605 includes a plurality of source PDUs 1615 and a plurality of repair PDUs 1635. Acknowledgements (ACKs) or negative acknowledgements (NACKs) are sent regarding some of the PDUs. The determination of the PDU set coded with AL-FEC, the associated AL-FEC-aware signaling, and the PDU set metadata enable optimization of downstream processing. In an embodiment, the latter information is processed by a RAN node for the purpose of discarding one or more PDUs from the PDU set. The RAN node applies the discard technique to optimize radio resource allocation by preventing over-provisioning of resources for PDUs that are redundant (i.e., the information available at the receiver is sufficient to recover the ADU information given the AL-FEC encoding, (A)) or obsolete (i.e., the information that can still be sent is insufficient to recover the ADU information given the AL-FEC encoding, (C)).

[0240] In one embodiment, the RAN node is indicated as having an AL-FEC configuration by means of control plane signaling or by means of data plane signaling. In one example, the control plane signaling includes an AMF N2 interface for relaying to the RAN the PFD rules determined by the SMF and the QoS rules associated with the AL-FEC encoding configuration applied to the associated services of the set of application PDUs. In this case, the AF indicates to the NEF / PFDF API the PFD set associated with the specific AL-FEC configuration, which is subsequently managed by the PFD management process via the SMF. In addition, the AF indicates to the PCF the QoS requirements associated with the AL-FEC encoded services, and the PCF configures subsequent QoS rules for the SMF. This control plane signaling path is in Fig.11 In the figure, the PFD rules are indicated as dashed lines and the QoS rules are indicated as solid lines.

[0241] In another example, a data plane is utilized where metadata included with the PDU set is included within a GTP-U extension header that carries information about the AL-FEC. Thus, this implicit data plane signaling is used by the RAN to obtain the AL-FEC encoding configuration information and simultaneously determine the PDU set boundaries. As a result, the RAN becomes aware of both the AL-FEC and the AL-FEC encoded PDU set, and in some embodiments, the RAN is signaled using at least one of a control plane signaling procedure or a data plane signaling procedure.

[0242] Since AL-FEC coding acts as a packet erasure code, many applicable coding schemes (e.g., Raptor / RaptorQ codes, MDS codes, Reed-Solomon codes, 1D / 2D flexible parity-check codes, etc.) provide analytic bounds on information recovery given a certain number of coded symbols and / or packets are lost from a codeword or equivalently a coded source block.

[0243] For example, it is known that Reed-Solomon codes can correct for erasures of up to t = nk coded symbols for a code of length n containing k information symbols, where the positions of the t erasures are known. This bound is achievable in practice, where sequence numbers are often used to locate expected erasures of coded symbols. Another example is GF(2 8 ) (see, for example, IETF RFC 6330), where the code is guaranteed to recover the original information of a source block of K coded symbols based on any K+h coded symbols (i.e., source symbols or repair symbols) with the following approximate probability

[0244]

[0245] Therefore, in a total of N RaptorQ GFs (2 8 ) coded symbols, K+1 symbols are sufficient on average to recover the original source block information with a probability better than 99.99%.

[0246] In some embodiments, AL-FEC configuration parameters such as the AL-FEC coding scheme (e.g., Raptor / RaptorQ, Reed-Solomon), the AL-FEC coding rate (e.g., total number of coded symbols / number of PDUs, number of source symbols / number of PDUs, and / or number of repair symbols / number of PDUs for source block size) are used together with the QoS flow requirements of the PDU set flow (e.g., packet error rate (PER) and / or PDU set error rate (PSER)) to determine the minimum number of PDUs in the coded PDU set that will necessarily be correctly transmitted. Given AL-FEC, a minimum number of PDUs is necessary for the coded PDU set ADU information to be recovered at the receiver application side with a certain high probability of recovery. In some examples, this probability of recovery is set to match or exceed the inverse value of the PER or PSER requirement associated with the QoS flow of the PDU set. From an information theoretic perspective, successful recovery at the receiver indicates that the PDU set transmission was successful, although some PDUs belonging to the PDU set were not received.

[0247] Furthermore, in many embodiments, the AL-FEC used is a systematic code so that the coded output generates the same source coded PDU as the source PDU input of the code. This ensures exact recovery, e.g., the source PDUs are all received correctly, but no repair PDU is not received correctly.

[0248] Thus, a RAN partially indicated with an AL-FEC configuration, a set of coded PDUs and its source PDU subsets and repair PDU subsets, and a threshold value of the minimum necessary PDUs to be successfully received for ADU information recovery is able to determine a strategy to discard PDUs in the set of coded PDUs for optimizing radio resource allocation and further system capacity increase. In some embodiments, consider a RAN that receives a set of AL-FEC coded PDUs (e.g., UDP / IP encapsulated RTP packets tunneled via GTP-U) with RaptorQ code in single sequence stream coding mode according to RFC 6681, where the coding symbol size is T=1420 bytes and the maximum source block length K max =50.

[0249] In one example, the RAN is further signaled that the QoS flow associated with the PDU set requires a PER of 1e-2 and / or a PSER of 1e-2 with a PDB of 10 ms. In such a case, the RAN is signaled by a higher layer, or determines based on these parameters, that for a PDU set consisting of 10 PDUs, 6 of which correspond to source PDUs and 4 correspond to repair PDUs (i.e., a coding rate of 0.6, or alternatively, a redundancy level of 66.67%), any 7 encoded PDUs that are successfully transmitted meet the PER / PSER requirements. In this case, 7 is the threshold of the minimum necessary PDUs (i.e., any PDU, source or repair) that need to be transmitted to meet the QoS requirements of the associated flow. On the other hand, given the system coding scheme used, the RAN is also able to determine that if 6 source PDUs are successfully transmitted, the repair PDU is not needed at the receiver and can be discarded. As used in this article, 1e-2 means 10 -2 .

[0250] Therefore, the following embodiments outline three example strategies that describe the discarding behavior of the RAN given a set of AL-FEC encoded PDUs. For the following, consider the context set by the previous example determination 7 as the discarding behavior for RaptorQ (K max=50, T=1420) system code, and a threshold value of a minimum necessary PDU for a coded PDU set of 10 PDUs, the coded PDU set consisting of 6 source PDUs of a first subset and 4 repair PDUs of a second subset.

[0251] In one embodiment, if all source PDUs 1615 of the coded PDU set have been successfully sent to the UE, the RAN decides to discard the repair PDU of the AL-FEC coded PDU set 1605. To this end, the UE indicates the successful transmission of the source PDU 1615 by means of a feedback acknowledgement, either by HARQ at L1 or by ARQ at L2 (e.g., by RLC status report). For the example considered, this is Fig.16 Since 6 source PDUs have been ACKed 1625 by the time 4 repair PDUs 1635 are ingested and / or scheduled by the RAN, for example, given the repair window of the AL-FEC encoding, 4 repair PDUs may be discarded without any loss of information at the ADU level for the application.

[0252] In some embodiments, the RAN threshold of the minimum necessary PDUs (either as source PDU 1615 or repair PDU 1635) for recovering the complete ADU information is used to determine the number of PDUs to be discarded given that a subset of PDUs has been sent to the UE. In such embodiments, the RAN threshold of the minimum necessary PDUs is determined by signaling the threshold of the minimum necessary PDUs to the RAN by the upper layers in a bit field representation, or by RAN side determination given the AL-FEC coding configuration and PDU set metadata information of the QoS flow. To this end, the UE indicates the transmission status of the PDUs that have been sent by means of feedback ACK / NACK 1625, either by HARQ at L1 or by ARQ at L2 (e.g., by RLC status report).

[0253] In one embodiment, the RAN decides to discard the remaining subset of PDUs (source PDUs or repair PDUs) from the set of encoded PDUs if at least a threshold number of previous subsets of minimum necessary PDUs have been successfully transmitted. Fig.16In the example of (B), #0, #1, #2, #3, #4 source PDU 1615 are ACKed, while #5 is NACKed and its PDB expires. Therefore, the RAN schedules #6 and #7 PDUs (i.e., repair PDU 1635) which are subsequently ACKed, and when 7 PDUs are successfully sent to the UE, the RAN discards processing of the additional repair PDUs, which match the threshold of the minimum necessary PDUs to recover the ADU information with an average probability of more than 99.99% and thus meet the QoS requirement of 1e-2 PSER.

[0254] In a second embodiment, the RAN decides to discard any remaining subset of PDUs (source PDUs or repair PDUs) from the coded PDU set if a previous subset greater than the total number of PDUs in the PDU set minus a threshold of minimum necessary PDUs has been unsuccessfully transmitted (i.e. the PDUs have been NACKed and the PDU PDB expired). Fig.16 In the example of (C), source PDUs #0, #1, #2, #3, and #4 are NACKed, while source PDU #5 is ACKed. However, even if the remaining 4 repair PDUs 1635 are successfully transmitted given the threshold of the minimum necessary PDU determined to be 7 corresponding to the required QoS PSER and the applied AL-FEC coding scheme, the remaining 4 repair PDUs 1635 cannot successfully recover the ADU information. Therefore, in this example, the 4 repair PDUs are also discarded by the RAN.

[0255] In an embodiment, when the UE performs UL transmission of a set of AL-FEC coded PDUs for an application, the same discarding procedures and policies applied to the RAN are performed. In this embodiment, the UE performs packet filtering to determine the PDU set and obtains the necessary AL-FEC awareness, and the UE is indicated by the application a minimum threshold of necessary PDUs in the coded PDU set to be successfully transmitted for ADU information recovery, or determines such a minimum threshold of necessary PDUs given the UE's awareness of the AL-FEC coding configuration and PDU set.

[0256] In some embodiments, RAN and / or UE discarding of a PDU in a PDU set corresponds to stopping layer 2 / layer 1 processing of transmission operations for the discarded PDU.

[0257] Specifically, in some examples, this implies at least one of the following:

[0258] Stop buffering incoming PDUs of the PDU set;

[0259] Stop scheduling radio resources, such as time slots, frequency carriers and / or spatial layers, and / or stop configuring grants for one or more PDUs in a PDU set;

[0260] Stop packetizing one or more PDUs in the coded PDU set for radio transmission, e.g., PDCP processing, RLC processing, TB encapsulation, and logical channel multiplexing;

[0261] Stop processing the feedback process of automatic repeat request confirmation / hybrid automatic repeat request confirmation;

[0262] Stop processing physical layer forward error correction coding, layer mapping, modulation and physical channel over-the-air transmission processes;

[0263] Signaling a buffer status report (BSR) (e.g., by the UE in the UL) to indicate subsequent discarding and update the buffer status; and

[0264] • Entering a lower power saving mode (eg, at the UE) or selecting a more efficient discontinuous reception (DRX) configuration (eg, the UE selects a more efficient DRX configuration given a set of available DRX configurations signaled by the RAN).

[0265] In one embodiment, the RAN may also signal the discard of a PDU subset belonging to a PDU set to the UE via an indication marker that notifies the UE that the PDU subset in the PDU set is no longer expected to be received. Thus, the UE is notified and may therefore synchronize its PDU set reception operations to the gNB, perform AL-FEC decoding on the transmitted PDUs in the encoded PDU set, and perform any UE-specific optimizations. Such UE-specific optimizations may include: entering a lower power state, flushing receive buffer states, releasing HARQ processes, etc. Similarly, in another embodiment, the UE may indicate to the RAN to stop UL transmission for the PDU set. Upon receiving the indication, the RAN will perform the same operations for AL-FEC decoding of the uplink ADU information and for RAN radio transmit receive optimization.

[0266] Fig.17 A method 1700 in a user equipment device of a wireless communication network is illustrated. The method 1700 includes receiving 1710 a subset of protocol data units (PDUs) in a set of PDUs, the set of PDUs corresponding to an encoded application data unit (ADU) and an application level forward error correction (AL-FEC) coding configuration, wherein the encoding of the encoded ADU is based on the AL-FEC coding configuration. The method 1700 also includes sending 1720 a delivery confirmation in response to the received PDUs, and receiving 1730 an indication that no additional PDUs belonging to the set of PDUs will be sent. The method 1700 also includes processing 1740 decoding of the encoded ADUs based on the received AL-FEC coding configuration and the received subset of PDUs.

[0267] The delivery confirmation may include a hybrid automatic repeat request confirmation or an automatic repeat request confirmation. The nature of the delivery confirmation may include delivery confirmed, or delivery unconfirmed. The indication that no further PDUs belonging to the PDU set will be sent may include a stop indication. The indication that no further PDUs belonging to the PDU set will be sent may be based on the delivery confirmation sent and the stop criteria determined by the sending node that sends the PDU. After the stop indication is received, given the AL-FEC encoding configuration for encoding by the transmitter, the received PDU with confirmed delivery from the PDU set can be used to decode the encoded ADU information. In one embodiment, the successfully received information is sufficient to recover the ADU. In another embodiment, the successfully received information is insufficient to recover the ADU.

[0268] The user equipment is arranged to receive a transmission from the wireless communication network. The transmission may be sent by a base station. The transmission may be sent by a transmitter of the base station.

[0269] A user equipment device for communicating with a wireless communication network is also provided, the user equipment device comprising a receiver, a transmitter and a processor. The receiver is arranged to receive a subset of protocol data units (PDUs) in a set of PDUs, the PDU set corresponding to an encoded application data unit (ADU) and an application level forward error correction (AL-FEC) coding configuration, wherein the encoding of the encoded ADU is based on the AL-FEC coding configuration. The transmitter is arranged to send a delivery confirmation in response to the received PDU. The receiver is also arranged to receive an indication that no additional PDUs belonging to the PDU set will be sent. The processor is arranged to decode the encoded ADU based on the received AL-FEC coding configuration and the received PDU subset.

[0270] A method for triggering RAN level discard of PDUs in an AL-FEC encoded PDU set based on AL-FEC and PDU set awareness is disclosed herein. Three examples or overall strategies for discarding PDUs in an AL-FEC encoded PDU set are presented for the proposed method applicable to unnecessary PDUs. Unnecessary PDUs may be discarded from an AL-FEC encoded PDU set. For example, the receiver may have received enough packets to decode the expected ADU information, so any additional PDUs are redundant. Alternatively, the receiver may no longer be able to recover the expected ADU information encoded by the PDU set because too many PDU erasures (or transmission losses) have occurred.

[0271] It should be noted that the above methods and apparatus illustrate rather than limit the present invention, and that those skilled in the art will be able to design many alternative arrangements without departing from the scope of the appended claims. The word "comprising" does not exclude the presence of elements or steps other than those listed in the claims, "a" or "an" does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units described in the claims. Any reference signs in the claims should not be construed as limiting their scope.

[0272] Furthermore, although examples have been given in the context of specific communication standards and application types, these examples are not intended to limit the communication standards and application types to which the disclosed methods and apparatus may be applied. For example, although specific examples have been given in the context of 3GPP, the principles disclosed herein may also be applied to another wireless communication system, and in fact to any communication system that uses routing rules. In fact, the methods and apparatus described herein are not only applicable to XR applications, but may also be used for any AL-FEC encoding application that is served via RTP or the like and uses PDU sets.

[0273] The method may also be embodied in a set of instructions stored on a computer-readable medium, which, when loaded into a computer processor, a digital signal processor (DSP), etc., causes the processor to perform the above method.

[0274] The described methods and apparatus may be practiced in other specific forms. The described methods and apparatus are considered in all respects to be illustrative only and not restrictive. Therefore, the scope of the present invention is indicated by the appended claims rather than by the foregoing description. All changes within the meaning and equivalent range of the claims should be included within their scope.

[0275] The following abbreviations are relevant to the areas covered by this document: 3GPP, 3rd Generation Partnership Project; 5G, fifth generation; 5GS, 5G system; 5QI, 5G QoS identifier; ADU, application data unit; AF, application function; AMF, access and mobility function; AR, augmented reality; ARQ, automatic repeat request; DL, downlink; FEC, forward error correction; AL-FEC, application layer forward error correction; FECFRAME, forward error correction framework; HARQ, hybrid automatic repeat request; NAL, network abstraction layer; NEF, network exposure function; PCF, policy control function; PDU, protocol data unit; PFD, packet flow description; PFDF, packet flow description function; PPS, Picture Parameter Set; QoE, quality of experience; QoS, quality of service; RAN, radio access network; RTCP, real-time control protocol; RTP, real-time protocol; SDAP, service data adaptation protocol; SMF, session management function; SRTCP, secure real-time control protocol; SRTP, secure real-time protocol; UE, user equipment; UL, uplink; UPF, user plane function; VCL, video coding layer; VMAF, video multi-method assessment function; VPS, video parameter set; VR, virtual reality; XR, extended reality; XR AS, XR application server; and XRM, XR media.

Claims

1. A method in a node of a wireless communication network, the method comprising: receiving, from an application, a set of protocol data units (PDUs) corresponding to an encoded application data unit (ADU), wherein the encoding is based on an application layer forward error correction (AL-FEC) encoding configuration; receiving an application layer forward error correction (AL-FEC) coding configuration used to encode the encoded ADU; Processing transmission of the PDU set; as well as It is determined whether a stopping criterion is satisfied, the stopping criterion being derived for the PDU set from the AL-FEC coding configuration, and if the stopping criterion is satisfied for the PDU set, transmission of the PDU set is stopped.

2. The method of claim 1, wherein the received set of PDUs comprises both a plurality of source PDUs and a plurality of repair PDUs, wherein the repair PDUs are associated with the source PDUs based on encoding using the AL-FEC coding configuration.

3. The method of claim 2, wherein the stopping criterion comprises a threshold of a minimum necessary PDU in the set of encoded PDUs required to recover the encoded ADU.

4. The method of claim 3, wherein the determination of the threshold of minimum necessary PDU is based in part on the determined AL-FEC coding scheme configuration, the AL-FEC coding scheme configuration further comprising at least one of: Coding rate indication; an indication of the plurality of source PDUs and an indication of the plurality of repair PDUs; and an explicit indication of a minimum number of PDUs within said coded PDU set that need to be sent for said ADU to be recovered; The associated QoS flow requirement for PDU error rate; The PDU Aggregate Error Rate is associated with the QoS flow requirement.

5. The method according to claim 3 or 4, wherein the stopping criterion comprises successful transmission of a certain number of PDUs in the PDU set, the number being greater than or equal to the threshold of the minimum necessary PDUs required to resume the ADU.

6. A method according to any one of claims 3, 4 or 5, wherein the stopping criterion includes unsuccessful transmission of a second number of PDUs in the PDU set, wherein the second number of PDUs is greater than or equal to the total number of PDUs in the PDU set minus the threshold of the minimum necessary PDUs required to recover the ADU.

7. The method of claim 2, wherein the stopping criteria comprises successful transmission of the source PDU.

8. A method according to any one of the preceding claims, wherein determining whether the stopping criterion is met is determined from a delivery confirmation received by the node.

9. A node in a wireless communication network, the node comprising: a receiver arranged to receive, from an application, a set of protocol data units (PDUs) corresponding to encoded application data units (ADUs), wherein the encoding is based on an application layer forward error correction (AL-FEC) encoding configuration; a processor arranged to identify an application layer forward error correction (AL-FEC) coding configuration used to encode the encoded ADU; The processor is further arranged to process transmission of the set of PDUs; as well as The processor is further arranged to determine whether a stopping criterion is satisfied, the stopping criterion being derived for the set of PDUs from the AL-FEC coding configuration, and to stop transmission of the set of PDUs if the stopping criterion is satisfied for the set of PDUs.

10. The node of claim 9, wherein the received set of PDUs comprises both a plurality of source PDUs and a plurality of repair PDUs, wherein the repair PDUs are associated with the source PDUs based on encoding with the AL-FEC coding configuration.

11. The node according to claim 10, wherein the stopping criterion comprises a threshold of a minimum necessary PDU in the set of encoded PDUs required to resume the encoded ADU.

12. The node of claim 11, wherein the determination of the threshold of minimum necessary PDU is based in part on the determined AL-FEC coding scheme configuration, the AL-FEC coding scheme configuration further comprising at least one of: Coding rate indication; an indication of the plurality of source PDUs and an indication of the plurality of repair PDUs; an explicit indication of a minimum number of PDUs within said coded PDU set that need to be sent for said ADU to be recovered; The associated QoS flow requirement for PDU error rate; as well as The PDU Aggregate Error Rate is associated with the QoS flow requirement.

13. The node according to claim 11 or 12, wherein the stopping criterion comprises successful transmission of a certain number of PDUs in the PDU set, the number being greater than or equal to the threshold of minimum necessary PDUs required to resume the ADU.

14. A node according to any one of claims 11, 12 or 13, wherein the stopping criterion includes unsuccessful transmission of a second number of PDUs in the PDU set, wherein the second number of PDUs is greater than or equal to the total number of PDUs in the PDU set minus the threshold of the minimum necessary PDUs required to recover the ADU.

15. The node of claim 10, wherein the stopping criteria comprises successful transmission of the source PDU.

16. A node according to any one of claims 9 to 15, wherein determining whether the stopping criterion is met is determined from a delivery confirmation received by the node.

17. A method in a user equipment device of a wireless communication network, the method comprising: receiving a subset of protocol data units (PDUs) in a set of PDUs, the set of PDUs corresponding to a coded application data unit (ADU) and an application level forward error correction (AL-FEC) coding configuration, wherein the coding of the coded ADU is based on the AL-FEC coding configuration; sending a delivery confirmation in response to receiving the PDU; receiving an indication that no further PDUs belonging to the PDU set are to be sent; as well as Based on the received AL-FEC coding configuration and the received PDU subset, decoding of the encoded ADU is processed.

18. A user equipment device for communicating with a wireless communication network, the user equipment device comprising: a receiver arranged to receive a subset of protocol data units (PDUs) in a set of PDUs, the set of PDUs corresponding to a coded application data unit (ADU) and an application level forward error correction (AL-FEC) coding configuration, wherein the coding of the coded ADUs is based on the AL-FEC coding configuration; a transmitter arranged to send a delivery confirmation in response to receiving said PDU; The receiver is further arranged to receive an indication that no further PDUs belonging to the set of PDUs are to be sent; as well as A processor is arranged to decode the encoded ADU based on the received AL-FEC coding configuration and the received PDU subset.

Images