CN101405942A

CN101405942A - 使用可变fec开销和保护周期的流送和缓冲

Info

Publication number: CN101405942A
Application number: CNA2007800100328A
Authority: CN
Inventors: M·沃森; M·G·卢比
Original assignee: Digital Fountain Inc
Current assignee: Digital Fountain Inc
Priority date: 2006-02-13
Filing date: 2007-02-13
Publication date: 2009-04-08

Abstract

数据是从传送器流送到接收器，其中流送是在假定接收器将在数据被全部传送和接收之前开始使用该数据的情况下输送数据的，并且所流送的数据包括前向纠错(“FEC”)，且数据消耗速率可变化。传送器具有输入速率和传送速率，且这两个速率可以是不同的并且可改变。在接收器处，有接收速率(接收器以此速率接收数据)和消耗速率(接收器以此速率用尽数据以进行其输出)。传送器使用比消耗速率大的传送速率进行传送，并且额外的带宽可用于FEC保护和缓冲。在某些实施例中，超额速率随传输周期改变。

Description

使用可变FEC开销和保护周期的流送和缓冲

交叉引用

本申请是2006年2月13日提交的美国临时专利申请No.60/773,185和2006年2月14日提交的美国临时专利申请No.60/773,501的非临时申请并要求它们的优先权。

以下引用并通过出于所有目的的引用被纳入并结合于此：

授予Luby的题为“Information Additive Code Generator and Decoder forCommunication Systems(用于通信系统的信息附加码生成器和解码器)”(在下文中为“Lubty”)的美国专利No.6,307,487；以及

授予Shokrollahi等人的题为“Multi-Stage Code Generator and Decoderfor Communication Systems(用于通信系统的多级码生成器和解码器)”的美国专利No.7,068,729(在下文中称为“Shokrollahi”)。

发明领域

本发明涉及编码和解码通信系统中的数据，尤其涉及编码和解码数据以解决所通信的数据中的差错和间隙，同时应付接收器在接收到数据时快速地提供该数据的需求的通信系统。

发明背景

发送者与接收者之间的文件和流在通信信道上的传输已成为众多文献的主题。较佳地，接收者期望在某一级别的确定性下接收由发送者通过信道传送的数据的正确副本。在信道不具有理想保真度(这包括几乎所有在物理上可实现的系统)的情况下，所关心的是如何处理传输中丢失和混淆的数据。丢失的数据(擦除)通常较遭破坏的数据(差错)更容易处理，因为接收者在遭破坏的数据被错误地接收到时并不总是能够进行辨认。已开发出许多纠错码来纠正擦除和/或差错。

当传送器与接收器具有通信所需的所有计算能力和电功率且传送器与接收器之间的信道足够干净以允许相对无差错的通信时，数据传输是简单的。当信道处于不利环境或传送器和/或接收器具有有限的能力时，数据传输问题变得比较艰难。

一种解决方案是使用前向纠错(FEC)技术，其中数据在传送器处被编码，以使得接收器能从传输擦除和差错中恢复。在可行的情况下，从接收器到传送器的反向信道允许接收器向传送器就差错进行传达，该传送器随后可相应地调节其传输过程。然而，反向信道常常不可用或不可行，或者仅有限的能力可用。例如，在传送器向大量接收器传送时，传送器不能处置来自所有这些接收器的反向信道。结果，通信协议常常需要被设计成没有反向信道或具有有限容量的反向信道，这样，传送器可能必须处理宽泛变化的信道状况而不具有对这些信道状况的全面概观。

在用于可能丢失分组的信道上的数据输送的分组协议的情形中，要在分组网络上传送的文件、流或其它数据块被划分成均匀大小的输入码元，使用FEC码来从输入码元生成与这些输入码元相同大小的编码码元，并且在分组中放置并发送编码码元。码元的“大小”可以比特来度量，无论码元实际上是否被分割成比特流，其中当码元是选自2^M个码元的字母表时，一个码元具有M比特的大小。在此类基于分组的通信系统中，面向分组擦除的FEC编码方案可能会是合适的。如果文件传输允许预期接收者恢复原始文件的正确副本——即使面临网络中的擦除时亦是如此——则该文件传输被认为是可靠的。如果流传输允许预期接收者及时地恢复流的每个部分的正确副本——即使面临网络中的擦除时亦是如此——则该流传输被认为是可靠的。在流的某些部分不能被及时恢复的情况下文件或流的某些部分不能恢复或者进行流送这种意义上来说，文件传输和流传输两者可能多少还是可靠的。通常因突发拥塞导致路由器中的缓冲机构达到其容量从而强制其丢弃传入分组而发生分组丢失。对抗输送期间的擦除的保护已成为众多研究的主题。

在用于会破坏比特的嘈杂信道上的数据传输的协议的情形中，要在数据传输信道上传送的数据块被划分成均匀大小的输入码元，从这些输入码元生成相同大小的编码码元，并且这些编码码元通过该信道被发送。对于此类嘈杂信道，码元的大小典型为一比特或几个比特，无论码元实际上是否被分割成比特流。在此类通信系统中，面向比特流纠错的FEC编码方案可能是合适的。如果数据传输允许预期接收者恢复原始块的正确副本——即使面临差错(信道中或者被检测到或者未被检测到的码元破坏)时亦是如此——则该数据传输被认为是可靠的。在恢复之后块的某些部分可能仍保留为遭破坏的这个意义上来说，输出多少也还是可靠的。码元通常遭到突发噪声、周期性噪声、干扰、弱信号、信道中的堵塞以及各种其它原因的破坏。

某些FEC码的一个问题在于，它们要求过量的计算能力或存储器来操作。另一个问题在于，输出码元的数目必须在编码过程之前被确定。如果高估分组丢失率，则这会导致低效率，而如果低估分组丢失率，则会导致失败。

链式反应码是允许从文件或流的固定输入码元生成任意数目的输出码元的FEC码。有时，它们被称为喷泉或无比率码，因为该码不具有先验固定传输速率，并且可能的输出码元的数目可能与输入码元的数目无关。例如，在Luby和Shokrollahi中示出了用于生成、使用或操作链式反应码的新颖技术。

还应当知道使用多级链式反应(“MSCR”)码，诸如在Shokrollahi中所描述以及由Digital Fountain(数字方敦)股份有限公司在商标“Raptor”码下开发的那些。例如，在接收来自源文件或源流的输入码元、从输入码元生成中间码元且这些中间码元作为链式反应编码器的源码元的编码器中使用多级链式反应码。

对于某些应用，这些码的其它变体可能是更合适或较佳的。如本文中所用的，输入码元指接收自文件或流的数据，而源码元指用于生成输出码元的码元。在某些情形中，源码元包括输入码元，而在某些情形中，源码元是输入码元。然而，存在输入码元被编码和/或转换成中间码元集合且此中间集合用于生成输出码元而不涉及输入码元(直接)的情形。因而，输入码元包括为与接收器通信的发送器所知的信息，源码元是被编码器的至少一个级使用并从输入码元导出的码元，而输出码元包括由发送器传送给接收器的码元。

在某些应用中，接收器可在传输完成之前开始使用数据。例如，在视频请求(video-on-demand)系统中，接收器可在仅接收到很少一部分视频数据之后开始播出视频，并假定其余视频数据将在其被需要之前被接收到。在此类系统中，编码不应当在整个传输上进行，因为在传输末端的某些输出码元可能对视频起始处所需的输入码元进行编码，在此情形中那些输出码元是浪费的，因为其信息在它不可用时需要，而在它可用时不需要。为了避免这种情况，数据流通常被分割成块，其中块的输入数据在下一块准备好之前被编码并发送，并且这些块通常不依赖于这些块之外的输入码元。

