CN102215435A

CN102215435A - 一种数字电视推送点播系统及其推送点播方法

Info

Publication number: CN102215435A
Application number: CN2010101407905A
Authority: CN
Inventors: 黄雷; 杜俊峰
Original assignee: CATON TECHNOLOGY (BEIJING) Co Ltd
Current assignee: Ever network technology (Shanghai) Co., Ltd.
Priority date: 2010-04-02
Filing date: 2010-04-02
Publication date: 2011-10-12
Anticipated expiration: 2030-04-02
Also published as: CN102215435B

Abstract

本发明提供一种数字电视推送点播系统，包括头端系统和终端系统，所述头端系统和终端系统之间具有广播链路，所述头端和终端系统均接入计算机网络中，所述头端系统用于通过广播链路推送文件到终端系统，所述终端系统用于接收头端系统所推送的文件，并通过所述计算机网络获取所接收的推送文件中的遗失数据包。本发明还提供了相应的数字电视推送点播方法。本发明占用的额外广播带宽较小，节省了有限的卫星、有线或者地面广播带宽资源。本发明对互联网资源的额外占用非常有限，因此能够有效地提高PUSH-VOD技术总的网络资源利用率。本发明能够提升用户体验品质。

Description

一种数字电视推送点播系统及其推送点播方法

技术领域

本发明涉及数字电视广播技术领域，具体来说，本发明涉及一种数字电视推送点播系统及其推送点播方法。

背景技术

数字电视领域推送点播技术(PUSH-VOD技术)是一种使用少部分的资源进行广播预推服务，在非高峰时段把用户关心的热点资源进行推送的技术。它可用于解决传统VOD技术大量占用带宽资源，头端部署非常昂贵且浪费等问题。PUSH-VOD技术是在一个集中的时段以广播的形式，将大量的音视频、文件、图片等各种数据内容同时推送到所有用户的本地终端内，从而使得用户实际进行点播操作时系统只要在终端本地进行处理，这样既可为用户提供个性化大容量的点播服务，又避免了传统VOD大量占用网络资源的问题。PUSH-VOD既适用于单向传输网络也适应用于双向传输网络(传统VOD只适用于双向传输网络)，因此具有广阔的市场前景。

图1示出了一种PUSH-VOD系统的应用网络环境，它是典型的卫星电视的组网方式，是一个完全单向的网络。在这种网络里，数据只能单一的从头端传递到终端，终端没有任何方法向头端回传数据。类似地，PUSH-VOD系统还应用于传统有线电视或者地面电视广播等其它单向网络中。为了通过各种不同的链路广播播出，PUSH-VOD的数据是面向数据包的。和所有以广播形式发送的技术一样，PUSH-VOD技术中核心技术之一是解决因链路或者传输过程中的各种原因而造成的终端丢包、错包问题。丢失的包和无法恢复而丢弃的错包，对于终端而言都是遗失数据包(Lost Packets)。目前，为解决遗失数据包的问题，传统PUSH-VOD技术所通行的做法是：由PUSH-VOD系统的头端反复推送同一份文件，终端在接收到重复推送的文件时，找出之前接收到的原文件中的遗失数据包进行补包处理，从而保证数据的完整性。对于正常的链路条件，二次推送可以使平均接受率达到99％。但为了逼近于100％的理想接收率，为了更好的用户体验，必须要推送更多次数。而目前的PUSH-VOD系统大都推送4次。随着PUSH-VOD技术的发展和推广，PUSH-VOD技术也开始应用到各种双向网络中，然而，在新的应用环境中，传统PUSH-VOD系统的补包机制(即上述解决遗失数据包的问题机制)的缺陷开始凸现。在传统的PUSH-VOD系统中，需要对全部内容进行多次重复推送才能确保终端较高的平均接受率，因此需要占用大量的带宽资源，导致效率低下。所以，迫切需要一种既能确保终端较高的平均接受率，又能提高带宽资源利用效率的使用于双向网络的PUSH-VOD技术。

发明内容

本发明的目的是提供一种占用带宽较少的数字电视推送点播(即PUSH-VOD)系统及方法。

为实现上述发明目的，本发明提供了一种数字电视推送点播系统，包括头端系统和终端系统，所述头端系统用于通过广播链路推送文件到终端系统，所述终端系统用于接收头端系统所推送的文件，并通过P2P机制获取所接收的推送文件中的遗失数据包。

其中，所述头端系统包括头端推送服务器和种子服务器，所述终端系统包括终端接收模块和终端补包模块；

所述头端推送服务器用于通过广播链路推送推送信息文件和内容文件；所述推送信息文件含有各内容文件的P2P属性信息，用于标记各内容文件当前所处状态，所述内容文件当前所处状态的类型包括非P2P补包状态和P2P补包状态；

所述种子服务器用于保存所述内容文件的副本和生成所述内容文件的种子文件，并为终端提供P2P服务；

所述终端接收模块用于接收头端推送服务器所推送的文件；

