Signaling of application layer forward error correction (FEC) information for a set of protocol data units (PDUs)

Abstract

A device configured to send data can generate one or more source protocol data units (PDUs) in a PDU set, and generate one or more corresponding repair PDUs in the PDU set, wherein the source PDUs and the repair PDUs share a same PDU set sequence number (PSSN), and wherein the corresponding repair PDUs are for forward error correction (FEC), and send the PDU set. A real-time transport protocol header extension (HE) can include information indicating whether a PDU in the PDU set is a source PDU or a repair PDU.

Description

[0001] This application claims priority to U.S. Patent Application No. 19 / 089,750, filed March 25, 2025, and U.S. Provisional Patent Application No. 63 / 572,798, filed April 1, 2024, the entire contents of each of which are incorporated herein by reference. U.S. Patent Application No. 19 / 089,750, filed March 25, 2025, claims the benefit of U.S. Provisional Patent Application No. 63 / 572,798, filed April 1, 2024. Technical Field

[0002] This disclosure relates to data transmission and forward error correction techniques. Background Technology

[0003] Digital video capabilities can be incorporated into a wide range of devices, including digital televisions, digital direct broadcasting systems, wireless broadcasting systems, personal digital assistants (PDAs), laptops or desktop computers, digital cameras, digital recording devices, digital media players, video game devices, video game consoles, cellular or satellite broadcast phones, video conferencing equipment, and more. Digital video devices implement video compression technologies (such as those described in standards defined by MPEG-2, MPEG-4, ITU-T H.263 or ITU-T H.264 / MPEG-4, Part 10, Advanced Video Decoding (AVC), ITU-T H.265 (also known as High Efficiency Video Decoding (HEVC)), and extensions to these standards) to transmit and receive digital video information more efficiently.

[0004] After video data is encoded, it can be packaged for transmission or storage. Video data can be assembled into video files that conform to any of various standards, such as the International Organization for Standardization (ISO) Basic Media File Format and its extensions, such as AVC. Summary of the Invention

[0005] Generally, this disclosure describes techniques for conveying (e.g., transmitting, receiving, or forwarding) data. This data may include media data, video data, extended reality (XR) media data, which may include any or all of text data, audio data, video data, mixed reality (MR) data, augmented reality (AR) data, and / or virtual reality (VR) data. Data may be segmented and encapsulated in Protocol Data Units (PDUs), which may be conveyed as bursts of activity over radio signals. Similarly, PDUs may be organized into PDU sets, which may include a group of PDUs to be consumed together by a receiver. For example, a PDU set may include corresponding PDUs that include audio, video, and XR data. Furthermore, PDU sets and End-of-Burst (EoB) tags may be used to help identify XR traffic and optimize its delivery.

[0006] This disclosure describes techniques for signaling application-layer forward error correction (FEC) information for PDU sets. Specifically, this disclosure describes techniques for binding source packets and repair (e.g., parity) packets in the case of systematic FEC, and techniques for disclosing FEC information more efficiently.

[0007] In one example, this disclosure describes a method for transmitting data, the method comprising: generating one or more source PDUs in a set of Protocol Data Units (PDUs); generating one or more corresponding repair PDUs in the set of PDUs, wherein the source PDUs and the repair PDUs share the same PDU set sequence number (PSSN), and wherein the corresponding repair PDU is used for forward error correction (FEC); and transmitting the set of PDUs.

[0008] In another example, this disclosure describes an apparatus configured to transmit data, the apparatus comprising: a memory; and processing circuitry connected to the memory, the processing circuitry being configured to: generate one or more source PDUs in a set of Protocol Data Units (PDUs); generate one or more corresponding repair PDUs in the set of PDUs, wherein the source PDUs and the repair PDUs share the same PDU set sequence number (PSSN), and wherein the corresponding repair PDU is used for forward error correction (FEC); and transmit the set of PDUs.

[0009] In another example, this disclosure describes a method for receiving data, the method comprising: receiving one or more source PDUs from a set of Protocol Data Units (PDUs); and receiving one or more corresponding repair PDUs from the set of PDUs, wherein the source PDUs and the repair PDUs share the same PDU set sequence number (PSSN), and wherein the corresponding repair PDU is used for forward error correction (FEC).

[0010] In another example, this disclosure describes an apparatus configured to receive data, the apparatus comprising: a memory; and processing circuitry connected to the memory, the processing circuitry being configured to: receive one or more source PDUs from a set of Protocol Data Units (PDUs); and receive one or more corresponding repair PDUs from the set of PDUs, wherein the source PDUs and the repair PDUs share the same PDU set number (PSSN), and wherein the corresponding repair PDU is used for forward error correction (FEC).

[0011] Details of one or more examples are set forth in the accompanying drawings and the following description. Other features, objects, and advantages will be apparent from these descriptions and drawings, and from the claims. Attached Figure Description

[0012] Figure 1 This is a block diagram illustrating the architecture of a system configured to perform immersive real-time communication for Web Real-Time Communication (WebRTC) according to the technology of this disclosure.

[0013] Figure 2 An example RTP packet format is shown.

[0014] Figure 3 Another example RTP packet format is shown.

[0015] Figure 4 An example grouping format for Reed-Solomon FEC is shown.

[0016] Figure 5 An example FEC repair group is shown.

[0017] Figure 6 This is a block diagram illustrating the elements of the example video file.

[0018] Figure 7 An example bitmask according to the technique of this disclosure is shown.

[0019] Figure 8 An example of a Real-Time Transport Protocol (RTP) header extension according to the technology disclosed herein is shown.

[0020] Figure 9 Another example of RTP header extension according to the technology disclosed herein is shown.

[0021] Figure 10 Another example of RTP header extension according to the technology disclosed herein is shown.

[0022] Figure 11 An example of packet generation for application layer FEC according to the technology of this disclosure is shown.

[0023] Figure 12 An example process performed by the source device according to the technology of this disclosure is shown.

[0024] Figure 13 An example process executed by a client device according to the technology of this disclosure is shown. Detailed Implementation

[0025] Generally speaking, this disclosure describes techniques for conveying media data, such as video data and / or extended reality (XR) media data. XR media data may include any or all of text data, voice data, audio data, still image data, video data, mixed reality (MR) data, augmented reality (AR) data, and / or virtual reality (VR) data. The labeling of XR services is a mechanism to help the network identify XR services and optimize their delivery. The concept of a set of Protocol Data Units (PDUs) has been specifically introduced for this purpose, but this concept can also be used for other types of services. A set of PDUs consists of PDUs consumed together by the receiver and therefore should be disposed of together by the network.

[0026] This disclosure describes techniques for signaling application-layer forward error correction (FEC) information for PDU sets. Specifically, this disclosure describes techniques for binding source packets and repair (e.g., parity) packets in the case of systematic FEC, and techniques for more efficiently disclosing FEC information. In this context, binding source packets and repair packets means providing information indicating which repair packets correspond to a specific source packet. Such repair packets can be used in FEC techniques to correct errors using the corresponding source packets.

[0027] Figure 1 This is a block diagram illustrating an architecture 100 of a system that can be configured to perform FEC signaling technology on a set of PDUs disclosed herein. In some examples, architecture 100 can be used for 5G media streaming (5GMS) using Web Real-Time Communication (WebRTC) or 5G Real-Time Transport Protocol (5G RTP). That is, architecture 100 can be used to perform WebRTC and / or RTP real-time communication over a 5G network connection.

[0028] Architecture 100 can be used to provide WebRTC in a variety of scenarios. As an example, Architecture 100 can be used in conjunction with 5G networks to provide "on-the-top" (OTT) WebRTC. As another example, mobile network operators (MNOs) can use Architecture 100 to provide trusted WebRTC functionality and / or facilitate WebRTC services. As yet another example, Architecture 100 can provide interoperable WebRTC services. Architecture 100 can also be used in a variety of other scenarios. Architecture 100 provides flexibility through a set of functions and interfaces that can be combined in different ways based on the needs of specific scenarios.

[0029] exist Figure 1 In the example, architecture 100 includes a 5G RTC application provider 102, a 5G RTC application function 104, and a user equipment (UE) 150. Generally, the 5G RTC application provider 102 interacts with the 5G RTC application function 104 and supplies 5G RTC-aware applications such as network application 152 to the user equipment 150.

