CN110915180A - 低时延媒体摄取系统、设备和方法 - Google Patents

Abstract

一种媒体分发系统和方法，其中媒体流传输网络包括媒体摄取网络部分，媒体摄取网络部分被配置为使用HTTP分块传输编码(CTE)来提供分段实况媒体流的媒体片段的低时延上传。在一个实施例中，分段的一个或多个片段在该分段的整个媒体数据变得可用之前被逐块地上传或以其他方式摄取。耦合到媒体摄取网络部分的IP多播分发网络部分可操作以使用IP多播协议将分块媒体数据分发给一个或多个IP多播接收者。客户端应用可操作以在与服务IP多播接收者的HTTP CTE传递会话中下载媒体数据。

Description

低时延媒体摄取系统、设备和方法

技术领域

本公开总体上涉及通信网络。更具体地并且不以任何方式加以限制地，本公开涉及使用一个或多个固定网络、无线网络和/或其任何组合上的可靠多播来促进低时延媒体摄取和分发的网络架构、系统、设备和方法。

背景技术

由于固定网络和移动网络所提供的数据速率不断增大，多媒体流传输服务也分布得越来越广泛。鉴于市场上智能手机的数量日益增多，移动视频消费也出现了爆发式的增长。为了实现视频流传输，广泛采用了用于会话建立及控制的实时流传输协议(RTSP)和会话描述协议(SDP)以及用于实时语音、音频和视频传输的实时传输协议(RTP)。为了应对传输路径上波动的比特率，还采用了自适应RTP流传输技术。不过，众所周知的是，RTSP/RTP流传输在包括防火墙和网络地址转换(NAT)穿越的网络环境中存在着若干不足之处。

为了应对消费者在受控网络环境及非受控网络环境中将内容(例如，广播和点播电影/电视等)穿过各种网络基础设施流传输给性能及协议都有较大差异的用户站这一不断增长的需求，实现了基于超文本传输协议(HTTP)的自适应流传输技术。在固定网络架构和移动网络架构中都在执行IP(互联网协议)多播，以除了能达到关键性能指标(KPI)之外，还能充分利用规模经济并解决带宽、内容保护、可扩展性和可达性等问题。尽管媒体传递技术取得了持续性的迅猛发展，但仍存在一些具有挑战性的问题，尤其是关于实况媒体传递。

发明内容

对于自适应实况媒体流，最好能缩短总的端到端延迟，这样，最终消费者所观看到的媒体在时间上尽可能地接近现实情况。延迟可能是由若干因素引起的，所有这些因素都可对媒体流传输网络中的总的端到端延迟造成影响。例如，就实况事件而言，存在着与媒体捕获、编码和处理有关的延迟成分。在以自适应比特率(ABR)流传输架构实现媒体分段的情况下，当分段在被完全处理之前对服务器节点不可用时，可能会出现加载延迟。

本专利公开总体上涉及用于促进媒体流传输网络中的媒体分发的系统、方法、装置以及网络节点和相关联的非暂时性计算机可读介质，其中该媒体流传输网络包括媒体摄取网络部分，该媒体摄取网络部分被配置为使用HTTP分块传输编码(CTE)提供分段实况媒体流的媒体片段的低时延上传。在示例实施例中，在分段的整个媒体数据变得可用之前，逐块地上传或以其他方式提供该分段的一个或多个片段，例如包括但不限于：触发推送、拉取和/或混合数据传输机制。耦合到媒体摄取网络部分的IP多播分发网络部分可操作以使用IP多播协议将分块媒体数据分发给一个或多个IP多播接收者。在一个实施例中，客户端应用可操作以在与服务IP多播接收者的HTTP CTE传递会话中下载媒体数据。在另一实施例中，客户端应用可以与IP多播接收器功能集成在一起，其中作为HTTP CTE的代替，可以使用合适的API调用来获取媒体数据。

一方面，公开了一种低时延媒体摄取方法，例如包括拉取、推送等。该方法尤其包括：由媒体打包器节点从进入的媒体流生成分段媒体流，其中每个分段包括多个片段，每个片段包括媒体数据的一个或多个帧，例如，音频帧、视频帧或其组合。分段流被识别为使用IP多播来分发，并且与具体IP多播组相关联。可选地，可以识别具体IP多播协议(例如，NORM、FLUTE、FCAST等)。在媒体打包器节点与起始服务器节点之间发起HTTP CTE会话。这可以由媒体打包器节点例如在推送场景中完成，由起始服务器例如在拉取场景中完成，或者由另一控制节点完成。起始服务器可以例如与内容分发网络(CDN)相关联，或者可以是移动电信网络的广播多播服务中心(BMSC)节点。针对分段流的每个分段N，执行以下动作：经由HTTP CTE会话，在分段N的整个媒体数据可用之前逐块地开始将分段N的片段摄取到起始服务器节点，其中一个或多个块被提供来传输每个片段；以及在已经传输了分段N的所有片段之后，将最后块信号发送给起始服务器节点。在一些实施例中，分段器可以被配置为仅在接收到HTTP GET请求之后才上传片段。在其他实施例中，分段器可以根据分段可用性时间来上传片段。在又一变型中，媒体摄取方法可以包括：在开始片段的上传之前，向起始服务器节点发送指示，以指示提供来打包和传输每个片段的块的数量。

在另一方面，公开了一种媒体打包器装置，该装置包括至少一个网络接口，该网络接口被配置为从一个或多个内容源接收实况媒体流。媒体打包器装置被配置为：将接收到的实况媒体流分成多个分段，其中每个分段包括多个片段，每个片段包括媒体数据的一个或多个帧；识别出将使用IP多播来分发分段流，并将分段流与具体的IP多播组相关联；并且发起与起始服务器节点的HTTP分块传输编码(CTE)会话。媒体打包器装置还被配置为：在分段N的整个媒体数据可用之前，经由CTE会话开始将分段N的片段摄取到起始服务器节点，其中一个或多个块被提供来传输每个片段；以及在已经传输了分段N的所有片段之后，将最后块信号发送给起始服务器节点。媒体打包器装置可以包括：编码器，用于针对每个实况媒体流生成多个比特率表示；和/或分段器，被配置为将具体实况媒体流的每个比特率表示分成多个分段。媒体打包器装置还可以包括一个或多个处理器和其上存储有程序指令的一个或多个持久性存储器模块，这些程序指令在由该一个或多个处理器执行时执行上述步骤。

在另一方面，公开了一种适于低时延片段的传输的媒体分发方法。该方法尤其包括：在起始服务器节点处从媒体打包器节点接收消息，以开始与媒体打包器节点的HTTPCTE会话，其中该消息包括实况媒体流的媒体数据将被摄取到起始服务器节点的指示。针对媒体流的每个分段N，从媒体打包器节点接收一个或多个HTTP首部。此后，经由HTTP CTE会话逐块地接收分段的一个或多个片段，每个块具有块边界标记，其中每个片段包含媒体数据的一个或多个帧，并且是在分段的整个媒体数据在媒体打包器节点处可用之前就接收的。块边界标记可以例如通过在HTTP块的开始处提供的块大小指示来实现。针对每个块生成传输对象(具体是IP多播传输对象)，这可能取决于所采用的(IP多播)协议。将可能包含完整片段或部分片段的传输对象传输给多个接收器，例如，CDN边缘节点(具体是家庭网关)和/或用户终端。根据实现方式，可以例如在分段的所有片段都已上传之后，提供显式的或固有的信令来指示从媒体打包器节点传输/接收了最后的块。在其他变型中，响应于最后块信号，可以将所有块的大小累加以生成与分段相关联的对象大小指示，并将其发信号通知给多个边缘多播接收器。

在另一方面，公开了一种起始服务器，该起始服务器包括HTTP分块传输编码(CTE)服务器和/或客户端以及IP多播发送器。起始服务器被配置为：从媒体打包器节点接收消息，以开始与媒体打包器节点的HTTP CTE会话，该消息包括对以分块传递方式来提供分段实况媒体流的媒体数据的指示；以及针对实况媒体流的每个分段N，经由HTTP CTE会话逐块地从媒体打包器节点接收一个或多个HTTP首部并接收分段的一个或多个片段，每个块具有块边界标记，其中每个片段包含媒体数据的一个或多个帧，并且是在分段的整个媒体数据在媒体打包器节点处可用之前就接收的。起始服务器还被配置为：为接收到的块生成传输对象(具体是IP多播传输对象)并将传输对象传输给多个接收器，并且在已经摄取分段的所有片段之后，从媒体打包器节点接收最后块信号。

在以上方面中，起始服务器可以例如与内容分发网络(CDN)相关联，或者可以是移动电信网络的广播多播服务中心(BMSC)节点。此外，在这种背景下，摄取可以是指例如媒体打包器节点向起始服务器节点上传，例如起始服务器节点从媒体打包器节点下载，或者从媒体打包器节点向起始服务器节点的其他方式的传输。在示例性实施例中，可以通过发送零字节大小的HTTP块来实现最后块信号。这表明，HTTP主体部分的传输已完成。

在另一方面，公开了基于对低时延片段的接收的媒体传递方法。该方法尤其包括：在IP多播接收器处，从IP多播发送器接收与实况媒体流的媒体数据的分发有关的IP多播信息消息。在一种布置中，IP多播信息消息可以包括包含位置信息、MIME类型和其他元数据的HTTP首部。从IP多播发送器接收包括媒体数据分组在内的协议特定的IP多播传输对象。基于有效载荷ID信息(例如，FEC有效载荷ID)，对分组进行排序并且可以将其打包成分段、片段和/或特别是块。其中，每个分段、片段和/或块包括媒体数据的一个或多个帧。响应于从客户端设备接收到对实况媒体流的信道请求，生成一个或多个HTTP首部，并经由HTTP分块传输编码(CTE)会话逐块地将块提供给客户端设备。客户端设备可以在其中使用HTTP首部，以针对每个片段逐块地经由HTTP CTE会话从IP多播发送器下载分段、片段或块数据。

在本方法中，IP多播发送器可以是如上所述的起始服务器，即例如与内容分发网络(CDN)相关联的边缘服务器，或者移动电信网络的广播多播服务中心(BMSC)节点。

在后一种情况下，当IP多播发送器是BMSC节点时，媒体传递方法的实施例可以是在服务于多个无线用户设备(UE)设备(各自包括广播客户端)的移动电信网络中操作的媒体广播方法。该方法尤其包括：在移动电信网络的广播多播服务中心(BMSC)节点处，经由与媒体打包器节点的HTTP CTE会话逐块地接收分段媒体流的每个分段的一个或多个片段，其中每个片段是在分段的整个数据在媒体打包器节点处可用之前就接收的。可以关于媒体数据来创建FLUTE对象。在一种情况下，可以针对每个HTTP块创建FLUTE传输对象。在另一种情况下，可以收集片段的多个HTTP块并将其作为单个FLUTE传输对象进行传输。一个或多个FLUTE对象可以在广播会话中传输给多个无线UE设备，其中FLUTE对象通过文件传递表(FDT)实例与分段的元数据和块元数据相关联。在已经接收到分段的所有片段(在某些布置和/或某些技术文献中也被称为“块”)之后，可以在FDT实例中向该多个无线UE设备提供最后块信号指示。在一种实现方式中，扩展FDT实例来包括Chunk-Length参数，以标识分段的媒体数据是以分块传递方式提供的，该参数也可以被配置为指示FLUTE对象的大小(例如，以字节为单位)。在其他变型中，可以将FDT实例扩展为包括Chunk-Offset参数，以指示例如与基本定位符的相对位置。每个块可以作为具有唯一的传输对象ID(TOI)的FLUTE传输对象来携带。当发送器收集了片段的所有块时，则每个片段都可以作为FLUTE传输对象来携带。从逻辑上而言，在一种布置中，发射机可操作以通过将片段的所有块组合成更大的新块来创建出新的块。Chunk-Offset可以被配置为标识数据在总体分段中的相对位置。Chunk-Offset和Chunk-Size在某些实施例中可以有助于检测在流动中丢失的块。在又一方面，公开了一种与IP多播分发网络相关联的端点节点，该端点节点包括IP多播接收器。端点节点被配置为从IP多播发送器接收与实况媒体流的媒体数据的分发有关的IP多播信息消息，并从IP多播发送器接收IP多播传输对象，该IP多播传输对象包括媒体数据分组。端点节点还被配置为：基于顺序有效载荷ID信息对媒体数据分组进行排序，基于排序后的分组来生成媒体数据的块，并且响应于从客户端接收到对实况媒体流的信道请求，将块提供给客户端设备。为了执行这些功能，可以预见到一个或多个处理器，这些处理器可操作以执行可以存储在存储器(特别是持久性非易失性存储器)中的程序指令。

在端点节点的一个实施例中，IP多播接收器可以与无线UE设备集成，特别是与可操作以在LTE网络中接收广播/多播媒体的UE集成。UE设备尤其包括HTTP CTE编码服务器或代理以及演进多媒体广播/多播服务(eMBMS)客户端，该eMBMS客户端可以包括IP多播客户端(对应接收器)和HTTP CTE接收器。UE设备被配置为：在IP多播接收器处从与BMSC节点相关联的IP多播发送器接收与分段媒体流的媒体数据的分发有关的IP多播信息消息；在IP多播接收器处接收多个FLUTE对象(例如，每个HTTP块一个FLUTE对象，或片段的所有块一个FLUTE对象，如前所述)，每个FLUTE对象包含分段媒体流中的分段的片段的媒体数据分组；以及基于排序后的分组来创建媒体数据的块。可选地，可以将来自多个FLUTE对象的块组合起来形成媒体数据的分段。响应于从HTTP CTE接收器接收到分段请求，可以生成一个或多个HTTP首部，针对每个分段，CTE接收器可以利用这些HTTP首部来经由HTTP CTE会话逐块地从HTTP CTE服务器下载分段。所接收的块数据可以提供给媒体播放器缓冲区，以在无线UE设备的显示器处呈现。

在又一方面，提供了一种媒体流传输网络，该媒体流传输网络包括：媒体摄取网络部分，该媒体摄取网络部分被配置为使用HTTP分块传输编码(CTE)来提供分段实况媒体流的媒体片段的低时延上传，其中分段的一个或多个片段在分段的整个媒体数据变得可用之前被逐块地摄取；耦合到媒体摄取网络部分的互联网协议(IP)多播分发网络部分，该IP多播分发网络部分被配置为使用IP多播协议将分块媒体数据分发给一个或多个IP多播接收者；以及传递网络部分，该传递网络部分被配置为在与服务IP多播接收者的HTTP CTE下载会话中将媒体数据传递给客户端。媒体流传输网络可以包括如上所述的媒体打包器、起始服务器和/或端点节点。

本发明的益处包括但不限于提供一种网络架构以及相关联的系统和方法，其中即使在将可靠的IP多播协议用于媒体分发的情况下，也可以显著地缩短CDN或移动广播网络内部的传输延迟。因此，可以有利地充分利用IP多播的益处，而不会对有线环境以及无线环境中的用户质量体验产生不利影响。此外，在公共安全网络领域，以低时延在LTE广播部署中引入DASH/ISOBMFF输送(carriage)也是有利的。根据以下描述和附图，实施例的其他益处和优点将是显而易见的。

在其他方面，公开了一种其上存储有计算机可执行程序指令或代码部分的非暂时性计算机可读介质或分布式介质的一个或多个实施例，所述计算机可执行程序指令或代码部分用于在由网络节点、元素、虚拟器件、UE设备等的处理器实体执行时执行本发明的方法的一个或多个实施例。各个实施例的其他特征如从属权利要求中所述和所定义。

附图说明

在附图部分的附图中通过示例而非限制性的方式示出了本公开的实施例，在附图中，相同的附图标记指代相似的元素。应注意，在本公开中对“实施例”或“一个实施例”的不同引用不一定涉及同一实施例，并且这样的引用可以表示至少一个。此外，当结合实施例来描述具体的特征、结构或特性时，可以认为，不管是否进行了明确描述，与其他实施例相结合地实现这种特征、结构或特性是在熟练技术人员的认知范围内。

附图包含在说明书中并形成说明书的一部分，以示出本公开的一个或多个示例性实施例。根据以下具体实施方式，结合所附权利要求并参照附图，将会理解本公开的各种优点和特征，其中：

图1描绘了根据本文教导的通用示例网络架构，其中可以实践本发明的一个或多个实施例来促进低时延媒体摄取和分发；

图2描绘了图1的示例网络架构的其他方面，该其他方面示出了实现方式中的其他细节；

图3A描绘了用于实践本发明的实施例的示例高层级多播网络；

图3B是可以被改进、组合或布置成一个或多个实施例的步骤、方框或动作的流程图和/或用于促进图3A所示的示例高层级多播网络中的低时延媒体摄取和分发的附加流程图；

图4A至图4C描绘了根据示例实施例的消息流程图，该消息流程图描绘了在基于CDN的实现方式中的媒体摄取和分发；

图5至图7描绘了出于本发明实施例的目的而配置用于媒体广播的移动电信网络架构的各个方面；

图8描绘了出于本发明实施例的目的的示例移动电信网络中的会话调度序列；

图9描绘了根据示例实施例的消息流程图，该消息流程图描绘了在基于移动广播的实现方式中的媒体摄取和分发；

图10A至图10C是根据本专利申请的教导的各种步骤、方框或动作的流程图，该各种步骤、方框或动作可以组合或布置成用于促进示例流传输网络中的低时延媒体摄取和分发的一个或多个实施例；

图11A和图11B是根据本专利申请的教导的各种步骤、方框或动作的流程图，该各种步骤、方框或动作可以组合或布置成用于促进低时延媒体摄取和分发系统和方法的其他方面的一个或多个实施例；

图12是根据本专利申请的教导的各种步骤、方框或动作的流程图，该各种步骤、方框或动作可以组合或布置成用于促进低时延媒体摄取和分发系统和方法的其他方面的一个或多个实施例；

图13是根据本专利申请的教导的各种步骤、方框或动作的流程图，该各种步骤、方框或动作可以组合或布置成用于促进低时延媒体摄取和分发系统和方法的其他方面的一个或多个实施例；

图14描绘了装置的框图，出于本专利申请的一个或多个实施例的目的，该装置可以配置成或布置成可操作以在多播流传输网络的一个或多个阶段部署的不同的网元或节点；以及

