用于在具有广播/多播能力的网络上传递对象流的方法和系统与流程

本申请要求享有以下申请中的每一件申请的优先权权益：于2013年4 月12日递交的、名称为“Methods for Delivery of Flows of Objects over Broadcast/Multicast Enabled Networks”的美国临时申请No.61/811,693；于2013年5月2日递交的、名称为“Methods for Delivery of Flows of Objects over Broadcast/Multicast Enabled Networks”的美国临时申请No.61/818,912；于2013年9月16日递交的、名称为“Methods for Delivery of Flows of Objects over Broadcast/Multicast Enabled Networks”的美国临时申请No.61/878,368；以及于2013年12月5日递交的、名称为“Methods for Delivery of Flows of Objects over Broadcast/Multicast Enabled Networks”的美国临时申请No. 61/912,145，故以引用方式将上述所有申请的全部内容并入本文。

背景技术：

无线通信技术在过去几年中已见证了爆发式增长。无线服务提供商现在向他们的客户提供各种服务，并且向用户提供对信息、资源和通信的前所未有的访问级别。最近增加到无线通信服务中的是将电视和其它内容广播给接收方设备的能力。多媒体仅前向链路(FLO)广播服务允许用户观看多媒体节目(例如，电视演出)，以及使用被配置为接收移动广播传输的移动接收方设备来接收新闻、娱乐、体育、商业、互联网数据、数据文件和其它内容的移动版本。多媒体广播服务意味着可用于向接收方设备传递各种服务的显著的带宽。

一种用于传递广播服务的协议是单向传输的文件传递(FLUTE)，该协议是在互联网工程任务组(IETF)请求注解(RFC)3926和RFC 6726中定义的。FLUTE可以用于使用几秒或更多秒的传递会话来向许多主机传递大型文件和小型文件。例如，FLUTE可以用于同时向许多主机传递大型软件更新。FLUTE还可以用于连续但分段的数据(例如，用于字幕制作的加时间轴的文本)——潜在地利用其继承自异步分层编码(ALC，如IETF RFC 3450和IETF RFC 5775中所指定的)和分层编码传输(LCT，如IETF RFC 3451和IETF RFC 5651中所指定的)的分层，以针对网络的拥塞状况来调节会话的丰富度。FLUTE还适用于对元数据(例如会话描述协议(SDP) 文件，其使得用户应用能够访问多媒体会话)的基本传输。FLUTE可以与多播和单播传递一起使用，但是其主要应用是针对单向多播文件传递。

最近出现了在单向多播系统上将流(例如，视频和/或音频流)传递成文件的序列的趋势。例如，3GPP MBMS系统中的主要流式传递机制在过去几年中已经从流的RTP传递演进为使用FLUTE来传递经DASH(MPEG HTTP动态自适应流式传输，如ISO/IEC 23009-1和TS26.247中所指定的 DASH的3GPP版本中所指定的)格式化的流式传输内容，其中通常将相等长度持续时间的流式传输内容格式化成DASH区段文件，并且然后使用 FLUTE协议将每个DASH区段文件传递成对象。但是，FLUTE不是专门被设计用于这种流式传输应用的，并且因此在该上下文中具有某些限制。

技术实现要素：

各个方面包括通过以下操作经由广播网络来发送信息的方法：将相关源对象的集合(collection)与源流进行关联；以及在所述广播网络上发送与所述源流相关联的所述相关源对象的集合中的源对象，使得所述源对象可以由接收方设备基于所述源对象的彼此关系进行接收和恢复。在一方面中，所述方法可以包括：确定针对所述源流的源流标识符；以及将所述源流标识符包括在分组中，其中所述分组可以包含与所述源流相关联的所述相关源对象的集合中的至少一个源对象的数据。

在另一方面中，所述方法可以包括：在所述分组中使用字节范围来对所述分组中的数据进行标识。在另一方面中，所述方法可以包括：在所述分组中包括对所述分组中的源对象的数据进行标识的字节范围。在另一方面中，所述方法可以包括：使用所述分组的传输会话标识符(TSI)字段作为所述源流标识符。在另一方面中，将所述源流标识符包括在所述分组中可以涉及：将所述源流标识符包括在所述分组的TSI字段中。在另一方面中，所述方法可以包括：使用所述分组的互联网协议(IP)目的地址字段和用户数据报协议(UDP)端口号字段的组合作为所述源流标识符。在另一方面中，将所述源流标识符包括在所述分组中可以包括：将所述源流标识符包括在互联网协议(IP)目的地址字段和UDP端口号字段的组合中。

在另一方面中，所述方法可以包括：使用所述分组的码点(CP)字段作为所述源流标识符。在另一方面中，将所述源流标识符包括在所述分组中可以包括：将所述源流标识符包括在数据分组的码点(CP)字段中。在另一方面中，发送所述相关源对象的集合可以包括：发送相关源对象的多个集合，每个集合与多个不同的源流中的一个源流相关联，所述多个不同的源流中的每个源流包括唯一的源流标识符。在该方面，将所述源流标识符包括在可以包含与所述源流相关联的所述相关源对象的集合中的至少一个源对象的数据的所述分组中可以包括：将所述源流的所述唯一的源流标识符包括在可以包含所述源对象的数据的所述分组中。

在另一方面中，发送所述相关源对象的集合可以包括：发送可以包括 FEC修复数据、修复流标识符和修复对象标识符的至少一个分组，所述方法还包括：将修复流与所述多个不同的源流中的一个或多个源流进行关联；针对所述修复流，确定所述修复流标识符；针对所述修复流，确定修复对象标识符的集合；以及至少部分地基于分组的所述修复流标识符和所述修复对象标识符的组合，来确定在所述分组中所包括的所述FEC修复数据是根据来自所关联的多个源流的所述源对象中的哪个或哪些源对象来生成的。

在另一方面中，所述修复流标识符包括在TSI字段中。在另一方面中，所述修复流标识符包括在互联网协议(IP)目的地址字段和UDP端口号字段的组合中。在另一方面中，所述修复流标识符包括在码点(CP)字段中。在另一方面中，所述修复对象标识符是传输对象标识符(TOI)。

在另一方面中，所述修复对象标识符是对象序列号(OSN)。在另一方面中，发送可以包括FEC修复数据的至少一个分组可以包括：在与可以包括针对相应的源对象的数据的所述分组相同的时间间隔中发送可以包括 FEC修复数据的至少一个分组。在另一方面中，所述方法可以包括：根据不同的源流中的两个源对象来生成针对具有相同修复流标识符和相同修复对象标识符的分组的FEC修复数据，使得从所述具有相同修复流标识符和相同修复对象标识符的分组以及从包括针对所述两个源对象中的任一源对象的数据的分组的结合中接收到的数据量足以对所述两个源对象进行解码，其中所述数据量大于或等于所述两个源对象的聚合大小。在另一方面中，所述修复流标识符的部分包括在可以包含FEC修复数据的所述分组的不同数据字段中。

在另一方面中，所述方法可以包括：确定针对所述修复流的修复流声明，使得所述修复流声明可以包括适用于以信号发送(signal)在可以包含 FEC修复数据的所述分组中的所述修复对象标识符和来自与源流相关联的所述相关源对象的集合的所述源对象之间的关系的信息，其中所述分组中的所述FEC修复数据是根据所述源对象来生成的。在另一方面中，所述方法可以包括：使用模板，经由所述修复流声明来以信号发送所述关系。在另一方面中，所述修复流声明的一部分是在与关联于所述修复流的所述源流相关联的至少一个源对象之前被发送给所述接收方设备的。

在另一方面中，所述方法可以包括：确定针对所述相关源对象的集合中的每个源对象的源对象标识符；以及将所述源对象标识符包括在一个或多个分组中，其中所述一个或多个分组包括针对所述源对象的数据。在另一方面中，所述方法可以包括：使用所述源流标识符和所述源对象标识符的组合来对所述相关源对象的集合中的相应的源对象进行标识。在另一方面中，将所述源对象标识符包括在可以包含数据的所述分组中可以包括：将所述源对象标识符包括在所述分组中，使得所述源流标识符和所述源对象标识符的组合对相应的源对象进行标识，其中所述分组携带针对所述相应的源对象的数据。在另一方面中，所述方法可以包括：使用TOI作为所述源对象标识符。

在另一方面中，所述方法可以包括：使用OSN作为所述源对象标识符。在另一方面中，所述方法可以包括：在所述广播网络上发送针对与所述源流相关联的所述相关源对象的集合的FEC修复数据，使得所述源对象可以由所述接收方设备基于所述源对象的彼此关系来进行接收和恢复，其中，可以包括针对与所述源流相关联的相关源对象中的一个或多个相关源对象的FEC修复数据的每个分组可以包括：对所述源流进行标识的所述源流标识符，其中所述分组可以包括针对所述源流的FEC修复数据，其中，可以包括针对与所述源流相关联的所述相关源对象中的一个或多个相关源对象的FEC修复数据的每个分组携带一个或多个源对象的一个或多个源对象标识符，在所述分组中所携带的所述FEC修复数据是根据所述一个或多个源对象来生成的，并且其中，所述源流标识符和一个或多个源对象标识符的组合对来自与所述源流相关联的所述相关源对象的集合的一个或多个源对象进行标识，在所述分组中所携带的所述FEC修复数据是根据所述一个或多个源对象来生成的。

在另一方面中，所述方法可以包括：在与携带针对所述一个或多个源对象的数据的分组相同的时间间隔中发送携带根据所述一个或多个源对象来生成的FEC修复数据的分组。在另一方面中，在所述广播网络上发送与所述源流相关联的所述相关源对象的集合中的所述源对象可以包括：独立于所述源对象的相应修复对象来发送所述源对象。在另一方面中，所述方法可以包括：使用会话描述协议(SDP)信息来区分源对象与所述源对象的相应修复对象。

在另一方面中，所述相关源对象的集合中的至少一个源对象可以包括文件的字节范围。在另一方面中，统一资源定位符(URL)与所述文件相关联，所述方法还包括：经由所述URL和所述字节范围来对所述至少一个源对象进行标识。在另一方面中，所述相关源对象的集合中的至少一个源对象是文件。在另一方面中，URL与所述文件相关联，所述方法还包括：经由所述URL来对所述至少一个源对象进行标识。在另一方面中，所述相关源对象的集合中的至少一个源对象可以包括文件的字节范围和超文本传输协议(HTTP)报头。在另一方面中，所述源对象中的至少一些源对象可以包括HTTP报头、相关联的文件和HTTP报尾。

在另一方面中，所述方法可以包括：确定针对与所述源流相关联的源对象的集合的源流声明，使得所述源流声明可以包括适用于以信号发送在针对与所述源流相关联的所述源对象的集合的位置、名称、可用性时间或其它元数据之间的关系的信息。在另一方面中，发送所述相关源对象的集合可以包括：经由多媒体广播多播服务(MBMS)来发送所述相关源对象的集合。在另一方面中，发送所述相关源对象的集合可以包括：经由单向传输的文件传递(FLUTE)来发送所述相关源对象的集合。在另一方面中，发送所述相关源对象的集合可以包括：发送所述源对象而不发送前向纠错 (FEC)信令信息。在另一方面中，所述源对象中的至少一些源对象包括文件的字节范围和HTTP报头。

各个方面还包括在广播网络上发送一个或多个源对象的方法，所述方法包括：接收整个文件的部分；在接收到所述整个文件之前，基于所接收到的部分来生成源对象；以及在接收到所述整个文件之前，将所生成的源对象发送给接收方设备。在一方面中，在接收所述整个文件之前将所生成的源对象发送给所述接收方设备可以包括：以与所述整个文件的数据顺序不同的顺序来发送针对所生成的源对象的数据。在另一方面中，接收所述整个文件的部分可以包括接收以下文件的部分：所述文件可以在所述文件的开始处包括文件大小，并且其中，源对象的数据是以以下顺序来发送的：使得跟在所述文件大小后面的、所述文件的至少一些数据是在所述文件大小之前发送的。

在另一方面中，源对象可以包括HTTP报头和相关联的文件。在另一方面中，源对象可以包括HTTP报头、相关联的文件和HTTP报尾。在另一方面中，所述方法可以包括：确定针对与源流相关联的源对象的集合的源流声明，其中，所述源流声明以信号发送在针对与所述源流相关联的所述源对象的集合的位置、名称、可用性时间或其它元数据之间的关系。在另一方面中，所述方法可以包括：使用模板在所述源流声明中以信号发送关系信息。

在另一方面中，所述方法可以包括：在与所述源流相关联的至少一个相关源对象之前将针对所述源流的所述源流声明的部分发送给所述接收方设备。在另一方面中，在与所述源流相关联的至少一个相关源对象之前将针对所述源流的所述源流声明的部分发送给所述接收方设备可以包括：发送可以包括以下各项中的至少一项的部分：定时信息；统一资源标识符 (URI)；以及对用于源对象的解密密钥进行标识的信息。在另一方面中，在与所述源流相关联的至少一个相关源对象之前将针对所述源流的所述源流声明的部分发送给所述接收方设备可以包括：在发送与所述源流相关联的至少一个源对象之前将所述源流声明的一部分在带外发送给所述接收方设备；以及在带内与源对象一起发送所述源流声明的另一部分。

在另一方面中，在带内与所述源对象一起发送所述源流声明的另一部分可以包括：发送对针对所述源对象的数据的最后部分的指示。在另一方面中，将所述源流声明的部分提供给所述接收方设备可以包括：在不发送文件传递表的情况下，经由单向传输协议来发送所述源流声明的部分。在另一方面中，在接收到所述整个文件之前将所生成的源对象发送给所述接收方设备可以包括：经由多媒体广播多播服务(MBMS)来发送相关源对象的集合。在另一方面中，在接收到所述整个文件之前将所生成的源对象发送给所述接收方设备可以包括：经由单向传输的文件传递(FLUTE)来发送相关源对象的集合。

在另一方面中，发送相关源对象的集合可以包括：独立于所述源对象的相应修复对象来发送所述源对象。在另一方面中，所述方法可以包括：使用会话描述协议(SDP)信息来区分源对象与所述源对象的相应修复对象。在另一方面中，在接收到所述整个文件之前将所生成的源对象发送给所述接收方设备可以包括：发送所述源对象而不发送FEC信令信息。

在另一方面中，所述方法可以包括：执行FEC操作以对单独的源对象的部分进行保护。在另一方面中，所述方法可以包括：利用多个FEC编码来发送所述单独的源对象。在另一方面中，所述方法可以包括：在修复分组报头中添加针对源对象的受保护部分的TOI或OSN；以及在所述受保护部分的传输源块的结尾处添加所述受保护部分的字节范围。在另一方面中，所述方法可以包括：在源对象的要保护的部分的开始处添加源符号；以及在修复分组报头中添加受保护部分的字节范围。

在另一方面中，所述方法可以包括：在修复分组报头内添加源对象的受保护部分的字节范围的起始位置和所述字节范围所覆盖的符号的数量；以及在传输源块的结尾处添加所述受保护部分的以字节或八位字节为单位的大小。在另一方面中，在接收到所述整个文件之前将所生成的源对象发送给所述接收方设备可以包括：经由单向协议将源对象作为HTTP实体报头和HTTP实体主体的组合传递给所述接收方设备，使得所述源对象适用于在所述接收方设备中作为常规地传递的HTTP资源来使用。

另外的方面可以包括一种通信系统，所述通信系统包括发射机和计算设备，所述计算设备被配置有用于执行与上面所讨论的方法相对应的各种操作的处理器可执行指令。

另外的方面可以包括一种通信系统，所述通信系统具有用于执行与上面所讨论的方法操作相对应的功能的各种单元。

另外的方面可以包括一种具有存储在其上的处理器可执行指令的非暂时性计算机可读存储介质，所述处理器可执行指令被配置为使得通信系统中的计算设备执行与上面所讨论的方法操作相对应的各种操作。

附图说明

并入本文并且构成本说明书的一部分的附图示出了本发明的示例性实施例，并且连同上面所给出的总体描述和下面所给出的具体实施方式，用以解释本发明的特征。

图1是示出了适用于在各种实施例中使用的一种移动多媒体通信系统的框图。

图2是示出了通过可以由各种实施例使用的各种硬件和软件协议层以及模块的信息流的栈图。

图3是根据各种实施例，示出了示例性的广播通信系统的各种逻辑组件和功能组件的框图，其中该示例性的广播通信系统适用于向移动接收方设备传递多媒体内容，使得每个对象与流相关联。

图4是根据实施例，示出了被打包成多个源分组的源对象的框图。

图5是示出了当前的FLUTE对象和实施例FLUTE对象之间的区别的框图。

图6是包括HTTP报头字段和可用性时间字段的实施例FLUTE对象的图示。

图7A是包括源对象字段、填充字段和大小/长度(F)字段的实施例传输对象的图示。

图7B是包括源对象字段、填充字段和字节范围字段的实施例传输对象的图示。

图8A和图8B是示出了当前的FLUTE修复前向纠错(FEC)有效载荷 ID和各种实施例修复FEC有效载荷ID之间的区别的框图。

图9A和图9B是根据实施例，示出了适用于在执行针对同步的源流的前向纠错(FEC)中使用的通信分组中的数据字段的框图。

图10是根据实施例，示出了适用于在执行针对两个同步的源流的前向纠错(FEC)操作中使用的通信分组的数据字段的框图。

图11是根据实施例，示出了适用于在执行针对两个不同步的源流的前向纠错(FEC)操作中使用的通信分组的数据字段的框图。

图12是根据实施例，示出了适用于在执行针对三个不同步的短源流的前向纠错(FEC)中使用的通信分组的数据字段的框图。

图13A是示出了在广播或多播网络上传送对象流中的信息的实施例服务器方法的过程流程图。

图13B是示出了在广播或多播网络上接收对象流中的信息并确定是否已接收到整个源对象或者对象的一部分是否从所接收到的源分组中缺失的实施例接收方设备方法的过程流程图。

图14A和图14B是根据各种实施例，示出了适用于传送内容的广播通信系统的各种逻辑组件和功能组件的框图。

图15是示出了在被配置为基于两个源对象来生成前向纠错(FEC)修复分组的实施例FEC框架中的各种结构、数据字段、通信分组、转换和信息流的框图。

图16是适用于与实施例中的任何实施例一起使用的接收方设备的系统框图。

图17是适用于与实施例中的任何实施例一起使用的服务器计算机的系统框图。

具体实施方式

将参考附图详细描述各种实施例。只要有可能，贯穿附图将使用相同的附图标记来指代相同或相似的部件。对特定例子和实现方式的引用是出于说明性的目的，并非旨在限制本发明或权利要求书的范围。

概括地说，各种实施例可以提供用于在广播信道上和/或经由广播网络向接收方设备高效地传递内容(例如，多媒体流、音频-视频流、视频文件、文本等)的系统、设备、方法和存储了软件的非暂时性计算机可读介质。各种实施例可以提供相对于现有的广播解决方案的多种特征、增强、改善和益处。

例如，实施例可以包括被配置为以以下方式来向接收方设备传送内容的组件(例如，服务器、接收方设备、软件应用、模块、过程等)：减小在广播网络上传送的信息量，减小通信所消耗的网络带宽量，满足针对所传送的单独对象的精确的定时要求，并且使得每个接收方设备能够接收、解码并呈现内容而不消耗该接收方设备过量的电池或处理资源。

实施例还可以包括被配置为进行以下操作的组件：经由FLUTE和/或在广播网络上，在单个流、串流或通信信道中发送相关对象的流(或相关对象的集合或群组)，使得相关对象可以由接收方设备基于它们的彼此关系进行接收、解码和处理。

实施例可以包括被配置为进行以下操作的组件：发送信令信息(例如，关于信道建立、安全、内容传递等的信息)，以协调要如何在广播系统上传递内容，以便减小在网络上传送的信息量以及由接收方设备在呈现内容时进行接收、解码和纠错的信息量。

实施例可以被配置为进行以下操作的组件：在将源对象发送给接收方设备的时间之前和/或源对象由接收方设备接收到的时间之前，将对象信息发送给接收方设备(例如，FLUTE接收机)。

实施例可以包括被配置为进行以下操作的组件：在信息变得可用于样本或对象时，对样本或对象进行广播，并且达到针对每个样本/对象的非常精确的定时，同时保持与现有的基于FLUTE的解决方案和系统兼容，从而实现对现有的基于分组的流式传输系统所提供的功能和现有的基于广播对象的流式传输系统所提供的那些功能的混合/组合。

实施例可以包括被配置为进行以下操作的组件：实现基于FLUTE的通信而不使用文件传递表(FDT)。在一个实施例中，所述组件可以被配置为：经由FLUTE和/或在广播网络上传送对象而不对FDT对象进行广播，并且不要求接收方设备针对进行请求或呈现的每个真实对象(例如，源对象) 接收两个对象。

实施例可以包括被配置为进行以下操作的组件：经由FLUTE和/或在广播网络上传递对象，使得对象传递与现有的DASH系统的功能、操作或要求很好地相结合。在一个实施例中，所述组件可以被配置为：通过对源对象进行广播，在广播传递网络上经由流对象传递机制来传递DASH内容，使得它们与DASH表示的DASH区段兼容，或者使得它们可以被解释为 DASH表示的DASH区段。在一个实施例中，所述组件可以被配置为：以信号发送基于FLUTE的对象是DASH区段，并且对基于FLUTE的对象打包，使得接收方设备可以对基于FLUTE的对象进行接收和处理，就好像它们是DASH区段一样。

实施例可以包括被配置为进行以下操作的组件：对对象或格式中的信令信息进行生成、广播或接收，该信令信息包括由现有的基于FLUTE的对象和基于DASH的区段提供的特征/特性的组合。

实施例可以包括被配置为执行组块(chunk)传递操作和/或组块接收操作的组件。

实施例可以包括被配置为传送可变大小的源分组的组件，其中所述大小是由发送方任意确定的。

实施例可以包括被配置为执行前向纠错(FEC)对象绑定操作的组件。

实施例可以包括被配置为进行以下操作的组件：独立于源对象的相应修复对象(例如，FEC对象)来传递源对象。所述组件可以经由数据分组内在带内携带的信息来区分源流与修复流和/或经由它们的会话描述协议 (SDP)信息来区分源流与修复流。

实施例可以包括被配置为进行以下操作的组件：传送不包括FEC语义 (例如，FEC编码ID、“无编码FEC”语义等)的源内容，传递源内容而无需FEC语义，和/或传递源内容而不以信号发送FEC(即，发送FEC信令信息)。这允许未装备有FEC能力的接收方设备经由FLUTE和/或在广播网络上接收、解码和恢复源对象。

实施例可以包括被配置为进行以下操作的组件：执行FEC操作以对单独的源对象或者DASH区段的部分进行保护，从而使得能够利用多个FEC 编码来传递源对象，并且使得能够在接收方设备中已接收到整个对象之前呈现对象。

实施例可以包括被配置为进行以下操作的组件：打包并传送针对源对象的信令和对象信息，使得对象的部分可以与不同的标记相关联。所述组件可以被配置为：使用分层编码传输(LCT)码点字段来对该分组(即，包含原始源对象的分组)中所携带的内容的“类型”进行标识。