[0030] User equipment 150 can also be referred to as a "UE" or "client device". User equipment 150 can be, for example, a laptop or desktop computer, digital camera, digital recording device, digital media player, video game device, video game console, cellular or satellite radio phone, video conferencing equipment, etc. In this example, user equipment 150 includes a network application 152, a local WebRTC application 154, and a Media Session Handler (MSH) 158. Interface 156 connects the local WebRTC application 154 and MSH 158. Interface 156 can be referred to as the "RTC-6" interface. UE 150 and 5G RTC application provider 102 are connected via interface 174, which can be referred to as the "RTC-8" interface.

[0031] MSH 158 is a feature in UE 150 that provides access to 5G RTC support functions (such as 5G RTC application function 104) for WebRTC applications (such as network application 152). These functions can be provided upon request via interface 156 (RTC-6 interface) or transparently without directly involving network application 154. For example, MSH 158 can indirectly assist interactive connection establishment (ICE) negotiation by providing a session traversal utility (STUN) for network address translation and / or providing a list of traversal (TURN) server candidates using NAT-around relays for 5G RTC functionality. MSH 158 can also collect Quality of Experience (QoE) metric reports and submit consumption reports. MSH 158 can also provide media configuration recommendations to network application 152 via interface 156 (RTC-6).

[0032] Interface 170 (which may be referred to as the "RTC-1 interface") allows the 5G RTC application provider 102 to provide support for the provided RTC sessions as a 5G RTC application function 104. Provisioning may cover functionality including Quality of Service (QoS) for WebRTC sessions, billing provisioning for WebRTC sessions, collection of consumption and QoE metric data related to WebRTC sessions, provisioning ICE functionality (such as STUN and TURN servers), and / or provisioning WebRTC signaling servers (potentially with interoperability with other signaling servers).

[0033] In this example, 5G RTC application function 104 includes 5G RTC Support Application Function (AF) 110, 5G RTC config AF 112, 5G RTC provisioning AF 114, 5G RTC data channel AF 116, 5G RTC signaling server AF 118, 5G RTC interop AF 120, 5G RTC STUN AF 122, and 5G RTC TURN AF 124. In this example, 5G RTC application function 104 can also interoperate with Policy and Charging Function (PCF) 160, Network Open Function (NEF) 162, and Session Management Function (SMF) 164.

[0034] Interface 170, which can be called a "supply interface", is not necessarily relevant to all collaboration scenarios, and can provide some of the functionalities of 5G support functionality in the absence of application provider supply.

[0035] Interface 172 (which may be referred to as the "RTC-5" interface) is the interface between MSH 158 and 5G RTC application function 104. Interface 172 can be used to transmit configuration information from 5G RTC application function 104 to MSH 158 and request support for starting / in progressing WebRTC sessions. Configuration information may include static information such as recommendations for media configuration, configuration of STUN and TURN server locations, configuration regarding consumption and QoE reporting, or discovery information about WebRTC signaling and data channel servers and their capabilities.

[0036] MSH 158 can provide support functionality such as notifying 5G RTC application function 104 or network application 152 about WebRTC sessions and their status, requesting QoS allocation for starting or modifying WebRTC sessions, receiving notifications about changes to QoS allocation for ongoing WebRTC sessions, or receiving, updating, or exchanging information about WebRTC sessions with the 5G RTC STUN / TURN / signaling server, for example, to identify WebRTC sessions and associate them with QoS templates.

[0037] In some examples, the 5G functionality providing application capabilities to WebRTC applications (including the 5G RTC data channel AF116, the 5G RTC signaling server AF118, the 5G RTC interoperability AF120, the 5G RTC STUN AF122, and the 5G RTC TURNAF 124) can be alternatively provided by the application server (5G RTC AS) instead of the AF. The 5G RTC AS can then use a dedicated RTC-3 interface to request configuration and network support for the ongoing WebRTC session from the 5G RTC AF.

[0038] The functionality attributed to the 5G RTC application provider 102, 5G RTC application function 104, and UE 150 can be implemented in hardware, software, firmware, or any combination thereof. When implemented in software or firmware, memory may be provided for storing instructions executable by one or more processors implemented in the circuit. The processor may include one or more of a microprocessor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), discrete logic circuitry, or any combination thereof.

[0039] Figure 6 This is a block diagram illustrating the elements of example video file 250. Video files, according to the ISO Basic Media File Format and its extensions, store data in a series of objects called "boxes". Figure 6 In the example, video file 250 includes a file type (FTYP) box 252, a movie (MOOV) box 254, a segment index (sidx) box 262, a movie clip (MOOF) box 264, and a movie clip random access (MFRA) box 266. Although Figure 6 The example shown is a video file, but it should be understood that other media files may include other types of media data (e.g., audio data, timed text data, etc.) constructed similarly to those in video file 250, depending on the ISO Basic Media File Format and its extensions.

[0040] The File Type (FTYP) box 252 generally describes the file type of the video file 250. The File Type box 252 may include data identifying the specifications for the best use of the video file 250. The File Type box 252 may optionally be placed before the MOOV box 254, the Movie Clip box 264, and / or the MFRA box 266.

[0041] exist Figure 6 In the example, MOOV box 254 includes a Movie Header (MVHD) box 256, a Track (TRAK) box 258, and one or more Movie Extension (MVEX) boxes 260. Typically, the MVHD box 256 describes general characteristics of the video file 250. For example, the MVHD box 256 may include data describing when the video file 250 was initially created, when the video file 250 was last modified, the timestamp of the video file 250, the playback duration of the video file 250, or other data generally describing the video file 250.

[0042] TRAK box 258 may include track data of video file 250. TRAK box 258 may include a Track Header (TKHD) box, which describes the characteristics of the track corresponding to TRAK box 258. In some examples, TRAK box 258 may include decoded video images, while in other examples, the decoded video images of the track may be included in movie clip 264, which may be referenced by data from TRAK box 258 and / or sidx box 262.