对于此类应用，常常存在可靠性与传输何时开始和数据何时可开始被使用两者间的滞后时间之间的权衡。例如，如果整个正片长度电影被编码以使得传输开始处的差错可使用传输结束处的数据来纠正，则接收器可能在向应用(或者应用的用户)指示电影可进行回放之前将进行等待直至它接收到所有电影数据。然而，在传输总时间很长时，可能有无法接受的滞后时间。

一种解决方案是编码数据流以使得接收器在某一较小的滞后时间之后具有足以开始回放电影的信息，而接收器可能期望及时接收进一步信息以继续回放。当然，如果接近传输末端的数据提供了对传输开始处的数据的冗余，则由于电影的第一部分被回放将远远早于后一信息被接收而浪费了该能力。因而，通常使得在有需要时可用的冗余在时间上靠近数据的解码是有效的。然而，如果约束过于苛刻，则回放可能必须过早地开始，并且引发接收器遭遇电影中其还不具有足以进行解码的数据的回放点的可能性并可能导致跳跃或暂停。

在使用块的情况下存在这样的权衡：块大小过小，则没有提供足够的差错保护，而块大小过大，则接收器在等待要被完全恢复的块时经历过多的延迟。

发明概要

在本发明的实施例中，数据被从传送器流送到接收器，其中流送是在假定接收器将在数据被全部传送和接收到之前开始使用数据的情况下输送数据。所流送的数据包括前向纠错(“FEC”)且数据消耗的速率可变化。传送器具有输入速率——在该速率下用尽输入数据——以及传送速率——以该速率发送此数据(以及按需的FEC数据)，并且这两个速率可以是不同的，且因此当涉及FEC时会改变，因为伴随FEC编码有某种开销。在接收器处，有接收速率(接收器按其接收数据)和消耗速率(接收器按其用尽数据以进行其输出)。传送器使用比消耗速率大的传送速率进行传送，并且额外的带宽可用于FEC保护和缓冲。

在某些实施例中，该超额速率随传输周期改变。

对本文所公开的本发明的特征和优点的进一步理解可通过参考说明书和附图的剩余部分来实现。

附图简述

图1是可使用本文所描述的可变FEC开销技术的通信系统的框图。

图2是FEC流送框架架构的示图。

图3是FEC源分组的示图。

图4是FEC修复(repair)分组的示图。

图5是FEC对象信息块的示图。

图6是源FEC有效载荷ID格式的示图。

图7是修复FEC有效载荷ID格式的示图。

图8是替换性修复FEC有效载荷ID格式的示图。

图9是FEC反馈协议消息格式的示图。

图10是成功报告消息的有效载荷格式的示图。

发明详细描述

在本发明的实施例中，数据被从传送器流送到接收器，其中流送是在假定接收器将在数据被全部传送和接收到之前开始使用数据的情况下输送数据。所流送的数据包括前向纠错(“FEC”)，后者提供了对重传-请求方案——其中如果检测到分组丢失则由接收器请求重传丢失分组——的改进。

在流送过程中涉及各种速率。所流送的数据包括前向纠错(“FEC”)且数据消耗的速率可变化。传送器具有输入速率——以该速率用尽输入数据——以及传送速率——以该速率发送此数据(以及按需的FEC数据)，并且这两个速率可以是不同的，且因此当涉及FEC时可改变，因为涉及FEC编码的情况下有某种开销。在接收器处，有接收速率(接收器以该速率接收数据)和消耗速率(接收器以该速率用尽数据以进行其输出)。在信道上不存在数据丢失时，接收速率与传输速率相同。存在原始接收速率，该接收速率是在不计入由于FEC的开销的情况下数据被接收的速率。例如，如果接收器是向显示设备输出11兆/秒(MBS)视频流的视频播放器，则消耗速率是11MBS。在显示器、音频、处理器或其它数据播放器上播出所消耗的数据时，消耗速率可称为“播出(playout)”速率。

在有许多流的情况下，使消耗连续进行以使得所流送的数据的呈现不会停止或阻滞——如果接收器处的所有数据被消耗且接收速率小于消耗速率时会发生这种停止和阻滞——是合需的。为了避免这种情况，接收器通常具有缓冲器以使得接收速率可暂时跌至消耗速率之下(由于分组丢失、拥塞等)却又未用尽要被消耗的数据。

当接收速率恰好是消耗速率时，没有要被缓冲的额外数据。为了填充接收器的缓冲器，流送系统可被设置成使得传输速率高于消耗速率，或者传输在播出开始之前启动。在任一情形中，有充分的接收以便至少部分地填充接收器缓冲器。

在任一情形中，使用FEC而非重传常常是较好的办法。在使用重传的情况下，在接收器发送重传请求并接收响应时，需要有足够的接收器缓冲器来继续播出数据，否则播放器在到达尚待还原的错失数据时将停止。

在具体实施例中，传送器使用大于消耗速率进行传送，并且额外的带宽被部分用于FEC保护且部分用于缓冲器填充以允许诸如“快速开始”的特征，此时可在缓冲器充分填充的情况下在接收开始之后立即开始播出，从而降低停止播出的风险。

在某些实施例中，用于FEC保护的带宽和用于缓冲填充的开销量随时间变化。例如，整体传输比特率可以是略高于消耗速率的恒定值，其中超出量在传输开始时较多地用于缓冲器填充而在后续时间较少地用于缓冲器填充。使用恒定比特率时，FEC保护在传输开始时将较少而在稍后的时间将较多。不需要恒定的比特率，并且可使用恒定的FEC开销。

综述

在以下针对包括DVB-IPI应用的应用描述了使用多级链式反应(MSCR)码的流送媒体的FEC保护的协议——诸如由DF Raptor^TM编码器和解码器所用的那些。在Shokrollahi中描述了这种多级码的示例。应当理解，本公开的目的在于，MSCR码仅用作多级码的示例，而本公开的示教可与除Shokrollahi中所述的那些之外的多级码联用。

多级码可用于DVB-IPI实时应用(使用MPEG-2输送流封装以及音频和视频在RTP上的直接传输两者的多播和单播)的FEC保护。

由IETF可靠多播工作组定义的FEC构建块[3]描述了一种使用FEC的协议规范的办法，该规范将协议的定义与FEC码本身的规范分隔开。这使得协议设计问题能够独立于极为不同的FEC码选择问题来解决。在FEC构建块的术语中，提供了用于“内容递送协议”和用于“FEC方案”的单独规范，前者定义了协议而后者定义了实际FEC码。FEC构建块描述了这样的规则：两种类型的规范都必须遵循以使得它们可一起使用，并由此提供内容递送协议与FEC方案之间的“粘合(glue)”。

根据这种办法，此规范被组织成多个模块化组件。随后，这些组件被组合以形成适于DVB-IPI应用的完整协议。这些组件包括：(1)FEC流送框架，它为将FEC应用到媒体流提供整体协议框架，并在第2章节中进行描述；(2)多个FEC方案，它们定义了适于各类应用的协议组件并定义了如何将核心MSCR码应用于流送应用，在第3章节中进行描述；(3)模块化协议组件，它可用于支持基于在此所定义的FEC流送框架和FEC方案的应用，在第4章节中示出；以及(4)用于使用MPEG-2输送流封装以及音频和视频在RTP上的直接传输两者的多播和单播视频的协议规范，它使用上述构建块来构造(第5章节)。

术语和缩略词