图15描绘了装置的框图，出于本专利申请的一个或多个实施例的目的，该装置可以配置成或布置成驻地设备或用户设备(UE)设备。

具体实施方式

在本文对本发明实施例的描述中，提供了许多具体细节(比如，组件和/或方法的示例)，从而实现对本发明实施例的透彻理解。然而，相关领域的技术人员将认识到的是，可以在没有一个或多个该具体细节的情况下，或者在具有其他装置、系统、套件、方法、组件、材料、零件和/或类似物的情况下实践本发明的实施例。在其他情形下，为了避免使本发明实施例的各方面变得不清晰，未具体示出或详细描述公知的结构、材料或操作。因此，熟练技术人员将理解，可以在没有这样的具体组件的情况下实践本公开的实施例。还应该认识到的是，借助本文阐述的具体实施方式部分并参考附图，本领域的普通技术人员将能够在不进行过度实验的情况下制造并应有一个或多个实施例。

另外，诸如“耦合”和“连接”之类的术语及其派生词可以在以下描述、权利要求书或这两者中使用。应当理解，这些术语不必一定是彼此的同义词。“耦合”可以用于指示彼此之间可以直接或可以不直接物理或电性接触、合作或相互作用的两个或多个元素。“连接”可以用于指示在彼此耦合的两个或多个元素之间建立通信，即通信关系。此外，在本文阐述的一个或多个示例实施例中，一般而言，如果可以对元素、组件或模块进行编程以执行功能或以其他方式在结构上布置为执行功能，则该元素、组件或模块可以被配置为执行该功能。

如本文所用，网元、节点或子系统可以由一个或多个服务网络设备组成，所述服务网络设备包括硬件和软件，该硬件和软件与网络上的其他设备(例如，其他网元、终端站、IP-STB、传统STB等)通信地互连，并且适于在虚拟或非虚拟环境中相对于多个订户和相关联的用户设备托管一个或多个应用或服务，所述订户和相关联的用户设备可操作以接收/消费媒体流传输网络中的内容，在媒体流传输网络中可以使用HTTP分块传递和/或IP多播传输机制来上传、分发和传递媒体内容资产。这样，一些网元可以部署在无线电网络环境中，而其他网元可以部署在公共分组交换网络基础设施中，包括或以其他方式涉及合适的内容分发/传递网络(CDN)基础设施和/或内容源网络(CSN)基础设施。此外，本文阐述的一个或多个实施例可以涉及固定运营商网络和/或移动运营商网络(例如，地面和/或卫星宽带传送基础设施)，其可以体现为数字用户线(DSL)网络架构、符合电缆数据服务接口规范(DOCSIS)的电缆调制解调器终端系统(CMTS)架构、IPTV架构、数字视频广播(DVB)架构、交换数字视频(SDV)网络架构、混合同轴光纤(HFC)网络架构、基于蜂窝和/或WiFi连接性的合适的卫星接入网架构或宽带无线接入网架构。因此，一些网元可以包括“多个服务网元”，这些服务网元除了为多个应用服务(例如，数据和多媒体应用)提供支持之外，还为多个基于网络的功能提供支持(例如，A/V媒体传递策略管理、会话控制、QoS策略实施、带宽调度管理、内容提供商优先级策略管理、流传输策略管理等)。示例性的订户终端站或客户端设备可以包括各种具备流传输能力的设备，这些设备可以使用流传输和/或基于文件的下载技术来消费或传递媒体内容资产，在某些实施例中，这些技术可能涉及某种类型的速率适配。因此，说明性的客户端设备或用户设备(UE)可以包括被配置为尤其执行一个或多个流传输客户端应用的任何设备，其中所述流传输客户端应用用于根据一种或多种基于文件的ABR流传输技术(比如，

平滑流传输、HTTP流传输(例如，基于HTTP的动态自适应流传输或称为DASH、HTTP实况流传输或称为HLS、HTTP动态流传输或称为HDS等)、Icecast等，以及实时传输协议(RTP)网络上的基于MPEG传输流(TS)的流传输)，例如经由宽带接入网从一个或多个内容提供商接收、记录、存储和/或呈现内容、实况媒体和/或静态/点播媒体。因此，这种客户端设备可以包括传统机顶盒(STB)、基于下一代IP的STB、联网电视、个人/数码录像机(PVR/DVR)、联网式媒体投影仪、便携式笔记本电脑、上网本、掌上电脑、平板电脑、智能手机、多媒体/视频电话、移动/无线用户设备、便携式媒体播放器、便携式游戏系统或控制台(如

Plav

等)等，根据本文阐述的一个或多个实施例，它们可以访问或消费经由IP多播分发网络提供的内容/服务。

可以使用软件、固件和/或硬件的不同组合来实现本专利公开的一个或多个实施例。因此，可以使用在一个或多个电子设备或节点(例如，订户客户端设备或终端站、网元等)上存储和执行的代码和数据来实现附图(例如，流程图)中所示的一种或多种技术。这样的电子设备可以使用计算机可读介质来存储和(在内部和/或与网络上的其他电子设备)传送代码和数据，所述计算机可读介质诸如非暂时性计算机可读存储介质(例如，磁盘、光盘、随机存取存储器、只读存储器、闪存设备、相变存储器等)、暂时性计算机可读传输介质(例如，电学、光学、声学或其他形式的传播信号，如载波、红外信号、数字信号)等。此外，这样的网元通常可以包括耦合到一个或多个其他组件(比如，一个或多个存储设备(例如，非暂时性机器可读存储介质))的一个或多个处理器的集合，以及存储数据库、用户输入/输出设备(例如，键盘、触摸屏、指向设备和/或显示器)和用于实现信令和/或承载媒体传输的网络连接。处理器的集合与其他组件的耦合通常可以通过一个或多个总线和桥(也被称为总线控制器)，该一个或多个总线和桥是以任何已知(例如，对称/共享的多处理)或迄今未知的架构来布置的。因此，给定电子设备或网元的存储设备或组件可以被配置为存储代码和/或数据，以便在该元素、节点或电子设备的一个或多个处理器上执行，达成实现本公开的一种或多种技术的目的。

现在参考附图并且具体参考图1，图1描绘了根据本专利申请的一个或多个实施例的用于促进低时延媒体摄取和分发/传递的通用示例性网络架构100。在下文中可以看出，可以使用多播技术或单播技术来分发和/或传递内容。在单播机制下，可以为订阅接收器提供一条直接且唯一的双向路径，该路径穿过传递网络一直返回到供应所需数据流的服务媒体服务器。在通信会话中，在接收器与源服务器之间以一对一的方式来管理主要的流传输活动。源服务器与接收器之间的网络通常可以包括安装在网络节点处的一系列中间服务器，这些中间服务器可能不会直接参与服务，而是仅支持分组流的传输。通常情况下，用于支持传输的协议是互联网协议(IP)自身的简易形式，这种形式通过一个或多个更高层的协议来增强，以提供流动控制。这些协议在源服务器与给定接收器之间的网络连接范围上进行扩展。

单播系统可以支持允许某种形式的速率适配的ABR(自适应比特率)流传输。可以按照对不同比特率(称为表示，如本文中其他地方所述)的选择来对给定服务进行编码，同步边界点位于限定的位置处(例如，每50帧)。对于每种表示，连续边界点之间的内容将被转换为离散文件。客户依次获取其中一种表示的分段。如果需要更高或更低的比特率，则从一个其他表示中获取下一个分段。分段被构造成使得如果客户端在边界点处切换表示，则解码后的图片/音频中不存在不连续性。该系统可能需要源与接收器之间的单播双向路径来请求文件并传递所请求的文件。

多播分发/传递通过在若干接收器之间共享内容流来更有效地利用带宽。目前，中间网元(例如，路由器或交换机)更紧密地参与到服务传递中，使得从源服务器委托了一些控制和管理功能。这种控制受到了为这类应用所设计的更广泛协议的支持，协议例如是协议独立多播(PIM)、互联网组多播协议(IGMP)、基于UDP的RTP/MPEG-TS以及基于流的多播的IP多播、面向NACK的可靠多播(NORM)、单向传输文件传递(FLUTE)、FCAST等。当接收器请求给定的媒体项目或资产时，网络路由器系统会找到网络中已经存在的该内容的现有流并将其副本从服务电缆前端、视频总部或边缘分发网络中适当的近端网络节点导向到接收器。也就是说，多播可以从前端打包器或国家起始服务器(例如，在国家数据中心处)一直通往部署在合适的接入网中或驻地网络节点处的服务边缘传递节点，再到具有适当的IP多播客户端功能的最终用户站。可以向发出请求的接收器提供在不对现有接收器造成不利影响的受控条件下加入此现有流的能力。也可以向该组中的任何接收器提供在不影响其他接收器的情况下离开流或者暂停其消费的能力。

熟练技术人员将认识到，虽然“分发”通常可以用来描述向边缘服务器的供应核心网内的媒体，但是，媒体的“传递”是发生在边缘服务器与客户端之间，尽管这些术语在本申请的一个或多个实施例的上下文中在某种程度上可以互换地使用。通常，参照本专利公开的至少一些实施例所使用的术语“媒体内容”、“数字资产”、“内容文件”、“媒体分段”或类似含义的术语(或简称为“内容”)可以包括数字资产或节目资产，比如，任何类型的音频/视频(A/V)内容，所述A/V内容可以包括实时捕获媒体或静态/存储的点播媒体，例如，无线免费网络电视(TV)表演或节目、通过有线网络或卫星网络的付费电视广播节目、免费卫星电视表演、IPTV节目、过顶(Over-The-Top，OTT)和视频点播(VOD)或电影点播(MOD)表演或节目、时移电视(TSTV)内容、追看服务内容、虚拟现实(VR)内容、增强现实(AR)内容、ABR内容等。作为说明，在网络架构110中示出了一个或多个实况内容源108、一个或多个TSTV内容源110、一个或多个静态/点播内容源112(例如，VOD服务和云/网络DVR内容源)以及追看TV服务114，以用作与将媒体流传输给大量UE设备190-1至190-N有关的通用内容源，其中的至少一些UE设备可以部署在订户驻地内并由诸如网关、STB、调制解调器等(未明确示出)合适的驻地设备提供服务。来自内容源的媒体内容资产可以由合适的媒体准备设施106结合打包116进行处理、编码/转码和/或准备，以便在IP多播分发网络118上传输，其中打包116耦合到内容源网络104或以其他方式与其相关联。此外，在某些实施例中，在将打包后的媒体上传给IP多播网络118之前，关于内容媒体流，适当的数字版权管理(DRM)、加密及数字水印(DWM)功能也可以被配置为与打包116相关联地操作。可以在UE/驻地节点与相应的分发网络基础设施中的上游网元之间对由附图标记124以渐增方式表示的各种类型的边缘网络和接入网(固定的或移动的)进行接口式连接，从而有助于通过有线和/或无线技术的媒体传递，如前所述。

与(例如，在全局前端处的)内容源网络104相关联的示例媒体处理系统可以被配置为接受来自实况源和/或静态文件源(例如，在线内容提供商，如

或

Prime，以及VOD目录或内容提供商或工作室，例如Disney、Warner、Sony等)的媒体内容。来自实况源的媒体内容可以包括关于任何类型事件而捕获的实况节目，例如，体育/娱乐/游戏活动、音乐会、电视直播节目、新闻直播广播源，例如，国家广播公司(例如，NBC、ABC等)以及有线电视广播公司频道(如CNN、ESPN、CNBC等的时代华纳频道)，另外还有本地和/或地区性的广播公司、公共安全网络等。在一般操作中，可以在执行适当程序代码(其存储在持久性存储器模块中)的一个或多个处理器的控制下，将示例媒体准备系统106配置为实现如下的媒体准备。最初，使用适用的编码器对源媒体内容以不同的比特率进行转码或编码(例如，多速率转码)。举例来说，可以使用可变比特率(或者同义词“位率”或“分辨率”)将具体媒体内容资产或节目的内容转码成五个视频流，范围涵盖低比特率到高比特率(举例说明，500Kbps到10Mbps)。因此，具体内容被编码为五个不同的“版本”，其中每个比特率称为配置文件或表示。分段服务器或分段器用作打包器116，用于将每个版本的编码媒体内容划分为固定持续时间分段，这些持续时间分段的持续时间通常在两秒到十秒之间，从而能根据实现方式生成多个分段流和/或虚拟分段流。熟练技术人员将认识到，较短的分段可能会降低编码效率，而较大的分段可能会影响对网络吞吐量变化和/或快速变化的客户端行为的适应性。不管大小如何，分段在实施例中都可以是对齐于图片组(GOP)的，这样使得所有编码配置文件都具有相同的分段。此外，打包器116包括被配置为针对每个媒体分段生成一个或多个片段的媒体分段器，或者与该媒体分段器相关联地操作，该一个或多个片段可以使用HTTP分块传输编码(CTE)上传到IP多播网络118中的适当网络节点，实现低时延，这将在下文中更详细地加以阐述。

图2描绘了图1的示例性网络架构100的其他方面，该其他方面示出了端到端实现方式中的其他细节，这种端到端实现方式涉及与一个或多个内容服务/提供商网络相结合地使用固定运营商网络和/或移动运营商网络进行实况媒体分发和传递。通过说明的方式，在网络架构200中例示了内容提供商网络部分220、固定运营商网络部分235和移动运营商网络部分230。熟练技术人员将认识到的是，示例性实现方式200可以分层地组织，其中国家数据中心(NDC)的前端或超级前端设施被配置为将媒体编码并准备为分段和子分段(即片段)，并将片段提供给集中式服务器，以便使用IP多播经由一个或多个等级的中间网络基础设施(例如，作为以下各项的一部分：受控网络基础设施或其一部分、移动/固定网络部分或CDN)分发给终端/边缘接收器。具有适当的客户端应用的各种用户终端站可操作以根据实现IP多播接收器功能的位置，经由一个或多个移动/固定接入网和家庭/驻地网络，使用基于HTTP CTE的传递从IP多播终端/边缘接收器下载或拉取媒体分段。如图所示，多个卫星或光纤馈送208将与一个或多个信道206相对应的源媒体内容提供给适当的编码器210，在一种实现方式中，编码器210根据ISO/IEC 13818-1以标准容器格式(例如，MPEG2-TS或M2TS)将媒体数据编码/压缩为高质量比特率流205(例如，多播流)或直接内存操作。在附加或替代布置中，打包器和编码器还可以从本地文件系统中读取内容，而不是从卫星或光纤馈送中读取内容。尽管在图2中未示出，但是在示例性实施例中可以提供一个或多个国家剪接器，用于将任何辅助媒体内容(例如，广告)插入到媒体流中，以便前端编码器/转码器/打包器模块202进行处理，在某些布置中，前端编码器/转码器/打包器模块202可以作为媒体服务器或系统的一部分分布在多个元素或组件中，并且可以与附加节点或元素(比如，广告服务器(ADS)等)相关联。优选地，前端节点202的转码器组件可以被配置为关于多播的每个媒体内容信道生成多个自适应TS流(ATS)以及相关联的流清单，其中ATS流包括信道的媒体内容资产的具体比特率表示，包括编码边界点(EBP)或虚拟分段信息、辅助内容信令(例如，SCTE 35信令)等。

在一种示例性实现方式中，图1的IP多播网络118的至少一部分可以包括内容提供商网络220，其可以被构造为图2中例示的覆盖CDN。作为CDN，网络220可以包括一组多等级的分层组织的互连网络服务器，用于提供从一个或多个中央分发节点(国家起始服务器)到一个或多个等级的区域分发节点的媒体路径或“管道”，这些区域分发节点连接到一个或多个本地边缘服务器，本地边缘服务器被配置为经由合适的接入网基础设施为相应服务位置区域中的多个最终用户或订户提供服务。应当理解的是，区域分发节点可以充当一个或多个子边缘/起始服务器的父节点，而中央或国家分发节点继而可以充当一个或多个子区域分发节点的父节点，以支持IP多播分发树。此外，熟练技术人员将理解，被配置为支持IP多播的CDN架构可以被实现为公共CDN、私有CDN、或混合CDN、或网络的网络(其可以包括基于云的基础设施或数据中心)。通过说明的方式，国家起始节点214和节点216-1至216-N被例示为CDN 220的一部分，其中的任何边缘节点都可以经由合适的边界网关(BGW 241)与固定网络基础设施235进行接口式连接，该边界网关耦合到MCTx 243(多播发射机功能，其作为到固定网络中的摄取功能)。没有明确示出诸如DSLAM、CMTS节点等附加示例基础设施元素。经由驻地网络240、242为一个或多个STB 236和UE设备238、239服务的订户驻地网关234(其还可以包括多播接收器功能或MCRx)是基础设施的客户侧部分的例示。还应理解，在附加的或替代的实现方式中，多播接收器功能也与STB位于同一位置。

熟练技术人员将认识到的是，除了媒体分发服务器(有时也称为“内容传递节点”)之外，CDN还可以包括被配置为实现请求重定向或重路由机制的各种网元以及相关的后台系统，和/或可以与其互操作，所述后台系统诸如可以部署为媒体流传输网络后台(未具体示出)的一部分的订户管理系统、带宽调度系统、账户/计费系统等。

在附加或替代实施例中，移动运营商网络230的移动摄取网关231可以耦合到内容服务网络220的一个或多个节点(例如，起始服务器214、边缘服务器216-N)，用于以任何数量的数据传输机制(例如，触发推送、拉取和/或混合传输机制)接收媒体片段。在又一实施例中，前端打包器/分段器源节点202可以被配置为将媒体片段上传、传输、发送或以其他方式提供给移动摄取网关231。在一种布置中，根据下面详细阐述的教导，移动摄取网关231可以被配置为充当运营商网络230的适于促进IP多播分发的合适广播/多播服务节点。在另一种布置中，由来自清单文件的定时和URL描述所触发，移动摄取网关231可以下载分段和片段。多个示例性无线或移动设备或用户设备(UE)设备236-1至236-N被示为在示例性移动运营商网络102的无线环境中运行。在本文的讨论中，术语“无线网络”、“移动网络”、“移动通信网络”、“运营商网络”或类似含义的术语可以互换地使用，以指代无线通信网络(例如，蜂窝网络、专有数据通信网络、公司范围内的无线网络等)，所述无线通信网络促进与不同类型的未绑定设备(例如，设备236-1至236-N)的语音、数据和/或多媒体通信。在一个实施例中，这样的设备可以包括智能手机、平板电脑、移动计算机/膝上型电脑、笔记本电脑、电子阅读器、个人数字助理(PDA)、VR/AR游戏设备等，它们能够在广播/多播传递会话中从网络230接收自适应流传输A/V内容，并使用在其上执行的本地ABR客户端/媒体播放器来播放该自适应流传输A/V内容。