实施例可以包括被配置为进行以下操作的组件：使用字节范围来以信号发送或标识源对象的受FEC保护的部分。

实施例可以包括被配置为进行以下操作的组件：基于完整源文件/对象的子集、统一资源定位符(URL)或统一资源标识符(URI)，来传递和保护源对象。

实施例可以包括被配置为进行以下操作的组件：在修复分组报头中(例如，在报头扩展中)添加针对源对象的受保护部分的传输对象标识符(TOI) /对象序列号(OSN)值，并且在传输源块的结尾处添加源块的受保护部分的字节范围。所述组件还可以被配置为：在要保护的源对象的一部分的开始处(而不是在源对象的刚开始处)添加或开始源符号；以及直接地在修复分组报头内提供文件、传递或源对象的受保护部分的实际字节范围。所述组件还可以被配置为：直接地在修复分组报头内添加字节范围的起始位置和该字节范围所覆盖的符号的数量；以及在传输源块(例如，FEC编码对象)的结尾处添加受保护源对象的部分以字节(或者，在本公开内容中等效地，八位字节)为单位的大小。所述组件还可以被配置为：针对源对象的每个受保护部分，生成具有修复分组报头的修复分组，所述修复分组报头包括源对象传输对象标识符(TOI)或对象序列号(OSN)、源对象内的开始字节位置和源对象内的结束字节位置。

实施例可以包括被配置为进行以下操作的组件：执行对象传递操作以便使得源对象能够包括完整的HTTP响应。所述组件还可以被配置为：发送HTTP实体主体和报头(例如，作为传递对象)，以便允许动态地分发与对象(或对象的字节范围)相关联的数据。

实施例可以包括被配置为进行以下操作的组件：在服务器或发送设备中接收到或生成整个文件或对象之前，提前开始发送数据。

实施例可以包括被配置为进行以下操作的组件：在接收到或生成文件/ 对象的所有部分之前和/或独立于FEC方案，乱序地发送文件/对象的部分。在一个实施例中，这可以经由LCT机制，通过使用LCT的扩展能力来实现。

实施例可以包括被配置为进行以下操作的组件：使用模板和模板化技术来以信号发送在与要传递的对象的集合或序列相关联的位置、名称、可用性时间和其它元数据之间的关系。在一个实施例中，所述组件可以被配置为：使用源流声明来标识对象的URI；以及确定将何时在广播/多播信道上发送和/或接收对象。在一个实施例中，所述组件可以被配置为：向接收方设备发送一次性的静态文件传递描述符，并且使用动态传递协议中的报头字段来创建动态信息，其中该信息对有效的统一资源标识符(URI)进行标识。

实施例可以包括以下的组件：所述组件被配置为执行上面提到的操作中的任何或所有操作，同时符合当前的FLUTE标准的要求和/或同时保持与实现当前的FLUTE标准的其它组件的后向兼容。

本文使用词语“示例性的”来表示“用作示例、实例或说明”。本文中被描述为“示例性的”任何实现方式不一定解释为比其它实现方式优选或有利。

本文使用术语“接收方设备”来指代以下各项中的任意一项或所有项：蜂窝电话、智能电话、多媒体播放器、个人数字助理(PDA)、计算设备、服务器计算机、个人计算机、膝上型计算机、智能本、超级本、平板计算机、掌上型计算机、无线电子邮件接收机、多媒体互联网使能蜂窝电话、无线游戏控制器，以及包括用于发送和接收信息的通信电路、存储器和可编程处理器的类似电子设备。

本文使用术语“广播”来表示数据(多媒体流、文件、信息分组等) 的传输，使得数据能够同时由大量的接收设备来接收，并且包含单播技术、多播技术以及适用于在单一传输中向一个或许多接收方设备发送信息的其它传输技术。由于广播网络仅能够进行发送并且不具有直接的返回通信链路，因此这种网络在本文中还被称为“仅前向链路”(FLO)广播网络，以区分这种通信网络与双向无线通信网络(例如，蜂窝电话系统和无线广域网(例如，WiFi、WiMAX等))。

本文中术语“传递对象”和“源对象”可以互换使用，以对包括或被表示为元数据或数据、并且可以使用无线或广播通信技术来传送的任何自包含(self-contained)单元进行描述。源对象的例子包括文件、HTTP实体、字节范围、实体报头和包含实体报头所指示的完整文件的实体主体、指示文件的字节范围的实体报头、以及包含实体报头所指示的文件的部分的实体主体，等等。

如本申请中所使用的，术语“组件”、“模块”、“系统”、“服务”、“编码器”、“发送方”、“接收方”等旨在包括与计算机相关的实体，例如但不限于，被配置为执行特定的操作或功能的硬件、固件、硬件和软件的组合、软件或执行中的软件。例如，组件可以是但不限于，在处理器上运行的进程、处理器、对象、可执行文件、执行的线程、程序和/或计算机。通过说明的方式，在计算设备上运行的应用和该计算设备二者可以被称为组件。一个或多个组件可以驻留在进程和/或执行的线程内，并且组件可以集中在一个处理器上或者分布在两个或更多个处理器之间。此外，可以通过其上存储有各种指令和/或数据结构的各种非暂时性计算机可读介质来执行这些组件。组件可以通过本地和/或远程过程、函数或程序调用、电子信号、通信消息、数据分组、存储器读/写、以及其它已知的网络、计算机、处理器和/或进程相关的通信方法来进行通信。

多种不同的广播服务、标准和技术在将来是可用的或可预期的，所有这些可以实现各种实施例并从中获益。这种服务、标准和技术包括例如，多媒体广播/多播服务(MBMS)、增强型多媒体广播/多播服务(eMBMS)、增强型多播广播服务(EMBS)、全球广播服务(GBS)、开放移动联盟移动广播服务使能器套件(OMA BCAST)、数字视频广播互联网协议数据广播(DVB-IPDC)、数字视频广播-手持(DVB-H)、数字视频广播-卫星服务至手持(DVB-SH)、数字视频广播-手持2(DVB-H2)、高级电视系统委员会-移动/手持(ATSC-M/H)、中国多媒体移动广播(CMMB)、高级电视系统委员会陆地(ATSC-T)和MPEG媒体传输(MMT)。这些广播标准、服务和技术中的每一个包括例如适用于传送数据、信令和/或内容消息的广播通信信道。

除了上面所提到的广播服务之外，还可以经由各种蜂窝和无线通信服务和标准，直接地向单独的移动接收方设备传递多媒体和其它服务，这些蜂窝和无线通信服务和标准中的任何或所有服务和标准可以实现各种实施例并从中获益。这种服务和标准包括，例如，第三代合作伙伴计划(3GPP)、长期演进(LTE)系统、第三代无线移动通信技术(3G)、第四代无线移动通信技术(4G)、全球移动通信系统(GSM)、通用移动电信系统(UMTS)、 3GSM、通用分组无线服务(GPRS)、码分多址(CDMA)系统(例如， cdmaOne、CDMA1020TM)、增强型数据速率GSM演进(EDGE)、高级移动电话系统(AMPS)、数字AMPS(IS-136/TDMA)、演进数据优化(EV-DO)、数字增强型无绳电信(DECT)、微波接入全球互通(WiMAX)、无线局域网(WLAN)、Wi-Fi受保护接入I&II(WPA1、WPA2)以及综合数字增强型网络(iden)。这些技术中的每种技术涉及例如对语音、数据、信令和/或内容消息的发送和接收。

应当要理解的是，对与单独的标准或技术相关的术语和/或技术细节的任何引用仅是出于说明性的目的，并非旨在将权利要求书的范围限制为特定的通信系统或技术，除非在权利要求字面语言中进行了专门地记载。

通常，在接收方设备上接收、解码和显示内容的操作消耗接收方设备大量的可用资源(CPU操作、电池功率、存储器等)。这其中部分原因是由于接收方设备必须要接收、解码和纠错的大量的数字信息。各种实施例可以减小接收方设备在接收或呈现内容时必须接收、解码和纠错的信息量。

当前存在多种用于减小当传递多媒体内容时必须要在网络上传送的信息量的容易获得的压缩技术(例如，活动图像专家组“MPEG”压缩)。但是，不论这种技术所使用的压缩方法的效率如何，为了向用户提供满意的用户体验，必须在网络上传送大量的信息。因此，单靠现有的压缩技术不能充分地减小在网络上传送的信息量或者极大地改善接收方设备的性能或功耗特征。

通常，存在使得传递网络的状态随时间变化的网络波动(例如，资源可用性的变化)。这些波动会使得接收方设备丢弃分组、欠运行缓冲区、或者以其它方式对用户体验产生负面影响。诸如DASH之类的各种技术通过对发送给接收方设备或由接收方设备接收的流的比特速率或质量进行调整，来允许接收方设备的客户端应用(例如，媒体播放器等)对网络状况的这种变化做出响应。这些技术通常包括内容生成服务器，该内容生成服务器读入原始视频文件并生成该文件的多个版本(被称为“表示 (representation)”)以便在生成式互联网协议(IP)网络上进行传递。

DASH是用于描述经多速率编码的多媒体的web兼容的国际标准，其允许客户端应用(例如，媒体播放器等)基于网络动态、资源可用性和/或其它适当的因素，来动态地选择要接收媒体呈现中的哪些部分。DASH支持将每个表示划分成区段，该区段对要传递给接收方设备的数据进行编码。 DASH通常使用媒体呈现描述(MPD)，MPD是区段可用性时间轴，其宣告了区段、区段可用的时间以及对包括区段的媒体的回放速率的指示。在当前的系统中，经由空中(OTA)传递技术来向接收方设备提供MPD。

FLUTE是用于文件的单向传递的传输层技术/协议，其特别适用于与广播/多播传递网络一起使用。FLUTE解决方案或系统可以包括服务器和接收方设备，所述服务器和接收方设备实现了互联网工程任务组(IETF)请求注解(RFC)3926和RFC 6726中所定义的通信机制。

现有的FLUTE解决方案彼此独立地传递源对象(例如，文件、区段等)，并且通常不支持在相同的流中所包括的相关源对象之间建立关系。因此，使用现有的解决方案，广播网络中的服务器必须在源对象的传递之前或期间，独立地向接收方设备以信号发送(即，发送包括信令或控制信息的通信消息)每个对象的参数、对象应当存储的位置、将何时传递对象以及其它类似信息。根据FLUTE标准(RFC 3926和RFC 6726)，针对要传递给该接收方设备的每个源对象，服务器必须发送这种信令信息。然而，针对每个对象来传送这种信令信息消耗网络过量的可用带宽并且要求接收方设备执行另外的处理、同步或存储器存取操作，任何这些操作会使接收方设备的性能和/或功耗特性变差或降低用户体验。此外，如果信令信息中的任何信令信息丢失，则通常不能恢复对象。

各种实施例可以包括用于对广播网络中的通信进行管理、以便减小在传递内容或源对象流时所传送的信息量的方法，以及被配置为实现所述方法的设备和系统。

各种实施例可以提供一种传递框架，所述传递框架适用于：经由FLUTE 和/或在广播网络上，在单个流、串流或通信信道中发送相关对象的流(或对象的相关群组的集合)，使得可以基于对象的彼此关系来对它们进行接收、解码和处理。这与现有的基于FLUTE的解决方案形成对比，现有的基于FLUTE的解决方案不对流中的FLUTE对象之间的关系进行标识，将不相关的对象打包到相同的流中，并且要求接收设备接收独立的信令信息和数据来对每个FLUTE对象进行解码。

各种实施例还可以包括网络广播服务器，所述网络广播服务器被配置为：发送信令信息(例如，关于信道建立、安全、内容传递等的信息)，以便以减小在网络上传送的信息量的方式来协调要如何在广播系统上传递内容。

用于经由广播系统来实现对象传递的现有解决方案通常要求广播网络中的服务器针对要在广播网络上传送的每个对象，独立地发送信令信息。这其中部分原因是由于现有解决方案不能够充分地对在广播网络上和/或在流或通信信道内传送的两个或更多个对象之间的关系进行建立或标识。出于这些原因和其它原因，现有解决方案通常在与包括内容信息的文件/对象不同的文件/对象中发送信令信息。在基于FLUTE的系统中，这种信令信息通常包括在文件传递表(FDT)中，其中FDT描述了与要在文件传递会话内传递的文件相关联的各种属性。

现有的FLUTE解决方案在与包括文件传递表(FDT)所描述的内容的对象分离的对象中向接收方设备发送FDT。因此，使用现有的FLUTE解决方案，要求接收方设备针对所请求的或所呈现的每个源对象(例如，视频的区段)接收两个对象(例如，视频的区段和对该视频的区段进行描述的 FDT)。此外，由于如果包括FDT的分组/对象丢失或丢弃，则接收方设备将不能够对源对象(例如，视频的区段)中所包括的信息进行恢复或解码，因此现有的FLUTE解决方案通常对每个FDT对象进行多次广播，以提高接收到FDT对象的概率。对FDT对象进行这种冗余广播是对广播资源的低效使用，这种冗余广播会消耗网络过量的可用带宽，并且具有其它缺点，例如当调到服务时更久的启动延迟。

各种实施例可以包括被配置为进行以下操作的组件：经由FLUTE和/ 或在广播网络上传送对象(例如，视频的区段等)而不对FDT对象进行广播并且不要求接收方设备针对所请求或所呈现的每个真实对象(即，源对象)接收两个对象。在一个实施例中，信令信息和对象信息的至少一部分可以在带内一起传送和/或在单个流或信道中传送。在带内传送这种信息可以减小在网络上传送的信息量，并且是对网络资源的更高效的使用。

各种实施例可以包括被配置为进行以下操作的网络服务器：在源对象被发送给接收方设备的时间之前和/或在源对象由接收方设备接收到的时间之前，将对象信息发送给接收方设备(例如，FLUTE接收机)。这种对象信息可以包括：定时信息、对文件的名称和位置进行指定的URI(例如，文件将在何处由应用进行引用或访问)、在对象是经加密后传递的情况下要使用哪些密钥来解密对象、以及与要传递的源对象相关的其它标识信息。可以用压缩的形式来提供针对对象的相关序列(或对象的集合)的这种对象信息。在一个实施例中，可以在源对象之前将对象信息的部分在带外发送给接收方设备，并且可以在带内与源对象一起发送该对象信息的部分，而不对任何FDT进行广播。以此方式，各种实施例可以完全消除在基于FLUTE 的通信中使用FDT的需要。

各种实施例可以包括被配置为进行以下操作的网络服务器：打包并传送针对源对象的信令和对象信息，以便允许接收方设备针对源对象的接收做出更明智的决策和更优的计划。这可以通过服务器在发送要发送给接收方设备的对象之前和/或在接收方设备中接收到这些对象之前，向接收方设备发送关于这些对象的信息来实现。提前获得这种信息有助于接收方设备进行更优的决策制定和计划。

各种实施例可以包括被配置为进行以下操作的组件：将经由FLUTE在广播网络上传递的对象链接到接收方设备的一个或多个客户端应用。

各种实施例可以包括被配置为进行以下操作的组件：经由FLUTE和/ 或在广播网络上传递对象，使得对象传递与现有的DASH系统的功能、操作或要求很好地相结合。

各种实施例可以包括被配置为进行以下操作的组件(例如，广播网络中的服务器等)：经由流对象传递机制，在广播传递网络上传递DASH内容。在一个实施例中，这可以通过对源对象进行广播，使得它们与DASH表示的DASH区段兼容或者可以被解释为DASH表示的DASH区段来实现。

各种实施例可以包括被配置为进行以下操作的网络服务器：以信号发送基于FLUTE的对象是DASH区段；以及对基于FLUTE的对象打包，使得接收方设备可以对基于FLUTE的对象进行接收和处理，就好像它们是 DASH区段一样。

各种实施例可以包括被配置为进行以下操作的组件：对对象或格式中的信令信息进行生成、广播或接收，该信令信息包括现有的基于FLUTE的对象和基于DASH的区段所提供的特征/特性的组合。

各种实施例可以包括被配置为进行以下操作的组件：执行组块传递操作和/或组块接收操作。这种组块传递操作可以允许广播网络中的服务器在对象由源编码器和/或封装单元或模块完全生成之前开始发送该对象。例如，广播网络中的服务器可以发送将包括10秒的视频的对象而无需为了使内容变得可用而等待完整的10秒。也就是说，服务器可以执行组块传递操作以在服务器接收到视频的其它部分之前开始发送视频的第一部分，而不是为了使内容变得可用而等待完整的10秒。在一个实施例中，服务器可以将接入单元或网络抽象层单元或样本的封装版本发送成单独的源分组，以便使发送延迟最小化。类似地，接收方设备可以执行组块接收操作，以在接收方设备中接收到整个源对象之前开始接收、解码并使用对象。例如，接收方设备可以被配置为：执行组块接收操作，以在接收方设备中接收到包含视频的整个对象之前开始播放视频内容的部分。

各种实施例可以包括被配置为支持可变大小的源分组的组件。也就是说，现有的FLUTE标准和解决方案要求每个源分组和每个修复分组是相同大小的(或至少是预先确定的符号大小的倍数)。与现有的FLUTE标准和解决方案形成对比，各种实施例可以包括被配置为进行以下操作的组件：生成、发送、接收、解码或使用可变大小的源分组。这种可变大小的分组中所携带的内容的边界可以完全任意地设置和/或可以与内容的底层结构对齐，例如，与视频内容的接入单元/模块或网络抽象层单元/模块结构对齐。当源分组边界可以与符号结构对齐时(例如，当使用FEC时等)，使用这种可变大小的分组是特别有利的。此外，丢失这种分组仅会影响单个接入单元/模块而不是多个单元/模块，并且经适当配置的接收方设备可以生成部分地接收的对象，该部分地接收的对象可以由接收方设备(或接收方设备的软件应用)进行处理以呈现接收到的内容并提供适度下降的质量。

各种实施例可以包括被配置为进行以下操作的组件：执行适用于传送不包括FEC语义的源内容的操作。也就是说，现有的FLUTE标准和解决方案通常要求以信号发送并执行源传递操作，使得它们与用于恢复操作的 FEC编码和FEC方案紧密联系。这包括但不限于，使用固定大小的源符号 (其要求除了最后分组外的所有源分组是源符号大小的倍数)，使用源符号作为用于应用FEC的基本单元，等等。出于这些原因和其它原因，现有的解决方案要求即使在不支持、不要求或不使用FEC编码的情况下也使用“无编码FEC”语义。但是，未装备有FEC能力的接收方设备可能不能够接收、解码或恢复包括FEC语义的对象。

各种实施例可以包括被配置为进行以下操作的服务器：传递源内容而无需FEC语义(和/或无需以信号发送FEC)，使得未装备有FEC能力的接收方设备可以接收、解码并恢复源对象。在一个实施例中，所述服务器可以被配置为：在第一对象中传递内容信息并且在第二对象中传递FEC信令信息。在一个实施例中，第一对象和第二对象可以一起在带内传递。

各种实施例可以包括被配置为进行以下操作的组件：执行前向纠错 (FEC)对象绑定操作。各种实施例可以包括被配置为进行以下操作的组件：对多个对象提供FEC保护。在一个实施例中，这可以经由FEC对象绑定操作和将FEC语义的传递从源内容中分离的操作的组合来实现(或使其成为可能)。

各种实施例可以包括被配置为进行以下操作的组件：执行前向纠错 (FEC)操作以对单独的源对象或者DASH区段的部分进行保护，从而使得能够利用多个FEC编码来传递源对象，提供了更大的灵活性并且使得能够在接收到整个对象之前呈现或“播出”对象。在这种实施例中，可以对部分的对象、对独立源对象的字节范围、和/或对来自不同流中的不同源对象的字节范围的组合提供FEC保护。例如，组件可以被配置为：对源对象的前三(3)帧提供独立的FEC保护，对源对象的接下来的五(5)帧提供独立的FEC保护，对源对象的接下来的六(6)帧提供另外的独立的FEC 保护，以及对源对象的最后十帧提供另外的独立的FEC保护。这种方式的 FEC保护可以允许系统更好地支持对可变大小的源分组或对象的传输，允许接收方设备在接收到整个对象之前开始对对象进行增量式解码，允许传输较大的对象，减小对象/流中所包括的独立的刷新帧的数量或频率，改善与流式传输内容(特别是由大型对象构成的内容)相关联的延迟，减小由流消耗的带宽量，并且在系统能够提供FEC保护的粒度上提供更多的灵活性和控制。

各种实施例可以包括被配置为进行以下操作的组件：打包并传送针对源对象的信令和对象信息，使得对象的部分可以与不同的标记相关联。例如，对象的开始部分可以被标记为“类型A”，紧接着是被标记为“类型B”的部分，紧接着是被标记为“类型A”的另一部分。这可以允许视频层组件(例如，视频层解码器等)对对象的各个部位或部分进行识别、归类或分类，其中所述各个部位或部分是相同类型的、相关的、可独立播放的，等等。对象标记还可以实现可能对视频层组件有用的信息的其它应用。在一个实施例中，可以经由码点向接收方设备传送或以信号发送针对源对象的各个部位/部分的标记信息，其中码点定义、包括或指定各种属性。

各种实施例可以包括被配置为进行以下操作的组件：使用字节范围来以信号发送或标识源对象的受FEC保护的部分。这些组件还可以被配置为：利用类型标识符或数据字段来对包含受FEC保护的部分的字节范围的分组进行标记。对源对象的部分的类型标识(一旦在接收方处恢复源对象，该类型标识通常对消耗该源对象的更高级应用来说是有价值的)可以结合系统来使用，以对各个字节范围提供FEC保护，从而能够提供对不同类型的源对象的部分的FEC保护。这允许源对象中与源对象内的数据类型相对应的每一部分使用FEC独立地进行恢复，当与类型相对应的源对象的不同部分对消耗应用是有用的时，这种独立恢复对该消耗应用可能是有价值的(即使当源对象的其它部分由于还未抵达接收方处而不可用，或者由于不足的 FEC保护而将永远不可用时)。但是，对源对象的部分的FEC保护和将源对象的不同部分的标识为不同的类型可以彼此独立地使用。例如，可以对源对象的不同类型的两个连续部分提供FEC保护，或者可以对与不同类型的不同部分未对齐的源对象的部分提供FEC保护，或者可以对未被分类成各类型的源对象的不同部分提供FEC保护。

在各种实施例中，对源对象的传递和保护可以基于完整源文件的子集。例如，在一个实施例中，组件可以被配置为：将某种字节范围视作为单独的传递对象(或源对象)。可以经由元数据(例如，动态元数据(DMD)) 来传送、发送或以信号发送与该字节范围相关联的信令信息。例如，可以向动态元数据中的对象分配Content-Range(内容-范围)报头，该 Content-Range报头允许系统将对象与在源数据的Content-Location(内容- 位置)字段中所定义的URL的Content-Range进行关联。在该情况下，作为对FLUTE的扩展，可能在传输对象标识符(TOI)和URL之间不存在一一映射，但是TOI可以映射到URL和字节范围的组合。在一个实施例中，源对象可以划分成多个保护对象或受FEC保护的部分。