术语/缩略词	定义/描述
术语/缩略词	定义/描述	包	被集合成单个源块并用于生成单个修复码元流的流(又称为流量)集合。例如，低比特率音频流可与高比特率流一起打包，从而提供较未被打包的情况下更好的FEC保护。
流量	用于“流”的另一术语，用在包的上下文中。	包
流量	用于“流”的另一术语，用在包的上下文中。	中间块	从原始源块数据导出的数据块——在MSCR编码器的情形中，或者接收到的源码元和修复码元的组合——在MSCR解码器的情形中。
修复码元	由MSCR编码器生成的码元，该码元是从源码元导出的。	中间块
修复码元	由MSCR编码器生成的码元，该码元是从源码元导出的。	源块	源数据的块，MSCR编码器提供该块上的FEC修复信息。
源码元	来自源块的数据单元。源块中的所有源码元是相同大小的。	源块	源数据的块，MSCR编码器提供该块上的FEC修复信息。
源码元	来自源块的数据单元。源块中的所有源码元是相同大小的。	FEC	前向纠错。
编码码元	源码元或修复码元。	FEC	前向纠错。
编码码元	源码元或修复码元。	源分组信息(SPI)	包括在与源分组有关或来自其的源块中的信息。
FEC流送配置信息	控制FEC流送框架的操作的信息。	源分组信息(SPI)	包括在与源分组有关或来自其的源块中的信息。

表2-术语和缩略词

编码器和解码器

图1是使用多级编码且可使用本文所描述的可变FEC开销技术的通信系统100的框图。

在通信系统100中，输入文件101或输入流105被提供给输入码元生成器110。输入码元生成器110从输入文件或流生成一个或多个输入码元(IS(0)、IS(1)、IS(2)、...)的序列，并且每个输入码元具有值和位置(在图1中标示为括号内的整数)。如上所说明的，输入码元的可能值——即其字母表——通常是2^M个码元的字母表，以使得每个输入码元码对输入文件的M个比特编码。M值通常是根据通信系统100的使用来确定的，但是通用系统可包括对应于输入码元生成器110的码元大小输入以使得M可随使用的不同而不同。输入码元大小生成器110的输出被提供给编码器115。

静态密钥生成器130产生静态密钥流S₀、S₁、....。所生成的静态密钥的数目通常是有限的，并取决于编码器115的具体实施例。将在随后更详细地描述静态密钥的生成。动态密钥生成器120为将由编码器115生成的每个输出码元生成动态密钥。每个动态密钥被生成为对于相同输入文件而言大部分动态密钥是唯一的。例如，Luby I描述了可被使用的密钥生成器的实施例。动态密钥生成器120和静态密钥生成器130的输出被提供给编码器115。

根据由动态密钥生成器120提供的每个密钥I，编码器115从由输入码元生成器提供的输入码元生成具有值B(I)的输出码元。将在以下更详细地描述编码器115的操作。每个输出码元的值是基于其密钥、输入码元的一个或多个的某些函数、以及可能已从输入码元计算出的一个或多个冗余码元来生成的。产生特定输出码元的输入码元和冗余码元的集合在此称为输出码元的“相关联码元”或简单地称为其“关联物(associate)”。函数(“价值函数”)和关联物的选择是根据在以下更详细描述的过程来进行的。通常，对于输入码元和输出码元而言，M是相同的，即它们两者是相同比特数目的码，但并非总是如此。

在某些实施例中，输入码元的数目K被编码器115用来选择关联物。如果K并非提前已知，诸如输入是流送文件时，则K可以仅是估计。值K也可被编码器115用来将存储分配给输入码元和由编码器115生成的任何中间码元。

编码器115将输出码元提供给传送模块140。还将来自动态密钥生成器120生成的每个此类输出码元的密钥提供给传送模块140。传送模块140传送输出码元，并且取决于所用的密钥控制(keying)法，传送模块140还可在信道145上向接收模块150传送关于所传送的输出码元的密钥的某些数据。信道145被假定为擦除信道，但是对于通信系统100的适当操作而言，这并非是必需的。模块140、145和150可以是任何合适的硬件组件、软件组件、物理介质、或其任何组合，只要传送模块140适于向信道145传送输出码元和任何所需的关于其密钥的数据，且接收模块150适于从信道145接收码元和潜在可能的某些关于其密钥的数据。如果用于确定关联物，则值K可通过信道145发送，或者可通过编码器115与解码器155之间的协定提前被设置。

如上所说明的，信道145可以是实时信道，诸如通过因特网的路径或从电视传送器到电视接收者的广播链路或从一个点到另一点的电话连接，或者信道145可以是诸如CD-ROM、盘驱动、网站等的存储信道。信道145甚至可以是实时信道和存储信道的组合，诸如在个人通过电话线路自个人计算机向因特网服务提供商(ISP)传送输入文件时形成的信道，该输入文件被存储在Web服务器上并在随后通过因特网传送给接收者。

由于信道145被假定为擦除信道，因此通信系统100并不假定离开接收模块150的输出码元与进入传送模块140的输出码元之间一对一地对应。实际上，在信道145包括分组网络时，通信系统100甚至不能假定任何两个或多个分组的相对次序在通过信道145传送时得以保持。因此，输出码元的密钥是使用上述密钥控制方案的一个或多个来确定的，而并非一定根据输出码元离开接收模块150的次序来确定。

接收模块150向解码器155提供输出码元，而接收模块150接收到的关于这些输出码元的密钥的任何数据被提供给动态密钥再生器160。动态密钥再生器160再生接收到的输出码元的动态密钥，并将这些动态密钥提供给解码器155。静态密钥生成器163再生静态密钥S₀、S₁、...并将它们提供给解码器155。静态密钥生成器访问用在编码和解码过程两者期间的随机数生成器135。如果随机数是在相同的物理设备上生成，则这可以是访问此设备的形式的访问，或者是访问随机数生成的相同算法的形式以实现同样的行为。解码器155使用由动态密钥再生器160和静态密钥生成器163提供的密钥连同相应的输出码元一起来恢复输入码元(仍为IS(0)、IS(1)、IS(2)、...)。解码器155将已恢复的输入码元提供给输入文件重组器165，后者生成输入文件101或输入流105的副本170。

编码器115可使用本文所示的技术来编码数据以使得FEC编码具有可变开销。

2FEC流送框架

2.1引言

本章节定义了用于CDP的定义的框架，从FEC构建块这个意义上来说，它提供了通过UDP流送的数据流量的FEC保护。本章节并不定义完全内容递送协议，而是仅定义期望为支持通过UDP流送数据的所有内容递送协议所共用的那些方面。

在本章节中定义的框架并不专用于单个流送应用协议。该框架提供了对通过UDP的应用协议流量的FEC保护以及对多个此类流量的组合保护。例如，多个RTP流量可连同相关联的RTCP流量以及诸如MIKEY分组的潜在可能其它相关流量一起被保护。对于许多丢失状况中的许多FEC方案，通过对使用具有给定FEC开销的FEC可达到的可靠性中的改进随着作为单个块保护的数据量的增加而增加。因此，在一起保护多个流的能力中有显著的益处，在接收器要求所有流以便向用户提供有用服务的情形中尤其如此。

此框架不定义待保护的流量如何被确定，也不定义所保护的流量和保护它们的FEC流自发送器传达到接收器的细节如何。完全内容递送协议规范——诸如章节5中给出的那些——解决了这些信令要求。然而，本章节的确规定发送器和接收器处FEC流送框架所要求的信息——例如要进行FEC保护的流量以及将携带FEC保护数据的流量的细节。还规定了内容递送协议用于传达此信息的SDP属性。

在图2中例示了以上概括的架构。

2.2程序综述

2.2.1概要

在本文章节中定义的机制包括三个组件：

(i)来自属于一个或若干个UDP分组流量的源媒体分组的‘源块’的构造。UDP流量可包括例如RTP、RTCP和SRTP分组以及还有与流有关的其它协议。

(ii)源分组的任选扩展，用于指示源块以及该源块中被来自源分组或与其有关的数据占据的位置。

(iii)通过UDP发送的修复分组的定义，它可被FEC解码器用来重构源块的错失部分。