[0043] In some examples, video file 250 may include more than one track. Therefore, MOOV box 254 may include TRAK boxes in a number equal to the number of tracks in video file 250. TRAK boxes 258 may describe the characteristics of the corresponding tracks in video file 250. For example, TRAK boxes 258 may describe the temporal and / or spatial information of the corresponding tracks. When encapsulation unit 30 ( Figure 1 When a parameter set track is included in a video file (such as video file 250), a TRAK box, similar to the TRAK box 258 of the MOOV box 254, can describe the characteristics of the parameter set track. The encapsulation unit 30 can signal the presence of a sequence level SEI message in the parameter set track within the TRAK box describing the parameter set track.

[0044] The MVEX box 260 can describe the characteristics of the corresponding movie clip 264, for example, by signaling to the video file 250 that, in addition to the video data (if any) included in the MOOV box 254, the movie clip 264 is also included. In the context of streaming video data, decoded video images may be included in the movie clip 264 instead of the MOOV box 254. Therefore, all decoded video samples may be included in the movie clip 264 instead of the MOOV box 254.

[0045] MOOV boxes 254 may include an equal number of MVEX boxes 260 as the number of movie segments 264 in the video file 250. Each MVEX box in the MVEX boxes 260 may describe the characteristics of a corresponding movie segment in the movie segment 264. For example, each MVEX box may include a Movie Extended Header Box (MEHD) box, which describes the time duration of a corresponding movie segment in the movie segment 264.

[0046] As noted above, encapsulation unit 30 may store a set of sequence data in a video sample that does not include the actual decoded video data. The video sample may typically correspond to an access unit, which is a representation of a decoded picture at a specific time instance. In the context of AVC, the decoded picture includes one or more VCL NAL units (containing information about all pixels used to construct the access unit) and other associated non-VCL NAL units (such as SEI messages). Therefore, encapsulation unit 30 may include a set of sequence data in a movie clip of movie clip 264, which may include a sequence-level SEI message. Encapsulation unit 30 may also signal the presence of the set of sequence data and / or the sequence-level SEI message as being present in a movie clip of movie clip 264 within an MVEX box of MVEX box 260 corresponding to a movie clip of movie clip 264.

[0047] SIDX box 262 is an optional element of video file 250. That is, video files conforming to 3GPP file formats or other such file formats do not necessarily need to include SIDX box 262. According to the example of the 3GPP file format, SIDX boxes can be used to identify sub-segments of a segment (e.g., a segment contained within video file 250). The 3GPP file format defines a sub-segment as "a self-contained set of one or more consecutive movie clip boxes having a corresponding media data box and a media data box containing data referenced by a movie clip box that must follow that movie clip box and precede the next movie clip box containing information about the same track." The 3GPP file format also instructs that the SIDX box "contains a series of references to sub-segments of the (sub)segment recorded by that box. The referenced sub-segments are consecutive in presentation time. Similarly, bytes referenced by the segment index box are always consecutive within the segment. The size of the reference gives a count of the number of bytes in the referenced material." SIDX box 262 typically provides information representing one or more sub-segments of a segment included in video file 250. For example, such information may include the playback time of the start and / or end of the sub-segment, the byte offset of the sub-segment, whether the sub-segment includes (e.g., begins at) a Stream Access Point (SAP), the type of SAP (e.g., whether the SAP is an Instant Decoder Refresh (IDR) picture, a Clean Random Access (CRA) picture, a Broken Link Access (BLA) picture, etc.), the location of the SAP within the sub-segment (in terms of playback time and / or byte offset), etc.

[0048] Movie clip 264 may include one or more decoded video pictures. In some examples, movie clip 264 may include one or more groups of pictures (GOPs), where each GOP may include several decoded video pictures, such as frames or images. Additionally, as described above, in some examples, movie clip 264 may include a sequence of data. Each movie clip in movie clip 264 may include a movie clip header box (MFHD). Figure 6 (Not shown in the image). MFHD boxes can describe the characteristics of the corresponding movie clip, such as the movie clip's sequence number. Movie clips 264 can be included in video file 250 in order of their sequence numbers.

[0049] MFRA box 266 can describe random access points within movie segments 264 of video file 250. This can help perform special effects modes, such as searching for specific time positions (i.e., playback times) within segments encapsulated by video file 250. In some examples, MFRA box 266 is typically optional and does not need to be included in the video file. Similarly, client devices (such as client device 40) do not necessarily need to refer to MFRA box 266 to correctly decode and display the video data of video file 250. MFRA box 266 can include a number of Track Fragment Random Access (TFRA) boxes (not shown) equal to the number of tracks in video file 250, or in some examples, a number equal to the number of media tracks (e.g., non-cue tracks) in video file 250.

[0050] In some examples, movie clip 264 may include one or more streaming access points (SAPs), such as IDR pictures. Similarly, MFRA box 266 can provide an indication of the location within the SAP video file 250. Therefore, a temporal subsequence of video file 250 can be formed from the SAP of video file 250. The temporal subsequence may also include other pictures, such as SAP-dependent P-frames and / or B-frames. Frames and / or slices of the temporal subsequence can be arranged within segments such that frames / slices of the temporal subsequence that depend on other frames / slices of the subsequence can be correctly decoded. For example, in a hierarchical arrangement of data, data used for prediction of other data may also be included in the temporal subsequence.

[0051] Application provider 102 and / or user equipment 150 can be configured to use forward error correction (FEC) information to process PDUs and / or PDU sets. Application layer FEC is within the scope of the Phase 2 study project of 5G Real-Time Transport Protocol (RTP) in 3GPP SA4 (Multimedia Codecs, Systems and Services). 5G RTP can facilitate low-latency, high-quality transmission of real-time data for applications such as voice, video, alternate reality (AR), virtual reality (VR), and other time-sensitive applications.

[0052] A PDU is a structured data unit transmitted across networks. As an example, in 5G, a PDU session is established between UE150 and the 5G RTC application provider 102 (see [link to PDU session]). Figure 1 The end-to-end connection between these devices allows for the exchange of different types of data, including IP packets, Ethernet frames, or unstructured data. When RTP services are transmitted over 5G, they are encapsulated within a PDU session to ensure efficient and reliable real-time data delivery.

[0053] RTP PDUs can include an RTP header and payload, encapsulated within UDP / IP packets and transmitted over 5G networks. The 5G Quality of Service (QoS) framework maps RTP packets to specific QoS streams, better ensuring low latency, minimal jitter, and optimized delivery for real-time applications such as Voice over New Radio (VoNR) and video conferencing. When transmitting TRP data within a 5G network, RTP PDUs are encapsulated within different network layers to facilitate delivery. For example, RTP PDUs can use the GPRS Tunneling Protocol-User Plane (GTP-U) bearer for transmission across the 5G core and are managed by the Service Data Adaptation Protocol (SDAP) at the Radio Access Network (RAN) level to ensure QoS compliance. A PDU set refers to a collection of PDUs transmitted together within a PDU session to support real-time media delivery.

[0054] exist Figure 6 In the context of this, the PDU collection will include data for one of the movie clips in movie clip 264. Each movie clip in movie clip 264 typically corresponds to a set of images or slices. The PDU collection may include PDUs that encapsulate all or a portion of that image.

[0055] Application-layer FEC schemes can be used in conjunction with data transmitted using PDUs and PDU sets. FEC is a technique used to enhance the reliability of real-time media transmission by adding redundant data to RTP packets. This redundancy allows the receiver to detect and correct packet loss or corruption without requiring retransmission. Many application-layer FEC schemes exist with different RTP packet formats, including non-MDS (Maximum Distance Separable) codes, near-MDS codes, and MDS codes.

[0056] MDS FEC codes are a class of forward error correction codes that achieve the theoretical limit of error correction and detection efficiency. MDS codes can recover the original data from the minimum required number of received symbols, meaning that MDS codes provide optimal redundancy without wasting additional resources.

[0057] On the other hand, non-MDS FEC codes do not achieve this optimal redundancy and may require more redundant symbols to achieve the same level of error correction. Non-MDS codes often sacrifice efficiency for other advantages, such as reduced computational complexity, reduced latency, or improved adaptability to specific network conditions. Although non-MDS codes may not be efficient in terms of the required minimum redundancy, they can still be highly efficient in real-world scenarios where computational constraints or different error modes must be considered.

[0058] Near-MDS FEC codes fall between MDS and non-MDS codes, offering error correction with near-optimal efficiency compared to MDS codes, but with slight compromises. Near-MDS codes aim to balance redundancy, computational overhead, and performance, making them suitable for scenarios where strict MDS-level efficiency is not necessary, but where a more efficient method than standard non-MDS codes is desired.

[0059] Example non-MDS codes include FlexFEC (RFC 8627) and ULPFEC (RFC 5109), where ULPFEC stands for Unequal Hierarchical Protection (ULP) FEC. Example MDS codes and near-MDS codes include RS (Reed-Solomon) FEC (RFC 5510, RFC 6865), Raptor (RFC 5053), and RaptorQ (RFC 6330).

[0060] All of the FEC techniques described above are system codes. System codes are error-correcting codes in which input data is embedded in the encoded output. Some specific implementations (e.g., WebRTC) may deviate from the standard (e.g., IETF RFC) in terms of session and stream configuration. That is, different FEC schemes use different FEC formats. Specifically, some of the FEC schemes described above may use different information and schemes to indicate which repair packets are associated with which source packets.

[0061] For example, Figure 2 The RTP packet format of FlexFEC (RFC 8267) is shown. The source packets are the same as regular RTP packets. Figure 2 The format of the repair group is shown. Figure 3 The RTP packet format of ULPFEC (RFC 5109) is shown. The protection rate varies for different FEC levels. Figure 4The packet format of RS FEC (RFC 6865) is shown. The explicit source FEC payload ID consists of the source block number, the coded symbol IDs of the source symbols contained in the source packet, and the source block length. The repair FEC payload ID consists of the source block number (which links the repair packet to the source packet), the coded symbol IDs of the repair symbols in the repair packet, and the source block length. Figure 5 An example FEC repair group is shown.

[0062] In the context of FEC, source packets are the original data packets carrying the primary information intended for transmission. These packets contain the actual payload (such as voice or video data in 5G RTP) before any error correction is applied. If all source packets are received correctly, data reconstruction requires no additional processing. Repair packets are redundant packets generated using the FEC algorithm to help recover lost or corrupted source packets. Repair packets do not carry new information; instead, they contain encoded data derived from multiple source packets. If some source packets are lost during transmission, the receiver can use repair packets to reconstruct the missing data without requiring retransmission, which is particularly useful in real-time applications where latency must be minimized.

[0063] In other FEC examples, information about binding the repair packet to the source packet for systematic FEC can be stored in the source packet's RTP payload. However, when encryption is applied to the RTP payload, any information indicating the binding of the source and repair packets becomes invisible to network routing entities such as base stations.

[0064] Considering the potential problems of systemic FEC handling, this disclosure describes techniques for binding source packets and repair packets. Sometimes repair packets are referred to as parity packets. In the context of this disclosure, binding source packets and repair packets means providing information indicating which repair packets correspond to a specific source packet. Such repair packets can be used in FEC techniques to correct errors using the corresponding source packet. This disclosure also describes techniques for more efficiently disclosing FEC information. The techniques of this disclosure make it easier for network entities to access the binding information between source packets and repair packets, thereby promoting better cross-layer optimization.

[0065] Example 1: Binding source PDUs and repair PDUs for systemic FEC Option 1:The source PDU and its corresponding repair PDU of an application data unit (e.g., a video frame) share the same PDU set sequence number (PSSN). The PSSN can be signaled in the RTP header extension (HE). The PSSN is a sequence identifier used to maintain the correct order of the PDU set. In Option 1, the source PDU and its corresponding repair PDU with the same PSSN form a PDU set. Network entities can determine which repair PDUs correspond to the source PDUs by matching the PSSN of the repair PDUs with the PDSSN of the source PDUs.

[0066] Option 1 can be used when the source PDU and repair PDU are multiplexed within the same flow (e.g., the same RTP session or the same IP 5-tuple). The IP 5-tuple is a set of five parameters used to uniquely identify a network flow in IP-based communication. The IP 5-tuple includes the source IP address, destination IP address, source port, destination port, and transport protocol. This combination allows network devices to track and manage individual data flows, enabling functions such as routing, firewall filtering, and QoS enforcement. In the context of 5G RTP, the 5-tuple can be used to identify and optimize real-time media flows, ensuring more efficient packet handling and minimal latency. Option 1 can also be used when the source PDU and repair PDU are in different media flows within the same flow (e.g., identified by different RTP synchronization sources (SSRC)).

[0067] Therefore, in one example of this disclosure, a device (e.g., a UE, a base station (e.g., a gNB), and / or an application provider) may be configured to transmit a source PDU and a corresponding repair PDU from a PDU set. In this example, the source PDU and the repair PDU share the same PSSN.

[0068] Option 2: In this example, the source PDUs form a first PDU set (e.g., referred to as the source PDU set). The corresponding repair PDUs form a second PDU set (e.g., referred to as the repair PDU set). The RTP HE of the PDUs in the repair PDU set carries information identifying the source PDU set. This technique can be used in two scenarios: when the source PDUs and repair PDUs are multiplexed in the same stream, or when the source PDUs and repair PDUs are transmitted in different streams.

[0069] The RTP payload format of the PDUs used to carry the source PDU set can be the same as the format without FEC. This allows for backward compatibility, enabling receivers that do not support FEC to still successfully process the source PDU set (e.g., in multicast scenarios where some receivers support FEC while others do not,).

[0070] The following describes additional details regarding the information about the source PDU set: 1) If the source PDU set and the repair PDU set are both in the same stream, the information in the RTP HE of the repair PDU set includes the PSSN of the source PDU set.