各种实施例可以包括被配置为进行以下操作的组件：在修复分组报头中(例如，在报头扩展中)添加针对源对象的受保护部分的传输对象标识符(TOI)/对象序列号(OSN)值；以及在传输源块的结尾处添加源块的受保护部分的字节范围。其它实施例可以包括被配置为进行以下操作的组件：在要保护的源对象的部分的开始处(而不是在源对象的刚开始处)添加或开始源符号；以及直接地在修复分组报头内提供文件、传递或源对象的受保护部分的实际字节范围。在另外的实施例中，组件可以被配置为：直接地在修复分组报头内添加字节范围的起始位置和该字节位置所覆盖的符号的数量；以及在传输源块(例如，FEC编码对象)的结尾处添加受保护的源对象的部分的以字节(或八位字节)为单位的大小。该优选实施例要求比上面所讨论的实施例更少的修复分组报头字节，不浪费修复符号，并且在传输源块的第一个符号中不具有填充字节。

各种实施例可以包括被配置为进行以下操作的组件：针对源对象的每个受保护部分，生成具有修复分组报头的修复分组，所述修复分组报头包括以下各项：源对象TOI(或OSN)、源对象内的开始字节位置和源对象内的结束字节位置。在一个实施例中，针对源对象的每个受保护部分，修复分组报头可以是10个字节(例如，两个字节用于TOI，四个字节用于开始字节位置，并且四个字节用于结束字节位置)。在一个实施例中，这些映射和其它映射可以包括在元数据文件中，其中该元数据文件在单独的文件或对象中传递给接收方设备。在优选的实施例中，组件可以被配置为：以信号发送开始字节位置和对象以符号为单位的大小。在一个实施例中，可以经由元数据来对TOI进行映射。在一个实施例中，以字节为单位的受保护对象大小可以包括在源块(例如，FEC编码对象)中已知的位置处或者由接收方以信号发送的位置处。在一个实施例中，组件可以被配置为：向源对象的部分应用FEC保护，所述FEC保护在其开始字节位置处开始。各种实施例可以定义多种扩展报头，这些扩展报头使得系统能够以信号发送不同类型的大小(例如，以符号为单位的大小)、传递/源对象的开始地址(例如，16比特、32比特)和以符号为单位的大小等。

各种实施例可以包括被配置为进行以下操作的组件：使用分层编码传输(LCT)码点字段来对该分组(即，包含原始源对象的分组)中所携带的内容的“类型”进行标识。在一个实施例中，该信息可以包括在码点中。在一个实施例中，组件可以被配置为：对传输源对象受FEC保护的字节范围和传输源对象的部分的“类型”之间的关系进行标识。例如，传输源对象的字节范围可以用若干类型(例如，一般地，类型X，类型Y，类型Z) 中的一种类型来标记，并且可以生成每个源分组，使其仅包括一种类型的数据。举另一个例子，类型X的字节范围12,000至19,999可以包括在七(7) 个源分组中(每个源分组在码点字段中被标记为类型X)，前六(6)个源分组可以包括1200个字节并且第七(7)个源分组可以包括800个字节。所有这种信息可以包括在相关联的分组的码点字段中。如果码点字段是特定类型的开始，则可以向该码点字段(或码点)分配特定的值。此外，可以对源对象内相同类型的连续的、源对象的部分提供FEC保护。例如，可能存在FEC修复对象，该FEC修复对象保护源对象的字节范围12,000至 19,999，其中该字节范围与如码点中所指示的、源对象内的类型X的数据相关联。

各种实施例可以包括被配置为进行以下操作的组件：使用现有的FEC 方案的源FEC有效载荷ID(即，不是如源协议中所提出的字节范围)。该实施例可以实现支持例如在源传递级上与现有的FEC方案后向兼容。该实施例还可以支持对象绑定。可以在应用FEC框架之前将源FEC有效载荷ID 变换为字节范围。该实施例可以允许在源协议中应用具有任意FEC方案的改进的FEC框架。

在一个实施例中，与完整的现有文件相反，源对象可以是(或包括) 现有文件的字节范围(例如，利用对它们进行标识的URL，如例如ISO/IEC 23009-1,Annex E中所定义的)。

通常，web缓存是用于临时存储web文件(例如，HTML页面、图像等)以减小带宽使用、服务器负载和网络延迟的机制。通常，web缓存对经过它的文件的副本进行存储，使得可以直接地从web缓存来满足后续的基于web的请求。HTTP缓存是实现了HTTP标准中所指定的基本的新鲜度、有效性和无效性要求的web缓存。

各种实施例可以包括被配置为进行以下操作的组件：执行对象传递操作，以便使得源对象能够包含完整的HTTP响应。这可以允许接收方设备操作成HTTP缓存，使得如果另一计算设备发出HTTP请求，或者运行在相同设备上的应用发出HTTP请求，则接收方设备可以向其提供完整的 HTTP响应，就好像该响应是完全在HTTP上传递的。

各种实施例可以包括以下的组件：所述组件被配置为执行上面提到的操作中的任何和或所有操作，同时符合当前的FLUTE标准的要求和/或同时保持与实现当前的FLUTE标准的其它组件的后向兼容。

可以在多种通信系统、网络和/或移动多媒体广播系统中实现各种实施例，图1中示出了其中一个例子。具体而言，图1示出了其中移动接收方设备102可以从多媒体广播网络104、单播网络106或者经由互联网108接收内容的通信系统。典型的多媒体广播网络104包括多个广播发射机112，其中广播发射机112是由移动广播网络控制中心/广播操作中心(BOC)114 控制的。多媒体广播网络104通过广播发射机112将内容广播成移动广播传输113，以便由移动接收方设备102接收。在BOC 114内，可能存在用于对内容广播进行管理的一个或多个服务器110，并且该一个或多个服务器 110提供至互联网108的连接。

除了多媒体广播网络104之外，移动接收方设备102还可以经由单播网络106(例如，蜂窝电话网、WiFi网络(未示出)、WiMAX等)进行通信。典型的蜂窝电话网包括耦合到网络操作中心118的多个蜂窝基站116。网络操作中心118操作为：例如经由电话陆地线路(例如，POTS网络，未示出)和互联网108来连接移动接收方设备102和其它网络目的地之间的语音和数据呼叫。

可以经由双向无线通信链路115(例如，LTE、4G、3G、CDMA、TDMA 和其它蜂窝电话通信技术)来实现移动接收方设备102和单播网络106之间的通信。这种双向无线通信链路115可以使得用户能够将多媒体内容流式传输到接收方设备(例如，移动设备)。

为了有助于互联网数据通信(例如，流式传输视频馈送)，通常单播网络106将包括耦合到网络操作中心118或者在网络操作中心118内的一个或多个服务器120，所述一个或多个服务器120提供至互联网108的连接。当有线连接可用时，移动接收方设备102还可以经由有线连接连接到互联网108，在这种情况下，互联网108可以充当单播网络。移动接收方设备 102还可以使用公知的常规的基于web的接入协议在互联网108上接收非广播的内容。

通常，用于由接收方设备(例如，上面所讨论的移动接收方设备102) 对内容进行接收和呈现的操作可以划分成单独的和独立的操作群组或操作类别，并且可以将每个操作群组或操作类别分配给层(例如，物理层、数据链路层等)。在这些层中的每一层中，各种硬件和/或软件组件可以实现与分配给该层的责任相当的功能。例如，媒体流(例如，广播、点到点等) 通常在物理层中进行接收，其中物理层可以包括无线接收机、缓冲区、以及执行对射频(RF)信号内的符号的解调、辨识操作并执行用于从接收到的RF信号中提取原始数据的其它操作的处理组件。

图2根据实施例，示出了适用于接收并显示内容的移动接收方设备的示例性协议栈200。在图2的所示出的例子中，协议栈200包括物理层202 模块、数据链路层204模块、网络层206模块、传输层208模块和应用层 210模块，这些模块中的每个模块可以在硬件中、在软件中或者在硬件和软件的组合中实现。此外，模块202-210中的每个模块可以包括子层，这些子层也可以在硬件中、在软件中或者在硬件和软件的组合中实现。

物理层202模块可以包括无线组件，所述无线组件被配置为接收基本的通信信号、从该通信信号中提取数据、以及将该数据提供给数据链路层 204模块中的媒体传输流(例如，MPEG-2传输流)或者介质访问控制模块。数据链路层204模块可以提供寻址和信道访问控制机制，这使得移动接收方设备的各种组件接收不同的数据流成为可能。数据链路层204模块还可以包括：在活动图像专家组(MPEG)传输流(TD)之上的、用于携带分组协议(例如，互联网协议)的子模块或子层，例如，所示出的多协议封装前向纠错(MPE-FEC)模块/层以及节目和系统信息(SI/PSI)模块/层。

可以由数据链路层204模块将携带内容和信息流的流/信号的部分传递给网络层206模块，其中网络层206模块可以包括IP模块/接口，IP模块/ 接口用于将流、数据报和/或分组传送/中继到传输层208模块。可以将传输层208中接收到的流和数据传递给适当的传输层子模块或子层，该传输层子模块或子层对数据进行处理和打包以便传输。这种传输层子模块/子层可以包括用户数据报协议(UDP)模块/层、异步分层编码/分层编码传输 (ALC/LCT)模块/层、实时传输协议(RTP)模块/层和单向传输的文件传递(FLUTE)模块/层。在一个实施例中，RTP模块/层可以包括在应用层 210中或者作为应用层210的一部分，类似于DASH格式。

应用层210模块可以包括建立主机到主机、端到端的连接以及进行过程到过程的通信所要求的协议和方法。应用层210模块还可以包括用于在移动接收方设备上对接收到的内容进行处理、呈现和/或显示的端用户应用 (例如，媒体播放器等)。应用层还可以包括媒体格式(例如，DASH格式)、经编码的媒体流以及其它与媒体相关的元数据。在图2中所示出的例子中，应用层210模块包括DASH模块、RTP模块和媒体播放器模块。

图3示出了适用于将多媒体内容传递给移动接收方设备的实施例广播通信系统300的各种逻辑组件和功能组件。在图3中所示出的例子中，广播通信系统300包括高级对象前向纠错组件302、高级对象信令组件304 和高级对象传递组件306。多媒体内容被编码到可变大小的对象(Obj)中，这些可变大小的对象(Obj)经由三个不同的对象流(对象流1、对象流2 和对象流3)进行广播。每个对象流(对象流1、对象流2和对象流3)包括高级对象传递组件306或者与其相关联。可变大小的对象(Obj)中的每一个可以是完整的对象或者是对象的一部分(例如，字节范围等)。

在各种实施例中，高级对象前向纠错组件302、高级对象信令组件304 和高级对象传递组件306中的任何或所有组件可以在硬件、软件或者硬件和软件的组合中实现。

高级对象传递组件306可以被配置为执行各种对象传递操作，包括：在传递级上建立或标识对象(Obj)之间的流关联；在分组级上向对象或数据添加时间戳；执行分块传递操作；将对象(Obj)打包或分段成源分组；以及执行各种其它类似的操作。

高级对象信令组件304可以被配置为执行各种信令操作，例如：在对象流(对象流1、对象流2和对象流3)中打包并发送信令信息；实现HTTP 服务器/代理/缓存复制；以及传递针对HTTP对象的“可用性定时”信息。例如，高级对象信令组件304可以被配置为：当传递HTTP对象时，以信号发送相应对象的可用性定时信息。这允许广播通信系统300在通过广播来传递对象时执行超时操作。对这种可用性定时信息的传递还可以允许广播通信系统300实现与缓存超时策略类似的特征，在缓存超时策略中，存储在缓存中的项目仅在有限的持续时间内可用于计算系统和/或在某一持续时间或时间段之后超时。以此方式，广播通信系统300可以确保数据、对象(Obj)和/或源分组总是当前的或包括最新的信息。

高级对象信令组件304还可以被配置为向接收方设备提供信令信息，该信令信息可以包括对以下内容进行标识的各种信息字段：将何时以及如何将一个或多个对象(Obj)传递给接收方设备。在各种实施例中，可以在由接收方设备接收或者由服务器发送相应的对象或分组之前，通过广播会话将该信息传递给接收方设备。

高级对象前向纠错组件302可以被配置为执行各种纠错操作，包括用于以下各项的操作：提供针对对象的源流的FEC保护；提供针对对象的绑定体的FEC保护；提供针对单独对象的部分的FEC保护；以及允许独立于 FEC语义、编码、逻辑、支持或操作来传递源对象。在一个实施例中，高级对象前向纠错组件302可以被配置为：提供针对源对象的绑定体的FEC 保护，而同时独立于FEC语义来传递绑定体的独立源对象。

在一个实施例中，高级对象前向纠错组件302可以被配置为：提供针对传输源对象的字节范围(以及字节范围的组合)的FEC保护，以保护相同或不同的流或串流中的对象的部分。这允许接收方设备在接收对象时执行FEC解码操作以增量式地呈现对象。这与现有的解决方案形成对比，在现有的解决方案中，对整个对象执行FEC编码，并且现有的解决方案通常要求接收方设备等到接收到整个对象，才执行FEC解码操作来呈现该对象。

在一个实施例中，高级对象前向纠错组件302可以被配置为提供针对源对象流的FEC保护。高级对象前向纠错组件302可以提供对任何基于对象的传递系统(包括基于FLUTE的传递系统)中的源对象流的FEC保护。此外，高级对象前向纠错组件302、高级对象信令组件304和/或高级对象传递组件306可以实现现有的FLUTE标准和解决方案或者可以是现有的 FLUTE标准和解决方案的子集。此外，这些组件302、304、306中的任何或所有组件可以将FLUTE功能(例如，由上面参考图2所讨论的FLUTE 子层提供的功能，等等)扩展到允许在FLUTE的上下文中更加有效地传递对象流并符合现有的FLUTE标准。

现有的基于广播对象的流式传递解决方案(例如，由当前的FLUTE解决方案(在用于传递区段的DASH序列的3GPP MBMS中所指定的)提供的解决方案)缺乏由基于分组的流式传输解决方案提供的特征和功能中的许多特征和功能。因此，许多现有的流式传输解决方案不是基于对象的，而是基于分组的解决方案，其中基于分组的解决方案经由RTP/IP、MPEG2 传输流(TS)或者其它类似技术来传递分组流。当在这种基于分组的流式传输解决方案中使用FEC时，分组通常划分成源块，并且针对这些源块中的每个源块单独地提供FEC修复保护。出于该原因和其它原因，现有的基于分组的流式传输解决方案缺乏对流的部分进行命名和标识(例如，利用统一资源标识符(URI))的能力，并且通常缺乏由基于对象的流式传输解决方案(例如，DASH)提供的优势特征中的许多优势特征。

在一个实施例中，广播通信系统300可以被配置为提供以下的功能：该功能是现有的基于分组的流式传输系统所提供的功能和现有的基于广播对象的流式传输系统所提供的功能的组合。也就是说，与现有的流式传输解决方案形成对比，广播通信系统300可以实现组合了现有的基于分组的流式传输解决方案和基于广播对象的流式传输解决方案的特征(并且提供了这些特征以外的特征)的功能，同时保持与现有的基于FLUTE的解决方案和系统兼容，并且同时经由广播来实现这种通信。

通常，基于分组的流式传输系统可以生成单独的分组，以匹配它们携带、打包或编码的源内容的特征。例如，当源内容是视频流时，基于分组的流式传输系统可以生成每个源分组，使其包括视频数据的一帧或片段或网络抽象层单元。这允许基于分组的流式传输系统在每个视频帧或每个片段或接入单元或网络抽象层单元变得可用于系统时立即对其进行发送，在一些环境或网络中这可以减小网络延迟。此外，基于分组的流式传输系统通常针对每个样本达到非常精确的定时，在一些环境或网络中这也是有益的。

现有的基于广播对象的流式传输系统比基于分组的流式传输系统更适用于传递较大的样本或对象，但是要求在发送区段/对象之前，使得要包括在区段或对象中的所有信息可用于在IP网络上的通信。也就是说，现有的基于广播对象的流式传输系统不允许服务器在针对源对象的内容变得可用于该服务器时开始对其进行发送。更确切地说，现有的基于广播对象的流式传输系统要求服务器等到大体上接收到针对DASH区段或源对象的所有信息或者这些信息可用于该服务器，该服务器才可以开始向接收方设备发送针对该DASH区段(或源对象)的分组。此外，现有的基于广播对象的流式传输系统不是非常适用于满足针对单独的样本/区段/对象的精确的定时要求，并且因此在一些环境或网络中容易受网络延迟和抖动的影响。

各种实施例可以包括广播通信服务器，其被配置为：在信息变得可用于服务器时高效地对样本或对象进行广播并且针对每个样本/对象达到非常精确的定时，同时保持与现有的基于FLUTE的解决方案和系统兼容，从而实现现有的基于分组的流式传输系统所提供的功能和现有的基于广播对象的流式传输系统所提供的功能的混合/组合。例如，广播通信服务器可以被配置为：在数据变得可用于服务器时将该数据包括在文件中，并且立即开始对该文件进行广播，使得在数据变得可用于服务器时(即，在服务器接收到要包括在文件中的所有数据之前)使该数据可用于网络。此外，广播通信服务器可以在FLUTE级将定时信息添加到每个文件/分组。这种定时信息可以用于测量网络中的抖动以及执行其它类似的操作。抖动测量和抖动补偿可以用于形成缓冲区的维度大小以及用于确保低延迟操作。

现有的FLUTE系统使用文件传递表(FDT)来传送信令信息。FDT可以包括前向纠错对象传输信息(FEC OTI)、统一资源标识符(URI)、传输对象标识符(TOI)(其对分组中所包含的对象信息进行标识)以及对象的传输会话/流标识符(TSI)。

前向纠错对象传输信息(FEC OTI)可以包括“FEC编码ID”，其对特定的FEC编码方法进行标识。此外，FEC OTI可以包括各种参数，例如字节范围或对象/文件大小(F)、对齐因子(Al)(其对字节偏移进行标识)、符号大小(T)、对象中的源块的数量(Z)以及每个源块针对该对象划分成的子块的数量(N)。

在各种实施例中，每个对象可以包括不同的前向纠错对象传输信息 (FEC OTI)和/或不同的统一资源标识符(URI)。文件传递表(FDT)可以将传输对象标识符(TOI)链接到FDT中所包含的其它信息，例如，URI、 FEC OTI和其它对象传输参数。传输会话/流标识符(TSI)可以界定TOI 的范围(即，标识TOI并提供针对TOI的上下文)，这允许在相同的会话中并且在不同的TOI的情况下传递多个对象。TSI和TOI的组合可以唯一地标识对象。对象序列号(OSN)可以映射到TOI，反之亦然。TSI可以映射到FLID。

文件传递表(FDT)可以包括静态信息和动态信息二者。例如，传输对象标识符(TOI)、URI、内容类型和字节范围或对象/文件大小(F)值可以包括随对象而变化的动态信息。FEC编码ID、传输会话/流标识符(TSI)、对齐因子(Al)、符号大小(T)、源块的数量(Z)和子块的数量(N)的值都可以包括静态信息，该静态信息跨越多个对象或者跨越对象的序列是固定的。可以例如通过针对所有对象使用Z＝1，N＝1和固定的Al和FEC编码ID值，一次性地针对整个相关对象的序列(或者对象的集合)来提供这些值。但是，使用现有的解决方案，必须针对要广播的每个对象发送(经由对FDT进行广播)信令信息，而不管跨越流中的多个对象进行共享的静态字段的数量。

当传递对象流时，可以跨越相关对象的流来预测TOI和URI值，而对象/文件大小(F)通常是不可预测的。可以经由模板化、通过使用TOI和模板来传送URI信息以生成URI。

除了上面所讨论的值字段之外，在现有的基于FLUTE的解决方案中，每个分组包括FEC有效载荷ID。FEC有效载荷ID提供关于分组有效载荷的信息，并且可以包括源块号(SBN)和编码符号标识符(ESI)。FEC有效载荷ID可以包括特定于具体的FEC方法或系统的信息，而不管分组是否包括源数据或修复数据。出于该原因，当经由FLUTE传递针对对象的源数据时，现有系统要求FEC编码ID。

各种实施例可以包括广播服务器，其被配置为：经由FLUTE传递针对对象的源数据而不包括FEC语义(例如FEC编码ID数据字段或值)。各种实施例还可以包括接收方设备，其被配置为：接收、解码和使用不包括FEC 语义的对象。

现有的FLUTE解决方案不支持在单个对象流或通信信道中所包括的多个对象之间建立关系。使用现有的解决方案，针对每个对象必须将可以包括在对象的FDT中的静态信息和动态信息中的所有信息单独地传递给接收方设备。此外，针对流中的每个对象，通常必须传递至少一个FDT，因为对象的FDT内所传递的信息中的一些信息通常仅当该对象自身被传递时才可用。针对每个对象，必须在FDT内传递该信息，而不管是否存在对信息的实际或潜在改变，并且不管针对多个对象或跨越流中的所有对象是否可以使用相同的信息。此外，FEC有效载荷ID(其是FEC语义并且提供与对象一起传递的每个分组的内容有关的信息)通常是特定于FEC的并且不是在所有实例中都要求。对相同的信息、接收方设备不要求或不使用的信息或者可以跨越多个对象共享的信息进行重复地广播(如现有系统中所进行的)，是对网络资源的低效使用。

各种实施例可以包括广播通信服务器，其被配置为：在单个流、串流或通信信道中对相关对象进行广播，使得可以跨越流中的多个对象共享信令信息(例如，FDT参数)。这减小了在网络上传送的信息量，是对网络资源(例如，带宽等)的更高效的使用，并且与用于向接收方设备传递信息的现有的解决方案相比更可靠。

各种实施例还可以包括广播通信服务器，其被配置为对相关对象的序列进行广播。在一个实施例中，可以经由TOI字段来对对象之间的关系进行标识，这可以通过将TOI字段划分成如下两个子字段来实现：流ID(FLID) 子字段，其对相关对象的流进行标识；以及对象序列号(OSN)子字段，其对相关源对象的流内的每个源对象进行标识。在一个实施例中，OSN可以映射到TOI字段。可以以此方式来划分TOI，因为FLUTE标准没有定义 TOI字段的严格结构，并且因此其中所包含的每个数字可以用于不同的对象或字段。此外，由于现有的TOI字段通常存储四(4)个字节的信息，因此TOI字段可以划分成一(1)个字节的FLID参数子字段和三(3)个字节的OSN参数子字段，而不影响它们与现有系统的后向兼容。

在一个实施例中，FLID可以是一(1)个字节的参数，这允许系统针对每个会话支持256个不同的FLID。在一个实施例中，可以将零(0)值排除作为FLID子字段的可接受的或支持的值，以便避免与零(0)的TOI 值冲突，在一些系统中可能保留零(0)值用于FDT对象传递。