除源数据通过UDP携带之外，此机制不对可被一起保护的源数据施加任何限制。数据可以是来自被联合保护的若干不同UDP流量。通常，对一个流构造多个源块，这些源块各自由不同源分组集构造成。例如，每个源块可及时地构造自与流的特定段有关的那些源分组。

支持这种流送架构的接收器应当支持FEC源分组的分组格式并且还应当支持FEC修复分组的分组格式。

本章节并不定义发送器如何确定哪些源分组被包括在哪些源块中。特定内容递送协议可定义这种映射，或者它可留待作为发送器处的相关实现。然而，CDP规范应当定义接收器如何确定其为接收任何给定源块的FEC修复分组所应等待的时间长度。

在发送器处，该机制处理原始UDP分组以创建：

(i)一个或多个‘源块’形式的原始分组的存储副本。源块是随后将对其应用FEC码的逻辑数据块。它是通过级联每个源分组的‘源分组信息(SPI)’来构造的。通常，分组的SPI包含该分组所属的流量的较短标识符、分组的长度、UDP有效载荷和可能的填充字节。

(ii)用于传输到接收器的FEC源分组。

FEC流送框架使用由FEC方案指定的用于从源块生成期望的修复码元量的FEC编码器。这些修复码元随后使用FEC修复分组格式发送给接收器。FEC修复分组可被发送到与由FEC流送配置信息指示的原始UDP分组的目的端口的任一个不同的UDP目的端口。

接收器直接从接收到的任何FEC源分组恢复原始源分组。接收器还使用接收到的FEC源分组来构造与发送器处构造的相同源块格式的原始分组的存储副本。

如果与给定源块有关的任何FEC源分组已丢失，则接收器处的源块的这个副本将是不完整的。如果已接收到与源块有关的足够的FEC源和FEC修复分组，则FEC框架可使用由FEC方案定义的FEC解码算法来恢复源块的副本(希望是完整的，但并不一定)。可随后从源块的完成部分中提取出错失源分组的SPI，并将其用于重构要传递给应用的源分组。

注意：接收器可能需要缓冲接收到的源分组以便为FEC修复分组的到达以及在部分或全部接收到或恢复的分组被传递给应用之前进行FEC解码留出时间。如果未提供这种缓冲，则应用必须能够处理被需要的分组的严格的重排序。然而，这种缓冲是内容递送协议和/或专用实现，且未在此指定。

FEC源分组的接收器标识源块以及该源块内由从每个分组导出的SPI占据的位置。此信息被称为FEC源分组标识信息并且可以多种方式来传达。FEC源分组标识信息可被编码到在本规范中定义的FEC源分组格式内的专用字段——称为源FEC有效载荷ID字段——中。源FEC有效载荷ID字段的确切内容和格式由FEC方案来定义。或者，FEC方案或CDP可定义如何从源分组内的其它字段导出FEC源分组标识信息。本文献定义了源FEC有效载荷ID字段——如果被使用——被附加到源分组以形成FEC源分组的方式。

FEC修复分组的接收器还应当能够标识源块以及所包含的修复数据与原始源块之间的关系。此信息称为FEC修复分组标识信息。此信息应当被编码成专用字段——修复FEC有效载荷ID字段——该字段的内容和格式由FEC方案来定义。

结合该规范使用的任何FEC方案应当是系统的FEC方案并且应当基于源块。FEC方案可为FEC源分组和FEC修复分组定义不同的FEC有效载荷ID字段格式。

2.2.2发送器操作

假定发送器已构造或接收到会话的原始数据分组。这些可以是RTP、RTCP、MIKEY或其它UDP分组。以下操作描述了用于生成顺应FEC源分组和FEC修复分组流的可能方法：

1.如章节2.3.2中指定的那样通过级联每个原始源分组的SPI来构造源块。通过如此进行，FEC源分组的源FEC分组标识信息可被确定并且被包括在源FEC有效载荷ID字段——如果被使用——中。在SPI中，分组的UDP流量的身份是使用本规范中定义的短‘UDP流量ID’来作标记的。将UDP流量规范与UDP流量ID相关联是通过FEC流送配置信息来定义的。

2.FEC源分组是根据章节2.3.3来构造的。在携带从特定协议(例如，RTP、RTCP、SRTP、MIKEY等)的原始流生成的FEC源分组时，原始流量的身份由源分组通过使用由内容递送协议(例如，使用DVB服务发现)已广告的相同UDP端口和IP地址来维护。所生成的FEC源分组根据常规UDP程序来发送。

3.FEC编码器从源块生成修复码元，而FEC流送框架将这些码元放置到FEC修复分组中，以便输送到接收器。这些修复分组使用常规UDP程序发送到唯一目的端口以便将它们与源分组流的任一个分开。在FEC流送配置信息中定义要用于FEC修复分组的端口。

2.2.3接收器操作

以下描述了当接收FEC源或修复分组时的可能的接收器算法：

1.如果FEC源分组被接收到(如由在其上进行接收的UDP流量指示的)：

a.原始源分组通过移除源FEC有效载荷ID——如果被使用——来构造。结果分组可被缓冲以为FEC修复留出时间。

b.源FEC分组标识信息是根据源FEC有效载荷ID——如果被使用——或根据其它手段来确定的。

c.结果分组的SPI根据源FEC分组标识信息和章节2.3.2中所述的源块格式来放置到源块中。在其处接收/从其发送分组的IP地址和UDP端口被用于确定SPI内的UDP流量ID。

2.如果接收到FEC修复分组(如由在其上接收到该分组的UDP流所指示的)，则所包含的修复码元根据修复FEC有效载荷ID来与源块相关联。

3.如果至少一个源分组错失且针对源块的至少一个修复分组已被接收到，则FEC解码会是合需的。FEC解码器确定在步骤1构造的源块加上在步骤2中接收到的相关联的修复码元是否包含足以解码源块中的任何或全部错失源码元，并且如果是，则执行解码操作。

4.在解码操作期间重构的任何SPI随后被用于重构错失的源分组，并且这些分组作为常规接收到的源分组来缓冲(参看上述步骤1a)。

注意：上述过程可能导致并非所有原始源分组被恢复的情形。

被正确接收到的源分组以及被重构的那些源分组可失序地且以与在接收器处到达的次序不同的次序递送到应用。或者，将源分组重排序和重构成它们被放置到源分组中的次序可能需要进行缓冲和分组重排序——如果根据应用需要的话。

2.3协议规范

2.3.1概要

本章节指定了FEC流送框架的协议元素。协议包括以下章节描述的三个组成：

1.源自源分组的源块的构造。FEC码可被应用到此源块以产生修复数据。

2.包含源数据的分组的格式。

3.包含修复数据的分组的格式。

FEC流送框架的操作由特定FEC流送配置信息来控制。在此章节中也定义了此配置信息。使用此框架的完全协议规范应当指定用于确定此信息并在发送器与接收器之间传达它们的手段。

2.3.2源块的结构

此条款定义了源块的布局。源块包括至少一个原始源UDP分组的SPI的级联。

令

n为源块中UDP分组的数目，可在源块构造过程期间动态地确定n。

Y为以字节计的源码元大小。注意：此信息是由如章节2.3.6中定义的FEC方案来提供的。

R[i]标示要被添加到源块的第i个UDP分组的UDP有效载荷的八位位组，0＜＝i＜n。

l[i]以八位位组计的R[i]的长度。

L[i]标示以网络字节次序表示的l[i]的值的两个八位位组(首先是高位八位位组)

f[i]标示标识取得第i个分组的UDP流量的整数‘UDP流量ID’

F[i]标示表示f[i]的值的单个八位位组

s[i]为使得s[i]*T＞＝(1[i]+3)的最小整数。注意：s[i]是以码元为单位计的SPI[i]的长度。

