專利名稱：用于多點播送或廣播中的增強型文件分布的方法和設備的制作方法
技術(shù)領(lǐng)域：
本發(fā)明大體上涉及數(shù)據(jù)通信，且更明確地說涉及多點播送或多點播送環(huán)境中數(shù)據(jù)通 信系統(tǒng)中的增強型文件分布。
背景技術(shù)：
全球網(wǎng)絡互連使得不管地理距離如何都能快速地存取信息。圖1展示由參考標號20 表示的一般稱為因特網(wǎng)的全球網(wǎng)絡連接的簡化示意圖。因特網(wǎng)20本質(zhì)上為許多具有鏈接 在一起的不同級別的階層架構(gòu)的網(wǎng)絡。因特網(wǎng)20在由因特網(wǎng)工程工作小組(IETF)發(fā)布 的因特網(wǎng)協(xié)議(IP)下操作。IP的細節(jié)可查閱由正TF發(fā)行的意見請求(Request for Comments' RFC) 791。
連接到因特網(wǎng)20的為各種個別網(wǎng)絡，其取決于網(wǎng)絡尺寸而有時稱為局域網(wǎng)(LAN) 或廣域網(wǎng)(WAN)。圖1中展示某些此種網(wǎng)絡22、 24和26。
在網(wǎng)絡22、 24和26的每一者內(nèi)，可存在彼此連接且彼此通信的各件設備。僅舉出 的幾個實例為計算機、打印機和服務器，其一般稱為節(jié)點。當節(jié)點經(jīng)由因特網(wǎng)20在其自 身網(wǎng)絡以外通信時，節(jié)點需要依據(jù)IP將數(shù)據(jù)包發(fā)送到其它網(wǎng)絡中的相應節(jié)點。類似地， 由其它網(wǎng)絡中相應節(jié)點發(fā)出到起始節(jié)點的數(shù)據(jù)包也必須符合IP 。
不同類型的應用使得不同級別的協(xié)議有必要結(jié)合IP進行操作。舉幾個實例說明。假 設網(wǎng)絡22中的節(jié)點28試圖從網(wǎng)絡26中的另一節(jié)點30下載文件。對于文件傳送，極為 經(jīng)常地使用稱為文件傳送協(xié)議(FTP)的較高等級協(xié)議。FTP可査閱由IETF發(fā)行的RFC 959。如此，由節(jié)點30發(fā)送到節(jié)點28的數(shù)據(jù)包尤其必須符合FTP和IP。
作為另一實例，假設網(wǎng)絡22中的節(jié)點28經(jīng)由因特網(wǎng)20瀏覽由網(wǎng)絡24中的另一節(jié) 點32提出的網(wǎng)站。此時，節(jié)點28和32可能使用另一較高等級協(xié)議，稱為超文本傳送協(xié) 議(HTTP)。 HTTP可査閱由正TF發(fā)行的RFC 2616。同樣，所交換的數(shù)據(jù)包尤其必須符合HTTP和IP。
示范性協(xié)議FTP和HTTP經(jīng)由稱為傳輸控制協(xié)議(TCP)的另一中間級別協(xié)議來承 載。TCP可查閱RFC 793。在TCP下，目標為準確地傳輸數(shù)據(jù)。如此，錯誤數(shù)據(jù)始終被 重新傳輸。TCP和依靠TCP的協(xié)議(例如FTP禾B HTTP) —般用于一對一應用。
技術(shù)發(fā)展使得數(shù)據(jù)密集的數(shù)據(jù)傳送成為可能。舉例來說，能夠處理高帶寬的網(wǎng)絡允 許多媒體文件交換，例如通常保存大量數(shù)據(jù)的音頻和視頻文件。當大量節(jié)點接收所述多 媒體文件時，經(jīng)由常規(guī)單點播送方法進行的文件傳遞可能效率較低。文件尤其首先需經(jīng) 復制且隨后個別地傳遞到每一節(jié)點。因此，需要開發(fā)適用于廣播或多點播送服務的其它 類型的協(xié)議來解決對于一對多應用的增加的需要。
為了滿足所述需要，己設計了特定地適于多點播送文件分布應用的單向傳送文件傳 遞(FLUTE)協(xié)議。FLUTE協(xié)議可查閱2003年11月14日由正TF發(fā)行的題為"FLUTE-File Delivery over Unidirectional Transport"的RFC 3926。在多點播送對話中，業(yè)務流或多或 少地為單向的。g卩，如果根本上存在的話，反向數(shù)據(jù)業(yè)務受到限制。所述單向使用在存 在一個將數(shù)據(jù)發(fā)送到許多接收器的通信源的廣播或多點播送應用中較常見。
在FLUTE協(xié)議下傳輸?shù)臄?shù)據(jù)承載于用戶數(shù)據(jù)報協(xié)議(UDP)上，而非如在HTTP和 FTP協(xié)議中一樣承載于TCP上。在UDP下，錯誤數(shù)據(jù)通常并不重新發(fā)送。為了進行準 確數(shù)據(jù)傳輸，F(xiàn)LUTE協(xié)議通常以冗余的方式傳輸數(shù)據(jù)并使用錯誤校正方案。
使用FLUTE協(xié)議，在文件傳遞對話期間傳送一個或一個以上文件。文件承載于具有 異步分層編碼(ALC)形式的數(shù)據(jù)包(稱為ALC包)中。視文件長度而定，每一文件可 在一個或一個以上ALC包中傳輸。所述文件稱為對象。可由包含于文件傳遞表(FDT) 中的文件屬性識別對象。在接收器端，依賴文件屬性從ALC包重建原始文件。在正確接 收到相應文件屬性之前不可處理所接收的文件對象。為了實現(xiàn)FDT接收的較高可靠性， 復制的FDT實例(instance)通常插入有發(fā)送到接收器的ALC包中的有效負載數(shù)據(jù)。到 此，F(xiàn)DT和內(nèi)容文件或多或少地同時傳輸。如此，即使正確地接收到內(nèi)容文件(通常情 況并非如此)，接收器也需要正確地接收FDT，從FDT提取文件屬性且隨后處理所接收 的內(nèi)容文件。即，所接收的文件的成功解碼和隨后呈現(xiàn)或多或少地同時取決于處理ALC 包所需的文件屬性的成功下載。所述依賴性不可避免地導致延遲且經(jīng)常不利地影響內(nèi)容 呈現(xiàn)的質(zhì)量。另外，不具有正確文件屬性的用戶極為經(jīng)常地作出多次嘗試以獲得所需文 件屬性，藉此測試通信信道類型。因此，這可能并非對可用通信資源的最有效使用。
因此，需要提供更有效的方案來獲得較佳質(zhì)量的廣播，且另外需要更經(jīng)濟地利用通
信資源。

發(fā)明內(nèi)容
在提供廣播服務的通信系統(tǒng)中，廣播服務中用于廣播的文件可由用戶存取。在一個 通信對話中發(fā)送廣播文件的內(nèi)容。在另一通信對話中單獨發(fā)送處理廣播文件所需的文件 屬性。根據(jù)配置，在內(nèi)容文件之前接收文件屬性使得更有效地下載并處理廣播文件。
所屬領(lǐng)域的技術(shù)人員參看附圖從以下具體實施方式
將易了解這些和其它特征與優(yōu) 點，附圖中相同參考標號表示相同部件。