所述终端补包模块用于统计所接收的内容文件中的遗失数据包，并在该内容文件处于P2P补包状态时通过P2P机制获取所述遗失数据包。

其中，所述头端推送服务器还用于推送内容文件所对应的种子文件。

其中，所述数字电视推送点播系统还包括用于提供P2P服务的tracker服务器。

其中，所述头端系统还包括头端统计服务器，用于重复推送遗失较为密集的数据包；所述终端补包模块还包括终端补包反馈子模块，用于向头端统计服务器反馈该终端的遗失数据包信息。

本发明还提供了一种利用上述数字电视推送点播系统的数字电视推送点播方法，包括下列步骤：

1)头端系统通过广播链路推送文件到终端系统；

2)终端系统接收头端系统所推送的文件，并通过P2P机制获取所接收的推送文件中的遗失数据包。

其中，所述步骤1)包括下列子步骤：

11)将待推送的内容文件的副本复制到种子服务器上，种子服务器生成所述内容文件的种子文件；

12)头端系统通过广播链路推送推送信息文件和内容文件；所述推送信息文件含有各内容文件的P2P属性信息，用于标记各内容文件当前所处状态，所述内容文件当前所处状态的类型包括非P2P补包状态、P2P补包状态；

所述步骤2)包括下列子步骤：

21)终端系统接收头端系统所推送的推送信息文件和内容文件；

22)终端系统统计所接收的内容文件中的遗失数据包；

23)当所接收到的推送信息文件中标记某一内容文件处于P2P补包状态时，终端系统将该内容文件加入P2P补包列表，并通过P2P机制获取该内容文件的遗失数据包；

24)当所接收到的推送信息文件中标记某一内容文件处于非P2P补包状态时，终端停止通过P2P机制获取该内容文件的遗失数据包。

其中，所述步骤12)还包括：所述头端系统还通过广播链路推送种子文件；

所述步骤21)还包括：所述终端系统接收头端系统所推送的种子文件，当接收到的头端系统所推送的种子文件不完整时，终端系统再通过P2P机制获取种子文件。

其中，所述步骤12)中，所述内容文件当前所处状态的类型还包括等待反馈状态；

所述步骤22)包括下列子步骤：

221)终端系统统计本地所接收的内容文件中的遗失数据包信息；

222)当所接收到的推送信息文件中标记某一内容文件处于等待反馈状态时，终端系统将该内容文件在本地的遗失数据包信息反馈给头端系统；

223)头端系统根据各终端反馈的遗失数据包信息，选出遗失最密集的遗失数据包进行推送；

224)终端系统再次统计本地的遗失数据包信息以便使用P2P机制进行补包。

其中，所述步骤222)中，反馈遗失数据包信息的终端系统限于被头端系统按一定比例选定的具有代表性的终端系统；各终端系统向头端系统进行反馈的时间段分散设置。

与现有技术相比，本发明具有下列技术效果：

1、占用的额外广播带宽较小，节省了有限的卫星、有线或者地面广播带宽资源。

2、本发明对互联网资源的额外占用非常有限，因此能够有效地提高PUSH-VOD技术总的网络资源利用率。

3、本发明能够提升用户体验品质。

附图说明

图1示出了一个典型的卫星电视单向网络结构的示意图；

图2示出了本发明中的协议文件每个分段发送时的组包格式；

图3示出了本发明一个实施例中的可以连接互联网的卫星电视系统的系统结构示意图；

图4示出了本发明使用了P2P补包技术的一个实施例中的逻辑框图；

图5示出了本发明使用了终端反馈技术的另一个实施例的逻辑框图；

图6示出了本发明使用了终端反馈技术的另一个实施例中的反馈数据包的组包格式；

图7示出了本发明使用了P2P补包技术的一个实施例中推送信息文件的格式；

图8示出了本发明使用了P2P补包技术的一个实施例中文件ID空间的分配情况示意图；

图9示出了本发明使用了终端反馈技术的另一个实施例中的终端反馈的协议交互过程示意图；

图10示出了本发明使用了终端反馈技术的另一个实施例中的头端推送计划示意图。

具体实施方式

本发明的网络环境必须是双向的网络，具体来说，由头端向终端广播(推送)所使用的链路是可以发送广播的卫星、有线、微波、地面广播等类型的链路，同时，终端和头端还需要直接或者间接地接入国际互联网，从而形成双向网络。

首先，围绕数据包的丢失和补包来分析。由于广播内容传输面向数据包，丢包率为遗失数据包数量与数据包总数的比率，即：

Lost_Packet_ratio＝Lost_Packets/Total_Packets*100％。

而终端出于效率的考虑，通常会把若干数据包中内容合并在一起进行写入(指从内存存储到硬盘的过程)和追踪，合并的一组数据包称为一个数据块(Block)。在实际的推送系统中，组成一个块的任一数据包丢失了，那整个块就作废了。因此需要统计块丢失率，即：

Lost_Block_ratio＝Lost_Blocks/Total_Blocks*100％

