HK1141172B

HK1141172B - Streaming and buffering using variable fec overhead and protection periods

Info

Publication number: HK1141172B
Application number: HK10107464.0A
Authority: HK
Inventors: M‧沃森; M‧G‧卢比
Original assignee: Qualcomm Incorporated
Priority date: 2006-02-13
Filing date: 2010-08-04
Publication date: 2015-07-31

Description

Streaming and buffering using variable FEC overhead and protection period

This application is a divisional application of PCT international application number PCT/US2007/062086, international application date 2007/2/13, chinese national application number 200780010032.8, entitled "streaming and buffering with variable FEC overhead and protection period".

Cross-referencing

This application is a non-provisional application from and claims priority to U.S. provisional patent application No.60/773,185 filed on 13.2006 and U.S. provisional patent application No.60/773,501 filed on 14.2006.

The following references are incorporated by reference herein for all purposes:

U.S. Pat. No.6,307,487 entitled "Information Additive Code Generator and Decoder for communication Systems" (hereinafter "Lubty") to Luby; and

U.S. patent No.7,068,729 entitled Multi-Stage Code Generator and decoder for Communication Systems (hereinafter "Shokrollahi") to Shokrollahi et al.

Technical Field

The present invention relates to encoding and decoding data in a communication system, and more particularly, to a communication system that encodes and decodes data to account for errors and gaps in the communicated data while coping with the need for a receiver to quickly provide the data as it is received.

Background

The transmission of files and streams between a sender and a receiver over a communication channel has been the subject of numerous documents. Preferably, the recipient desires to receive a correct copy of the data transmitted by the sender over the channel with some level of certainty. In the case of channels that do not have ideal fidelity (which includes almost all physically realizable systems), there is concern about how to handle data lost and garbled in transmission. Lost data (erasures) are generally easier to handle than corrupted data (errors) because the recipient is not always able to recognize when corrupted data is received in error. Many error correcting codes have been developed to correct erasures and/or errors.

Data transmission is simple when the transmitter and receiver have all the computing power and electrical power required for communication and the channel between the transmitter and receiver is clean enough to allow relatively error-free communication. The data transmission problem becomes difficult when the channel is in a hostile environment or the transmitter and/or receiver has limited capabilities.

One solution is to use Forward Error Correction (FEC) techniques, where data is encoded at the transmitter to enable the receiver to recover from transmission erasures and errors. Where feasible, a back channel from the receiver to the transmitter allows the receiver to communicate errors to the transmitter, which may then adjust its transmission process accordingly. However, reverse channels are often unavailable or infeasible, or only limited capabilities are available. For example, when a transmitter transmits to a large number of receivers, the transmitter cannot handle the reverse channels from all of these receivers. As a result, communication protocols often need to be designed with no or limited capacity back channels, and as such, the transmitter may have to deal with widely varying channel conditions without having a comprehensive overview of those channel conditions.

In the case of a packet protocol for data transport over a channel where packets may be lost, a file, stream, or other data block to be transmitted over a packet network is divided into uniformly sized input symbols, an FEC code is used to generate from the input symbols code symbols of the same size as the input symbols, and the code symbols are placed and transmitted in the packet. The "size" of a symbol can be measured in bits, whether or not the symbol is actually split into a bit stream, where when the symbol is selected from 2^MAn alphabet of symbols, one symbol has a size of M bits. In such packet-based communication systems, a packet erasure-oriented FEC coding scheme may be suitable. A file transfer is considered reliable if it allows the intended recipient to recover the correct copy of the original file, even in the face of an erasure in the network. Streaming is considered reliable if it allows the intended recipient to recover the correct copy of each part of the stream in time, even in the face of erasures in the network. Both file transfer and streaming may be somewhat reliable in the sense that a file or portions of a stream cannot be recovered or streamed in the event that portions of the stream cannot be recovered in time. Buffering mechanisms in routers are often forced to drop incoming packets by causing them to reach their capacity due to bursty congestionPacket loss occurs by group. Protection against erasure during transport has been the subject of numerous studies.

In the case of a protocol for data transmission over a noisy channel that can corrupt bits, a data block to be transmitted over the data transmission channel is divided into input symbols of uniform size, code symbols of the same size are generated from the input symbols, and the code symbols are transmitted over the channel. For such noisy channels, the size of a symbol is typically one or a few bits, regardless of whether the symbol is actually split into a bit stream. In such communication systems, a bit stream error correction oriented FEC coding scheme may be suitable. A data transmission is considered reliable if it allows the intended recipient to recover the correct copy of the original block, even in the face of errors (either detected or undetected symbol corruption in the channel). The output is also somewhat reliable in the sense that some parts of the block may remain corrupted after recovery. Symbols are typically corrupted by bursty noise, periodic noise, interference, weak signals, congestion in the channel, and various other causes.

One problem with some FEC codes is that they require excessive computing power or memory to operate. Another problem is that the number of output symbols must be determined before the encoding process. This can lead to inefficiencies if the packet loss rate is overestimated, and failures if the packet loss rate is underestimated.

Chain reaction codes are FEC codes that allow the generation of an arbitrary number of output symbols from a fixed input symbol of a file or stream. Sometimes they are called fountain or rateless codes because the code does not have an a priori fixed transmission rate and the number of possible output symbols may not be related to the number of input symbols. For example, novel techniques for generating, using, or manipulating chain reaction codes are shown in Luby and Shokrollahi.

It should also be appreciated that multi-level chain reaction ("MSCR") codes, such as those described in Shokrollahi and developed under the trademark "Raptor" code by Digital Fountain, inc. For example, multi-level chain reaction codes are used in encoders that receive input symbols from a source file or stream, generate intermediate symbols from the input symbols, and use these intermediate symbols as source symbols for a chain reaction encoder.

Other variations of these codes may be more suitable or preferred for some applications. As used herein, an input symbol refers to data received from a file or stream, and a source symbol refers to a symbol used to generate an output symbol. In some cases, the source symbols include input symbols, and in some cases, the source symbols are input symbols. However, there are situations where the input symbols are encoded and/or converted into an intermediate set of symbols and this intermediate set is used to generate the output symbols without involving the input symbols (directly). Thus, the input symbols comprise information known to a transmitter in communication with the receiver, the source symbols are symbols used by at least one stage of the encoder and derived from the input symbols, and the output symbols comprise symbols transmitted by the transmitter to the receiver.

In some applications, the receiver may begin using the data before the transmission is complete. For example, in a video-on-demand (video-on-demand) system, a receiver may start playing out video after receiving only a small portion of video data, and assume that the rest of the video data will be received before it is needed. In such systems, encoding should not be done over the entire transmission, as some output symbols at the end of the transmission may encode input symbols needed at the beginning of the video, in which case those output symbols are wasted because their information is needed when it is not available, and not when it is available. To avoid this, the data stream is typically partitioned into blocks, where the input data for a block is encoded and transmitted before the next block is ready, and these blocks are typically not dependent on input symbols outside these blocks.

For such applications, there is often a tradeoff between reliability and the lag time between when transmission begins and when data can begin to be used. For example, if an entire feature length movie is encoded such that errors at the beginning of the transmission can be corrected using data at the end of the transmission, the receiver may wait until it receives all of the movie data before indicating to the application (or user of the application) that the movie is available for playback. However, there may be unacceptable lag times when the total time of transmission is long.

One solution is to encode the data stream such that the receiver has enough information to begin playback of the movie after some small lag time, while the receiver may desire to receive further information in time to continue playback. Of course, if the data near the end of the transmission provides redundancy to the data at the beginning of the transmission, this capability is wasted because the first part of the movie will be played back much earlier than the latter information is received. Thus, decoding of temporally close data, which often makes available redundancy when needed, is efficient. However, if the constraints are too severe, playback may have to start prematurely and raise the possibility that the receiver encounters a playback point in the movie where it does not yet have enough data to decode and may cause a jump or pause.