P[i]标示s[i]*T-(1[i]+3)个全零八位位组。注意：P[i]是用于使每个UDP分组的起始与码元的起始对齐的填充八位位组。

SPI[i]为F[i]、L[i]、R[i]和P[i]的级联。

随后，通过级联SPI[i]——i＝0，2，...n-1——来构造源块。源块大小S随后通过sum{s[i]*T，i＝0，...，n-1}来给出。

源块由整数源块号来标识，而源块内的码元由整数编码码元ID来标识。本章节不指定如何将源块号分配给源块。在源块内从零开始对码元连续编号。每个源分组与包含该分组的SPI的第一码元的编码码元ID相关联。因此，与第j个源分组相关联的编码码元ID值ESI[j]通过以下给出：

ESI[j]＝0，其中j＝0

ESI[j]＝sum{s[j]，i＝0，...，(j-1)}，其中0＜j＜n

源FEC分组标识信息包括源块的身份以及与该分组相关联的编码码元ID。

UDP流量是由IP源和目的地址以及UDP源和目的端口值来唯一地定义的。将UDP流量ID值指派给UDP流量是FEC流送配置信息的一部分。

2.3.3FEC源分组的分组格式

FEC源分组的分组格式应当用于输送原始源UDP分组的有效载荷。如图3中所示的，它包括其后任选地跟随有源FEC有效载荷ID字段——如果被使用——的原始UDP分组。

IP和UDP报头字段应当与原始源分组的那些相同。原始UDP有效载荷字段应当等于原始源分组的UDP有效载荷。FEC源分组的UDP有效载荷应当包括其后跟随有源FEC有效载荷ID字段的原始UDP有效载荷。

源FEC有效载荷ID字段——如果存在——包含FEC算法的操作——尤其是导出源FEC分组标识信息时——所需的信息。源FEC有效载荷ID的格式以及源FEC分组标识信息的导出是由FEC方案来定义的。注意：FEC方案或CDP可定义用于从源分组中的其它信息(例如，RTP序号)导出FEC分组标识信息的手段。在此情形中，本文所述的源FEC有效载荷ID字段不被附加到分组，且源FEC分组在各方面与原始源分组相同。

2.3.4FEC修复分组的分组格式

图4中示出了FEC修复分组的分组格式。UDP有效载荷包括修复FEC有效载荷ID字段以及由FEC编码过程生成的一个或多个修复码元。修复FEC有效载荷ID字段包含FEC算法的操作所需的信息。此信息是由FEC方案定义。修复FEC有效载荷ID字段的格式是由FEC方案来定义的。

任何数目的完整修复码元可被包含在FEC修复分组中，该FEC修复分组服从由FEC方案定义的分组大小限制或其它限制。分组内修复码元的数目可根据码元长度和分组长度来确定。部分修复码元不应当被包括在FEC修复分组中。

2.3.5FEC流送配置信息

FEC流送配置信息是FEC流送框架为了将FEC保护应用到UDP流量而需要的信息。使用在此指定的框架的用于流送的完全内容递送协议规范应当包括此信息如何被导出以及如何在发送器与接收器之间传达的细节。

FEC流送配置信息包括对多个UDP分组流量的标识。每个UDP分组流量由元组{源IP地址、目的IP地址、源UDP端口、目的UDP端口}来唯一地标识。

FEC-SF的单个实例经由包含修复分组的一个或多个UDP分组流量提供了对指定的一组源UDP分组流量的所有分组的FEC保护。对于FEC-SF的每个实例，FEC流送配置信息包括：

1.携带FEC修复分组的UDP分组流量——称为FEC修复流量——的标识。

2.对于由FEC修复流量保护的每个源UDP分组流量：

a.携带源分组的UDP分组流量的标识。

b.整数标识符，对于此流量，在0与255之间。由同一FEC修复流量保护的所有源UDP分组流量之间，此标识符应当是唯一的。

3.FEC编码ID、FEC实例ID(如果可应用)以及任选地，码元大小。

以上的项目(3)被包括在FEC对象传输信息中。

在发送器或接收器处可存在具有分开和独立的FEC流送配置信息的多个FEC-SF实例。单个FEC-SF实例保护以上(2)中标识的所有源UDP分组流量的所有分组，即，这些流量上的所有分组应当是如章节2.3.3中所定义的FEC源分组。单个源UDP分组流量不应当由一个以上的FEC-SF实例来保护。

单个FEC修复流量为单个FEC-SF实例提供了修复分组。其它分组不应当在此流量中发送，即，FEC修复流量中的所有分组应当是在章节2.3.4中定义的FEC修复分组且应当与相同的FEC-SF实例有关。

需要向FEC-SF通知要用于每个源块的码元大小。此信息可被包括在FEC流送配置信息中或它可通过其它手段来传达——例如在FEC修复有效载荷ID字段内。完全内容递送协议规范应当指定此信息如何在发送器与接收器之间传达。

2.3.6FEC方案要求

较佳的FEC方案是系统的，是基于离散源块的，指定与源分组相关联的源块号和编码码元ID如何被导出或如何从发送器传到接收器(例如，在源FEC有效载荷ID字段内)，以及指定码元长度如何被导出或如何从发送器传到接收器(例如，作为FEC对象传输信息的部分)。

3.用于流送的FEC方案

3.1用于任意分组流量的MSCR FEC方案

此条款定义了用于UDP上任意分组流量的MSCR保护的FEC方案。

3.1.1格式和码

3.1.1.1FEC对象传输信息

3.1.1.1.1FEC对象传输元素

FEC对象传输元素、FEC编码ID被设为预定值。

3.1.1.1.2公共的

对于此方案，此公共FEC对象传输信息元素及其值范围是这样的：最大源块长度为小于2¹⁶的非负整数——以码元为单位计的——而编码码元大小是小于2¹⁶的非负整数——以字节为单位计的。经编码的公共FEC对象传输信息元素的格式可以是图5中定义的四-八位位组字段。

3.1.1.2FEC有效载荷ID

3.1.1.2.1源FEC有效载荷ID

源FEC有效载荷ID可以是如图6中所示的。在那里，源块号(SBN)(16比特)是与分组内的源数据有关的源块的整数标识符，而编码码元ID(ESI)(16比特)是源块中源分组的起始码元索引。编码码元标识符的说明是由FEC流送框架来定义的(参见章节2)。

3.1.1.2.2修复FEC有效载荷ID

在图7中定义了修复FEC有效载荷ID的结构，其中源块号(SBN)(16比特)是与分组内的修复码元有关的源块的整数标识符，编码码元ID(ESI)(16比特)是分组内编码码元的整数标识符，而源块长度(SBL)(16比特)是源块内源码元的数目。源块号、编码码元标号符和源块长度的说明可以是如FEC码规范所定义的。

3.1.2程序

此FEC方案使用章节2中定义的框架的程序来构造可应用FEC码的源块。发送器应当向源块顺序分配源块号，在源块号216-1之后卷绕回到零。发送器不应当构造比在FEC对象传输信息中信令的最大源块大的源块。

3.1.3FEC码规范

传递给MSCR FEC编码器的源块包括根据章节3.1.2构造的、扩展成具有零或多个填充码元以使得源块中的码元总数等于FEC对象传输信息中信令的最大源块长度的源块(参见章节3.1.1.1.2)。因此，由编码的FEC使用的K值等于最大源块长度。填充码元可以是设置成值零的字节。

要用于源块构造和修复码元构造的码元大小T等于FEC对象传输信息中信令的编码码元大小(参见章节3.1.1.1.2)。参数T被设置成使得任何源块中源码元的数目最多为KMAX＝8192。

章节3.1.3.3中给出了推荐参数。

3.1.3.1编码分组构造