无线UE设备236-1至236-N被示为通过一个或多个基站(例如，基站(BS)234)与无线网络230进行无线通信(经由相应的无线电链路238-1至238-N)，基站可操作以经由适当的天线元件向设备236-1至236-N提供空中/无线电接口(取决于具体的移动通信技术，采用合适的射频(RF)链路的形式)。举例而言，基站104可以包括第三/第四/第五代或下一代网络中的节点，并且可以与可操作地耦合到移动摄取网关231的网络控制器节点232进行接口式连接或集成。例如，示例无线运营商网络230可以包括长期演进(LTE)网络，出于本发明实施例的目的，下面将进一步详细描述该基础设施。

将认识到，尽管未在图2中具体示出，但是示例的未绑定UE设备也可以例如经由WiFi网络中的合适热点或接入点使用短程无线电通信(例如，IEEE 802.11b、IEEE802.11a、IEEE 802.11g、HiperLan和HiperLan II标准、Wi-Max标准、OpenAir标准、蓝牙标准等)下载媒体。在又一个实施例中，可以实现DVB架构，该DVB架构涉及图2所示的网络基础设施组件的至少一部分。在又一布置中，作为上面阐述的用于接收媒体分段、片段和/或块的布置的附加或替代，移动摄取网关231可以与分段器/打包器节点202进行接口式连接。

图3A描绘了用于实践本发明的实施例的示例多播网络环境300A的高层级表示。熟练技术人员将理解的是，多播网络环境300A是以上阐述的网络100或200的抽象版本，在此对其进行了简化，以便着重关注与示例性实施例有关的关键组件和概念。大体上，网络环境300A包括媒体摄取部分304A，304B、分发部分308-1至308-N以及客户端传递部分314-1至314-K，其中，在一个示例实施例中，可以使用基于HTTP CTE的数据传输机制来实现媒体摄取网络部分304A/304B和客户端传递部分314-1至314-K。在其他实施例中，媒体摄取网络部分304A/B可以被配置为实现任何合适的媒体数据传输机制(例如，推送/拉取、触发推送/拉取)，以将媒体数据传输给或以其他方式提供给一个或多个媒体入口网络节点，这将在下面进行阐述。因此，应当理解，根据本文的教导，术语“摄取(ingest)”或“摄取中(ingesting)”或相关变型可以包括用于将媒体数据传输给摄取节点的任何类型的数据传输机制(包括CTE)。在一个实施例中，分发网络部分308-1至308-N可以基于使用诸如NORM、FLUTE、FCAST之类的合适IP多播协议的可靠IP多播传输。优选地，根据本文的教导对IP多播传输机制进行扩展或以其他方式加以修改，从而促进从上游网元开始的媒体分发，其中甚至在分段的整个媒体数据变得可用之前就将媒体上传给或以其他方式提供给该上游网元。

源分段器/打包器节点302包括处理功能，该处理功能用于将每个媒体分段分为多个片段(每个片段包括音频、视频和/或A/V数据的一个或多个帧)，并且还使用建立在网元306A、306B之间的相应HTTP CTE会话将片段摄取到该一个或多个网元306A、306B，其中网元306A、306B充当IP多播入口节点。在一个实施例中，网元306A/306B可以包括CDN起始服务器(例如，国家起始节点、区域分发节点或边缘分发节点，取决于哪个节点被提供来作为IP多播摄取点)。在另一个实施例中，网元306A/306B可以包括LTE广播/多播服务中心(BMSC)节点。可以将一个或多个边缘多播接收器310-1至310-M部署为IP多播网络308-1至308-N的端点，用于在协议特定的IP多播传输对象中接收媒体数据。各种客户端应用(或简称为客户端)312-1至312-K在绑定和/或未绑定环境中可操作以经由相应的HTTP CTE会话(取决于它们加入了哪个IP多播组)从边缘接收器310-1至310-M下载媒体数据。应当注意，媒体内容可以通过受益于HTTP CTE传递的方式进行打包。如本专利申请中其他地方所指出的，IP接收器功能可以在不同等级(例如，最终用户站、STB或网关)下位于同一位置或者通过其他方式集成，并且根据实现方式，IP接收器功能还可以与HTTP CTE接收器功能和/或媒体播放器功能集成。

图3B是包括可以被改进、组合或(重新)布置成一个或多个实施例的步骤、方框或动作的高层级方案300B的流程图，以及用于促进图3A所示的示例高层级多播网络中的端到端流动中的低时延媒体摄取和分发的附加流程图。在方框350处，内容源网络节点被配置为创建每个媒体分段的多个数据片段，并用于例如使用分块传递向与IP多播摄取点相关联的HTTP CTE服务器节点上传和摄取媒体片段(例如，当它们在实况媒体服务中变得可用时)。如方框352所述，通过生成并向一个或多个边缘IP多播接收器(即，接收者)传输合适的IP传输对象的方式来促进分块媒体的多播分发。由一个或多个客户端来实现(方框354)从边缘接收者下载/传递媒体内容，这可以是与内容源网络节点处用于媒体上传的CTE机制相同的基于HTTP CTE的机制，或者可以是不同的CTE机制(例如，使用不同的块大小)，或者可以是常规HTTP数据传输机制(例如，针对的是传统客户端应用)。此外，根据IP多播接收器功能的集成位置(例如，媒体播放器直接消费IP多播传输对象)，媒体播放器或客户端应用可以被配置为使用直接应用编程接口(API)调用、子例程、协议、功能调用等来模拟“类似HTTP”的文件操作，以获得用于回放的媒体数据，如方框354所示。因此，在这样的实施例中，可以将与示例性端到端过程300B的方框352相关联的接收功能以及方框354的消费功能在单个UE节点中进行组合，该UE节点充当所请求的媒体信道的IP多播树的IP多播端点。

熟练技术人员将认识到，边缘接收者与关联的客户端之间的不同的媒体下载/消费会话可以相对于彼此异步地发生。以类似的方式，与各种媒体信道有关的数据可以在经由不同的网络端口/接口执行的不同的HTTP CTE上传会话中从一个或多个前端媒体上传打包器上传到IP多播摄取点，这与一个或多个客户端是否正在加入到或调整到与媒体信道相关联的多播组无关。

因此，在示例实施例中，分块传输编码可以作为方框350的一部分提供以作为HTTPver.1.1中的数据传输机制，其中可以跨越在网络中提供的所有比特率表示(例如，标清(SD)质量、高清(HD)质量、超高清(UHD)质量、4K质量等)，针对媒体信道流的分段的每个片段来在一个或多个“块”中发送媒体数据。在一种实现方式中，基于CTE的数据传输机制可以使用Transfer-Encoding HTTP首部代替Content-Length首部，Content-Length首部在典型的HTTP会话中通常是必需的。由于没有使用Content-Length首部，因此，发送器在向接收器进行传输之前无需知道内容的长度/大小。在一种实现方式中，可以在传输的(例如，可配置的)适当时间点发信号通知每个块的大小，使得HTTP CTE接收器可以确定何时已经接收到了完整的块。例如，在说明性实施例中，可以正好在对块本身进行传输之前来传输块大小。在另一个实施例中，数据传输可以由零长度的最终块来终止。

在另一个实施例中，基于CTE的传输机制可以被配置为支持和维护上传打包器与起始服务器之间的HTTP持久连接，例如，优选地用于动态生成的内容。熟练技术人员还将认识到，在某些实施例中，可以将分块编码配置为允许发送器在消息主体之后发送附加的首部字段，这在产生内容之前无法知晓字段的值的情况下(例如在需要对媒体内容进行数字签名或加水印时)是有利的。

在示例CTE格式化方案中，如果在HTTP消息中指定了值为“分块”的Transfer-Encoding字段(客户端发送的请求或来自于服务器的响应，其中客户端和服务器是HTTPCTE会话的指定端点)，则消息的主体可以包含未指定数量的块、终止块、尾部以及最终的CRLF(回车后跟换行)序列。每个块可以以其嵌入的数据的多个八位位组(例如，以十六进制数表示)开始，其后是可选的参数(例如，块扩展参数)和终止CRLF序列，然后再是块数据，其中块由CRLF终止(例如，用作块边界标记)。如果提供了块扩展，则块大小可以以分号终止，后跟参数，每个参数也以分号划界。每个参数可以被编码为扩展名，后跟可选的等号和值，该等号和值可以用于支持附加服务，例如，运行消息摘要或数字签名，对估计的数据传输进度的指示等。终止块可以是作为常规块提供，但块长度为零，其后可以跟一个或多个尾部。

通过参考将认识到的是，本发明的实施例提供了一种交换到交换(E2E)传递/分发系统，用于通过固定或移动分发网络的媒体分段(例如，DASH分段)的低时延传递，该系统利用IP多播将内容从起始节点发送给边缘接收者站点。大体上，在一种示例实现方式中，实况分段器/打包器(也称为内容源节点)可以被配置为创建相对较大的分段，例如，持续时间为5秒。可以将每个分段细分为使用HTTP CTE来上传的多个片段。例如，片段可以仅包含如编码视频帧之类的单个媒体样本，例如即时解码器刷新(IDR)帧(一种特殊的I帧)，但是，其他变型也是可能的。

熟练技术人员将认识到，例如，对于使用DASH/ISOBMFF的低延迟实况通信，示例分段/分割过程可以被配置为生成从帧构建的相对较短的片段，其中GOP可以分为两个或多个片段。分段器/打包器节点可以被配置为仅当已经从实况源中完全接收到分段的该片段的所有帧(视频图片和/或音频样本)时才使内容变得可用。可以提供GOP作为两个关键帧(例如，IDR帧)之间的视频图像的编码序列，其中解码器可以仅在关键帧后跟着一个或多个增量帧的情况下才开始对GOP的视频序列进行解码。在一种极端情况下，分段器/打包器可以针对每个新帧生成新的片段，使得一旦帧的所有数据对分段器而言是可用的，则该片段就变得可用。应当理解，在这种情况下，所有的P帧和B帧也被打包成单独的片段。

关于图3A所示的示例端到端网络环境300A，将认识到的是，尽管在分发网络(例如，CDN)内部使用了可靠的IP多播分发来将对象从HTTP起始服务器携带到IP多播边缘，但是，诸如实况编码器/分段器之类的节点以及HTTP客户端仍位于该网络的外部并且可能未必知晓CDN内部的IP多播的使用情况。

由于本发明的至少一些示例性实施例特别地涉及ISOBMFF，在下面给出了简要的概述。ISOBMFF以灵活可扩展的格式定义了一种通用的容器或包装器结构，这种格式有助于基于时间的多媒体文件(如音频和视频)的互换、管理、编辑和呈现，该格式可以构成其他容器格式的基础，其中呈现可以是本地的，或者可以经由网络或其他基于文件的传递机制。通常，媒体文件格式提出了一种面向对象的文件结构，并包含媒体数据定时序列(如视听呈现)的定时、结构和媒体信息。可以将文件分解为基本对象，其中对象的类型可以暗示出对象的结构。符合ISOBMFF标准(ISO/IEC 14496-12，以引用的方式并入本文)的文件被形成为一系列对象，称为“框”，其中所有数据都包含在框内，并且在文件内可能没有其他数据。“框”是由唯一类型标识符和长度定义的面向对象的构建块。呈现(运动序列)可以包含在若干文件中，所有定时和成帧(位置和大小)信息都必须在ISO基本媒体文件中，并且辅助文件实际上可以采用任何格式，只要它们能够通过以ISO基本媒体文件格式定义的元数据来进行描述即可。为了标识基于ISOBMFF的文件所遵循的规范，可以将品牌用作文件格式中的标识符，这些标识符可以设置在名为文件类型框(“ftyp”)或者在媒体分段的情况下名为“styp”的框中(必须将其放在文件的开头)。支持流传输的文件包括与待流传输的数据单元有关的信息(例如，如何基于流传输协议在文件中提供基本流数据)。与流传输有关的附加框包括“moov”框、“mdat”框、“moof”框等，这些框可以出于本发明的目的而作为低时延ISOBMFF片段的一部分提供，如下所述。应当注意，分段或文件类型框(styp)或其他附加ISO-BMFF框可以用同一HTTP块的第一片段来提供，或者可以通过单独的HTTP块提供。styp框指示关于片段和分段结构的信息以及一些兼容性信息。

在示例实施例涉及作为源节点302的实况DASH分段器的情况下，可以将其配置为使用ISOBMFF作为分段格式，但是，也可以使用其他分段/格式化方案(例如，通用媒体应用格式(CMAF)格式以及其他类型的HTTP自适应流传输(HAS)格式等)。如前所述，IP多播接收器通常可以位于CDN边缘，该CDN边缘可以位于不同的低层级下，例如，在家庭网关中或者甚至与客户端共同位于同一物理UE设备或器件上。在示例实现方式中，源节点302可以被配置为接收实况媒体信道的每个多比特率表示的连续媒体流并将其分成单独的媒体分段，并且进一步将分段媒体流的分段细分成多个片段。例如，一个5秒的分段可以包含5个片段，每个片段包含1秒的媒体数据，例如完整GOP。为了低时延，片段可以仅包含GOP的一小部分。作为说明，在编码器产生具有1秒GOP的流的情况下，分段器302可以被配置为创建5秒分段，每个分段包含十个0.5秒的片段(即，GOP的一半)。

在一个实施例中，实况分段器/打包器302可操作以利用初始HTTPPUT或POST操作将内容位置信息(例如，文件的统一资源定位符(URL))上传至充当IP多播摄取点或与IP多播摄取点相关联的起始服务器；此举可以被认为是如上所述的推送机制的示例。响应于此，尽管未接收到文件大小和实际内容，起始服务器仍可以被配置为向边缘接收者节点通知新接收到的HTTP媒体资源。通常，边缘接收者节点可以被配置为一旦边缘接收者节点知晓了HTTP媒体资源信息(例如，URL)，就开始服务于来自HTTP客户端的任何请求，例如，优选地通过HTTP CTE机制来进行，这是因为边缘接收者节点不知道实际文件大小，也没有实际数据可用。

如前所述，实况分段器/打包器302可操作以创建跨多个比特率表示的媒体流的多个分段，其中每个分段可以包含一个或多个片段。在一个示例实施例中，分段器/打包器节点302可以被配置为一旦针对片段的数据变得可用，就将每个片段作为一个或多个HTTP块进行发送。因而，由于分段器/打包器不必等待创建整个分段，在上传过程中缩短了分段延迟。根据本文的教导，与起始节点的HTTP CTE服务器相关联的IP多播发送器可操作以开始为新分段的每个片段或每个HTTP块创建新的IP多播传输对象(即，当接收到新的HTTP资源信息时)，其中片段以HTTP块的形式上传。此外，多播发送器还可以被配置为(例如，在一些示例实现方式中的短缓冲之后)将块连续地写入对应的传输对象，这在一些示例性实现方式中可能涉及到块首部的去除。当接收到空块时，多播发送器可操作以通过累加所有先前接收的块大小来确定文件片段大小，这可以通过发送边界标志以指示“最后分组”并开始新的传输对象来发信号通知。应当理解，可以在本发明的范围内实现用于指示“最后块”的各种其他方法。

转到其中示出了消息流程图的图4A至图4C，这些消息流程图示出了根据上述总体方案的示例实施例的基于CDN的实现方式中的低时延媒体摄取和分发。特别地，图4A中的附图标记400A通常是指相对于基于CDN的IP多播架构，与媒体上传、分发和传递的端到端过程有关的消息流。示例源网络或节点402包括分段器(也称为打包器)403，其可操作以实现与CDN起始节点404的HTTP CTE会话，CDN起始节点404可以包括HTTP CTE服务器405和多播(MC)发送器407，在一个实施例中，其可以构造为分布式计算平台。CDN边缘节点406同样可以包括MC接收器409和HTTP CTE服务器411。能够进行HTTP分块传递的UE设备可以设置有客户端408，客户端408包括HTTP CTE接收器413和媒体播放器/缓冲区415。尽管在图4A中例示了单个CDN边缘节点406和单个UE/客户端408，但是熟练技术人员将理解的是，可以在基于CDN的IP多播架构中提供多个CDN边缘节点，其中每个CDN边缘节点服务一个或多个UE/客户端。

在一种布置中，分段器403可以被配置为一旦片段变得可用，就使用HTTP CTE将分段的每个片段加载或以其他方式传输给起始节点的HTTP CTE服务器405。如前所述，可以将一个分段细分为多个片段，例如，分段#N的片段416-1至416-N，其中可以使用一个或多个块将每个片段上传或以其他方式提供给HTTP CTE服务器405。可以将分段Url(也称为HTTP对象URL)和与开始分段传输有关的一个或多个HTTP首部418提供给HTTP CTE服务器405，可以基于向MC发送器设施407提供的新对象开始指示来将该分段URL和HTTP首部418作为分段url和HTTP首部422传播给MC发送器设施407。早于第一片段(即，当最终确定(finalize)上一个分段并且分段器转到下一个分段时)发送新创建的分段的分段URL和HTTP首部的好处在于：下游节点可以更早地知晓新创建的分段。此外，在某些情况下可能还有益的是，还发送一些其他元数据(如styp框)来作为带有首部和分段url的第一个HTTP块，以便任何客户端都可能已请求一部分二进制数据。作为说明，附图标记420、437、444、451指的是分段器403与HTTP CTE服务器405之间的关于分段#N的片段416-1至416-N的块传输，优选地使用如上所述的适当格式化的CTE消息来携带媒体数据。应注意的是，HTTP块中的媒体数据仅在420与437之间(以及之后在444与451之间)的时间期间提供。分段器节点403在418与420之间(以及之后在437与451之间)不发送媒体数据。当分段包含两个以上的片段时或者当分段器403正将片段细分为更多的HTTP块时，则相应地重复该过程，例如如图4B所示。