There is a trade-off in using blocks: too small a block size does not provide adequate error protection, while too large a block size does experience too much delay while waiting for the block to be fully recovered.

Summary of The Invention

In an embodiment of the invention, data is streamed from a transmitter to a receiver, where streaming is the delivery of data assuming that the receiver will begin using the data before it is fully transmitted and received. The streamed data includes forward error correction ("FEC") and the rate at which the data is consumed may vary. The transmitter has an input rate at which it runs out of input data and a transmission rate at which it sends this data (and FEC data on demand) and these two rates may be different and therefore change when FEC is involved, as there is some overhead accompanying FEC encoding. At the receiver, there is a receiving rate (at which the receiver receives data) and a consuming rate (at which the receiver runs out of data for its output). The transmitter transmits using a transmission rate greater than the consumption rate and the extra bandwidth is available for FEC protection and buffering.

In some embodiments, the excess rate varies with transmission period.

A further understanding of the nature and advantages of the inventions disclosed herein may be realized by reference to the remaining portions of the specification and the attached drawings.

Brief Description of Drawings

Fig. 1 is a block diagram of a communication system that may use the variable FEC overhead techniques described herein.

Fig. 2 is a diagram of an FEC streaming framework architecture.

Fig. 3 is a diagram of an FEC source packet.

Fig. 4 is a diagram of an FEC repair (repair) packet.

Fig. 5 is a diagram of an FEC object information block.

Fig. 6 is a diagram of a source FEC payload ID format.

Fig. 7 is a diagram of a repair FEC payload ID format.

Fig. 8 is a diagram of an alternative repair FEC payload ID format.

Fig. 9 is a diagram of an FEC feedback protocol message format.

Fig. 10 is a diagram of a payload format of a success report message.

Detailed Description

In an embodiment of the invention, data is streamed from a transmitter to a receiver, where streaming is the delivery of data assuming that the receiver will begin using the data before it is fully transmitted and received. The streamed data includes forward error correction ("FEC"), which provides an improvement over retransmission-request schemes in which retransmission of lost packets is requested by the receiver if packet loss is detected.

Various rates are involved in the streaming process. The streamed data includes forward error correction ("FEC") and the rate at which the data is consumed may vary. The transmitter has an input rate at which it runs out of input data and a transmission rate at which it sends this data (and FEC data on demand) and these two rates may be different and therefore may change when FEC is involved, as there is some overhead in the case where FEC encoding is involved. At the receiver, there is a receiving rate (at which the receiver receives data) and a consuming rate (at which the receiver uses up data for its output). The reception rate is the same as the transmission rate when there is no data loss on the channel. There is an original reception rate, which is a rate at which data is received without accounting for overhead due to FEC. For example, if the receiver is a video player that outputs 11 mega/second (MBS) video streams to the display device, the consumption rate is 11 MBS. When playing out consumed data on a display, audio, processor, or other data player, the consumption rate may be referred to as a "play out" rate.

In the case of many streams, it is desirable to have consumption continue so that the presentation of the streamed data does not stop or block, which would occur if all of the data at the receiver were consumed and the receiving rate was less than the consumption rate. To avoid this, the receiver typically has a buffer so that the receiving rate can fall temporarily below the consumption rate (due to packet loss, congestion, etc.) but without running out of data to be consumed.

When the receiving rate happens to be the consuming rate, there is no additional data to be buffered. To fill the buffer of the receiver, the streaming system can be set such that the transmission rate is higher than the consumption rate, or the transmission starts before playout starts. In either case, there is sufficient reception to at least partially fill the receiver buffer.

In either case, it is often a better approach to use FEC instead of retransmission. In case retransmission is used, when the receiver sends a retransmission request and receives a response, there needs to be enough receiver buffer to continue playing out the data, otherwise the player will stop when the missing data that has yet to be restored is reached.

In a particular embodiment, the transmitter transmits using a rate greater than the consumption rate, and the extra bandwidth is partly used for FEC protection and partly for buffer filling to allow features such as "fast start", where the play-out can be started immediately after the start of reception with the buffer sufficiently filled, thereby reducing the risk of stopping the play-out.

In some embodiments, the bandwidth used for FEC protection and the amount of overhead used for buffer padding vary over time. For example, the overall transmission bit rate may be a constant value slightly higher than the consumption rate, with the excess being more used for buffer filling at the beginning of the transmission and less used for buffer filling at a subsequent time. With a constant bit rate, the FEC protection will be less at the beginning of the transmission and more at a later time. A constant bit rate is not required and a constant FEC overhead can be used.

Overview

Protocols for FEC protection of streaming media using multi-level chain reaction (MSCR) codes, such as by DF Raptor, are described below for applications including DVB-IPI applications^TMThose used in encoders and decoders. Examples of such multilevel code are described in Shokrollahi. It should be understood that the purpose of this disclosure is that MSCR codes are used merely as an example of multilevel codes, and that the teachings of this disclosure can be used with multilevel codes other than those described in Shokrollahi.

Multilevel codes can be used for FEC protection for DVB-IPI real-time applications (multicast and unicast using MPEG-2 transport stream encapsulation and direct transmission of both audio and video over RTP).

FEC building block [3] defined by the IETF reliable multicast working group describes a way to use the protocol specification of FEC, which separates the definition of the protocol from the specification of the FEC code itself. This enables the protocol design problem to be solved independently of the very different FEC code selection problems. In the terminology of FEC building blocks, separate specifications are provided for the "content delivery protocol" and for the "FEC scheme", the former defining the protocol and the latter defining the actual FEC code. The FEC building block describes the rules: both types of specifications must be followed so that they can be used together and thus provide a "glue" between the content delivery protocol and the FEC scheme.

According to this approach, the specification is organized into a plurality of modular components. These components are then combined to form a complete protocol suitable for DVB-IPI applications. These components include: (1) an FEC streaming framework, which provides an overall protocol framework for applying FEC to media streams, and is described in section 2; (2) a plurality of FEC schemes that define protocol components suitable for various types of applications and define how the core MSCR code is applied to streaming applications, described in section 3; (3) a modular protocol component, which can be used to support applications based on the FEC streaming framework and FEC scheme defined herein, shown in section 4; and (4) protocol specifications for multicast and unicast video using MPEG-2 transport stream encapsulation and direct transport of both audio and video over RTP, which is constructed using the building blocks described above (section 5).

Terms and acronyms

Term/acronym	Define/describe
		Bag (bag)	Streams grouped into a single source block and used to generate a single stream of repair symbols (also referred to asTraffic) collection. For example, a low bit rate audio stream may be packetized with a high bit rate stream, providing better FEC protection than if it were unpacked.
Flow rate	Another term for "stream" is used in the context of packets.
		Intermediate block	A data block derived from the original source block data-in the case of an MSCR encoder, or a combination of received source symbols and repair symbols-in the case of an MSCR decoder.
Repairing code elements	A symbol generated by the MSCR encoder, the symbol being derived from the source symbol.
		Source block	A block of source data, and the MSCR encoder provides FEC repair information on the block.
Source code element	Data units from a source block. All source symbols in a source block are of the same size.
		FEC	Forward error correction.
Encoding code element	Source symbols or repair symbols.
		Source Packet Information (SPI)	Information included in source blocks related to or from the source packet.
FEC streaming configurationInformation	Information that controls the operation of the FEC streaming framework.