如章节2.3.4中所述的，每个修复分组包含源块号(SBN)、编码码元ID(ESI)、源块长度(SBL)和修复码元。

包含在修复分组内的修复码元的数目是从分组长度计算出的。放置入修复分组的ESI值以及用于生成修复码元的修复码元三倍数是如[2]的子条款C.3.2.2中所描述的来计算的。

修复FEC有效载荷ID字段的源块长度字段被设置成包括在与源块相关联的分组的源分组信息中的码元数目，即，在填充成最大源块长度之前。

3.1.3.2输送

此子条款描述了MSCR编码器/解码器与利用MSCR FEC进行流送的任何输送协议之间的信息交换。

用于流送的MSCR编码器根据输送协议对每个源块使用以下信息：

-以字节计的码元大小T

-源块中码元的数目K

-源块号(SBN)

-要被编码的源码元——K·T个字节

对于每个修复分组，MSCR编码器向输送协议提供包括以下的编码分组信息：

-源块号(SBN)

-编码码元ID(ESI)

-源块长度(SBL)

-修复码元

输送协议向MSCR解码器透明地传达此信息。

在本规范中定义了合适的输送协议。

3.1.3.3示例参数

3.1.3.3.1参数导出算法

本章节提供了对输送参数T的导出的推荐。此推荐是基于以下输入参数：

-B以字节计的最大源块大小

-P以字节计的最大修复分组有效载荷大小(不包括修复FEC有效载荷ID)，它应当是A的倍数。

-A以字节计的码元对齐因子

-K_MAX每源块的最大源码元数目如在[2]中定义的，KMAX＝8192。

-K_MIN每源块的最小目标码元数目

-G_MAX每修复分组的最大目标码元数目

对这些输入的要求是ceil(B/P)≤K_MAX。基于以上输入，输送参数T计算如下：

令，

G＝min{ceil(P·K_MIN/B)，P/A，G_MAX}-每分组的适当码元数目

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

以上导出的T值应当被认为是对实际所用T值的指导。确保T除尽P会是有益的，或者可有益地将T的值设置成较小以在全尺度修复码元被用于在丢失源分组结束时恢复部分源码元时最小化损耗(只要源块中的最大源码元数目不超过K_MAX)。此外，对T的选择取决于源分组大小分布，例如，如果所有源分组是相同大小的，则选择T以使得修复分组P’的实际有效载荷大小等于(或以尽可能少的字节地大于)每个源分组在源块中占用的字节数目，其中P’是T的倍数。

对输入参数A、K_MIN和G_MAX的推荐设置是A＝16、K_MIN＝640、G_MAX＝10。

3.1.3.3.2示例

在假定A、K_MIN和G_MAX为推荐的值且P＝1424的情况下，以上算法导致如以下表3中的输送参数：

最大源块大小B G 码元大小T G-T

16KB 10 128 1280

32KB 10 128 1280

128KB 7 192 1344

256KB 4 352 1408

表3：示例参数设置

3.2用于单个有序分组流量的MSCR FEC方案

本章节定义了用于其中源分组各自携带唯一序号的单个分组流量的FEC保护的替换性FEC方案。称此类分组流量为“有序流量”。主要示例可以是包含MPEG-2输送流——其内关于服务的所有数据被复用——的RTP流量的FEC保护。在此情形中，RTP序号可用于导出源FEC分组标识信息。

与章节3.1中定义的FEC方案相比，本方案的主要优点是它无论如何不更改源分组。因此，存在不能识别已根据章节3.1中定义的方案更改的源分组的传承设备时，可使用此FEC方案。

在此FEC方案中，章节3.1的方案中源FEC有效载荷ID扮演的角色由序号代替。要被保护的每个流量内的分组的序号应当针对流中的每个分组递增1。

给定有序流量内每个分组的给定源块内的源分组信息的大小应当相同且是从FEC修复分组的大小导出的，它们对于给定源块而言还应当是相同大小的。

3.2.1格式和码

3.2.1.1FEC对象传输信息

3.2.1.1.1强制性的

此FEC方案是由预定FEC编码ID来标识的。

3.2.1.1.2公共的

参看章节3.1.1.1.2

3.2.1.1.3方案专用

没有由此FEC方案中定义的方案专用FEC对象传输信息。

3.2.1.2FEC有效载荷ID

3.2.1.2.1源FEC有效载荷ID

源FEC有效载荷ID字段未被此FEC方案使用。源分组未被此FEC方案以任何方式更改。

3.2.1.2.2修复FEC有效载荷ID

在图8中示出了此FEC方案的修复FEC有效载荷ID格式。在那里，初始序号(流量iISN)是16比特字段，该字段指定了要被包括在此子块中的第一分组的序号的最低16比特。如果序号少于16比特，则接收到的序号使用零比特来逻辑填充以相应地在长度上形成16比特。编码码元ID(ESI)是16比特字段，该字段指示哪些修复码元被包含在此修复分组内。所提供的ESI是分组中第一修复码元的ESI。源块长度(SBL)是16比特字段，该字段是以码元计的源块的长度。

3.2.2程序

此FEC方案使用章节2中定义的框架的程序来构造可应用FEC码的源块。除在此定义的程序之外，还应用以下程序。

3.2.2.1源FEC分组标识信息的导出

源分组的源FEC分组标识信息是从分组的序号以及修复FEC分组中接收到的信息来导出的。源块是由块中第一源分组的序号来标识的。在与初始序号字段中的源块相关联的所有修复FEC分组中信令此信息。

源块内源分组的源分组信息的长度(以字节计)等于包含该块的修复分组的编码码元的有效载荷的长度(即，不包含修复FEC有效载荷ID)，它们应当全都一样。码元中的源分组信息长度(SPIL)等于此长度除以编码码元大小(在公共FEC对象传输信息中信令)。

包括在源块中的源分组集合是根据初始序号(ISN)和源块长度(SBL)如下来确定的：

令，

I为源块的初始序号

L_P为以码元计的源分组信息长度

L_B为以码元计的源块长度

然后，具有从I到I+L_B/L_P-1(并且包含I和I+L_B/L_P-1)的序号的源分组被包括在源块中。

注意：如果没有FEC修复分组被接收到，则FEC解码是不可能的，并且无需接收器来标识源分组的源FEC分组标识信息。

分组的编码码元ID是从以下信息导出的：

分组的序号N_S

源块的源分组化信息长度LP

源块的初始序号I

然后，具有序号N_S的分组的编码码元ID是根据以下公式来计算的：

ESI＝(N_S-I)·L_P

注意：与给定源块相关联的所有修复分组应当包含相同的源块长度、源分组信息长度和初始序号。

3.2.2.2修复分组编码码元ID的导出

修复分组的编码码元ID指示分组包含哪些修复码元。这由修复FEC有效载荷ID的编码码元ID字段直接给出。

3.2.2.3RTP流量的程序

随后，在RTP分组流量的特定情形中，RTP序号字段被用作上述程序中的序号。

3.2.3FEC码规范

适用章节3.1.3的要求。

3.2.3.1示例参数

3.2.3.1.1参数导出算法

推荐使用章节3.1.3.3.1的算法。

然后，在RTP流携带MPEG-2输送流的情形中，最大修复分组大小应当被设置成

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

其中n是每IP源分组188字节TS分组的标称数目。

最大源块大小是根据发送器处的应用配置来确定的。

3.2.3.1.2示例

在假定A、K_MIN和G_MAX为推荐值的情况下，以上算法导致如以下表4中MPEG-2输送流的输送参数：

每保护周期最大分组	每IP分组标称TS分组	最大分组大小，P	最大源块大小，B	G	码元大小T
每保护周期最大分组	每IP分组标称TS分组	最大分组大小，P	最大源块大小，B	G	码元大小T	100	7	1344	134400	6	224
200	7	1344	268800	3	448	100	7	1344	134400	6	224
200	7	1344	268800	3	448	300	7	1344	403200	2	672

