專(zhuān)利名稱(chēng)：用于請(qǐng)求文件修復(fù)分發(fā)模式的方法
技術(shù)領(lǐng)域：
本發(fā)明一般涉及文件修復(fù)機(jī)制，尤其涉及一種用于請(qǐng)求文件修復(fù)分發(fā)模式的方法。
背景技術(shù)：
本部分用于向讀者介紹技術(shù)的各個(gè)方面，它們與下文中介紹和/或請(qǐng)求保護(hù)的本發(fā)明的各個(gè)方面相關(guān)。這部分介紹向讀者提供了背景技術(shù)信息，從而有利于了解本發(fā)明的各個(gè)方面。相應(yīng)地，應(yīng)當(dāng)認(rèn)識(shí)到這些介紹主要是為了方便讀者了解本發(fā)明的各個(gè)方面，而不應(yīng)該作為對(duì)現(xiàn)有技術(shù)的承認(rèn)。IETF RFC 3擬6定義了單向文件傳輸協(xié)議(file delivery over unidirectional transport)，縮寫(xiě)為FLUTE。在這個(gè)標(biāo)準(zhǔn)中的協(xié)議很好的解決了用戶數(shù)量的擴(kuò)展問(wèn)題和用戶支持的帶寬的異構(gòu)(heterogeneity)問(wèn)題。DVB-H IP數(shù)據(jù)廣播標(biāo)準(zhǔn)是《ETSI TS 102 472 VL 2. 1(2006-12)，數(shù)字視頻廣播(Digital Video Broadcasting, DVB)；在 DVB-H 上的 IP 數(shù)據(jù)廣；內(nèi)容傳輸協(xié)議(Content Delivery Protocols，CDP)》。以下記為CDP標(biāo)準(zhǔn)。它定義了文件修復(fù)機(jī)制。該機(jī)制在第二篇文件中詳細(xì)闡述，即ETSI TS 102 591 1.1.1，數(shù)字視頻廣播；DVB-H上的IP數(shù)據(jù)廣播；內(nèi)容傳輸協(xié)議實(shí)現(xiàn)指導(dǎo)書(shū)。在DVB-H IP數(shù)據(jù)廣播標(biāo)準(zhǔn)中采用的文件修復(fù)策略是單一級(jí)別的文件修復(fù)策略，并且它采用了集中的客戶-服務(wù)器“文件修復(fù)“模式。它使用文件修復(fù)機(jī)制來(lái)幫助FLUTE協(xié)議在廣播/組播網(wǎng)絡(luò)上實(shí)現(xiàn)可靠的文件傳輸。一旦檢測(cè)到接收了一個(gè)不完整的文件，F(xiàn)LUTE 接收端啟動(dòng)文件修復(fù)機(jī)制。它包括請(qǐng)求丟失或損壞的數(shù)據(jù)包。根據(jù)FLUTE的術(shù)語(yǔ)表，這些數(shù)據(jù)包被命名為符號(hào)(symbol)。通過(guò)使用點(diǎn)到點(diǎn)(Point to Point,P2P)連接把請(qǐng)求發(fā)送到修復(fù)文件服務(wù)器。請(qǐng)求中基本包括要被修復(fù)的文件的名字和丟失符號(hào)的列表。在這樣的系統(tǒng)中，可以同時(shí)存在多個(gè)修復(fù)服務(wù)器，每一個(gè)修復(fù)服務(wù)器包括一個(gè)或多個(gè)修復(fù)服務(wù)。所有可能的修復(fù)服務(wù)列表在“相關(guān)傳輸過(guò)程配置文件”中被記載。這是一個(gè)XML文件，它包括每一個(gè)可以使用的修復(fù)服務(wù)的URL。當(dāng)需要修復(fù)服務(wù)器的時(shí)候，客戶端隨機(jī)地選擇其中的一個(gè)服務(wù)，并且通過(guò)點(diǎn)到點(diǎn)連接發(fā)送一個(gè)包括要請(qǐng)求符號(hào)列表的修復(fù)請(qǐng)求。修復(fù)服務(wù)或者通過(guò)點(diǎn)到點(diǎn)連接發(fā)送部分或者所有要請(qǐng)求符號(hào)，或者把請(qǐng)求重定向到一個(gè)不同的服務(wù)。這個(gè)重定向可能不是指示另一個(gè)修復(fù)服務(wù)器，而是指示一個(gè)FLUTE會(huì)話描述，在這個(gè)FLUTE會(huì)話上丟失的或損壞的符號(hào)要被重新廣播。文件修復(fù)過(guò)程由客戶端通過(guò)點(diǎn)到點(diǎn)連接啟動(dòng)，并且進(jìn)一步使用點(diǎn)到點(diǎn)連接、廣播信道或者兩者混合來(lái)實(shí)現(xiàn)?？蛻舳苏?qǐng)求所有丟失的符號(hào)。在分析符號(hào)列表之后，修復(fù)服務(wù)器選擇分發(fā)模式。為了能夠有效地利用資源，一些符號(hào)通過(guò)廣播連接分發(fā)，而其它的則通過(guò)點(diǎn)到點(diǎn)連接發(fā)送。如下介紹了一個(gè)使用點(diǎn)到點(diǎn)連接和廣播連接的文件修復(fù)的例子。客戶端發(fā)送修復(fù)查詢到服務(wù)器。然后，響應(yīng)于修復(fù)請(qǐng)求，服務(wù)器通過(guò)點(diǎn)到點(diǎn)連接發(fā)送被請(qǐng)求符號(hào)的子集。然后修復(fù)客戶端向修復(fù)服務(wù)器發(fā)送請(qǐng)求仍然丟失的符號(hào)的第二請(qǐng)求(這里可能與前一個(gè)類(lèi)似)。這一次，修復(fù)服務(wù)器把請(qǐng)求重定向到可能能夠修復(fù)剩余符號(hào)的廣播會(huì)話。當(dāng)一個(gè)符號(hào)被多個(gè)客戶端請(qǐng)求的時(shí)候，使用廣播信道分發(fā)的好處是使用了較少的資源。但是，在有些情況下，其就不是最好的解決方案。例如，如果終端僅僅能防問(wèn)點(diǎn)到點(diǎn)網(wǎng)絡(luò)(在失去對(duì)廣播信道的防問(wèn)之后)，它就不能接收在廣播信道分發(fā)的任何內(nèi)容。在上面描述的混合修復(fù)的例子中，終端不能夠收到修復(fù)查詢中請(qǐng)求的所有符號(hào)，這是因?yàn)橹挥幸迯?fù)符號(hào)的一部分是在點(diǎn)到點(diǎn)網(wǎng)絡(luò)上分發(fā)，而其它的是在廣播網(wǎng)絡(luò)中分發(fā)。因此，需要一種修復(fù)方法使得設(shè)備能夠以特定的方式來(lái)接收內(nèi)容(僅僅點(diǎn)到點(diǎn)，混合模式等等)，或者在某種特定網(wǎng)絡(luò)上接收內(nèi)容，例如，通過(guò)兩個(gè)不同的點(diǎn)到點(diǎn)連接來(lái)連接中終端。