在一个实施例中，TOI可以是4字节的值，并且可以保留取值范围(例如，128-255等)用于TOI的FLID子字段，以允许使用现有的FLUTE解决方案并且在相同的会话内传递对象。例如，不将TOI划分成子字段并且使用FDT的解决方案可以将所使用的TOI值限制到范围0至 128*256*256*256-1＝2147483647(第一用例)。另一方面，将4字节的TOI 划分成1字节的FLID和3字节的OSN的解决方案可以将所使用的FLID 值限制到范围128至255(第二用例)而对3字节的OSN值的范围没有任何进一步的限制。当进行级联时，1字节的FLID和3字节的OSN形成4 字节的TOI整型值，该值的范围从128*256*256*256到256*256*256*256-1 (或者等效地，TOI整型值的范围从2147483648至4294967295)。这确保用于上面所讨论的两个用例的4字节的TOI值的总体范围是不相交的。这允许FLUTE广播传递系统在相同的会话中，传递不对TOI进行划分并且使用FDT的对象(上面所描述的第一用例，现有的FLUTE解决方案)以及对TOI进行划分并且不使用FDT的对象(上面所描述的第二用例)。如所描述的，这可以通过将整体TOI值的范围划分成针对两个不同用例的不相交的范围来实现，这消除了针对相同会话中的两个用例的冲突的TOI的可能性。

在一个实施例中，传输会话/流标识符(TSI)可以用作流ID(FLID)。

相关对象的流(例如，由各种实施例的FLID子字段所标识的)可以与 DASH表示中的视频区段的流相对应。例如，在这种表示中所传递的每个对象会具有相同的FLID(例如，FLID＝1)，并且因此，具有相同FLID的分组可以由各种实施例服务器和接收方设备视作为属于相同的对象流的对象。另一种流可以例如是DASH媒体呈现的音频数据。

属于相同的对象流、并且因此具有相同FLID值的对象可以经由OSN 子字段来标识。OSN子字段可以存储简单整型，针对第一个对象在零(0) 值处开始，并且针对流中的每个后续源对象以一(1)进行递增。在一个实施例中，OSN可以是三(3)个字节的参数，以每秒一个对象的对象传递速率，该参数允许大约200天的不同OSN值。

TSI可以界定FLID子字段的范围，FLID字段可以界定OSN子字段的范围。也就是说，TSI值可以提供用于在具有相同FLID值的两个对象之间进行区分的足够的上下文，并且FLID值可以提供用于在具有相同OSN值的两个对象之间进行区分的足够的上下文。

在一个实施例中，系统可以被配置为使用TSI作为FLID值。在各种实施例中，TSI字段可以映射到DASH表示，反之亦然。

根据各种实施例，通过将TOI字段划分成两个子字段(即，FLID和 OSN)，广播网络不需要对针对源流的FDT进行广播。相反，广播网络可以对针对每个接收机和针对每个流(即，不是针对流中的每个对象)的单个源流声明(其可以包括在FLUTE元数据中)进行广播。

源流声明可以是对与对象流/或该对象流中所包括的分组的对象相关的各种信息字段和值的简要表示。源流声明可以对对象序列号和对象之间的关系进行标识。源流声明可以在元数据级对流进行声明。这可以通过在 FLUTE元数据中包括各种信息字段和值来实现。源流声明可以包括唯一的流标识符(FLID)，FLID对流中的源分组和针对该流的其它静态信息进行标识。源流声明还可以包括与流的类型(例如，视频对象流、音频对象流等)相关的信息。源流声明可以对流中的多用途互联网邮件扩展(MIME) 类型的对象进行标识并且包括其它类似的信息。在一个实施例中，源流声明可以包括对适用于在对流中的对象进行解密中使用的解密密钥和/或解密密钥的序列的指示(即，如果对象被加密的话)。

在使用FLUTE的MBMS传递的情况下，可以在用户服务描述(USD) 中携带源流声明。源流声明可以传送与FLUTE接收机或接收方设备最相关的信令信息。源流声明可以向接收方设备提供与对象传递流相关的、带外的提前信息。

在一个实施例中，在服务器或接收方设备中可以如下对源流声明进行声明或表示：

在上面的源流声明的例子中，用flow_type(流_类型)字段的值(本例中为“source(源)”)来指示流的类型，用FLID数据字段的值(本例中为“5”)来指示针对该流的流标识符，并且用source_type(源_类型)数据字段的值(本例中为“video(视频)”)来指示流的对象中所携带的内容的类型。通常，要求在flow_declaration(流_声明)内声明flow_type和FLID，而其它信息可以包括或者可以不包括在flow_declaration中。

作为替代方案，可以使用现有字段来以信号发送并支持使用流标识符 (FLID)，在这种情况下，可以使用传输对象标识符(TOI)信令和使用而不是单独定义的OSN来标识传输对象，而对信令或协议没有其它修改。例如，可以使用LCT报头中的现有的码点字段来以信号发送FLID(除了码点字段的其它使用之外)，并且可以使现有的TOI字段保持未修改来以信号发送传输对象标识符，而不是使用新定义的OSN。

各种实施例可以包括广播服务器，其被配置为将源对象打包成源分组，使得源分组：不包括对FEC或FEC语义的任何依赖性；的确实现组块传递；的确使得能够在对象完全可用之前发送对象；以及的确支持将源对象打包成可变大小的分组(例如，底层媒体的每个接入单元的传递)。

在一个实施例中，source_type数据字段或值可以用相应的对象流的 MIME类型来替换。

在一个实施例中，可以生成源分组，使其包括源有效载荷ID数据字段和值，该数据字段和值包括分组中所携带的第一个源对象的字节偏移。还可以生成源分组，使得源对象的字节顺序地存储在分组内，并且使得可以用分组有效载荷的大小来推断结束字节位置。在一个实施例中，源有效载荷ID可以是四(4)字节的参数。在一个实施例中，为了提高FEC恢复效率，广播系统可以将每个源分组中的字节数量与FEC符号的大小对齐。在一个实施例中，可以生成源分组，使其还包括码点，该码点可以包括针对源对象的字节范围或部分的标记信息和/或FEC编码信息。

通过将源对象以此方式打包成源分组，各种实施例可以允许独立于 FEC操作或语义来传递源对象。此外，通过对源对象进行打包，使得它们独立于FEC操作，发送方可以在需要时对相同的源对象应用不同的FEC方法。

此外，通过对源对象进行打包，使得它们独立于FEC操作，各种实施例可以允许发送方(即，服务器)应用FEC保护方法来产生修复流，该修复流对源流或流的组合进行保护以创建第一版本的FEC保护，在该版本中，每个FEC编码被应用于流或者流的组合中的多个对象上，其中所述多个对象适用于传递给处于较差接收状况的接收方或者适用于仅记录广播会话并且因此需要尽可能最高的保真度恢复的接收方；以及产生另一修复流，该修复流对相同的流或流的组合进行保护以创建第二版本的FEC保护，在该版本中，每个FEC编码被应用于流或者流的组合中的比第一版本少的对象上，这可以提供适用于传递给所有其它接收机的更短的端到端延迟和/或这允许加入会话时更快地访问媒体流。例如，第一版本的FEC保护可以是第一修复流，其中每个FEC编码应用于来自源流的一对连续的源对象，并且第二版本的FEC保护可以是第二修复流，其中每个FEC编码应用于来自相同源流的单个源对象。

各种实施例的广播系统可以被配置为提供多种源对象信令增强。现有的系统使用FEC语义来确定是否/何时已接收到源对象的所有分组和/或确定源对象的长度/大小。各种实施例可以允许接收方设备来确定是否或者何时已接收到源对象的所有分组、确定源对象的长度/大小、以及确定源对象是否是不完整的对象(例如，没有接收到所有分组)，其均不使用FEC语义或不要求分组包括FEC语义。在一个实施例中，这可以通过在源对象的最后源分组中设置“对象结束标志(close object flag)”(例如，B-标志)、用发送信令来指示源对象的结尾来实现，其中B-标志是现有FLUTE标准中的现有字段。

例如，可以在除了最后源分组之外的所有源分组中将B-标志字段的值设置为零(0)，在最后源分组中可以将B-标志设置为一(1)。这是有可能的，因为FLUTE没有设置针对B-标志字段的使用的明确的或精确的要求，并且在任何情况下，没有指定仅在源对象的最后源分组中要将B-标志字段设置为一(1)。

源对象的最后源分组(P)包含该源对象的最后部分。因此，通过仅在最后源分组中设置B-标志(即，设置P的B-标志＝1)，各种实施例可以使得接收方设备能够确定是否已接收到源对象的最后部分。此外，接收方设备可以通过将长度/大小值设置为等于最后源分组(P)的源有效载荷ID中的字节偏移加上该最后源分组(P)的有效载荷大小，来确定源对象的大小 /长度。此外，接收方设备可以使用针对对象所接收到的其它源分组的字节偏移和有效载荷大小，来确定是否存在该对象的任何其它部分还未接收到，即，接收机可以确定源分组内是否存在对象的任何字节序列还未接收到。以此方式，广播系统可以确定是否或者何时已接收到源对象的所有分组、确定源对象的长度/大小和/或确定源对象是否是不完整的对象，其均不要求针对每个对象发送FDT或其它信令信息并且在源分组或对象中不包括FEC 语义。

图4示出了将实施例的源对象402打包成多个源分组404-410，使得广播系统可以在没有FDT或FEC语义的情况下确定是否或何时已接收到源对象的所有分组。每个源分组404-410包括B-标志字段、源有效载荷ID字段和源有效载荷字段。在图4中所示出的例子中，源对象402的大小/长度为5,000个字节，并且前三个源分组404-408中的每个源分组包括大小/长度为 1280个字节的源有效载荷数据字段。由于源对象的大小(即，5,000个字节) 不是1280的倍数，因此最后分组410的源有效载荷数据字段仅包括1160 个字节。前三个源分组404-408中的每个源分组的B-标志字段设置为零(0)，而每个最后分组410的B-标志字段设置为1。

概括地说，接收方设备或接收方可以根据接收到的源分组来确定是否已接收到整个源对象或者是否缺失了对象的至少某一部分。例如，如果接收方没有接收到对象中具有B-标志字段设置为一(1)的最后分组，则接收方可以确定至少还未接收到对象的某种后缀。另一方面，如果针对对象已接收到具有B-标志字段设置为一(1)的源分组，则接收方可以确定其已接收到对象的后缀，并且可以通过计算具有B-标志设置为一(1)的分组中的字节偏移和该分组的分组有效载荷大小之和，来确定对象的大小。此外，当针对对象已接收到具有B-标志字段设置为一(1)的源分组时，接收方可以根据接收到的源分组的字节偏移和分组有效载荷大小，来确定源对象的内部部分是否存在缺失。

针对图4中所示出的例子，接收方设备可以接收源分组404、408和410 (并且未接收源分组406)，并且根据接收到具有B-标志设置为一的源分组 410，来确定已接收到对象的后缀并且对象的大小是3840(字节偏移)+1160 (有效载荷大小)＝5000字节的大小。接收方设备还可以根据接收到的源分组以及这些分组的字节偏移和有效载荷大小，来确定对象的字节1280-2559(未接收到的源分组406中所携带的字节)缺失。如果接收方未接收到源分组410而不是源分组406，则接收方可以确定针对该对象它还未接收到具有B-标志字段设置为一(1)的源分组，并且因此还未接收到对象的后缀。在一个实施例中，接收方设备可以被配置为：在等待一段持续时间之后，确定针对源对象还未接收到的其它分组未被发送或将不会被发送或将不会被接收到的概率很高；以及按需要执行恢复操作。接收方为做出该判定而会等待的时间量可以至少部分地基于源声明中的传递时间信息 (如果有的话)。

在一个实施例中，广播系统可以被配置为生成源分组404-410，使其包括定时信息。该定时信息可以是对发送源分组的定时。因此，源分组的定时可以被放置在分组自身中。在源分组中包括定时信息允许系统复制RTP 操作、测量网络抖动、关联传递定时、关联媒体时间关系、指定NTP时间戳的掩码等。例如，系统可以生成64比特的NTP时间戳，并且使用64比特的NTP时间戳的4字节掩码，将该掩码包括在分组中来确定定时的精确性。时间戳可以呈现发送分组的时间(或者某种其它参考)并且可以与呈现时间相关联(类似于RTP，但是不用于媒体同步)。掩码可以在信令信息中进行指定并且可以具有比特1和64之间的任意范围。掩码大小可以是8 比特的倍数，以实现基于字节的时间戳。还可以将掩码字节以信号发送为零(0)，以便指示不存在定时信息。

在一个实施例中，系统可以被配置为：使用FLUTE/LCT报头中的拥塞控制信息来携带定时信息。替代地，FLUTE/LCT报头中的拥塞控制信息可以用于携带流序列号，以实现由接收方设备在每个流进行分组丢失测量。

图5示出了现有技术的FLUTE对象分组报头502和实施例FLUTE对象分组报头504之间的区别中的一些区别。具体而言，图5示出了实施例 FLUTE对象分组报头504可以包括时间戳506字段、FLID 508字段、OSN 510字段和字节偏移512。

各种实施例可以包括被配置为进行以下操作的组件：实现对源流的组块传递和接收，使得数据传递的端到端延迟是最小的。在广播侧，实施例广播服务器可以在源对象变得可用时以组块的形式发送源对象，因为广播服务器仅需要在发送源分组时在每个源分组中放入字节偏移。广播服务器还可以在源对象的最后源分组中设置“对象结束标志”(B-标志)，使得源对象大小对于发送源分组是不需要的。类似地，服务器可以设置“结束类型”标志、字段或值，以对源对象中的每个部分或者不同类型的部分中的最后分组进行标识。例如，如果源对象划分成四个不同的部分，并且第一部分和第三部分被标记为“类型A”，第二部分和第四部分被标记为“类型 B”，则系统可以在这四个部分中的每个部分的最后分组中包括或设置“结束类型”标志/字段，以将该分组标识为该部分中和/或该类型的最后分组。

在接收方侧，接收方设备可以被配置为：在源对象以组块的形式抵达时对其进行恢复。接收方设备可以使用源分组字节偏移来确定数据在源对象内的位置，立即将接收到的源分组数据顺序地发送给应用或客户端(例如，媒体播放器)。接收方设备可以经由源有效载荷ID字节偏移和“对象结束标志”(B-标志)字段值来检测源对象内缺失的数据。接收方设备可以经由接收到的源分组有效载荷的字节偏移值和大小来确定是否存在缺失的数据间隙。接收方设备可以通过确定其还未接收到具有B-标志设置为一(1) 的源分组，来检测缺失的数据后缀。

图6是实施例FLUTE对象602的图，其中实施例FLUTE对象602包括(或绑定有)HTTP报头604字段和可用性时间606字段。HTTP报头604 字段可以包括HTTP响应报头，HTTP响应报头包括适用于由HTTP代理用来复制缓存行为的信息。

可用性时间606字段可以包括关于在接收设备处FLUTE对象602的可用性定时的信令或控制信息，该信令或控制信息可以允许系统确定FLUTE 对象602是否已被激活、是否有效或者是否已失效。在一个实施例中，可用性时间606字段可以包括针对对象的开始和/或结束可用性时间的网络时间协议(NTP)时间戳，以便由消耗的应用来使用。在FLUTE对象602中包括这种定时信息可以允许广播系统实现类似于缓存超时策略的特征，在缓存超时策略中，存储在缓存中的项目仅在有限的持续时间内可用和/或在某一时间段之后超时。以此方式，广播系统可以确保FLUTE对象602包括当前的或者最新的信息。

在现有的FLUTE解决方案中，对用于源对象的传递的元数据信息进行携带的FDT对象不包括它们的相应的源对象的定时信息或时间戳。FDT对象可以包括通常包括在HTTP响应报头中的一个或两个字段，但是现有的 FDT对象不允许如各种实施例中所实现的那样包括完整的HTTP报头。此外，由于对FDT对象进行广播消耗另外的带宽，并且由于针对流中的每个源对象通常对每个FDT重复地进行广播，因此使单独的FDT对象的大小最小化是有利的。各种实施例可以在没有FDT对象的情况下实现对象传递，并且与源对象一起传递HTTP响应报头和时间戳信息，这是对网络资源的更高效的使用，这种使用减小了每个对象流所消耗的带宽量。

各种实施例可以包括被配置为进行以下操作的组件：传送包括模板信息的源流声明信息。如上面所讨论的，源流声明可以是对与对象流相关的信息字段(例如，FLID、流类型、MIME类型、解密密钥信息等)的简要表示，并且源流声明可以用于对对象流中的对象之间的关系进行标识。通过使用模板和模板化技术，各种实施例可以使用源流声明来对对象的URI 以及将要何时在广播/多播信道上发送和/或接收对象进行标识。例如，在服务器或接收方设备中可以如下表示包括模板信息的源流声明：

在上述的例子中，源流声明的URI字段包括字符串“％OSN％”。使用模板化技术，针对对象流中的每个对象可以将该字符串变换成不同的值，以提供URI和对象的序列号之间的隐式映射。例如，该流内具有OSN＝25 的对象与URI http://localhost.seq1/object25相关联。类似的技术可以用于传输信息，例如用于“START_TRANSMISSION(开始_传输)”字段和“END_TRANSMISSION(结束_传输)”字段。在一个实施例中，可以基于“Timescale(时间尺度)”字段的值来计算“START_TRANSMISSION”字段和“END_TRANSMISSION”字段以指示传递的定时。例如，Timescale ＝10指示时间测量是以每秒10节拍为单元的，并且因此该流内具有OSN＝ 25的对象具有50秒的开始传输时间和52秒的结束传输时间。

因此，可以使用模板和模板化技术来提供用于推导出对象的URI，对象的传递时间，FLID、OSN和URI之间的关系等的机制。因此，各种实施例中可以将模板用作以信号发送在与要传递的对象序列相关联的位置、名称、可用性时间和其它元数据之间的关系的紧凑和简要的方式。

各种实施例可以包括被配置为进行以下操作的组件：传送包括模板信息和到应用的链接的源流声明信息。在服务器或接收方设备中可以如下表示这种源流声明：

在上述的例子中，源流声明包括MPD_URL字段和MPD_REP_ID字段。在一个实施例中，这些字段可以由实施例服务器或接收方设备用于在对象和MPD中所描述的表示的DASH区段之间的对应。

各种实施例可以包括被配置为进行以下操作的组件：向广播通信系统提供改进的FEC能力，该FEC能力允许独立于FEC语义或信息来独立地传递源对象而不使用FDT，并且同时使分组报头开销最小化、支持对象的组块传递并且允许使用可变大小的源分组。

各种实施例可以包括被配置为进行以下操作的组件：使用静态的文件传递信息来以信号发送流声明。

各种实施例可以包括被配置为进行以下操作的组件：在对象的上下文中提供针对流的绑定的FEC保护的支持。

各种实施例可以传送源对象并且仅在需要的地方而不是在源流声明或者源对象中提供FEC信息，并且同时使得不具有FEC能力的接收方设备能够忽略FEC修复流。

在每个修复流具有固定的符号大小的情况下，FEC可以是基于符号的。

FEC修复流可以提供对一个或多个源流中的对象的保护(例如，经由绑定)。

各种实施例可以包括各种特定于FEC的组件、单元、通信消息和数据结构，例如FEC修复流声明、FEC修复分组和FEC传输对象(其可以包括源块或源对象的绑定体)。FEC修复流声明可以包括FEC信令信息和其它特定于FEC的信息。FEC传输对象可以包括源对象和相关信息。各种实施例可以被配置为：向多个FEC传输对象中的一个FEC传输对象或多个FEC 传输对象的级联应用FEC编码。

在一个实施例中，接收方设备可以被配置为：基于可用的FEC信息，从修复分组中恢复所绑定的对象。

各种实施例可以包括针对每个修复流的单独的和唯一的FLID，该FLID 不同于其它的源FLID和修复FLID。可以由TSI来界定该FLID的范围，并且该FLID可以界定FLID中所包括的信息的范围。

各种实施例可以提供针对同步的源流的FEC修复，该FEC修复可以提供针对源流的保护。可以在修复流声明中列出受保护的源流。各种实施例可以将受保护的源流中的对象进行时间对齐，对来自不同的源流的具有相同OSN的源对象进行保护。各种实施例可以在每个修复流分组中包括一个 OSN，使得用于修复的OSN与用于受保护的源流的源对象的OSN匹配。

各种实施例还可以提供针对不同步的源流的FEC修复，以提供针对包括不完全时间对齐的对象的源流的保护。各种实施例可以对来自不同流的具有不同OSN的源对象进行保护，对单个源流的一个以上的源对象进行保护，这可以通过以与要保护的源对象同样多的次数列出这些源流来实现。

各种实施例可以将修复流分组中的OSN的数量设置为等于受保护的对象的数量。可以以与修复流声明中的源流列表相匹配的顺序来列出OSN。

各种实施例可以包括针对源对象的FEC传输对象，该FEC传输对象可以用于FEC编码操作。FEC传输对象可以包括源对象、填充字节和大小/ 长度(F)字段，其中F是源对象以字节为单位的大小。在一个实施例中，大小/长度(F)字段可以是4字节的字段。

各种实施例可以包括针对源对象的一部分的FEC传输对象，该FEC传输对象可以用于FEC编码操作。FEC传输对象可以包括源对象的字节范围和填充字节。在一个实施例中，FEC传输对象还可以包括大小/长度(F) 字段。在各种实施例中，大小/长度(F)字段可以提供源对象的字节范围或者源对象的部分的字节范围的结束和字节范围的开始之间的字节差。

FEC传输对象大小可以是符号大小T的倍数。可以在FEC传输对象的最后4个字节中携带大小/长度(F)字段值。在该情况下，FEC传输对象中的符号数量可以计算为ceil((F+4)/T)，其中ceil(x)是返回不小于x的最小整数的函数。例如，如果T＝1280并且F＝5000，则FEC传输对象中的符号数量计算为ceil(5004/1280)＝4。可以生成FEC传输对象，使其包括最小数量的填充字节。填充字节和F可以不在源对象的源分组内发送，并且可以是FEC解码所恢复的FEC传输对象的一部分。

各种实施例可以包括用于向源流提供FEC保护的FEC修复流，该FEC 修复流可以用于：保护源流的源对象的一部分、保护源流中的单独的对象、保护来自一个或多个源流的多个对象或者保护来自一个或多个源流的对象的多个部分。当用于保护源流中的单独对象时，可以根据针对源对象的FEC 传输对象来生成每个FEC编码。当用于保护来自一个或多个源流的多个对象时，可以根据针对源对象的FEC传输对象的级联来生成每个FEC编码。所述级联可以是按照修复流声明所指示的源流的顺序以及修复分组中接收到OSN的顺序。

在各种实施例中，在接收方处可以根据修复分组中所携带的TOL来确定FEC传输对象长度，其中TOL指示与修复分组中所携带的OSN以及修复流声明中所声明的FLID相对应的FEC传输对象中的符号数量。TOL可以是2字节的值，该值包括在针对受FEC保护的源对象的每个FEC传输对象的修复FEC有效载荷ID中。