4公共协议元素

本章节定义了可结合章节2中定义的框架和章节3中定义的FEC方案使用以构造用于流送媒体的FEC保护的完全协议的多个公共协议元素。

4.1FEC反馈协议

4.1.1概要

本章节规定了用于接收器的任选的简单协议以在单播流中提供关于FEC数据的接收的反馈。此反馈数据可被发送器用来调节FEC参数。为多组源块提供关于接收以及解码成功或失败的反馈，这些源块组被称为‘反馈组’。

用于接收反馈的能力必须连同应当发送反馈的IP地址和目的UDP端口以及请求反馈的反馈组的请求大小由发送器向接收器来广告。

以“尽力”为基础提供反馈——发送器不应当依赖于接收反馈消息。

在此版本的协议中，提供单个反馈报告消息，该消息在单个反馈组上提供反馈。

·在每个反馈报告中提供以下信息：

·反馈组中源块的数目

·反馈组中接收到的没有差错的源块的数目

·反馈组中被成功解码的源块的数目

·反馈组中不能被解码的源块的数目

·反馈组中的任何源块接收到的最大分组数目

·反馈组中的任何源块接收到的最小分组数目

·关于该反馈接收到的分组总数

4.1.1格式和码

4.1.2.1通用消息格式

FEC反馈协议消息伴随根据图9格式化的UDP有效载荷通过UDP来发送。在此类消息中，在此版本的协议中，版本字段被设为零(0)。

消息类型：

0x00 反馈报告

0x01-0xff 保留

源块标识符：

标识此报告所涉及的组中的第一源块。如果FEC方案定义源块号，则此标识符被用作源块标识符。

源块的数目：

此报告所及的源块的数目。

有效载荷：

有效载荷字段的内容取决于消息类型并且在以下定义。

4.1.2.2消息有效载荷格式

在图10中定义了反馈报告的有效载荷字段的格式。

“无差错”块的数目：指示反馈组中因所有源分组被无差错地接收到而不要求解码的源块的数目。

“解码成功”的块的数目：指示反馈组中要求解码且成功完成的源块的数目。

“解码不成功”的块的数目：指示反馈组中要求解码但因没有接收到足够的信息而不能成功完成的源块的数目。

最大接收到的分组：指示为反馈组中的任何源块接收到的最大分组(源和修复)数目。

最小接收到的分组：指示为反馈组中的任何源块接收到的最小分组(源和修复)数目。

接收到分组总数指示为反馈组中的所有源块接收到的分组(源和修复)总数。

4.1.3程序

4.1.3.1FEC发送器程序

本章节定义正发送FEC保护的数据并接收FEC反馈协议数据的设备处的程序。

4.1.3.1.1概要

在发送器处对FEC反馈协议的支持是任选的。发送器在FEC流送配置信息中广告对FEC反馈协议的支持、所支持的最高版本、消息应当被发送至的IP目的地址和UDP目的端口、以及所请求的反馈组的大小。用于传达FEC流送配置信息的机制是专用内容递送协议。

FEC发送器可忽略接收到的具有未被承认的版本号的FEC反馈协议分组以及接收到的具有保留消息类型的FEC反馈协议分组。

在接收到比预期更长的FEC反馈协议消息的情形中，发送器应当丢弃附加字节并如往常那样处理消息。

4.1.3.1.2反馈报告消息的接收

一旦接收到反馈报告消息，FEC发送器就可基于在反馈报告消息中接收到的信息来为后继源块改编FEC参数(源块大小、发送速率和布置等)。

在反馈组的大小为单个源块的情形中，并且如果

·反馈报告指示源块被成功接收到或被成功解码，且

·FEC发送器仍在发送源块的FEC修复分组，

则FEC发送器应当停止发送源块的FEC修复分组。

4.1.3.2FEC接收器程序

本章节定义了正接收FEC保护的数据并发送FEC反馈协议数据的设备处的程序。

4.1.3.2.1概要

在接收器处对FEC反馈协议的支持是任选的。

如果对FEC反馈协议的支持尚未由FEC发送器广告，则FEC接收器不应当发送FEC反馈协议消息。

如果对FEC反馈协议的支持已由FEC发送器广告，则FEC接收器可使用FEC流送配置信息中的信息来确定由FEC发送器支持的最高版本、消息应当被发送至的IP目的地址和UDP目的端口、以及反馈组的大小。

FEC接收器不应当发送具有比由FEC发送器支持的最高版本高的版本号的FEC反馈协议消息。

FEC接收器应当以每个FEC流送框架实例为基础来确定FEC反馈协议是否将被使用。除未接收到针对其的修复分组的源块不应当被包括在任何反馈组中之外，反馈组应当包括连续源块序列。反馈组中源块的数目应当等于在FEC流送配置信息中指示的所请求的反馈组大小。

反馈组中的每个源块应当被归类为如在以下章节所述的或者“无差错”、“解码成功”或者“解码不成功”。

一旦反馈组中所有源块的分类被确定，FEC接收器就应当发送反馈报告消息。

4.1.3.2.2“无差错”源块

一旦FEC接收器确定无需对源块进行FEC解码，源块就可被认为是“无差错”。

4.1.3.2.3“解码成功”源块

一旦源块成功解码，源块就可被认为是“解码成功”。

4.1.3.2.4“解码未成功”源块

一旦FEC接收器确定对源块的FEC解码是必需的但是不可能的，源块就可被认为是“解码未成功”。FEC接收器可确定对源块的FEC解码是必需的，但在以下情形中是不可能的：

·源块的至少一个源码元是未知的，

·尚未接收到用于解码源块的足够的修复码元，以及

·应用要求源码元(例如，媒体播放器)。

FEC接收器可确定对源块的FEC解码是必需的，但是在其它时候是不可能的，例如，在由FEC接收器确定的某一时间段内尚未接收到源块的其它修复码元的情况下。

4.2FEC发送布置

在章节2中定义的FEC流送框架没有规定所传送的分组的任何布置。本章节描述了可被发送器用来确定流的FEC源和FEC修复分组的发送布置的办法。

4.2.1简单恒定速率FEC发送

本章节描述了每个源块中FEC源分组和FEC修复分组的发送速率保持恒定的简单发送布置。

对于每个源块，源分组首先被发送，继之以修复分组。一个源块的所有分组在后继块的任何分组之前被发送。

源块中的所有数据(源和修复)的发送数据率是恒定的，且由以下公式给出：

其中：

R_发送是发送速率

R_源是源数据速率

D_修复是修复数据量(字节，包括分组化开销)

D_源是源数据量(字节，包括分组化开销)

4.3确定FEC源块边界

本章节给出可被发送器用来确定FEC源块边界的多个算法。

4.3.1基于保护周期

在此办法中，源块是基于称为“保护周期”的时间周期来构造的。通常，保护周期对于一个流的每个源块而言是相同的。然而，它可随块的不同而变化。

在实时流的情形中，源块的源分组确切地为在等于保护周期的时间段内到达的那些分组。

在预编码内容的情形中，源块的源分组确切地为将在等于从该内容产生的非FEC保护流的常规发送布置中的保护周期的时间段内发送的那些分组。

在此办法中，使用章节4.2.1和在别处的发送布置，在接收器处缓冲分组至少与任何源块的最长播出时间相等的时间。

5内容递送协议

本章节利用章节2-4中定义的组件来定义若干完全内容递送协议。

5.1多播MPEG-2输送流

本章节定义了用于MPEG-2输送流的FEC保护多播递送的内容递送协议。

5.1.1控制协议

会话信息包括：

·每个修复流量的目的UDP端口

·在多个修复流量层被提供的情况下，每个修复流量的IP多播地址