[0071] 2) Additionally, if the source PDU set and the repair PDU set are in different streams (e.g., using ULPFEC according to RFC 5109), the information in the RTP HE of the repair PDU set includes the PSSN of the source PDU set and the identifier of the stream to which the source PDU set belongs.

[0072] Therefore, the device (e.g., UE, base station (e.g., gNB), and / or application provider) can be configured to transmit source PDUs from a first PDU set and corresponding repair PDUs from a second PDU set. The device may further include information identifying the corresponding source PDU from the first PDU set in the RTP header extension of the second PDU set.

[0073] Example 2: Indicating additional FEC information in the RTP header extension (HE) In this example of the disclosure, application provider 102 and / or user equipment 150 may be configured to identify the packet type in the RTP HE (e.g., source PDU to repair PDU). The technology of Example 2 can be used in conjunction with the technology of Example 1.

[0074] Option 1: Application provider 102 and / or user equipment 150 may use two RTP header extension IDs: one for the source PDU (e.g., source RTP packet) and another for the repair PDU (e.g., repair RTP packet). This example, along with option 1 of Example 1, can be used to identify the actual type of the PDU (e.g., source or repair) when both the source and repair PDUs share the same PSSN. As described above, by making the source and repair PDUs share the same PSSN, the repair PDU can be associated with the source PDU (e.g., bound). Option 1 of Example 2 can be used to provide an RTP header extension ID to explicitly indicate whether the PDU is a source or repair PDU.

[0075] Option 2:Application provider 102 and / or user equipment 150 may use the same RTP header extension ID for both source PDUs and repair PDUs, and distinguish PDU types with other information. In one example, different subsets of the PSN space may be used to distinguish source PDUs and repair PDUs (e.g., even numbers for source packets and odd numbers for repair packets, or vice versa). The PSN represents the PDU sequence number (SN) of a PDU within a PDU set. In another example, source PDUs and repair PDUs may be distinguished by different PDU set importance (PSI) values. In yet another example, a new field added to the RTP HE may be used to distinguish source PDUs and repair PDUs. As an example, the new field added to the RTP HE could be a field used for PDU set labeling. As yet another example, a reserved field in the RTP header extension may be used to distinguish source PDUs and repair PDUs.

[0076] Option 3: Application provider 102 and / or user equipment 150 may use RTP header extensions (which are part of the RTP header) to convey information about the FEC applied to the RTP payload, without using any RTP header extensions to indicate that the RTP packet is a source PDU. In this case, the RTP header can be used to distinguish between the two types of packets.

[0077] Furthermore, in Example 2, application provider 102 and / or user equipment 150 may be configured to add at least one or more of the following to the RTP header extension: - Fields indicating the level of redundancy (e.g., the number of source PDUs, the number of repair PDUs, the FEC decoding rate, and / or the redundancy ratio). For example, the redundancy ratio could indicate the ratio of repair packets to source packets.

[0078] - A field indicating whether the RTP payload is encrypted and, if not, which FEC scheme is used. This field will allow routers (such as User Plane Functions (UPF) or base stations) to examine the RTP payload against a standard or known specific implementation to obtain more detailed information about the FEC scheme. In another example, the RTP endpoint informs the network (e.g., UE to AF (Application Functions) to PCF (Policy Control Functions) to UPF (User Plane Functions)), or the network detects whether packets in the flow are encrypted during session setup.

[0079] - One or more fields corresponding to the FEC header and / or FEC level m header (m=0, 1, 2, ..., e.g., in the case of ULPFEC) carried in the RTP payload of the FEC scheme.

[0080] Furthermore, in Example 2, application provider 102 and / or user equipment 150 may be configured to add at least one or more of the following to the RTP header extension related to the decoding relationship for non-MDS FEC schemes: - Information indicating which source PDUs are protected by the repair group. This information may include the identifier sequence number (SN) of the reference source PDU (e.g., PSSN and PSN or RTP sequence number) and a bitmask for the following source PDUs, where bit n indicates that the nth source PDU after the reference source PDU is protected and 0 indicates no protection.

[0081] - Number of columns (L) and rows (D) for two-dimensional (2D) FEC protection: If L>0 and D=0, indicate row FEC, and there will be no column FEC(1D) afterward.

[0082] The source group for each line is: SN, SN+1, ..., SN+(L-1); If L>0 and D=1, indicate row FEC, followed by column FEC(2D).

[0083] The source blocks for each line are: SN, SN+1, ..., SN+(L-1) Source groups for each column: SN, SN+L, ..., SN+(D-1) L After all row FEC packets have been transmitted, column FEC packets will be transmitted.

[0084] If L>0 and D>1, it indicates the number of columns FEC and D for each L group.

[0085] Source groups for each column: SN, SN+L, ..., SN+(D-1) L exist Figure 5 In Figure 510, an example of such RTP packets is shown.

[0086] Some of the fields mentioned above are optional. Session Description Protocol (SDP) signaling can indicate the presence or absence of optional fields. SDP signaling also maps the RTP HE ID to the RTP HE format.