通常，FEC解码器仅需要知道对象要恢复的部分的符号。因此，各种实施例可以基于对象受FEC保护的部分所覆盖的符号范围来设置FEC传输对象长度。也就是说，可以基于源对象的一部分所覆盖的源符号的范围来设置FEC传输对象长度。例如，如果符号长度是1000个字节(即，在每一千字节处开始新的符号，并且符号零覆盖源对象的字节0-999)，并且源对象要受FEC保护的部分在字节1500处开始并且在字节4500处结束，则系统可以将FEC传输对象长度设置为指示符号范围1-4以覆盖字节范围 1500-4500。系统然后可以利用零来填充FEC传输对象中的范围1000-1499 和4501-4999。在一个实施例中，接收方设备可以在对对象进行解码时自动地添加这种零的填充，并且接收方可以在对对象进行编码时添加这些符号。这消除了发送填充信息的需要。通过从受FEC保护的部分中移除填充字节，这还减小了FEC编码中所包含的字节数量。

为了减小对部分符号的性能影响，在一个实施例中，系统可以被配置为：选择足够小的符号大小，使得FEC传输对象中所包括的填充是小的或者不显著的。在一个实施例中，系统可以被配置为：生成分组结构，使其与符号边界对齐。

图7A是针对源对象的实施例传输对象700的图。所示出的传输对象 700包括源对象702字段、填充704字段和字节范围或大小/长度(F)706 字段。传输对象700可以与多个符号边界708相关联，其中符号边界708 可以基于符号大小T来确定。FEC传输对象可以划分成的符号的数量可以计算为对源对象702的大小/长度和字节范围或大小/长度(F)706字段的大小之和除以符号大小(T)进行上取整。可以通过对大小/长度(F)706字段和源对象702字段进行填充来创建传输对象700。可以对填充704字段进行填充，以填满源对象702字段和大小/长度(F)706字段之间的任何间隙。

在图7A中所示出的例子中，FEC传输对象700划分成三个符号，并且源对象702在符号边界708处不结束。在该例子中，传输对象长度(TOL) 是3，指示FEC传输对象的大小是3个符号。

修复FEC有效载荷ID可以包括编码符号标识符(ESI)字段和传输对象长度(TOL)字段以及针对每个受保护对象的符号。在一个实施例中， ESI和TOL字段的大小均可以是两(2)个字节。

图7B是针对源对象的一部分的实施例传输对象750的图。所示出的传输对象750包括源对象702字段、填充704字段和字节范围752字段。传输对象750可以与多个符号边界754相关联，其中符号边界754可以是基于符号大小T(例如，1000)或者基于源对象来确定的。受FEC保护的部分所覆盖的字节范围752可以等于1500-4500，并且因此，如果符号大小被设置为如上面的例子中所描述的1000个字节，则受保护部分的符号范围可以等于符号1-4(即，为了覆盖字节范围1500-4500)。

修复FEC有效载荷ID可以包括ESI字段和符号范围字段，其中符号范围字段覆盖受FEC保护的部分的开始和结束边界754。在一个实施例中， ESI和符号范围字段的大小均可以是两(2)个字节。

在一个实施例中，FEC有效载荷ID可以包括源符号开始位置和源符号结束位置。在另一个实施例中，FEC有效载荷ID可以包括来自受保护的对象标识符流的源的TOI。TOI的大小可以是两(2)个字节。

在优选的实施例中，FEC有效载荷ID包括源对象内要保护的部分的字节开始位置，连同FEC编码对象(其包括要保护的源对象的部分)以符号为单位的大小(舍入到最接近的符号边界)，并且在该传输源块的结尾处携带源对象的受保护部分以字节(或八位字节)为单位的大小。该优选实施例在修复报头开销方面是相对高效的，使对传输源对象内的填充字节的浪费的保护最小化，并且允许接收方进行FEC解码以恢复FEC编码对象并且根据修复报头内和FEC编码对象内的信息来提取源对象的部分。

图8A示出了当前的FLUTE修复FEC有效载荷ID 802和各种实施例修复FEC有效载荷ID 804、806、808之间的区别。当前的FLUTE修复FEC 有效载荷ID 802包括SBN字段和ESI字段。实施例修复FEC有效载荷ID 804、806、808中的每一个包括ESI字段和针对FEC编码所保护的每个对象的一个传输对象长度字段(TOL1、TOL2、TOL3等)。因此，实施例修复FEC有效载荷ID 804、806、808的格式取决于受保护对象的数量。

当前的FLUTE修复FEC有效载荷ID 802不包括对源对象或者相应的 FEC传输对象(FEC编码对象)中的符号数量进行标识的信息，也不包括对源对象或相应的FEC传输对象的长度进行标识的任何信息。相反，在当前的FLUTE解决方案中，与源对象和/或相应的传输对象有关的信息是在与该源对象相关联的单独的FDT中携带的。当前的FLUTE修复FEC有效载荷ID 802中的SBN(源块号)字段对源块进行标识，其中修复分组中所携带的符号是根据该源块来生成的，当对象划分成多个源块时这是有用的。

在一个实施例中，可以利用统一对象符号标识符(UOSI)字段来替换实施例修复FEC有效载荷ID 804、806、808的ESI字段，其中UOSI字段唯一地标识了如何根据对象来生成修复分组有效载荷中所携带的修复符号。当FEC编码对象中的源块数量是一时，则UOSI和ESI是相等的。但是，当FEC编码对象的源块数量Z大于一时，则来自具有SBN值为C的源块的、具有ESI值为B的符号的UOSI值A计算为A＝B*Z+C。如果至少有时将对象划分并经FEC编码成多个源块，则使用UOSI而非ESI是特别有用的。

图8B示出了当前的FLUTE修复FEC有效载荷ID 802和各种其它实施例修复FEC有效载荷ID 852a和852b之间的区别。针对单个(可能是部分的)源对象的FEC有效载荷ID 852a包括源对象开始字节位置(SBP)、传输对象长度(TOL)(其是传输对象以符号为单位的大小)和ESI字段。 FEC有效载荷ID 852b也包括TOI字段。类似地，FEC有效载荷ID 858可以包括针对与要保护的源对象的一部分相对应的每个TOI字段的SBP和 TOL，紧接着是ESI字段。

在其它实施例中，FEC有效载荷ID包括针对修复流所保护的每个(可能是部分的)源对象的源对象开始字节位置(SBP)和结束字节位置(EBP)，以及ESI字段。FEC有效载荷ID还可以携带针对修复流所保护的每个(可能是部分的)源对象的TOI。

当FEC编码对象中的源块数量Z大于一(1)时，或者当每个源块的子块数量N大于一(1)时，系统保持或达到各种属性、特征或目标往往是重要的。例如，系统确保可以独立于FEC保护来发送源对象(如本申请中所描述的)可能是重要的。当存在来自不同源对象的源分组的不同数量的丢失时，系统确保FEC保护操作在恢复受保护的对象时是有效的和高效的 (即，在恢复开销方面)也可能是重要的。此外，对于系统来说也可能重要的是，确保可以在接收方设备中执行FEC解码操作，使得在对数据进行尽可能少的重新排序的情况下并且使用尽可能少的存储，来高效地恢复 FEC传输对象。然而，用于形成FEC编码对象的常规和直接的方法通常是低效的或者不充分的，因为它们不允许系统保持或达到这些属性、特征或目标。

各种实施例可以包括形成FEC编码对象的方法以及被配置为实现所述方法的组件，以便当源块数量Z大于一(1)时和/或当每个源块的子块数量 N大于一(1)时允许系统保持或达到上面所讨论的属性、特征或目标。例如，组件可以被配置为：将FEC传输对象的部分均匀地(或者尽可能均匀地)映射到源块中。然后，在源块内，组件可以将FEC传输对象的部分映射到该源块的子块。对于每个这种FEC传输对象，组件可以向每个子块填充相同数量的子符号，使得每个FEC传输对象在每个子块内填充子符号的连续集合。

举例而言，假设FEC传输对象的数量为O，并且FEC传输对象i中的符号数量为Ki。令Kt为Ki从i＝0至O-1的和，即，Kt是所有FEC传输对象中的符号的总数量。对于每个j＝0至Z-1，令Nj为分配给源块j的源符号的数量。在该例子中，组件可以使用标准的方法(例如，IETF RFC 6330 中所描述的那些方法)来计算每个源块的符号数量和每个子块的子符号大小。然后，对于每个对象i＝0至O-1，组件可以将Ki的值划分到Z个源块中，使得Ki,j为要分配给源块j的FEC传输对象i的符号数量。这可以通过以下操作来实现：以循环(round robin)方式遍历源块并将第一个对象的一个符号分配给源块中的每个源块，直到第一个对象的所有符号已被分配，并且然后从循环中的该点继续，并将第二个对象的一个符号分配给源块中的每个源块，直到第二对象的所有符号已被分配，以此类推。可以重复地执行这些操作(即，以循环的方式遍历源块，等等)，直到对象的所有Kt 个符号已被分配给源块。组件然后可以将FEC传输对象的部分分配给FEC 编码对象的源块中的每个源块。这可以通过以下操作来实现：从每个FEC 传输对象的开始处开始，其中T为符号大小：对于i＝0至O-1，对于j＝0 至Z-1，将对象i接下来的Ki,j*T字节分配给源块j。组件然后可以将被分配给每个源块的FEC传输对象的部分分配给源块的子块。对于k＝0至N-1，令SSk为针对子块k的以字节为单位的子符号大小。然后，可以向源块j的子块k分配的FEC传输对象i的部分是SSk*Ki,j字节。通过以此方式来形成FEC编码对象，组件可以允许系统达到或保持上面所讨论的所有令人期望的属性、特征或目标。

各种实施例可以包括被配置为进行以下操作的组件：生成或使用修复流声明。修复流声明可以包括适用于以下各项的信息：确定保护类型(同步的或不同步的)；确定如何执行针对源流的信令操作；确定要在源流中保护的源对象；以及确定要由修复流保护的源流。保护的类型在确定分组的报头格式中可能是有用的。修复流声明还可以列出修复流所保护的源流，使得可以通过源流的FLID来对它们进行标识。修复流声明还可以列出源流，使得列出的顺序与FEC传输对象的级联的顺序相对应。在一个实施例中，修复流声明可以包括FEC OTI字段或值。

在服务器或接收方设备中可以如下表示对单个同步的源流进行保护的修复流声明：

在上面的流声明的例子中，用flow_type(流_类型)值(在本例中为“repair(修复)”)来指示流的类型，用FLID值(在本例中为“20”)来指示针对该流的流标识符，用repair_type(修复_类型)值(在本例中为“synchronized(同步的)”)来指示修复类型，并且用source_FLID(源_FLID) 值(在本例中为具有FLID为“5”的源流)来指示该修复流所保护的源流。

在一个实施例中，FEC OTI可以包括：FEC编码ID＝6(其与IETF RFC 6330中所指定的RaptorQ码相对应)，Al＝8(其指示使用8字节对齐)，T＝ 1280(其指示符号的大小为1280个字节)，Z＝1并且N＝1(其指示FEC 传输对象包括一个源块以及每个源块一个子块(即，未使用子分块))。对于修复流声明，可以提供repair_type和source_FLID以及FEC OTI。

图9A和图9B示出了与上面所讨论的示例性修复流声明相对应的FEC 编码对象和修复分组。

图9A的上部示出了可以包括在修复分组中的、适用于在执行与上面所讨论的示例性修复流声明相对应的FEC中使用的各种数据字段。具体而言，图9A示出了修复FLUTE报头902可以包括FLID字段和OSN字段，修复 FEC有效载荷ID 904可以包括TOL字段和ESI字段，并且FEC编码对象 906可以包括FEC传输对象。

在902和904以及上面所示出的相应流声明中所示出的修复分组报头指示：修复分组携带了根据FEC编码对象906生成的修复符号。在该例子中，由于每个FEC编码对一个源对象进行FEC保护，因此当FEC编码对象906的源块数量Z和子块数量N都是一时，FEC编码对象906与对应于该源对象的FEC传输对象一致。FEC编码对象906的长度是三十五(35) 个符号，其与修复FEC有效载荷ID 904的TOL字段的值相对应。在该例子中，该修复分组中所携带的修复符号具有ESI＝37。

在服务器或接收方设备中可以如下表示对两个同步的源流进行保护的示例性修复流声明：

在上面的流声明的例子中，用flow_type(流_类型)值(在本例中为“repair(修复)”)来指示流的类型，用FLID值(在本例中为“21”)来指示针对该流的流标识符，用repair_type(修复_类型)值(在本例中为“synchronized(同步的)”)来指示修复类型，并且用source_FLID(源_FLID) 值(在本例中为具有FLID为“6”和“7”的源流)来指示该修复流所保护的源流。FEC OTI与前面例子中的相同。

在各种实施例中，为了利用FEC修复来保护源对象的部分，可以提供模板化的TOI范围作为FEC修复流声明的一部分。例如，该TOI范围可能标识：修复TOI十至十九保护来自源流的源对象1，修复TOI二十至二十九将保护源对象2，等等。以下是这种FEC修复流声明的例子。

在上面的例子中，每个源TOI声明了十(10)个修复TOI。修复TOI 1-10 被保留用于对来自具有FLID＝6和FLID＝7的源流的、具有TOI＝1的源对象的部分进行保护。修复TOI 11-20被保留用于对来自具有FLID＝6和 FLID＝7的源流的、具有TOI＝2的源对象的部分进行保护。因此，在该例子中，可以使用多达十(10)个修复TOI对来自具有FLID 6和7的两个源流的每对源对象进行保护。要注意的是，对于来自两个源流的不同对的源对象，可能使用不同数量的修复TOI，多达最大分配的数量(在该例子中为10)。也就是说，针对具有源TOI＝3的源对象对，可能仅使用一(1) 个修复TOI，例如，修复TOI 30。另一方面，针对具有源TOI＝4的源对象对，可能使用十(10)个修复TOI，例如，修复TOI 40、41，......，49。针对具有源TOI＝5的源对象对，可能使用零(0)个修复TOI。

因此，针对不同对的源对象，可以提供对源对象的部分的不同数量的 FEC保护。此外，针对同一对源对象提供的两个不同的FEC保护可以对源对象的未重叠部分或者源对象的重叠部分进行保护。

例如，与修复TOI 40相关联的FEC保护可以提供对具有TOI＝4和 FLID＝6的源对象的前半部分以及具有TOI＝4和FLID＝7的源对象的前半部分的绑定的保护。与修复TOI 41相关联的FEC保护可以提供对具有 TOI＝4和FLID＝6的源对象的后半部分以及具有TOI＝4和FLID＝7的源对象的后半部分的绑定的保护。与修复TOI 42相关联的FEC保护可以提供对具有TOI＝4和FLID＝6的源对象的中间一半以及具有TOI＝4和FLID＝ 7的源对象的中间一半的绑定的保护。

在上面的例子中，针对每个源对象的TOI不是在修复流的每个修复分组的修复FEC有效载荷ID 952中携带的(或者不要求携带)。这是因为可以基于FEC修复流声明中所携带的模板化的TOI范围以及每个修复分组的修复FEC有效载荷ID 952中所携带的修复流TOI来确定源对象TOI。

图9B的上部示出了可以包括在修复分组中的、适用于在对源对象的部分执行FEC中使用的各种数据字段。具体而言，图9B示出了修复FLUTE 报头902可以包括FLID字段和OSN字段。修复FEC有效载荷ID 952可以包括开始字节位置(SBP)字段、传输对象长度(TOL)字段和ESI字段。 TOL可以是源符号的传输对象的大小(以符号为单位)。

图9B还示出了FEC编码对象954可以包括源对象的要保护的部分，以及源对象的要保护的部分以字节为单位的大小(可能在源对象的部分和大小之间具有一些填充字节)。在所示出的例子中，SBP＝1500和TOL＝4 指示要保护的部分的源对象在源对象内的字节位置1500处开始。如果符号大小是1000个字节，则由于TOL＝4，因此源对象的受FEC保护的部分的大小在3001字节和3996字节之间。在该例子中，该部分的源对象的大小最多为3996字节，因为在FEC编码对象的结尾处存在用于携带要受FEC 保护的部分源对象的大小的4字节的字段，并且因此，当TOL＝4并且符号大小为1000个字节时，该部分的源对象的大小最多可以是1000*4-4＝ 3996字节。因此，结束字节位置(其在该实施例中未明确地以信号发送) 在4500(1500+3001-1)和5495(1500+3996-1)之间。由于FEC编码对象 954的受保护部分的大小(以字节为单位)是在FEC编码对象954的结尾处携带的，因此实际的结束字节位置可以在对FEC编码对象954进行FEC 解码之后确定。在所示出的例子中，FEC编码对象954以字节为单位的大小示出为3500，并且结束字节位置是源对象内的4999(1500+3500-1)。

在另一个实施例中，修复FEC有效载荷ID 952可以包括针对受保护的完整或部分的源对象的开始字节位置(SBP)字段和结束字节位置(EBP) 字段，以及ESI字段。对于要保护的每个源对象，FEC编码对象954可以包括源对象的要保护的部分。

图10的上部示出了可以包括在修复分组中的、适用于在执行针对两个同步的源流的FEC中使用的各种数据字段。图10中所示出的例子与上面所讨论的修复流声明相对应。

在图10中所示出的例子中，修复FLUTE报头902的OSN字段是用于两个受保护的源流的，并且FEC编码对象906包括对针对具有OSN 4的对象的、具有FILD＝6的FEC传输对象以及具有FLID＝7的FEC传输对象的级联。可以通过以适当的顺序(即，18,10)(例如，声明中所列出的对象的顺序)在修复FEC有效载荷ID 904中列出两个FEC传输对象的TOL，来对受保护的FEC传输对象的长度进行标识。

在服务器或接收方设备中可以如下表示对两个不同步的源流进行保护的示例性修复流声明：

在上面的流声明的例子中，用flow_type(流_类型)值(在本例中为“repair(修复)”)来指示流的类型。用FLID值(在本例中为“22”)来指示针对该流的流标识符。用repair_type(修复_类型)值(在本例中为“unsynchronized(不同步的)”)来指示修复类型。用source_FLID(源_FLID) 值(在本例中为具有FLID“8”和“9”的源流)来指示该修复流所保护的源流。FEC OTI与前面例子中的相同。

可以在修复分组中包括不同的数据字段，使得它们适用于在对源对象的部分执行FEC中使用。例如，修复FEC有效载荷ID 904可以包括针对每个受保护部分的开始位置(Start Pos)字段和结束位置(End Pos)字段，这些字段适用于在对对象的受保护部分的符号或字节范围进行标识中使用。

图11的上部示出了可以包括在修复分组中的、适用于在执行针对两个不同步的源流的FEC中使用的各种数据字段，并且图11的上部与上面所讨论的保护两个不同步的源流的示例性修复流声明相对应。在图11中所示出的例子中，修复FLUTE报头902包括针对对象(也就是说，在修复流声明中经由“source_FLID”字段所标识的对象(即，具有FLID 8和9的对象)) 中的每个对象的OSN字段(OSN1、OSN2)。

针对源流或修复流，各种实施例可以在对象序列号指示符(OSNI)字段或值中表示对象序列号(OSN)。OSNI可以是用于以信号发送针对同步或不同步的修复流保护的OSN的短形式。OSNI还可以用于指示是否要在当前的受保护对象的绑定体中对对象进行FEC保护。也就是说，零OSNI 值可以指示不保护任何源对象，而非零OSNI值可以指示要在绑定体内保护源对象。

当存在要保护的源对象时，各种实施例可以将OSNI值设置为((OSN modulo 255)+1)。可以基于OSNI值以及针对受保护的源流的源流声明中的开始和结束传输时间信息的组合来完成从OSNI值到OSN的映射。

举例而言，假设源流的每个源对象的传输的持续时间是两(2)秒，并且源对象的传输在时间上是连续的。进一步假设当接收具有OSNI＝191的源分组时，传输的总的持续时间是1401秒。在该情况下，映射到OSNI＝191 的可能的OSN值包括OSN＝190、445、700、955、1210，等等。然而，具有OSN＝190的源对象是在380至382秒的时间间隔期间发送的，具有OSN ＝445的源对象是在890至892秒的时间间隔期间发送的，具有OSN＝700 的源对象是在1400至1402秒的时间间隔期间发送的，具有OSN＝955的源对象是在1910至1912秒的时间间隔期间发送的，并且具有OSN＝1210 的源对象是在2420至2422秒的时间间隔期间发送的。因此，实施例接收方设备可以很有把握地确定在1410秒处接收到传输中的具有OSNI＝191 的源分组对应于OSN＝700。

要注意的是，在上面的例子中，当在时间1401秒处接收到具有映射到 OSNI＝191的其它OSN值的分组时，接收方设备可能在其假设/判定方面是不正确的。但是，这通常仅当比源流声明中的传输时间信息中所通告的至少早500秒或者至少晚500秒发送或接收分组时才发生。例如，当在1401 秒处接收到来自具有OSN＝445(其意在890至892秒之间发送)的源对象的分组时，实施例接收方设备可以确定分组比它们的预定传输时间晚了超过500秒抵达，并相应地作出响应。

在一个实施例中，OSNI的长度可以是一(1)个字节。这可以表示系统每个流仅使用FLUTE报头的一个字节，与针对源流或修复流使用OSN 时可能要求的三(3)个字节相反。对于修复流，OSNI还可以允许系统以信号发送不保护“任何对象”，这可以通过将OSNI的值设置为零(0)来实现。以此方式，系统可以支持可变数量的受保护的源对象。也就是说，受保护的源对象的数量可以是可变的。

可以在服务器或接收方设备中如下表示使用OSNI而非OSN(短形式) 来对三个不同步的源流进行保护的示例性修复流声明：

在上面的流声明的例子中，用flow_type(流_类型)值(在本例中为“repair(修复)”)来指示流的类型。用FLID值(在本例中为“23”)来指示针对该流的流标识符。用repair_type(修复_类型)值(在本例中为“unsynchronized short(不同步的短型)”，其指示使用短的OSNI字段(而不是修复分组报头中较长的OSN)的不同步的保护)来指示修复类型。用 source_FLID(源_FLID)值(在本例中为具有FLID“8”、FLID“8”和“9”的源流)来指示该修复流所保护的源流。FEC OTI与前面的例子中相同。

图12的上部示出了可以包括在修复分组中的、适用于在执行针对三个不同步的源流FEC中使用的各种数据字段，并且图12的上部与刚刚上面所讨论的示例性修复流声明相对应。在图12中所示出的例子中，修复FLUTE 报头902包括针对对象中的每个对象的OSNI字段(OSNI 1-3)。OSNI字段 (OSNI 1-3)的值可以等于它们相应的三个FEC传输对象的((OSN modulo 255)+1)。FEC编码对象906对具有FLID＝8的两个FEC传输对象以及具有FLID＝9的一个FEC传输对象进行保护。

