CN102037678B - 分发在多个接收机处可用的内容的映射图的系统和方法 - Google Patents

Abstract

本发明涉及一种内容服务器设备以及一种内容估计时间设备以及一种在所述设备处以鲁棒的模式发送内容的方法。具体地，本发明涉及一种在对等客户端处从服务器接收内容的方法，所述方法包括以下步骤：以组播模式从服务器接收内容；向服务器指示已正确接收的内容；以组播模式从服务器接收对每个对等端处可用的内容加以指示的内容可用性映射图；以及向内容可用性映射图中的指示的对等端请求丢失的内容。

Description

分发在多个接收机处可用的内容的映射图的系统和方法

技术领域

本发明总体涉及视频点播的分发，具体涉及一种向多个接收机分发视频点播的方法。

背景技术

本部分旨在向读者介绍所描述的和/或权利要求中要求保护的本发明的各方面。相信这些讨论有助于为读者提供背景信息以便于更好地理解本发明的各方面。因此，应理解，这些陈述应在此范围内阅读，而不是作为对现有技术的认可。

DVB-IP内容下载系统特别工作组负责：基于通过受控IP网络(如，在互联网服务提供商控制下的DSL网络)向诸如机顶盒或住宅家用网关等家庭网络设备的本地存储装置的内容下载，来指定视频点播的标准。在来自DVB-CM IPTV group的CM-IPTV0102r15“CommercialRequirements for downloading IPTV content and management of localstorage”中编辑了CDS商业需求。在DVB-IPTV规范中结合了CDS规范，TS 102034v1.4.1文献的下一个ETSI公开之前，DVB-IPTV规范目前作为DVB蓝皮书文献A086Rev.7September 2008可用。

CDS规范的主要特性是：

-CDS规范提供了两个VOD服务模式：

-推送服务模式，由服务提供商发起并且基于全部内容的下载；专用于巨作(blockbuster)

-拉动服务模式，基于用户发起的内容下载；专用于除了巨作以外的所有内容

-这两种服务模式都依赖于三种基本内容下载机制：

-组播，使用如在RFC 3926中定义的单方向传输协议文件传递(FLUTE)

-单播，使用HTTP协议

-对等，标记为P2P，使用专用协议，所述专用协议基于：将HTTP请求重定向至若干对等客户端，以便在这些对等客户端上分发内容下载。

-每个服务可以使用任何下载机制或下载机制的组合。例如，通过使用组播协议来向客户端设备推送内容并使用P2P协议来修复组播分发期间的误差，可以实现推送服务。通过在针对一个内容能够的用户请求数目或多或少显著增加的情况下，使用可能向组播或P2P传递重定向的HTTP协议，可以实现拉动服务。

-SD&S/BCG用于按照服务类型和协议来通告可用内容以下载这些可用内容。SD&S/BCG支持基于单播(HTTP)或组播(DVB-STP)协议的通告。在DVB蓝皮书文献A086Rev.7September 2008中描述了允许CDS服务通告的SD&S/BCG规范。

CDS规范提出了推送服务模式，所述推送服务模式基于向客户端本地存储装置先行下载全部内容。这种服务模式非常适于巨作的分发，因为这种服务模式允许用户即时访问内容。然而这种服务模式对于设备存储装置的使用也有限制，因为全部内容被复制在每个客户端上。另一方面，CDS还提出了没有任何先行内容下载的拉动服务模式。拉动服务用于所有内容的分发。然而在用户可以访问之前，巨作需要下载延迟时间。

采用先行有目标内容推送策略的P2P实质上使用单播协议来先行向网络上的对等端分发内容片段。此外，在查找可以为请求内容服务的对等端的阶段，而不是在从这些对等端下载请求内容的阶段，许多P2P协议使用单播协议。有时单播协议的使用完全适用，这是因为诸如组播协议等其他协议不可用(例如，在诸如互联网等不受控制的环境中)，或者因为在其他情况下，解决方案的主要设计约束之一是对等端存储装置的优化，其中对等存储装置的优化产生了一种解决方案，在该解决方案中，每个对等端存储不同内容片段，从而组播协议的使用效率不高。

发明内容

本发明试图通过提供一种分发内容可用性映射图的方法来克服与现有内容分发有关的问题中的至少一些问题。

本发明涉及一种在对等客户端处从服务器接收内容的方法，所述方法包括以下步骤：以组播模式从服务器接收内容；向服务器指示已正确接收的内容；以组播模式从服务器接收对每个对等端处可用的内容加以指示的内容可用性映射图；以及向所述内容可用性映射图中的指示的对等端请求丢失的内容。