發(fā)明內(nèi)容
本發(fā)明通過(guò)提供一種方法讓接收器向服務(wù)器指示希望的分發(fā)模式，來(lái)試圖解決現(xiàn)有技術(shù)中修復(fù)文件分發(fā)中的一些問(wèn)題。本發(fā)明涉及在接收器端的用于向修復(fù)服務(wù)器請(qǐng)求丟失的符號(hào)的方法。該方法包括如下步驟接收包括至少一個(gè)修復(fù)服務(wù)器和被所述至少一個(gè)修復(fù)服務(wù)器使用的至少一個(gè)傳輸模式的列表；從第二服務(wù)器接收包括很多符號(hào)的文件；對(duì)符號(hào)的正確接收與否進(jìn)行檢測(cè)；和如果識(shí)別出有丟失的符號(hào)，選擇一個(gè)修復(fù)服務(wù)器和一種傳輸模式，并請(qǐng)求所述修復(fù)服務(wù)器使用所述傳輸模式傳輸丟失的符號(hào)。有利地，接收器獲得修復(fù)服務(wù)器及每一個(gè)修復(fù)服務(wù)器能夠使用的傳輸模式的列表。接收器能夠向修復(fù)服務(wù)器指示它希望修復(fù)服務(wù)器使用的傳輸模式，從而能夠優(yōu)化來(lái)自修復(fù)服務(wù)器的數(shù)據(jù)接收。根據(jù)本發(fā)明的一個(gè)實(shí)施例，傳輸模式是點(diǎn)到點(diǎn)模式和/或廣播模式。當(dāng)處于廣播接收質(zhì)量很低的區(qū)域時(shí)，接收器可以請(qǐng)求點(diǎn)到點(diǎn)傳輸模式。如果廣播質(zhì)量接收沒(méi)有那么低的時(shí)候，接收器可以請(qǐng)求廣播模式，或者使用廣播和點(diǎn)到點(diǎn)的混合模式。根據(jù)本發(fā)明的一個(gè)實(shí)施例，所請(qǐng)求的傳輸模式基于傳輸成本和/或廣播接收質(zhì)量。接收器預(yù)先知道傳輸成本。如果使用點(diǎn)到點(diǎn)模式成本很高，接收器會(huì)明智地不使用該模式。根據(jù)本發(fā)明的一個(gè)實(shí)施例，該方法包括在請(qǐng)求步驟之前的對(duì)廣播接收質(zhì)量進(jìn)行的接收質(zhì)量測(cè)量步驟。根據(jù)本發(fā)明的一個(gè)實(shí)施例，列表被包括在associatedProcedureDescription的 XML文件中。根據(jù)本發(fā)明的一個(gè)實(shí)施例，根據(jù)FLUTE協(xié)議對(duì)所述文件進(jìn)行接收。本發(fā)明還提出了一種接收器。包括通信裝置，用于從廣播網(wǎng)絡(luò)接收數(shù)據(jù)以及用于在雙向網(wǎng)絡(luò)中通信；文件接收計(jì)算裝置，用于當(dāng)從廣播網(wǎng)絡(luò)中接收一個(gè)包括很多符號(hào)的文件時(shí)，對(duì)在廣播網(wǎng)絡(luò)上的符號(hào)的正確接收與否進(jìn)行檢測(cè)；選擇裝置，用于從包括至少一個(gè)修復(fù)服務(wù)器和被所述至少一個(gè)修復(fù)服務(wù)器使用的至少一個(gè)傳輸模式的列表中選擇一個(gè)修復(fù)服務(wù)器和一個(gè)傳輸模式；以及文件接收?qǐng)?bào)告裝置，用于在所述雙向網(wǎng)絡(luò)上向所述修復(fù)服務(wù)器發(fā)送一個(gè)請(qǐng)求所述修復(fù)服務(wù)器使用所述傳輸模式傳輸丟失的符號(hào)的請(qǐng)求。根據(jù)本發(fā)明的一個(gè)實(shí)施例，通信裝置被用于接收包括至少一個(gè)修復(fù)服務(wù)器和被所述至少一個(gè)修復(fù)服務(wù)器使用的至少一個(gè)傳輸模式的列表。本發(fā)明還提出了一種計(jì)算機(jī)程序產(chǎn)品，當(dāng)程序在電腦上執(zhí)行的時(shí)候，它包括用于執(zhí)行根據(jù)本發(fā)明的方法的步驟的程序代碼指令。這里所說(shuō)的計(jì)算機(jī)程序產(chǎn)品，它指的計(jì)算機(jī)程序支持，它不僅包括存儲(chǔ)程序的存儲(chǔ)空間，例如磁盤(pán)或磁帶，還包括信號(hào)，如電信號(hào)或光信號(hào)。本發(fā)明還提出了一種associatedProcedureDescription類(lèi)型的XML配置文件，包括包括至少一個(gè)修復(fù)服務(wù)器和被所述至少一個(gè)修復(fù)服務(wù)器使用的至少一個(gè)傳輸模式的列表。如下對(duì)實(shí)施例的各個(gè)方面進(jìn)行描述。應(yīng)當(dāng)了解，這些方面僅僅用于向讀者介紹本發(fā)明可能采取一些形式，因此不應(yīng)該被用于限定本發(fā)明的范圍。實(shí)際上，本發(fā)明應(yīng)該包括許多下文中沒(méi)有介紹的方面。