在该例子中，假设对于具有FLID＝8的源流，在不重叠的两(2)秒中发送针对每个后续源对象的源分组，对于具有FLID＝9的源流，在不重叠的4秒中发送针对每个后续源对象的源分组，并且在类似的时间间隔上发送针对具有FLID＝23的修复流的修复分组，其中在该时间间隔期间发送针对它们所保护的源对象的源分组。进一步假设在时间1401秒处接收到具有图12的上部中所示出的报头的修复分组。在该情况下，实施例组件可以很有把握地确定：对应于OSNI＝191的、具有FLID＝8的源流的源对象是具有OSN＝700的源对象，对应于OSNI＝192的、具有FLID＝8的源流的源对象是具有OSN＝701的源对象，并且对应于OSNI＝96的、具有FLID＝9 的源流的源对象是具有OSN＝350的源对象。

各种实施例可以包括被配置为进行以下操作的组件：执行对源对象和/ 或源对象的部分的FEC恢复。接收方设备可以被配置为：根据针对接收到的修复分组的修复流声明中所列出的源流的FLID(例如，TSI字段值)、修复分组的修复分组报头中的OSN和/或根据来自受保护的源对象的源符号的范围，来确定该修复分组所保护的源对象或部分。

接收方设备可以被配置为：根据修复分组的修复FEC有效载荷ID 904 中的开始和结束位置值字段，来确定针对受保护对象的部分的符号范围。接收方设备可以根据修复分组的修复FEC有效载荷ID 904中的TOL，来确定针对受保护的源对象中的每个源对象的FEC传输对象大小(以符号为单位)。在一个实施例中，接收方设备可以被配置为：通过对FEC传输对象大小求和来确定FEC编码对象906的大小。接收方设备可以使用修复分组的修复FEC有效载荷ID 904中所携带的ESI，来确定如何根据FEC编码对象 906来生成符号(或者多个符号或符号的部分)。

接收方设备可以被配置为：确定源数据在来自针对受保护的源对象中的一个源对象接收到的源分组的、FEC编码对象906中的身份和放置。例如，可以根据源分组报头中接收到的FLID和OSN、根据FEC传输对象的 TOL、根据符号范围、以及根据源分组的源有效载荷ID中的字节偏移，来确定源数据在来自针对受保护的源对象中的一个源对象的接收到的源分组的、FEC编码对象906中的身份和放置。接收方设备的FEC解码器可以基于相结合接收来自源分组的FEC编码对象906(或者对象的部分)的足够的源数据、字节或符号范围信息、针对来自修复分组的FEC编码对象906 的修复符号、以及适当放置的源分组数据，来恢复FEC编码对象906的全部或部分。

接收方设备可以被配置为：从FEC编码对象906(或者其部分)中提取FEC传输对象。接收方设备可以基于在每个FEC传输对象的结尾处的源对象大小字段和/或根据字节范围信息，来从FEC传输对象中提取源对象(或者部分)。

在替代的实施例中，与使用字节范围相反，组件可以被配置为使用现有的FEC方案的源FEC有效载荷ID。该实施例至少在源传递级上可以更好地支持与现有的FEC方案的后向兼容。该实施例还可以支持对象绑定。例如，在执行FEC操作或者应用本申请中所讨论的改进的FEC框架之前，可以将源FEC有效载荷ID变换为字节范围。该实施例还可以允许在源协议组件中应用具有任意FEC方案的改进的FEC框架，所述改进的FEC框架在下面进一步详细讨论。

举另一个替代方案，组件可以被配置为：以信号发送由修复流保护的传输源对象，以便避免在修复分组报头内的带内信令。具体而言，可以使用修复流声明内的模板化来以信号发送要由修复流保护的源对象TOI，而不是在修复分组报头中显式地携带OSN(或者OSNI)的列表。

各种实施例可以包括被配置为利用修复流执行组块传递/接收的组件。在广播侧，服务器可以在源对象变得可用时以组块的形式发送源对象，对在那些对象的源分组之后发送的受保护的源对象进行修复，以及使其对端到端延迟的影响最小化。在接收方侧，接收方设备可以在源对象以组块的形式抵达时恢复源对象。可以在接收到源对象数据时使其可用于客户端应用。接收方设备可以仅当接收到针对对象的修复时才对第一源对象回放进行回放，即使不需要FEC解码。这防止将来当针对后续的源对象需要FEC 解码时的停顿。替代地，FEC编码可以应用于源对象的部分，从而允许在源对象的部分抵达接收方设备时对其进行FEC解码，并且因此允许在接收方设备处更迅速的回放。

在一个实施例中，接收方设备可以被配置为：在接收到源对象之后立即开始回放/呈现第一个源对象。要求FEC解码的、后续的分组丢失在等待 FEC修复的抵达时会触发停顿。高级媒体播出系统可以通过对媒体的播出速率进行调整(例如，通过以比额定的视频帧率更低的视频帧率来播放或者通过使用音频处理来延长播出时间)来组合这些FEC技术。

在另一个实施例中，将信息打包成对象的方法可以扩展为在MPEG媒体传输(MMT)内提供传输通用文件和资产，用于增强MMT以提供与上面所描述的增强FLUTE/3GPP MBMS类似的能力和益处以及功能。该实施例解决了对要在网络上(通常以广播或多播模式)传递的相关文件的序列 (例如，划分成文件序列的视频或音频流)的传递的问题。一种激励性的例子是传递DASH区段，其中每个区段是音频或视频的文件或者经复用的音频/视频DASH表示。

存在经由MSMB来传递DASH区段的现有的解决方案，但是这些现有的解决方案缺乏用于指示或以信号发送文件的序列在逻辑上是相关的能力和/或缺乏用于指定区段、文件、对象、实体、流等之间的关系的能力。如上面所描述的，本文我们描述利用这些能力和信令来增强MBMS的方法。本文所描述的实施例还可以针对上面针对FLUTE/3GPP MBMS协议族所描述的相同的整体系统结构和方法，提供了增强MPEG MMT协议族的新的信令、协议、过程和方法，并且所述新的信令、协议、过程和方法还增强上面所描述的整体方法和信令操作。

概括地说，该实施例提供了用于通过MMT协议来传递通用资产的解决方案。通用资产可以是逻辑上成组的并且共享针对应用的某种共性(例如，DASH表示的区段、MPU序列等)的一个或多个文件。组件可以被配置为：使用通用文件传递会话(GFDS)，经由通用文件传递(GFD)协议来传递通用资产。

可以定义针对通用资产或对象的新的数据类型以用于包含要传输的通用对象的有效载荷。携带通用对象的分组可以具有通用有效载荷报头。GFD 会话内传递的每个文件可以与传输传递信息相关联。这可以包括但不限于诸如传输长度和传输编码之类的信息。对于传输编码，可以定义不同的类型，这些类型实现传递无带内元信息的文件、具有带内元信息的文件，并且实现对具有带内元信息的文件的渐进式传递。

通常，MMT协议依赖于接收方处的会话信息的存在性和可用性，以便解释协议分组。会话信息可以对流进行描述以及对接收方设备要如何解释和/或访问经由流传递的对象进行描述。在一个实施例中，可以在一个或多个码点中定义、包括和/或传递这种会话信息。例如，码点可以用于以信号发送相关对象的分组或序列符合码点中所定义的特定的限制集合。在这些实施例中，可以使用packet_id(分组_id)属性和值来实现上面针对流ID (FLID)所讨论的操作。因此，在MMT内传输通用文件和资产的上下文中，packet_id可以与上面所讨论的FLID属性相同或相对应。

实施例可以包括被配置为进行以下操作的组件：向对象或相关对象的序列分配通常仅当经由HTTP传递内容时才可用的信息。实施例可以包括被配置为进行以下操作的组件：向对象或对象的序列分配信息，并且以高效的方式来传递并使用这种信息。这可以通过将对于多个对象来说静态的并且相同的信息添加到对会话信息进行定义的码点中来实现。

简要地说，码点可以定义、包括或者指定各种属性，例如文件传递模式和利用该码点信令所传递的任何对象的最大传输长度。此外，码点可以包括以下信息中的任何信息：对象的实际传输长度；可以出现在实体报头中的任何信息；使用TOI和packet_id(如果存在的话)参数的 Content-Location-Template(内容-位置-模板)；以及关于内容的特定信息(例如，内容是如何打包的，等等)。

在单个会话中可能存在多种类别的属性。在一个实施例中，可以生成每个码点，使其定义一种类别的属性，并且可以使用多个码点来传送针对会话的多种类别的属性。

在一个实施例中，可以生成每个码点，以便使其特定于相关对象的序列中或该相关对象的特定子序列中的特定的对象。也就是说，对象序列中的每个对象可以指代一个码点。在一个实施例中，可以在模板文件或者类似的数据结构中定义码点。

实施例可以包括被配置为在一个会话内以信号发送多个码点的组件。组件可以经由码点来生成实体报头，该实体报头包括HTTP RFC 2616中可用的所有信息和属性以及另外的或补充的信息。组件可以生成包括非静态信息的码点，例如包括可以进行解析(例如，使用TOI等)的参数的模板。

实施例可以包括被配置为在GFD会话中传递文件的组件，其中所述文件可能必须被提供给应用(例如，复合信息文档、媒体呈现描述等)。可以通过所提供的URI或者根据Content-Location(内容-位置)推导出的URI 来引用该文件，其中可以在带内或者作为会话描述的一部分来提供 Content-Location。也就是说，可能存在引用该文件的应用，并且在会话描述中包括这种信息可以允许建立适用于在MMT内传输通用文件和资产的连接。

在一个实施例中，码点可以定义用于传递文件或对象的不同方式。例如，对象可以是不包括任何另外信息的常规文件(即，常规文件模式)。对象可以是包括实体报头和文件的实体(即，常规实体模式)。对象可以传递成实体报头、文件和报尾(即，渐进式实体模式)。

图13A示出了在广播或多播网络上传送对象流中的信息的实施例服务器方法1300。在框1302中，广播网络中的服务器的服务器处理器可以将信息打包成对象。在一个实施例中，作为框1302中将信息打包成对象的一部分，在可选框1304中服务器处理器可以将信息打包成可变大小的源分组。在一个实施例中，作为框1302的一部分，在可选框1306中服务器处理器可以对信息打包，使得对象不包括前向纠错语义。在一个实施例中，作为框1302的一部分，在可选框1308中服务器处理器可以将信息打包成FLUTE 对象。

在框1310中，服务器处理器可以在广播网络上发送对象流中的对象而不发送针对文件传递表(FDT)中的每个对象的伴随元数据。在一个实施例中，作为框1310的一部分，在可选框1312中服务器处理器可以将对象发送成相关对象的序列。在一个实施例中，作为框1310的一部分，在可选框 1314中服务器处理器可以在信息中的所有信息可用之前开始对象传输。在一个实施例中，作为框1310的一部分，在可选框1316中服务器处理器可以经由FLUTE在广播网络上发送对象。

图13B示出了在广播或多播网络上接收对象流中的信息并且确定是否已接收到整个源对象或者对象的至少某一部分是否从接收到的源分组中缺失的实施例接收方设备方法1350。在框1352中，接收方设备的设备处理器可以接收从广播或多播网络发送的源分组。在判定框1354中，设备处理器可以确定接收到的源分组中是否有任何源分组包括具有值为“1”的B-标志数据字段。

当设备处理器确定接收到的源分组包括具有值为“1”的B-标志数据字段时(即，判定框1354＝“是”)，在框1356中，设备处理器可以确定它已接收到对象的后缀。在框1358中，设备处理器可以通过对具有B-标志设置为“1”的分组中的字节偏移和该分组的分组有效载荷大小进行求和，来计算对象的大小。在框1360和1362中，设备处理器可以根据接收到的源分组的字节偏移和分组有效载荷大小，来确定是否存在源对象的内部部分缺失。当确定不存在内部部分从接收到的源分组中缺失时(即，判定框1362＝“否”)，在框1364中，设备处理器可以呈现接收到的源分组中所包括的内容和/或信息。当确定存在内部部分从接收到的源分组中缺失时(即，判定框1362＝“是”)，在可选框1366中，设备处理器可以执行恢复操作，例如等待接收另外的信息、请求重新发送信息、使用接收到的修复分组对源对象的缺失部分进行FEC解码、或者对接收到的分组进行处理以便以降低的质量来呈现内容。

当设备处理器确定接收到的源分组不包括具有值为“1”的B-标志数据字段时(即，判定框1354＝“否”)，在框1368中，设备处理器可以确定至少对象的某种后缀还未接收到。在可选的判定框1370中，设备处理器可以确定定时器是否已到期或者是否已满足另一测试条件，以指示有很高的概率将不会接收到对象的后缀。如果设备处理器确定定时器还没有到期或者还没有满足其它的测试条件(可选判定框1370＝“否”)，在框1352中，设备处理器可以等待接收另外的源分组。

当设备处理器确定定时器已到期或者已满足另一测试条件(可选判定框1370＝“是”)，在可选框1366中，设备处理器可以执行多个修复操作中的任何修复操作，例如使用接收到的修复分组对源对象的缺失部分进行 FEC解码，或者请求重新发送信息，或者对接收到的分组进行处理以便以降低的质量来呈现内容。

在各种实施例中，可以对服务器和接收方组件进行配置，使得上面提到的操作、方法和解决方案中的任何或所有操作、方法和解决方案可以作为现有技术和/或结构的扩展来执行、完成或实现。

图14A-图14B根据各种实施例，示出了适用于传送内容的广播通信系统1400、1420中的逻辑组件和功能组件。在这些广播通信系统1400、1420 中的每个广播通信系统中，用于接收、打包、FEC保护、信令和传送信息的操作划分成单独的和独立的操作群组或类别，并且可以由一个或多个硬件和/或软件组件(例如，服务器计算设备，等等)来执行每个操作群组或类别。这种成组/组织可以更好地允许广播通信系统1400、1420中的每个广播通信系统更好地支持各种不同的保护方案和传递技术、协议以及标准。

图14A示出了广播通信系统1400可以划分或组织成两个主要群组：源传递协议1402和前向纠错(FEC)框架1404。以此方式来划分/组织系统 1400允许对两个异步分层编码(ALC)实例化进行复用或以其它方式进行组合。这允许经由各种现有的技术和/或结构(包括现有的FLUTE框架)来传递内容。这种组织/成组还允许广播通信系统1400提供相对于现有的广播解决方案的多种其它的增强和益处，包括本文所讨论的特征。

在图14A中所示出的例子中，源传递协议1402包括源ALC组件1406。源ALC组件1406可以被配置为包括源LCT并且不要求使用FEC(无FEC)。前向纠错(FEC)框架1404可以包括对象绑定组件1414和修复ALC组件 1408。修复ALC组件1408可以包括修复LCT和FEC方案。

源传递协议1402将多媒体内容编码成两个文件集合1410和1412。每个集合1410、1412可以包括一组相关的文件。举例而言，第一集合1410 可以包括视频数据文件，并且第二集合1412可以包括音频数据文件。每个集合1410、1412可以是或者可以不是流。可以向每个集合1410、1412分配静态元数据(静态元数据1、静态元数据2)。在图14A中所示出的例子中，第二集合中的每个文件与动态元数据(DMD)相关联。

系统1400可以被配置为将系统中的每个文件视作为单独的对象，并且可以通过ALC实例化来传递每个文件/对象。

源ALC组件1406可以被配置为传递文件、对象、流、绑定体或集合。修复ALC组件1408可以被配置为灵活地保护文件、对象、流、绑定体或集合以用于FEC。

系统1400可以定义针对LCT/UDP的新的协议句柄，该句柄对协议进行标识。在一个实施例中，系统1400可以使用码点来标识不同的对象集合并分配参数。

系统1400可以被配置为：支持乱序发送对象的字节范围以及在会话定义中以信号发送对象的传输，使得可以向客户端应用(例如，在接收方设备中)提前通知对象和/或传输，很可能具有最大交织深度。这允许系统1400 支持需要在文件的开始处添加对象大小的格式。这还允许首先发送对象的内容数据，并且稍后一旦报头数据可用，就通过指示与更早发送的相同对象的数据相比更小的字节范围数字来发送大小字段/报头。这允许接收方设备在指定的字节范围处添加报头的情况下重构对象。

在一个实施例中，系统1400可以被配置为提供开始TOI、结束TOI或二者，这些可以用于以信号发送受限制列表。在另外的实施例中，码点可以指代使用中的静态FDI，并且LCT时间报头可以用于对服务器时间和客户端进行同步以及用于测量端到端的延迟或抖动。修复流可以包括对会话描述1416和码点的引用，该引用可以用于获得详细的保护特性。

在一个实施例中，FEC框架组件1404可以被配置为仅发送修复分组。在一个实施例中，系统1400可以被配置为定义LCT扩展报头，以便实现发送单独对象的大小。在一个实施例中，系统1400可以被配置为定义受FEC 保护的超级对象。

图14B根据各种实施例，示出了示例性的广播通信系统1420中的各种组件和信息流，其中广播通信系统1420被配置为：基于两个集合(即，两个相关的对象组)来生成FEC修复分组；以及独立于FEC修复分组来向接收方设备传递对象。在图14B中所示出的例子中，将广播通信系统1420组织成源协议组件1424和修复协议组件1426。修复协议组件1406包括源对象创建组件1434、修复ALC组件1436、LCT组件1438和FEC方案组件 1440。源协议组件1424包括源分组创建组件1428和LCT组件1430，源分组创建组件1428和LCT组件1430的组合可以被配置为传递对象(例如，源/传递对象)或对象的流/集合。在一个实施例中，源分组创建组件1428 和/或LCT组件1430可以是异步分层编码(ALC)实例化。

源协议组件1424可以被配置为接收、使用、打包和传送源数据1442。源协议组件1424可以经由传递对象或对象的流/集合来传送源数据1442。每个传递对象可以是针对应用自包含的对象，很可能与来自静态元数据的信息以及传输会话/流标识符(TSI)和传输对象标识符(TOI)的LCT报头数据相结合。

源协议组件1424可以被配置为：接收并使用包括不同的信息单元/实体的集合的源数据1422，其中每个信息单元/实体可以具有不同的特性或属性。例如，源协议组件1424可以接收并使用源数据1402，该源数据1402 包括：非实时数据和实时数据的组合、仅作为整体可访问的并且包括不同大小(例如，在几千字节至几千兆字节之间)的子单元(例如，文件)的单个数据文件(例如，经压缩的文件，等等)、和/或可单独地访问但是仅一起时才有用的数据文件的集合(例如，web页面的对象，等等)。举另外的例子，源数据1402可以包括：大型多媒体文件(其作为整体在广播多播服务中心(BMSC)上可用并且无实时约束地分发)、通过任意的URL名称来引用的定时的媒体区段的集合(例如，HLS分发中的一个表示)、通过公共 URL模式来引用的定时的媒体区段的集合(例如，DASH中的媒体呈现中的表示)，是媒体呈现的一部分的媒体区段、联合地分发并且联合地播出的多个媒体组件、或者在服务器中逐渐地生成并且在服务器生成整个文件之前发送的媒体文件。举另一个例子，源数据1402可以包括媒体文件，其中接收方设备可以在仅接收到该媒体文件的一部分(例如，分段的MP4文件、 DASH点播(On-Demand)格式表示，等等)之后开始呈现、播放或消耗，但是该媒体文件仅作为整体可用于服务器。

源协议组件1424可以被配置为使用源数据1422来生成相关对象的集合(即，集合1和集合2)。在图14B中所示出的例子中，源协议组件1424 生成第一集合(集合1)，第一集合包括三个传递对象(即，传递对象1-3) 和静态元数据(即，静态元数据1)。第二集合(集合2)包括静态元数据 (即，静态元数据2)和与动态元数据(DMD)相关联的三个传递对象(即，传递对象1’-3’)。

在一个实施例中，源协议组件1424可以被配置为：将会话信息传递成下载传递会话。下载传递会话可以包括在会话描述协议(SDP)单元中或者由SDP单元来描述。

在一个实施例中，源协议组件1424可以被配置为：以信号发送对会话信息或源协议的使用进行描述的FEC方案。在一个实施例中，源协议组件 1424可以被配置为：经由会话描述协议(SDP)单元来以信号发送FEC方案。

在各种实施例中，源协议组件1424可以被配置为：生成、使用或传送静态和/或动态文件传递描述符(FDD)。源协议组件1424可以针对每个下载传递会话来生成、使用或传送一个或多个静态FDD分段。源协议组件1424 可以将一个或多个静态FDD分段与单个下载传递会话进行关联。可以经由 @tsi数据字段值来标识每个FDD，其中@tsi数据字段值包括在会话描述协议(SDP)单元的下载传递会话中。在一个实施例中，源协议组件1424可以生成、使用或传送FDD，使得FDD复制文件传递表(FDT)的所有功能。在一个实施例中，源协议组件1424可以被配置为：生成、使用或传送FDD，使得FDD可以用于例如通过使用TOI和模板来生成FDT的等效项。

在各种实施例中，源协议组件1424可以被配置为：生成、使用和/或传送源流声明。源流声明可以包括在用户服务描述(USD)中并经由USD来传送。在一个实施例中，可以生成USD，使其包括元数据分段。每个元数据分段可以包括StaticFDD(静态FDD)数据字段，该数据字段指定静态文件传递描述符(FDD)。每个StaticFDD数据字段还可以包括各种其它的数据字段，例如@tsi数据字段、@objectDeliveryMode数据字段、 @oufOfOrderSending数据字段、@expires数据字段、@complete数据字段、 @contentType数据字段、@contentEncoding数据字段、CodePoint数据字段、 File数据字段以及FileTemplate数据字段。这些数据字段中的每个数据字段可以包括可以由各种实施例组件用于对源数据、传递数据或通信的各种特性进行标识或确定的信息。

例如，@oufOfOrderSending数据字段可以包括可以用于确定是否乱序地发送源数据1422的信息。@objectDeliveryMode数据字段可以包括可以用于对对象传递模式进行标识的信息。@tsi数据字段可以包括传输会话/流标识符(TSI)，或者可以用于对静态文件传递描述符(FDD)在LCT报头中被分配至的传输会话进行标识的信息。例如，@tsi数据字段可以包括TSI，该TSI对用于解释传递对象或传递对象的集合的静态FDD实例进行标识。此外，@tsi数据字段还可以包括针对传递对象或传递对象的集合的唯一标识符(在会话的范围内)。

StaticFDD数据字段的CodePoint数据字段可以包括对分组报头中使用的码点进行标识和/或对到特定值的映射进行标识的信息。CodePoint数据字段可以包括各种其它的数据字段，例如@assignment数据字段、 @schemeIDURI数据字段和@value数据字段。@assignment数据字段可以包括对分配给码点的CP字段(码点字段)的值进行标识的信息。 @schemeIDURI数据字段可以包括对定义码点的方案进行标识的信息。 @value数据字段可以包括对定义码点的方案的值进行标识的信息。