本发明中对接收率的定义是正确接收的数据块数量与总数据块数量的比率。即：

RX_Ratio＝1-Lost_Block_ratio

通过现有推送系统运行中产生的大量数据，可以得出推送点播系统中数据包/数据块丢失的一些规律：

R1，数据包错误或者丢失常常在稳定接收一段数据后连续出现，比如连续完整接收500个数据包后连续丢失2、3个数据包。这一点为以数据块(多个数据包)作为追踪记录的基本单位提供了可能。

R2，地理相邻的一个区域内的所有终端，它们的接受率基本是相同的，并且丢包的序号也非常相似。

R 3，从整个系统而言，其每一次推送的平均接收率也大致是相同的。假设这个值是95％，那么也就是说每发出100个数据块，平均每个终端会丢失5个。这个值称为系统的固有接收率。

R4，假设系统的固有接收率是RR_1，第二次全部推送后能达到的接收率RR_2≈RR_1+(1-RR_1)*RR_1＝2RR_1-RR_1²。所以如果RR_1＝95％，RR_2能达到99.75％；RR_1＝80％(在实践上已经属于链路条件比较差的情况)，RR_2也能达到96％。

基于以上的分析，本发明设计了基于P2P机制补包的PUSH-VOD系统，以有效地利用双向网络中的反向链路，降低对PUSH-VOD系统中昂贵的广播信道的占用。

下面结合附图和具体实施例对本发明作进一步地描述：

实施例1

根据本发明的实施例1，提供了一种PUSH-VOD系统。图3示出了该实施例的PUSH-VOD系统的实体结构，该PUSH-VOD系统包括头端系统、终端系统和补包辅助设备(即图3中的第二边缘服务器)。头端系统包括中央服务器、复用器、调制器和第一边缘服务器。终端系统包括天线接收器、机顶盒和显示设备(如电视机)。中央服务器与机顶盒之间具有广播链路(在本实施例中是卫星链路)。第一、第二边缘服务器和机顶盒均接入互联网中。

其中，所述中央服务器上部署了推送服务器(推送服务器可以是一个软件模块)，中央服务器安装Windows 2003 server操作系统。所述第一边缘服务器上部署种子服务器(种子服务器可以是一个软件模块)，所述第二边缘服务器上部署了tracker服务器(tracker服务器可以是一个软件模块)，第一、第二边缘服务器上都安装CentOS操作系统。CentOS操作系统是商业版Red Hat Enterprise Linux(RHEL)的免费版，是架构LAMP的理想操作系统，稳定性非常好，是搭建大型商业运行系统的理想选择。在第二边缘服务器上还可以部署NAT服务器，所述NAT服务器可用于帮助P2P的数据包穿越网络防火墙，但需要注意的是，NAT不是本发明所必须的。

本实施例中使用广播数据带宽是2Mbps。同时，终端使用的是具有P2P补包功能的卫星机顶盒。该卫星机顶盒是一个嵌入式系统，在其上运行的是Linux的操作系统，其中安装终端接收模块和终端补包模块等软件模块。

本实施例的PUSH-VOD系统在逻辑上包括头端推送服务器、头端种子服务器、终端接收模块、终端补包模块以及tracker服务器，其逻辑结构框图如图4所示。

所述头端推送服务器，用于以广播的形式将设定的若干个文件推到每一个终端。推送服务器的工作是由推送系统软件来控制的，可设定一次连续推送若干文件的时间，这个时间称为一个推送周期，根据实际应用的需要，一天可以有1个或者多个推送周期，其总时长也就是广播链路可以空闲出来用于推送服务的时间。比如，可以把推送周期定为从晚上22:00到早上6:00，总共8小时。所有通过头端广播的形式到达终端的文件，都称为推送协议文件，或简称做协议文件。

推送服务器以设定的速率广播推送信息(本实施例中设定为96Kbps)，用以指示终端正确地接收文件。所述推送信息(PI)也会被封装成一个文件，所以推送信息文件也是一个协议文件，并且它是其它所有协议文件的根文件。参考图7，本实施例中的推送信息文件实质是一个XML格式的文本文件，它通常包括多个<file>节点和1个<seeder>节点，每个<file>节点用来描述一个被推送的协议文件。<file>节点包含下列主要属性：id是文件全局的标示，在本实施例中，所有协议文件都拥有一个全局唯一的ID号，它是一个32位长的数字，id空间被分成若干段，每个id空间对应于一种特定用途的文件。本发明的协议文件的种类主要有推送信息文件、推送内容文件(简称内容文件)和推送内容文件所对应的种子文件(简称种子文件)。参考图8，推送信息文件、推送内容文件和种子文件都拥有自己的id空间。推送信息文件中，src字段是要求在终端存储的路径，根据应用的需要，它可以是一个完整路径也可以是一个相对路径；name字段是给终端用户在界面上看到的名字，可以用来方便的支持多语言界面显示的要求；size字段是协议文件的大小，以字节为单位；type字段表示出文件的类型，图中的类型”ts”指明这个协议文件是一个ts格式封装的音视频文件(它通常被作为内容文件)，而当type＝”seed”时，指明这个协议文件是一个种子文件，用于补全其对应的内容文件，种子文件通过id属性与它对应的内容文件产生关联，将种子文件的id的十六进制数值最高位变为0，得出的就是对应内容文件的id。Duration字段是预定该协议文件被推送的时间段，属于辅助的信息；pushindex字段是在本推送周期中该协议文件所排的次序，只作为界面显示时的一个参考；P2P字段是该文件所处补包的状态，默认值是0，表示该文件不使用P2P方式补包，而当P2P字段为1时，则表示该文件可以用P2P方式来补包。可以看到并非所有的文件都需要以上罗列的属性，比如种子文件自身不需要P2P字段。