TABLE 2 terminology and acronyms

Encoder and decoder

Fig. 1 is a block diagram of a communication system 100 that uses multi-level coding and may use the variable FEC overhead techniques described herein.

In communication system 100, an input file 101 or an input stream 105 is provided to an input symbol generator 110. The input symbol generator 110 generates a sequence of one or more input symbols (IS (0), IS (1), IS (2),..) from an input file or stream, and each input symbol has a value and a position (denoted in fig. 1 as an integer in parentheses). As explained above, the possible values of an input symbol, i.e. its alphabet, are typically 2^MAn alphabet of symbols such that each input symbol code encodes M bits of the input file. The value of M is typically determined based on the use of the communication system 100, but a general system may include a symbol size input corresponding to the input symbol generator 110 so that M may vary from use to use. The output of the input symbol size generator 110 is provided to an encoder 115.

The static key generator 130 generates a static key stream S₀、S₁.. The number of static keys generated is typically limited and depends on the particular embodiment of the encoder 115. The generation of the static key will be described in more detail later. The dynamic key generator 120 generates a dynamic key for each output symbol to be generated by the encoder 115. Each dynamic key is generated such that most of the dynamic keys are unique to the same input file. For example, Luby I describes an embodiment of a key generator that may be used. The outputs of the dynamic key generator 120 and the static key generator 130 are provided to the encoder 115.

From each key I provided by the dynamic key generator 120, the encoder 115 generates output symbols having values b (I) from the input symbols provided by the input symbol generator. The operation of the encoder 115 will be described in more detail below. The value of each output symbol is generated based on its key, some function of one or more of the input symbols, and one or more redundant symbols that may have been calculated from the input symbols. The set of input symbols and redundant symbols that produce a particular output symbol is referred to herein as the "associated symbol" of the output symbol or simply its "association". The selection of the function ("cost function") and associations is made according to the process described in more detail below. Typically, M is the same for both input and output symbols, i.e. they are both codes of the same number of bits, but this is not always the case.

In some embodiments, the number of input symbols, K, is used by encoder 115 to select the association. K may only be an estimate if K is not known in advance, such as when the input is a streaming file. The value K may also be used by the encoder 115 to allocate storage to the input symbols and any intermediate symbols generated by the encoder 115.

The encoder 115 provides the output symbols to the transmission module 140. The key for each such output symbol generated by the dynamic key generator 120 is also provided to the transmission module 140. The transmitting module 140 transmits the output symbols, and depending on the key control (keying) method used, the transmitting module 140 may also transmit some data regarding the keys of the transmitted output symbols to the receiving module 150 over the channel 145. Channel 145 is assumed to be an erasure channel, but this is not necessary for proper operation of communication system 100. Modules 140, 145 and 150 may be any suitable hardware components, software components, physical media, or any combination thereof, as long as transmitting module 140 is adapted to transmit the output symbols and any required data about its keys to channel 145, and receiving module 150 is adapted to receive the symbols and potentially some data about its keys from channel 145. The value K may be transmitted through the channel 145 if used to determine the association, or may be set in advance through agreement between the encoder 115 and the decoder 155.

As explained above, the channel 145 may be a real-time channel, such as a path through the internet or a broadcast link from a television transmitter to a television receiver or a telephone connection from one point to another, or the channel 145 may be a storage channel such as a CD-ROM, disk drive, website, or the like. Channel 145 may even be a combination of a real-time channel and a storage channel, such as a channel formed when an individual transmits an input file over a telephone line from a personal computer to an Internet Service Provider (ISP), which is stored on a Web server and then transmitted over the internet to a recipient.

Since channel 145 is assumed to be an erasure channel, communication system 100 does not assume a one-to-one correspondence between output symbols exiting receiving module 150 and output symbols entering transmitting module 140. Indeed, where channel 145 comprises a packet network, communication system 100 cannot even assume that the relative order of any two or more packets is preserved as they are transmitted over channel 145. Thus, the key for the output symbols is determined using one or more of the key control schemes described above, and is not necessarily determined according to the order in which the output symbols leave the receiving module 150.

The receiving module 150 provides the output symbols to the decoder 155 and any data received by the receiving module 150 regarding the keys of these output symbols is provided to the dynamic key regenerator 160. The dynamic key regenerator 160 regenerates the dynamic keys of the received output symbols and provides these dynamic keys to the decoder 155. Static key generator 163 regenerates static key S₀、S₁And provide them to decoder 155. The static key generator accesses a random number generator 135 used during both the encoding and decoding processes. If the random numbers are generated on the same physical device, this may be in the form of access to that device, or in the form of access to the same algorithm for random number generation to achieve the same behavior. The decoder 155 uses the keys provided by the dynamic key regenerator 160 and the static key generator 163 together with the corresponding keysThe output symbols are taken together to recover the input symbols (again IS (0), IS (1), IS (2) ·). Decoder 155 provides the recovered input symbols to an input file reassembler 165, which generates a copy 170 of input file 101 or input stream 105.

Encoder 115 may encode data using the techniques shown herein such that FEC encoding has variable overhead.

2FEC streaming framework

2.1Introduction to the design reside in

This section defines a defined framework for CDP, which provides FEC protection of data traffic streamed over UDP in the sense of FEC building blocks. This section does not define a full content delivery protocol, but only those aspects that are desired to be common to all content delivery protocols that support streaming data over UDP.

The framework defined in this section is not specific to a single streaming application protocol. The framework provides FEC protection for application protocol traffic over UDP and combined protection for multiple such traffic. For example, multiple RTP traffic may be protected along with associated RTCP traffic and potentially other related traffic such as MIKEY packets. For many FEC schemes in many loss conditions, the improvement in reliability achievable by using FEC with a given FEC overhead increases with the amount of data protected as a single block. There is therefore a significant benefit in the ability to protect multiple streams together, especially in situations where the receiver requires all streams in order to provide useful services to the user.

This framework does not define how the traffic to be protected is determined, nor how the details of the protected traffic and the FEC streams protecting them are communicated from the transmitter to the receiver. Full content delivery protocol specifications, such as those given in section 5, address these signaling requirements. However, this section does specify the information required by the FEC streaming framework at the sender and receiver-e.g., the details of the traffic to be FEC protected and the traffic that will carry the FEC protected data. The SDP attribute used by the content delivery protocol to convey this information is also specified.

The architecture outlined above is illustrated in fig. 2.

2.2Overview of procedures

2.2.1 overview

The mechanism defined in this section includes three components:

(i) construction of 'source blocks' from source media packets belonging to one or several UDP packet flows.

UDP traffic may include, for example, RTP, RTCP, and SRTP packets and also other protocols related to the stream.

(ii) An optional extension to the source packet to indicate the source block and the position in the source block occupied by data from or relating to the source packet.

(iii) It can be used by the FEC decoder to reconstruct the missing part of the source block by the definition of the repair packet sent over UDP.

This mechanism does not impose any restrictions on the source data that can be protected together, except that the source data is carried over UDP. The data may come from several different UDP traffic that is jointly protected. Typically, a plurality of source blocks are constructed for one stream, each of which is constructed from a different set of source packets. For example, each source block may be constructed in time from those source packets that are related to a particular segment of the stream.

A receiver supporting such a streaming architecture should support the packet format of FEC source packets and should also support the packet format of FEC repair packets.

This section does not define how the sender determines which source packets are included in which source blocks. A particular content delivery protocol may define such a mapping, or it may be left as a relevant implementation at the sender. However, the CDP specification should define how the receiver determines how long it should wait to receive the FEC repair packets for any given source block.

At the sender, the mechanism processes the original UDP packet to create:

(i) one or more stored copies of the original packet in 'source block' form. The source block is a logical data block to which FEC codes will be subsequently applied. It is constructed by concatenating 'Source Packet Information (SPI)' of each source packet. Typically, the SPI of a packet contains a short identifier of the traffic to which the packet belongs, the length of the packet, the UDP payload and possibly padding bytes.

(ii) FEC source packets for transmission to a receiver.

The FEC streaming framework uses an FEC encoder specified by the FEC scheme to generate the desired amount of repair symbols from the source block. These repair symbols are then sent to the receiver using the FEC repair packet format. The FEC repair packet may be sent to a different UDP destination port than any of the destination ports of the original UDP packet indicated by the FEC streaming configuration information.

The receiver recovers the original source packets directly from any FEC source packets received. The receiver also uses the received FEC source packets to construct a stored copy of the original packets in the same source block format as constructed at the sender.

This copy of the source block at the receiver will be incomplete if any FEC source packets related to the given source block have been lost. If enough FEC source and FEC repair packets have been received in relation to the source block, the FEC framework may use the FEC decoding algorithm defined by the FEC scheme to recover a copy (desirably complete, but not necessarily) of the source block. The SPI for the missing source packet may then be extracted from the completed portion of the source block and used to reconstruct the source packet to be passed to the application.

Note that: the receiver may need to buffer the received source packets to allow time for the arrival of FEC repair packets and FEC decoding before some or all of the received or recovered packets are passed to the application. If such buffering is not provided, the application must be able to handle strict reordering of the packets that are needed. However, such buffering is a content delivery protocol and/or a dedicated implementation and is not specified here.

The receiver of the FEC source packet identifies the source block and the position within the source block occupied by the SPI derived from each packet. This information is referred to as FEC source packet identification information and may be conveyed in a variety of ways. The FEC source packet identification information may be encoded into a dedicated field within the FEC source packet format defined in the present specification, referred to as the source FEC payload ID field. The exact content and format of the source FEC payload ID field is defined by the FEC scheme. Alternatively, the FEC scheme or CDP may define how the FEC source packet identification information is derived from other fields within the source packet. This document defines the way in which the source FEC payload ID field, if used, is appended to the source packet to form an FEC source packet.

The receiver of the FEC repair packet should also be able to identify the source block and the relationship between the contained repair data and the original source block. This information is called FEC repair packet identification information. This information should be encoded into a dedicated field-the repair FEC payload ID field-the content and format of this field is defined by the FEC scheme.

Any FEC scheme used in connection with this specification should be systematic and should be based on the source block. The FEC scheme may define different FEC payload ID field formats for FEC source packets and FEC repair packets.

2.2.2 transmitter operation

It is assumed that the sender has constructed or received the original data packets of the session. These may be RTP, RTCP, MIKEY or other UDP packets. The following operations describe possible methods for generating compliant FEC source packets and FEC repair packet streams:

1. the source block is constructed by concatenating the SPIs of each original source packet as specified in section 2.3.2. By doing so, source FEC packet identification information for the FEC source packet may be determined and included in the source FEC payload ID field, if used. In the SPI, the identity of the UDP traffic of the packet is tagged with a short 'UDP traffic ID' as defined in the present specification. Associating the UDP traffic specification with the UDP traffic ID is defined by FEC streaming configuration information.

FEC source packets are constructed according to section 2.3.3. When carrying FEC source packets generated from an original stream of a particular protocol (e.g., RTP, RTCP, SRTP, MIKEY, etc.), the identity of the original traffic is maintained by the source packets using the same UDP port and IP address that has been advertised by the content delivery protocol (e.g., using DVB service discovery). The generated FEC source packets are transmitted according to conventional UDP procedures.

The FEC encoder generates repair symbols from the source block, and the FEC streaming framework places these symbols into FEC repair packets for delivery to the receiver. These repair packets are sent to the unique destination port using conventional UDP procedures in order to separate them from any of the source packet streams. The ports to be used for FEC repair packets are defined in the FEC streaming configuration information.

2.2.3 receiver operation

The following describes possible receiver algorithms when receiving FEC source or repair packets:

1. if an FEC source packet is received (as indicated by UDP traffic received over it):

a. the original source packet is constructed by removing the source FEC payload ID, if used. The resulting packet may be buffered to allow time for FEC repair.

b. The source FEC packet identification information is determined from the source FEC payload ID, if used, or from other means.

c. The SPI of the resulting packet is placed into the source block according to the source FEC packet identification information and the source block format described in section 2.3.2. The IP address and UDP port at which the packet is received/sent is used to determine the UDP traffic ID within the SPI.

2. If an FEC repair packet is received (as indicated by the UDP stream over which the packet was received), the repair symbols contained are associated with the source block according to the repair FEC payload ID.

3.FEC decoding may be desirable if at least one source packet is missed and at least one repair packet for a source block has been received. The FEC decoder determines whether the source block constructed in step 1 plus the associated repair symbols received in step 2 contain enough symbols to decode any or all of the missing source symbols in the source block and, if so, performs a decoding operation.

4. Any SPI that is reconstructed during the decoding operation is then used to reconstruct the missing source packet, and

these packets are buffered as conventionally received source packets (see step 1a above).

Note that: the above procedure may lead to a situation where not all of the original source packets are recovered.

Correctly received source packets, as well as those reconstructed, may be delivered to the application out of sequence and in a different order than the order of arrival at the receiver. Alternatively, reordering and reconstructing the source packets into the order in which they were placed into the source packets may require buffering and packet reordering if required by the application.

2.3Protocol specification

2.3.1Summary of the invention

This section specifies the protocol elements of the FEC streaming framework. The protocol includes three components described in the following sections:

1. construction of source blocks from a source packet. FEC codes may be applied to this source block to generate repair data.

2. The format of the packet containing the source data.

3. The format of the packet containing repair data.

The operation of the FEC streaming framework is controlled by specific FEC streaming configuration information. This configuration information is also defined in this section. The full protocol specification using this framework should specify the means for determining this information and communicating them between the sender and the receiver.

2.3.2Structure of source block

This clause defines the layout of the source blocks. The source block includes a concatenation of the SPIs of at least one original source UDP packet.

Order to

n is the number of UDP packets in the source block, which may be determined dynamically during the source block construction process.

Y is the source symbol size in bytes. Note that: this information is provided by the FEC scheme as defined in section 2.3.6.

R [ i ] denotes the octet of the UDP payload of the i-th UDP packet to be added to the source block, 0 ≦ i < n.

l [ i ] length of R [ i ] in octets.

Li indicates the two octets (first the high octet) of the value of L i expressed in network byte order

f [ i ] denotes an integer ' UDP traffic ID ' identifying UDP traffic for retrieving the ith packet '

Fi indicates a single octet representing the value of F i

s [ i ] is the smallest integer such that s [ i ] × T > - (l [ i ] + 3). Note that: s [ i ] is the length of SPI [ i ] in units of symbols.

P [ i ] denotes s [ i ] T- (l [ i ] +3) all zero octets. Note that: p i is a padding octet used to align the start of each UDP packet with the start of the symbol.

SPI [ i ] is the cascade of F [ i ], L [ i ], R [ i ] and P [ i ].