StaticFDD数据字段的File数据字段可以包括当使用现有的FLUTE解决方案时通常包括在“File单元”中的相同或相似信息。但是，与现有的解决方案中所使用的“File单元”不同，不要求File数据字段包括FEC参数。此外，File数据字段可以包括各种其它的数据字段，例如@byteRange数据字段。@byteRange数据字段可以包括对构成传递对象的文件的字节范围进行标识的信息。该字节范围可以表示为或格式化为特定于字节范围的表达式，或者对连续的字节范围进行标识的表达式。实施例组件(例如，接收方设备)可以使用该信息来确定传递对象是否包括整个文件或者文件的部分。例如，响应于确定@byteRange数据字段为null、空或者不包括任何值，组件可以确定整个文件是传递对象。

StaticFDD数据字段的FileTemplate数据字段可以包括可以由实施例组件用于对文件模板(其可以包括在传递对象或HTTP实体的主体中)进行标识的信息。FileTemplate数据字段可以包括各种其它的数据字段，例如 @startTOI数据字段和@endTOI数据字段。@startTOI数据字段可以包括可以用于对传递的第一个TOI进行标识的信息。@endTOI数据字段可以包括对传递的最后一个TOI进行标识的信息。

在各种实施例中，源协议组件1424可以被配置为：对会话中所传递的所有文件进行描述。源协议组件1424可以单独地或者经由列表来对文件进行描述。源协议组件1424还可以在一次性的静态描述(例如，文件传递描述符)中包括静态文件信息，并且使用报头字段来创建动态信息，例如， URL/URI信息。源协议组件1424可以使用这种技术来描述对象、对象集合或汇集。实施例组件可以使用本文所描述的各种技术中的任何技术来标识对象集合或对象群组。例如，TSI值可以界定对象集合或群组的范围，在这种情况下，可以使用TOI和/或字节范围来标识对象群组。

在各种实施例中，源协议组件1424可以被配置为：使用模板和模板化技术来以信号发送在与要传递的对象或集合相关联的位置、名称、可用性时间和其它元数据之间的关系。可以使用这种模板和模板化技术来提供用于推导出对象的URI、对象的传递时间、在FLID、OSN和URI之间的关系等的机制。

在一个实施例中，源协议组件1424可以被配置为：在静态文件传递描述符中包括FileTemplate元素或数据字段。FileTemplate数据字段可以包括可以利用替代参数来替换(例如，在接收方设备中接收到整个传递对象或文件之后)的标识符。例如，FileTemplate数据字段可以包括$TSI$标识符和$TOI$标识符，其中$TSI$标识符可以利用相应的LCT分组的TSI来替换， $TOI$标识符可以利用相应的LCT分组的TOI来替换。

在一个实施例中，源协议组件1424可以被配置为传递对象或实体，该对象或实体包括具有实体报头字段形式的元信息和具有实体主体形式的内容(例如，文件、对象等)。源协议组件1424可以例如经由带内的传递技术和/或以动态的方式，在与文件自身相同的传递对象中包括文件属性。例如，源协议组件1424可以经由包括相应文件的相同传递对象，来对诸如 Content-Location(内容-位置)、Content-Size(内容-大小)、Content-Range (内容-范围)之类的属性进行关联和传递。

在各种实施例中，源协议组件1424可以被配置为：在各种文件传递表 (FDT)通信模式(包括扩展的FDT模式)下进行操作。当在扩展的FDT 模式下进行操作时，源协议组件1424可以使用FDT和FDT扩展来提供或传送通常包括在实体报头中的信息。使用FDT扩展可以允许源协议组件 1424经由FLUTE来以信号发送HTTP扩展报头和其它HTTP能力。

源协议组件1424可以被配置为：在各种文件传递模式(例如，文件模式、常规实体模式、渐进式实体模式、冗余FDT模式、互补式FDT模式和动态FDT模式)下进行操作。在一个实施例中，源协议组件1424可以被配置为：经由静态文件传递描述符单元来标识文件传递模式。

当在文件模式下进行操作时，源协议组件1424可以将对象传递成常规文件或者文件的字节范围。也就是说，当在常规文件模式下进行操作时，每个传递对象可以表示文件或文件的字节范围(即，@byteRange存在)。源协议组件1424可以包括与FDD中的传递对象相关联的所有信息，并且可以经由静态FDD或静态FDT来传递文件或字节范围的所有属性。

源协议组件1424还可以在常规实体模式下操作。在该模式下，经由LCT 的对象传递可以与经由HTTP实体传递内容的现有的HTTP传递技术紧密地或完全地对齐。如上面所提到的，HTTP实体包括实体报头和实体主体。因此，当在常规实体模式下进行操作时，源协议组件1424可以将对象传递成包括实体报头和实体主体(即，文件)的实体。可以生成或传送传递对象，使得它们以实体报头开始。可以生成或传送传递对象，使得消息主体包括URL和内容范围，该URL和内容范围可以用于以信号发送、传送或确定传递对象是对象/文件的某一字节范围，而不是完整的对象/文件。

当在常规实体模式下进行操作时，源协议组件1424在适用于所传递的文件的静态文件传递描述符(FDD)或静态文件传递表(FDT)中传递文件的所有属性。此外，与文件或字节范围(例如，在带内)一起发送的实体报头可以包括针对该文件/字节范围的另外的信息。当某些属性出现在FDD 和实体报头二者中时，则实体报头中的值可以覆写静态FDD中的对应值。当报头包含实体报头中的Content-Range时，则可以确定传递对象包括对象 /文件的某一字节范围，而不是完整的对象/文件。

源协议组件1424还可以在渐进式实体模式下操作，以实现对文件的渐进式传递，与可以经由HTTP/1.1中的分块传输模式实现的传递类似。当在渐进式实体模式下进行操作时，源协议组件1424可以将对象传递成包括实体报头、文件和报尾的实体。报尾可以包含另外的报头字段，该另外的报头字段使得源协议组件1424能够以渐进的方式传递对象/文件，即，可以在生成整个文件之前传递对象/文件。

在各种实施例中，源协议组件1424可以被配置为：在码点或实体报头中包括报尾。静态文件传递表(FDT)中的所有属性可以应用于所传递的对象/文件。此外，源协议组件1424可以生成实体报头，使其包括针对文件的另外的信息。当某些属性出现在两个位置(即，FDD和实体报头)中时，实体报头中的值可以覆写静态FDD中的相应值。

当在冗余FDT模式下进行操作时，源协议组件1424可以与对象一起生成并发送FDT，使得FDT中所包括的信息对于FDD中所包括的信息来说是冗余的。当在互补式FDT模式下进行操作时，源协议组件1424可以与对象一起生成并发送FDT，使得FDT包括对于接收方设备可能有用的另外的信息。当在动态FDT模式下进行操作时，源协议组件1424可以与对象一起生成并发送FDT，使得FDT包括可以由接收方设备使用的必要的另外信息。

源协议组件1424可以被配置为：以特定的方式来使用LCT通信技术和方法，以便经由FLUTE实现对象传递，并且支持本申请中所讨论的各种特征和功能。例如，源协议组件1424可以将拥塞控制报头(LCT/ALC中所定义的)值设置为零(0)，根据分组所应用的传递对象集合来设置LCT 报头中的TSI(例如，经由@tsi数据字段)，基于@codepoint数据字段的值来设置LCT报头中的码点，将PSI的第一比特设置为零(0)以指示源分组，等等。源协议组件1424还可以使用源FEC有效载荷ID，源FEC有效载荷 ID指定传递对象的起始地址(例如，以八位字节、字节等为单位)。可以经由直接寻址(例如，使用32或64比特)或者通过使用SBN、ESI和符号大小(T)值来传送该信息。

源协议组件1424可以被配置为：使用LCT报头EXT_TIME扩展来传送或以信号发送各种时间值和事件。例如，源协议组件1424可以使用 EXT_TIME扩展作为“发送方当前时间”字段来以信号发送发送方的当前时间。该信息可以用于对发送方和接收方设备中的时钟进行同步。举另一个例子，源协议组件1424可以使用EXT_TIME扩展作为“预期残余时间”字段，以便以信号发送针对当前对象的预期剩余时间。源协议组件1424还可以使用EXT_TIME扩展作为SLC标志(会话最后改变标志)来以信号发送区段的添加或移除。

源协议组件1424可以被配置为：在发送方设备中接收到或生成所有的文件/对象之前，乱序地发送文件/对象的字节范围或部分。因此，对象/文件的这些字节范围可能不是顺序地发送的。更确切地说，较晚的字节范围可能在较早的字节范围之前发送。在这些情况下，源协议组件1424可以使用 @outOfOrderSending数据字段来向接收方设备传达：发送方设备应用这种技术和/或这些字节范围可以被乱序地发送。

对于要求在产生媒体之后生成报头数据的数据格式(例如，在报头中包括文件的大小信息的格式)来说，乱序地发送文件/对象的字节范围或部分是特别有用的。对于这种格式，源协议组件1424可以在发送数据之后向接收方设备发送报头，使得接收方设备可以接收并使用该报头信息来确定数据单元的大小。由于通常提前知道报头字段的大小，因此这可以通过接收方设备在接收对象时跳过报头部分或通过使用本申请中所讨论的其它技术中的任何技术来实现。为了支持报头字段的大小是可变的格式，源协议组件1424可以对数据或通信进行填充。源协议组件1424还可以设置或使用标志来传送在时间上的交织深度(例如，毫秒)、最大数据范围等。

在各种实施例中，系统1140可以被配置为：通过源流和修复流的不同的UDP流(即，在不同的IP/UDP端口组合上所携带的)和/或经由源流和修复流的会话描述协议(SDP)文件来对源流和修复流进行区分。当LCT 分组在相同的UDP流中进行发送时，系统1140可以基于分组的LCT报头字段中的传输会话/流标识符(TSI)来区分源流和修复流。当LCT分组在相同的UDP流中进行发送并且具有相同的TSI值时，系统1140可以基于分组的报头中的节目和系统信息(PSI)比特来区分源流/分组和修复流/分组。当系统1420在后向兼容模式下操作或者要求支持后向兼容模式时，这可能是特别有用的。

修复协议组件1426可以被配置为：保护传递对象的片(piece)、传递对象的绑定体和/或传递对象的片的绑定体以用于FEC。此外，修复协议组件1426可以被配置为实现对传递对象或其片的传递(与对分组进行保护相对)。

修复协议组件1426可以包括FEC方案组件1434，FEC方案组件1434 被配置为：定义FEC编码方案、FEC解码方案、和/或用于对分组有效载荷数据进行标识的各种其它协议字段和过程(即，在FEC方案的上下文中)。在各种实施例中，FEC方案组件1434可以实现为、或者被配置为操作成传输层(例如，UDP/IP多播)组件1428之上的功能层。

修复协议组件1426还可以包括修复异步分层编码(ALC)组件1438， ALC组件1438被配置为：灵活地保护传递对象1430或对象的集合(例如，集合1、集合2)。此外，修复协议组件1426和源协议组件1424中的每个组件可以包括分层编码传输(LCT)组件1436。分组可以是LCT分组。

修复协议组件1426可以被配置为生成一个或多个FEC对象。每个FEC 对象可以是完整的传递对象或者传递对象的连续字节范围。在各种实施例中，可以对修复协议组件1426进行配置，使得FEC保护可以应用于单个 FEC对象或FEC对象的集合。可以对修复协议组件1426进行配置，使得 TSI可以用于界定FEC对象的集合的范围。修复协议组件1426可以被配置为：独立于FEC结构和/或使用本申请中所讨论的技术中的任何技术来对 TOI/TSI进行实例化。

在各种实施例中，可以对修复协议组件1426进行配置，使得仅当确定需要、要求与FEC相关的信息和/或与FEC相关的信息有用时才传送该信息。修复协议组件1426还可以被配置为传送与FEC相关的信息，使得不能够执行FEC操作的接收方设备能够忽略与FEC相关的信息并且仍然呈现其相应的内容。修复协议组件1426可以被配置为：在针对每个受保护的修复流具有固定的符号大小的情况下，执行基于符号的FEC操作。修复协议组件1426还可以被配置为：执行FEC操作，使得每个修复流提供针对来自一个或多个源流的传递对象的保护。

修复协议组件1426可以是FEC框架，该FEC框架包括或者被配置为传送以下各项：FEC修复流声明，其包括所有特定于FEC的信息；FEC对象，其是源对象的受保护的连续八位字节范围或者源对象自身；FEC传输对象，其是FEC对象的级联；FEC超级对象，其是一个或多个FEC传输对象的级联；FEC协议和分组结构。FEC传输对象可以包括填充八位字节和大小信息，这些可以用于形成符号对齐的数据组块。FEC超级对象可以用于绑定FEC传输对象以便FEC保护。

图15示出了实施例FEC框架1500中的各种结构、数据字段、通信分组、转换和信息流，其中FEC框架1500被配置为：基于两个源对象1504、 1506来生成FEC修复分组1502。FEC框架1500可以包括在上面参照图14B 所讨论的修复协议组件1426中或者实现为修复协议组件1426的一部分。在一个实施例中，源对象1504、1506可以与上面参照图14B所讨论的传递对象相同。

在图15中所示出的例子中，FEC框架1500生成针对第一源对象1504 的第一FEC对象1508，以及针对第二源对象1506的第二FEC对象1510。 FEC对象1508、1510中的每个FEC对象可以是完整的源对象或者源对象的连续八位字节范围。FEC框架1500可以被配置为：使用FEC对象1508、 1510的相应的源对象1504、1506的TSI和TOI和/或源对象1504、1506的八位字节范围(即，源对象1504、1506内的开始八位字节和构成要保护的 FEC对象1508、1510的源对象1504、1506的八位字节的数量)来生成FEC 对象1508、1510。

对于每个FEC对象1508、1510，FEC框架1500可以生成FEC传输对象1512、1514，其包括以下各项的级联：FEC对象1508、1510；填充八位字节(P)1516、1520；以及FEC对象大小(F)1518、1522。填充八位字节(P)1516、1520可以是被包括在临近FEC传输对象1512、1514的结尾处、在源对象1504、1506和FEC对象大小(F)1518、1522之间的填充数据。FEC对象大小(F)1518、1522值可以用八位字节表示和/或经由一四 (4)个八位字节字段进行传送。也就是说，可以在FEC传输对象1512、 1514的最后四(4)个八位字节中携带FEC对象大小(F)1518、1522。

在各种实施例中，FEC框架1500可以被配置为：基于会话信息和/或修复分组报头，针对FEC传输对象1512、1514中的每个FEC传输对象来计算FEC传输对象大小(S)。FEC框架1500可以以符号为单位来计算FEC 传输对象大小(S)和/或计算为符号大小(T)的整数倍。例如，如果FEC 对象大小(F)1518、1522是用八位字节表示的FEC对象1508、1510的大小，F是源对象1504、1506的F个八位字节的数据，参数“f”表示以网络八位字节顺序(高阶八位字节在前)携带F的值的四(4)个八位字节的数据，FEC传输对象大小(S)是具有S＝ceil((F+4)/T)的FEC传输对象的大小，填充八位字节(P)1516、1520是S*T-4-F零八位字节的数据，并且O 是F、P和f的级联，则O构成大小为S*T八位字节的FEC传输对象。

应当理解的是，不要求在源对象1504、1506的源分组中发送填充八位字节(P)1516、1520和FEC对象大小(F)1518、1522。更确切地说，可以将它们包括在FEC传输对象1512、1514中，其中FEC解码对FEC传输对象1512、1514进行恢复以提取FEC对象1508、1510，并且因此，提取构成FEC对象1508、1510的源对象1504、1506或者源对象1504、1506 的部分。

FEC框架1500可以被配置为：向接收方设备传送与FEC传输对象 1512、1514有关的通用信息。可以对FEC框架1500进行配置，使得传送给具有FEC能力的接收方设备的、与FEC传输对象1512、1514有关的通用信息是源TSI、源TOI、以及相关联的FEC对象1508、1510的源对象1504、 1506内的相关联的八位字节范围。由于可以在FEC传输对象1512、1514 内的附加字段中提供FEC对象1508、1510以八位字节为单位的大小，因此剩余的信息可以被传送成：源对象1504、1506的TSI和TOI，其中根据源对象1504、1506来生成与FEC传输对象1512、1514相关联的FEC对象 1508、1510；针对相关联的FEC对象1508、1510的源对象1504、1506内的开始八位字节；以及FEC传输对象1512、1514以符号为单位的大小。

FEC框架1500可以被配置为：基于FEC传输对象1512、1514和/或 FEC修复流声明来生成FEC超级对象1540。例如，FEC框架1500可以生成FEC超级对象1540，使其包括FEC传输对象1512和FEC传输对象1514 的级联。FEC框架1500还可以生成FEC超级对象1540，使其包括上面所描述的与FEC传输对象1512、1514有关的所有通用信息，以及对FEC超级对象1540内FEC传输对象1512、1514的顺序进行标识的信息。

在一个实施例中，FEC框架1500可以被配置为：确定FEC超级对象 1540中的源符号的数量。例如，如果N是用于FEC超级对象构造的FEC 传输对象的总数，S[i]是对于i＝0，…，N-1的FEC传输对象i以符号为单位的大小，并且B是包括FEC传输对象1512、1514按顺序的级联的FEC 超级对象1540，则可以确定FEC超级对象1540包括K＝sum(i＝0)(N-1)S[i] 个源符号。

FEC框架1500可以被配置为：生成FEC超级对象1540，使其包括FEC 传输对象1512、1514中所携带的通用信息以外的另外的通用信息。该信息可以包括FEC传输对象的总数N。该信息还可以包括针对每个FEC传输对象1512、1514的值，例如，源对象1504、1506(根据源对象1504、1506 来生成与FEC传输对象1512、1514相关联的FEC对象1508、1510)的TSI 和TOI；针对相关联的FEC对象1508、1510的源对象1504、1506内的开始八位字节；以及FEC传输对象1512、1514以符号为单位的大小。

在一个实施例中，FEC框架1500可以被配置为：基于FEC超级对象 1540来生成FEC修复分组1502。可以基于异步分层编码(ALC)、LCT分层编码传输(LCT)构建块来生成FEC修复分组1502和/或使FEC修复分组1502包括本申请中所讨论的技术、特征和修改中的任何技术、特征和修改。例如，可以根据FEC修复分组1502应用的修复流来设置LCT报头中的TSI，其中可以经由RepairFlow.SDPParameter@tsi属性来定义TSI。可以将SPI(源分组指示符)的第一比特设置为0以指示它是修复分组。可以在 LCT扩展报头中携带FEC配置信息。

举另外的例子，FEC框架1500可以被配置为：使用FEC构建块来仅传递修复分组。可以生成修复流(如由LCT报头中的TSI字段所指示的) 的范围内的每个修复分组，使其包括/携带适当的修复TOI，该修复TOI针对在TSI的范围内创建的每个FEC超级对象可以是唯一的。可以通过SDP 参数(例如，经由上面所讨论的SDPParameter)来传送会话描述信息。

FEC框架1500可以被配置为向接收方设备传送概要的FEC信息。在各种实施例中，FEC框架1500可以被配置为：在修复流声明中静态地传送概要的FEC信息、在LCT扩展报头中动态地传送概要的FEC信息、或者这两种方式的组合。FEC框架1500可以针对每个超级对象(由修复流内唯一的TOI进行标识并且通过LCT报头中的TSI与修复流关联)来传送该信息。该信息可以包括FEC配置信息、FEC编码ID、FEC OTI和另外的FEC 信息。该信息还可以包括：FEC超级对象1540中所包括的FEC对象的总数；以及源对象1504、1506(根据源对象1504、1506生成与FEC传输对象1512、1514相关联的FEC对象1508、1510)的TSI和TOI；针对相关联的FEC对象1508、1510的源对象1504、1506内的开始八位字节；以及 FEC传输对象1512、1514以符号为单位的大小。

FEC框架1500可以被配置为：生成、使用和/或传送包括FEC信令信息的FEC修复流声明。例如，在MBMS用户服务中，可以包括修复流声明作为绑定体描述或用户服务描述的分段。作为该修复流声明的一部分，在所有的修复流被声明为属于类型RepairFlow的情况下，FEC框架1500可以在@tsi属性中提供针对修复流的修复流标识符。IP地址、端口和修复流标识符的组合可以提供对用户服务内的所有流的唯一标识符。要注意的是，IP/ 端口组合可以携带不同的FEC修复数据以及源数据。在该情况下，可以通过LCT报头中不同的TSI值来区分数据。

在一个实施例中，FEC框架1500可以被配置为：生成修复流声明，使其包括对来自要由修复流保护的源流的源对象(或者源对象的八位字节范围)的模式进行标识的信息。在另外的实施例中，FEC框架1500可以生成修复流声明，使其包括元数据分段，该元数据分段包括对会话中的修复流进行定义的RepairFlow数据字段。每个RepairFlow数据字段还可以包括各种其它的数据字段，例如@tsi数据字段、@sessionDescription数据字段以及 FECParameters数据字段。@tsi数据字段可以包括可以用于对TSI(在会话中的LCT报头中向修复流分配的TSI)进行标识的信息。@sessionDescription 数据字段可以包括可以用于对包含修复流的会话描述的引用的信息。

FECParameters数据字段可以包括各种其它的数据字段，例如 @fecEncodingId数据字段、@maximumDelay数据字段、FECOTI数据字段和ProtectedObject数据字段。@fecEncodingId数据字段可以包括可以用于对所应用的FEC方案进行标识的信息。@maximumDelay数据字段可以包括可以用于对源流中的任何源分组和修复流之间的最大传递延迟进行标识的信息。FECOTI数据字段可以包括FEC对象传输信息(FEC OTI)，该FEC OTI与关联于对象的FEC相关信息以及关联于对象的编码符号的FEC信息相对应，该数据字段要包括在该声明中，并且应用于与修复流一起的所有修复分组。

ProtectedObject数据字段可以包括可以用于对修复流所保护的源流以及关于如何进行保护的细节进行标识的信息。实施例组件可以使用该信息来确定源流是否包含在与修复流相同的会话中、源流是否是利用与修复流相同的TSI来以信号发送的、源TOI是否与修复TOI相同，等等。响应于确定源TOI与修复TOI相同，实施例组件可以确定，可以经由LCT报头中的PSI标志来对分组进行区分。实施例组件还可以使用ProtectedObject数据字段中的信息来确定是否可以使用EXT_TOL报头来从修复分组中获得每个FEC传输对象的大小。

ProtectedObject数据字段可以包括可以用于对修复流中所包括的对象集合中的源对象进行标识的信息。ProtectedObject数据字段还可以包括各种其它的数据字段，例如@sessionDescription数据字段、@tsi数据字段、 @sourceTOI数据字段、@fecTransportObjectSize数据字段和@startOctet数据字段。

@sessionDescription数据字段可以包括可以用于对包含源流的会话描述进行标识的信息。实施例组件可以被配置为：响应于确定 @sessionDescription数据字段为空，确定源流包含在与修复流相同的会话中。