·在多个修复流量层被提供的情况下，修复流量的联结次序

·FEC对象传输信息(最大源块大小和编码码元大小)

·在接收器处所需的最小缓冲时间

MPEG-2TS流量的流量ID为零。

5.1.2输送协议

MPEG-2输送流的FEC保护可使用以下来提供：

·章节2中描述的FEC流送框架

·章节3.3中定义的FEC方案

·4.2.1中描述的FEC发送布置

·4.3.1中描述的FEC源块边界标识机制

每个MPEG-2输送流应当被独立地保护。

5.2单播MPEG-2输送流

本章节定义了用于MPEG-2输送流的FEC保护单播递送的内容递送协议。

5.2.1控制协议

会话信息可包括：

·FEC对象传输信息(最大源块大小和编码码元大小)

·在接收器处所需的最小缓冲时间

·所请求的FEC反馈组大小(或者在未要求反馈的情况下为零)

与单播RTP流量相关联的修复FEC流量可被发送到端口号较RTP流量被发送至的目的UDP端口大2的目的UDP端口号。

MPEG-2TS流量的流量ID为零。

如果FEC反馈是由发送器要求并由接收器支持的，则FEC反馈消息可被发送到用作自服务器到接收器的FEC修复流的源地址/端口的地址/UDP端口。

5.2.2输送协议

MPEG-2输送流的FEC保护可使用以下来提供：

·章节2中描述的FEC流送框架

·章节3.3中定义的FEC方案

·4.2.1中描述的FEC发送布置

·4.3.1中描述的FEC源块边界标识机制

每个MPEG-2输送流应当被独立地保护。

5.3普通多播视频

本章节定义了用于任意音频/视频流(例如，封装在RTP中的H.264)的的FEC保护多播递送的内容递送协议。提供本章节来描述如何可将FEC应用于针对音频/视频流在RTP中的直接封装的DVB IPI手册的将来扩展。

5.3.1控制协议

会话信息包括：

·每个修复流量的目的UDP端口

·在多个修复流量层被提供的情况下，修复流量的联结次序

·FEC对象传输信息(最大源块大小和编码码元大小)

·IP多播地址、UDP目的端口号和受保护UDP流量(例如，音频和视频流量)的流量ID。

·在接收器处所需的最小缓冲时间

5.3.2输送协议

音频/视频流被假定为由一个或多个UDP流量(很可能为RTP流量)携带。

这些UDP流量的FEC保护可使用以下来提供

·章节2中描述的FEC流送框架

·章节3.1中定义的FEC方案

·4.2.1中描述的FEC发送布置

·4.3.1中描述的FEC源块边界标识机制

5.4普通单播视频

本章节定义了用于任意音频/视频流(例如，封装在RTP中的H.264)的FEC保护单播递送的内容递送协议。提供本章节来描述如何可将FEC应用于针对音频/视频流在RTP中的直接封装的DVB IPI手册的将来扩展。

5.4.1控制协议

会话信息包括：

·修复流量的目的UDP端口

·FEC对象传输信息(最大源块大小和编码码元大小)

·UDP目的端口号和受保护UDP流量(例如，音频和视频流量)的流量ID。

·在接收器处所需的最小缓冲时间

·FEC反馈组大小(或者在未要求FEC反馈的情况下为零)

5.4.2输送协议

这些UDP流的FEC保护可使用以下来提供

·章节2中描述的FEC流送框架

·章节3.1中定义的FEC方案

·4.2.1中描述的FEC发送布置

·4.3.1中描述的FEC源块边界标识机制

6.FEC流送建议

本章节提供了对在DVB环境中使用以上FEC流送协议的某些其它任选建议。

6.1多播

6.1.1分层FEC发送(任选)

发送器可为与单个源流相关联的修复分组广告一个以上的IP多播地址。发送器应当对每个多播组发送不同修复分组。

接收器可联结任何数目的此类多播组以根据本地差错率调节接收到的修复分组的速率。

然而，应当注意，为了满足IPTV质量目标，必须接收到足够的开销以克服即使相对较少差错的事件，且由此接收器应当在足够长的时间段上测量差错率以便确定所需的修复数据量。

6.2单播

6.2.1流起始处的源块构造(任选)

源块边界应当使用章节4.4.1中定义的保护周期算法来标识。推荐以下算法来确定要在新的流被播出的任何时间(例如，流起始或当使用技巧(trick)模式时)使用的保护周期、FEC开销和发送速率。此算法将在FEC修复数据与快速缓冲填充数据之间均匀地分配源速率之上的初始可用带宽。初始可用带宽可能大于标称(长期)带宽或它可以是相等的，但是不应当更小。

令，

B_max为可为流所用的初始带宽(源和FEC)

B_nom为流的标称带宽(源和FEC)

B_src为源带宽

P_init为初始缓冲延迟

P_final(P_最后)为目标保护周期

P为第i个保护周期，其中i＝0，1，...

S_init为初始源发送速率

R_init为初始修复发送速率

则，

S_{init} = B_{src} + \max (\frac{B_{\max} - B_{src}}{2}, B_{\max} - B_{nom})

P_{0} = P_{init} \cdot \frac{s_{init}}{B_{src}}

R_init＝B_max-S_init

以及，对于所有i使得P_i＜P_final，则

P_{i + 1} = P_{i} \cdot \frac{S_{init}}{B_{src}}

以及对于所有i使得P_i＞＝P_final

P_i+1＝P_i

对于持续时间小于P_final的保护周期，源发送速率应当是Sinit而修复发送速率是Rinit。在此之后，源发送速率应当被缩减至Bsrc。此布置意味着在初始周期期间，源发送速率大于实际源数据速率，由此每个保护周期包含播出将比发送占用更久的数据。结果，可根据以上算法在不使接收器缺乏分组的情况下使后继保护周期更长。

在服务发现信息中广告的接收器处最小缓冲时间应当为Pinit。

6.2.2FEC反馈的使用(任选)

可以长期为基础使用FEC反馈来调节被提供给各个用户的FEC开销。然而，应当注意，为了满足IPTV质量目标，必须提供足够的开销以克服即使相对较少差错的事件，且由此在较短时间段内收集到的反馈数据不足以确定所需的长期开销。

在保护周期显著长于发送器与接收器之间的IP往返时间的情形下，则单个源块的反馈组可能要求FEC反馈。在此情形中，反馈报告可用于放弃发送在接收到的指示此源块已被成功接收到/解码的报告中的源块的FEC修复分组。

虽然已参照示例性实施例描述了本发明，但是本领域技术人员应当认识到，许多更改是可能的。例如，本文所述的方法和过程可使用硬件组件、软件组件和/或其任何组合来实现。因而，尽管已参照示例性实施例描述了本发明，但是应当领会，本发明旨在涵盖落在所附权利要求的范围内的所有更改和等效方案。

Claims

1.一种用于流送数据的通信系统，其中数据被从传送器流送到接收器，以使得所述接收器可在所述所流送的数据被全部接收到或传送之前开始使用所述流送的数据，所述传送器包括：

用于编码所述要传送的数据的前向纠错(“FEC”)的逻辑，

藉此所传送的流包括数据和FEC信息，并且所述数据是使用比所述接收器的消耗速率大的传送速率来传送的。

2.一种用于流送数据的通信系统，其中数据被从传送器流送到接收器，以使得所述接收器可在所述所流送的数据被全部接收到或传送之前开始使用所述流送的数据，所述传送器包括：

用于编码所述要传送的数据的前向纠错(“FEC”)的逻辑，

藉此所传送的流包括数据和FEC信息；

用于定时传输以使得至少对于所述传输的部分，所述传送器的输入速率比所述接收器的消耗速率大的逻辑；以及

用于随流送传输的时间改变超额的FEC量和/或输入速率的逻辑。