在一个示例实施例中，当源节点402开始新的分段(例如，分段#N)时，与源节点402相关联的适当的服务逻辑可操作以在到起始服务器404的初始传输中在HTTP首部418中包括各种元数据信息，例如，与MIME类型、内容位置(即，分段URL，其可以是相对于基础URL的或从基础URL开始进行索引)等有关的信息。在另一个实施例中，HTTP首部418还可以包括对用于分段上传的HTTP分块传输编码的指示。在一种布置中，在源节点402已经指示了新分段的创建并且已经提供了HTTP首部和分段URL(作为HTTP方法行的一部分)之后，源节点402可操作以收集/处理片段的所有数据。应当理解，在这种数据收集阶段期间，源节点402可以不发送媒体数据。因此，在这种情形下，源节点402可以被配置为仅在源节点102已经创建了相应的片段之后才开始使用一个或多个HTTP块来发送片段的数据。可选地或替代地，源节点402可以被配置为延迟对新分段创建的指示(即，利用HTTP URL和HTTP首部的HTTP方法)，直到第一片段的数据可用为止。

如图4A所示，可以在分段(例如，分段#N)的所有片段都已上传之后由源节点402将“最后块”信号452提供给起始服务器节点。在接收最后块信号452之前，在CDN起始节点404处执行的例如与作为组成部分的HTTP CTE服务器405组件和/或MC发送器组件407相关联的适当服务逻辑可以被配置为实现CDN起始节点404的组件(例如，HTTP CTE服务器405(其可以被称为上游HTTP CTE服务器)和MC发送器407)之间的各种通信、信号和/或消息，以便处理接收到的元数据(例如，HTTP首部)以及用于在相关信息一可用便经由合适的IP多播向下游传输的HTTP数据块。在一个示例实施例中说明了HTTP首部422的传输或传播以及关于一个或多个片段416-1至416-N的分块数据的传输或传播(如块数据传输430、438、446所例示的那样)。此外，在CDN起始节点404处执行的例如与MC发送器407相关联的服务逻辑可以被配置为生成适当的IP多播传输对象(例如，取决于为CDN起始服务器配置的IP多播协议)，而IP多播传输对象可以被配置为将HTTP首部信息和媒体数据携带到与CDN边缘节点406相关联的MC接收器409，这将在下面更详细地阐述。作为说明，传输424说明了根据正在使用的IP多播协议在被适当分组化的传输对象中输送HTTP首部信息。同样，传输434、440、448说明了根据正在使用的IP多播协议又在被适当分组化的传输对象中输送部分分段的媒体数据。在CDN边缘节点406处执行的例如与作为组成部分的MC接收器组件409和HTTP CTE服务器组件406(其可以被称为下游CTE服务器)和/或MC发送器407相关联的适当服务逻辑可以被配置为实现CDN边缘节点406的组件(例如，HTTP CTE服务器411和MC发送器409)之间的各种通信、信号和/或消息，以便根据以下因素来处理接收到的元数据(例如，HTTP首部)以及传输对象中的媒体数据：MC接收器功能所处/集成的位置，客户端是否能够直接消费IP多播对象等。如图4A所示，当存在对媒体的请求(例如，客户端调谐到或切换到与实况媒体流相对应的信道)时，关于到客户端408的下游传递，可以通过传输426将HTTP首部提供给下游HTTPCTE服务器411，可以通过存储动作428在服务器缓冲区处缓冲对象，且如附图标记436、442、450所示，可以针对分段的多个片段创建HTTP块。熟练技术人员将认识到的是，接收到的媒体数据块/分段可以存储在根据HTTP首部信息(例如，在从分段的基础URL开始进行索引的相对URL处)识别出的存储位置处，该存储位置在边缘节点406和/或与其相关联的一些其他媒体存储节点处。

如前所述，可以使用HTTP CTE数据传输机制(例如，通过符合CTE的UE/客户端应用)或常规HTTP机制(例如，通过传统UE/客户端应用)实现与媒体数据的请求和下载有关的UE/客户端侧操作。在图4的说明性实施例中，与符合CTE的客户端408相关联(例如，与HTTPCTE接收器413相关联)的适当服务逻辑可操作以生成对分段的HTTP CTE请求433(例如，基于通过带外或带内传输机制接收的清单文件或MPD；MPD包含以下信息：客户端可在分段完全可用之前开始获取分段)，于是，在多个块传输(例如，关于片段416-1的块传输435和关于最终片段416-N的块传输)中，经由HTTP分块传递来提供分段的媒体数据。如附图标记431所示，可以将接收到的媒体数据提供给媒体播放器的缓冲区415，以便在合适的显示器上进行呈现。

在一个示例实施例中，在CDN起始节点404处执行的服务逻辑可操作以移除关于从源节点402上传的HTTP块的块边界标记。在一个示例实施例中，响应于来自源节点402的最后块信号，CDN起始节点404可以被配置为对所有块的大小进行累加，以生成与分段相关联的对象大小指示453来边缘多播接收器(例如，CDN边缘节点406)发信号通知对象大小指示。在另一实施例中，可以将块边界指示提供给CDN边缘节点406的MC接收器409，MC接收器409可以对所有片段大小进行累加。一旦CDN边缘节点406已知文件大小(通过来自CDN起始服务器404的显式信令或借助于MC接收器的内部确定)，就可以向客户端408生成“最后块”信号454，该信号454可以如信号456所指示的那样传播给媒体播放器。根据客户端配置，针对下一分段(例如，分段#N+1)的HTTP请求460可以基于对所传播的最后块信号456的接收。在另一示例实施例中，客户端可以被配置为以预先配置的间隔生成下一分段请求460，而无需接收最后块信号456。

在图4A和图4B中，CDN起始节点404使用推送基础URL来确定相关联的基础IP多播传输信息，比如，IP多播地址、UDP端口和协议(NORM或FLUTE)。可以将推送基础URL与文件系统中的目录文件夹进行比较，其中该文件夹中的所有文件或对象都与传输相关联。单独的控制器节点通常提供推送基础URL和相关联的IP多播传输参数。CDN起始节点将多播发送器功能(407)与每个推送基础URL相关联，并且可以将推送基础URL部分替换为可见URL。对于每个接收到的单独的分段和块，多播发送器功能(407)随后指派唯一的传输对象标识符。

关于CDN内的IP多播分发，在下文中更详细地阐述了涉及NORM(RFC 5740，通过引用的方式并入本文)的示例实施例。在一个实施例中，MC发送器407可以被配置为针对每个HTTP块创建NORM传输对象，而不管HTTP块包含的是完整片段还是部分片段。在有线环境(例如，DSL/电缆网络)(在该环境中，传输速度通常较高，分组丢失最少(即数据是可恢复的))中，IP传输对象是包含完整片段还是部分片段可能都不会产生重大的影响。另一方面，在移动UE设备不能轻松地建立上行链路的移动电信网络中，涉及部分片段的丢失通常是不可恢复的，由此可能在播放器侧引发同步问题，尤其是在诸如IDR或I帧之类的关键帧丢失的情况下。如将在下面阐述的，根据本发明的实施例，公开了与示例LTE移动电信网络中的IP多播分发有关的附加改进。然而，熟练技术人员将认识到，在作必要修改后，本文描述的IP多播分发方案的至少某些方面也可以适用于例如采用FLUTE的网络中的基于移动网络的IP多播或广播分发实施例。

在一种布置中，可以从接收到的HTTP块中移除HTTP块首部(例如，<size>\r\n，有时也被称为块边界标记或块边界指示)和尾部(trailing\r\n)。在MC发送器节点407处执行的服务逻辑可操作以使用块有效载荷来生成NORM传输对象，其中NORM传输对象大小(即，相当于HTTP块大小)可以利用文件传输信息扩展首部(EXT_FTI)或者作为NORM INFO消息的一部分来发信号通知(例如，在将于下面描述的一个或多个选项中)。应当理解的是，在另一方面，在基于移动网络的IP多播分发实施例中，总是发送完整分段片段来作为对象可能是有利的。在这种情形下，用于媒体片段的HTTP块的数量可以在分段的开头处以新的HTTP首部来发信号通知，或者可以用CDN起始服务器节点(通过节点上的配置文件，或经由外部配置和控制服务器)或充当广播/多播起始服务器或其功能性等同物的网元来单独地进行配置。因此，熟练技术人员将认识到，在基于NORM的电缆/DSL分发环境的情况下，将NORM传输对象与分段片段对齐可能不会带来切实的好处。

当CDN起始服务器404接收到新分段的HTTP首部和分段URL时，与MC发送器407相关联的服务逻辑(例如，被配置为支持基于NORM的可靠多播)可操作以利用与具体传输对象ID(TOI)相关联的NORM INFO消息(例如，如图4B的消息流程图400B中所示的NORM INFO 477)将分段URL和HTTP首部提供给一个或多个边缘多播接收器节点，例如与CDN边缘节点406相关联的MC接收器409(如图4A所示)。应注意，CDN起始服务器404可以使接收到的分段也可用于单播传递。从概念上讲，CDN起始服务器404和CDN EDGE406因而被部署在同一节点上，并且HTTP服务器节点405上的摄取立即可在HTTP Server节点406上使用。

在一个示例实施例中，NORM INFO消息可以通过TOI与分段的第一块相关联(即，NORM INFO消息与分段的第一块携带相同的TOI)。应当注意，NORM INFO消息中的HTTP首部信息可以被配置为指示HTTP分块传递，因此在一个示例实施例中，它可以不包括Content-Length首部字段。此外，根据一种实现方式，MC发送器407可以被配置为仅针对分段的第一块(即，完整片段或部分片段)生成NORM INFO消息(例如，具有HTTP首部和分段URL)，其中没有针对分段的后续块提供相应的NORM INFO消息。在这种布置中，可以通过EXT_FTI扩展首部来发信号通知块大小(也称为传输对象大小)，如前所述。对于后续片段，TOI值可以顺序递增，例如迭代地增加1，其中多播客户端可以被配置为将接收到的对象与最近一次接收到NORM INFO消息的HTTP资源相关联。作为示例，可以在TOI值为20的对象中发送具有分段URL和HTTP首部的第一片段。优选地，NORM MC接收器/客户端可操作以将所有后续的NORM传输对象(例如，TOI＝21的传输对象)附于TOI为20的传输对象之后，如图4B所示，其中附图标记478的多个实例指代用于携带媒体数据并与NORM INFO消息477相关联的多个NORM DATA消息或对象。熟练技术人员将认识到，这种分发机制的好处在于，NORM INFO消息(例如，NORMINFO消息477)可以包含来自源节点402的HTTP首部的精确副本，同时没有指示第一HTTP块的大小的大小指示符。如前所述，当在HTTP块传递事务451中上传来自分段的最后片段的数据之后，可以将最后块信号452提供给CDN起始节点404，对该片段数据进行处理，并作为内部数据传输446、448提供给MC发送器节点407。

在另一示例实施例中，可以将NORM INFO消息与每个NORM传输对象一起传输，其中第一块的NORM INFO消息可以被配置为包括分段URL、HTTP首部以及对HTTP块大小的大小指示。另一方面，所有后续块的NORM INFO消息可以仅包含块大小。

下面阐述的是根据一个实施例的第一块的示例NORM INFO消息：

应注意，块大小不是随HTTP首部一起提供，而是作为单独的条目提供。

后续块的示例NORM INFO消息格式可以包括如下所示的内容：

在另一个示例实施例中，可以将NORM INFO消息与每个NORM传输对象一起传输，其中所有NORM INFO消息可以被配置为包括分段URL、HTTP首部以及对HTTP块大小的大小指示。为了标识第一块，将块编号引入到每个NORM INFO消息中。分段的第一块始终由块编号零(或另一个明确定义的编号)标识。所有后续块均以增加的块编号进行编号。

下面阐述的是根据一个实施例的第一块的示例NORM INFO消息：

后续块的示例格式可以包括如下所示的内容：

尽管在如上所述的一个实施例中可以仅包括chunkSize指示符，但是，附加或替代变型仍可以可选地或以其他方式支持提供分段URL。熟练技术人员在参考本文时将认识到的是，这种情形的潜在缺点在于，可能不得不延迟HTTP首部信息和分段URL信息，直到第一片段可用为止。

另一变型涉及使用块偏移量而不是块编号来定义块的序列。例如，块偏移量可以被配置为表示块被放置在的总体分段内的字节位置。作为说明，块偏移量零表示该块被放置在总体分段的开始处。块偏移量1000可以表示该块的第一字节位于总体分段中的字节偏移量1000处。块偏移量与块大小的总和通常给出了下一个块的块偏移量。与块编号相比，采用块偏移量的好处在于：接收器不仅可以检测到块丢失，而且还可以检测到缺失块的缺失字节范围。

其他变型还可以涉及针对每个NORM传输对象的NORM INFO消息的传输，但是针对第一块传输了两个NORM INFO消息。在这种情形下，可以将第一块的第一NORM INFO消息配置为仅包含HTTP首部，而第二NORM INFO消息可以被配置为仅包含块大小。下面阐述了本实施例中的包含分段URL和HTTP首部信息的示例NORM INFO消息格式：

下面阐述了第一块和所有后续块(仅包含块大小(chunkSize)以及可选的分段Url(segmentUrl))的示例NORM INFO消息格式：

下面紧接着阐述了关于NORM边缘接收器(例如，与图4A中所示的CDN边缘节点406相关联的MC接收器409)的处理的更多细节。

在一个示例实施例中，一旦与CDN边缘节点406相关联的MC接收器组件409接收到了带有即将到来的分段的分段URL和HTTP首部信息的NORM INFO消息(例如，图4B的消息流程图400B中的NORM INFO消息477，或者经由图4A的消息流程图400A中的IP多播信息消息424)，尽管尚未收到HTTP有效载荷和/或Content-Length信息，但CDN边缘节点406仍可以开始服务与所请求的媒体信道有关的客户端请求。由于Content-Length信息是未知的，因此，CDN边缘节点406可操作以使用相关联的下游HTTP CTE服务器411提供响应，以实现HTTP分块传递，这是因为HTTP首部“transfer-encoding：chunked”仍然存在于NORM INFO消息477的有效载荷中。在一种布置中，媒体有效载荷的分块传递可以优选地发生，直到接收并缓存了完整分段为止。在另一种布置中，优选地在接收到分段的所有片段之后才可以提供常规的HTTP响应。

CDN边缘节点406的HTTP CTE服务器组件411可以被配置为通过发送HTTP首部信息来开始服务，该HTTP首部信息包括与符合CTE的客户端有关的适用的内容位置信息(例如，如果需要的话，包括任何URL翻译)以及分块传输首部。应当理解，第一块仅在该块部分的所有数据都被接收到时(尤其是当客户端408与CDN边缘节点406之间的链路比特率高于多播比特率时)才可以生成并传输。

在附加或替代实施例中，CDN边缘节点406可以被配置为将传输对象缓冲可配置的时间量(例如，相对较小)和/或直到接收到块的足够数据为止。作为说明，可以提供1400字节的缓冲限制(即，HTTP服务器411缓冲数据，直到已接收到1400字节为止)，这可以是UDP分组的有效载荷。

在以下部分中阐述了关于一个或多个前述实施例的其他改进。如前所述，一旦分段器403最终确定了分段的第一片段(例如，在创建该片段之前已经接收到了该片段的所有帧并对其进行了编码)，源节点402就可以开始发送该片段。此外，在另一实施例中，可以在此时刻在数据平面中引入诸如DRM/DWM、内容策略等附加功能。与CDN起始节点404相关联的MC发送器组件407可以被配置为从相关联的上游HTTP CTE服务器组件405接收不包括HTTP分块首部的数据，并将该数据包装(wrap)为NORM分组有效载荷。NORM传输对象被划分为一个或多个NORM数据分组。在一种实现方式中，MC发送器组件407可以被配置为连续地增加顺序分组标识符或有效载荷标识符(无论是否针对IP多播分发实施了纠错方案(例如，FEC方案)，都可以对其进行配置)，并将其加入IP传输对象的每个新分组中。例如，FEC有效载荷ID首部中的编码符号ID可以递增并添加到每个新的NORM或FCAST分组中。分组编号可以是分层组织的，意味着源块编号以及分组或符号编号。此外，如前所述，每个分组还可以包含TOI字段(传输对象ID)，该字段可以被配置为将每个分组与HTTP对象或HTTP块唯一地关联。在一种配置中，MC接收器实体409可以被配置为监视接收到的分组的顺序有效载荷/分组标识符(例如，FEC有效载荷ID)并根据FEC有效载荷ID对分组进行排序，并且将排序后的流转发给相关联的下游HTTP CTE服务器411。当检测到缺失的分组(例如，基于FEC有效载荷ID)时，MC接收器409的实施例可以被配置为将流阻截，直到分组已被恢复为止。熟练技术人员将理解的是，本特征在本发明的对于HTTP CTE可能需要按顺序传递HTTP对象或HTTP块的实施例中尤其相关。

关于指示HTTP CTE上传会话中的最后块传输，可以根据本文的教导实践几种变型。在一个实施例中，当分段器403使分段的最后一个片段可用时，源网络节点402可操作以使用HTTP分块传递来上传该片段，并使用空块机制来发信号通知HTTP对象结束，以指示“HTTP对象结束”，即作为图4A和图4B中阐述的最后块信号452。如前所述，当HTTP CTE服务器组件405接收到“对象的最后块”信号时，其可操作以通过累加所有接收到的块大小来计算出对象大小。在一个使用NORM来隐式地发信号通知“分块传递结束”的实施例中，与CDN边缘节点406相关联的MC接收器组件409可以被配置为将对具有新的分段URL和新的HTTP首部的新NORM INFO消息的接收视为对完成了先前或当前分块传递的指示。在参考该内容后，熟练技术人员将认识到的是，这种解决方案的潜在缺点在于：多播客户端(例如，MC接收器)在开始新对象之前不能关闭分块对象。在另一实施例中，可以生成新的NORM命令(CMD)消息，用于将“分块传递结束”显式地发信号通知给IP多播接收者实体。可以生成新的NORM CMD消息作为专用控制消息，该专用控制消息可以新定义，或者可以重新使用或重新配置现有的CMD消息，以向MC接收器显式地发信号通知对象结束指示。在又一实施例中，可以生成与零大小NORM传输对象相关联的NORM INFO消息，以发信号通知对象结束指示。熟练技术人员将认识到，本实施例仅适用于与每个块一起传输NORM INFO消息的布置，这已经在上文中作为示例性实施例进行了描述。在又一实施例中，最后块的最后NORM分组可以被配置为包含最后块指示符，类似于B标志。在又一变型中，MC发送器组件407可以被配置为将具有EXT_FTI扩展首部的空NORM传输对象(仍具有有效的ESI和TOI)传输给分发网络的MC接收器，其中扩展首部可以被配置为包含对象大小。

图4C描绘了与另一个摄取变型实施例有关的消息流程图400C，该实施例涉及使用HTTP GET将媒体分段和块摄取到起始节点404中。在此变型中，分段器/打包器节点485(也称为分段器起始节点)被配置为通过本地HTTP服务器使分段可用。起始节点404包括ABR客户端487，其可以被配置为如ABR清单所描述和触发地获取分段。作为说明，ABR清单可以是DASH媒体表示描述(MPD)或另一清单格式。该清单描述了分段URL以及分段变得可用的定时。清单URL和与多播发送器功能的关联(407)由单独的控制节点提供。控制器节点提供IP多播地址、UDP端口以及可能提供协议(如FLUTE或NORM)。对于每个新接收到的HTTP对象或块，MC发送器指派唯一的传输对象标识符。ABR客户端487可操作以针对每个分段确定分段可用性开始时间，该分段可用性开始时间定义了这样的时间：从该时间开始，可使用HTTPGET来下载分段。当分段器/打包器485创建多片段型分段时，分段器/打包器485可操作以更早地制作分段片段，并在ABR客户端在整个分段可用之前开始获取分段时使用HTTP分块传输编码。DASH清单可以包含指示(即可用性时间偏移量(ASTO))，该指示指出分段片段在整个分段之前的时间偏移量处可用。

响应于由分段可用性开始时间(根据DASH清单计算得出)触发并由ASTO时间偏移量进行校正，ABR客户端487可操作以发送包含所请求分段的分段URL的分段请求489。分段器起始节点485开始发送包含分段和第一HTTP块的HTTP首部的响应491。在接收到之后，ABR客户端487使用触发422来触发MC发送器407传递分段URL(来自分段请求489)和来自491的HTTP首部，从而指示HTTP分块传输编码。ABR客户端487将HTTP响应数据传递给MC发送器407，其中去除了HTTP块边界标记。ABR客户端487继续转发HTTP块(例如，块437)，其中去除了HTTP块边界标记。当ABR客户端487接收到最后块指示符(例如，如上所述的指示符451)时，其可操作以触发多播路径(例如，路径418)上的对应指示。之后，ABR客户端487考虑时间偏移量(ASTO)来确定下一分段的开始时间，并触发下一分段Url的分段获取493。然后，ABR客户端487使用来自获取请求493的分段URL以及经由路径495的HTTP首部来触发MC发送器407。应注意的是，ABR客户端487仅在420与437之间(并且以后在444与451之间)接收片段相关的媒体数据。在分段器485创建片段时，分段器没有发送与片段有关的任何数据(即，在491与420之间以及437与444之间没有片段数据)。当分段包含两个以上的片段时或者当分段器485将一个片段细分为更多的HTTP块时，则相应地重复该过程。

图5至图7描绘了出于本发明实施例的目的而配置用于媒体广播的LTE移动电信网络架构的各个方面。具体地转到图5，示出了LTE网络500，LTE网络500具有设置在演进分组核心(EPC)553中的BMSC节点504(例如，用作图2所示的移动摄取网关231)，在示例实施例中，EPC 553被配置为关于包括多个小区554-1至544-N的广播服务区域552来支持演进多媒体广播服务(eMBMS)。通过进一步的说明，提供一个或多个eNB节点556，作为服务于部署在服务区域552中的移动用户/设备558的蜂窝基础设施的一部分。优选地，内容源节点或网络502可操作以使用HTTP分块传递将分段片段上传到BMSC节点504，如上文详细所述。在图5中示出为同一元素510的服务网关(SGW)和/或相关联的分组数据网络(PDN)网关(PGW)可被提供来作为EPC 553的一部分，并且可以经由SGi接口509耦合到BMSC节点504。移动性管理实体(MME)508可以经由S11控制接口511耦合到S/PGW元素510。MBMS网关(GW)节点506可以经由Sm接口519耦合到MME 508，并经由SGmb控制平面接口507和SGi-mb数据平面接口505耦合到BMSC 504。每个eNB节点556可以经由相应的M3/S2-MME控制平面接口515耦合到MME 508，并经由相应的M1数据平面接口517耦合到MBMS-GW 506。S/PGW元素510还可以设置有用于支持单播的S1-U数据平面接口513。

在LTE网络架构500的一个示例布置中，广播和单播无线电信道可以被配置为在同一小区中共存并共享可用容量，其中可用无线电资源的子集可以被临时分配给广播无线电信道。常规LTE网络传统上是为单播通信而设计的，其中具有为每个移动设备服务的单独无线电信道(其中，分配给设备的资源取决于服务所需的数据速率、无线电信道质量和小区内的总业务量)，根据本专利申请的教导，在示例实施例中，广播/多播通信可以实现成演进分组系统(EPS)架构的扩展，该扩展包括与内容源网络502耦合的EPC部分553。因此，可以根据3GPP TS 23.246(MBMS架构)规范(通过引用的方式并入本文)来配置LTE网络架构500的一种实现方式，其中，媒体广播/多播可以与单播数据和语音服务共存，但是应当理解的是，本发明的实施例并不局限于此。在一种布置中，可以同时支持实况流传输和文件传递用例场景，其中可以在同一承载上同时传递不同的服务组合。在一种布置中，广播服务激活可以被配置为根据需要触发示例LTE网络500中的无线电资源分配。例如，广播会话可能在短时间内(例如，几分钟或更长的时间段，或者在某些情况下为几天)处于活跃状态。当会话不再活跃时，可以重新分配所指派的无线电资源和系统资源，以供其他服务使用。此外，LTE广播可以针对诸如体育场馆和城市中心之类的小型地理位置或针对覆盖整个城市或地区的大型区域而被激活。只要LTE网络500中存在足够的容量，多个广播会话就可以同时处于活跃状态。因此，在一种布置中，可以动态地分配用于广播的资源，例如，可以将高达60％的频分双工(FDD)无线电资源和/或高达50％的时分双工(TDD)指派给广播传输。

在LTE网络架构500的一个示例布置中，无线电接口在下行链路中可以基于正交频分复用(OFDM)，其中频率选择性宽带信道可被细分为彼此正交的窄带信道。例如，时域中的10毫秒(ms)无线电帧可以包含各自为1ms的子帧；其中子帧是具有可以分配给广播传输的完整频域的最小单位。在示例eMBMS实现方式中，广播区域(例如，区域552)内的所有用户可以接收广播内容，只要它们具有正确的订阅级别和带MBMS能力的设备(即，具有eMBMS客户端应用的UE)即可。对于熟练技术人员将显而易见的是，通过在无线电接口上建立单个承载，网络运营商可以将数据流分发给数量不限的用户。尽管可以在服务区域的单个小区内传递广播(例如，使用点对多点(PTM)传输)，但是，也可以使用单频网络(SFN)架构来实践本发明的实施例。在一种涉及SFN的布置中，广播区域可以包括多个eNB小区，其中可以使用相同的子帧集和调制及编码方案来通过同步SFN传输发送广播数据，这被实现为来自多个小区的紧密同步的相同传输。熟练技术人员将认识到的是，在这种布置中，SFN传输被配置为：对设备而言像是时间离散信道上的来自于单个大型小区的传输，这可以改善接收信号的质量和频谱效率。通过在OFDM中使用较长的数据符号持续时间，在基于SFN架构的本发明的示例移动宽带传递实施例中，可以减轻延迟信号所引起的符号间干扰(ISI)的影响。对于对抗传播延迟的附件保护而言，LTE/OFDM可以被配置为采用保护间隔，其中在保护间隔期间到达的延迟信号不会引起ISI，因而可以维持数据速率。应当认识到，对于SFN，与单播不同的是，信号可来自许多地理上分离的源并且可能引起较大的延迟扩展，这可能会导致不可恢复的分组丢失，因而出于本发明的目的，有必要对涉及移动宽带的IP多播分发方案作出进一步改进。由于网络中限制MBMS容量的因素之一是来自发射机(其延迟大于保护间隔(即，低发射机密度))的信号的自干扰，因此，在LTE网络500的另一变型中，可以将长循环前缀添加到MBSFN预留子帧，从而允许接收器中的时间差对应于可接受的站点间距离(ISD)(例如大约5km)，该ISD可以基于容量和宽度覆盖区域来配置。

继续参考图5，BMSC节点504可以配置成LTE网络架构500所支持的示例性LTE广播/多播分发树的关键入口点。从CSN 502经由HTTP分块传递提供的通用文件和/或实况视频流(例如，MPEG-DASH格式)可以作为内容携带跨过BMSC节点504，并且可以用于使用FLUTE的广播分发，这将在下面详细地进行阐述。在一个实施例中，在BMSC节点504处执行的适当的服务逻辑可以被配置为使用更高层级的纠错方案(例如，应用层FEC(AL-FEC))向广播添加恢复能力，这不仅向流增加了冗余性以使得接收器能够恢复分组丢失，而且在某些附加或替代布置中还支持各种3GPP相关的传递过程。例如，这样的过程可以包括单播基础文件修复-允许接收器通过单播从BMSC节点504获取文件的其余部分。可以针对接收报告来实施附加的过程，由此网络运营商或网络管理实体可以收集QoE报告并确定可能需要的会话质量度量。

在LTE网络架构500的示例性实现方式中，在MBMS-GW 506处执行的适当的服务逻辑可以被配置为在无线电部分与服务网络部分之间提供网关功能。在一种布置中，MBMS-GW506将流从BMSC节点504转发给参与SFN传输或PTM传输的所有eNB。在网关与eNB之间的M1接口上使用IP多播，这样使得可以高效地使用现有路由器的分组复制功能。网关节点506可以进一步被配置为将MBMS会话控制信令路由到服务于区域552的一个或多个MME 508。MME508又将会话控制消息复制、过滤并转发给参与特定广播会话的eNB 556。在一种布置中，eNB 556可以操作以提供用于SFN区域的配置的功能，以及在无线电接口上向所有设备广播MBMS用户数据和MBMS相关控制信令。熟练技术人员将认识到，在这种布置中，可以向eNB节点提供3GPP多小区协调实体(MCE)功能。

图6描绘了出于本发明实施例的目的的示例eMBMS架构600，其示出了可以在图5的LTE网络500中实现的各种接口。图6中描绘的若干节点或元素与上面详细阐述的图5的节点或元素相同，在此将不再重复其细节描述。HTTP CTE接口或网络路径612设置在CSN/实况编码器节点502(其包含如图4A中的分段器/打包器402/403或图3中的节点302)与BMSC 504之间，以实现如前所述的低时延媒体上传操作。在本示例架构中分别示出了SGW 604和PGW602，其中SGW 604可操作以路由和转发用户数据分组，同时还充当eNB间切换期间的用户平面的移动性锚点以及LTE与其他3GPP技术(如果提供)之间的移动性锚点。对于空闲状态的UE，SGW 604终止下行链路数据路径并在针对UE的下行链路数据到达时触发寻呼。在SGW604处执行的适当的服务逻辑还可操作以管理并存储UE上下文，例如，IP承载服务的参数、网络内部路由信息等。PGW 602可操作以通过充当UE的业务出入点来提供从UE设备(例如，UE 558)到外部分组数据网络(PDN)的连接。UE可以具有与一个以上PGW的同时连接，以便接入一个或多个PDN(例如，PDN 614)。在PGW 602处执行的适当的服务逻辑还可操作以执行策略实施、针对每个用户的分组过滤、收费支持、合法拦截和分组筛选等。根据部署，PGW 602还可以被配置为充当3GPP与非3GPP技术(比如，WiMAX和3GPP2网络(例如CDMA 1X和EvDO))之间的移动性锚点。尽管在图6的eMBMS架构600中未示出诸如归属订户服务器(HSS)、接入网发现和选择功能(ANDSF)、演进分组数据网关(ePDG)等其他网络节点，但应当理解的是，根据具体运营商的基础设施部署，这样的节点或元素也可以包括在示例性网络布置中。

在一个实施例中，UE 558可以被配置成支持eMBMS的终端站，出于本发明实施例的目的，该终端站可以进一步包括IP多播接收器功能和/或HTTP CTE接收器功能。HTTP接口606也可以设置在UE 558与BMSC 604之间。根据在UE 558上执行的应用，应用接口610可以设置在UE 558与一个或多个应用服务器608之间。关于移动宽带网络环境700，图7中示出了示例UE设备平台704。LTE广播/单播网络702表示设置在BMSC 504与UE 558之间的上述网络架构500、600的至少一部分。在一种布置中，UE设备平台704可以包括结合了LTE无线电层的低层级模块710，其可以在芯片组中实现来用于支持单播以及广播。中间件块或模块708可操作以处理合适的IP多播协议(例如，在下面进一步详细描述的具体实施例中的FLUTE)、AL-FEC解码、单播文件修复、传输控制功能(包括服务调度)以及用于广播后文件/片段处理的缓存。根据实现方式，更高层级的方框或模块706可被提供来促进关于中间件708和连接层方法的一个或多个平台应用编程接口(API)，由此，合适的软件开发套件(SDK)和应用下载实体712可以接口式连接来开发、测试和创建支持eMBMS的应用。因此，示例性UE设备不仅可以包括智能电话和平板电脑，而且还可以包括配置用于M2M通信的各种嵌入式平台。

如先前指出的并且在下文中进一步详细描述的，具有eMBMS能力的示例性LTE网络中的实况视频/文件传递场景将FLUTE用于从服务节点(如BMSC节点504)的IP多播。eMBMS架构内的实况流传输可以提供来支持针对实况视频和音频广播的服务，而按需文件传送使得诸如单播减负(例如，本地设备缓存)、软件更新和M2M文件加载之类的服务成为可能。应当理解，实际上，任何任意文件或文件序列都可以在eMBMS架构上进行分发，这些文件或片段可以使用低时延HTTP CTE传递或其他机制上传到广播分发树的头节点，例如BMSC 504。在一些实现方式中，示例性用例的目标广播区域可以具有任何期望的大小，其中一些场景可能需要较小的广播区域(比如，会场或购物中心)，而其他情况则需要更大的区域，甚至覆盖全国范围。当在实况视频应用中使用HTTP自适应流(HAS)(例如，HLS、MPEG-DASH、HDS、HSS、CMAF等)的情况下，示例性eMBMS架构可以有利地被配置为与用于提供单播和广播的相同实况编码器和公共客户端互操作。可以在允许使用UDP在多个单向链路上分发文件的示例性实施例中采用IETF FLUTE协议(如RFC 3926中所述，通过引用的方式并入本文)。在一种涉及FLUTE的布置中，可以使用用于eMBMS会话的嵌套/分层传递架构，其中传递会话的持续时间可以跨越一个或多个eMBMS会话。在一种布置中，广播对于整个eMBMS会话而言可以是活跃的，在此eMBMS会话期间，UE可以接收内容。

通常，可以实现eMBMS多播服务供应的以下阶段：(i)订阅、(ii)服务公告、(iii)加入、(iv)会话开始、(v)MBMS通知、(vi)数据传输、(vii)会话终止和(viii)离开。订阅、加入和离开阶段可以针对每个用户单独执行。其余阶段可以逐个服务地执行，即针对所有对具体服务感兴趣的用户。阶段的序列可以例如根据数据传输需要而重复。此外，订阅、加入、离开、服务公告以及MBMS通知可以与其他阶段并行地运行。在广播服务模式中，可以提供以下阶段：(i)服务公告、(ii)会话开始、(iii)MBMS通知、(iv)数据传输和(v)会话终止。与在多播模式中一样，广播模式下阶段的序列也可以例如根据数据传输需要而重复。服务公告和MBMS通知阶段也可能可以与其他阶段并行地运行，以例如通知尚未接收到具体媒体广播服务的UE。

图8中示出了示例性会话调度场景800中的传递会话与eMBMS会话之间的关系，其中FLUTE传递会话802跨越多个eMBMS会话806、808。服务公告804可以用于例如使用调度描述来向设备通知传递会话802以及eMBMS会话806、808，由此UE设备无需在无线电接口上连续地监视eMBMS会话。在图8所示的场景800中，调度描述指示UE期望与相应参考时间T₁和T₅有关的在某些时间范围或窗口之间(例如，T₂与T₃之间以及T₆与T₇之间)的eMBMS会话。在UE期望eMBMS会话806之前，优选地将其配置为在无线电接口上已经是活跃的(即，T₁＜T₂)。当涉及文件传递服务时，优选的是设备应在无线电上的预期传输时间之前搜索会话，以确保它们不会错过传输的开始。应当理解的是，图8中的示例性场景800可以表示一种服务，比如，下载允许用户使用来自电话、平板电脑或电视的单播服务来激活和接收广播并与广播进行交互的应用。从用户和UE中间件的角度来看，这两个广播806、808属于同一MBMS用户服务，这种服务呈现了包括激活和停用的完整服务。

为了促进对涉及LTE广播的分块FLUTE传递的实施例的描述，下面将阐述关于FLUTE的简短部分。

在FLUTE中，提供了文件传递表(FDT)，作为用来描述与将在文件传送会话内传递的文件相关联的各种属性的手段。作为数据库机制，FDT可以包含传输对象标识符(TOI)(类似于先前描述的NORM传输对象的标识)与文件元数据(如文件名、内容位置(例如，URL/URI)、文件类型、文件大小、FEC实例ID等)之间的映射。TOI是一个整数值，打戳(stamp)在属于文件的每个UDP分组中。接收器/客户端可以被配置为基于TOI值确定IP/UDP分组与任何给定文件的关联。根据通常与FLUTE FDT实例一起提供给客户端的文件大小，客户端可以导出具有特定TOI值的文件的预期UDP分组的数量。序列号(例如，表示为编码符号ID和源块编号)允许客户端根据IP/UDP分组有效载荷序列来正确地重新组装文件。分组的序列编号也可被用于分组丢失检测。

在一种布置中，基于FLUTE的网络可以被配置为支持FDT实例和实际FLUTE传输对象(由TOI标识)的独立传输。FDT实例可以被配置为向接收器提供一个或多个文件条目(其也包含针对该文件的TOI关联)。FLUTE不需要发送器将实际FLUTE传输对象与FDT实例相结合地发送。在示例性LTE MBMS实现方式中，对文件条目的隐含假设可以是在接收实际传输对象的任何数据之前接收具有该文件条目的FDT实例。因此，假设了在接收具有TOI的第一个分组之前，客户端已经具有文件元数据(如文件名和文件大小)。在其他示例性实现方式中，文件的FDT实例信息可以与实际传输对象进行组合，其中情况可能是具有所需元数据(比如，每个传输对象的文件名、文件大小和内容类型)，类似于IETF FCAST协议(RFC6968)，其以引用的方式并入本文。在其他布置中(例如，符合在3GPP TS 26.347中提出的MBMS API规范，通过引用的方式并入本文)，可以经由HTTP将经由FLUTE在MBMS承载上接收到的任何文件提供给客户端应用，以便进行检索。因此，根据一个实施例，MBMS接收器/客户端可以被配置为接收完整文件(例如，DASH媒体分段)并使该文件在本地HTTP服务器上可用。实际的文件URL(其可以包括来自FLUTE传递的文件名)可以通过API来通知，也可以在单独的元数据文件(如DASH媒体表示描述(MPD)文件)中描述。

为了在基于FLUTE的LTE eMBMS环境中支持低时延分块传递，本文的实施例提供了对FLUTE FDT实例的适当扩展和修改，以便于将FLUTE传输对象作为(例如，针对于单个文件、片段或分段的HTTP块的)部分文件来进行传输。在一种实现方式中，FDT实例扩展可以包括FLUTE传输对象的顺序标识，其说明了对“最后块指示符”的发信号通知。此外，根据本发明实施例的基于FLUTE的实体可以被配置为一旦接收到部分文件就传输该部分文件，并且不会等待组装所有部分文件(例如，没有要求仅传输完整文件)。在又一布置中，当媒体摄取变为基于片段时，BMSC实体(用作FLUTE发送器)可以被配置为解析进入的HTTP分块流以找到片段边界。在另一个实施例中，内容源实体(例如，分段器/打包器节点)可以被配置为始终将片段放入相同固定数量的HTTP块中(例如，分段器致力于用两个HTTP块来发送每个片段)。关于对传输对象和/或块中的丢失的处理，示例性实施例可以涉及将FEC或文件修复应用于部分文件。在无法修复部分文件的情况下，示例性实施例可以被配置为确保后续的部分文件是可接收的，其中FLUTE传输对象可以配置成一个或多个UDP分组的序列，所有这些UDP分组都通过TOI映射关系与同一对象相关联。

如前所述，本发明的分段及分段分割过程的实施例涉及生成从帧构建的相对较短的片段(例如，GOP细分为两个或多个片段)，以促进低时延媒体摄取。关于在DASH环境中发信号通知低时延片段，一种选择可以基于对来自DASH MPD的可用性时间偏移量(ASTO)信息的使用。在另一种布置中，称为SegmentTimeline的参数可被用于发信号通知每个单独片段的分段可用性。在一个示例性场景中，考虑每个分段包含1秒的媒体数据。假设内容以每秒30帧(fps)的速度进行编码并且分段器/打包器被配置为将5帧打包为一个片段，则每个片段包含30/5＝6个片段，其中每个片段包含5帧＝166.67ms的媒体数据(以5帧/30fps得出)。分段器将片段附于分段，直到接收到该分段的所有片段(在这种情况下为6个)为止。因此，为了构建1秒的片段，分段器会在写入初始片段之后附上5个额外的片段。在客户端侧，DASH播放器可以被配置为利用在DASH MPD中发信号通知的@availabilityTimeOffset(ASTO)参数来开始播放“第一个”片段(而不是要等到全部6个到达)。这样做会使客户端得知：与其计算的针对所有相关联表示的所有分段的可用性开始时间相比，客户端可以开始“获取”的时间要早得多。在此示例场景中，ASTO参数可以设置为等于833.4ms，这就向播放器表明了：分段的第一部分(即，第一个片段)在分段的最后一部分之前833.34ms变得可用(从播放器的角度来看)。因此，客户端可以被配置为在分段可用性开始时间(根据MPD计算出)之前833.34ms针对分段发出HTTP GET请求。此外，一旦使用HTTP GET请求了第一片段，则分段器/打包器可以被配置为使用HTTP分块传递将所有后续片段推送给客户端。因此，在这种布置中，客户端每秒发出一次HTTP GET请求，并且分段器在数据可用时推送该数据(例如，在可能是异步的混合推送-拉取式分发/传递方案中)。因此，分段器/打包器在创建分段的最后一个片段之前不知道分段大小，因而无法在开始时在HTTP首部中发信号通知内容大小。

在另一种布置中，可以将分段器/打包器配置为使得每个分段仅包含单个片段，其中分段器/打包器通知每个单独的分段/片段的客户端分段可用性。由于每个分段仅包含一个片段，因此，一旦该片段可用，服务器就会知道分段大小。假设以上所述的类似分段配置(即，内容以30fps的速率进行编码，分段器将5帧放入每个片段中)，则分段器将创建一个新的166.67毫秒的分段。因为客户端必须每166.67ms发出一次HTTP GET请求，所以需要六个这样的请求而不是先前布置中的一个HTTP GET请求来获得1秒的媒体数据。因此，应当理解的是，尽管在一个实施例中可以实现涉及这种子分段布置的基于FLUTE或NORM的分发网络，但是它将会需要大量的HTTP GET事务来传递内容，从而潜在地影响了网络性能。

因此，在本发明的当前优选的示例实施例中，由于接收器/客户端设备被配置为通过HTTP管道使用少量的GET事务来线性地接收片段序列，因此可以显著地减少HTTP级开销量(例如，URL和HTTP首部)，即使对于相对较大的分段大小也是如此。如上所述，本文的实施例涉及扩展/修改IP多播协议(例如，FLUTE、FCAST等)以支持HTTP分块传递，这样，每个HTTP块可以被打包成FLUTE/FCAST中的单独传输对象。在一种布置中，FLUTE/FCAST功能可以与分段器位于同一位置，使得基于内部数据传输机制和通信来利用每个新片段生成新的传输对象。在另一种布置中，分段器可以被配置为在摄取侧使用HTTP CTE会话来向BMSC节点进行上传，该BMSC节点可以根据本发明的教导被配置为解析和处理接收到的块，进而确定片段边界。

大体上，在一种布置中，利用HTTP块相关信息来扩展FLUTE FDT实例，以利用为每个媒体分段提供的多个片段。因此，示例FLUTE FDT实例方案被配置为包括块标识符参数，使得FDT实例和/或FDT可以包含具有相同文件URL但是却具有不同块编号或块偏移量的多个文件条目。在一种具体实现方式中，FDT实例可以利用HTTP块开始(HTTP-Chunk-Start)元素(如前所述，也被称为chunk-offset元素)和针对包含HTTP块的每个传输对象的chunk-size元素来扩展。替代地，当存在针对FLUTE传输对象的HTTP块开始元素时，content-length元素可以包含块大小信息。HTTP块开始包含块的第一个字节的相对于总文件的开头(例如，相对于文件的第一块)的字节偏移量。作为说明，当第一块为1024字节时，第二块的HTTP-Chunk-Start值可以被配置为1024。当第二块为100字节大小时，第三块的字节偏移量为1124，依此类推。熟练技术人员将理解的是，在这种布置中，HTTP-Chunk-Start值也可以配置成确保HTTP块的序列，由此，客户端可以从HTTP-Chunk-Start导出HTTP块在实际文件中的精确位置。与HTTP CTE传递类似，空块指示HTTP主体的最后块。在FLUTE的情况下，FLUTE发送器仅发送指示文件URL和HTTP-Chunk-Start的FDT实例，但将块大小设置为零。因此在这种布置中，相对于IP多播分发树内的最后块信令，FLUTE发送器不会生成任何传输对象分组。在另一个实施例中，当FDT实例指示块大小为零(即，最后块指示符)时，FLUTE发送器发送大小为零的FLUTE传输对象(即，仅是没有有效载荷的FLUTE分组)。

在实际的基于FLUTE的网络部署中，可以假设各个FLUTE传输对象可能会出现损坏，其中用于纠正(例如FEC)的冗余数据可能无法恢复HTTP块。如前所述，示例LTE MBMS系统(例如，图5至图7中阐述的实施例)可以依赖AL-FEC机制来提高传输可靠性。因此，当在本发明的示例实施例中发送HTTP块时，HTTP块可被配置成FEC源块。

在一种布置中，可以将用作FLUTE发送器的BMSC节点配置为始终将完整片段放入传输对象中。为了实现这种打包，可以将在BMSC节点处执行的适当的服务逻辑配置为对进入的HTTP块流进行解析，以获取片段边界，或者将分段器配置为将片段细分为固定数量的HTTP块(例如，每个片段两个块，如上所述)。因此，可以将多个HTTP块组合/打包为单个新的FLUTE分块传输对象，以进行多播分发。由于HTTP分块传递需要HTTP块的可靠传输和按顺序传递，因此，当块流的前面或中间的块丢失或损坏时，可以将接收器配置为补偿这种丢失，这样，块传递顺序仍然保持一致。为了支持ISOBMFF解析器，本发明的FLUTE接收器的实施例可以被配置为在朝向客户端的流中创建合适的ISOBMFF框，例如，‘free’或‘skip’ISOBMFF框。在某些情况下，FLUTE客户端可以被配置为生成完整电影片段首部，从而例如发信号通知缺失片段的持续时间。为了支持该功能，FLUTE FDT实例的实施例可以被配置为包含与呈现中的片段相关联的呈现时间参数(例如，呈现时间戳或PTS)，由此接收器可操作以将具有正确的呈现持续时间的NULL片段引入流中。对于熟练技术人员而言，在参考本文后将显而易见的是，在本文的示例性实施例中，有利地使接收器能够从后续块中导出块大小以及可选地一些片段信息。

转到图9，图9中描绘了根据示例实施例的消息流程图900，该消息流程图900描绘了在基于移动广播的实现方式中的媒体摄取和分发。应当理解，消息流程图900在某种程度上类似于图4A的消息流程图400A(与基于CDN的IP多播分发有关)。相应地，在作必要修改后，图4A的描述的相关部分也可以结合图9应用，其中提供了涉及基于FLUTE的多播分发的示例性LTE广播实现方式。示例源网络906包括分段器/打包器910，该分段器/打包器910可操作以实现与BMSC节点909的HTTP CTE会话，该BMSC节点909可以包括HTTP CTE服务器组件902和FLUTE MC发送器组件904，在一个实施例中，其可以被构造为分布式计算平台。移动UE节点911用作多播端点，该多播端点可以包括MC接收器组件907和HTTP CTE服务器组件908。能够进行HTTP分块传递的客户端应用912可以设置有HTTP CTE接收器914和媒体播放器/缓冲区916。尽管在图9中例示了单个移动UE节点911，但是熟练技术人员将理解的是，可以将参与基于订阅的多播服务的多个UE节点设置在LTE广播区域中，如上文参考图5至图7所示的示例性LTE架构所述。此外，在图9的消息流程图900中未具体示出诸如MBMS网关、eNB节点等其他中间节点或元素。

当源/分段器906/910开始新的分段(例如，分段#N)时，可以将其被配置为将包含相关联的HTTP首部(例如，MIME类型、内容位置信息(例如，分段URL)等)的初始消息920发送给BMSC 909的HTTP CTE服务器组件902。本领域技术人员将认识到的是，HTTP拉取也可以用于摄取。如前所述，HTTP首部还包括对用于分段上传/摄取的HTTP分块传输编码的指示。在源/分段器906/910已经指示了新分段的创建并且已经提供了HTTP首部和分段URL之后，源/分段器906/910被配置为收集片段918-1的所有数据。一旦已经创建了片段918-1，源/分段器906/910就可操作以使用一个或多个HTTP块来发送片段918-1的数据。类似于图4A的实施例，附图标记934指的是用于上传片段918-1的媒体数据的一个或多个块传输。同样地，附图标记946、954指的是用于上传分段#1的最后片段918-N的媒体数据的多个块传输。在LTE广播的示例实现方式中，BMSC节点909可操作以将每个片段打包到一个传输对象中(即，该片段没有在多个IP多播对象之间“分割”)。因此，在源/分段器906/910使用多个HTTP块来提供片段的情况下，BMSC节点909在一个实施例中可操作以接收片段的所有块并将其打包在具有TOI的传输对象中。为了避免解析字节流，可以向BMSC节点909发信号通知源/分段器906/910为单个片段创建了多少个HTTP块。要么创建新的HTTP首部(将其添加到分段的HTTP首部中)，要么BMSC节点909通过控制配置(例如，使用先前阐述的多种技术)来接收信息。应当理解，将片段的所有块(即，完整片段)打包到多播传输对象中的功能不一定局限于FLUTE实施例，因为它也可以在其他IP多播环境(例如，基于NORM的多播分发网络)中实现。

继续参考图9，附图标记922、934指的是HTTP首部(例如，根据新对象指示)穿过多播/广播网络到UE 911的传播。同样地，附图标记936、948、956指的是HTTP服务器902与FLUTE MC发送器904之间的块的内部传播，这些块被打包到FLUTE传输对象中，以分别用于向UE 911的MC接收器组件907的传输938、950、958。类似于在图4A所示的基于NORM的环境中的CDN边缘节点处的处理，附图标记926、940、952、960指的是HTTP首部处理、UE 911处的分块数据缓冲/传输。UE 911的客户端应用912与HTTP CTE服务器组件908之间的HTTP下载操作类似地图示为针对分段(例如，分段#N)的HTTP请求928，其后是关于片段918-1的CTE分块传递传输935和关于最终片段918-N的分块传递传输945。如附图标记932所示，可以将接收到的媒体数据提供给媒体播放器的缓冲区916，以在合适的显示器上进行呈现。

可以将最后块信号962提供给BMSC节点909，以发信号通知分段边界划分。如前所述，BMSC节点909可操作以累加所有块大小和/或在FDT实例中向UE 911提供最后块指示978。作为响应，UE 911可以向客户端提供对应的指示949，该指示949可以向媒体播放器传播，如信号964所示。根据UE/客户端配置，针对下一分段(例如，分段#N+1)的HTTP请求966可以基于对所传播的最后块信号964的接收。在另一示例实施例中，类似于图4A所示的基于NORM的消息传递流程，客户端可以被配置为以预先配置的间隔来生成下一分段请求966，无需显式地要求最后块信号964。

应当理解，图9所示的各种客户端侧组件(例如，MC接收器907、HTTP服务器908、HTTP接收器914和播放器/缓冲区916)可以集成在不同的布置中，如上文结合图7中示例的支持eMBMS的设备平台704所描述的。例如，在将播放器配置为直接消费IP多播的情况下，可以将IP MC接收器功能集成到播放器功能内。在这种情况下，播放器功能将继续执行“类似HTTP”的文件操作，然而是经由直接API调用而不是HTTP调用。此外，eMBMS客户端可以包括IP多播接收器或与IP多播接收器位于同一位置，其中应用可以直接包括eMBMS客户端，从而避免使用HTTP来获取文件。因此，应当理解的是，在示例实施例中，不必在客户端侧具备HTTP CTE下载操作。在另一种布置中，例如出于本发明的目的，替代地，可以将直接文件访问API与FLUTE多播结合使用。

如上所述，示例的基于FLUTE的LTE广播分发方案涉及通过FDT实例将FLUTE传输对象与HTTP元数据和分段位置信息(例如，URL/URI指针)相关联。下面阐述了配置用于HTTP分块的FDT实例的示例方案，其中说明了针对分段的第一片段的条目(注意，元素Chunk-Size在这里称为Chunk-Length，而HTTP-Chunk-Start在这里称为Chunk-Offset)。

前述示例示出了具有对象ID 2的传输对象与HTTP URL的关联。此外，Chunk-Length参数被配置为指示使用了分块传递以及指示块大小(例如，其可以以字节为单位指定或表示传输对象的大小)。

后续片段(和传输对象)的FDT实例的示例方案可以如下所示。应当注意，Content-Location参数值是与属于该对象的所有其他片段中的URL相同的URL，其中Content-Location参数与Chunk-Offset参数的组合给出了具体片段的唯一引用：

上面的示例性FDT实例说明了序列中的第三片段，其中第一片段以Chunk-Offset0开始，第二片段以Chunk-Offset 1024开始，而第三片段以Chunk-Offset 2048开始。在一个示例性实施例中，当丢失了前面的传输对象时(例如，由于分组丢失太高)，可以根据接收的传输对象的相对位置将该接收的传输对象清楚地放置在总分段中。

基于前述内容，应当理解的是，在本发明的示例性实施例的实践中，可以在分层架构中提供诸如分段、片段、HTTP块和传输对象(FLUTE或NORM)之类的各种实体。例如，一个分段可以包括多个片段，其中每个片段可以由一个或多个HTTP块携带，每个块由一个传输对象携带。多个UDP分组可以形成NORM或FLUTE传输对象。在NORM INFO的情况下，可以提供以下信息：NORM INFOR分组首部中的TOI、URL、分块指示符、分块大小以及分块偏移量或编号。同样地，在FLUTE FDT实例的情况下，可以提供以下信息：TOI、URL、分块指示符、分块大小以及分块偏移量或编号。

图10A至图10C是根据本专利申请的教导的各种步骤、方框或动作的流程图，其中可以将各种步骤、方框或动作组合或布置成用于促进示例的基于IP多播的流传输网络中的低时延媒体摄取和分发的一个或多个实施例

特别地，图10A中所示的过程1000A说明了各种步骤、方框和/或动作，所述步骤、方框和/或动作可以由源网络节点(例如，媒体打包器/分段器)执行，以促进实况内容源的低时延媒体摄取。在方框1002中，可以在源网络节点与IP多播入口节点(例如，被配置为如上所述地支持多播分发树的CDN起始服务器节点、与移动电信网络相关联的广播服务节点等)之间发起HTTP CTE会话。在一个实施例中，实况媒体流被编码、压缩和/或转码成多个比特率表示。当正在接收实况媒体流时，每个对应的比特率表示可以被顺序地分成分段(方框1004)。将每个分段分割成一个或多个片段，其中每个片段包括媒体数据的一个或多个音频帧、视频帧或音频/视频(A/V)帧，或者包括ISOBMFF帧(方框1006)。在方框1008中，识别或以其他方式确定媒体流以用于IP多播分发，并且该媒体流可以与特定IP多播组相关联。

将可以与源网络节点相关联地执行的附加步骤、方框和/或动作被阐述为图10B的过程1000B。在一种布置中，如方框1020所示，可以向网络入口节点发信号通知如下指示：将使用IP多播来分发媒体数据。对于每个分段N，起始节点可以以方框1022所指出的迭代的方式(例如，只要正在接收实况媒体流即可)执行以下操作或动作。包含适当的元数据信息的一个或多个HTTP首部可以例如在分段的片段的传输之前或开始时提供给IP多播入口节点(方框1024)。在分段的整个媒体数据可用之前，经由HTTP CTE会话逐块地开始将分段的一个或多个片段摄取到多播网络节点，其中将一个或多个块提供来用于传输每个片段(方框1026)。在已经传输了分段的所有片段之后，可以将最后块信号提供给IP多播网络节点(方框1028)。如前所述，可以在示例实现方式中提供各种显式的或固有的信令机制，从而指示分段的边界终止/划分。

将可以与源网络节点相关联地执行的其他附加步骤、方框和/或动作阐述为图10C的过程1000C。在一种布置中，在开始片段的上传/摄取之前，可以将指示发信号通知给IP多播网络节点，以指示提供来传输媒体分段的每个片段的块的数量(方框1040)。附加地或替代地，还可以向IP多播网络节点发信号通知协议指示，以指示将使用具体IP多播协议将上传/摄取的媒体分发给一个或多个IP多播接收器(方框1042)。例如，这样的指示可以例如在推送操作中由媒体打包器节点(如前端分段器/打包器202、源分段器/打包器302或源/分段器402/403(对应906/910))提供。它也可以例如在拉取操作中由单独的控制节点提供。

图11A和图11B是根据本专利申请的教导的各种步骤、方框或动作的流程图，其中可以将各种步骤、方框或动作组合或布置成用于促进低时延媒体摄取和分发系统和方法的其他方面的一个或多个实施例。特别地，图11A中所示的过程1100A说明了可以由与内容源网络节点(例如，媒体打包器/分段器)相关联地操作的IP多播网络节点执行的各种步骤、方框和/或动作。在方框1102中，可以从媒体打包器/分段器节点接收消息，以开始与媒体打包器节点的HTTP CTE会话。在一个实施例中，该消息可以包括如下的显式指示：将使用分块传递来跨多个比特率表示将实况媒体流的媒体数据上传或以其他方式提供或摄取到IP多播网络节点。对于实况媒体流的每个分段N，可以按照方框1104中所述的迭代方式(例如，只要分块数据传输过程继续上传媒体分段即可)来关于一个或多个比特率表示执行以下操作或动作。在方框1106中，从媒体打包器节点接收包含各种元数据信息的一个或多个HTTP首部。在方框1108中，经由HTTPCTE会话逐块地接收分段的一个或多个片段，每个块具有块边界标记，其中每个片段包含媒体数据的一个或多个帧，并且在整个分段在媒体打包器节点处可用之前就被接收。在一个示例实施例中，可以针对每个块生成IP多播传输对象，以传输给多个边缘多播接收器(方框1110)。在已经上传或摄取了分段的所有片段之后，可以从媒体打包器节点接收到最后块信号(方框1112)。

将可以与IP多播网络节点相关联地执行的附加步骤、方框和/或动作阐述为图11B的过程1100B。在一种布置中，在接收分段的一个或多个片段之前，可以将包括HTTP首部和其他信息的IP多播信息消息发送给多个边缘多播接收器，该IP多播信息消息还包括新对象开始指示(方框1120)。响应于可以如前所述显式地或固有地发信号通知的最后块信号，可以将所有块的大小累加在一起，以生成与分段相关联的对象大小指示(方框1122)。在一个示例实施例中，可以将对象大小指示发信号通知给多个边缘多播接收器，以指示分段边界划分(方框1124)。

图12是根据本专利申请的教导的各种步骤、方框或动作的流程图，其中可以将各种步骤、方框或动作组合或布置成用于促进低时延媒体摄取和分发系统和方法的其他方面的一个或多个实施例。图12所示的过程1200特别说明了可以由与内容源网络(CSN)节点(例如，媒体打包器/分段器)相关联地操作的LTE移动电信网络的BMSC节点执行的各种步骤、方框和/或动作。在方框1202中，经由HTTP CTE会话逐块地从CSN节点接收分段媒体流(例如，以多个比特率表示的形式)的每个分段的一个或多个片段，每个块具有块边界标记，其中片段在分段的整个数据在CSN节点处可用之前接收的。针对分段的每个片段生成FLUTE对象，以在广播会话中传输给一个或多个无线UE设备，其中FLUTE对象通过文件传递表(FDT)实例与分段的元数据相关联(方框1204)。在已经接收到分段的所有片段之后，可以在FDT实例中向多个无线UE设备提供最后块信号指示(方框1206)。只要媒体流可用于移动电信网络上的实况广播(例如在服务于订阅无线UE设备的广播区域上的广播/多播服务中)，就可以继续经由HTTP分块传递过程来接收分段媒体流的片段(方框1208)，

图13是根据本专利申请的教导的各种步骤、方框或动作的流程图，其中可以将各种步骤、方框或动作组合或布置成用于促进低时延媒体摄取和分发系统和方法的其他方面的一个或多个实施例。图13所示的过程1300特别说明了可以在IP多播接收器处执行的各种步骤、方框和/或动作，该IP多播接收器可以在IP多播分发树中的不同等级处(例如，在CDN边缘、驻地网关节点、STB、绑定或未绑定UE设备等处)位于同一位置或以其他方式集成。在一个实施例中，可以从IP多播发送器接收与实况媒体流的媒体数据的分发有关的IP多播信息消息(方框1302)。然后，一个或多个IP多播传输对象可以来自IP多播发送器，其中IP多播传输对象各自包括分段实况媒体流的分段的片段的媒体数据分组(方框1304)。在方框1306中，可以基于顺序有效载荷ID信息(例如，FEC ID)来对媒体数据分组进行排序。基于排序后的分组，可以生成、存储和/或标识媒体数据的分段和/或块(方框1308)。响应于从客户端设备接收到对实况媒体流的信道请求，可以生成具有适当元数据的一个或多个HTTP首部。此外，可以针对每个分段逐块地经由HTTP CTE会话将这些分段提供给客户端设备(方框1310)。如前所述，根据客户端侧集成，替代或附加实施例可以涉及直接文件访问API，出于本发明的目的，可以使用API来代替HTTP CTE下载/传递。

图14描绘了装置1400的框图，出于本专利申请的一个或多个实施例的目的，该装置1400可以配置成或布置成可操作以在IP多播流传输网络的一个或多个阶段部署的不同网元或节点。例如，熟练技术人员将认识到的是，根据本专利公开的实施例，装置1400可以配置或布置成网元或子系统，其充当用于促进一个或多个网络环境中的低时延媒体摄取和分发的内容源节点或IP多播发送器节点或IP多播接收器节点。因此，根据媒体通信网络的实现方式和/或网络架构，可以基于将源媒体馈送或其他内容源注入示例性部署的位置，按照适合于CDN/CSN和/或移动广播网络的多个分级层级(例如，在超级前端节点、区域前端节点、视频中心办公室节点、ABR起始服务器节点、CDN中的中央或区域或边缘分发节点、EPC网络的BMSC节点等处)处的操作的不同方式来配置装置1400。因此，可以提供合适的网络接口(例如，I/F 1414-1至1414-L)来实现与其他网络基础设施元素和数据库(例如，馈源、用于存储编码媒体片段的全局数据库、元数据/清单文件、DRM实体等)的通信。同样地，可以提供用于实现与一个或多个下游节点(例如，IP多播发送器/接收器、起始服务器、区域分发中心、其他中间网元等)的通信会话的接口1412-1至1412-K，来作为装置1400的一部分。可以提供一个或多个处理器1402作为合适的计算机架构的一部分，以实现对装置1400的整体控制，处理器1402可以被配置为执行存储在适当的存储器模块或方框(例如，持久性存储器1404)中的各种程序指令以及特定的程序指令1408(包括专用于编码/转码、媒体分段、片段生成和/或容器化、HTTP分块传递等的附加模块或方框)。作为说明，ABR编码/转码方框1410可操作以生成各种源媒体的多比特率表示的分段，对于这些分段，可以由清单生成器(未具体示出)生成合适的元数据文件。多重加密方框1416可操作以根据实现方式以多种DRM加密方案对内容进行加密。可以提供以DASH/ISOBMFF/CMAF和/或MPEG-TS格式对媒体打包的媒体打包方框1406，以与媒体分段器1413相结合地操作，实现各种级别粒度(例如，逐帧地构建)下的分段分割，由此达到本发明的一个或多个实施例的目的。在附加或替代布置中，还可以将内容推送策略管理模块、带宽和内容策略管理模块、程序权益等(共同地示为模块或方框1418)作为示例网络架构中后端IP多播ABR管理节点的一部分来提供。HTTP CTE模块1420可操作以提供HTTP分块数据传输/接收功能(取决于装置1400配置成哪个HTTP CTE端点)。以类似的方式，根据如上文详细所述的各种IP多播协议(例如，NORM、FCAST、FLUTE等)，IP多播服务器/接收器1422可以被包括在装置1400的布置或重新布置中，从而促进适于低时延片段分发的IP多播操作。如前所述，IP接收器功能可以在网关低层级下或甚至作为UE设备来集成，这具体取决于IP多播端点设置的位置。熟练技术人员将进一步认识到，在移动广播环境中，装置1400可以部署为BMSC节点，其具有合适的接口1414-1至1414-L(例如，通往其他EPS/EPC基础设施节点、CSN节点等)以及通往MBMS网关的合适的接口1412-1至1412-K，等等。

图15描绘了根据本专利公开的一个或多个实施例的配置用于执行各种客户端侧过程的示例性客户驻地设备(CPE)的框图。CPE设备1500通常表示上述一个或多个附图中所示的多个UE设备(例如，NXG STB、传统STB、到达设备等)，并且可以包括适当的硬件/软件组件和子系统，根据实现方式，出于本专利申请的目的，该硬件/软件组件和子系统被配置为结合媒体分段/流检索和呈现，执行与本地高速缓存访问、内容请求生成、元数据解析、HTTPCTE请求/响应处理或用于直接消费IP多播对象的API处理等有关的任何设备侧过程(单独地或其任何组合)。将一个或多个微控制器/处理器1502提供来用于客户端设备1500的整体控制以及用于执行嵌入到持久性存储器中的各种存储程序指令(例如，作为eMBMS客户端1513、CTE接收器1515和/或ABR流客户端应用1517等)，持久性存储器可以是与订户站1500的IP多播接收器1510一起操作的存储子系统1511的一部分。附图标记1502所指代的控制器/处理器复合体也可以代表与合适的视频及音频接口(未具体示出)相关联地操作的其他专用处理模块，比如，图形处理器、视频处理器、数字信号处理器(DSP)等。可以包括涉及调谐器、解调器、解扰器、MPEG/H.264/H.265解码器/多路复用器或者与其一起操作的适当接口(比如，网络I/F模块1504和1506)，以便处理和以接口方式连接经由DSL/CMTS网络1598或卫星网络1596接收的IP多播和其他内容。在将STB配置成示例性端点设备的情况下，还可以包括合适的解调器1517(例如，可以包括NTSC解调器和/或ATSC/PAL解调器等)。可以提供一个或多个媒体播放器1514来与客户端设备1500的其他子系统相结合地操作，以促进用户对媒体回放的控制，包括信道改变请求。可以将示例媒体播放器配置为基于已知或迄今未知的标准或规范，与一种或多种A/V编码器/解码器(codec)功能一起操作，所述标准或规范包括但不限于例如，运动图像专家组(MPEG)编解码器(MPEG、MPEG-2、MPEG-4等)、H.264编解码器、高效视频编码或HEVC(H.265)编解码器等。

根据设备配置，还可以提供其他I/O或接口，比如，显示接口1515、用于标识媒体服务信道的电子节目指南(EPG)1516(例如，在STB实现方式中)、触摸屏或小键盘接口1520、USB/HDMI端口1518、以太网I/F1508以及短程和广域无线连接接口1512。在STB实现方式中，可以包括硬盘驱动器(HDD)或DVR系统(未具体示出)，用于各种节目资产的本地存储。合适的电源方框1522可以包括AC/DC电源转换，以为设备1500提供电源。应当理解，订户设备1500的实际电源架构可以根据所采用的硬件平台而发生变化，例如取决于核心SoC(片上系统)、内存、模拟前端、特定平台中使用的模拟信号链组件和接口等。

基于前述内容，熟练技术人员将认识到，尽管将可靠的IP多播协议用于媒体分发，但本发明的实施例可以显著减少CDN或移动广播网络内部的传输延迟。关于移动媒体传递，应当理解的是，本文阐述的具体实施例有利地提供了一种用于在LTE广播部署中引入DASH/ISOBMFF输送的低时延解决方案。考虑到在媒体和工业方面以及从公共安全的角度来看都存在有这种强烈的需求，则可以实现在此上下文中的本发明的其他优点。在媒体领域，可以看到最终用户拥有时间或视觉参考点的用例场景不断增多，这就意味着最终用户将时延视为重要的属性，尤其是在实况媒体消费中。在“体育场内”中找到示例用例(用户自行生成的实况内容和潜在的虚拟/增强现实(VR/AR)用例)，其中可以有利地部署LTE广播网络中的分块FLUTE传递的实施例。在公共安全领域，在LTE广播的关键任务使用中，作为TETRA窄带替代的一部分，也预期有类似的低时延要求，因为近实时的情景视频用例是至关重要的。

熟练技术人员将认识到，根据本专利公开的附加或替代实施例中的网络功能虚拟化(NFV)架构，可以在虚拟化环境中构造各种装置、子系统、功能/应用和/或一个或多个网元和/或端点节点以及上面阐述的底层网络基础设施。例如，在本申请的示例性网络内执行的各种物理资源、数据库、服务、应用和功能(包括某些GW/UE/CPE功能)可以被提供为虚拟器件、机器或功能，其中经由合适的虚拟化层将资源和应用虚拟化为合适的虚拟网络功能(VNF)或虚拟网元(VNE)。包括计算资源、内存资源和网络基础设施资源的资源被虚拟化为相应的虚拟资源，其中虚拟计算资源、虚拟内存资源和虚拟网络资源可共同地操作以支持VNF层，而VNF层的总体管理和编排功能可以由虚拟化基础设施管理器(VIM)结合VNF管理器和NFV编排器来支持。运营支持系统(OSS)和/或业务支持系统(BSS)组件通常可以提供来处理网络级功能，比如，网络管理、故障管理、配置管理、服务管理和订户管理等，这些组件可以经由合适的接口与VNF层和NFV编排组件相接。

此外，本文所公开的示例性网络架构的至少一部分可以如上所述地进行虚拟化，并且可以在包括可配置虚拟资源的共享池的云计算环境中进行架构。各种硬件/软件(例如，ABR编码器、加密系统和方案、分段和/或分割机制、媒体资产打包/容器化、分段/清单数据库、IP多播功能等)以及NDC的平台和基础设施、RDC、起始服务器、MABR网元可以在具有多个实体的面向服务的架构(例如软件即服务(Saas)、平台即服务(Paas)、基础设施即服务(IaaS)等)中实现，所述多个实体提供本发明的示例性实施例的不同功能，其中一层或多层虚拟化环境可以在商业现货(COTS)硬件上实例化。技术人员还将认识到，这种云计算环境可以包括私有云、公共云、混合云、社区云、分布式云、多云和互联云(例如，“云中云”)等中的一种或多种。

在本公开的各种实施例的上述描述中，要理解本文使用的术语仅是为了描述具体实施例并且不是旨在限制本发明。除非另有限定，否则本文使用的所有术语(其包括技术和科学术语)具有与本发明所属领域内的普通技术人员通常所理解的相同的含义。将进一步理解的是，术语(例如在常用字典中定义的那些)应解释为具有与它们在该说明书和相关领域的上下文中的含义一致的含义，并且将不在本文明确地如此限定的理想化或过于正式的意义上解释。

至少一些示例性实施例在本文中参考计算机实现方法、装置(系统和/或设备)和/或计算机程序产品的框图和/或流程图图示来描述。应理解，框图和流程图图示的方框以及框图和流程图图示中的多个方框的组合可以由一个或多个计算机电路所执行的计算机程序指令实现。这样的计算机程序指令可以被提供给通用计算机电路、专用计算机电路的处理器电路和/或其他可编程数据处理电路来产生机器，使得指令经由计算机的处理器和/或其他可编程数据处理装置、变换和控制晶体管、存储在存储器位点中的值和这样的电路内的其他硬件组件执行来实现在框图和/或流程图单个或多个方框中规定的功能/动作，并且由此创建用于实现在框图和/或流程图方框中规定的功能/动作的工具(功能性)和/或结构。另外，计算机程序指令还可存储在有形的计算机可读介质中，其可以指示计算机或其他可编程数据处理装置采用具体方式起作用，使得存储在计算机可读存储介质中的指令产生制造品，其包括实现框图和/或流程图单个或多个方框中规定的功能/动作的指令。

如之前提到的，有形的非暂时性计算机可读介质可已包括电子、磁、光、电磁或半导体数据存储系统、装置或设备。计算机可读介质的更具体的示例将包括以下内容：便携式计算机软盘、随机存取存储器(RAM)电路、只读存储器(ROM)电路、可擦除可编程只读存储器(EPROM或闪速存储器)电路、便携式压缩盘只读存储器(CD-ROM)和便携式数字视频盘只读存储器(DVD/蓝光)。计算机程序指令还可以装载到或另外下载到计算机和/或其他可编程数据处理装置上以使要在计算机和/或其他可编程装置上执行的一系列操作步骤产生计算机实现的过程。因此，本发明的实施例可以体现为硬件和/或在处理器或控制器上运行的软件(包括固件、常驻软件、微代码等)，其可以被统称为“电路”、“模块”或其变型。此外，通过说明的方式，示例性处理单元可以包括通用处理器、专用处理器、常规处理器、数字信号处理器(DSP)、多个微处理器、与DSP核心相关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何其他类型的集成电路(IC)和/或状态机。可以理解，在某些实施例中，示例性处理器单元可以采用分布式处理。

此外，在至少一些附加或替代实现方式中，方框中描述的功能/动作可以未按照在流程图中示出的顺序发生。例如，相继示出的两个方框实际上可以大致上并发地执行，或者方框有时可以按相反顺序执行，这具体取决于所涉及的功能/动作。此外，流程图和/或框图的指定方框的功能性可以分成多个方框，和/或流程图和/或框图的两个或更多方框的功能性可以至少部分整合。此外，尽管一些图包括通信路径上的箭头来示出通信的主要方向，但应理解，通信可以在与所描绘的箭头相反的方向上发生。最后，可以在图示的方框之间增加/插入其他方框。

因此，应清楚理解的是，在本公开的附图部分中描绘的任何流程图中示出的动作、步骤、功能、组件或方框的顺序或序列可以被修改、改变、替换、自定义或者以其他方式在具体流程图内重新排列，包括删除或省略具体动作、步骤、功能、组件或方框。此外，具体流程图中示出的动作、步骤、功能、组件或方框可以与另一流程图中示出的动作、步骤、功能、组件或方框相互混合或者以其他方式相互排列或重新排列，以相对于一个或多个过程实现附加的变化、修改和配置，进而达成实践本专利公开的教导的目的。

尽管已经详细示出和描述各种实施例，但权利要求并不局限于任何具体实施例或示例。上面的具体实施部分中没有内容应解读为暗指了任何具体组件、元素、步骤、动作或功能是必不可少的，使得它必须被包括在权利要求的范围内。对采用单数的元素的引用没有旨在表示“一个且仅一个”，除非这样明确规定，相反却是表示“一个或多个”。与本领域内普通技术人员已知的上述实施例的元素等效的所有结构和功能通过引用的方式明确地结合于此并且意在被本权利要求涵盖。因此，本领域内技术人员将认识到，可以在下文所附权利要求的精神和范围内的各种修改和改动的情况下实践本文描述的示例性实施例。

Claims (52)

1.一种媒体摄取方法，包括：

由媒体打包器节点从进入的媒体流生成分段媒体流，其中每个分段包括多个片段，每个片段包括媒体数据的一个或多个帧；

识别出将使用IP多播来分发分段流，并将所述分段流与具体IP多播组相关联；

在所述媒体打包器节点与起始服务器节点之间发起HTTP分块传输编码CTE会话；

针对每个分段N，执行以下操作：

在分段N的整个媒体数据可用之前，经由所述HTTP CTE会话开始经由所述CTE会话将分段N的片段摄取到所述起始服务器节点，其中一个或多个块被提供来传输每个片段；以及

在已经传输了分段N的所有片段之后，将最后块信号发送给所述起始服务器节点。

2.根据权利要求1所述的媒体摄取方法，其中，所述起始服务器节点是与内容分发网络CDN相关联的起始服务器或移动电信网络的广播多播服务中心BMSC节点。

3.根据权利要求1或2所述的媒体摄取方法，其中，所述摄取包括推送机制、拉取机制或混合机制中的一种，所述拉取机制具体是触发拉取机制。

4.根据权利要求3所述的媒体摄取方法，其中，片段的摄取在使用推送机制时由所述媒体打包器节点发起，和/或在使用拉取机制时由所述起始服务器节点发起。

5.根据权利要求1至4中任一项所述的媒体摄取方法，还包括：在开始片段的摄取之前，向所述起始服务器节点发送指示，以指示提供来传输每个片段的块的数量。

6.根据权利要求1至5中任一项所述的媒体摄取方法，还包括：在开始片段的摄取之前，向所述起始服务器节点发送协议指示，以指示用于将媒体数据分发给与所述CDN相关联的一个或多个边缘节点的具体IP多播协议，所述具体IP多播协议具体是单向传输文件传递FLUTE协议、面向NACK的多播NORM协议、以及FCAST协议中的至少一项。

7.根据权利要求1至6中任一项所述的媒体摄取方法，其中，将所述实况媒体流编码为多个自适应比特率ABR表示，每个ABR表示被分段并使用对应的HTTP CTE会话上传到所述CDN起始服务器。

8.根据权利要求1至7中任一项所述的媒体摄取方法，其中，以容器格式来打包所述实况媒体流的分段，所述容器格式选自HTTP实况流传输HLS、HTTP动态流传输HDS、基于HTTP的动态自适应流传输DASH、HTTP平滑流传输HSS、通用媒体应用格式CMAF、ISO基本媒体文件格式ISOBMFF和MPEG-传输流TS格式。

9.根据权利要求1至8中任一项所述的媒体摄取方法，还包括：保持与所述起始服务器节点的持久HTTP连接，以实现所述HTTP CTE会话。

10.一种媒体打包器装置，包括：

至少一个网络接口，所述至少一个网络接口被配置为从一个或多个内容源接收实况媒体流；

所述媒体打包器装置被配置为：

-将接收到的实况媒体流分成多个分段，其中每个分段包括多个片段，每个片段包括媒体数据的一个或多个帧；

-识别出将使用IP多播来分发分段流，并将所述分段流与具体IP多播组相关联；

-发起与起始服务器节点的HTTP分块传输编码CTE会话；

-对于每个分段N，在分段N的整个媒体数据可用之前，经由所述CTE会话开始将分段N的片段摄取到所述起始服务器节点，其中一个或多个块被提供来传输每个片段；以及

-在已经传输了分段N的所有片段之后，将最后块信号发送给所述起始服务器节点。

11.根据权利要求10所述的媒体打包器装置，还被配置为包括用于以下操作的指令：在开始片段的摄取之前，向所述起始服务器节点生成指示，以指示提供来打包每个片段的块的数量。

12.根据权利要求10或11所述的媒体打包器装置，还被配置为：在开始片段的摄取之前，向所述起始服务器节点发送协议指示，以指示用于将媒体数据分发给与所述CDN相关联的一个或多个边缘节点的具体IP多播协议，所述协议指示被配置为指示单向传输文件传递FLUTE协议、面向NACK的多播NORM协议、以及FCAST协议中的至少一项。

13.根据权利要求10至12中任一项所述的媒体打包器装置，其中，所述摄取包括推送机制、触发拉取机制或混合机制中的一种。

14.一种媒体分发方法，包括：

在起始服务器节点处从媒体打包器节点接收消息，以开始与所述媒体打包器节点的HTTP分块传输编码CTE会话，所述消息包括对实况媒体流的媒体数据将被摄取到所述起始服务器节点的指示；

对于所述实况媒体流的每个分段N：

-从所述媒体打包器节点接收一个或多个HTTP首部；

-经由所述HTTP CTE会话逐块地接收分段的一个或多个片段，每个块具有块边界标记，其中每个片段包含媒体数据的一个或多个帧，且是在分段的整个媒体数据在所述媒体打包器节点处可用之前就接收的；

-为接收到的块生成传输对象，并将所述传输对象传输给多个接收器，所述传输对象具体是IP多播传输对象；以及

-在已经摄取分段的所有片段之后，从所述媒体打包器节点接收最后块信号。

15.根据权利要求14所述的媒体分发方法，其中，所述起始服务器节点是与内容分发网络CDN相关联的起始服务器或移动电信网络的广播多播服务中心BMSC节点。

16.根据权利要求14或15所述的媒体分发方法，其中，在一个或多个块中接收片段，并且将每个块或者携带同一片段的各部分的所有块作为一个传输对象传输给所述多个接收器中的一个或多个接收器。

17.根据权利要求14或15所述的媒体分发方法，其中，每个块在多个传输对象上分发。

18.根据权利要求14至17中任一项所述的媒体分发方法，其中，所述多个接收器包括内容数据网络CDN边缘节点和/或用户终端，所述CDN边缘节点具体是家庭网关。

19.根据权利要求14至18中任一项所述的媒体分发方法，还包括：在接收一个或多个片段之前，向所述多个接收器传输包括所述一个或多个HTTP首部的IP多播信息消息，所述IP多播信息消息还包括新传输对象开始指示。

20.根据权利要求14至19中任一项所述的媒体分发方法，还包括：响应于所述最后块信号来累加所有块的大小，以生成与片段相关联的对象大小指示，且将所述对象大小指示发信号通知给所述多个接收器。

21.根据权利要求14至20中任一项所述的媒体分发方法，还包括：在接收片段之前，接收对提供来传输每个片段的块的数量的指示。

22.根据权利要求14至21中任一项所述的媒体分发方法，还包括：在接收片段之前，例如从所述媒体打包器节点接收协议指示，所述协议指示规定用于将所述媒体数据分发给所述多个边缘多播接收器的具体IP多播协议，所述具体IP多播协议具体是单向传输文件传递FLUTE协议、面向NACK的多播NORM协议、以及FCAST协议中的至少一项。

23.根据权利要求22所述的媒体分发方法，其中，所述具体IP多播协议包括NORM协议，并且所述IP多播信息消息生成为NORM INFO消息，所述NORM INFO消息包括所述一个或多个HTTP首部以及与分段相关联的内容位置指针。

24.根据权利要求23所述的媒体分发方法，其中，仅针对分段的第一片段或块生成所述NORM INFO消息。

25.根据权利要求24所述的媒体分发方法，其中，经由NORM FEC对象传输信息EXT_FTI首部扩展来将片段或块大小发信号通知给所述多个接收器。

26.根据权利要求23所述的媒体分发方法，其中，针对每个NORM对象来传输所述NORMINFO消息，并且进一步地，其中至少与第一块相关联的所述NORM INFO消息包括所述一个或多个HTTP首部、所述内容位置指针和块大小。

27.根据权利要求26所述的媒体分发方法，其中，与分段的后续块相关联的所述NORMINFO消息包含所述内容位置指针、相应的块大小、以及可选地相应的块偏移量和/或块索引。

28.根据权利要求23所述的媒体分发方法，其中，针对每个NORM对象来传输所述NORMINFO消息，其中每个NORM对象是一个块或包括一个块，并且其中所述NORM INFO消息包含块信息，所述块信息具体是块索引和/或块偏移量。

29.根据权利要求14至28中任一项所述的媒体分发方法，其中，分段的第一块与传输对象ID TOI相关联，所述TOI针对分段的后续块递增1。

30.根据权利要求14至29中任一项所述的媒体分发方法，其中，将所述实况媒体流编码为多个自适应比特率ABR表示，每个ABR表示被分段并使用对应的HTTP CTE会话从所述媒体打包器节点上传。

31.根据权利要求14至30中任一项所述的媒体分发方法，其中，以容器格式来打包所述实况媒体流的分段，所述容器格式选自HTTP实况流传输HLS、HTTP动态流传输HDS、基于HTTP的动态自适应流传输DASH、HTTP平滑流传输HSS、通用媒体应用格式CMAF、ISO基本媒体文件格式ISOBMFF和MPEG-传输流TS格式。

32.根据权利要求14至31中任一项所述的媒体分发方法，还包括：保持与所述媒体打包器节点的持久HTTP连接，以实现所述HTTP CTE会话。

33.根据权利要求14至32中任一项所述的媒体分发方法，包括：针对分段的每个片段生成单向传输文件传递FLUTE对象，并在广播会话中将所述FLUTE对象传输给多个无线UE设备，其中所述FLUTE对象通过文件传递表FDT实例与分段的元数据相关联；以及

在已经接收到分段的所有片段之后，在所述FDT实例中向所述多个无线UE设备提供最后块信号指示。

34.根据权利要求33所述的媒体分发方法，其中，所述FDT实例包括Chunk-Length字段，所述Chunk-Length字段被配置为标识以分块传递方式来提供分段的媒体数据，并且具体地指示所述FLUTE对象的以字节为单位的大小。

35.一种起始服务器，包括：

HTTP分块传输编码CTE服务器和/或客户端；以及

IP多播发送器；

所述起始服务器被配置为执行以下操作：

从媒体打包器节点接收消息，以开始与所述媒体打包器节点的HTTP CTE会话，所述消息包括对以分块传递方式来提供分段实况媒体流的媒体数据的指示；

针对所述实况媒体流的每个分段N，从所述媒体打包器节点接收一个或多个HTTP首部；

经由所述HTTP CTE会话逐块地接收分段的一个或多个片段，每个块具有块边界标记，其中每个片段包含媒体数据的一个或多个帧，且是在分段的整个媒体数据在所述媒体打包器节点处可用之前就接收的；

为接收到的块生成传输对象，并将所述传输对象传输给多个接收器，所述传输对象具体是IP多播传输对象；以及

在已经摄取分段的所有片段之后，从所述媒体打包器节点接收最后块信号。

36.根据权利要求35所述的起始服务器，所述起始服务器是与内容分发网络CDN相关联的起始服务器或移动电信网络的广播多播服务中心BMSC节点。

37.根据权利要求35或36所述的起始服务器，还被配置为：在接收一个或多个片段之前，向所述多个接收器传输包括所述一个或多个HTTP首部的IP多播信息消息，所述IP多播信息消息还包括新传输对象开始指示。

38.根据权利要求35至37中任一项所述的起始服务器，还被配置为：响应于所述最后块信号来累加所有块的大小，以生成与片段相关联的对象大小指示，且将所述对象大小指示发信号通知给所述多个边缘多播接收器。

39.根据权利要求35至38中任一项所述的起始服务器，被配置为根据权利要求14至34中任一项所述的方法进行操作。

40.一种媒体传递方法，包括：

在IP多播接收器处，从IP多播发送器接收与实况媒体流的媒体数据的分发有关的IP多播信息消息；

从所述IP多播发送器接收IP多播传输对象，所述IP多播传输对象包括媒体数据分组；

基于顺序有效载荷ID信息，对所述媒体数据分组进行排序；

基于排序后的分组来生成媒体数据的块，每个块包括媒体数据的一个或多个帧；以及

响应于从客户端设备接收到对所述实况媒体流的信道请求，生成一个或多个HTTP首部，并经由HTTP分块传输编码CTE会话逐块地将所述块提供给所述客户端设备。

41.根据权利要求40所述的媒体传递方法，其中，根据可靠的IP多播协议接收所述传输对象，所述可靠的IP多播协议包括单向传输文件传递FLUTE协议、面向NACK的多播NORM协议、以及FCAST协议中的至少一项。

42.根据权利要求40或41所述的媒体传递方法，其中，所述一个或多个HTTP首部包括内容位置信息，并且在分段的整个媒体数据可用之前，将所述一个或多个HTTP首部提供给所述客户端设备。

43.一种与IP多播分发网络相关联的端点节点，包括IP多播接收器；

所述端点节点被配置为执行以下操作：

从IP多播发送器接收与实况媒体流的媒体数据的分发有关的IP多播信息消息；

从所述IP多播发送器接收IP多播传输对象，所述IP多播传输对象包括媒体数据分组；

基于顺序有效载荷ID信息，对所述媒体数据分组进行排序；

基于排序后的数据分组来生成媒体数据的块；以及

响应于从客户端接收到对所述实况媒体流的信道请求，将所述块提供给所述客户端设备。

44.根据权利要求43所述的端点节点，其中，根据可靠的IP多播协议接收所述IP多播传输对象，所述可靠的IP多播协议包括单向传输文件传递FLUTE协议、面向NACK的多播NORM协议、以及FCAST协议中的至少一项。

45.根据权利要求43或44所述的端点节点，其中，所述IP多播接收器与被配置为用作所述端点节点的客户驻地网关、机顶盒STB和用户设备UE设备中的至少一个集成。

46.根据权利要求43至45中任一项所述的端点节点，其中，所述IP多播接收器与无线用户设备UE设备集成，所述无线UE设备包括：

HTTP分块传输编码CTE服务器或代理；

演进多媒体广播/多播服务eMBMS客户端，所述eMBMS客户端包括所述IP多播接收器和HTTP CTE接收器；

所述UE设备被配置为：

在所述IP多播接收器处，从与移动电信网络的广播多播服务中心BMSC节点相关联的IP多播发送器接收所述IP多播信息消息；

在所述IP多播接收器处，接收所述IP多播传输对象，作为多个单向传输文件传递FLUTE对象，每个对象包含所述分段媒体流中的分段的片段的媒体数据分组；

基于所述排序后的分组，创建媒体数据的块；以及

响应于从所述HTTP CTE接收器接收到请求，生成一个或多个HTTP首部并由所述HTTPCTE服务器经由HTTP CTE会话逐块地提供片段，其中所述块被提供给媒体播放器缓冲区，以在所述无线UE设备的显示器处呈现。

47.根据权利要求46所述的端点节点，其中，将所述一个或多个HTTP首部与内容位置信息一起发送，并且在分段的整个媒体数据可用之前，将所述一个或多个HTTP首部提供给所述eMBMS客户端。

48.根据权利要求46或47所述的端点节点，其中，所述分段媒体流包括基于HTTP的动态自适应流传输DASH流，并且程序指令还包括用于经由媒体表示描述MPD文件将可用性时间偏移量ATO信息提供给所述HTTP CTE接收器的指令。

49.根据权利要求46至48中任一项所述的端点节点，其中，所述IP多播接收器被配置为在分段的所有片段的传输结束时在来自所述BMSC节点的文件传递表FDT实例中接收最后块指示信号，并且程序指令还包括用于基于所述最后块指示信号来识别分段边界信息的指令。

50.根据权利要求46至49中任一项所述的端点节点，还包括与长期演进LTE网络一起操作的无线电接口，并且其中在广播会话中接收所述FLUTE对象，所述广播会话在以下至少一个中实现：所述LTE网络的多个eNB小区上的同步单频网络SFN，以及所述LTE网络中的单小区点对多点PTM传输。

51.一种媒体流传输网络，包括：

媒体摄取网络部分，所述媒体摄取网络部分被配置为使用HTTP分块传输编码CTE来提供分段实况媒体流的媒体片段的低时延上传，其中分段的一个或多个片段在分段的整个媒体数据变得可用之前被逐块地摄取；

耦合到所述媒体摄取网络部分的互联网协议IP多播分发网络部分，所述IP多播分发网络部分被配置为使用IP多播协议来将分块媒体数据分发给一个或多个IP多播接收者；以及

传递网络部分，所述传递网络部分被配置为在与服务IP多播接收者的HTTP CTE下载会话中向客户端传递所述媒体数据。

52.根据权利要求51所述的媒体流传输网络，包括以下中的至少一个：

-根据权利要求10至13中任一项所述的媒体打包器装置；

-根据权利要求35至39中任一项所述的起始服务器；

-根据权利要求43至50中任一项所述的端点节点。

Images