使接收机知道对等接收机处可用的内容，以便于从对等接收机恢复丢失的内容。接收机不需要向服务器请求丢失的文件。接收机直接询问正确的对等端而不询问服务器。

CDS规范支持将组播协议和P2P协议相组合的可能性。这种组合用于基于“采用先行有目标内容推送的P2P”分发模式来高效地实现CDS服务。这种服务专用于中等流行的内容的分发。这允许服务运营商通过更好地利用客户端本地存储装置来提供更多的内容。当运营商提供包括一个或多个内容的服务时，这对于CDS布局的成功而言是一个重要争议点。

本发明的另一方是一种包括程序代码指令的计算机程序产品，所述程序代码指令用于当在计算机上执行所述程序时执行根据本发明的方法步骤。“计算机程序产品”是指计算机程序支持，可以不仅在于包含程序的存储空间(如，磁盘和磁带)，还在于诸如电信号和光信号等信号。

以下阐述了在范围上与所公开的实施例相同的特定方面。应理解，这些方面仅用于为读者提供本发明可能采用的特定形式的简要概括，这些方面不旨限制本发明的范围。实际上，本发明可以包含没有在下文中阐述的各个方面。

附图说明

参考附图，以非限制性方式，通过以下实施例和执行示例，将更好地理解和说明本发明，附图中：

-图1示出了符合实施例的网络体系；

-图2示出了根据实施例的对等端处可用的内容；以及

-图3示出了根据实施例的按照本地分区对不同类型客户端设备的重新划分。

在图1至3中，所示模块是纯功能实体，不必与物理上分离的实体相对应。即，这些模块可以以硬件或软件的形式开发，或者可以实现在一个或多个集成电路中。

具体实施方式

示例实施例在CDS和FLUTE的架构的范围内，然而本发明不限于这种具体环境，而是可以应用于其他架构的范围内，在所述其他架构中，向多个接收机分发内容，并且向所有接收机分发每个接收机处可用的内容的映射图。那么这些接收机可以接收来自对等端接收机的丢失内容。

本发明的实施例在符合DVB-IP/CDS需求的内容下载系统的范围内。网络体系架构基于如图1所示的受控运营商网络。该网络体系架构包括：

-组播内容服务器1，能够向客户端设备有效地推送内容，

-控制服务器3，为客户端设备提供远程管理和报告功能，

-通告服务器2，向客户端信号通知服务传递的细节，

-多个客户端设备11、12、13，能够在所述多个客户端设备11、12、13之中共同分发内容并为用户提供对运营商服务的访问。

运营商注册了客户端并为每个客户端分配“Client-Type”。客户端类型的数目限于“n”。这种分配由在控制服务器与客户端之间实现的运营商远程管理系统来执行。

在这种情况下，“采用先行有目标内容推送的P2P”传递按以下步骤进行：

步骤1：内容片段的先行推送

在步骤1.a，将该先行推送的每个内容分成如客户端类型一样多的片段，使用组播服务器在具有相同“Client-Type”的所有客户端中推送每个片段。可以使用仅一个组播FLUTE会话来实现这种“有目标推送”，以向所有类型的客户端传输所有内容片段，或按照客户端类型使用一个组播FLUTE会话来实现这种“有目标推送”。

每个组播会话承载一些FLUTE文件传递表实例，标记为如在RFC3926中指示的FLUTE FDT，以描述所传送的内容片段。按照“Content-Fragment-URI”在FDT实例的“Content_Location”字段中标识每个内容片段。在以下表1中给出了这种FDT实例的示例。

如在专利申请EP1901525中描述的并且结合组播传递和P2P传递的策略可以用于使这种先行内容片段推送可靠。表1指示了对组播会话中传送的内容片段加以描述的FDT实例。

表1

在步骤1.b，在下载内容片段之前，使用通告机制向客户端推送用于该客户端根据该客户端的“Client-Type”来访问组播会话中的内容的详细信息。在以下表2中指示了这种通告数据的示例，表2示出了“有目标推送”服务的SD&S/BCG通告。通过SD&S/BCG协议来传送这种通告。该示例基于使用FLUTE组播传递的CDS服务类型的通告，其中，“Client-Type”字段允许客户端确定该客户端必须下载的内容片段。在当前CDS规范中描述了该表的其他字段。

表2