多个这样的<file>节点和/或<seeder>节点叠加就组成了一个推送周期内所有推送文件的信息。其中，与<file>节点并列的<seeder>节点，记录了全局的种子服务器的地址信息。终端只有在完整无误地接收推送信息后，才可以接收推送服务器所推送的其它文件。为保证推送服务正常运行，本实施例以一定的时间间隔反复广播推送信息文件，这样，终端在任何时候开机，都能够正确地接收到推送信息。由于推送信息与下面会描述到的其它协议文件的封装是一样的，只是File Id部分被规定为从1-255之间循环递增。在推送信息大于段长度时，它同样会被分段传输。推送信息每一次内容的变化，都会令File Id加1，终端在探测到这种改变时必须要重新接收推送信息，更新本地的接收行为。

从上述描述中可以看出，推送信息文件这种XML格式的设计，可以很容易地被扩展，增加新的节点属性，以增加新的应用需求。

所述头端种子服务器，用于保存推送内容文件的完整可靠的副本，并且产生P2P机制所需的种子文件，同时向未从广播的协议文件中完整获取种子文件的终端提供接收种子文件的途径。所述种子文件与普通P2P应用中的种子文件意义相同，其中包含了tracker服务器的地址以及文件校验信息等内容，在本实施例中P2P协议使用32K字节的分块，产生的种子文件的大小大约是原始文件的0.06％。tracker服务器部署于互联网中。在tracker服务器的角度，头端种子服务器可以看做是一台已经具有完整数据的P2P客户端。在P2P方法被应用于推送系统时，需要解决一个问题：如何让终端获取种子文件？本发明提供了下述方案：

将种子文件编排在推送计划中推送至终端，因为种子文件相对于内容文件非常的小(在本实施例的配置中大约是万分之六)，其占用广播带宽也非常有限。由于种子文件较小(1G的内容文件的种子文件大约600K)，结合前述的数据包/数据块丢失规律R1，R3，2次推送后可以令99％的终端完整接收种子文件。另外1％的终端会在进入P2P补包阶段时，向种子服务器去请求获取种子文件，种子服务器会向tracker服务器查询某一台已经获得该种子文件的终端地址信息，用以答复这种请求，在查询无效时，才会自己将种子文件回复给请求的终端，这种做法可以避免因种子服务器处流量过大而出现瓶颈效应。

所述终端接收模块用于接收推送服务器所广播的协议文件(包括推送信息文件)。本实施例的终端接收模块与传统PUSH-VOD系统的相应模块是一致的。

所述终端补包模块，用于统计终端所接收文件中的遗失数据包，并且选择合适的方式去获取该终端的遗失数据包。本实施例中，所述终端补包模块包括终端决策子模块和P2P客户端，所述终端决策子模块用于根据头端指令和本地策略，对终端补包的所有行为做出决策。比如头端会在对一个文件推送完毕后，在推送信息中指示终端可以对这个文件进行补包的动作(可通过修改推送信息文件中相应<file>节点中的P2P字段实现)，而终端决策子模块就负责接收和执行这个指令；又比如终端可以设定本地策略，对于大于一定阈值(如50％)的数据遗失情况，放弃补包，这种情况可能出现在终端开机晚了，没能从头开始接收一个文件，此时终端决策子模块即使收到了头端可以开始补包的指示，仍旧可以决定放弃补包，这样可以避免P2P流量过大。所述P2P客户端则用于以P2P的方式从互联网上获取该终端缺失的数据块，并为其它终端提供P2P服务。

所述tracker服务器，用于维护所有互联的P2P客户端的接收信息。在补包过程中，P2P客户端会持续与tracker服务器通信，以知道从哪里可以获取所需的数据包，这与通常P2P应用中的tracker服务器的作用是一致的。

在本实施例的推送系统中，一个完整的协议文件(包括推送信息文件、内容文件和种子文件)被分割为多个分段，每个分段被封装成如图2所示的数据包。参考图2，该数据包开头有16个字节的包头，其中File Id是在整个推送系统范围内唯一指明某一个协议文件的标示，即图8所示的id；Size代表了该协议文件的总长度；Offset代表了这段负载在原来协议文件中的偏移量；而Length代表了这一段负载的长度。Playload部分是实际的负载，也称为协议文件中的一个分段。考虑实际的广播链路的一些协议限制，一个分段的长度不能超过1500字节。