Subsequently, the source block is constructed by concatenating SPI [ i ] — i ═ 0, 2.. n-1. The source block size S is then given by sum { S [ i ] × T, i ═ 0.

The source block is identified by an integer source block number and the symbols within the source block are identified by an integer encoding symbol ID. This section does not specify how source block numbers are assigned to source blocks. Symbols are numbered consecutively starting from zero within the source block. Each source packet is associated with an encoding symbol ID containing the first symbol of the SPI for that packet. Thus, the encoding symbol ID value ESI [ j ] associated with the jth source packet is given by:

ESI [ j ] ═ 0, where j ═ 0

ESI [ j ] ═ sum { s [ i ], i ═ 0., (j-1) }, where 0 < j < n

The source FEC packet identification information includes the identity of the source block and the encoding symbol ID associated with the packet.

UDP traffic is uniquely defined by IP source and destination addresses and UDP source and destination port values. Assigning UDP traffic ID values to UDP traffic is part of the FEC streaming configuration information.

2.3.3 packet format for FEC Source packets

The packet format of the FEC source packet should be used to transport the payload of the original source UDP packet. As shown in fig. 3, it comprises the original UDP packet optionally followed by the active FEC payload ID field, if used.

The IP and UDP header fields should be the same as those of the original source packet. The original UDP payload field should be equal to the UDP payload of the original source packet. The UDP payload of the FEC source packet should include the original UDP payload followed by the active FEC payload ID field.

The source FEC payload ID field-if present-contains information required for the operation of the FEC algorithm, in particular when deriving source FEC packet identification information. The format of the source FEC payload ID and the derivation of the source FEC packet identification information are defined by the FEC scheme. Note that: the FEC scheme or CDP may define means for deriving FEC packet identification information from other information in the source packet (e.g., RTP sequence number). In this case, the source FEC payload ID field described herein is not appended to the packet, and the source FEC packet is identical in all respects to the original source packet.

2.3.4 packet format for FEC repair packets

The packet format of the FEC repair packet is shown in fig. 4. The UDP payload includes a repair FEC payload ID field and one or more repair symbols generated by the FEC encoding process. The repair FEC payload ID field contains information required for the operation of the FEC algorithm. This information is defined by the FEC scheme. The format of the repair FEC payload ID field is defined by the FEC scheme.

Any number of complete repair symbols may be included in the FEC repair packet subject to the packet size limit or other limit defined by the FEC scheme. The number of repair symbols within a packet may be determined based on the symbol length and the packet length. The partial repair symbols should not be included in the FEC repair packet.

2.3.5FEC streaming configuration information

The FEC streaming configuration information is information that the FEC streaming framework needs in order to apply FEC protection to UDP traffic. The full content delivery protocol specification for streaming using the framework specified herein should include details of how this information is derived and communicated between the sender and receiver.

The FEC streaming configuration information includes an identification of a plurality of UDP packet traffic. Each UDP packet traffic is uniquely identified by a tuple { source IP address, destination IP address, source UDP port, destination UDP port }.

A single instance of FEC-SF provides FEC protection for all packets of a given set of source UDP packet traffic via one or more UDP packet traffic containing repair packets. For each instance of FEC-SF, the FEC streaming configuration information includes:

1. an identification of UDP packet traffic carrying FEC repair packets, called FEC repair traffic.

2. For each source UDP packet traffic protected by FEC repair traffic:

a. carries an identification of the UDP packet traffic of the source packet.

b. Integer identifiers, for this traffic, between 0 and 255. This identifier should be unique among all source UDP packet traffic protected by the same FEC repair traffic.

FEC coding ID, FEC instance ID (if applicable) and optionally symbol size.

The above item (3) is included in the FEC object transmission information.

There may be multiple FEC-SF instances with separate and independent FEC streaming configuration information at the sender or receiver. A single FEC-SF instance protects all packets of all source UDP packet traffic identified in (2) above, i.e., all packets on these traffic should be FEC source packets as defined in section 2.3.3. A single source UDP packet traffic should not be protected by more than one FEC-SF instance.

A single FEC repair traffic provides repair packets for a single FEC-SF instance. Other packets should not be sent in this traffic, i.e. all packets in the FEC repair traffic should be FEC repair packets as defined in section 2.3.4 and should be related to the same FEC-SF instance.

The FEC-SF needs to be informed of the symbol size to be used for each source block. This information may be included in the FEC streaming configuration information or it may be communicated by other means-e.g. within the FEC repair payload ID field. The full content delivery protocol specification should specify how this information is communicated between the sender and the receiver.

2.3.6FEC scheme requirements

The preferred FEC scheme is systematic, based on discrete source blocks, specifies how the source block number and encoding symbol ID associated with a source packet are derived or passed from sender to receiver (e.g., within the source FEC payload ID field), and specifies how the symbol length is derived or passed from sender to receiver (e.g., as part of the FEC object transport information).

3.FEC scheme for streaming

3.1 MSCR FEC scheme for arbitrary packet traffic

This clause defines a FEC scheme for MSCR protection of arbitrary packet traffic over UDP.

3.1.1 Format and code

3.1.1.1FEC object transport information

3.1.1.1.1FEC object transport element

The FEC object transport element, FEC encoding ID is set to a predetermined value.

3.1.1.1.2 are common

For this scheme, the common FEC object transport information element and its value range are such that: maximum source block length of less than 2¹⁶Is not a negative integer-in units of symbols-and the code symbol size is less than 2¹⁶Non-negative integer of (a) — in bytes. The format of the encoded common FEC object transport information element may be the four-octet field defined in fig. 5.

3.1.1.2FEC payload ID

3.1.1.2.1 Source FEC payload ID

The source FEC payload ID may be as shown in fig. 6. There, the Source Block Number (SBN) (16 bits) is an integer identifier of the source block related to the source data within the packet, and the encoding symbol id (esi) (16 bits) is the starting symbol index of the source packet in the source block. The description of the code symbol identifier is defined by the FEC streaming framework (see section 2).

3.1.1.2.2 repair FEC payload ID

The structure of the repair FEC payload ID is defined in FIG. 7, where the Source Block Number (SBN) (16 bits) is the integer identifier of the source block associated with the repair symbols within the packet, the Encoding Symbol ID (ESI) (16 bits) is the integer identifier of the encoding symbols within the packet, and the Source Block Length (SBL) (16 bits) is the number of source symbols within the source block. The source block number, code symbol identifier, and source block length specifications may be as defined by the FEC code specification.

3.1.2 procedures

This FEC scheme uses the procedure of the framework defined in section 2 to construct source blocks to which FEC codes can be applied. The sender should assign source block numbers to the source blocks sequentially, wrapping back to zero after source block number 216-1. The sender should not construct source blocks larger than the largest source block signaled in the FEC object transport information.

3.1.3FEC code Specifications

The source blocks passed to the MSCR FEC encoder comprise source blocks constructed according to section 3.1.2, extended to have zero or more padding symbols such that the total number of symbols in the source block is equal to the maximum source block length signaled in the FEC object transport information (see section 3.1.1.1.2). Thus, the K value used by the encoded FEC is equal to the maximum source block length. The padding symbols may be bytes set to a value of zero.

The symbol size T to be used for source block construction and repair symbol construction is equal to the coding symbol size signaled in the FEC object transmission information (see section 3.1.1.1.2). The parameter T is set such that the number of source symbols in any source block is at most KMAX 8192.

Recommended parameters are given in section 3.1.3.3.

3.1.3.1 code packet construction

As described in section 2.3.4, each repair packet contains a Source Block Number (SBN), an encoding symbol id (esi), a Source Block Length (SBL), and repair symbols.

The number of repair symbols contained in the repair packet is calculated from the packet length. The ESI values placed into the repair packet and the repair symbol triples used to generate the repair symbols are calculated as described in subclause c.3.2.2 of [2 ].

The source block length field of the repair FEC payload ID field is set to the number of symbols included in the source packet information of the packet associated with the source block, i.e., before padding to the maximum source block length.

3.1.3.2 transfer

This subclause describes the exchange of information between the MSCR encoder/decoder and any transport protocol that streams with MSCR FEC.

The MSCR encoder for streaming uses the following information for each source block according to the transport protocol:

-symbol size in bytes T

-number of symbols K in source block

-Source Block Number (SBN)

Source symbols to be encoded-K.T bytes

For each repair packet, the MSCR encoder provides to the transport protocol encoded packet information comprising:

-Source Block Number (SBN)

Encoding Symbol ID (ESI)

-Source Block Length (SBL)

-repair symbols

The transport protocol conveys this information transparently to the MSCR decoder.

Suitable transport protocols are defined in this specification.

3.1.3.3 example parameters

3.1.3.3.1 parameter derivation algorithm

This section provides recommendations for the derivation of transport parameters T. This recommendation is based on the following input parameters:

b maximum Source Block size in bytes

P maximum repair packet payload size in bytes (excluding repair FEC payload ID), which should be a multiple of a.

-a symbol alignment factor in bytes

-K_MAXThe maximum number of source symbols per source block is as in [2]]KMAX 8192 as defined in (1).