在步骤1.c，当成功接收到与客户端类型相对应的片段时，对于“有目标推送”会话的所有内容项，每个客户端必须向控制服务器报告良好地接收到这些片段。使用倒计时在报告过程中将控制服务器的负载在时间上展开。采用这种信息，控制服务器能够识别客户端(利用诸如客户端的IP地址和Client-Type等参数)。然后控制服务器知道客户端已下载了哪些内容片段(Content-Fragment-URI)。

在以下表3中给出了内容片段接收报告消息的示例。该消息非常接近在CDS规范中规定的报告消息。在该规范中描述了该表中字段“Multicast-Delivery-Session-List”和“Recovery-Delivery-Server-Source-List”的使用。

在备选的基于多个服务器的内容传递的情况下，server_source_ID字段指示哪个服务器下载了内容。

表3

步骤2：“内容可用件映射图”的先行推送

在步骤2.a，一旦客户端已全部下载了与这些客户端的“Client-Type”相对应的内容片段并报告了这些内容片段的成功接收，运营商就发起另一组播会话或使用先前的组播会话来向每个客户端推送对所有其他客户端中推送的内容片段的可用性加以描述的信息。这些内容可用性信息可以由控制服务器来构建，所述控制服务器借助于报告过程而具有所有相关信息。一旦构建，这些内容可用性信息就被发送至组播服务器，然后被推送至客户端设备。

在以下表4中给出了这种内容可用性信息的示例。该表称作“CAM：内容可用性映射图”。该表描述了其片段已被已先行下载的每个内容。对于每个内容，表包括对等端列表(“Peer-List”)，该对等端列表标识了已下载内容片段的对等端。将该对等端列表分成对等端子集(“Peer-Subset”)，所述对等端子集存储相同的内容片段。在每个对等端子集中，所下载的内容片段由“Available-Chunk-List”字段来标识，所述“Available-Chunk-List”字段给出了可用内容的组块。在表的“Content-Map”字段中给出了每个内容项的组块的大小。

内容片段和内容组块通常是不同的实体，它们之间的关系是先验已知的(每片段的组块数目、最后一个片段中的组块数目……)。内容片段专用于通过组播传递的内容分发，而内容组块专用于通过P2P传递的内容分发。内容片段的大小通常超过内容组块的大小，内容片段是可以连续或不连续的某些内容组块的拼接。

表4

在步骤2.b，通过在先前的SD&S/BCG通告中添加如以下表5描述的组播会话通告，来通告用于推送CAM的组播会话。在该通告中没有“Client-Type”字段，这意味着每个客户端设备都必须下载该“ContentAvailability Map”而不管该客户端的“Client-Type”是什么。

表5

在以下表6中描述了在组播会话中传送的并且描述了“ContentAvailability Map”的FLUTE FDT：

表6

步骤3：内容请求

在步骤3.a，一旦客户端设备接收到了“Content Availability Map”，该客户端就向用户提出内容，用户可以请求下载内容之一。

在步骤3.b，由于发出请求的客户端设备不存储所有需要的内容片段，所以该发出请求的客户端需要取回其他客户端设备中存储的丢失片段。为了标识这些对等客户端设备，发出请求的客户端直接使用“Content AvailabilityMap”而不需要询问中央服务器或其他对等端。采用该表，发出请求的客户端可以精确地知道该客户端先前存储的内容组块，从而知道可以为丢失的内容组块服务的对等端的列表。

图2示出了实施例，其中图2示出了在推送内容片段和ContentAvailability Map(CAM)之后的对等端状态。想要下载内容“B”的客户端设备“Peer 1b”使用“Content Availability Map”来：

-确定该客户端已经下载的内容组块(Chk2，Chk3)，

-确定该客户端必须下载的内容组块(Chk0，Chk1，Chk4...Chk11)

-选择用于下载这些内容组块的对等端(例如，P0a→Chk0，P0b→Chk1，P2a→Chk4...，P5b→Chk11)

为了在DSL网络中的DSLAM下本地地且可能地限制P2P交换，改进了实施例。

“Content Availability Map”对于每个本地区域而不同。向由“Client-Locality-Id”标识的所有客户端设备本地推送“Local ContentAvailability Map”(LCAM)。该标识符由运营商远程系统控制来管理，管理方式与“Client-Type”标识符相同。图3示出了按照本地分区(“Client-Locality-Id”)对不同类型(“Client-Type”)的客户端设备的重新划分。

一种便于由控制服务器构建“LCAM”的方式是，如以下表中所描述的，在内容片段接收报告消息中添加本地性标识符(“Client-Locality-Id”)。

表7