在本实施例中，使用1024字节的固定分段长度，也就是说，除了最后一个分段，所有的分段都是1024字节。定义每32个分段组成一个块，文件最后少于32个分段时，就把余下的分段合并成一个块。块是终端进行写入和追踪的基本单位。按上述方式定义的块的长度与本实施例中所采用的P2P协议的块长度相同，便于二者相互匹配。

在终端接收任何协议文件(包括了推送信息文件，内容文件，种子文件和协议中定义的其它文件)时，会为每一个协议文件维护一个接收进度(RP)文件，这是一个位图形式的文件，它的每一位(即每一个bit)代表了协议文件中的一个块，RP文件中的一位为1时，代表该位所对应的块已经接收并写入，为0时代表该位所对应的块没有收到。RP文件的大小大约是协议文件的百万分之四。当一个协议文件接收完整后，终端接收模块会自动删除对应的RP文件。

实施例2

根据本发明的实施例2，提供了一种基于实施例1的推送系统的推送点播方法，该方法包括下列步骤：

1)在推送初始，种子服务器获取内容文件的完整拷贝，并计算出对应的种子文件发还给推送服务器。推送服务器将种子文件也编入推送计划中。

2)头端使用广播信道定期向终端广播推送信息文件，推送信息文件的格式在实施例1中已有介绍，这里不再赘述。推送信息文件中，每个内容文件对应的<file>节点的P2P字段的初始值为0。

3)头端使用广播信道在推送周期向终端广播内容文件和内容文件所对应的种子文件。为保证可靠性，本实施例中在广播内容文件前，先推送种子文件2遍。

4)在一个内容文件推送结束时，头端的推送服务器更新推送信息，标示该内容文件已处于P2P补包模式，即该推送信息文件中该内容文件对应的P2P字段的值修改为1。

5)终端补包模块始终监视文件接收的情况，并在初始化时即打开P2P客户端；在接收一个内容文件后，当终端补包决策子模块在接收到该文件处于P2P补包模式的指示后(即推送信息文件中该内容文件对应的P2P字段的值为1时)，将该文件加入P2P补包文件列表，如果此时该终端还没有得到该文件的种子文件，则向种子服务器请求获取种子文件，获取种子文件的一般步骤如下：

51)终端A向种子服务器请求种子文件x.seed；

52)种子服务器接收到请求后，转向tracker服务器查询，得到终端B已经拥有x.seed，则答复终端A，让其向终端B请求这个种子文件；

53)终端A收到种子服务器的答复后，向终端B请求x.s eed；

54)终端B将x.seed通过TCP协议发给终端A。

6)终端得到种子文件后，就以通常的P2P方法去获取所需的数据块。对于已经接收完整的终端，也必须开启着P2P客户端，为其它终端服务，直到推送信息文件中相应P2P字段为0。也就是终端接收模块在接收新的推送文件时，终端补包模块仍旧可以在为所有列在P2P补包文件列表中的文件补包，并为其它终端提供为这些文件进行补包的P2P服务。

7)在终端上，当遇到以下几种情况时，需要从P2P补包文件列表把一个文件删除。A，这个文件在本终端上已经接收完整；B，在最新的推送信息中该文件的P2P属性值为0；C，在最新的推送信息中该文件已经不存在。

实施例3

实施例1中将所有丢失数据块由P2P方式补包，能够有效地降低系统对广播信道的占用，然而，这种补包方式对互联网络占用相对较大。因此，本发明还提供了另一种补包方案，以对实施例1的PUSH-VOD系统做进一步改进。

在实践中发现，PUSH-VOD系统中，地理相邻的一个区域内的所有终端的接受率基本是相同的，并且丢包的序号也非常相似。对待相似性的丢包状况，广播仍旧是最有效率的做法，因此可以利用这种相似性，通过使用较小的额外的广播链路带宽来重新推送丢失最密集的数据块，以此实现更有效率的二次推送，从而大幅减小对互联网带宽的占用。

根据本发明的实施例3，提供了一种具有反馈机制的PUSH-VOD系统。如图5所示，具有反馈机制的PUSH-VOD系统在逻辑上除了包括实施例1中所有模块外，还包括头端统计服务器及终端补包反馈子模块，这两个模块之间可以通过互联网通信。

本实施例的推送系统的实体结构也与实施例1基本相同，其区别是，在第一边缘服务器上另外部署了头端统计服务器；在卫星机顶盒里包含了终端补包反馈子模块的软件。本实施例的系统结构框图可参考图3。

本实施例中的头端统计服务器，用于接收终端补包模块的补包反馈子模块发送的接收反馈信息，对其进行统计，并决定将被重新推送的数据块。然后通知推送服务器按照该头端统计服务器做出的决策进行第二次推送。