[0087] For option 2 of Example 1, if the source PDU and the corresponding repair PDU form a set of PDUs, the following can be added to the RTP header extension: - If the source PDU set and the repair PDU set are in the same stream, then it is the PSSN of the source PDU set; or - The PSSN of the source PDU set and the identifier of the stream to which the source PDU set belongs. The identifier can be an IP 5-tuple or a simplified form of an IP 5-tuple (e.g., the output of a hash function).

[0088] Figure 7 An example bitmask according to this disclosure is shown. Figure 7 The example can be used in conjunction with option 2 of Example 1, where the source PDU and the repair PDU are in different PDU sets (e.g., a source PDU set and a repair PDU set). In this example, the source PDU set 300 includes eight PDUs, all of which have a PSSN equal to 315. Each PDU in the source PDU set 300 may include a unique PSN. A PSN is the PDU serial number of a PDU within a PDU set. The repair PDU set 310, corresponding to the source PDU set 300, includes two repair PDUs. The PDUs in the repair PDU set 310 include PSSNs different from those in the source PDU set 310 (e.g., 316). Figure 7 As shown, a bitmask is used to indicate which repair PDUs correspond to the source PDUs. For example... Figure 7 As shown, the value of a bit in the bitmask can be determined by the XOR function.

[0089] Figure 8 An example of RTP header extension is shown (e.g., for all FEC schemes). Figure 8 This example can be used in conjunction with option 2 of Example 1, where the source PDU and the repair PDU are in different PDU sets (e.g., a source PDU set and a repair PDU set). The source PDU set and the repair PDU set are in... Figure 8 The examples are in the same stream. HE ID=1 means the source PDU set and HE ID=2 means the repair PDU set.

[0090] HE 400 shows the HE for a PDU set of source PDUs. HE 410 shows the HE for a PDU set of repair PDUs. The SRC PSSN information in HE 410 identifies the set of source PDUs protected by the repair group (e.g., a repair PDU with HE 410 is bound to a source PDU with HE 400).

[0091] The following is an example of SDP signaling for Option 2 of Example 1 described above. SDP signaling can be included in the SDP Offer and SDP Answer for negotiation between the two endpoints.