-K_MINMinimum number of target symbols per source block

-G_MAXMaximum number of object symbols per repair packet

The requirement for these inputs is ceil (B/P). ltoreq.K_MAX. Based on the above inputs, the transport parameter T is calculated as follows:

in order to ensure that the water-soluble organic acid,

G＝min{ceil(P·K_MIN/B)，P/A，G_MAX} -number of appropriate symbols per packet

T＝floor(P/(A·G))·A

The above derived T values should be considered as a guide to the actual T values used. It may be beneficial to ensure that T divides up P, or it may be beneficial to set the value of T small to minimize losses when full-scale repair symbols are used to recover part of the source symbols at the end of a lost source packet (as long as the maximum number of source symbols in the source block does not exceed K)_MAX). Furthermore, the choice of T depends on the source packet size distribution, e.g., if all source packets are the same size, T is chosen such that the actual payload size of the repair packet P 'is equal to (or larger than with as few bytes as possible) the number of bytes each source packet occupies in the source block, where P' is a multiple of T.

For input parameter A, K_MINAnd G_MAXIs that a is 16, K_MIN＝640、G_MAX＝10。

3.1.3.3.2 example

At the assumption of A, K_MINAnd G_MAXIs a recommended value and P1424In this case, the above algorithm results in the delivery parameters as in table 3 below:

maximum source block size B G symbol size T G-T

16KB 10 128 1280

32KB 10 128 1280

128KB 7 192 1344

256KB 4 352 1408

Table 3: example parameter settings

3.2 MSCR FEC scheme for Single in-order packet traffic

This section defines an alternative FEC scheme for FEC protection of single packet traffic where the source packets each carry a unique sequence number. Such packet traffic is referred to as "in-order traffic". A primary example may be FEC protection of RTP traffic containing an MPEG-2 transport stream within which all data for a service is multiplexed. In this case, the RTP sequence number may be used to derive the source FEC packet identification information.

The main advantage of this scheme compared to the FEC scheme defined in section 3.1 is that it does not modify the source packets anyway. Thus, this FEC scheme can be used when there are legacy devices that cannot identify source packets that have been altered according to the scheme defined in section 3.1.

In this FEC scheme, the role played by the source FEC payload ID in the scheme of section 3.1 is replaced by a sequence number. The sequence number of the packet within each flow to be protected should be incremented by 1 for each packet in the flow.

The size of the source packet information within a given source block of each packet within a given ordered flow should be the same and derived from the size of the FEC repair packets, which should also be the same size for a given source block.

3.2.1 Format and code

3.2.1.1FEC object transport information

3.2.1.1.1 mandatory

This FEC scheme is identified by a predetermined FEC encoding ID.

3.2.1.1.2 are common

See section 3.1.1.1.2

3.2.1.1.3 special for scheme

There is no scheme-specific FEC object transport information defined by this FEC scheme.

3.2.1.2FEC payload ID

3.2.1.2.1 Source FEC payload ID

The source FEC payload ID field is not used by this FEC scheme. The source packets are not altered in any way by this FEC scheme.

3.2.1.2.2 repair FEC payload ID

The repair FEC payload ID format for this FEC scheme is shown in fig. 8. There, the initial sequence number (traffic ISN) is a 16-bit field that specifies the lowest 16 bits of the sequence number of the first packet to be included in this sub-block. If the sequence number is less than 16 bits, the received sequence number is logically padded with zero bits to form 16 bits in length accordingly. The encoding symbol id (esi) is a 16-bit field that indicates which repair symbols are contained within this repair packet. The ESI provided is the ESI of the first repair symbol in the packet. The Source Block Length (SBL) is a 16-bit field, which is the length of the source block in symbols.

3.2.2 procedures

This FEC scheme uses the procedure of the framework defined in section 2 to construct source blocks to which FEC codes can be applied. In addition to the programs defined herein, the following programs apply.

3.2.2.1 derivation of Source FEC packet identification information

The source FEC packet identification information for the source packet is derived from the sequence number of the packet and the information received in the repair FEC packet. The source block is identified by the sequence number of the first source packet in the block. This information is signaled in all repair FEC packets associated with the source block in the initial sequence number field.

The length (in bytes) of the source packet information of the source packet within the source block is equal to the length of the payload of the encoding symbols of the repair packet containing the block (i.e., no repair FEC payload ID is contained), and they should all be the same. The Source Packet Information Length (SPIL) in a symbol is equal to this length divided by the encoding symbol size (signaled in the common FEC object transport information).

The set of source packets included in a source block is determined according to an Initial Sequence Number (ISN) and a Source Block Length (SBL) as follows:

in order to ensure that the water-soluble organic acid,

i is the initial sequence number of the source block

L_PFor source packet information length in symbols

L_BFor source block length in symbols

Then, have a range from I to I + L_B/L_P-1 (and comprising I and I + L)_B/L_P-the source packet of the sequence number of 1) is included in the source block.

Note that: if no FEC repair packets are received, FEC decoding is not possible and no receiver is needed to identify the source FEC packet identification information for the source packet.

The coded symbol ID of a packet is derived from the following information:

sequence number N of packet_S

Source packetization information length LP of source block

Initial sequence number of source block I

Then, having a serial number N_SThe coded symbol ID of the packet of (a) is calculated according to the following formula:

ESI＝(N_S-I)·L_P

note that: all repair packets associated with a given source block should contain the same source block length, source packet information length, and initial sequence number.

3.2.2.2 derivation of repair Block coded symbol IDs

The coded symbol ID of the repair packet indicates which repair symbols the packet contains. This is directly given by the encoding symbol ID field of the repair FEC payload ID.

3.2.2.3 procedure for RTP traffic

Then, in the specific case of RTP packet traffic, the RTP sequence number field is used as the sequence number in the procedure described above.

3.2.3FEC code Specifications

The requirements of section 3.1.3 apply.

3.2.3.1 example parameters

3.2.3.1.1 parameter derivation Algorithm

The algorithm of section 3.1.3.3.1 is recommended.

Then, in case the RTP stream carries an MPEG-2 transport stream, the maximum repair packet size should be set to

P＝ceil((n·188+15)/A)·A

Where n is the nominal number of 188 bytes TS packets per IP source packet.

The maximum source block size is determined according to the application configuration at the sender.

3.2.3.1.2 examples

At the assumption of A, K_MINAnd G_MAXIn the case of the recommended value, the above algorithm results inTransport parameters for an MPEG-2 transport stream as in table 4 below:

maximum packet per guard period	Nominal TS packets per IP packet	Maximum packet size, P	Maximum source block size, B	G	Code element size T
						100	7	1344	134400	6	224