补包反馈子模块，用于将内容文件接收进度信息回传给头端统计服务器。内容文件接收进度信息即所述接收反馈信息。

统计服务器和终端补包反馈子模块间的协议交互过程参考图9。

首先，在T0点，推送服务器在完成一个内容文件第一次的推送后，更新推送信息，将该内容文件的P2P属性值设为2。在本实施例中，将会在推送信息文件中增加新的全局节点“stat”，其中包含了统计服务器的地址信息和反馈等待时间FT的值；同时扩展了推送信息文件中的file-＞P2P属性值的含义，将该内容文件的P2P属性值设为2，表示准备接收该内容文件的接收反馈信息。

接着，在T1点，终端接收模块收到更新的推送信息文件后，通知补包反馈子模块。此时有2件事情需要考虑。第一，如果每个终端都在此时立即发送反馈数据，会在瞬间发生爆炸性的数据。因此需要一个方法让每个终端错开发送反馈的时间段；第二，由于同一地区的终端接收情况是很类似的，因此完全可以只选取一定比例的有代表性的终端发送反馈数据包，而不需要全部发送，以减少网络上的数据量。对于第一个问题，本实施例使用一段时间间隙来完成反馈的行为，计做FT，头端预先设置了该参数，并且如上所述，在广播的推送信息文件中记录该参数的值，以将其通知给各终端。

在T1点，补包反馈子模块使用延迟反馈算法算出这台终端上发送反馈数据的时间点。

所述延迟反馈算法，是一种以各终端独立的序列号SN和规定的反馈间隙的FT为输入参数而得出所需延迟时间T_delay的计算方法，它依赖在生产终端机顶盒时确立的SN在自然数域的分布规律，令每一台终端得出的结果可以在0到FT之间均匀分布。可以用T_delay＝DelayFb(SN，FT)表示这个方法，其中0＜＝T_delay＜＝FT。于是在时间点T1+T_delay，终端补包反馈子模块向统计服务器发送了反馈问询(FB_Query)，这个数据包里包含了以千分率为单位的该终端对于当前内容文件的接收率，如955，代表当前接收率是95.5％。

统计服务器选择预设比例(在本实施例中是10％)的终端，答复反馈应答(FB_Reply)，其中告知可以发送反馈数据(Data字段为1)；另外90％，同样会以FB_Reply应答，但会告知不用再发送反馈数据(Data字段为0)。统计服务器选择这10％终端的方式来自于终端的IP地址加上随机的选取。因为互联网上IP地址的分配与地域有关，所以首先根据IP地址，将所有终端划分为若干个组；再从各个组中按比例随机抽取需要反馈的终端。

需要反馈数据的终端在T2时刻，发送反馈数据(FB_Data)，其本质上就是对前述RP文件(进度文件)的封包，由于RP文件用TCP协议通过互联网传输，所以封装过程中的数据分段问题可以由TCP/IP协议自行处理。而对于本实施例的推送系统而言，1个数据包封装1个RP文件。

参考图6，是反馈交互中所有数据包的封装格式。其中FB_Flag是区分FB_Query，FB_Replay和FB_Data的数据头标示，0x01表示这是一个FB_Query，0x02表示这是一个FB_Reply，0x04标示这是一个FB_Data。FileId是该轮反馈交互所代表的内容文件的id。第三个字段意义在3种包内各不相同。当这是一个FB_Query时，此处代表Rx，是对文件Id的接收千分比值；当这是一个FB_Reply时，此处是Data，代表是否需要终端反馈数据；当这是一个FB_Data时，此处是Size，代表了后续封装的RP文件的长度，在头端接收FB_Data时应检查这个长度，确认和计算得出的长度相等，否则视为无效的反馈数据，予以丢弃。只有FB_Data具有Payload部分，即是RP文件的内容。

统计服务器会预设一段大于FT的时间，用来等待所有反馈数据的完成，计做WT。在T0时刻更新推送信息起，推送服务器即通知统计服务器，启动“等待反馈定时器”，持续WT的时间，在此期间接收的反馈数据为有效，在定时器过时后到达的反馈数据包会被丢弃。在本实施例中，FT＝60，WT＝90。

在接收完毕对一个内容文件的所有反馈数据后，统计服务器将涉及遗失的数据块序号按终端报告的数量由多到少排序。对于一个平均接收率在95％的系统，可选取总数据块的前20％，这样已经可以覆盖95％的遗失数据块范围。统计服务器将选取的前20％数据块报告给推送服务器，由推送服务器安排进行重新推送，这次推送对于终端接收率的效果将等近似于全部重新推送，但效率增长了5倍。

为了不让广播链路在上述的等待反馈时间WT中产生空闲的浪费，只需对推送计划做一些小的调整。参考图10，在文件1推送完毕后，发起对文件1的反馈和统计，并同时开始推送文件2；在文件2推送的过程中，完成对文件1的反馈和统计；在文件2推送结束后，立即开始部分重推文件1，同时发起对文件2的反馈和统计。以此类推，一个推送周期以最后2个内容文件的部分重推结束为结束。