通過(guò)結(jié)合附圖來(lái)對(duì)下面的具體實(shí)施例和執(zhí)行例子進(jìn)行描述，可以更好地了解本發(fā)明。其中圖1示出一個(gè)具體實(shí)施例的系統(tǒng)；和圖2示出了根據(jù)該具體實(shí)施例的移動(dòng)終端。在圖1和圖2中，示出的功能塊僅僅是功能實(shí)體，并不一定需要和物理上分開(kāi)的實(shí)體相對(duì)應(yīng)。即，它們能夠通過(guò)硬件或軟件來(lái)實(shí)現(xiàn)，或者在一個(gè)或多個(gè)集成電路中實(shí)現(xiàn)。
具體實(shí)施例方式在DVB-H IP數(shù)據(jù)廣播中的文件修復(fù)框架中描述實(shí)例的實(shí)施例，但是本發(fā)明并不局限于該環(huán)境，并且能夠應(yīng)用于其它的接收方請(qǐng)求服務(wù)器在多種傳輸模式下發(fā)送內(nèi)容的框架中。在第一實(shí)施例中，存在多個(gè)修復(fù)服務(wù)。一種文件修復(fù)服務(wù)獨(dú)占點(diǎn)到點(diǎn)信道。它通過(guò)在URI以字符串“/p2p_0nly”結(jié)束來(lái)標(biāo)記。另一種修復(fù)服務(wù)使用廣播信道。它通過(guò)以字符串“/bcst_only”結(jié)束來(lái)標(biāo)記。另一種修復(fù)服務(wù)使用廣播信道或點(diǎn)到點(diǎn)信道。這是一種混合服務(wù)，通過(guò)字符串“/hyprid”來(lái)標(biāo)記。如果以后有別的網(wǎng)絡(luò)可以被修復(fù)服務(wù)使用，那么可以別的字符串來(lái)區(qū)分它們，例如，/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結(jié)構(gòu)，用于把有效的修復(fù)服務(wù)的URL通知給終端。 此外，DVB-CBMS之中也定義了一種XML結(jié)構(gòu)。文件修復(fù)過(guò)程被描述成一種相關(guān)文件傳輸過(guò)程(和相關(guān)文件傳輸會(huì)話相關(guān))，并且在文件傳輸會(huì)話開(kāi)始之前，通過(guò)使用特定的XML結(jié)構(gòu)把相關(guān)信息提供給文件接收端。一個(gè)示例的配置文件有如下的形式< 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〉在客戶端通過(guò)廣播或這點(diǎn)到點(diǎn)模式來(lái)接收的正常的覆蓋情況下，客戶端通過(guò)發(fā)送請(qǐng)求到給出的4個(gè)URI中隨機(jī)的一個(gè)來(lái)請(qǐng)求修復(fù)符號(hào)。下面介紹一個(gè)請(qǐng)求的示例。終端使用HTTP協(xié)議提交修復(fù)請(qǐng)求。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終端可能現(xiàn)在處在一個(gè)特別的情況下，如它僅能夠通過(guò)所有傳輸模式或傳輸信道的一個(gè)子集進(jìn)行接收修復(fù)符號(hào)。可以通過(guò)很多方法來(lái)檢測(cè)在一個(gè)信道上的低的信號(hào)接收水平、高錯(cuò)誤率或者低數(shù)據(jù)速率，或者禁止成本(prohibitive cost)。也有可能是它能預(yù)測(cè)出這種情況，因?yàn)樗鼨z測(cè)到子集處于覆蓋范圍的邊緣。如果終端確定當(dāng)前的情況僅僅允許通過(guò)點(diǎn)到點(diǎn)連接來(lái)接收修復(fù)符號(hào)，它從修復(fù)服務(wù)列表中選取一個(gè)為“僅僅點(diǎn)到點(diǎn)修復(fù)”的修復(fù)服務(wù)。在這種情況下的修復(fù)請(qǐng)求是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在第二實(shí)施例中，XML架構(gòu)(XML scheme)被修改。XML架構(gòu)中增加修復(fù)服務(wù)器支持的修復(fù)模式。它是一個(gè)XML屬性，對(duì)每一個(gè)修復(fù)服務(wù)器使用XML配置樹(shù)進(jìn)行描述。屬性值在如下值中選擇僅僅點(diǎn)到點(diǎn)；點(diǎn)到點(diǎn)和廣播修復(fù)混合，或者僅僅廣播修復(fù)。屬性值可以被擴(kuò)展用于指定以后可能的傳輸信道，例如Wi-Fi，Wimax0它的好處在于減少了對(duì)XML配置模型的改變。接收端知道默認(rèn)的修復(fù)服務(wù)器行為(僅僅P2P修復(fù)，混合修復(fù)或僅僅廣播)。默認(rèn)的修復(fù)服務(wù)器行為最好是混合修復(fù)模式。如果選項(xiàng)信息沒(méi)有被提供，接收端則認(rèn)為修復(fù)服務(wù)器可以使用3種模式(僅僅 P2P、混合模式、僅僅廣播)中的任何一種。
在DVB-CBMS中實(shí)現(xiàn)上述修改后的架構(gòu)的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>對(duì)第二實(shí)施例的一個(gè)變形實(shí)施例是允許文件接收端獲取超過(guò)一個(gè)修復(fù)服務(wù)器列表的描述的XML架構(gòu)，每一個(gè)列表都有明確的修復(fù)模式能力描述。一個(gè)列表是關(guān)于僅僅提供點(diǎn)到點(diǎn)的修復(fù)服務(wù)器，另一個(gè)列表是關(guān)于提供混合修復(fù)(點(diǎn)到點(diǎn)和廣播)的修復(fù)服務(wù)器， 或者是關(guān)于僅僅提供廣播修復(fù)的修復(fù)服務(wù)器。 在DVB-CBMS環(huán)境中的XML架構(gòu)示例如下所示
< 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〉第三實(shí)施例在HTTP擴(kuò)展頭中指示修復(fù)模式。用于HTTP1. 1的IETF RFC 2616定義了 HTTP擴(kuò)展頭。接收端對(duì)修復(fù)請(qǐng)求增加一個(gè)比壓頭(specific header)來(lái)通知修復(fù)模式類(lèi)型(僅僅P2P、混合模式或者僅僅廣播)。如果這個(gè)增強(qiáng)的修復(fù)請(qǐng)求被與傳統(tǒng)的HTTP1. 1兼容的修復(fù)服務(wù)器接收，它僅會(huì)被當(dāng)作擴(kuò)展頭并被服務(wù)器忽視。下面示出了在OMA BCAST環(huán)境下一個(gè)擴(kuò)展的修復(fù)查詢的例子，它使用了一個(gè)新的頭域 ItepairMode 來(lái)提供 3 個(gè)選項(xiàng)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第三個(gè)實(shí)施例的第一個(gè)變形是使用允許的修復(fù)模式和信道(3G-P2P、Wifi_P2P和 DVB-H-BCAST)的列表來(lái)作為域值，在列表中使用逗號(hào)來(lái)分隔。之前描述的例子現(xiàn)在變?yōu)?br> 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第三實(shí)施例的第二個(gè)變形是在修復(fù)請(qǐng)求中增加首選的修復(fù)模式。通過(guò)增加參數(shù)(例如ItepairMode)來(lái)增強(qiáng)傳統(tǒng)的HTTP修復(fù)。它被關(guān)聯(lián)到3個(gè)可能的值來(lái)為查詢指示首選的修復(fù)模式僅僅P2P、混合修復(fù)或者僅僅廣播。下面為在OMA BCAST環(huán)境中一個(gè)擴(kuò)展的修復(fù)查詢的例子。它使用了一個(gè)新的參數(shù) RepairMode 來(lái)提供 3 個(gè)選項(xiàng)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第三實(shí)施例的第三個(gè)變形是使用請(qǐng)求中的頭域和響應(yīng)中的特殊頭。如果客戶端發(fā)送消息通知它已經(jīng)準(zhǔn)備好接受混合或者廣播修復(fù)(在該例中為了向后兼容)，服務(wù)器則在響應(yīng)的頭中指示用于廣播修復(fù)的會(huì)話信息。這樣就減少了在混合修復(fù)模式中服務(wù)器和客戶端之間交互的數(shù)量。也就不需要客戶端發(fā)送第二個(gè)請(qǐng)求來(lái)獲得可能是動(dòng)態(tài)的廣播會(huì)話的信肩、ο根據(jù)本發(fā)明的一個(gè)變形，對(duì)應(yīng)于第三實(shí)施例的請(qǐng)求或第三實(shí)施例的第一變形的請(qǐng)求的響應(yīng)為HTTP/1. 1 200 OKContent-Type !application/simpIeSymboIContainerBcastSDP :http://www. example, com/ipdc/sessionl. sdp〈followed by the payload>它指出在響應(yīng)消息的主體(通過(guò)點(diǎn)到點(diǎn)連接)中沒(méi)被提供的所有被請(qǐng)求的符號(hào)將會(huì)通過(guò)指示的廣播會(huì)話提供。圖1示出了根據(jù)本實(shí)施例的用于視頻分發(fā)的系統(tǒng)。視頻廣播系統(tǒng)1.6適應(yīng)如下標(biāo)準(zhǔn):"ETSI TR 102 469 VI. 1. 1 (2006-05)，“數(shù)字視頻廣播(DVB) ；DVB-H 上的 IP 數(shù)據(jù)廣播 體系”。如下被記為IP數(shù)據(jù)廣播標(biāo)準(zhǔn)。該系統(tǒng)也適應(yīng)如下標(biāo)準(zhǔn)“ETSI TS 102 472 VI. 2. 1 (2006-12)，“數(shù)字視頻廣播 (DVB) ；DVB-H上的IP數(shù)據(jù)廣播內(nèi)容傳輸協(xié)議”。以下被記為⑶P標(biāo)準(zhǔn)。文件服務(wù)器1. 1依據(jù)⑶P標(biāo)準(zhǔn)和FLUTE協(xié)議發(fā)送數(shù)據(jù)文件。通過(guò)IP網(wǎng)絡(luò)1. 3和 DVB-H廣播網(wǎng)絡(luò)1. 6數(shù)據(jù)文件被傳輸?shù)揭苿?dòng)終端1.7。IP網(wǎng)絡(luò)可以是任何支持組播傳輸?shù)?IP網(wǎng)絡(luò)，例如Internet。DVB-H傳輸網(wǎng)絡(luò)包括DVB-H IP封裝器(IPE) 1. 4和DVB-H發(fā)送器 1.5。當(dāng)然，本實(shí)施例不局限于DVB-H網(wǎng)絡(luò)。它適用于其它任何寬帶分發(fā)網(wǎng)絡(luò)，例如數(shù)字用戶線家族。系統(tǒng)還包括通過(guò)蜂窩網(wǎng)絡(luò)1. 8或者熱點(diǎn)網(wǎng)絡(luò)1. 9的返回信道。移動(dòng)終端可以通過(guò)返回信道接收和發(fā)送數(shù)據(jù)，尤其是交互數(shù)據(jù)。當(dāng)然，返回信道可以是其它任何提供點(diǎn)到點(diǎn)雙向連接的信道。這個(gè)系統(tǒng)是與CDP標(biāo)準(zhǔn)定義的DVB-H相關(guān)的簡(jiǎn)化的文件修復(fù)架構(gòu)。為了重新獲得數(shù)據(jù)包，終端向修復(fù)服務(wù)器1. 2提交修復(fù)請(qǐng)求。這里要重新獲得的數(shù)據(jù)包是被檢測(cè)出丟失或損壞的數(shù)據(jù)包，被記作FLUTE符號(hào)。修復(fù)服務(wù)器存儲(chǔ)已經(jīng)下載的文件的一個(gè)副本。 如果修復(fù)服務(wù)器擁有被請(qǐng)求的數(shù)據(jù)包的話，修復(fù)服務(wù)器把被請(qǐng)求的數(shù)據(jù)包發(fā)送給終端。移動(dòng)終端通過(guò)返回信道把數(shù)據(jù)包失敗信息發(fā)送給文件服務(wù)器。在下文中，我們對(duì)數(shù)據(jù)包失敗信息做了定義。
9
圖2示出了移動(dòng)終端1. 7。根據(jù)實(shí)施例，它是兼容IP數(shù)據(jù)廣播標(biāo)準(zhǔn)的終端。它包括通信模塊對(duì)，用于接收來(lái)自廣播網(wǎng)絡(luò)，尤其是DVB-H網(wǎng)絡(luò)的數(shù)據(jù)，以及用于在返回信道上，尤其是蜂窩網(wǎng)絡(luò)，發(fā)送和接收數(shù)據(jù)。它還包括存儲(chǔ)模塊22，用于存儲(chǔ)從廣播信道接收的數(shù)據(jù)，這些數(shù)據(jù)包括FDT和ESG信息。該終端還包括處理模塊21，和用于在各個(gè)模塊間通信的內(nèi)部總線26。該終端還包括文件接收計(jì)算模塊25，用于執(zhí)行如上面所闡述的對(duì)文件接收的檢測(cè)。該終端還包括文件接收?qǐng)?bào)告模塊23，用于向文件服務(wù)器報(bào)告接收到的或者沒(méi)有接收到的文件。尤其是，文件接收?qǐng)?bào)告模塊向修復(fù)服務(wù)器發(fā)送前面描述的請(qǐng)求。它還包括一個(gè)選擇模塊26，用于選擇上文中描述的請(qǐng)求服務(wù)器使用的傳輸模式。在發(fā)送給修復(fù)服務(wù)器的修復(fù)請(qǐng)求中指示傳輸模式。在說(shuō)明書(shū)、權(quán)利要求書(shū)和附圖中提供的參考能夠單獨(dú)地提供或者適當(dāng)?shù)亟M合提供。如果可以的話，這些特征能夠通過(guò)硬件、軟件或者兩者的結(jié)合來(lái)實(shí)現(xiàn)。對(duì)實(shí)施例的參考意味著實(shí)施例的某個(gè)特征、結(jié)構(gòu)或者特性能夠在本發(fā)明的至少一個(gè)實(shí)現(xiàn)方式中實(shí)現(xiàn)。在具體實(shí)施方式
中多處出現(xiàn)的“在一個(gè)實(shí)施例中“的短語(yǔ)并不意味著指向同一個(gè)實(shí)施例，也不是與其它實(shí)施例相排斥的單獨(dú)的實(shí)施例或者可選擇的實(shí)施例。權(quán)利要求書(shū)中出現(xiàn)的附圖參考標(biāo)記僅為了說(shuō)明目的，不應(yīng)該對(duì)權(quán)利要求的保護(hù)范圍有限制影響。
權(quán)利要求
1.在接收端(1.7)的用于請(qǐng)求丟失的符號(hào)的方法，所述方法包括步驟從文件服務(wù)器(1. 1)接收至少一個(gè)修復(fù)服務(wù)器(1. 2)和被所述至少一個(gè)修復(fù)服務(wù)器的每一個(gè)使用的至少一個(gè)傳輸模式的列表； 從第二服務(wù)器接收包括很多符號(hào)的文件； 對(duì)符號(hào)的正確接收與否進(jìn)行檢測(cè)；和如果識(shí)別出有丟失的符號(hào)，選擇一個(gè)修復(fù)服務(wù)器和一種傳輸模式，并請(qǐng)求所述修復(fù)服務(wù)器使用所述傳輸模式傳輸丟失的符號(hào)。
2.如權(quán)利要求1所述的方法，所述傳輸模式是點(diǎn)到點(diǎn)模式和/或廣播模式。
3.如前述權(quán)利要求的任何一個(gè)所述的方法，所請(qǐng)求的傳輸模式基于傳輸成本和/或廣播接收質(zhì)量。
4.如權(quán)利要求3所述的方法，包括，在請(qǐng)求步驟之前的對(duì)廣播接收質(zhì)量進(jìn)行的接收質(zhì)量測(cè)量步驟。
5.如前述權(quán)利要求的任何一個(gè)所述的方法，所述列表被包括在 associatedProcedureDescription 白勺 XML 文件中。
6.如前述權(quán)利要求的任何一個(gè)所述的方法，根據(jù)FLUTE協(xié)議對(duì)所述文件進(jìn)行接收。
7.一種接收器(1.7)，包括通信裝置(M)，用于從廣播網(wǎng)絡(luò)接收數(shù)據(jù)以及用于在雙向網(wǎng)絡(luò)中通信； 文件接收計(jì)算裝置(25)，當(dāng)從廣播網(wǎng)絡(luò)中接收一個(gè)包括很多符號(hào)的文件時(shí)，用于對(duì)在廣播網(wǎng)絡(luò)上的符號(hào)的正確接收與否進(jìn)行檢測(cè)；選擇裝置( )，用于從包括至少一個(gè)修復(fù)服務(wù)器和被所述至少一個(gè)修復(fù)服務(wù)器使用的至少一個(gè)傳輸模式的列表中選擇一個(gè)修復(fù)服務(wù)器和一個(gè)傳輸模式；以及文件接收?qǐng)?bào)告裝置(23)，用于在所述雙向網(wǎng)絡(luò)上向所述修復(fù)服務(wù)器發(fā)送一個(gè)請(qǐng)求所述修復(fù)服務(wù)器使用所述傳輸模式傳輸丟失的符號(hào)的請(qǐng)求。
8.如權(quán)利要求7所述的接收器，所述通信裝置被用于接收包括至少一個(gè)修復(fù)服務(wù)器和被所述至少一個(gè)修復(fù)服務(wù)器使用的至少一個(gè)傳輸模式的列表。
9.一種計(jì)算機(jī)程序產(chǎn)品，其特征在于，當(dāng)所述程序在電腦上執(zhí)行的時(shí)候，它包括用于執(zhí)行根據(jù)權(quán)利要求1到6的任一權(quán)利要求的步驟的程序代碼指令。
10.一種associatedProcedureDescription類(lèi)型的XML配置文件，包括包括至少一個(gè)修復(fù)服務(wù)器(1. 和被所述至少一個(gè)修復(fù)服務(wù)器使用的至少一個(gè)傳輸模式的列表。
全文摘要
本發(fā)明涉及一種接收器終端和在接收器端的用于向修復(fù)服務(wù)器請(qǐng)求丟失的符號(hào)的方法。該方法包括如下步驟接收包括至少一個(gè)修復(fù)服務(wù)器和被所述至少一個(gè)修復(fù)服務(wù)器使用的至少一個(gè)傳輸模式的列表；從第二服務(wù)器接收包括很多符號(hào)的文件；對(duì)符號(hào)的正確接收與否進(jìn)行檢測(cè)；和如果識(shí)別出有丟失的符號(hào)，選擇一個(gè)修復(fù)服務(wù)器和一種傳輸模式，并請(qǐng)求所述修復(fù)服務(wù)器使用所述傳輸模式傳輸丟失的符號(hào)。
文檔編號(hào)H04L29/06GK102177694SQ200980140190
公開(kāi)日2011年9月7日 申請(qǐng)日期2009年10月9日 優(yōu)先權(quán)日2008年10月10日
發(fā)明者樊尚·阿洛姆, 赫爾穆特·比爾克林 申請(qǐng)人:湯姆遜許可公司