200	7	1344	268800	3	448
						300	7	1344	403200	2	672

4 common protocol element

This section defines a number of common protocol elements that can be used in conjunction with the framework defined in section 2 and the FEC scheme defined in section 3 to construct a full protocol for FEC protection of streaming media.

4.1FEC feedback protocol

4.1.1 summary

This section specifies an optional simple protocol for the receiver to provide feedback on the reception of FEC data in a unicast stream. This feedback data may be used by the transmitter to adjust the FEC parameters. Feedback on reception and decoding success or failure is provided for groups of source blocks, referred to as 'feedback groups'.

The capability to receive feedback must be advertised by the sender to the receiver along with the IP address and destination UDP port where the feedback should be sent and the requested size of the feedback group requesting the feedback.

Feedback is provided on a "best effort" basis-the sender should not rely on receiving feedback messages.

In this version of the protocol, a single feedback report message is provided that provides feedback on a single feedback group.

The following information is provided in each feedback report:

the number of source blocks in the feedback group

The number of source blocks received in the feedback group without errors

The number of successfully decoded source blocks in the feedback group

The number of source blocks in the feedback group that cannot be decoded

Maximum number of packets received by any source block in the feedback group

Minimum number of packets received by any source block in the feedback group

The total number of packets received in relation to this feedback

4.1.1 Format and code

4.1.2.1 general message format

The FEC feedback protocol message is sent over UDP along with a UDP payload formatted according to fig. 9. In such a message, the version field is set to zero (0) in this version of the protocol.

Message type:

0x00 feedback report

0x01-0xff Retention

Source block identifier:

the first source block in the group to which this report relates is identified. If the FEC scheme defines a source block number, this identifier is used as the source block identifier.

Number of source blocks:

this reports the number of source blocks reached.

Payload:

the content of the payload field depends on the message type and is defined below.

4.1.2.2 message payload Format

The format of the payload field of the feedback report is defined in fig. 10.

Number of "error free" blocks: indicating the number of source blocks in the feedback group that do not require decoding because all source packets were received without errors.

Number of blocks of "decoding success": indicating the number of source blocks in the feedback set that require decoding and complete successfully.

The number of blocks for which "decoding was unsuccessful: indicating the number of source blocks in the feedback group that require decoding but cannot be successfully completed because sufficient information has not been received.

Maximum received packet: indicating the maximum number of packets (source and repair) received for any source block in the feedback group.

Minimum received packet: indicating the minimum number of packets (source and repair) received for any source block in the feedback group.

The total number of packets received indicates the total number of packets (source and repair) received for all source blocks in the feedback group.

4.1.3 procedures

4.1.3.1FEC sender program

This section defines the procedures at the device that is sending FEC protected data and receiving FEC feedback protocol data.

4.1.3.1.1 outline

Support for the FEC feedback protocol at the sender is optional. The sender advertises in the FEC streaming configuration information the support of the FEC feedback protocol, the highest version supported, the IP destination address and UDP destination port to which the message should be sent, and the size of the requested feedback group. The mechanism for communicating FEC streaming configuration information is a dedicated content delivery protocol.

The FEC transmitter may ignore received FEC feedback protocol packets with a version number that is not acknowledged and received FEC feedback protocol packets with a reserved message type.

In case a FEC feedback protocol message is received that is longer than expected, the sender should discard the additional bytes and process the message as usual.

4.1.3.1.2 reception of feedback report message

Upon receiving the feedback report message, the FEC transmitter may adapt the FEC parameters (source block size, transmission rate and arrangement, etc.) for the subsequent source blocks based on the information received in the feedback report message.

In the case of a feedback group of a single source block size, and if

The feedback report indicates that the source block was successfully received or successfully decoded, and

the FEC sender is still sending FEC repair packets for the source block,

the FEC transmitter should stop transmitting the FEC repair packets of the source block.

4.1.3.2FEC receiver program

This section defines the procedure at a device that is receiving FEC protected data and sending FEC feedback protocol data.

4.1.3.2.1 outline

Support for the FEC feedback protocol at the receiver is optional.

The FEC receiver should not send FEC feedback protocol messages if support for FEC feedback protocol has not been advertised by the FEC transmitter.

If support for the FEC feedback protocol has been advertised by the FEC transmitter, the FEC receiver may use information in the FEC streaming configuration information to determine the highest version supported by the FEC transmitter, the IP destination address and UDP destination port to which the message should be sent, and the size of the feedback group.

The FEC receiver should not send FEC feedback protocol messages with a version number higher than the highest version supported by the FEC transmitter.

The FEC receiver should determine whether the FEC feedback protocol is to be used on a per FEC streaming frame instance basis. The feedback groups should include a sequence of consecutive source blocks, except that source blocks for which no repair packets are received should not be included in any feedback group. The number of source blocks in a feedback group should be equal to the requested feedback group size indicated in the FEC streaming configuration information.

Each source block in the feedback group should be classified as either "error free", "decoding successful", or "decoding unsuccessful", as described in the following sections.

Once the classification of all source blocks in the feedback group is determined, the FEC receiver should send a feedback report message.

4.1.3.2.2 source block without error

Once the FEC receiver determines that FEC decoding of the source block is not required, the source block may be considered "error free".

4.1.3.2.3 successful decode Source Block

Once a source block is successfully decoded, the source block may be considered "decoding successful".

4.1.3.2.4 "decode unsuccessful" source block

Once the FEC receiver determines that FEC decoding of the source block is necessary but not possible, the source block may be considered "decoding unsuccessful". The FEC receiver may determine that FEC decoding of the source block is necessary, but not possible in the following cases:

at least one source symbol of the source block is unknown,

sufficient repair symbols have not been received for decoding the source block, an

Application requires a source symbol (e.g., media player).

The FEC receiver may determine that FEC decoding of the source block is necessary, but is not possible at other times, e.g., if other repair symbols for the source block have not been received within a certain time period as determined by the FEC receiver.

4.2FEC Transmit arrangement

The FEC streaming framework defined in section 2 does not specify any arrangement of transmitted packets. This section describes approaches that can be used by a transmitter to determine the FEC source for a stream and the transmission arrangement of FEC repair packets.

4.2.1 simple constant Rate FEC Transmission

This section describes a simple transmission arrangement where the transmission rate of FEC source packets and FEC repair packets in each source block remains constant.

For each source block, a source packet is sent first, followed by a repair packet. All packets of one source block are sent before any packets of a succeeding block.

The transmit data rate for all data in the source block (source and repair) is constant and is given by the following equation:

wherein:

R_sendingIs the sending rate

R_SourceIs the source data rate

D_RepairIs the repair data amount (bytes, including packetization overhead)

D_SourceIs the amount of source data (bytes, including packetization overhead)

4.3 determining FEC source block boundaries

This section presents a number of algorithms that can be used by the transmitter to determine FEC source block boundaries.

4.3.1 based on the guard period

In this approach, the source blocks are constructed based on a time period called a "guard period". Typically, the guard period is the same for each source block of a stream. However, it may vary from block to block.

In the case of real-time streaming, the source packets of a source block are exactly those that arrive within a time period equal to the guard period.

In the case of pre-encoded content, the source packets of a source block are exactly those packets that will be transmitted within a period of time equal to the protection period in a conventional transmission arrangement of a non-FEC protection stream generated from the content.

In this approach, packets are buffered at the receiver for at least the same time as the longest playout time of any source block, using the transmission arrangement of section 4.2.1 and elsewhere.

5 content delivery protocol

This section utilizes the components defined in sections 2-4 to define several full content delivery protocols.

