专利名称：用于请求文件修复分发模式的方法
技术领域：
本发明一般涉及文件修复机制，尤其涉及一种用于请求文件修复分发模式的方法。
背景技术：
本部分用于向读者介绍技术的各个方面，它们与下文中介绍和/或请求保护的本发明的各个方面相关。这部分介绍向读者提供了背景技术信息，从而有利于了解本发明的各个方面。相应地，应当认识到这些介绍主要是为了方便读者了解本发明的各个方面，而不应该作为对现有技术的承认。IETF RFC 3拟6定义了单向文件传输协议(file delivery over unidirectional transport)，缩写为FLUTE。在这个标准中的协议很好的解决了用户数量的扩展问题和用户支持的带宽的异构(heterogeneity)问题。DVB-H IP数据广播标准是《ETSI TS 102 472 VL 2. 1(2006-12)，数字视频广播(Digital Video Broadcasting, DVB)；在 DVB-H 上的 IP 数据广；内容传输协议(Content Delivery Protocols，CDP)》。以下记为CDP标准。它定义了文件修复机制。该机制在第二篇文件中详细阐述，即ETSI TS 102 591 1.1.1，数字视频广播；DVB-H上的IP数据广播；内容传输协议实现指导书。在DVB-H IP数据广播标准中采用的文件修复策略是单一级别的文件修复策略，并且它采用了集中的客户-服务器“文件修复“模式。它使用文件修复机制来帮助FLUTE协议在广播/组播网络上实现可靠的文件传输。一旦检测到接收了一个不完整的文件，FLUTE 接收端启动文件修复机制。它包括请求丢失或损坏的数据包。根据FLUTE的术语表，这些数据包被命名为符号(symbol)。通过使用点到点(Point to Point,P2P)连接把请求发送到修复文件服务器。请求中基本包括要被修复的文件的名字和丢失符号的列表。在这样的系统中，可以同时存在多个修复服务器，每一个修复服务器包括一个或多个修复服务。所有可能的修复服务列表在“相关传输过程配置文件”中被记载。这是一个XML文件，它包括每一个可以使用的修复服务的URL。当需要修复服务器的时候，客户端随机地选择其中的一个服务，并且通过点到点连接发送一个包括要请求符号列表的修复请求。修复服务或者通过点到点连接发送部分或者所有要请求符号，或者把请求重定向到一个不同的服务。这个重定向可能不是指示另一个修复服务器，而是指示一个FLUTE会话描述，在这个FLUTE会话上丢失的或损坏的符号要被重新广播。文件修复过程由客户端通过点到点连接启动，并且进一步使用点到点连接、广播信道或者两者混合来实现。客户端请求所有丢失的符号。在分析符号列表之后，修复服务器选择分发模式。为了能够有效地利用资源，一些符号通过广播连接分发，而其它的则通过点到点连接发送。如下介绍了一个使用点到点连接和广播连接的文件修复的例子。客户端发送修复查询到服务器。然后，响应于修复请求，服务器通过点到点连接发送被请求符号的子集。然后修复客户端向修复服务器发送请求仍然丢失的符号的第二请求(这里可能与前一个类似)。这一次，修复服务器把请求重定向到可能能够修复剩余符号的广播会话。当一个符号被多个客户端请求的时候，使用广播信道分发的好处是使用了较少的资源。但是，在有些情况下，其就不是最好的解决方案。例如，如果终端仅仅能防问点到点网络(在失去对广播信道的防问之后)，它就不能接收在广播信道分发的任何内容。在上面描述的混合修复的例子中，终端不能够收到修复查询中请求的所有符号，这是因为只有要修复符号的一部分是在点到点网络上分发，而其它的是在广播网络中分发。因此，需要一种修复方法使得设备能够以特定的方式来接收内容(仅仅点到点，混合模式等等)，或者在某种特定网络上接收内容，例如，通过两个不同的点到点连接来连接中终端。
发明内容
本发明通过提供一种方法让接收器向服务器指示希望的分发模式，来试图解决现有技术中修复文件分发中的一些问题。本发明涉及在接收器端的用于向修复服务器请求丢失的符号的方法。该方法包括如下步骤接收包括至少一个修复服务器和被所述至少一个修复服务器使用的至少一个传输模式的列表；从第二服务器接收包括很多符号的文件；对符号的正确接收与否进行检测；和如果识别出有丢失的符号，选择一个修复服务器和一种传输模式，并请求所述修复服务器使用所述传输模式传输丢失的符号。有利地，接收器获得修复服务器及每一个修复服务器能够使用的传输模式的列表。接收器能够向修复服务器指示它希望修复服务器使用的传输模式，从而能够优化来自修复服务器的数据接收。根据本发明的一个实施例，传输模式是点到点模式和/或广播模式。当处于广播接收质量很低的区域时，接收器可以请求点到点传输模式。如果广播质量接收没有那么低的时候，接收器可以请求广播模式，或者使用广播和点到点的混合模式。根据本发明的一个实施例，所请求的传输模式基于传输成本和/或广播接收质量。接收器预先知道传输成本。如果使用点到点模式成本很高，接收器会明智地不使用该模式。根据本发明的一个实施例，该方法包括在请求步骤之前的对广播接收质量进行的接收质量测量步骤。根据本发明的一个实施例，列表被包括在associatedProcedureDescription的 XML文件中。根据本发明的一个实施例，根据FLUTE协议对所述文件进行接收。本发明还提出了一种接收器。包括通信装置，用于从广播网络接收数据以及用于在双向网络中通信；文件接收计算装置，用于当从广播网络中接收一个包括很多符号的文件时，对在广播网络上的符号的正确接收与否进行检测；选择装置，用于从包括至少一个修复服务器和被所述至少一个修复服务器使用的至少一个传输模式的列表中选择一个修复服务器和一个传输模式；以及文件接收报告装置，用于在所述双向网络上向所述修复服务器发送一个请求所述修复服务器使用所述传输模式传输丢失的符号的请求。根据本发明的一个实施例，通信装置被用于接收包括至少一个修复服务器和被所述至少一个修复服务器使用的至少一个传输模式的列表。本发明还提出了一种计算机程序产品，当程序在电脑上执行的时候，它包括用于执行根据本发明的方法的步骤的程序代码指令。这里所说的计算机程序产品，它指的计算机程序支持，它不仅包括存储程序的存储空间，例如磁盘或磁带，还包括信号，如电信号或光信号。本发明还提出了一种associatedProcedureDescription类型的XML配置文件，包括包括至少一个修复服务器和被所述至少一个修复服务器使用的至少一个传输模式的列表。如下对实施例的各个方面进行描述。应当了解，这些方面仅仅用于向读者介绍本发明可能采取一些形式，因此不应该被用于限定本发明的范围。实际上，本发明应该包括许多下文中没有介绍的方面。
通过结合附图来对下面的具体实施例和执行例子进行描述，可以更好地了解本发明。其中图1示出一个具体实施例的系统；和图2示出了根据该具体实施例的移动终端。在图1和图2中，示出的功能块仅仅是功能实体，并不一定需要和物理上分开的实体相对应。即，它们能够通过硬件或软件来实现，或者在一个或多个集成电路中实现。
具体实施例方式在DVB-H IP数据广播中的文件修复框架中描述实例的实施例，但是本发明并不局限于该环境，并且能够应用于其它的接收方请求服务器在多种传输模式下发送内容的框架中。在第一实施例中，存在多个修复服务。一种文件修复服务独占点到点信道。它通过在URI以字符串“/p2p_0nly”结束来标记。另一种修复服务使用广播信道。它通过以字符串“/bcst_only”结束来标记。另一种修复服务使用广播信道或点到点信道。这是一种混合服务，通过字符串“/hyprid”来标记。如果以后有别的网络可以被修复服务使用，那么可以别的字符串来区分它们，例如，/wimax_bcast, /wifi_p2p等等。在OMA-BCAST standard OMA-BCAST，OMA-TS-BCAST Distribution-Vl_0-20080807-C fe it Φ, X Ji ^ OMA-SUP-XSD_bcast_fd_ associatedprocedure-Vl_0之中定义XML结构，用于把有效的修复服务的URL通知给终端。 此外，DVB-CBMS之中也定义了一种XML结构。文件修复过程被描述成一种相关文件传输过程(和相关文件传输会话相关)，并且在文件传输会话开始之前，通过使用特定的XML结构把相关信息提供给文件接收端。一个示例的配置文件有如下的形式< xml vers土on="l.0" encoding="UTF-8“ >
〈associatedProcedureDescription xmlns="urn:dvb:ipdc:cdp: associated Procedures :2005" xmlns:xsi="http://www.w3. org/2001/XMLSchema-instance" xsi:schemaLocation="urn:dvb:ipdc:cdp:associatedProcedures:2 005 associated—procedure_description .xsd"> <poStFiIeRepair offsetT土me二"50" randomTimePer■土od二n6 00">
<serverURI>"http://ipdcrepair. operator .umts/ipdc file repair s
cript"</serverURI> <serverURI〉"http://ipdcrepair1. operator .umts/ipdc file repair
script"</serverURI〉 〈serverURI〉"http://ipdcrepair2. operator .umts/ipdc—file—repair—
script/p2p—〇nly"</serverURI> <serverURI>"http://ipdcrepair2. operator .umts/ipdc file repair script/hybrid"</serverURI> </postFileRepair>
〈bmFileRepai] sessionDescripti〇nURI="http : //www. example . com/ipdc /session1.sdp"/> </associatedPr〇cedureDescription〉在客户端通过广播或这点到点模式来接收的正常的覆盖情况下，客户端通过发送请求到给出的4个URI中随机的一个来请求修复符号。下面介绍一个请求的示例。终端使用HTTP协议提交修复请求。GET/ipdc_file_repair_script ？ fiIeURI = www. news. ipdc. com/1atest/ipdcFileTest. txt&SBN = 0 ；ESI = 12，44，78&SBN = 2&SBN= 3 ；ESI = 55-98HTTP/1. 1.Host :http://ipdcrepair 1. operator, com终端可能现在处在一个特别的情况下，如它仅能够通过所有传输模式或传输信道的一个子集进行接收修复符号。可以通过很多方法来检测在一个信道上的低的信号接收水平、高错误率或者低数据速率，或者禁止成本(prohibitive cost)。也有可能是它能预测出这种情况，因为它检测到子集处于覆盖范围的边缘。如果终端确定当前的情况仅仅允许通过点到点连接来接收修复符号，它从修复服务列表中选取一个为“仅仅点到点修复”的修复服务。在这种情况下的修复请求是GET/ipdc_file_repair_script/p2p_only ？ fiIeURI = www. news, ipdc. com/latest/ipdcFileTest. txt&SBN = 0 ；ESI = 12，44，78&SBN = 2&SBN = 3 ；ESI = 55-98HTTP/1· 1.Host :http://ipdcrepair2. operator.com在第二实施例中，XML架构(XML scheme)被修改。XML架构中增加修复服务器支持的修复模式。它是一个XML属性，对每一个修复服务器使用XML配置树进行描述。属性值在如下值中选择仅仅点到点；点到点和广播修复混合，或者仅仅广播修复。属性值可以被扩展用于指定以后可能的传输信道，例如Wi-Fi，Wimax0它的好处在于减少了对XML配置模型的改变。接收端知道默认的修复服务器行为(仅仅P2P修复，混合修复或仅仅广播)。默认的修复服务器行为最好是混合修复模式。如果选项信息没有被提供，接收端则认为修复服务器可以使用3种模式(仅仅 P2P、混合模式、仅仅广播)中的任何一种。
在DVB-CBMS中实现上述修改后的架构的XML文件的例子如下
< xml version=Ml.0" encoding="UTF-8“ > 〈associateciProcedureDescription
xmlns=MurndvbipdccdpassociatedProcedures:20 05" xmlnsxsi=Mhttp//www .w3. org/2 001/XMLSchema-instance" xsi:schemaLocati〇n="um:dvb:ipdc:cdp:associatedProcedures:2008 associated—procedure—description .xsd"> <postFileRepair offsetTime=,,50" randomTiraePeri〇d=,,600n> <serverURI repairMode=〃P2P_0NLY〃>
"http://ipdc. op .umts/ipdc—file_repair_script“ </serverURI> <serverURI>
"http: //ipdc . op2 . uints/ipdc_file_]:epair" </serverURI>
〈serverURI repairMode=〃HYBRID">
"http://ipdc. op.umts/ipdc_file_repair_script“ </serverURI>
<serverURI repairMode=〃HYBRID〃>
"http://ipdc. op .umts/ipdc_file—repair—script“
</serverURI>
<serverURI repairMode=〃BCAST_ONLY〃>
"http : //ipdc . op. umts /土pdc_f ile_repair_script11 </serverURI> </p〇stFileRepair〉
<bmF土IeRepair sessionDescriptionURI=Mhttp: I/www. example . com/ipdc/ sessionl.sdp"/> </associatedProcedureDescription>对第二实施例的一个变形实施例是允许文件接收端获取超过一个修复服务器列表的描述的XML架构，每一个列表都有明确的修复模式能力描述。一个列表是关于仅仅提供点到点的修复服务器，另一个列表是关于提供混合修复(点到点和广播)的修复服务器， 或者是关于仅仅提供广播修复的修复服务器。 在DVB-CBMS环境中的XML架构示例如下所示
< xml version=”l.0" encoding="UTF-8" >
<associatedProcedureDescripti〇n xmlns=Murn:dvb:ipdc:cdp:associatedP rocedures:2 005" xmlns : xsi="http : / /www. w3 .〇rg/2001/XMLScherna—土nstance “ xsi : schemaLocatio:n="u:rn : dvb : ipdc : cdp : associatedProcedures : 2 008 associated—procedure—description .xsd"> <postFiIeRepair offsetTime="50n IrandomTiiTiePeriod=HGOOnS <P2P—ONLY—serverList> <serverURI〉
"http://ipdc. op .umts/ipdc—file—repair—script" </serverURI> <serverURI>
"http://ipdc.op2.umts/ipdc_fiIe一:repair" </serverURI> </P2P_〇NLY_serverList> 〈HYBRID—serverList〉 <serverURI>
"http://ipdc. op .umts/ipdc_file_repair—script" </serverURI> <serverURI>
"http://ipdc. op .umts/ipdc—file_repair_script" </serverURI> 〈/HYBRID—serverList> <BCAST_ONLY_serverList> <serverURI>
"http://ipdc. op .umts/ipdc_file_repair_script" </serverURI> </BCAST_〇NLY—serverList> </postFileRepair>
<bmFileRepair sessionDescriptionURI="http://www.example . com/ipdc/ sessionl.sdp"/> </assoc土atedProcedureDescription〉第三实施例在HTTP扩展头中指示修复模式。用于HTTP1. 1的IETF RFC 2616定义了 HTTP扩展头。接收端对修复请求增加一个比压头(specific header)来通知修复模式类型(仅仅P2P、混合模式或者仅仅广播)。如果这个增强的修复请求被与传统的HTTP1. 1兼容的修复服务器接收，它仅会被当作扩展头并被服务器忽视。下面示出了在OMA BCAST环境下一个扩展的修复查询的例子，它使用了一个新的头域 ItepairMode 来提供 3 个选项P2P_0NLY、HYBRID 或 BCAST_ONLY。
GET /path/repair—script fileURI=www.example . com/news/latest.3g p&Contant-MD5=0DZiYTUl〇TFkZGY2NWY50Dh==&SBN=5,.ESI = 12& SBN=2 0;ESI = 2 7 HTTP/1 .1 Host: mbmsrepairl.example.com RepairMode: HYBRID第三个实施例的第一个变形是使用允许的修复模式和信道(3G-P2P、Wifi_P2P和 DVB-H-BCAST)的列表来作为域值，在列表中使用逗号来分隔。之前描述的例子现在变为
GET /path/repair—script fileURI=www. example . com/news/latest.3g p&Content-MD5=0DZiYTU10TFkZGY2NWY50Dh==&SBN=5 ,.ES 1 = 12 & SBN=20;ESI=27 HTTP/1.1 Host: mbmsrepairl.example.com RepairMode: 3G-P2P,DVB-H-BCAST第三实施例的第二个变形是在修复请求中增加首选的修复模式。通过增加参数(例如ItepairMode)来增强传统的HTTP修复。它被关联到3个可能的值来为查询指示首选的修复模式仅仅P2P、混合修复或者仅仅广播。下面为在OMA BCAST环境中一个扩展的修复查询的例子。它使用了一个新的参数 RepairMode 来提供 3 个选项P2P_0NLY、HYBRID 或 BCAST_0NLY。GET/path/repair_script ？ fiIeURI = www. example, com/news/latest. 3gp&R印airMode = P2P_0NLY&Content_MD5 = 0DZiYTU10TFkZGY2NWY50Dh== &SBN = 5 ；ESI = 12&SBN = 20 ；ESI = 27HTTP/1. 1Host :mbmsrepairl. example, com第三实施例的第三个变形是使用请求中的头域和响应中的特殊头。如果客户端发送消息通知它已经准备好接受混合或者广播修复(在该例中为了向后兼容)，服务器则在响应的头中指示用于广播修复的会话信息。这样就减少了在混合修复模式中服务器和客户端之间交互的数量。也就不需要客户端发送第二个请求来获得可能是动态的广播会话的信肩、ο根据本发明的一个变形，对应于第三实施例的请求或第三实施例的第一变形的请求的响应为HTTP/1. 1 200 OKContent-Type !application/simpIeSymboIContainerBcastSDP :http://www. example, com/ipdc/sessionl. sdp〈followed by the payload>它指出在响应消息的主体(通过点到点连接)中没被提供的所有被请求的符号将会通过指示的广播会话提供。图1示出了根据本实施例的用于视频分发的系统。视频广播系统1.6适应如下标准:"ETSI TR 102 469 VI. 1. 1 (2006-05)，“数字视频广播(DVB) ；DVB-H 上的 IP 数据广播 体系”。如下被记为IP数据广播标准。该系统也适应如下标准“ETSI TS 102 472 VI. 2. 1 (2006-12)，“数字视频广播 (DVB) ；DVB-H上的IP数据广播内容传输协议”。以下被记为⑶P标准。文件服务器1. 1依据⑶P标准和FLUTE协议发送数据文件。通过IP网络1. 3和 DVB-H广播网络1. 6数据文件被传输到移动终端1.7。IP网络可以是任何支持组播传输的 IP网络，例如Internet。DVB-H传输网络包括DVB-H IP封装器(IPE) 1. 4和DVB-H发送器 1.5。当然，本实施例不局限于DVB-H网络。它适用于其它任何宽带分发网络，例如数字用户线家族。系统还包括通过蜂窝网络1. 8或者热点网络1. 9的返回信道。移动终端可以通过返回信道接收和发送数据，尤其是交互数据。当然，返回信道可以是其它任何提供点到点双向连接的信道。这个系统是与CDP标准定义的DVB-H相关的简化的文件修复架构。为了重新获得数据包，终端向修复服务器1. 2提交修复请求。这里要重新获得的数据包是被检测出丢失或损坏的数据包，被记作FLUTE符号。修复服务器存储已经下载的文件的一个副本。 如果修复服务器拥有被请求的数据包的话，修复服务器把被请求的数据包发送给终端。移动终端通过返回信道把数据包失败信息发送给文件服务器。在下文中，我们对数据包失败信息做了定义。
9
图2示出了移动终端1. 7。根据实施例，它是兼容IP数据广播标准的终端。它包括通信模块对，用于接收来自广播网络，尤其是DVB-H网络的数据，以及用于在返回信道上，尤其是蜂窝网络，发送和接收数据。它还包括存储模块22，用于存储从广播信道接收的数据，这些数据包括FDT和ESG信息。该终端还包括处理模块21，和用于在各个模块间通信的内部总线26。该终端还包括文件接收计算模块25，用于执行如上面所阐述的对文件接收的检测。该终端还包括文件接收报告模块23，用于向文件服务器报告接收到的或者没有接收到的文件。尤其是，文件接收报告模块向修复服务器发送前面描述的请求。它还包括一个选择模块26，用于选择上文中描述的请求服务器使用的传输模式。在发送给修复服务器的修复请求中指示传输模式。在说明书、权利要求书和附图中提供的参考能够单独地提供或者适当地组合提供。如果可以的话，这些特征能够通过硬件、软件或者两者的结合来实现。对实施例的参考意味着实施例的某个特征、结构或者特性能够在本发明的至少一个实现方式中实现。在
具体实施方式
中多处出现的“在一个实施例中“的短语并不意味着指向同一个实施例，也不是与其它实施例相排斥的单独的实施例或者可选择的实施例。权利要求书中出现的附图参考标记仅为了说明目的，不应该对权利要求的保护范围有限制影响。
权利要求
1.在接收端(1.7)的用于请求丢失的符号的方法，所述方法包括步骤从文件服务器(1. 1)接收至少一个修复服务器(1. 2)和被所述至少一个修复服务器的每一个使用的至少一个传输模式的列表； 从第二服务器接收包括很多符号的文件； 对符号的正确接收与否进行检测；和如果识别出有丢失的符号，选择一个修复服务器和一种传输模式，并请求所述修复服务器使用所述传输模式传输丢失的符号。
2.如权利要求1所述的方法，所述传输模式是点到点模式和/或广播模式。
3.如前述权利要求的任何一个所述的方法，所请求的传输模式基于传输成本和/或广播接收质量。
4.如权利要求3所述的方法，包括，在请求步骤之前的对广播接收质量进行的接收质量测量步骤。
5.如前述权利要求的任何一个所述的方法，所述列表被包括在 associatedProcedureDescription 白勺 XML 文件中。
6.如前述权利要求的任何一个所述的方法，根据FLUTE协议对所述文件进行接收。
7.一种接收器(1.7)，包括通信装置(M)，用于从广播网络接收数据以及用于在双向网络中通信； 文件接收计算装置(25)，当从广播网络中接收一个包括很多符号的文件时，用于对在广播网络上的符号的正确接收与否进行检测；选择装置( )，用于从包括至少一个修复服务器和被所述至少一个修复服务器使用的至少一个传输模式的列表中选择一个修复服务器和一个传输模式；以及文件接收报告装置(23)，用于在所述双向网络上向所述修复服务器发送一个请求所述修复服务器使用所述传输模式传输丢失的符号的请求。
8.如权利要求7所述的接收器，所述通信装置被用于接收包括至少一个修复服务器和被所述至少一个修复服务器使用的至少一个传输模式的列表。
9.一种计算机程序产品，其特征在于，当所述程序在电脑上执行的时候，它包括用于执行根据权利要求1到6的任一权利要求的步骤的程序代码指令。
10.一种associatedProcedureDescription类型的XML配置文件，包括包括至少一个修复服务器(1. 和被所述至少一个修复服务器使用的至少一个传输模式的列表。
全文摘要
本发明涉及一种接收器终端和在接收器端的用于向修复服务器请求丢失的符号的方法。该方法包括如下步骤接收包括至少一个修复服务器和被所述至少一个修复服务器使用的至少一个传输模式的列表；从第二服务器接收包括很多符号的文件；对符号的正确接收与否进行检测；和如果识别出有丢失的符号，选择一个修复服务器和一种传输模式，并请求所述修复服务器使用所述传输模式传输丢失的符号。
文档编号H04L29/06GK102177694SQ200980140190
公开日2011年9月7日 申请日期2009年10月9日 优先权日2008年10月10日
发明者樊尚·阿洛姆, 赫尔穆特·比尔克林 申请人:汤姆逊许可公司