对于仍旧遗失的数据块，则使用实施例1中的P2P方法进行补包，此时需要补的数据已经大大减少，因此能够有效地降低P2P补包机制对互联网带宽的占用。

实施例4

根据本发明的实施例4，提供了一种基于实施例3的PUSH-VOD系统的结合了终端补包和反馈机制的推送点播方法，该方法包括下列步骤：

2)头端使用广播信道定期向终端广播推送信息文件，推送信息文件的格式在实施例1和实施例3中已有介绍，这里不再赘述。推送信息文件中，每个内容文件对应的<file>节点的P2P字段的初始值为0。在推送信息文件中还携带种子服务器的地址，统计服务器的地址和反馈等待时间FT。此时所有推送内容文件的P2P属性值都是0。

4)在一个内容文件推送结束时，推送服务器更新推送信息，标示该内容文件开始接收反馈，即该内容文件对应的P2P属性值为2，并启动针对这个内容文件的“等待反馈定时器”；同时按推送计划开始推送下一个协议文件。

5)终端补包模块始终监视文件接收的情况，并在初始化时即打开P2P客户端。终端补包决策子模块在最新的推送信息中了解到该文件在头端等待反馈，于是调用补包反馈子模块对本地接收情况进行反馈补包(也称为部分重推)，该反馈补包步骤包括下列子步骤：

51)终端补包反馈子模块通过延迟反馈算法算得延迟反馈的时间点，并在这个时间点到来时向统计服务器发送FB_Query；

52)统计服务器根据通过终端IP地址选择出了10％的终端作为提取反馈数据的代表性终端(这一过程可以预先完成)，统计服务器在收到FB_Query后答复FB_Reply，告知各终端是否需要发送反馈数据；

53)如果该终端需要发送反馈数据，则立即发送由RP文件封包而成的FB_Data。

54)当等待反馈定时器达到定时时间后，头端统计服务器汇总各终端反馈的信息，统计服务器将涉及数据包遗失的数据块序号按终端报告的数量由多到少排序。选取总数据块的前20％(这个比例可称为部分重推比例阈值，该值可视具体情况而定)的序号，通知推送服务器将这些数据块安排进图10所示的推送计划中进行重新广播。

6)对内容文件的部分重推结束后，推送服务器在推送信息中携带标志指示该内容文件处于P2P补包模式，即将相应文件的P2P属性值设为1。

7)终端补包决策子模块在得到该文件处于P2P补包模式的指示后，将该文件加入P2P补包文件列表，如果还没有得到该文件的种子文件，则向种子服务器请求。获取种子文件的一般步骤如下：

71)终端A向种子服务器请求种子文件x.seed；

72)种子服务器接收到请求后，转向tracker服务器查询，得到终端B已经拥有x.seed，则答复终端A，让其向终端B请求这个种子文件；

73)终端A收到种子服务器的答复后，向终端B请求x.seed；

74)终端B将x.seed通过TCP协议发给终端A。

8)得到种子文件后，就以通常的P2P方法去获取所需的数据块。对于已经接收完整的终端，也必须开启着P2P客户端，为其它终端服务。在这之后的推送信息中，该内容文件一直处于P2P补包模式，也就是终端接收模块在接收新的推送文件时，终端补包模块仍旧可以在为所有列在P2P补包文件列表中的文件补包。

9)在终端上，当遇到以下几种情况时，需要从P2P补包文件列表把一个文件删除。A，这个文件在本终端上已经接收完整；B，在最新的推送信息中该文件的p2p属性值为0；C，在最新的推送信息中该文件已经不存在。

下面分析本发明对各类带宽的使用情况。

在实施例1、2中，广播推送只进行1次，推送种子文件增加额外千分之一的开销，可以忽略不计。对于互联网的开销在获取种子文件的过程和P2P补包的过程。实验中，一次推送的平均接受率约是95％，因此，在实施例1、2中，互联网数据总量Q≈5.0006％*N*P(其中N为终端数目，P为推送总数据量，5％是需要补足的数据量百分比，0.0006％是需要通过网络获取的种子文件的数据量百分比)。考虑到这两个过程都使用了P2P技术，互联网开销被分担在各个终端的IP链路上，并且广播推送和P2P补包有近似相同的时间跨度(8小时的推送周期内)，所以对每个终端的IP带宽占用平均为T＝2M*5.0006％≈100K。可以看到广播链路的使用已经降低到最低的程度，互联网的数据量主要来自于补包的内容，其总量还是比较巨大。如果遇到链路质量不佳的状况，P2P对网络资源的占用将加剧。