5.1 multicast MPEG-2 transport streams

This section defines the content delivery protocol for FEC protected multicast delivery for MPEG-2 transport streams.

5.1.1 control protocol

The session information includes:

destination UDP Port per repair traffic

IP multicast address per repair traffic in case multiple repair traffic layers are provided

In the case where multiple repair traffic layers are provided, the order of joining of repair traffic

FEC object transport information (maximum source block size and code symbol size)

Minimum buffer time required at the receiver

The flow ID of the MPEG-2TS flow is zero.

5.1.2 transport protocol

FEC protection for MPEG-2 transport streams may be provided using:

the FEC streaming framework described in section 2

FEC scheme defined in section 3.3

FEC Transmit arrangement as described in 4.2.1

FEC Source Block boundary identification mechanism described in 4.3.1

Each MPEG-2 transport stream should be protected independently.

5.2 unicast MPEG-2 transport streams

This section defines a content delivery protocol for FEC protected unicast delivery of MPEG-2 transport streams.

5.2.1 control protocol

The session information may include:

Minimum buffer time required at the receiver

Requested FEC feedback group size (or zero if no feedback is required)

Repair FEC traffic associated with unicast RTP traffic may be sent to a destination UDP port number that is 2 port number greater than the destination UDP port to which the RTP traffic is sent.

The flow ID of the MPEG-2TS flow is zero.

If FEC feedback is required by the sender and supported by the receiver, an FEC feedback message may be sent to the address/UDP port used as the source address/port for the FEC repair stream from the server to the receiver.

5.2.2 transport protocol

FEC protection for MPEG-2 transport streams may be provided using:

the FEC streaming framework described in section 2

FEC scheme defined in section 3.3

FEC Transmit arrangement as described in 4.2.1

FEC Source Block boundary identification mechanism described in 4.3.1

Each MPEG-2 transport stream should be protected independently.

5.3 generic multicast video

This section defines the content delivery protocol for FEC protected multicast delivery of arbitrary audio/video streams (e.g., h.264 encapsulated in RTP). This section is provided to describe how FEC can be applied to future extensions of the DVB IPI manual for direct encapsulation of audio/video streams in RTP.

5.3.1 control protocol

The session information includes:

destination UDP Port per repair traffic

IP multicast address, UDP destination port number, and traffic ID of protected UDP traffic (e.g., audio and video traffic).

Minimum buffer time required at the receiver

5.3.2 transport protocol

The audio/video stream is assumed to be carried by one or more UDP traffic (likely RTP traffic).

FEC protection for these UDP traffic may be provided using the following

The FEC streaming framework described in section 2

FEC scheme as defined in section 3.1

FEC Transmit arrangement as described in 4.2.1

FEC Source Block boundary identification mechanism described in 4.3.1

5.4 generic unicast video

This section defines the content delivery protocol for FEC protected unicast delivery of arbitrary audio/video streams (e.g., h.264 encapsulated in RTP). This section is provided to describe how FEC can be applied to future extensions of the DVB IPI manual for direct encapsulation of audio/video streams in RTP.

5.4.1 control protocol

The session information includes:

destination UDP port of repair traffic

UDP destination port number and traffic ID of protected UDP traffic (e.g., audio and video traffic).

Minimum buffer time required at the receiver

FEC feedback group size (or zero if no FEC feedback is required)

5.4.2 transport protocol

FEC protection for these UDP streams may be provided using the following

The FEC streaming framework described in section 2

FEC scheme as defined in section 3.1

FEC Transmit arrangement as described in 4.2.1

FEC Source Block boundary identification mechanism described in 4.3.1

FEC streaming recommendation

This section provides some other optional suggestions for using the above FEC streaming protocol in a DVB environment.

6.1 multicast

6.1.1 layered FEC Transmission (optional)

The sender may advertise more than one IP multicast address for repair packets associated with a single source stream. The sender should send a different repair packet for each multicast group.

The receiver may join any number of such multicast groups to adjust the rate of received repair packets according to the local error rate.

It should be noted, however, that in order to meet IPTV quality objectives, sufficient overhead must be received to overcome even relatively few error events, and thus the receiver should measure the error rate over a sufficiently long period of time in order to determine the amount of repair data required.

6.2 unicast

6.2.1 Source Block construction at the beginning of stream (optional)

The source block boundaries should be identified using the guard period algorithm defined in section 4.4.1. The following algorithms are recommended to determine the protection period, FEC overhead and sending rate to be used at any time a new stream is played out, e.g. at the start of a stream or when using trick (puck) mode. This algorithm will evenly distribute the initial available bandwidth over the source rate between the FEC repair data and the fast buffer fill data. The initial available bandwidth may be larger than the nominal (long-term) bandwidth or it may be equal, but should not be smaller.

In order to ensure that the water-soluble organic acid,

B_maxis the initial bandwidth (source and FEC) available to the stream

B_nomFor nominal bandwidth of the stream (source and FEC)

B_srcSource bandwidth

P_initDelay for initial buffering

P_final(P_{Finally, the}) For a target protection period

P is the ith guard period, where i is 0, 1.

S_initSending a rate for an initial source

R_initSending a rate for initial repair

Then the process of the first step is carried out,

R_init＝B_max-S_init

and, for all i, let P_i＜P_finalThen, then

And for all i, let P_i＞＝P_final

P_i+1＝P_i

For durations less than P_finalThe source transmission rate should be Sinit and the repair transmission rate Rinit. After that, the source sending rate should be reduced to Bsrc. This arrangement means that during the initial period the source transmission rate is greater than the actual source data rate, whereby each guard period contains data that will be played out longer than it will take to transmit. As a result, the subsequent guard period can be made longer without starving the receiver of packets according to the above algorithm.

The minimum buffering time should be Pinit at the receiver advertised in the service discovery information.

6.2.2 use of FEC feedback (optional)

FEC feedback may be used on a long-term basis to adjust the FEC overhead provided to individual users. It should be noted, however, that in order to meet IPTV quality objectives, sufficient overhead must be provided to overcome even relatively error-less events, and thus feedback data collected over a short period of time is insufficient to determine the required long-term overhead.

In case the guard period is significantly longer than the IP round trip time between sender and receiver, then the feedback set of a single source block may require FEC feedback. In this case, the feedback report may be used to forgo sending FEC repair packets for the source block in the received report indicating that this source block has been successfully received/decoded.

While the invention has been described with reference to exemplary embodiments, those skilled in the art will recognize that many modifications are possible. For example, the methods and processes described herein may be implemented using hardware components, software components, and/or any combination thereof. Thus, while the invention has been described with reference to exemplary embodiments, it will be appreciated that the invention is intended to cover all modifications and equivalents falling within the scope of the appended claims.

Claims

1. A communication system for streaming data, wherein data is streamed from a transmitter to a receiver so that the receiver can start using the streamed data before it is all received or transmitted, the transmitter comprising:

a module for encoding a forward error correction "FEC" of said data to be transmitted,

whereby the transmitted stream comprises data and FEC information, and the data is transmitted using a transmission rate that is greater than a consumption rate of the receiver,

wherein streaming is performed over a plurality of guard periods, and wherein the source transmission rate is reduced from the initial source transmission rate to the source bandwidth for a guard period after the target guard period.

2. A communication system for streaming data, wherein data is streamed from a transmitter to a receiver so that the receiver can start using the streamed data before it is all received or transmitted, the transmitter comprising:

the stream thus transmitted includes data and FEC information;

means for timing a transmission such that, for at least a portion of the transmission, an input rate of the transmitter is greater than a consumption rate of the receiver; and

means for varying the amount of excess FEC and/or the input rate with time of streaming transmission.