[0092] - For HEs used for PDUs in the source PDU set (e.g., the same as in the current specification), the extended Backus-Noor Normal Form (ABNF) syntax for the extmap attribute can be as follows: extensionname = "urn:3gpp:pdu-set-marking:rel-18" extensionattributes = 3(format / "pdu-set-size" / "num-pdus-in-pdu- set") format = "short" / "long" - For HEs used to repair PDU sets, use the following syntax elements: extensionname = "urn:3gpp:pdu-set-marking-fec-repair:rel-21" extensionattributes = 3(format / "pdu-set-size" / "num-pdus-in-pdu- set") format = "short" / "long" - for Figure 8 An example of SDP signaling could be as follows: a=extmap:1 urn:3gpp:pdu-set-marking:rel-18 short pdu-set-size a=extmap:2 urn:3gpp:pdu-set-marking-fec-repair:rel-21 short pdu-set-size For other variants of FEC repair grouping, the same or different extmap attributes can be used ( extensionname and extensionattributes ABNF syntax. As an example, if the receiver can extend the length field in the RTP header element (... len If the RTP HE format is identified, the same extmap attribute can be used.

[0093] Figure 9 An example of RTP header extension is shown (e.g., for FlexFEC), where the source PDU set and the repair PDU set are in the same stream. Figure 9 The example can be used in conjunction with option 2 of Example 1, where the source PDU and the repair PDU are in different PDU sets (e.g., a source PDU set and a repair PDU set). Figure 9 As shown, HE 500 is the HE for the PDUs in the source PDU set. HE 510 is the HE for the PDUs in the repair PDU set. The SRC PSN identifies the starting PDU of the source PDU set protected by this repair packet. The BIT MASK is a bitmask of various sizes (e.g., 15, 46, 110, as in the bitmask size in RFC 8627). If bit n is set to 1, the PDUs (SRC PSN) + n of the source PDU set are protected; if bit n is set to 0, the PDUs are not protected.

[0094] Figure 10 An example of RTP header extension is shown (e.g., for RS FEC or RaptorQ FEC), where the source PDU set and the repair PDU set are in the same stream. Figure 10 The example can be used in conjunction with option 2 of Example 1, where the source PDU and the repair PDU are in different PDU sets (e.g., a source PDU set and a repair PDU set). HE 600 is the HE for the PDUs in the source PDU set. HE 610 is the HE for the PDUs in the repair PDU set. K is the number of source packets. N can be calculated as the total number of source packets and repair packets (e.g., N = z + K). The field K = k shows the binding between the repair PDU and the source PDU, where k is the number of PDUs in the PDU set (NPDS) of the source PDU set. The decoding rate is K / N.

[0095] It should be noted that any technique in Example 2 may be used in combination with any technique in Example 1.

[0096] Example 3: Using existing headers for PDU set identification 3GPP TR 26.926, Clause 5.7.4 describes content delivery modeling for application layer FEC. Several FEC schemes are defined in the IETF that allow or require RTP source packets to be transmitted unmodified or to be transmitted in a manner compatible with the payload format they adhere to. This restriction applies, for example, to IETF RFC 8627, Resilient FEC. Similarly, for Raptor FEC in the context of FECFRAME as defined in IETF RFC 6681, for a single ordered stream as described in Clause 8 of IETF RFC 6681, the source packets are unmodified.

[0097] In these cases, the repair packet preferably includes sufficient information to form a source block from a series of unmodified source packets. For example, IETF RFC 6681 adds the initial sequence number (of the RTP source packets included in the source block), source block length, and coded symbol ID to each repair packet, totaling 48 bits. The FEC coded ID, coded symbol size, and maximum source block length are signaled as part of the SDP. The information in the SDP and the repair packet allows the receiver to add the appropriate coded symbol ID (ESI) to the source block at the receiver for each received source packet. Once decoded, the information (size F) in the source block can be used to recover the length of the included packets.

[0098] Figure 11 This is an example of the packet generation process 700 for the application layer FEC.

[0099] Identification of PDU sets and FEC data The following signaling can be transmitted in SDP: - FEC-encoded ID (e.g., what FEC code is used, e.g., Raptor) - Encoded symbol size (e.g., block size) and maximum source block length Entities possessing the aforementioned information (e.g., the UE transmits information to the AF, which then forwards the information to the PCF, SMF, and ultimately to the UPF) (e.g., application server, UPF, gNB, etc.), and also considering the FEC header, can create a virtual PDU set. Such entities can perform one or more of the following: - Add the actual PDU set header (e.g., a GTP-U packet header to identify the PDU set and / or provide FEC information). In some examples, this generally only involves a delay because the source packet arrives before the repair packet.

[0100] - It can be operated based on a virtual PDU set to, for example, actively schedule application repair groups.

[0101] Figure 12 An example process performed by a source device according to the technology of this disclosure is shown. The source device may be a device that transmits a set of PDUs and may include a UE, a base station (e.g., a gNB) and / or an application provider (including application provider 102 and / or user equipment 150).

[0102] In one example of this disclosure, the source device may be configured to: generate one or more source PDUs (1200) in a set of Protocol Data Units (PDUs); generate one or more corresponding repair PDUs in a set of PDUs, wherein the source PDUs and repair PDUs share the same PDU set sequence number (PSSN), and wherein the corresponding repair PDUs are used for forward error correction (FEC) (1210); and transmit a set of PDUs (1220).

[0103] In one example, to generate one or more source PDUs in a PDU set, the source device is configured to generate a first Real-Time Transport Protocol (RTP) header extension (HE) for the one or more source PDUs, the first RTP HE including first information indicating the type of the source PDU. Additionally, to generate one or more corresponding repair PDUs in the PDU set, the source device is configured to generate a second RTP HE for the one or more corresponding repair PDUs, the second RTP HE including second information indicating the type of the repair PDU.

[0104] In one example, the first information is the first RTP header ID indicating the source PDU type, and the second information is the second RTP header ID indicating the repair PDU type.

[0105] In another example, the first information is a first PDU sequence number (PSN) subset for one or more source PDUs, and the second information is a second PSN subset for one or more corresponding repair PDUs, wherein the second PSN subset is different from the first PSN subset.

[0106] In another example, the first information is a first PDU set importance (PSI) value for one or more source PDUs, and the second information is a second PSI value for one or more corresponding repair PDUs, wherein the second PSI value is different from the first PSI value.

[0107] In another example, the source device is further configured to decode a field in the first RTP HE or the second RTP HE that indicates one or more of the following: redundancy level, whether the RTP payload is encrypted, FEC technology or decoding relationship for non-MDS (Maximum Distance Separable) FEC technology.

[0108] In another example, the source is further configured to generate first information in the fields of the RTP HE for PDU set tagging, and second information in the fields of the RTP HE for PDU set tagging.

[0109] Figure 13 An example process performed by a client device according to the technology of this disclosure is shown. The client device may be a device that receives a set of PDUs and includes a UE, a base station (e.g., a gNB), and / or an application provider (including application provider 102 and / or user equipment 150).

[0110] In one example, the client device may be configured to: receive one or more source PDUs (1300) from a set of Protocol Data Units (PDUs); and receive one or more corresponding repair PDUs from the set of PDUs, wherein the source PDUs and repair PDUs share the same PDU set sequence number (PSSN), and wherein the corresponding repair PDUs are used for forward error correction (FEC) (1310).

[0111] In one example, to receive one or more source PDUs from a PDU set, the client device is configured to receive a first Real-Time Transport Protocol (RTP) header extension (HE) for the one or more source PDUs, the first RTP HE including first information indicating the type of the source PDU. Additionally, to receive one or more corresponding repair PDUs from the PDU set, the client device is configured to receive a second RTP HE for the one or more corresponding repair PDUs, the second RTP HE including second information indicating the type of the repair PDU.

[0112] In one example, the first information is a first RTP header ID indicating the source PDU type, and the second information is a second RTP header ID indicating the repair PDU type.

[0113] In another example, the first information is a first PDU sequence number (PSN) subset for one or more source PDUs, and the second information is a second PSN subset for one or more corresponding repair PDUs, wherein the second PSN subset is different from the first PSN subset.

[0114] In another example, the first information is a first PDU set importance (PSI) value for one or more source PDUs, and the second information is a second PSI value for one or more corresponding repair PDUs, wherein the second PSI value is different from the first PSI value.

[0115] In another example, the client device is further configured to decode a field in the first or second RTP HE that indicates one or more of the following: redundancy level, whether the RTP payload is encrypted, FEC technology, or decoding relationship for non-MDS (Maximum Distance Separable) FEC technology.

[0116] In another example, the client device is further configured to decode the first information in the field of the RTP HE for PDU set tagging, and the second information in the field of the RTP HE for PDU set tagging.

[0117] In another example, the client device is further configured to perform FEC on one or more source PDUs using one or more corresponding repair PDUs.

[0118] Aspects of this disclosure may include any combination of the following: Aspect 1A. A method for retrieving media data, the method comprising: transmitting one or more source PDUs in a set of Protocol Data Units (PDUs); and transmitting one or more corresponding repair PDUs in the set of PDUs, wherein the source PDUs and the repair PDUs share the same PDU set sequence number (PSSN), and wherein the corresponding repair PDUs are used for forward error correction (FEC).

[0119] Aspect 2A. The method according to aspect 1A, wherein the one or more source PDUs represent data for a video frame.

[0120] Aspect 3A. A method for retrieving media data, the method comprising: sending one or more source PDUs in a first set of Protocol Data Units (PDUs); and sending one or more corresponding repair PDUs in a second set of PDUs, wherein a Real-Time Transport Protocol (RTP) header extension in the second set of PDUs identifies a corresponding source PDU of the one or more source PDUs in the first set of PDUs, and wherein the corresponding repair PDU is used for forward error correction (FEC).

[0121] Aspect 4A. A method for retrieving media data, the method comprising: transmitting one or more source PDUs in a first set of Protocol Data Units (PDUs), wherein the Real-Time Transport Protocol (RTP) RTP header extension in the first set of PDUs includes information identifying the first set of PDUs as including source PDUs; and transmitting one or more corresponding repair PDUs in a second set of PDUs, wherein the Real-Time Transport Protocol (RTP) RTP header extension in the second set of PDUs includes information identifying the second set of PDUs as including repair PDUs, and wherein the corresponding repair PDUs are used for forward error correction (FEC).

[0122] Aspect 5A. The method according to aspect 4A, wherein the information is an RTP header extension ID, which is different for the source PDU and the repair PDU.

[0123] Aspect 6A. The method according to aspect 4A, wherein the information is a subset of the PDU sequence number space.

[0124] Aspect 7A. The method according to aspect 4A, wherein the information is a PSI value.

[0125] Aspect 8A. The method according to aspect 4A, wherein the information is included in a separate field of the RTP header extension.

[0126] Aspect 9A. The method according to aspect 4A, the method further comprising: decoding fields in the RTP header extension to indicate a redundancy level.

[0127] Aspect 10A. The method according to aspect 4A, the method further comprising: decoding a field in the RTP header extension to indicate whether the RTP payload is encrypted.

[0128] Aspect 11A. The method according to aspect 4A, the method further comprising: decoding a field in a forward error correction (FEC) header, the field indicating the FEC technique.

[0129] Aspect 12A. The method according to aspect 4A, the method further comprising: an indication in the RTP header extension of the decoding relationship for a non-MDS (Maximum Distance Separable) FEC technique.

[0130] Aspect 13A. An apparatus for retrieving media data, the apparatus comprising: a memory; and one or more processors communicating with the memory, the one or more processors being configured to perform any combination of the methods described in aspects 1 to 12.

[0131] Aspect 14A. The apparatus according to aspect 13A, wherein the apparatus is a user equipment (UE) or an application provider.

[0132] Aspect 15A. The apparatus according to aspect 13A, wherein the apparatus comprises at least one of: an integrated circuit; a microprocessor; and a wireless communication device.

[0133] Aspect 16A. A method of receiving media data, the method comprising: receiving one or more source PDUs of a protocol data unit (PDU) set, the one or more source PDUs having a PDU set sequence number (PSSN); receiving one or more repair PDUs having the PSSN; determining that the one or more repair PDUs correspond to the one or more source PDUs when the PSSN of the repair PDU matches the PSSN of the source PDU; and using the source PDUs and the repair PDUs to perform forward error correction (FEC).

[0134] Aspect 17A. A method of receiving media data, the method comprising: receiving one or more source PDUs from a first set of Protocol Data Units (PDUs); receiving one or more corresponding repair PDUs from a second set of PDUs, wherein a Real-Time Transport Protocol (RTP) header extension in the second set of PDUs identifies a corresponding source PDU of the one or more source PDUs in the first set of PDUs; and performing forward error correction (FEC) using the repair PDUs and the corresponding source PDUs.

[0135] Aspect 18A. A method of receiving media data, the method comprising: receiving one or more source PDUs from a first set of Protocol Data Units (PDUs), wherein a Real-Time Transport Protocol (RTP) RTP header extension in the first PDU set includes information identifying the first PDU set as including source PDUs; receiving one or more corresponding repair PDUs from a second set of PDUs, wherein a Real-Time Transport Protocol (RTP) RTP header extension in the second PDU set includes information identifying the second PDU set as including repair PDUs corresponding to the source PDUs in the first PDU set; and performing forward error correction (FEC) using the source PDUs and the repair PDUs corresponding to the source PDUs.

[0136] Aspect 19A. A method of receiving media data, the method comprising: receiving one or more source protocol data units (PDUs); receiving one or more repair PDUs, the one or more repair PDUs including an FEC header; receiving Session Description Protocol (SDP) signaling, the SDP signaling including one or more of the following: a forward error correction (FEC) coding ID, a coding symbol size, or a maximum source block length in the SDP; and signaling the FEC header based on the SDP to create a virtual PDU set of source PDUs and corresponding repair PDUs.

[0137] Aspect 1B. A method for transmitting data, the method comprising: generating one or more source PDUs in a set of Protocol Data Units (PDUs); generating one or more corresponding repair PDUs in the set of PDUs, wherein the source PDUs and the repair PDUs share the same PDU set sequence number (PSSN), and wherein the corresponding repair PDUs are used for forward error correction (FEC); and transmitting the set of PDUs.

[0138] Aspect 2B. The method according to aspect 1B, wherein generating the one or more source PDUs in the PDU set includes generating a first Real-Time Transport Protocol (RTP) Header Extension (HE) for the one or more source PDUs, the first RTP HE including first information indicating the type of the source PDU, and wherein generating the one or more corresponding repair PDUs in the PDU set includes generating a second RTP HE for the one or more corresponding repair PDUs, the second RTP HE including second information indicating the type of the repair PDU.

[0139] Aspect 3B. The method according to aspect 2B, wherein the first information is a first RTP header ID indicating the source PDU type, and wherein the second information is a second RTP header ID indicating the repair PDU type.

[0140] Aspect 4B. The method according to aspect 2B, wherein the first information is a first PDU sequence number (PSN) subset for the one or more source PDUs, and wherein the second information is a second PSN subset for the one or more corresponding repair PDUs, wherein the second PSN subset is different from the first PSN subset.

[0141] Aspect 5B. The method according to aspect 2B, wherein the first information is a first PDU set importance (PSI) value for the one or more source PDUs, and wherein the second information is a second PSI value for the one or more corresponding repair PDUs, wherein the second PSI value is different from the first PSI value.

[0142] Aspect 6B. The method according to aspect 2B, the method further comprising: decoding a field in the first RTP HE or the second RTP HE, the field indicating one or more of the following: redundancy level, whether the RTP payload is encrypted, FEC technology or decoding relationship for non-MDS (Maximum Distance Separable) FEC technology.

[0143] Aspect 7B. The method according to aspect 2B, the method further comprising: generating the first information in a field of the RTP HE for PDU set labeling; and generating the second information in the field of the RTP HE for PDU set labeling.

[0144] Aspect 8B. An apparatus configured to transmit data, the apparatus comprising: a memory; and processing circuitry connected to the memory, the processing circuitry being configured to: generate one or more source PDUs in a set of Protocol Data Units (PDUs); generate one or more corresponding repair PDUs in the set of PDUs, wherein the source PDUs and the repair PDUs share the same PDU set sequence number (PSSN), and wherein the corresponding repair PDUs are used for forward error correction (FEC); and transmit the set of PDUs.

[0145] Aspect 9B. The apparatus according to aspect 8B, wherein, for generating the one or more source PDUs in the PDU set, the processing circuitry is configured to generate a first Real-Time Transport Protocol (RTP) header extension (HE) for the one or more source PDUs, the first RTP HE including first information indicating the type of the source PDU, and wherein, for generating the one or more corresponding repair PDUs in the PDU set, the processing circuitry is configured to generate a second RTP HE for the one or more corresponding repair PDUs, the second RTP HE including second information indicating the type of the repair PDU.

[0146] Aspect 10B. The apparatus according to aspect 9B, wherein the first information is a first RTP header ID indicating the type of the source PDU, and wherein the second information is a second RTP header ID indicating the type of the repair PDU.

[0147] Aspect 11B. The apparatus according to aspect 9B, wherein the first information is a first PDU sequence number (PSN) subset for the one or more source PDUs, and wherein the second information is a second PSN subset for the one or more corresponding repair PDUs, wherein the second PSN subset is different from the first PSN subset.

[0148] Aspect 12B. The apparatus according to aspect 9B, wherein the first information is a first PDU set importance (PSI) value for the one or more source PDUs, and wherein the second information is a second PSI value for the one or more corresponding repair PDUs, wherein the second PSI value is different from the first PSI value.

[0149] Aspect 13B. The apparatus according to aspect 9B, wherein the processing circuitry is further configured to: decode a field in the first RTP HE or the second RTP HE, the field indicating one or more of the following: redundancy level, whether the RTP payload is encrypted, FEC technology or decoding relationship for non-MDS (Maximum Distance Separable) FEC technology.

[0150] Aspect 14B. The apparatus according to aspect 9B, wherein the processing circuitry is further configured to: generate the first information in the field of the RTP HE for PDU set labeling; and generate the second information in the field of the RTP HE for PDU set labeling.

[0151] Aspect 15B. A method of receiving data, the method comprising: receiving one or more source PDUs from a set of Protocol Data Units (PDUs); and receiving one or more corresponding repair PDUs from the set of PDUs, wherein the source PDUs and the repair PDUs share the same PDU set number (PSSN), and wherein the corresponding repair PDUs are used for forward error correction (FEC).

[0152] Aspect 16B. The method according to aspect 15B, wherein receiving the one or more source PDUs in the PDU set includes receiving a first Real-Time Transport Protocol (RTP) Header Extension (HE) for the one or more source PDUs, the first RTP HE including first information indicating the type of the source PDU, and wherein receiving the one or more corresponding repair PDUs in the PDU set includes receiving a second RTP HE for the one or more corresponding repair PDUs, the second RTP HE including second information indicating the type of the repair PDU.

[0153] Aspect 17B. The method according to aspect 16B, wherein the first information is a first RTP header ID indicating the source PDU type, and wherein the second information is a second RTP header ID indicating the repair PDU type.

[0154] Aspect 18B. The method according to aspect 16B, wherein the first information is a first PDU sequence number (PSN) subset for the one or more source PDUs, and wherein the second information is a second PSN subset for the one or more corresponding repair PDUs, wherein the second PSN subset is different from the first PSN subset.

[0155] Aspect 19B. The method according to aspect 16B, wherein the first information is a first PDU set importance (PSI) value for the one or more source PDUs, and wherein the second information is a second PSI value for the one or more corresponding repair PDUs, wherein the second PSI value is different from the first PSI value.

[0156] Aspect 20B. The method according to aspect 16B, the method further comprising: decoding a field in the first RTP HE or the second RTP HE, the field indicating one or more of the following: redundancy level, whether the RTP payload is encrypted, FEC technology or decoding relationship for non-MDS (Maximum Distance Separable) FEC technology.

[0157] Aspect 21B. The method according to aspect 16B, the method further comprising: decoding the first information in a field of the RTP HE for PDU set labeling; and decoding the second information in the field of the RTP HE for PDU set labeling.

[0158] Aspect 22B. The method according to aspect 15B, the method further comprising: using the one or more corresponding repair PDUs to perform FEC on the one or more source PDUs.

[0159] Aspect 23B. An apparatus configured to receive data, the apparatus comprising: a memory; and processing circuitry connected to the memory, the processing circuitry being configured to: receive one or more source PDUs from a set of Protocol Data Units (PDUs); and receive one or more corresponding repair PDUs from the set of PDUs, wherein the source PDUs and the repair PDUs share the same PDU set number (PSSN), and wherein the corresponding repair PDUs are used for forward error correction (FEC).

[0160] Aspect 24B. The apparatus according to aspect 23B, wherein, for receiving the one or more source PDUs in the PDU set, the processing circuitry is configured to receive a first Real-Time Transport Protocol (RTP) header extension (HE) for the one or more source PDUs, the first RTP HE including first information indicating the type of the source PDU, and wherein, for receiving the one or more corresponding repair PDUs in the PDU set, the processing circuitry is configured to receive a second RTP HE for the one or more corresponding repair PDUs, the second RTP HE including second information indicating the type of the repair PDU.

[0161] Aspect 25B. The apparatus according to aspect 24B, wherein the first information is a first RTP header ID indicating the type of the source PDU, and wherein the second information is a second RTP header ID indicating the type of the repair PDU.

[0162] Aspect 26B. The apparatus according to aspect 24B, wherein the first information is a first PDU sequence number (PSN) subset for the one or more source PDUs, and wherein the second information is a second PSN subset for the one or more corresponding repair PDUs, wherein the second PSN subset is different from the first PSN subset.

[0163] Aspect 27B. The apparatus according to aspect 24B, wherein the first information is a first PDU set importance (PSI) value for the one or more source PDUs, and wherein the second information is a second PSI value for the one or more corresponding repair PDUs, wherein the second PSI value is different from the first PSI value.

[0164] Aspect 28B. The apparatus according to aspect 24B, wherein the processing circuitry is further configured to: decode a field in the first RTP HE or the second RTP HE, the field indicating one or more of the following: redundancy level, whether the RTP payload is encrypted, FEC technology or decoding relationship for non-MDS (Maximum Distance Separable) FEC technology.

[0165] Aspect 29B. The apparatus according to aspect 24B, wherein the processing circuitry is further configured to: decode the first information in a field of the RTP HE for PDU set marking; and decode the second information in the field of the RTP HE for PDU set marking.

[0166] Aspect 30B. The apparatus according to aspect 23B, wherein the processing circuitry is further configured to perform FEC on the one or more source PDUs using the one or more corresponding repair PDUs.

[0167] In one or more examples, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality may be stored as one or more instructions or code on a computer-readable medium or transmitted via a computer-readable medium and executed by a hardware-based processing unit. A computer-readable medium may include a computer-readable storage medium (which corresponds to a tangible medium such as a data storage medium) or a communication medium, including, for example, any medium that facilitates the transfer of a computer program from one place to another according to a communication protocol. In this way, a computer-readable medium may generally correspond to (1) a non-transitory tangible computer-readable storage medium, or (2) a communication medium such as a signal or carrier wave. A data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to extract instructions, code, and / or data structures for implementing the techniques described in this disclosure. Computer program products may include computer-readable media.

[0168] By way of example, and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disc storage devices, magnetic disk storage devices or other magnetic storage devices, flash memory, or any other medium capable of storing desired program code in the form of instructions or data structures and accessible by a computer. Furthermore, any connection is appropriately referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies (such as infrared, radio, and microwave), then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies (such as infrared, radio, and microwave) are included in the definition of medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but instead refer to non-transient tangible storage media. As used herein, disks and optical discs include: compact optical discs (CDs), laser optical discs, optical discs, digital versatile optical discs (DVDs), floppy disks, and Blu-ray discs, wherein disks typically reproduce data magnetically, while optical discs reproduce data optically using lasers. The combinations described above should also be included within the scope of computer-readable media.

[0169] Instructions can be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Therefore, as used herein, the term "processor" can refer to any of the foregoing structures or any other structure suitable for implementing the techniques described herein. Additionally, in some aspects, the functionality described herein can be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated into combined codecs. Furthermore, these techniques can be fully implemented in one or more circuit or logic elements.

[0170] The techniques disclosed herein can be implemented in a wide variety of devices or apparatuses, including wireless mobile phones, integrated circuits (ICs), or IC sets (e.g., chipsets). Various components, modules, or units are described in this disclosure to emphasize functional aspects of a device configured to perform the disclosed techniques, but implementation by different hardware units is not necessarily required. Rather, as described above, various units can be combined in a codec hardware unit, or various units can be provided by a collection of interoperable hardware units (including one or more processors as described above) combined with appropriate software and / or firmware.

[0171] Various examples have been described. These and other examples are within the scope of the following claims.

Claims

1. A method for sending data, the method comprising: Generate one or more source PDUs in the Protocol Data Unit (PDU) set; One or more corresponding repair PDUs are generated from the PDU set, wherein the source PDU and the repair PDU share the same PDU set number (PSSN), and wherein the corresponding repair PDU is used for forward error correction (FEC). as well as Send the PDU set.

2. The method of claim 1, wherein generating the one or more source PDUs in the PDU set includes generating a first Real-Time Transport Protocol (RTP) header extension (HE) for the one or more source PDUs, the first RTP HE including first information indicating the type of the source PDU, and Generating one or more corresponding repair PDUs in the PDU set includes generating a second RTP HE for the one or more corresponding repair PDUs, the second RTP HE including second information indicating the type of the repair PDU.

3. The method of claim 2, wherein the first information is a first RTP header ID indicating the source PDU type, and wherein the second information is a second RTP header ID indicating the repair PDU type.

4. The method of claim 2, wherein the first information is a first PDU sequence number (PSN) subset for the one or more source PDUs, and wherein the second information is a second PSN subset for the one or more corresponding repair PDUs, wherein the second PSN subset is different from the first PSN subset.

5. The method of claim 2, wherein the first information is a first PDU set importance (PSI) value for the one or more source PDUs, and wherein the second information is a second PSI value for the one or more corresponding repair PDUs, wherein the second PSI value is different from the first PSI value.

6. The method according to claim 2, further comprising: Decode a field in the first RTP HE or the second RTP HE, the field indicating one or more of the following: redundancy level, whether the RTP payload is encrypted, FEC technology or decoding relationship for non-MDS (Maximum Distance Separable) FEC technology.

7. The method according to claim 2, further comprising: Generate the first information in the fields of the RTP HE used for PDU set tagging; as well as Generate the second information in the field of the RTP HE used for PDU set tagging.

8. An apparatus configured to transmit data, the apparatus comprising: Memory; and Processing circuitry, connected to the memory, is configured to: Generate one or more source PDUs in the Protocol Data Unit (PDU) set; One or more corresponding repair PDUs are generated from the PDU set, wherein the source PDU and the repair PDU share the same PDU set number (PSSN), and wherein the corresponding repair PDU is used for forward error correction (FEC). as well as Send the PDU set.

9. The apparatus of claim 8, wherein, for generating the one or more source PDUs in the PDU set, the processing circuitry is configured to generate a first Real-Time Transport Protocol (RTP) header extension (HE) for the one or more source PDUs, the first RTP HE including first information indicating the type of the source PDU, and In order to generate one or more corresponding repair PDUs in the PDU set, the processing circuit is configured to generate a second RTP HE for the one or more corresponding repair PDUs, the second RTP HE including second information indicating the type of the repair PDU.

10. The apparatus of claim 9, wherein the first information is a first RTP header ID indicating the type of the source PDU, and wherein the second information is a second RTP header ID indicating the type of the repair PDU.

11. The apparatus of claim 9, wherein the first information is a first PDU sequence number (PSN) subset for the one or more source PDUs, and wherein the second information is a second PSN subset for the one or more corresponding repair PDUs, wherein the second PSN subset is different from the first PSN subset.

12. The apparatus of claim 9, wherein the first information is a first PDU set importance (PSI) value for the one or more source PDUs, and wherein the second information is a second PSI value for the one or more corresponding repair PDUs, wherein the second PSI value is different from the first PSI value.

13. The apparatus of claim 9, wherein the processing circuit is further configured to: Decode a field in the first RTP HE or the second RTP HE, the field indicating one or more of the following: redundancy level, whether the RTP payload is encrypted, FEC technology or decoding relationship for non-MDS (Maximum Distance Separable) FEC technology.

14. The apparatus of claim 9, wherein the processing circuit is further configured to: Generate the first information in the fields of the RTP HE used for PDU set tagging; and Generate the second information in the field of the RTP HE used for PDU set tagging.

15. An apparatus configured to receive data, the apparatus comprising: Memory; and Processing circuitry, connected to the memory, is configured to: Receive one or more source PDUs from the Protocol Data Unit (PDU) set; as well as Receive one or more corresponding repair PDUs from the PDU set, wherein the source PDU and the repair PDU share the same PDU set number (PSSN), and wherein the corresponding repair PDU is used for forward error correction (FEC).

16. The apparatus of claim 15, wherein, for receiving the one or more source PDUs from the PDU set, the processing circuitry is configured to receive a first Real-Time Transport Protocol (RTP) header extension (HE) for the one or more source PDUs, the first RTP HE including first information indicating the type of the source PDU, and In order to receive one or more corresponding repair PDUs from the PDU set, the processing circuit is configured to receive a second RTP HE for the one or more corresponding repair PDUs, the second RTP HE including second information indicating the type of the repair PDU.

17. The apparatus of claim 16, wherein the first information is a first RTP header ID indicating the type of the source PDU, and wherein the second information is a second RTP header ID indicating the type of the repair PDU.

18. The apparatus of claim 16, wherein the first information is a first PDU sequence number (PSN) subset for the one or more source PDUs, and wherein the second information is a second PSN subset for the one or more corresponding repair PDUs, wherein the second PSN subset is different from the first PSN subset.

19. The apparatus of claim 16, wherein the first information is a first PDU set importance (PSI) value for the one or more source PDUs, and wherein the second information is a second PSI value for the one or more corresponding repair PDUs, wherein the second PSI value is different from the first PSI value.

20. The apparatus of claim 16, wherein the processing circuit is further configured to: Decode a field in the first RTP HE or the second RTP HE, the field indicating one or more of the following: redundancy level, whether the RTP payload is encrypted, FEC technology or decoding relationship for non-MDS (Maximum Distance Separable) FEC technology.

Images