然后利用有目标组播会话来本地推送每个“Local ContentAvailability Map”，所述有目标组播会话与用于在客户端设备中推送内容片段有目标组播会话相同，但是基于“Client-Locality-Id”标识符。

在这种情况下，在以下表中描述了用于推送“Local ContentAvailability Map”的组播会话通告的示例：

表8

在表6中描述了在组播会话中传送的并且描述了“Local ContentAvailability Map”对象的FLUTE FDT，其中，“Content-Location”被设置为“LCAM-URI”。

根据实施例的第一备选方案，先验地准备CAM并在FLUTE会话中与内容片段一起发送该CAM。网络运营商熟知该网络运营商的网络拓扑。该网络运营商能够基于该拓扑来构建理论上理想的CAM而不等待来自该网络运营商的客户端的接收报告消息。因此，可以在单个FLUTE会话中与所有对应内容片段一起推送该CAM。

该变型实施例仅使用经由SD&S的单个通告和单个FLUTE会话(而不是两个)。向集中控制服务器的客户端接收报告变得对于确保P2P下载来说无用。如果需要报告用于其他用途，则在CDS中存在完整轮询机制，使得仅客户端的子集向集中控制服务器报告成功接收。

根据实施例的第二备选方式，引入对等端之间的邻近信息。“Client-Locality-Id”是对等端(即，相同本地性的对等端)列表的描述的一部分，对等端可以识别该对等端的相邻对等端并仅与这些相邻对等端联系以下载所有其他片段。

可以拓宽相邻对等端的概念，以创建区域，附近本地性列表。如以下表8所示，将这些新字段插入CAM中：

表8

区域的使用用于：更接近网络拓扑，以及在必要的情况下(在客户端在连接或CPU负载等方面不可用的情况下)，使客户端设备可以按照从近到远的分级方式访问客户端。

以一般方式，这种分级可以具有多于两个级别，可以成为在由运营商配置的级别如同树一样表示网络拓扑抽象的数据结构。在表8中，可以将“Region”字段重命名为“Region-Level-1”。

CAM可以扩展为包含每个本地性、上述所有定性数据(用于下载和用于上载的平均比特率容量)、精确信息的特性，使得客户端可以在必要时选择最佳的本地性。

可以周期地上载CAM，以反映网络上下载进程的状态。运营商可以选择更新级别(在组块级别精确地，或在片段级别宏观地(仅针对具有完整片段的对等端))，并根据CAM的连接状态向CAM添加对等端/从CAM去除对等端。不管原始CAM是否是理论上的，都可以应用这种更新。

可以独立地或以任何合适组合的形式提供说明书、权利要求和附图中公开的参考。在合适的情况下，可以以硬件、软件或二者的组合来实现特征。

这里对“一个实施例”或“实施例”的引用意味着结合实施例而描述的具体特征、结构或特性可以包含在本发明的至少一个实现方式中。在说明书中不同地方出现的短语“在一个实施例中”不必须是指相同的实施例，也不必须是指分开的实施例或必须与其他实施例互不相同的备选实施例。

权利要求中出现的附图标记仅用于说明，不应起到限制权利要求的范围的作用。

Claims (7)

1.一种在对等客户端(11，12，13)处接收内容的方法，所述方法包括以下步骤：

-以组播模式从第一服务器(1)接收(S1)多个内容；

-向第二服务器(3)指示(S2)已正确接收的内容；

-以组播模式从第三服务器(2)按照本地区域接收(S3)对每个其他对等客户端处可用的内容加以指示的内容可用性映射图，其中对于每个本地区域所述内容可用性映射图不同，并且以组播方式将所述内容可用性映射图本地推送到由本地区域的本地性标识符标识的本地区域的所有对等客户端；以及

-根据所述内容可用性映射图中的指示，向可用内容所在的对等客户端(11，12，13)之一请求(S4)丢失的内容。

2.根据权利要求1所述的方法，所述对等客户端向服务器指示所述对等客户端的定位。

3.根据权利要求2所述的方法，其中，所述内容可用性映射图指示每个所述其他对等客户端的定位。

4.根据权利要求3所述的方法，其中，所述对等客户端按照从近处对等客户端到远处对等客户端的分级方式向所述对等客户端之一请求内容。

5.根据权利要求1所述的方法，包括向所述第二服务器指示已从中接收到所述多个内容的第一服务器的标识符的步骤。

6.根据权利要求1所述的方法，其中，所述多个内容是使用单方向传输协议文件传递FLUTE协议接收的。

7.根据权利要求1所述的方法，其中，所述内容可用性映射图是使用FLUTE协议接收的。

Images