@tsi数据字段可以包括可以用于对针对要保护的源流的传输会话标识符进行标识的信息。实施例组件可以被配置为：响应于确定@tsi数据字段为空，确定源流是利用与修复流相同的tsi/TSI来以信号发送的，在这种情况下，如ALC IETF RFC 5775中所定义的，可以经由LCT报头中的SPI标志(源分组指示符标志)来对分组进行区分。

@sourceTOI数据字段可以包括可以用于对源对象的TOI以及修复流中所包含的TOI的映射进行标识的信息。实施例组件可以被配置为：响应于确定@sourceTOI数据字段为空，确定源TOI与修复TOI相同。

@fecTransportObjectSize数据字段可以包括可以用于对每个FEC传输对象的缺省大小(例如，以符号为单位)进行标识的信息。实施例组件可以被配置为：响应于确定@fecTransportObjectSize数据字段为空，确定可以使用EXT_TOL报头在修复分组中提供缺省大小值。

@startOctet数据字段可以包括可以用于对相关联的源对象中的开始八位字节进行标识的信息。实施例组件可以被配置为：响应于确定@startOctet 数据字段为空，确定可以使用EXT_TOL报头在修复分组中包括开始八位字节信息。实施例组件还可以被配置为：响应于确定@startOctet数据字段包括值或者不为空，确定将不存在EXT_TOL报头。

在一个实施例中，组件(例如，接收方设备)可以被配置为：响应于确定修复流声明包括ProtectedObject数据字段值，确定@sourceTOI属性指定修复分组中所包含的修复TOI值到修复分组所保护的源对象的源TOI的映射。可以通过具有C格式的等式来描述该映射，其中修复流的TOI字段被指定为变量TOI。组件可以使用应用该等式的结果来确定源TOI。该属性的值可以是适当的C等式，其具有最多一个变量TOI并且不添加“；”符号。组件还可以被配置为：响应于确定ProtectedObject数据字段中不包括 @sourceTOI数据字段值，应用缺省式(例如，sourceTOI＝“TOI”)。

在服务器或接收方设备中可以如下表示针对具有TSI值10和值TOI 20 的修复分组(该修复分组对来自具有TSI值1的源流的、具有TOI值20的源对象进行保护)的示例性修复流声明：

不包括@sourceTOI值的示例性修复流声明如下：

在上面的例子中，由于在ProtectedObject中没有提供@sourceTOI属性，因此使用缺省式sourceTOI＝“TOI”来从TOI中推导出源TOI。因此，由具有TSI 11和TOI 20的修复分组保护的超级对象是针对具有TSI 2和TOI 20 的FEC传输对象以及针对具有TSI 3和TOI 20的FEC传输对象的级联。定义了在上述两种情况下的FEC传输对象大小并且FEC超级对象具有2232 符号的总大小。

在服务器或接收方设备中可以如下表示针对由具有TSI 12和TOI 20的修复分组保护的FEC超级对象(该FEC超级对象是针对具有TSI 4和TOI 40 的源对象的FEC传输对象、针对具有TSI 5和TOI 20的源对象的FEC传输对象以及针对具有TSI 4和TOI 41的源对象的FEC传输对象的级联)的示例性修复流声明：

在上面的例子中，修复流声明中不包括源对象的FEC传输对象大小。此外，修复流声明内的ProtectedObject声明序列可以用于确定超级对象中针对源对象的FEC传输对象的顺序。

在服务器或接收方设备中可以如下表示针对具有TSI 13和TOI 20的修复分组(该修复分组对具有TSI 6和TOI 21的源对象进行保护)的示例性修复流声明：

在服务器或接收方设备中可以如下表示针对具有TSI 14和TOI 10的修复分组(该修复分组对针对以下两个源对象的FEC传输对象的级联进行保护：具有TSI 7和TOI 20的源对象以及具有TSI 7和TOI 21的源对象)的示例性修复流声明：

在上面的例子中，具有TSI 14的修复流声明提供静态FDD。此外，FEC 传输对象在FEC超级对象中的顺序排列与修复流声明中作出 ProtectedObject声明的顺序相同。因此，与具有TSI 14和TOI 10的修复分组相对应的FEC超级对象是针对具有TSI 7和TOI 20的源对象的FEC传输对象以及针对具有TSI 7和TOI 21的源对象的FEC传输对象的级联。

概括地说，前述实施例包括可以在广播方和接收方设备中实现的、用于经由广播网络来传送信息的方法，所述方法包括：将相关源对象的集合与源流进行关联；以及在广播网络上发送与源流关联的相关源对象的集合，使得源对象可以由接收方设备基于它们的彼此关系来进行接收和恢复。在一个实施例中，可以确定对源流进行标识的源流标识符(例如，FLID)，并且携带针对与源流相关联的相关源对象中的一个或多个源对象的数据的每个分组可以携带源流标识符。在一个实施例中，分组中所携带的源对象的数据可以由分组中所携带的字节范围来标识。在一个实施例中，可以在传输会话标识符(TSI)字段中携带源流标识符。在一个实施例中，可以在IP 目的地址字段和UDP端口号字段的组合中携带源流标识符。在一个实施例中，可以在码点(CP)字段中携带源流标识符。

在一个实施例中，可以确定源对象标识符的集合，携带源流的相关源对象中的一个相关源对象的数据的每个分组可以携带源对象标识符，并且源流标识符和源对象标识符的组合可以对来自与源流相关联的相关源对象的集合的源对象(分组携带针对该源对象的数据)进行标识。在一个实施例中，源对象标识符可以是传输对象标识符(TOI)。在一个实施例中，源对象标识符可以是对象序列号(OSN)。

在一个实施例中，可以在广播网络上发送相关源对象的一个以上的集合，相关源对象的每个集合可以与不同的源流相关联，对源流中的每个源流进行标识的源流标识符可以是唯一的，并且携带数据的每个分组的源流可以与分组中所携带的源流标识符相关联并且可以由该源流标识符进行标识。

在一个实施例中，可以在分组内的不同字段内携带源流标识符的部分。在一个实施例中，源对象中的至少一些源对象可以包括文件的字节范围，并且源对象中的至少一些源对象可以包括文件的字节范围和HTTP报头。在一个实施例中，URL可以与文件相关联，并且可以利用文件的URL和相应的字节范围来引用源对象。在一个实施例中，源对象中的至少一些源对象可以包括文件，并且URL可以与文件相关联，使得可以利用文件的URL 来引用源对象。

在一个实施例中，源对象中的至少一些源对象可以包括HTTP报头和相关联的文件。在一个实施例中，源对象中的至少一些源对象可以包括 HTTP报头、相关联的文件和HTTP报尾。

另外的实施例包括可以在广播方或接收方设备中实现的、用于经由广播网络来发送信息的方法，所述方法包括：接收整个文件的部分；在接收到整个文件之前，基于接收到的部分来生成源对象；以及在接收到整个文件之前，将所生成的源对象发送给接收方设备。在一个实施例中，在接收到整个文件之前将所生成的源对象发送给接收方设备可以包括：以与文件的数据顺序不同的顺序来发送针对源对象的数据。在一个实施例中，文件可以在文件的开始处包括文件大小，并且可以用以下顺序发送针对源对象的数据：使得跟在文件大小后面的、文件的至少一些数据可以在文件大小之前发送。在一个实施例中，源对象可以包括HTTP报头和相关联的文件。在一个实施例中，源对象可以包括HTTP报头、相关联的文件和HTTP报尾。

在一个实施例中，方法还可以包括：确定针对与源流相关联的源对象的集合的源流元数据，其中源流元数据以信号发送在针对与源流相关联的源对象的集合的位置、名称、可用性时间或其它元数据之间的关系。在一个实施例中，可以使用模板来以信号发送源流元数据中的关系信息中的至少一些关系信息。在一个实施例中，可以在发送与源流相关联的相关源对象中的至少一些相关源对象的时间之前，将针对源流的源流元数据的部分提供给接收方设备。在一个实施例中，提供给接收方设备的源流元数据的部分可以包括定时信息、统一资源标识符(URI)以及对用于源对象的解密密钥进行标识的信息。在一个实施例中，将源流元数据的部分提供给接收方设备可以包括：在发送与源流相关联的源对象中的至少一些源对象之前，将流元数据的部分在带外发送给接收方设备；以及在带内与源对象一起发送源流元数据的其它部分。在一个实施例中，在带内与每个源对象一起发送的源流元数据的部分可以包括对源对象的数据的最后部分的指示。在一个实施例中，将源流元数据的部分提供给接收方设备可以包括：在不发送文件传递表的情况下，经由单向传输协议来发送源流元数据的部分。在一个实施例中，发送相关源对象的集合可以包括：经由多媒体广播多播服务 (MBMS)来发送相关源对象的集合。

在一个实施例中，发送相关源对象的集合可以包括：经由单向传输的文件传递(FLUTE)来发送相关源对象的集合。在一个实施例中，发送相关源对象的集合可以包括：独立于源对象的相应修复对象来发送源对象。在一个实施例中，所述方法还可以包括：使用会话描述协议(SDP)信息来区分源对象与源对象的相应修复对象。在一个实施例中，发送相关源对象的集合可以包括：发送源对象而不发送前向纠错(FEC)信令信息。

在一个实施例中，方法还可以包括：在广播网络上发送针对与源流相关联的相关源对象的集合的FEC修复数据，使得源对象可以由接收方设备基于它们的彼此关系来进行接收和解码，携带针对与源流相关联的相关源对象中的一个或多个相关源对象的FEC修复数据的每个分组可以携带对源流(分组携带针对该源流的FEC修复数据)进行标识的源流标识符，携带针对与源流相关联的相关源对象中的一个或多个相关源对象的FEC修复数据的每个分组可以携带所述一个或多个源对象(可以根据所述一个或多个源对象来生成分组中所携带的FEC修复数据)的所述一个或多个源对象标识符，并且源流标识符和所述一个或多个源对象标识符的组合可以对来自与源流相关联的相关源对象的集合的所述一个或多个源对象(可以根据所述一个或多个源对象来生成分组中所携带的FEC修复数据)进行标识。

在一个实施例中，所述方法还可以包括：在与发送携带针对一个或多个源对象的数据的分组大致相同的时间间隔内发送携带根据所述一个或多个源对象来生成的FEC修复数据的分组。

在一个实施例中，所述方法还可以包括：将修复流与一个或多个源流进行关联；确定针对修复流的修复流标识符；在携带与修复流相关联的FEC 修复数据的每个分组中携带修复流标识符；确定针对修复流的修复对象标识符的集合；以及在携带与修复流相关联的FEC修复数据的每个分组中携带来自修复对象标识符的集合的修复对象标识符，其中，可以至少部分地通过分组中所携带的修复流标识符和修复对象标识符的组合，来确定根据源对象(该源对象来自与修复流相关联的所述一个或多个源流的相关源对象的集合)中的哪个或哪些源对象来生成分组中所携带的FEC修复数据。在一个实施例中，可以在传输会话标识符(TSI)字段中携带修复流标识符。在一个实施例中，可以在IP目的地址字段和UDP端口号字段的组合中携带修复流标识符。在一个实施例中，可以在码点(CP)字段中携带修复流标识符。在一个实施例中，修复对象标识符是传输对象标识符(TOI)。在一个实施例中，修复对象标识符是对象序列号(OSN)。

在一个实施例中，所述方法还可以包括：确定针对修复流的修复流元数据，其中修复流元数据以信号发送在携带FEC修复数据的分组中所携带的修复对象标识符和来自与源流相关联的相关源对象的一个或多个集合的源对象(根据该源对象来生成分组中的FEC修复数据)之间的关系。在一个实施例中，可以使用模板来以信号发送修复流元数据中的关系信息中的至少一些关系信息。在一个实施例中，可以在发送与关联于修复流的源流相关联的相关源对象中的至少一些相关源对象的时间之前，将针对修复流的修复流元数据的部分提供给接收方设备。

在一个实施例中，所述方法可以包括：在与发送携带针对一个或多个源对象的数据的分组大致相同的时间间隔内发送携带根据所述一个或多个源对象而生成的FEC修复数据的分组。在一个实施例中，在具有相同的修复流标识符和相同的修复对象标识符的分组中所携带的FEC修复数据可以根据在不同的源流中的两个源对象来生成，其中，从具有相同的修复流标识符和相同的修复对象标识符的分组以及从两个源对象(根据这两个源对象来生成那些分组中的FEC修复数据)联合接收到的、足以对两个源对象进行解码的数据量可以等于或稍大于两个源对象的聚合大小。在一个实施例中，可以在分组内的不同字段内携带修复流标识符的部分。

图16是适用于与实施例中的任何实施例一起用作接收方设备的移动计算设备的系统框图。典型的移动计算设备1600可以包括处理器1601，处理器1601耦合到内部存储器1602、耦合到显示器1603、并且耦合到扬声器 1604。此外，移动计算设备1600将包括用于发送和接收电磁辐射的天线 1606，其中天线1606可以连接到无线数据链路和/或蜂窝电话收发机1608 (蜂窝电话收发机1608耦合到处理器1601)和移动多媒体广播接收机1610 (移动多媒体广播接收机1610耦合到处理器1601)。移动计算设备1600通常还包括用于接收用户输入的菜单选择按钮1612或提杆开关。

移动计算设备1600还可以包括声音编码/解码(CODEC)电路1614， CODEC电路1614将从麦克风接收到的声音数字化成适用于无线传输的数据分组，并且对接收到的声音数据分组进行解码以生成模拟信号，其中将该模拟信号提供给扬声器1604以生成声音。此外，处理器1601、无线收发机1608和CODEC电路1614中的一项或多项可以包括数字信号处理器 (DSP)电路(未单独示出)。

广播侧的各种实施例可以在各种商业上可得到的服务器设备中的任何一种服务器设备上实现，例如图17中所示出的服务器1700。这种服务器 1700通常包括处理器1701，处理器1701耦合到易失性存储器1702和大容量非易失性存储器(例如，磁盘驱动器1703)。服务器1700还可以包括耦合到处理器1701的软盘驱动器、压缩光盘(CD)或DVD光盘驱动器1704。服务器1700还可以包括耦合到处理器1701的、用于与网络1706(例如，耦合到其它广播系统计算机和服务器的局域网)建立数据连接的网络接入端口1705。

处理器1701可以是任何可编程的微处理器、微计算机或者多处理器芯片(或多个芯片)，其可以由软件指令(应用)配置为执行各种功能，包括上面所描述的各种实施例的功能。在一些移动接收方设备中，可以提供多个处理器，例如专用于无线通信功能的一个处理器和专用于运行其它应用的一个处理器。通常，在访问软件应用并将其加载到处理器1601、1602中之前可以将软件应用存储在内部存储器1702中。处理器1601、1602可以包括足以存储应用软件指令的内部存储器。

各种实施例可以包括在广播网络上传送信息的方法，所述方法可以包括：使用现有的技术、协议和/或结构来传递文件/对象；在分组中传递文件 /对象，其中每个分组包含文件的连续字节范围；在分组中传递文件/对象，其中具有针对字节范围的较大的起始地址的至少一个分组是在具有针对字节范围的较小的地址的分组之前发送的；定义针对LCT/UDP的新的协议句柄，该句柄对适用于传递文件/对象的通信协议进行标识；使用码点来标识不同的对象集合并分配参数；使用会话定义或会话描述消息或组件来支持文件/对象的传递以及该传递的信令；在发送大小字段/报头之前发送文件/ 对象的数据；使用开始传输对象标识符(TOI)或结束TOI或二者来以信号发送受限制列表；使用码点来唯一地标识使用中的静态文件传递信息 (FDI)；使用LCT时间扩展报头来同步服务器和客户端；使用LCT时间扩展报头来进行抖动或延迟测量；定义修复流作为对会话描述和码点的引用并且提供详细的保护特性；定义超级对象，使得该超级对象受FEC保护；使用FEC框架作为ALC实例化以便仅发送修复分组；定义LCT扩展报头，该LCT扩展报头实现发送单独的FEC传输对象的大小；使用现有的字段来以信号发送或支持使用流标识符(FLID)；使用TOI来标识传输对象而无需对信令或协议的其它修改；使用静态FDI来以信号发送流声明；以信号发送由修复流保护的传输源对象，以便避免修复分组报头内的带内信令；以及使用修复流声明内的模板化来以信号发送要由修复流保护的源对象TOI。

各种实施例可以提供相对于现有的广播解决方案的多种增强和益处。实施例提供了基于增强型单向传输的文件传递(FLUTE)的、对相关对象的序列的传递。实施例提供了：用于实现流对象传递的能力；对HTTP动态自适应流式传输(DASH)和其它类似应用、标准或协议的支持；以及用于减小在可以从对象中恢复内容之前要求接收的对象数量的能力。实施例消除了针对流式传输/发送的每个对象对文件传递表(FDT)进行传递的需要。实施例提供了对提前向FLUTE接收机提供信息的支持，这可以在将对象发送给FLUTE接收机或FLUTE接收机接收到对象之前完成。实施例改善了对定时信息、统一资源标识符(URI)和针对流中对象的其它标识信息的传递。实施例支持接收方设备中改善的决策制定和计划。实施例提供了对提供至客户端应用的链接的支持。实施例支持建立并标识在对象和媒体呈现描述(MPD)中所描述的表示的DASH区段之间的关系。实施例支持对内容的组块传递/接收。实施例独立于使用前向纠错(FEC)操作或接收方设备的能力，实现了发送方端到端延迟的减小。实施例实现了当不使用或不要求FEC时接收方端到端延迟的减小。实施例提供了用于等待或暂停操作直到FEC的使用被视为可接受的能力。实施例支持生成、发送和接收可变大小的源分组。实施例支持将源分组边界与底层媒体结构边界(例如，接入单元、网络抽象层单元、样本、文件格式的盒或类似结构体)对齐。实施例支持对没有FEC语义的源内容的传递；从而允许不具有FEC能力的接收方设备接收源内容。一些实施例支持FEC对象绑定；提供对多个对象的FEC保护；其它实施例提供针对单独源对象的部分的FEC保护；其它实施例提供对单独源对象的部分的绑定体的FEC保护。实施例实现了将对象作为完整的HTTP GET响应(例如，RFC 2616中所定义的那些HTTP GET 响应)来传递。实施例提供与当前的广播和FLUTE标准的兼容，并且支持对当前的广播和FLUTE标准的重用。实施例支持在与本文所描述的不使用 FDT来传递相关对象的序列相同的会话中，使用FDT来传递标准的FLUTE 对象。各种实施例还可以包括下面所讨论的多种另外的益处和增强。

由各种实施例提供的对现有的广播解决方案的另外的增强和益处还可以包括：在MPEG媒体传输(MMT)内传输通用文件和资产；使用码点；使用超文本传输协议(HTTP)报头作为对象的一部分；模板化；使用码点和码点中的信令来传递文件的特定于内容的方面；对MMT协议的修改包括适用于经由码点来以信号发送的特征；经由码点的报尾或实体报头来以信号发送对象传输大小；通过单向协议将对象作为HTTP实体报头和HTTP 实体主体的组合来传递，使得对象适用于作为常规地传递的HTTP资源来使用；经由组块传递或顺序传递来传递对象；通过在报尾中添加大小值或其它信息作为对象传递的一部分来指示在传递的开始处未知的、对象的大小或者与对象相关的其它信息；作为码点传输的一部分来以信号发送对象大小；以及经由MPEG媒体传输(MMT)协议来传递对象，使得由MMT 协议报头中的packet_id属性(该属性对对象所属于的流进行标识)和通用文件传递(GFD)协议报头中所携带的传输对象标识符(TOI)属性(该属性对对象流内的特定对象进行标识)来标识与有效载荷相关的对象。

提供前述的方法说明和过程流程图仅作为说明性的例子，并非旨在要求或暗示必须用所给出的次序来执行各个方面的步骤。如本领域技术人员将意识到的，可以用任何次序来执行前述方面中的步骤的次序。诸如“此后”、“然后”、“接下来”之类的词语并非旨在对步骤的次序进行限制；这些词语仅用于引导读者贯穿对方法的描述。此外，以单数形式对权利要求要素的任何引用，例如使用冠词“一”、“一个”或“所述”不应解释为将要素限制为单数。

结合本文公开的各方面所描述的各种说明性的逻辑框、模块、电路和算法步骤可以实现为电子硬件、计算机软件或者二者的组合。为了清楚地示出硬件和软件的这种可互换性，上面已经对各种说明性的组件、框、模块和步骤围绕其功能进行了一般性描述。至于这种功能是实现为硬件还是软件，取决于特定的应用和施加在整体系统上的设计约束。本领域技术人员可以针对每个特定应用以不同的方式来实现所描述的功能，但是这种实现决策不应当解释为致使偏离本发明的范围。

使用被设计为执行本文所描述的功能的通用处理器、数字信号处理器 (DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其它可编程逻辑器件、分立门或晶体管逻辑器件、分立硬件组件或者其任意组合，可以实现或执行用于实现结合本文公开的各方面所描述的各种说明性的逻辑单元、逻辑框、模块和电路的硬件。通用处理器可以是多处理器，但在替代方案中，该处理器也可以是任何常规的处理器、控制器、微控制器或状态机。处理器还可以实现为计算设备的组合，例如，DSP和多处理器的组合、多个多处理器、一个或多个多处理器与DSP内核的结合，或者任何其它此种配置。替代地，可以由特定于给定功能的电路来执行一些步骤或方法。

在一个或多个示例性方面中，所描述的功能可以在硬件、软件、固件或其任意组合中实现。如果在软件中实现，则所述功能可以作为一条或多条指令或代码存储在非暂时性计算机可读存储介质、非暂时性计算机可读介质或者非暂时性处理器可读介质上。本文所公开的方法或算法的步骤可以体现在处理器可执行软件模块中，该处理器可执行软件模块可以驻留在非暂时性计算机可读或处理器可读存储介质上。非暂时性计算机可读或处理器可读存储介质可以是可以由计算机或处理器存取的任何存储介质。通过举例而非限制性的方式，这种非暂时性计算机可读或处理器可读介质可以包括RAM、ROM、EEPROM、FLASH存储器、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备，或者可用于存储具有指令或数据结构形式的期望的程序代码并且可以由计算机存取的任何其它介质。如本文所使用的，磁盘(disk)和光盘(disc)包括压缩光盘(CD)、激光光盘、光盘、数字多功能光盘(DVD)、软盘和蓝光光盘，其中磁盘通常磁性地复制数据，而光盘利用激光来光学地复制数据。

上面各项的组合也包括在非暂时性计算机可读和处理器可读介质的范围内。此外，方法或算法的操作可以作为代码和/或指令的一个或任意组合或集合驻留在可以并入计算机程序产品中的非暂时性处理器可读介质和/或计算机可读介质上。

提供对所公开的实施例的以上描述是为了使得任何本领域技术人员能够实施或使用本发明。对这些实施例的各种修改对于本领域技术人员来说将是显而易见的，并且在不脱离本发明的精神或范围的情况下，本文所定义的总体原理可以应用于其它实施例。因此，本发明并非旨在受限于本文所示出的实施例，而是旨在符合与上面的权利要求以及本文所公开的原理和新颖性特征相一致的最广的范围。