在实施例3、4中，由统计服务器选出了20％的数据进行重推，也就是1.2次的推送。而这种经过挑选的重推可以达到与全部重新推送近似的效果，根据推送律R4，在固有接收率95％的情况下，全部二次推送后的接收率可以达到99.75％，算上部分重推的数据只覆盖了95％的遗失数据块的细微损失，部分重推后可以使接收率达到99.5％。对于互联网的开销在终端反馈数据的过程、获取种子文件的过程和P2P补包的过程。每个FB_Data的数据总量RP_Q≈0.0004％*N*S*0.1(其中N为终端数目，S为单个推送内容文件的平均大小，0.0004％是RP文件相对于内容文件的比例，0.1是因为选取了10％的终端反馈数据)，当N＝1000，S＝100M bytes时，RP_Q≈40M bytes。因为FT＝60，也就是将所有反馈数据分配在1分钟的时间间隙内完成，头端统计服务器所需的带宽RP_T≈40M*8/60＝5.33Mbps。再继续扩大终端数目的话，可以通过增大FT的值，来减轻头端所需承受的网络带宽压力。因为等待反馈时隙利用了下一个文件的推送时间段，所以FT有很宽裕的增长空间。这个时候再应用P2P补包，每个终端的IP带宽占用降为T＝2M*0.5006％≈10Kbps。可以看到互联网的数据量只有实施例1，2的十分之一。

值得说明的是，以上实施例虽然都采用了P2P机制进行补包，但可以理解，只要各终端能够通过计算机网络与头端或部署在计算机网络中的服务器连接，终端即可从计算机网络下载所需的遗失数据块，其下载所需的遗失数据块的方法并不限于P2P机制。特别地，在实施例3，4中，当头端进行二次推送后，实际需要进行补包的数据块已经比较少，此时，直接让每个终端直接向头端种子服务器请求数据并下载数据(不使用P2P机制)也可以达到补包的目的。并且，这种做法也并不会增加头端的复杂性。在中小型规模的应用中(比如终端数量小于1000)，根据以上的计算，头端只要有10Mbps的出口带宽，即可满足要求。而此时由于不需要tracker服务器，终端机顶盒中也不需要有P2P客户端，整个系统的成本可以进一步降低。

综上上述，本发明相对于现有的单向网络中的推送点播系统具有如下的优势：

1)本发明提出的终端反馈方法，以1次完整推送加上1次部分推送，达到单向PUSH-VOD系统2次完整推送所能达到的效果。也就是对广播链路带宽的需求比现有系统低。这在资源稀缺的卫星链路上具有很高的现实意义。

2)本发明提出以P2P的技术完成小量的补包，使得在理论上，所有的终端都可以达到100％的最终接收率，而在传统的推送系统中，付出巨大的链路开销，也只能无限逼近这个目标，而不可能保证这一点。因此本发明能够有效提升PUSH-VOD系统的用户体验的品质。

3)本发明提出以P2P技术作为PUSH-VOD的补充，使小部分错过推送时间段的终端，从技术上有了重新获取错失文件的条件，这也将提高PUSH-VOD系统的用户体验的品质。

Claims

1.一种数字电视推送点播系统，包括头端系统和终端系统，所述头端系统和终端系统之间具有广播链路，所述头端和终端系统均接入计算机网络中，所述头端系统用于通过广播链路推送文件到终端系统，所述终端系统用于接收头端系统所推送的文件，并通过所述计算机网络获取所接收的推送文件中的遗失数据包。

2.根据权利要求1所述的数字电视推送点播系统，其特征在于，所述头端系统包括头端推送服务器和种子服务器，所述终端系统包括终端接收模块和终端补包模块；

所述终端接收模块用于接收头端推送服务器所推送的文件；

3.根据权利要求2所述的数字电视推送点播系统，其特征在于，所述头端推送服务器还用于推送内容文件所对应的种子文件。

4.根据权利要求2所述的数字电视推送点播系统，其特征在于，所述数字电视推送点播系统还包括用于提供P2P服务的tracker服务器。

5.根据权利要求2所述的数字电视推送点播系统，其特征在于，所述头端系统还包括头端统计服务器，用于重复推送遗失较为密集的数据包；所述终端补包模块还包括终端补包反馈子模块，用于向头端统计服务器反馈该终端的遗失数据包信息。

6.一种利用权利要求1所述的数字电视推送点播系统的数字电视推送点播方法，包括下列步骤：

1)头端系统通过广播链路推送文件到终端系统；

7.根据权利要求6所述的数字电视推送点播方法，其特征在于，所述步骤1)包括下列子步骤：

所述步骤2)包括下列子步骤：

22)终端系统统计所接收的内容文件中的遗失数据包；

8.根据权利要求7所述的数字电视推送点播方法，其特征在于，所述步骤12)还包括：所述头端系统还通过广播链路推送种子文件；

9.根据权利要求7所述的数字电视推送点播方法，其特征在于，所述步骤12)中，所述内容文件当前所处状态的类型还包括等待反馈状态；

所述步骤22)包括下列子步骤：

10.根据权利要求9所述的数字电视推送点播方法，其特征在于，所述步骤222)中，反馈遗失数据包信息的终端系统限于被头端系统按一定比例选定的具有代表性的终端系统；各终端系统向头端系统进行反馈的时间段分散设置。