圖1為全球網(wǎng)絡連接的示意圖2為包含于本發(fā)明的示范性實施例中的節(jié)點和網(wǎng)絡的示意圖； 圖3為展示階層式等級的協(xié)議堆棧的示意圖； 圖3A為FLUTE協(xié)議的更詳細示意表示；
圖4為展示在FLUTE協(xié)議下操作的CFD方法的一套方法的示意圖 圖5為展示根據(jù)本發(fā)明的示范性實施例而操作的CFD方法的示意圖； 圖6為展示在不同時間窗口期間執(zhí)行的文件傳遞和呈現(xiàn)的時序圖； 圖7為展示根據(jù)本發(fā)明的示范性實施例的文件檢索和處理的流程圖； 圖8為展示根據(jù)本發(fā)明的示范性實施例的文件傳遞的流程圖； 圖9為展示示范性緊密ALC數(shù)據(jù)包的示意圖
圖IO為展示適于經(jīng)由無線通信的文件傳遞的另一緊密包格式的示意圖； 圖11為根據(jù)本發(fā)明的示范性實施例經(jīng)配置以接收并處理廣播文件的節(jié)點的電路的一 部分的示意圖；以及
圖12為根據(jù)本發(fā)明的示范性實施例經(jīng)配置以傳遞廣播文件的節(jié)點的電路的一部分 的示意圖。
具體實施例方式
提供以下描述使得所屬領(lǐng)域的技術(shù)人員能夠制造并使用本發(fā)明。在以下描述中為了 解釋的目的而陳述細節(jié)。應了解，所屬領(lǐng)域的一般技術(shù)人員將意識到可實踐本發(fā)明而不 使用這些特定細節(jié)。在其它實例中，為了避免不必要的細節(jié)混淆對本發(fā)明的描述而未詳 述眾所周知的結(jié)構(gòu)和過程。因此，本發(fā)明并不希望限于所展示的實施例，而是應符合與 本文所揭示的原理和特征一致的最廣泛范圍。
圖2展示本發(fā)明的示范性實施例的簡化示意圖。整個系統(tǒng)通常由參考標號40表示。
在通信系統(tǒng)40中，為了說明的簡潔和明確，僅展示兩個網(wǎng)絡42和44。網(wǎng)絡42和44由 基干網(wǎng)絡46 (例如內(nèi)部網(wǎng)絡或因特網(wǎng))鏈接。
假設在此實施例中，網(wǎng)絡42由服務提供者操作。服務提供者在網(wǎng)絡42中安裝節(jié)點 48。在此實例中，節(jié)點48稱為廣播服務分布器(BSD)。內(nèi)容服務器48可經(jīng)設計以保存 廣播內(nèi)容以及由服務提供者提供的相關(guān)廣播信息。
在網(wǎng)絡44中，存在訂戶節(jié)點50，其能夠接收服務，包括由服務器節(jié)點48經(jīng)由基干 網(wǎng)絡46提供的服務。在此實施例中，將節(jié)點50描繪為無線裝置，(僅舉幾個實例)例如 個人數(shù)字助理(PDA)、移動計算機或蜂窩式電話。網(wǎng)絡44支持無線技術(shù)，例如由3GPP2 (第三代合作伙伴計劃2)陳述的cdma2000標準，其中3GPP2為若干國際標準機構(gòu)的協(xié) 會，包括美國TIA/EIA (電信工業(yè)協(xié)會/電子工業(yè)協(xié)會)。應注意，網(wǎng)絡40還可支持其它 標準，例如由3GPP (第三代合作伙伴計劃)發(fā)布的WCDMA (寬帶碼分多址)標準，其 由不同的歐洲標準機構(gòu)協(xié)調(diào)并支持。另一實例為由前向鏈路(FLO)論壇開發(fā)的標準， FLO論壇為促進用于FLO網(wǎng)絡中的標準化的無線工業(yè)中各種機構(gòu)的協(xié)會。
訂戶單元50經(jīng)由無線電存取網(wǎng)絡(RAN) 52而與網(wǎng)絡44通信。RAN 52包括連接 到多個基站(BS) 66A到66N的基站控制器/包數(shù)據(jù)控制功能(BSC/PDF) 54。在網(wǎng)絡 44中，建構(gòu)有包數(shù)據(jù)服務節(jié)點(PDSN) 68和廣播服務節(jié)點(BSN) 70。 PDSN 68禾卩BSN 70均提供在基干網(wǎng)絡46與網(wǎng)絡44中的RAN 52之間進行介接的功能。安裝BSN 70更 多地用于多點播送或廣播使用，而PDSN68大部分處理單點播送應用。在本說明書中， 術(shù)語多點播送和廣播可互換使用。
在網(wǎng)絡44中，存在連接到BSN70的另一服務器，稱為廣播多點播送服務(BCMCS) 內(nèi)容服務器63。通常，BCMCS內(nèi)容服務器63預先存儲廣播內(nèi)容和廣播內(nèi)容的相關(guān)數(shù)據(jù)， 包括由內(nèi)容服務器48提供且經(jīng)由基干網(wǎng)絡46傳遞的數(shù)據(jù)。
在示范性實施例中，將某些節(jié)點之間的通信描繪為以無線的方式執(zhí)行。然而應了解， 無需總是如此。經(jīng)由那些節(jié)點之間各種其它裝置而進行的非無線通信也適用。舉例來說， 替代無線裝置，節(jié)點50可為固定計算機或經(jīng)由光學鏈路或常規(guī)導電電纜而與網(wǎng)絡44通 信的另一服務器。
假設在此實施例中，基干網(wǎng)絡46支持因特網(wǎng)協(xié)議(IP)。在描述操作細節(jié)之前，有 必要首先大體上解釋在經(jīng)由各種級別的不同階層架構(gòu)的協(xié)議進行包數(shù)據(jù)通信期間對于數(shù) 據(jù)包的處理，及其在IP下操作的相互關(guān)系。
在網(wǎng)絡通信技術(shù)中，根據(jù)如由國際標準化組織(ISO)和國際電信聯(lián)盟-電信標準部
門(ITU-T)陳述的開放系統(tǒng)互連(OSI)模型，將協(xié)議層級化。此目的在于促進多供應 商設備的可交互操作性。即，每一級別的協(xié)議階層架構(gòu)具有其自身規(guī)格。如此，只要滿 足特定階層架構(gòu)級別的規(guī)格，即可確保此級別的產(chǎn)品的開發(fā)與其它級別的其它產(chǎn)品相容。 圖3示意展示階層式等級的協(xié)議的堆棧，其通常稱為"協(xié)議堆棧"，且通常由參考標 號72表示。依據(jù)因特網(wǎng)工程工作小組(正TF)模型構(gòu)建IP協(xié)議堆棧72，所述因特網(wǎng)工 程工作小組模型類似于OSI模型但不精確地與OSI模型相同。根據(jù)正TF模型，IP協(xié)議 堆棧72具有五層，從層i開始到層5。因此，由節(jié)點(例如圖2中所展示的節(jié)點48或 50)發(fā)出的數(shù)據(jù)包必須經(jīng)由協(xié)議堆棧72處理。協(xié)議堆棧72以軟件或硬件或其組合的形 式內(nèi)建于節(jié)點中。類似地，由相同節(jié)點接收的數(shù)據(jù)包必須經(jīng)由相同協(xié)議堆棧72但以反向 次序進行處理。
舉一實例說明。假設數(shù)據(jù)包經(jīng)處理以便從一節(jié)點(例如，節(jié)點48 (圖2))發(fā)出，首 先根據(jù)應用層(即，層5)中的協(xié)議的一者來建立所述數(shù)據(jù)包。層5包括超文本傳送協(xié) 議(HTTP)、服務郵件傳送協(xié)議(SMTP)、文件傳送協(xié)議(FTP)、實時傳送協(xié)議(RTP) 和單向傳送文件傳遞/異步分層編碼(FLUTE/ALC)協(xié)議。進一步假設數(shù)據(jù)包為VoIP (因 特網(wǎng)語音協(xié)議)對話的產(chǎn)物。因此必須根據(jù)層5中的RTP格式化數(shù)據(jù)包。
例如根據(jù)層5中的RTP產(chǎn)生的數(shù)據(jù)包的時間敏感數(shù)據(jù)包需經(jīng)實時處理。明確地說， 通常不重新發(fā)送缺陷包而是將其簡單地丟棄，以免阻塞其它即將到來的數(shù)據(jù)包的傳輸。 RTP數(shù)據(jù)包因此通常經(jīng)由層4 (傳輸層)中的用戶數(shù)據(jù)包協(xié)議(UDP)而承載。因此，須 進一步根據(jù)層4中的UDP來明確表示來自層5中RTP的數(shù)據(jù)包。
另一方面，如果數(shù)據(jù)包源自層5中的其它協(xié)議(例如FTP)，那么通常經(jīng)由層4中的 傳送控制協(xié)議(TCP)來發(fā)送所述數(shù)據(jù)包。在TCP下，數(shù)據(jù)包的正確傳遞最為重要。如 此，總是重新發(fā)送缺陷包，雖然可能減緩整個數(shù)據(jù)傳輸過程。
經(jīng)過此傳送層(層4)之后的數(shù)據(jù)包被添加有例如源和目的地端口號的信息。
在經(jīng)過傳送層(層4)之后接著將數(shù)據(jù)包發(fā)送到網(wǎng)絡層(層3)以供進行處理。在此 特定情況中，從層4所得的數(shù)據(jù)包必須根據(jù)IP (例如，根據(jù)添加的數(shù)據(jù)包的源和目的地 地址)再次格式化。
隨后，必須構(gòu)造所述數(shù)據(jù)包以使其適合鏈路層(層2)中適用的無論何種協(xié)議。舉 例來說，如果服務器節(jié)點48經(jīng)由以太網(wǎng)而連接到所述網(wǎng)絡，那么層2將為如由電氣電子 工程師協(xié)會(正EE)發(fā)行的第正EE 802.3號文獻中所陳述的以太網(wǎng)協(xié)議的形式。
圖5中協(xié)議堆棧72的最底層為物理層(層l)，其處理數(shù)據(jù)包傳輸?shù)奈锢韺嵤┓桨浮?br> 舉例來說，在圖2中，如果節(jié)點48與網(wǎng)絡42之間的通信鏈接為常規(guī)有線鏈接，那么物 理層(層1)關(guān)注節(jié)點48上的硬件電路和網(wǎng)絡42的接口電路兩者。作為另一實例，在 圖2中，如果節(jié)點50與BS 66A之間的通信鏈接為空中接口。在此情況下，物理層(層 1)與大氣空間和經(jīng)由大氣空間收發(fā)信號的RAN52的硬件電路相關(guān)。
現(xiàn)在返回參看圖3。對于由示范性節(jié)點50 (圖2)接收的數(shù)據(jù)包，所述數(shù)據(jù)包必須 經(jīng)由相同協(xié)議堆棧72但以反向次序(即，從層1到層5)處理。
本文描述系統(tǒng)40中示范性廣播過程的操作。在圖2中，如先前所提及，假設節(jié)點 48 (即BSD)是由將廣播服務提供到訂戶的服務提供者安裝于網(wǎng)絡42中，其中節(jié)點50 為所述訂戶中的一者。舉例來說在此情況中，節(jié)點50可從另一網(wǎng)絡漫游到網(wǎng)絡44并尋 求對于新聞剪輯的存取，例如對于可從操作網(wǎng)絡42的服務提供者獲得的7:00 p.m.新聞的 存取。
如果網(wǎng)絡44支持廣播服務，網(wǎng)絡44時常為可用服務維持廣播信道?？捎梅盏男?息可以可下載文件的形式組織?；蛘撸嗤畔⒖梢詫崟r可視數(shù)據(jù)連續(xù)流的形式呈現(xiàn)。
假設在此示范性實施例中，可用服務以類似于廣播服務指南(SG)的方式而集合為 可下載文件，其中廣播服務指南(SG)由包括服務提供者、硬件和軟件供應商和網(wǎng)絡操 作者等無線工業(yè)中各種實體的協(xié)會開放移動聯(lián)盟(OMA)發(fā)布，用于統(tǒng)一無線通信系統(tǒng) 中各種標準的目的。由OMA發(fā)行的出版物OMA-TS-BCAST匿Service-Guide-Vl. ~@弁$@@ 中陳述了 SG的細節(jié)。
到此，當在網(wǎng)絡44中時，節(jié)點50的用戶需要參考SG以獲得可用服務。為了此目 的，必須從網(wǎng)絡44下載SG。節(jié)點50的用戶接著從SG選擇所尋求的服務，并隨后調(diào)諧 到承載如SG中所提供的所述服務的信道。
對于某些服務(例如音樂下載)，節(jié)點50的用戶可首先下載所尋求的文件并稍后欣 賞所下載的文件。對于其它服務(例如新聞廣播對話)，所尋求的文件的內(nèi)容被下載并或 多或少地同時呈現(xiàn)。S卩，所尋求的服務實時呈現(xiàn)，與服務關(guān)聯(lián)的文件下載同樣如此。所 述方法帶來若干缺點。尤其是，因為文件內(nèi)容的成功呈現(xiàn)不僅取決于內(nèi)容本身的成功下 載，而且取決于處理內(nèi)容文件所需的文件屬性的成功下載。所述依賴性不可避免地導致 延遲且經(jīng)常不利地影響用戶對于內(nèi)容呈現(xiàn)的體驗。另外，為了更好地確保可靠的數(shù)據(jù)包 接收，通常發(fā)送冗余數(shù)據(jù)。因此，如下文進一步解釋，這可能不會促成對可用通信資源 的最有效使用。
假設所尋求的服務的文件內(nèi)容經(jīng)由FLUTE/ALC協(xié)議傳送。為了確保正確的數(shù)據(jù)傳
送，常規(guī)地將圓盤式文件分布(Carousel File Distribution) (CFD)方法與FLUTE/ALC 協(xié)議結(jié)合使用。圖3A展示FLUTE/ALC協(xié)議的更詳細示意表示，且稍后將進行進一步論 述。圖4展示在FLUTE/ALC協(xié)議下操作的CFD方案的方法。
在圖4中，參考標號74表示一文件。 一則多媒體內(nèi)容(例如此實例中的新聞剪輯) 可包含多個文件。在文件74中，數(shù)據(jù)包#1到#5中的每一者表示一 ALC數(shù)據(jù)包。包含同 樣以ALC協(xié)議格式配置的文件傳遞表(FDT) 78的ALC數(shù)據(jù)包與每一文件74的傳遞關(guān) 聯(lián)。
在FDT78中，包括解碼數(shù)據(jù)包#1到#5所需的各種參數(shù)或?qū)傩?。所述參?shù)可包含(但 不限于)文件名稱、文件識別符(ID)、文件的源位置(即，URI)、呈現(xiàn)時間、文件大 小、內(nèi)容類型、編碼方案、前向誤差校正(FEC)類型和FEC相關(guān)參數(shù)，以及安全相關(guān) 參數(shù)(如果可應用)。
在CFD方法中，文件被多次傳輸。在此實例中，包括內(nèi)容包#1到#5的文件74與關(guān) 聯(lián)的FDT78 —起第一次在首次通過73中傳輸，且接著第二次在第二次通過75中傳輸。 在首次通過73中，F(xiàn)DT 78在內(nèi)容包#1到#5之前傳輸。在第二次通過75中，相同F(xiàn)DT 78 在內(nèi)容包#1到#5結(jié)束時傳輸。
重復地傳輸每一文件的一個目的是，消除所有接收器為了接收文件完全地時間對準 的需要。即，不需要為了接收文件的目的而使接收器同步。
重復地傳輸每一文件的另一理由是，在未安裝FEC方案或即使安裝但FEC機制不能 操作的事件中確保數(shù)據(jù)傳送期間的正確性。為了達到此目的，CFD方法經(jīng)設計以包含如 由圖4中所展示的場景A、 B和C表示的三個場景。除了三個場景A、 B和C外，可通 告失敗的文件下載。
在場景A中，假設節(jié)點50試圖下載文件74。在首次通過73期間，節(jié)點50需要成 功地接收FDT 78。假設首次通過73中FDT 78的下載成功且無誤差。接著節(jié)點50接收 后續(xù)的數(shù)據(jù)包弁1到#5。假設首次通過73中所有數(shù)據(jù)包并1到#5的下載也成功。節(jié)點50 可使用從首次通過73下載的FDT78中的信息來解碼所有包#1到#5中的數(shù)據(jù)，用于整個 文件74的組合。
在場景B中，在首次通過73中下載文件74期間，假設FDT包78的檢索成功。首 次通過中所有內(nèi)容包弁l到#5的檢索除了數(shù)據(jù)包#3外也成功。假設所實施的FEC機制不 發(fā)揮作用。在此情況下，節(jié)點50必須等待直到第二次通過75發(fā)生才可在第二次通過75 期間接收相同數(shù)據(jù)包并3以補償在首次通過73中接收的相應缺陷包#3。隨后，節(jié)點50可
使用來自從首次通過獲得的FDT78的信息來解碼所有數(shù)據(jù)包，用于文件74的重構(gòu)。
在場景C中，即使在首次通過73中正確下載了所有數(shù)據(jù)包弁1至!J弁5,節(jié)點在首次通 過73中也未能正確地接收FDT 78。在此情況下，節(jié)點50必須等待直到第二次通過75 發(fā)生才可檢索相應FDT 78以補償來自首次通過73的錯誤FDT 78，用于對文件74的所 有數(shù)據(jù)包的正確解碼。
在不適宜的信號接收條件下，如以上在場景A、 B和C中描述的在FEC頂部實施的 額外步驟可能不能夠校正任何錯誤數(shù)據(jù)。即，如先前所提及，可通告文件74的下載失敗。 在場景B中，數(shù)據(jù)包#3的損失可能僅影響在呈現(xiàn)期間文件74的質(zhì)量。然而，在場景C 中，F(xiàn)DT78的不成功檢索可導致整個文件74的損失，因為如果無FDT78，那么不可處 理整個文件74。在此情況下，節(jié)點50可能必須僅為了具有另一機會獲得FDT78而等待 直到下一圓盤式循環(huán)出現(xiàn)，所述圓盤式循環(huán)可為許多時間周期，例如由時間通過73和 75延展的時間周期。如果發(fā)生此情況，那么不可避免額外的時間延遲和通信信道占用。 如果裝置50為如在此實例中的移動裝置，那么額外的時間延遲轉(zhuǎn)化為裝置50的電池的 額外功率消耗。在移動通信中，電池壽命的維持極其重要。
根據(jù)本發(fā)明的示范性實施例，F(xiàn)DT和內(nèi)容數(shù)據(jù)包未如常規(guī)實踐那樣在頻帶內(nèi)接收。 事實上，如稍后將描述，文件屬性和內(nèi)容數(shù)據(jù)在頻帶外接收。
下文中，術(shù)語"頻帶內(nèi)"解釋為表示經(jīng)由相同傳輸信道且進一步大體上在同一傳輸 對話內(nèi)的信息傳送。頻帶內(nèi)信息傳送的實例如圖4的傳輸過程中所展示和描述。另一方 面，術(shù)語"頻帶外"解釋為表示經(jīng)由不同傳輸對話的信息傳送，其與所述傳送經(jīng)過相同 傳輸信道還是不同傳輸信道無關(guān)，如圖5中展示的傳輸過程所例示且如下文所描述。
現(xiàn)參看圖5。在此實施例中，與有效負載數(shù)據(jù)(例如數(shù)據(jù)包M到#5)相比，文件屬 性82 (例如先前所提及的包括于FDT 78中的文件屬性)被分離地傳輸，即在頻帶外而 非在頻帶內(nèi)傳輸。
優(yōu)選地，F(xiàn)A經(jīng)由網(wǎng)絡44 (圖2)且在廣播信道中傳輸。舉例來說，F(xiàn)A可為先前所 提及的SG的一部分。SG且因此FA首先由尋求廣播服務的節(jié)點50獲得。即，在第一通 信對話81期間獲得FA82。在正確檢索FA82之后，節(jié)點50接著可根據(jù)SG中所提供的 信息而調(diào)諧到所述信道以獲得內(nèi)容文件(例如文件84)。即，在第二通信對話86期間獲 得內(nèi)容文件。如圖5中所展示，不存在插入有內(nèi)容文件包的FDT。事實上，內(nèi)容文件(例 如，文件83和84)經(jīng)設計以連續(xù)且不間斷地傳輸。換句話說，只有在確認節(jié)點50較早 在通信對話81期間已正確檢索FA 82之后才在通信對話86期間下載內(nèi)容文件。因此，
可避免當文件和FDT兩者均在頻帶內(nèi)并如以上所描述而被接收時文件的成功處理受相應 FDT的成功下載支配的情況。
在傳輸過程期間，如果發(fā)現(xiàn)缺陷數(shù)據(jù)包(例如，在首次通過85期間文件84中的數(shù) 據(jù)包#4，且由圖5中的參考標號90表示)，且進一步假設安裝的FEC機制未能校正缺陷 包#4，那么可檢索第二次通過87中的相應數(shù)據(jù)包#4以供進行修復。如果修復過程不成 功，那么在呈現(xiàn)期間文件84的質(zhì)量可能存在某一程度的降級。然而，如圖4中所展示的 失敗場景C中和如上文所描述的情況可能從不會發(fā)生。原因是，如先前所陳述較早在通 信對話81期間己成功接收到FA 82。
以如上文所描述的方式操作，不需要占用用于FDT傳輸?shù)娜魏晤l帶內(nèi)信道。藉此可 更確定地執(zhí)行內(nèi)容文件檢索。文件獲得時間也可大體上縮減。因此，可減輕通信信道中 的擁塞，這又可促成對可用通信資源的更有效使用。另外，如果節(jié)點50 (圖2)為移動 裝置，那么較短的文件獲得時間意味著在下載內(nèi)容文件期間喚醒節(jié)點50的電池所需的時 間較短。因此，可節(jié)省電池電力。
應進一步注意，圖5中所展示的FA 82為需經(jīng)獲得以用于適當?shù)亟獯a所尋求的服務 對話的所有文件而所需的許多FA中的一者，其中文件84為所述文件中的一者。然而， FA 82具有不僅用于文件84而且用于例如鄰近文件83的其它文件的檢索的許多共同屬 性。因此，可將所有FA組織為適于在傳輸對話中所有文件的文件檢索的一個主FA?；?者，替代主FA,可將聚集的FA劃分為兩個部分。第一部分可保存視為長期的文件屬性。 所述屬性可包括文件名稱、文件ID、文件位置、呈現(xiàn)時間和分布時間窗口。另一方面， 認為相對短期的屬性可放置于FA的第二部分中。短期屬性可包括應用程序文件大小、傳 輸文件大小、內(nèi)容類型、編碼方案、FEC類型和參數(shù)以及安全相關(guān)參數(shù)。第一部分可保 持于SG中而隨著時間過去相對不發(fā)生改變。第二部分可在SG中周期性地更新以反映不 斷變化的條件。
如先前所提及，某些文件首先可經(jīng)下載并稍后由用戶在由用戶選定的時間執(zhí)行。實 例為音樂文件和軟件更新文件。其它文件可首先經(jīng)下載但優(yōu)選在特定時間呈現(xiàn)。實例為 如下文將描述的新聞廣播對話。在任一情況中，根據(jù)本發(fā)明的另一方面，內(nèi)容文件獲得 和呈現(xiàn)不需要同時執(zhí)行。相反，文件獲得可分離地并在文件呈現(xiàn)過程之前執(zhí)行。
為了便于解釋，說明更具體的實例?，F(xiàn)返回參看圖2。假設在此實例中，節(jié)點50的 用戶想要觀看通常在7:00 p.m.經(jīng)由定期電視廣播可用的新聞廣播。在經(jīng)由網(wǎng)絡44廣播的 SG中，關(guān)于7:00 p.m.新聞剪輯的相關(guān)信息通?？捎?。網(wǎng)絡44經(jīng)由基干網(wǎng)絡46而具有來
自服務提供網(wǎng)絡42的此信息。在SG中，可指定兩個時間窗口，艮卩，"分布窗口 (DW)" 和"呈現(xiàn)窗口 (PW)"。圖6展示所述配置。
在DW中，指定一時間窗口 ，其中需啟動節(jié)點50以便接收7:00 p.m.新聞對話的文件。 舉例來說，在此實例中，從5:00 p.m.到6:30 p.m.,其為節(jié)點50可通電以接收新聞文件的 時間區(qū)間。另一方面，PW識別所下載的新聞對話的呈現(xiàn)時間，在此實例中，其為從7:00 p.m.到7:30 p.m.。即，在此時間間隔期間，所下載的文件將呈現(xiàn)為7:00 p.m.新聞。將DW 與PW分離的額外益處為，允許訂戶在呈現(xiàn)時間之前下載文件，以避免在通常與峰值時 間重合的呈現(xiàn)時間期間發(fā)生業(yè)務信道過載。即使在DW期間網(wǎng)絡44中大量業(yè)務負載的情 況下，個別文件下載仍可緩慢地以小流量流到其各自的接收器，并恰當?shù)卦赑W開始之 前完成。
基于由SG提供的信息，假設節(jié)點50通電并在從5:25p.m.到5:37 p.m.的時間周期期 間起動用于接收新聞剪輯。如果實施適當?shù)奈募嚎s技術(shù)，那么下載所需的時間(在此 實例中為12分鐘)可短于呈現(xiàn)時間(在此情況下為30分鐘)。
圖7的流程圖中展示節(jié)點50的先前提及的方法。圖8展示由網(wǎng)絡44實踐的相應方法。
根據(jù)本發(fā)明的又一方面，可進一步流線化有效負載數(shù)據(jù)的傳送。
對于文件內(nèi)容下載，可使用FLUTE/ALC協(xié)議。如先前所提及，與在FTP中數(shù)據(jù)包 經(jīng)由TCP傳送層(圖3)傳送不同，F(xiàn)LUTE/ALC中的數(shù)據(jù)包承載于UDP傳送層上。FTP 更傾向于適合一對一應用，且通常重新傳輸錯誤包，但這減緩整個傳輸過程。經(jīng)由UDP 承載的FLUTE/ALC協(xié)議經(jīng)設計以適于多點播送或廣播應用。通常不重新傳輸錯誤數(shù)據(jù)。 事實上，通過使用適當?shù)那跋蛘`差校正(FEC)方案來減少數(shù)據(jù)傳輸中的錯誤。
現(xiàn)參看圖3A，其示意展示通常由參考標號96表示的FLUTE/ALC協(xié)議。FLUTE協(xié) 議的數(shù)據(jù)包由ALC協(xié)議承載傳送。2002年12月由IETF發(fā)行的題為"Asynchronous Layered Coding(ALC) Protocol Instantiation "的出版物RFC 3450中陳述了 ALC協(xié)議。ALC 協(xié)議是為多點播送傳送而提議的基本協(xié)議之一。包含ALC的數(shù)據(jù)傳送不需要上行鏈路信 號傳輸(即，從接收器傳輸信號到發(fā)射器)，并使用FEC來進行可靠的數(shù)據(jù)檢索。ALC 還利用分層編碼傳送(LCT)結(jié)構(gòu)塊98來進行多速率擁塞控制(CC) 97，且利用FEC 結(jié)構(gòu)塊99來進行可靠的內(nèi)容傳遞。2002年12月題為"Layered Coding Transport(LCT) Building Block"的IETF出版物RFC 3451中描述了 LCT。同樣由IETF發(fā)行的RFC 3453 中描述了 FEC。
FLUTE協(xié)議表示用于多點播送文件傳遞的ALC的應用。然而，常規(guī)FLUTE/ALC協(xié)
議主要經(jīng)設計用于非移動環(huán)境。在需要節(jié)省電池功率且空氣鏈接帶寬較為珍貴的無線環(huán) 境中，可進一步流線化文件下載過程。為了達到此目的，可將有效負載中每一數(shù)據(jù)包設 計得更緊密。
圖9展示由參考標號94識別的示范性緊密ALC數(shù)據(jù)包，其經(jīng)格式化以更加符合RFC 3450中所詳述的常規(guī)ALC包。ALC包格式94經(jīng)設計與由3GPP2發(fā)布在公開的文獻3GPP TS 23.346中的廣播/多點播送服務(MBMS)相同。數(shù)據(jù)包84中所展示的格式與文獻3GPP TS 23.346中詳述的格式之間的主要差異是缺少文件描述信息(即，處理數(shù)據(jù)包94的有 效負載所需的文件屬性)的任何頻帶內(nèi)傳輸。
圖10展示由參考標號96表示的另一示范性緊密包格式。數(shù)據(jù)包96大體上經(jīng)流線化 且適用于無線通信環(huán)境中。尤其免除了擁塞控制信息。如在無線環(huán)境中，無線媒體為單 一存取裝置，用于以不同數(shù)據(jù)速率調(diào)節(jié)多個存取裝置的擁塞控制不是必需的。在圖9中 所展示的數(shù)據(jù)包94中，額外開銷為16字節(jié)。對于圖10中所展示的數(shù)據(jù)包％，額外開 銷僅為8字節(jié)。
圖11示意展示根據(jù)本發(fā)明的示范性實施例的設備(例如圖2中展示的節(jié)點50)的硬 件實施方案的一部分，其由參考標號100表示?？梢愿鞣N形式建造且并入設備100，例 如(僅舉幾例說明)膝上型計算機、PDA或蜂窩式電話。
設備100包含將若干電路鏈接在一起的中央數(shù)據(jù)總線102。所述電路包括CPU (中 央處理單元)或控制器104、接收電路106、發(fā)射電路108和存儲器單元110。
如果設備100為無線裝置的一部分，那么接收和發(fā)射電路106和108可連接到射頻 (RF)電路，但圖式中未展示。接收電路106在將所接收的信號發(fā)出到數(shù)據(jù)總線102之前 處理并緩沖所述信號。另一方面，發(fā)射電路108在從裝置100發(fā)出來自數(shù)據(jù)總線102的 數(shù)據(jù)之前處理并緩沖所述數(shù)據(jù)。CPU/控制器104執(zhí)行數(shù)據(jù)總線102的數(shù)據(jù)管理功能并進 一步執(zhí)行一般數(shù)據(jù)處理功能，包括執(zhí)行存儲器單元110的指令性內(nèi)容。
替代如圖11中所展示分離地安置，作為替代方案，發(fā)射電路108和接收電路106可 為CPU/控制器104的部分。
存儲器單元110包括一組指令，其通常由參考標號101表示。在此實施例中，所述 指令包括例如尤其能夠處理如上文所描述的FLUTE/ALC協(xié)議的協(xié)議堆棧功能112的部 分。所述組指令還包括能夠執(zhí)行圖7中所展示和描述的方法的廣播客戶端功能114。
在此實施例中，存儲器單元IIO為RAM (隨機存取存儲器)電路。示范性指令部分112和H4為軟件常用程序或模塊。存儲器單元110可連接到易失性或非易失性類型的另 一存儲器電路(未圖示)?；蛘?，存儲器單元110可由其它電路類型組成，例如EEPROM (電可擦可編程只讀存儲器)、EPROM (電可編程只讀存儲器)、ROM (只讀存儲器)、 ASIC (專用集成電路)、磁盤、光盤和此項技術(shù)中已知的其它類型。
圖12示意展示廣播服務器(例如圖2中所展示的BSN設備70)的硬件實施方案的 一部分，其由參考標號120表示。設備120包含將若干電路鏈接在一起的中央數(shù)據(jù)總線 122。所述電路包括CPU (中央處理單元)或控制器124、接收電路126、發(fā)射電路128、 數(shù)據(jù)庫存儲單元129和存儲器單元131。
接收和發(fā)射電路126和128可連接到網(wǎng)絡數(shù)據(jù)總線(未圖示)，設備120鏈接到所述 網(wǎng)絡數(shù)據(jù)總線。接收電路126在將從網(wǎng)絡數(shù)據(jù)總線(未圖示)接收的信號路由到內(nèi)部數(shù) 據(jù)總線122之前處理并緩沖所述信號。發(fā)射電路128在從設備120發(fā)出來自數(shù)據(jù)總線122 的數(shù)據(jù)之前處理并緩沖所述數(shù)據(jù)?；蛘?，發(fā)射電路128和接收電路126可共同稱為接口 電路。CPU/控制器124執(zhí)行數(shù)據(jù)總線122的數(shù)據(jù)管理職責并執(zhí)行一般數(shù)據(jù)處理功能，包 括執(zhí)行存儲器單元131的指令內(nèi)容。數(shù)據(jù)庫存儲單元129存儲數(shù)據(jù)，例如具有各種參數(shù) 的SG和內(nèi)容文件。
存儲器單元131包括一組指令，其通常由參考標號121表示。在此實施例中，所述 指令尤其包括協(xié)議堆棧132和廣播主機134等若干部分。存儲器單元131可由如上文所 提及的存儲器電路類型組成，且不再進一步重復。協(xié)議堆棧121和廣播主機134的功能 包括根據(jù)本發(fā)明例如圖3和圖8中所展示且如先前所描述的指令組。
應進一步注意，如上文圖7和圖8中所描述和展示的過程也可編碼為在此項技術(shù)中 已知的任何計算機可讀媒體上執(zhí)行的計算機可讀指令。在本說明書和隨附的權(quán)利要求書 中，術(shù)語"計算機可讀媒體"表示參與將指令提供到任何處理器(例如圖11和圖12中 分別展示和描述的CPU/控制器104和124)以供執(zhí)行的任何媒體。所述媒體可為存儲類 型的，并可采取同樣如先前所描述的易失性或非易失性存儲媒體的形式，例如分別在圖 11和圖12中描述的存儲器單元110和131的形式。所述媒體也可為傳輸類型的，并可包 括同軸電纜、銅線、光纜和承載能夠承載由機器或計算機可讀取的信號的聲波或電磁波 的空中接口。
最后，如在此實施例中所描述，節(jié)點BSD48描述為安裝于服務提供者的網(wǎng)絡42中。 情況可能并非始終如此?？赡軐SD48安裝于不屬于服務提供者的另一網(wǎng)絡中。另外， 如示范性實施例中所描述的頻帶外傳輸信道可如通常在擴頻通信技術(shù)中所實踐而邏輯地
或物理地加以區(qū)分。另外，不同頻帶外對話可由不同端口號而非如先前所提及的時間分 離來識別。因此，例如在圖5中，F(xiàn)DT可在層4 (圖3)的UDP上經(jīng)由對應于第一傳輸 對話的一個目的地端口而傳輸。內(nèi)容文件可在層4的UDP上在第二傳輸對話期間經(jīng)由另 一目的地端口號傳輸。另外，還應清楚，圖7和圖8中的流程圖也適應于根據(jù)用戶選擇 來下載并執(zhí)行文件，例如音樂文件。舉例來說，用戶可從SG收集并自主地確定文件分 布和文件呈現(xiàn)窗口。另外，如示范性實施例中所描述，基干網(wǎng)絡描繪為在IP下操作。除 了 IP以外的其它協(xié)議是可能的。舉例來說，在FLO網(wǎng)絡中，根據(jù)由FLO論壇發(fā)行的題 為"FLO Air Interface Specification"的文獻(floforum 2005.001)的協(xié)議將為適用的。在 FLO網(wǎng)絡中，替代SG，相應文件屬性可放置于系統(tǒng)信息(SI)中，SI的細節(jié)可查閱由 FLO論壇發(fā)行的文獻floforum 2006.005。另外，結(jié)合實施例而描述的任何邏輯塊、電路 和算法步驟可實施于硬件、軟件、固件或其組合中。所屬領(lǐng)域的技術(shù)人員將了解，可作 出形式和細節(jié)上的這些和其它改變而不背離本發(fā)明的范圍和精神。
權(quán)利要求
1.一種用于通信系統(tǒng)中的廣播的文件下載方法，其包含在第一通信對話中接收用于處理所述廣播的至少一個文件的文件屬性；以及在第二通信對話中與所述文件屬性分離地接收所述廣播的所述至少一個文件。
2. 根據(jù)權(quán)利要求1所述的方法，其進一步包含經(jīng)由第一通信信道接收所述文件屬性；以及 經(jīng)由第二通信信道接收所述至少一個文件。
3. 根據(jù)權(quán)利要求1所述的方法，其中所述通信系統(tǒng)支持因特網(wǎng)協(xié)議(IP)，所述方法進 一步包含通過所述IP的用戶數(shù)據(jù)報協(xié)議(UDP)經(jīng)由第一端口號來接收所述文件屬性；以及通過所述IP的所述UDP經(jīng)由第二端口號來接收所述至少一個文件。
4. 根據(jù)權(quán)利要求l所述的方法，其進一步包含在所述第二通信對話中連續(xù)地接收所述 廣播的多個文件，以及在所述第一通信對話中接收用于處理所述多個文件的所述文 件屬性，其中所述第一通信對話早于所述第二通信對話。
5. 根據(jù)權(quán)利要求1所述的方法，其中所述至少一個文件包括多個數(shù)據(jù)包，所述方法進 一步包含在所述數(shù)據(jù)包的每一者中不接收任何文件屬性用于處理所述至少一個文 件。
6. 根據(jù)權(quán)利要求l所述的方法，其進一步包含在所述第二通信對話中接收所述廣播的 多個文件，且進一步包含使用某些所述文件屬性來處理所述多個文件，其中所述某 些文件屬性通常在所述多個文件之間共享以用于處理所述多個文件。
7. 根據(jù)權(quán)利要求l所述的方法，其進一步包含在所述文件屬性中提供用于呈現(xiàn)所述廣 播的所述至少一個文件的時間信息以便允許在預定時間呈現(xiàn)所述至少一個文件。
8. —種用于通信系統(tǒng)中的廣播的文件傳遞方法，其包含在第一通信對話中發(fā)送用于處理所述廣播的至少一個文件的文件屬性；以及 在第二通信對話中與所述文件屬性分離地發(fā)送所述廣播的所述至少一個文件。
9. 根據(jù)權(quán)利要求8所述的方法，其進一步包含經(jīng)由第一通信信道發(fā)送所述文件屬性；以及經(jīng)由第二通信信道發(fā)送所述至少一個文件。
10. 根據(jù)權(quán)利要求8所述的方法，其中所述通信系統(tǒng)支持因特網(wǎng)協(xié)議(IP)，所述方法進 一步包含-通過所述IP的用戶數(shù)據(jù)報協(xié)議(UDP)經(jīng)由第一端口號來發(fā)送所述文件屬性；以及通過所述IP的所述UDP經(jīng)由第二端口號來發(fā)送所述至少一個文件。
11. 根據(jù)權(quán)利要求8所述的方法，其進一步包含在所述第二通信對話中連續(xù)地發(fā)送所述 廣播的多個文件，以及在所述第一通信對話中發(fā)送用于處理所述多個文件的所述文 件屬性，其中所述第一通信對話早于所述第二通信對話。
12. 根據(jù)權(quán)利要求8所述的方法，其中所述至少一個文件包括多個數(shù)據(jù)包，所述方法進 一步包含在所述數(shù)據(jù)包的每一者中不提供任何文件屬性用于處理所述至少一個文 件。
13. 根據(jù)權(quán)利要求8所述的方法，其進一步包含在所述第二通信對話中發(fā)送所述廣播的 多個文件，且進一步包含在所述第一通信對話中提供某些所述文件屬性，其中所述 某些文件屬性通常在所述多個文件之間共享以用于處理所述多個文件。
14. 根據(jù)權(quán)利要求8所述的方法，其進一步在所述文件屬性中包含用于呈現(xiàn)所述廣播的 所述至少一個文件的時間信息。
15. —種經(jīng)配置以在通信系統(tǒng)中接收廣播的設備，其包含用于在第一通信對話中接收用于處理所述廣播的至少一個文件的文件屬性的裝 置；以及用于在第二通信對話中與所述文件屬性分離地接收所述廣播的所述至少一個文 件的裝置。
16. 根據(jù)權(quán)利要求15所述的設備，其進一步包含用于經(jīng)由第一通信信道接收所述文件屬性的裝置；以及 用于經(jīng)由第二通信信道接收所述至少一個文件的裝置。
17. 根據(jù)權(quán)利要求15所述的設備，其中所述通信系統(tǒng)支持因特網(wǎng)協(xié)議(IP),所述設備 進一步包含用于通過所述IP的用戶數(shù)據(jù)報協(xié)議(UDP)經(jīng)由第一端口號來接收所述文件屬性 的裝置；以及用于通過所述IP的所述UDP經(jīng)由第二端口號來接收所述至少一個文件的裝置。
18. 根據(jù)權(quán)利要求15所述的設備，其進一步包含用于在所述第二通信對話中連續(xù)地接收所述廣播的多個文件的裝置，以及用于在所述第一通信對話中接收用于處理所述 多個文件的所述文件屬性的裝置，其中所述第一通信對話早于所述第二通信對話。
19. 根據(jù)權(quán)利要求15所述的設備，其中所述至少一個文件包括多個數(shù)據(jù)包，其中所述 數(shù)據(jù)包中的每一者不包括任何用于處理所述至少一個文件的文件屬性。
20. 根據(jù)權(quán)利要求15所述的設備，其進一步包含用于在所述第二通信對話中接收所述 廣播的多個文件的裝置，且進一步包含用于使用某些所述文件屬性來處理所述多個 文件的裝置，其中所述某些文件屬性通常在所述多個文件之間共享以用于處理所述 多個文件。
21. 根據(jù)權(quán)利要求15所述的設備，其中所述文件屬性包含用于呈現(xiàn)所述廣播的所述至 少一個文件的時間信息以便允許在預定時間呈現(xiàn)所述至少一個文件。
22. —種用于通信系統(tǒng)中的廣播的文件傳遞設備，其包含用于在第一通信對話中發(fā)送用于處理所述廣播的至少一個文件的文件屬性的裝 置；以及用于在第二通信對話中與所述文件屬性分離地發(fā)送所述廣播的所述至少一個文 件的裝置。
23. 根據(jù)權(quán)利要求22所述的設備，其進一步包含用于經(jīng)由第一通信信道發(fā)送所述文件屬性的裝置；以及 用于經(jīng)由第二通信信道發(fā)送所述至少一個文件的裝置。
24. 根據(jù)權(quán)利要求22所述的設備，其中所述通信系統(tǒng)支持因特網(wǎng)協(xié)議(IP)，所述設備 進一步包含用于通過所述IP的用戶數(shù)據(jù)報協(xié)議(UDP)經(jīng)由第一端口號來發(fā)送所述文件屬性 的裝置；以及用于通過所述IP的所述UDP經(jīng)由第二端口號來發(fā)送所述至少一個文件的裝置。
25. 根據(jù)權(quán)利要求22所述的設備，其進一步包含用于在所述第二通信對話中連續(xù)地發(fā) 送所述廣播的多個文件的裝置，以及用于在所述第一通信對話中發(fā)送用于處理所述 多個文件的所述文件屬性的裝置，其中所述第一通信對話早于所述第二通信對話。
26. 根據(jù)權(quán)利要求22所述的設備，其中所述至少一個文件包括多個數(shù)據(jù)包，所述設備 進一步包含用于在所述數(shù)據(jù)包的每一者中不提供任何文件屬性用于處理所述至少 一個文件的裝置。
27. 根據(jù)權(quán)利要求22所述的設備，其進一步包含用于在所述第二通信對話中發(fā)送所述 廣播的多個文件的裝置，且進一步包含用于在所述第一通信對話中提供某些所述文 件屬性的裝置，其中所述某些文件屬性通常在所述多個文件之間共享以用于處理所 述多個文件。
28. 根據(jù)權(quán)利要求22所述的設備，其中所述文件屬性包含用于呈現(xiàn)所述廣播的所述至 少一個文件的時間信息。
29. —種在通信系統(tǒng)中的廣播中使用的設備，其包含處理器；以及耦合到所述處理器的存儲器單元，所述存儲器單元包括計算機可讀指令，所述計 算機可讀指令用于在第一通信對話中接收用于處理所述廣播的至少一個文件的文 件屬性，以及在第二通信對話中與所述文件屬性分離地接收所述廣播的所述至少一 個文件。
30. 根據(jù)權(quán)利要求29所述的設備，其中所述存儲器單元進一步包含計算機可讀指令， 所述計算機可讀指令用于經(jīng)由第一通信信道接收所述文件屬性，以及經(jīng)由第二通信 信道接收所述至少一個文件。
31. 根據(jù)權(quán)利要求29所述的設備，其中所述通信系統(tǒng)支持因特網(wǎng)協(xié)議(IP)，所述存儲 器單元進一步包含計算機可讀指令，所述計算機可讀指令用于通過所述IP的用戶數(shù) 據(jù)報協(xié)議(UDP)經(jīng)由第一端口號來接收所述文件屬性，以及通過所述IP的所述 UDP經(jīng)由第二端口號來接收所述至少一個文件。
32. 根據(jù)權(quán)利要求29所述的設備，其中所述存儲器單元進一步包含計算機可讀指令， 所述計算機可讀指令用于在所述第二通信對話中連續(xù)地接收所述廣播的多個文件， 以及在所述第一通信對話中接收用于處理所述多個文件的所述文件屬性，其中所述 第一通信對話早于所述第二通信對話。
33. 根據(jù)權(quán)利要求29所述的設備，其中所述至少一個文件包括多個數(shù)據(jù)包，且其中所 述數(shù)據(jù)包中的每一者不包括任何用于處理所述至少一個文件的文件屬性。
34. 根據(jù)權(quán)利要求29所述的設備，其中所述存儲器單元進一步包含計算機可讀指令， 所述計算機可讀指令用于在所述第二通信對話中接收所述廣播的多個文件，以及使 用某些所述文件屬性來處理所述多個文件，其中所述某些文件屬性通常在所述多個 文件之間共享以用于處理所述多個文件。
35. 根據(jù)權(quán)利要求29所述的設備，其中所述文件屬性包含用于呈現(xiàn)所述廣播的所述至 少一個文件的時間信息以便允許在預定時間呈現(xiàn)所述至少一個文件。
36. —種用于通信系統(tǒng)中的廣播的文件傳遞設備，其包含處理器；以及耦合到所述處理器的存儲器單元，所述存儲器單元包含計算機可讀指令，所述計 算機可讀指令用于在第一通信對話中發(fā)送用于處理所述廣播的至少一個文件的文 件屬性，以及在第二通信對話中與所述文件屬性分離地發(fā)送所述廣播的所述至少一 個文件。
37. 根據(jù)權(quán)利要求36所述的設備，其中所述存儲器單元進一步包含計算機可讀指令， 所述計算機可讀指令用于經(jīng)由第一通信信道發(fā)送所述文件屬性，以及經(jīng)由第二通信 信道發(fā)送所述至少一個文件。
38. 根據(jù)權(quán)利要求36所述的設備，其中所述通信系統(tǒng)支持因特網(wǎng)協(xié)議(IP)，其中所述 存儲器單元進一步包含計算機可讀指令，所述計算機可讀指令用于通過所述IP的用戶數(shù)據(jù)報協(xié)議(UDP)經(jīng)由第一端口號來發(fā)送所述文件屬性，以及通過所述IP的所 述UDP經(jīng)由第二端口號來發(fā)送所述至少一個文件。
39. 根據(jù)權(quán)利要求36所述的設備，其中所述存儲器單元進一步包含計算機可讀指令， 所述計算機可讀指令用于經(jīng)由所述IP的單向傳送文件傳遞(FLUTE)結(jié)合所述IP 的所述UDP來發(fā)送所述至少一個文件。
40. 根據(jù)權(quán)利要求36所述的設備，其中所述存儲器單元進一步包含計算機可讀指令， 所述計算機可讀指令用于在所述第二通信對話中連續(xù)地發(fā)送所述廣播的多個文件， 以及在所述第一通信對話中發(fā)送用于處理所述多個文件的所述文件屬性，其中所述 第一通信對話早于所述第二通信對話。
41. 根據(jù)權(quán)利要求36所述的設備，其中所述至少一個文件包括多個數(shù)據(jù)包，其中所述 數(shù)據(jù)包中的每一者不包括任何用于處理所述至少一個文件的文件屬性。
42. 根據(jù)權(quán)利要求36所述的設備，其中所述存儲器單元進一步包含計算機可讀指令， 所述計算機可讀指令用于在所述第二通信對話中發(fā)送所述廣播的多個文件，以及在 所述第一通信對話中提供某些所述文件屬性，其中所述某些文件屬性通常在所述多 個文件之間共享以用于處理所述多個文件。
43. 根據(jù)權(quán)利要求36所述的設備，其中所述文件屬性包含用于呈現(xiàn)所述廣播的所述至 少一個文件的吋間信息。
44. 一種包括計算機可讀指令的計算機可讀媒體，所述計算機可讀指令用于在第一通信對話中接收用于處理廣播的至少一個文件的文件屬性；以及在第二通信對話中與所述文件屬性分離地接收所述廣播的所述至少一個文件。
45. 根據(jù)權(quán)利要求44所述的計算機可讀媒體，其進一步包含計算機可讀指令用于經(jīng)由第一通信信道接收所述文件屬性；以及 經(jīng)由第二通信信道接收所述至少一個文件。
46. 根據(jù)權(quán)利要求44所述的計算機可讀媒體，其中所述通信系統(tǒng)支持因特網(wǎng)協(xié)議(IP), 所述計算機可讀媒體進一步包括計算機可讀指令用于通過所述IP的用戶數(shù)據(jù)報協(xié)議(UDP)經(jīng)由第一端口號來接收所述文件屬性；以及通過所述IP的所述UDP經(jīng)由第二端口號來接收所述至少一個文件。
47. —種包括計算機可讀指令的計算機可讀媒體，所述計算機可讀指令用于在第一通信對話中發(fā)送用于處理廣播的至少一個文件的文件屬性；以及 在第二通信對話中與所述文件屬性分離地發(fā)送所述廣播的所述至少一個文件。
48. 根據(jù)權(quán)利要求47所述的計算機可讀媒體，其進一步包括計算機可讀指令用于經(jīng)由第一通信信道發(fā)送所述文件屬性；以及 經(jīng)由第二通信信道發(fā)送所述至少一個文件。
49. 根據(jù)權(quán)利要求47所述的計算機可讀媒體，其進一步包括計算機可讀指令用于通過所述IP的用戶數(shù)據(jù)報協(xié)議(UDP)經(jīng)由第一端口號來發(fā)送所述文件屬性；以及通過所述IP的所述UDP經(jīng)由第二端口號發(fā)送所述至少一個文件。
全文摘要
在提供廣播服務的通信系統(tǒng)中，廣播服務中用于廣播的文件可由用戶存取。分離地發(fā)送所述廣播文件的內(nèi)容和處理所述廣播文件所需的文件屬性。根據(jù)配置，在所述內(nèi)容文件之前接收所述文件屬性使得更有效地下載并處理所述廣播文件。
文檔編號H04L29/06GK101189851SQ200680019627
公開日2008年5月28日 申請日期2006年4月10日 優(yōu)先權(quán)日2005年4月8日
發(fā)明者克里斯·貝內(nèi)特, 蘭吉特·賈亞拉姆, 基爾提·古普塔, 戈登·肯特·沃克, 查爾斯·N·羅, 薩迪·納加拉杰 申請人:高能股份有限公司