專利名稱：用于提供單播會(huì)話的高級(jí)會(huì)話控制的系統(tǒng)和方法
技術(shù)領(lǐng)域：
本發(fā)明總體上涉及單播會(huì)話的建立和實(shí)現(xiàn)。更具體地，本發(fā)明 涉及對(duì)單播會(huì)話的控制，其中單播會(huì)話例如是按照諸如單向傳送文
件遞送(FLUTE)協(xié)議的推送型數(shù)據(jù)遞送協(xié)議進(jìn)行的會(huì)話。
背景技術(shù)：
本部分旨在對(duì)權(quán)利要求中記載的本發(fā)明提供背景或上下文。此 處的描述可以包括能夠被探究的概念，但未必是那些之前已經(jīng)想到
或者探究的概念。因此，除非在此明確指出外，本部分提及的內(nèi)容 對(duì)于本申請(qǐng)的說(shuō)明書和權(quán)利要求書而言不是現(xiàn)有技術(shù)，并且并不因
為包括在本部分中就承認(rèn)其為現(xiàn)有技術(shù)。
近年來(lái)，移動(dòng)廣播解決方案已一皮不同的組織標(biāo)準(zhǔn)化，這些組織 諸如是第三代伙伴合作計(jì)劃(3GPP )多媒體廣播多播服務(wù)(MBMS ) 組織、數(shù)字視頻廣播(DVB)廣播與移動(dòng)服務(wù)整合(CBMS)組織、 以及開放移動(dòng)聯(lián)盟(OMA)廣播(BCAST)組織。這種多播/廣播解 決方案提供的兩個(gè)主要服務(wù)是流式傳輸和文件遞送服務(wù)。盡管流式 傳輸服務(wù)被認(rèn)為是該技術(shù)的主要驅(qū)動(dòng)力，但也期望文件遞送隨著時(shí) 間而生成大量的業(yè)務(wù)和活動(dòng)。例如，在音樂(lè)和-f見頻剪輯的遞送中， 文件遞送可以包括主要的應(yīng)用組成部分。備選地，在例如豐富媒體 應(yīng)用和頻道切換(zapping)流的情況下，文件遞送可能是應(yīng)用的次 要組成部分。
在文件遞送的情況下，可以^吏用FLUTE作為文件遞送協(xié)議。如 網(wǎng)絡(luò)工作組的請(qǐng)求注解(RFC )3926(可在www.ietf.org/rfc/rfc3926.txt 處找到，在此通過(guò)引用并入其全部?jī)?nèi)容)中所討論的，F(xiàn)LUTE由互 聯(lián)網(wǎng)工程任務(wù)組(IETF)定義，并且目前正在對(duì)該文檔進(jìn)行修訂。FLUTE基于異步分層編碼(ALC)協(xié)議實(shí)例化，其可以在RFC 3450 (www.ietf.org/rfc/rfc3451.txt, www.ietf.org/rfc/rfc3451.txt， 在》匕通 過(guò)引用并入其全部?jī)?nèi)容)中找到。ALC包括一組構(gòu)建塊，諸如可在 RFC 3451 ( www.ietf.org/rfc/rfc345l,txt， www.ietf.org/rfc/rfc3451.txt， 在此通過(guò)引用并入其全部?jī)?nèi)容)中找到的分層編碼傳輸(LCT)塊， 以及可在RFC 3452 ( www.ietf.org/rfc/rfc3452.txt,在此通過(guò)引用并入 其全部?jī)?nèi)容)中找到的前向糾錯(cuò)(FEC )構(gòu)建塊。除其他之外，F(xiàn)LUTE 通過(guò)定義用來(lái)描述FLUTE會(huì)話內(nèi)容的機(jī)制來(lái)擴(kuò)展ALC。這是通過(guò)引 入以下公知對(duì)象實(shí)現(xiàn)的，該對(duì)象的傳輸對(duì)象標(biāo)識(shí)符(TOI)等于O， 并攜帶文件遞送表(FDT)實(shí)例。FDT實(shí)例列出了一組文件及其相 應(yīng)的傳輸選項(xiàng)。FDT是遵循在FLUTE規(guī)范中定義的模式(schema) 的XML文件。
3GPP目前正在規(guī)定對(duì)多媒體廣播/多播服務(wù)(MBMS)文件下載 和流式傳輸方法的擴(kuò)展。這些擴(kuò)展的目標(biāo)之一是支持單播會(huì)話上的 服務(wù)遞送。在用戶剛好離開多播覆蓋區(qū)域、并且僅具有單播信道可 用于數(shù)據(jù)接收的情況下，這尤其重要。支持通過(guò)單播會(huì)話的服務(wù)遞 送是這樣實(shí)現(xiàn)的提供適當(dāng)?shù)男帕?，以便向接收機(jī)指示存在與多播/ 廣播會(huì)話遞送相同內(nèi)容的備選單播會(huì)話。
在通過(guò)廣播信道向用戶遞送文件下載會(huì)話的文件時(shí)，會(huì)話的內(nèi)
特性。作為該系統(tǒng)的結(jié)果，接收機(jī)必須選擇用戶感興趣的內(nèi)容，并 丟棄其他內(nèi)容。另一方面，在單播遞送中，接收機(jī)和發(fā)送機(jī)建立點(diǎn) 對(duì)點(diǎn)連接以用于其通信。這允許更自由地定制會(huì)話內(nèi)容。
當(dāng)移動(dòng)出多播/廣播覆蓋區(qū)域時(shí)，用戶可能希望繼續(xù)接收文件下 載會(huì)話的文件。在這種情況下，接收機(jī)首先連接至在會(huì)話公告或者 其他地方信發(fā)號(hào)通知的FLUTE單播服務(wù)器。FLUTE單播服務(wù)器將 多播/廣播會(huì)話的內(nèi)容轉(zhuǎn)發(fā)至單播接收機(jī)。然而，該布置具有幾個(gè)缺 點(diǎn)。例如，在此布置中，即使用戶可能并非對(duì)所有會(huì)話文件感興趣， 接收機(jī)也會(huì)通過(guò)單播載體接收廣播/多播的所有文件，這可能是相對(duì)昂貴的。而且，在此布置中，接收機(jī)必須等待感興趣的內(nèi)容在多播/ 廣播信道上可獲得，此后才能通過(guò)單播信道來(lái)接收該內(nèi)容。此外，
FLUTE單播服務(wù)器被假定為多播/廣播FLUTE會(huì)話的接收機(jī)，并且 充當(dāng)轉(zhuǎn)發(fā)單元，但是情況并非總是這樣。所有這些限制影響了發(fā)送 機(jī)和接收機(jī)的總體性能和成本效率。盡管文件傳輸協(xié)議(FTP)(可 以在www.ietf.org/rfc/rfc959.txt，在此通過(guò)引用并入其全部?jī)?nèi)容)允 許對(duì)文件遞送會(huì)話的某些控制、對(duì)遠(yuǎn)程文件系統(tǒng)的列表以及對(duì)選定 文件的接收，但期望提供一種系統(tǒng)，其支持對(duì)單播FLUTE信道的更 為靈活的控制。

發(fā)明內(nèi)容
本發(fā)明的各種實(shí)施方式提供用于控制FLUTE單播會(huì)話的系統(tǒng)和 方法。按照各種實(shí)施方式，在單播會(huì)話中，可以使用多種命令來(lái)觸 發(fā)特定的動(dòng)作。這些命令可能導(dǎo)致諸如以下的動(dòng)作遞送當(dāng)前文件 列表，遞送單個(gè)文件或文件組，以及其他功能。利用這些命令，可 以擴(kuò)展對(duì)按照單播模式遞送的FLUTE會(huì)話的控制。通過(guò)降低文件的 發(fā)送機(jī)與接收機(jī)之間的帶寬使用以及優(yōu)化FLUTE服務(wù)器(或者其他 FLUTE發(fā)送機(jī))與接收機(jī)之間的數(shù)據(jù)流，文件的發(fā)送機(jī)和接收機(jī)二 者都將受益于這種高級(jí)控制。本發(fā)明的各種實(shí)施方式實(shí)際上可以利 用任意推送型數(shù)據(jù)遞送協(xié)議來(lái)實(shí)現(xiàn)，包括FLUTE協(xié)議和其他基于 ALC的協(xié)議。
當(dāng)結(jié)合附圖閱讀下文詳細(xì)描述時(shí)，本發(fā)明的這些以及其他優(yōu)點(diǎn) 和特征以及本發(fā)明的組織和操作方式將變得易見，其中貫穿下文描 述的多個(gè)附圖，類似的元件具有類似的標(biāo)號(hào)。


圖1是示出了當(dāng)接收機(jī)不在特定的廣播/多播覆蓋區(qū)域內(nèi)的情況 下，接收機(jī)經(jīng)由單播網(wǎng)絡(luò)與FLUTE服務(wù)器或者其他發(fā)送機(jī)的交互的
圖示；圖2是示出了使用實(shí)時(shí)流式傳輸協(xié)議(RTSP)的本發(fā)明一個(gè)實(shí) 施方式的實(shí)現(xiàn)的圖表；
圖3是可以在本發(fā)明的實(shí)現(xiàn)中使用的移動(dòng)設(shè)備的透視圖；以及 圖4是圖3的移動(dòng)電話的電路的示意圖。
具體實(shí)施例方式
本發(fā)明的各種實(shí)施方式提供用于按照推送型數(shù)據(jù)遞送協(xié)議(例 如，F(xiàn)LUTE協(xié)議或者其他基于ALC的協(xié)議)來(lái)控制單播會(huì)話的系統(tǒng) 和方法。圖1是示出按照在此討論的各種實(shí)施方式的、接收機(jī)100 與FLUTE服務(wù)器或者發(fā)送機(jī)110之間交互的圖示。應(yīng)當(dāng)注意，盡管 在此包含的以下描述特別地參考FLUTE協(xié)議的使用，但本發(fā)明的各 種實(shí)施方式實(shí)際上可以在任何推送型數(shù)據(jù)遞送協(xié)議中實(shí)現(xiàn)，其中文 件從服務(wù)器被"推送"至接收機(jī)。
如圖l所示，F(xiàn)LUTE發(fā)送機(jī)110 (其還可以包括其他類型的發(fā) 送機(jī))和接收機(jī)100二者都能夠通過(guò)廣播/多播網(wǎng)絡(luò)120(諸如，MBMS 或者DVB-H網(wǎng)絡(luò))和單播網(wǎng)絡(luò)130(諸如，通用移動(dòng)電信系統(tǒng)(UMTS ) 或者通用分組無(wú)線電服務(wù)(GPRS)網(wǎng)絡(luò))進(jìn)行通信。在特定的時(shí)間 點(diǎn)，接收機(jī)100可能移動(dòng)到廣播/多播覆蓋區(qū)域之外，這需要通信切 換至單播信道，這在圖1中在140處表示。
按照各種實(shí)施方式，在單播會(huì)話中，可以使用多種命令來(lái)觸發(fā) 特定動(dòng)作。這些命令可以導(dǎo)致諸如以下的動(dòng)作遞送當(dāng)前文件列表， 遞送單個(gè)文件或者一組文件，以及其他功能。利用這些命令，可以 對(duì)按照單播模式遞送的FLUTE會(huì)話的控制進(jìn)行擴(kuò)展。通過(guò)降低文件 的發(fā)送機(jī)和接收機(jī)的帶寬使用以及優(yōu)化FLUTE發(fā)送機(jī)110與接收機(jī) 100之間的數(shù)據(jù)流，文件發(fā)送機(jī)和接收機(jī)二者將受益于這種高級(jí)控
在一個(gè)特定實(shí)施方式中，可以將以下命令用于FLUTE會(huì)話的控 制。然而，還應(yīng)當(dāng)注意，根據(jù)本發(fā)明的原理，也可以使用其他命令。 LIST (列表)命令觸發(fā)將當(dāng)前文件列表從FLUTE發(fā)送機(jī)110遞送至接收機(jī)100。對(duì)LIST命令的響應(yīng)例如可以包括實(shí)際的FDT實(shí)例 或者文件統(tǒng)一資源標(biāo)識(shí)符(URI)的列表。FDT可以作為對(duì)請(qǐng)求的答 復(fù)來(lái)發(fā)送，或者在FLUTE會(huì)話本身中發(fā)送。
GET (獲取)命令觸發(fā)將單個(gè)文件或者一組文件從FLUTE發(fā)送 機(jī)110遞送至接收機(jī)100。在命令體中，給出所請(qǐng)求文件的列表。 FLUTE發(fā)送機(jī)110可以立即遞送所請(qǐng)求的文件，或者稍后在這些文 件變?yōu)榭捎脮r(shí)遞送。
MASK (屏蔽)命令是由接收機(jī)100發(fā)送給FLUTE發(fā)送機(jī)110 的命令。MASK命令通知FLUTE發(fā)送機(jī)110:接收機(jī)100不想接收 特定的一個(gè)或多個(gè)文件。命令體攜帶將不會(huì)傳輸至接收機(jī)100的文 件的列表。
PAUSE(暫停)命令也是由接收機(jī)100發(fā)送給FLUTE發(fā)送機(jī)110 的命令。PAUSE命令的作用是請(qǐng)求暫時(shí)停止數(shù)據(jù)傳輸，而并不相應(yīng) 地拆除會(huì)話。PLAY命令也由接收機(jī)100發(fā)送，其指示應(yīng)當(dāng)恢復(fù)從 FLUTE發(fā)送機(jī)110到接收機(jī)100的數(shù)據(jù)傳輸。
除上述之外，還可以在針對(duì)數(shù)據(jù)傳輸?shù)膫€(gè)體請(qǐng)求(諸如，PLAY (播放)或者GET請(qǐng)求/命令)內(nèi)指示傳送對(duì)象的范圍、源塊以及編 碼符號(hào)。
本發(fā)明實(shí)施方式的一個(gè)實(shí)現(xiàn)基于RTSP。 RTSP2.0的互聯(lián)網(wǎng)草案 可以在www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-13.txt 處找到，并且在此通過(guò)引用并入其全部?jī)?nèi)容。
在RTSP 2.0中，請(qǐng)求消息使用以下格式，而不考慮請(qǐng)求是由服 務(wù)器還是客戶端發(fā)起。請(qǐng)求以請(qǐng)求行開始，其包含將要應(yīng)用于資源 的方法、資源的標(biāo)識(shí)符以及所使用的協(xié)議版本。其后是零個(gè)或者更 多報(bào)頭行。這些報(bào)頭行可以是"general (通用)"、"request(請(qǐng)求)，， 或者"entity (實(shí)體)"類型。使用空行來(lái)只是報(bào)頭部分的結(jié)束。還 可以包括消息體(實(shí)體)。如果包括消息體，則消息體包含一行或 多行。消息體的長(zhǎng)度(以字節(jié)為單位)由Content-Length (內(nèi)容長(zhǎng)度) 實(shí)體報(bào)頭指示。Content-Length通用報(bào)頭字段包含消息體(實(shí)體)的長(zhǎng)度。會(huì)話 請(qǐng)求斗艮頭(request-header)和響應(yīng)才艮頭(response-header)字！殳標(biāo)識(shí) RTSP會(huì)話。作為成功的SETUP (建立)請(qǐng)求的結(jié)果，服務(wù)器創(chuàng)建 RTSP會(huì)話，作為響應(yīng)，將會(huì)話標(biāo)識(shí)符給予客戶端。RTSP會(huì)話存在， 直到由服務(wù)器超時(shí)或者TEARDWON (拆除)請(qǐng)求所銷毀。CSeq通 用報(bào)頭(general-header)字段指定用于RTSP請(qǐng)求響應(yīng)對(duì)的序號(hào)。 使用各種"方法"請(qǐng)求/命令來(lái)指示在由請(qǐng)求統(tǒng)一資源標(biāo)識(shí)符 (URI)所標(biāo)識(shí)的資源上執(zhí)行的任務(wù)。 一種這樣的方法是RSTP OPTIONS (選項(xiàng))方法。該方法是雙向的，其中客戶端可以向服務(wù) 器請(qǐng)求該方法，反之亦然?？蛻舳吮仨殞?shí)現(xiàn)發(fā)送OPTIONS請(qǐng)求的能 力，而服務(wù)器或者代理必須實(shí)現(xiàn)響應(yīng)OPTIONS請(qǐng)求的能力?？蛻舳?、 服務(wù)器或者代理還可以實(shí)現(xiàn)其所需能力的相反性(converse)。 OPTIONS請(qǐng)求可以在任何時(shí)候發(fā)出。這種請(qǐng)求并不修改會(huì)話狀態(tài)。 然而，該請(qǐng)求可以延長(zhǎng)會(huì)話的生命期。OPTIONS請(qǐng)求中URI確定請(qǐng) 求以及相應(yīng)響應(yīng)的范圍。如果Request (請(qǐng)求)URI指向(refer to ) 給定主機(jī)上的特定媒體資源，則范圍限于所指示的RTSP代理針對(duì) 該媒體資源所支持的方法集合。僅具有主機(jī)地址的Request URI將范 圍限于特定RTSP代理的一般能力，而不考慮任何特定的媒體。如 果請(qǐng)求URI是星號(hào)(*),則范圍限于下一跳(也即，與請(qǐng)求發(fā)送機(jī) 直接通信的RTSP代理)的 一般能力。不論請(qǐng)求的范圍如何，OPTIONS 響應(yīng)中必須總是包括Public (公共)報(bào)頭，其列出響應(yīng)RTSP代理所 支持的方法。而且，如果請(qǐng)求的范圍限于媒體資源，則響應(yīng)中必須 包括Allow (允許)報(bào)頭，以枚舉出針對(duì)該資源所允許的方法集合， 除非方法集合與Public報(bào)頭中的集合完全匹配。如果給定資源不可 用，RTSP代理應(yīng)當(dāng)返回適當(dāng)?shù)捻憫?yīng)碼，諸如3rr或者4xx。所支持 的報(bào)頭可以包括在請(qǐng)求中，以查詢響應(yīng)RTSP代理所支持的特征集 合。
GET—PARAMETER (獲取參數(shù))請(qǐng)求獲取用于URI中所指定的 表示或者流的一個(gè)或多個(gè)參數(shù)的值。如果請(qǐng)求中存在Session (會(huì)話)報(bào)頭，則在指定的會(huì)話上下文中必須獲取參數(shù)的值?；貜?fù)和響應(yīng)的 內(nèi)容取決于實(shí)現(xiàn)。
還應(yīng)當(dāng)注意，還可以在沒(méi)有體(實(shí)體)的情況下使用方法。如
果請(qǐng)求成功，也即接收到2000K響應(yīng)，則保活(keep-alive)定時(shí)器 已經(jīng)更新。這種請(qǐng)求中存在的任何不需要的才艮頭可以處理，也可以 不處理。為了允許客戶端確定是否已經(jīng)處理了任何這種報(bào)頭，需要 使用特征標(biāo)簽和Require (需求)報(bào)頭。由于這個(gè)原因，推薦在體中 發(fā)送將要獲取的任何參數(shù)，而不是使用任何報(bào)頭。
3GPP和IEFT中已經(jīng)存在用于使用如互聯(lián)網(wǎng)草案中描述的RTSP 來(lái)控制FLUTE會(huì)話的建議，該建議可以在
www.ietf,org/internet-drafts/draft-lohmar-mmusic-rtsp-flute-OO.txt中找 到，在此通過(guò)引用并入其全部?jī)?nèi)容。該文檔已經(jīng)提出擴(kuò)展RTSP功 能，以支持FLUTE會(huì)話控制。然而，在此文檔中定義的控制粒度僅 僅是數(shù)據(jù)傳輸?shù)拈_始和停止?？梢詫?duì)所定義的機(jī)制進(jìn)行擴(kuò)展，以支 持如本發(fā)明的各種實(shí)施方式中所描述的精細(xì)粒度控制。
利用本發(fā)明的各種實(shí)施方式，可以實(shí)現(xiàn)多個(gè)功能。 一個(gè)這樣的 功能包括在設(shè)備之間交換能力信息。例如，接收機(jī)100可以查詢 FLUTE服務(wù)器llO，以查看是否支持高級(jí)FLUTE會(huì)話控制命令。這 可以使用OPTIONS命令來(lái)實(shí)現(xiàn)。備選地，定義特征標(biāo)簽，例如 "3gpp.org油anced-flute-control"，并且接收機(jī)和發(fā)送機(jī)可以在 "S叩ported (支持)"字段中使用該特征標(biāo)簽來(lái)指示其對(duì)這些特征 的支持。如杲不支持高級(jí)FLUTE會(huì)話控制，則接收機(jī)100不應(yīng)當(dāng)向 FLUTE發(fā)送機(jī)110發(fā)送請(qǐng)求。
而且，在實(shí)現(xiàn)本發(fā)明的各種實(shí)施方式時(shí)，新的命令顯然是可能 的。特別地，定義新的RTSP方法，以涵蓋上文討論的LIST、 GET 和MASK命令。備選地，可以在"SET—PARAMETER (設(shè)置參數(shù))" 和"GET—PARAMETER (獲取參數(shù))，，的體中發(fā)送命令。在后一種 情況下，針對(duì)命令定義新的參數(shù)。例如，在這種情況下，在對(duì) GET PARAMETERS請(qǐng)求的響應(yīng)中或者在FLUTE會(huì)話本身中(在答復(fù)是FDT實(shí)例的情況下)，在GET—PARAMETER請(qǐng)求的體中發(fā)送 的"LIST"參數(shù)觸發(fā)傳輸FLUTE會(huì)話的FDT或者文件列表。
在一個(gè)實(shí)施方式中，對(duì)RTSPPALY (播放)請(qǐng)求進(jìn)行修改，以 包括新的范圍報(bào)頭字段。傳統(tǒng)上用來(lái)攜帶時(shí)間范圍的范圍報(bào)頭字段 被修改為攜帶TOI、源塊以及編碼符號(hào)范圍，以便向FLUTE發(fā)送^/L IIO指示接收機(jī)100已經(jīng)請(qǐng)求的詳細(xì)數(shù)據(jù)部分。
下面是按照一個(gè)實(shí)施方式的經(jīng)過(guò)修改的PLAY請(qǐng)求的示例，例
如
才妾收才幾-〉發(fā)送才幾PLAY rtsp:〃example.com/'flute/sessionl RTSP/2.0
CSeq: 84 Session: 5428765
Range: TOI=45; SBN=2; ESI=2-34, TOI=34 按照 一 個(gè)實(shí)施方式使用GET—PARAMETER ifr求的 一 個(gè)示例如 下，例^口
接收機(jī)->發(fā)送機(jī)GET—P ARAMETER rtsp:〃example.com/flute/sessionl RTSP/2.0 CSeq: 17 Session: 5428765 Content-Length : 6
LIST
發(fā)送機(jī)-〉接收機(jī)RTSP/2.0 200 OK
CSeq: 17
Content-Length: 325 Content-Type: text/flute.fdt-instance <FDT-Instance> <File>...
在RTSP中，GET和MASK命令可以通過(guò)多種不同的方式來(lái)實(shí) 現(xiàn)。例如，這些命令可以包括在PLAY方法的報(bào)頭字段中，例如4妾^:才幾->發(fā)送才幾PLAY rtsp:〃exampIe.com/flute/sessionl RTSP/2.0
CSeq: 84 Session: 5428765 GET: TOI=23 MASK: TOI=24
GET和MASK命令也可以包括在SET_PARAMETER請(qǐng)求的參 數(shù)中，以下例如
接收機(jī)-〉發(fā)送機(jī)SET—PARAMETER rtsp:〃example，com/flute/sessionl RTSP/2.0
CSeq: 17
Session: 5428765
Content-Length: 6
Content-type: text/parameters (文本/參數(shù)) GET: TOI=13,TOI=54 MASK: TOI=14
GET和MASK命令也可以用作上面指定的PLAY方法中的范圍指示。
對(duì)于能力交換，該功能可以使用OPTIONS請(qǐng)求以及定義以下新 的特征標(biāo)簽來(lái)實(shí)現(xiàn)
接收機(jī)-〉發(fā)送機(jī)OPTIONS * RTSP/2.0
CSeq: 1
User-Agent: NokiaClient/1.0 Supported: play.basic, 3gpp.org.advanced-flute-control
發(fā)送機(jī)-〉接收機(jī)RTSP/2.0 200 OK
CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN， PLAY,
PAUSESupported; play.basic， implicit-play， 3gpp.org.advanced-flute- control
Server: NokiaServer/1.1
他牽連。換言之，可以按照先前實(shí)現(xiàn)的相同模式來(lái)使用傳統(tǒng)的RTSP 報(bào)頭字段，具有在RTSP 2.0的互聯(lián)網(wǎng)草案中所定義的RTSP方法， 該草案可以在
www.ietf.org/internet-drafts/draft-ietf-mmusic曙rfc2326bis畫13.txt處找到。
圖2示出了使用RTSP的本發(fā)明一個(gè)實(shí)施方式的示例實(shí)現(xiàn)。在圖 2中的200處，接收機(jī)100向FLUTE發(fā)送機(jī)110發(fā)送"Describe (描 述)"消息。在210處，F(xiàn)LUTE發(fā)送機(jī)110利用"OK"消息以及 FLUTE會(huì)話的會(huì)話描述協(xié)議(SDP)描述進(jìn)行響應(yīng)。在220處，接 收機(jī)向FLUTE發(fā)送機(jī)110發(fā)送"SETUP (建立)，，請(qǐng)求，F(xiàn)LUTE 發(fā)送機(jī)110在230處確認(rèn)該請(qǐng)求。在240處，接收機(jī)100向FLUTE 發(fā)送機(jī)110發(fā)送"GET—PARAMETER LIST (獲取參數(shù)列表)"請(qǐng)求。 作為響應(yīng)，在250處，F(xiàn)LUTE發(fā)送才幾110確認(rèn)該請(qǐng)求，并且向接收 機(jī)IOO發(fā)送將要發(fā)送的文件的列表或者FDT實(shí)例。在260處，接收 機(jī)100向FLUTE發(fā)送機(jī)110發(fā)送PLAY (播放)命令，請(qǐng)求進(jìn)行傳 輸。在此特定示例中，PLAY命令還包括應(yīng)當(dāng)由FLUTE發(fā)送機(jī)110 傳輸?shù)腡OI的范圍。在270處，F(xiàn)LUTE發(fā)送機(jī)110確認(rèn)該命令，隨 后進(jìn)行指定TOI的傳輸。
發(fā)送設(shè)備和接收設(shè)備二者可以使用各種傳輸技術(shù)進(jìn)行通信，這 些傳輸技術(shù)包括但不限于碼分多址(CDMA)、全球移動(dòng)通信系 統(tǒng)(GSM) 、 UMTS、時(shí)分多址(TDMA)、頻分多址(FDMA)、 傳輸控制協(xié)議/互聯(lián)網(wǎng)協(xié)議(TCP/IP)、短消息收發(fā)服務(wù)(SMS)、 多媒體消息收發(fā)服務(wù)(MMS)、電子郵件、即時(shí)消息收發(fā)服務(wù)(IMS)、 藍(lán)牙、IEEE 802.il等。通信設(shè)備可以使用各種媒介進(jìn)行通信，這些 媒介包括但不限于無(wú)線電、紅外、激光、線纜連接等。圖3和圖4示出了本發(fā)明可以在其中實(shí)現(xiàn)的一個(gè)代表性移動(dòng)電 話12。然而，應(yīng)當(dāng)理解，本發(fā)明不旨在限于一種特定類型的移動(dòng)電 話12或者其他電子設(shè)備。圖3和圖4的移動(dòng)電話12包括外殼30、 液晶顯示器形式的顯示器32、小鍵盤34、麥克風(fēng)36、耳機(jī)38、電 池40、紅外端口42、天線44、才艮據(jù)本發(fā)明一個(gè)實(shí)施例的通用UICC 形式的智能卡46、讀卡器48、無(wú)線電接口電路52、編解碼器電路 54、控制器56以及存儲(chǔ)器58。個(gè)體電路和元件可以是本領(lǐng)域公知的 所有類型，例如Nokia系列的移動(dòng)電話。
本發(fā)明是在方法步驟的一般上下文中描述的，在一個(gè)實(shí)施例中， 這些方法步驟可以通過(guò)程序產(chǎn)品來(lái)實(shí)現(xiàn)，該計(jì)算機(jī)程序產(chǎn)品包括在 網(wǎng)絡(luò)環(huán)境中由計(jì)算機(jī)執(zhí)行的計(jì)算機(jī)可執(zhí)行指令，諸如程序代碼。通 常，程序模塊包括例程、程序、對(duì)象、組件、數(shù)據(jù)結(jié)構(gòu)等，用于執(zhí) 行具體任務(wù)或者實(shí)現(xiàn)特定的抽象數(shù)據(jù)類型。計(jì)算機(jī)可執(zhí)行指令、相 關(guān)數(shù)據(jù)結(jié)構(gòu)和程序模塊代表了用于執(zhí)行此處公開的方法的步驟的程 序代碼的示例。這種可執(zhí)行指令或者相關(guān)數(shù)據(jù)結(jié)構(gòu)的特定序列代表 了用于實(shí)現(xiàn)在這種步驟中描述的功能的對(duì)應(yīng)動(dòng)作的示例。
本發(fā)明的軟件和web實(shí)現(xiàn)能夠利用標(biāo)準(zhǔn)編程技術(shù)來(lái)完成，利用 基于規(guī)則的邏輯或者其他邏輯來(lái)實(shí)現(xiàn)數(shù)據(jù)庫(kù)搜索步驟、相關(guān)步驟、 比較步驟和決策步驟。還應(yīng)當(dāng)注意的是，此處以及權(quán)利要求書中使 用的詞語(yǔ)"組件，，和"模塊，，意在包括使用一行或者更多行軟件代碼的 實(shí)現(xiàn)和/或硬件實(shí)現(xiàn)和/或用于接收手動(dòng)輸入的設(shè)備。
出于示例和描述的目的，已經(jīng)給出了本發(fā)明實(shí)施的前述說(shuō)明。
式，根據(jù)上述教導(dǎo)還可能存在各種變形和修改，或者是可能從本發(fā) 明的實(shí)踐中得到各種變形和修改。選擇和描述這些實(shí)施例是為了說(shuō) 明本發(fā)明的原理及其實(shí)際應(yīng)用，以使得本領(lǐng)域的技術(shù)人員能夠以適
權(quán)利要求
1.一種方法，包括向發(fā)送設(shè)備傳輸命令，所述命令指示所述發(fā)送設(shè)備應(yīng)當(dāng)如何使用按照推送型數(shù)據(jù)遞送協(xié)議的單播會(huì)話來(lái)傳輸內(nèi)容；以及從所述發(fā)送設(shè)備接收信息，所述信息涉及所述單播會(huì)話，并且按照由所傳輸?shù)拿钐峁┑乃鲋甘尽?br> 2. 如權(quán)利要求l的方法，其中，響應(yīng)于所述命令，所接收的信 息包括來(lái)自所述發(fā)送設(shè)備的當(dāng)前文件列表。
3. 如權(quán)利要求2的方法，其中，響應(yīng)于所述命令，所接收的信 息包括文件統(tǒng)一資源標(biāo)識(shí)符(URI)的列表。
4. 如權(quán)利要求2的方法，其中，響應(yīng)于所述命令，所接收的信 息包括文件遞送表(FDT)實(shí)例。
5. 如權(quán)利要求4的方法，其中所述FDT實(shí)例在所述單播會(huì)話中 接收。
6. 如權(quán)利要求1的方法，其中所述信息包括從所述發(fā)送設(shè)備接 收的至少一個(gè)特定文件。
7. 如權(quán)利要求l的方法，其中所述命令通知所述發(fā)送設(shè)備不 應(yīng)當(dāng)傳輸至少一個(gè)特定文件。
8. 如權(quán)利要求l的方法，其中所述命令通知所述發(fā)送設(shè)備暫時(shí) 停止數(shù)據(jù)傳輸，而不拆除所述單播會(huì)話。
9. 如權(quán)利要求1的方法，其中所述命令通知所述發(fā)送設(shè)備應(yīng) 當(dāng)恢復(fù)數(shù)據(jù)傳輸。
10. 如權(quán)利要求1的方法，其中所述命令進(jìn)一步指示以下至少一 個(gè)傳送對(duì)象的范圍，源塊，以及編碼符號(hào)。
11. 如權(quán)利要求1的方法，其中所述方法按照實(shí)時(shí)流式傳輸協(xié)議 (RTSP)來(lái)實(shí)現(xiàn)。
12. 如權(quán)利要求l的方法，進(jìn)一步包括，在傳輸所述命令之前 就是否支持所述命令對(duì)所述發(fā)送設(shè)備進(jìn)行查詢；以及接收對(duì)所述查詢的應(yīng)答，所述應(yīng)答指示所述命令是否得到支持。
13. 如權(quán)利要求1的方法，其中所述命令在傳輸給所述發(fā)送設(shè)備的SET—PARAMETER消息內(nèi)傳輸。
14. 如權(quán)利要求1的方法，其中所述命令在傳輸給所述發(fā)送設(shè)備 的GET—PARAMETERS消息內(nèi)傳輸。
15. 如權(quán)利要求1的方法，其中所述推送型數(shù)據(jù)遞送協(xié)議是單向 傳送文件遞送(FLUTE)協(xié)議。
16. —種計(jì)算機(jī)產(chǎn)品，包含在計(jì)算機(jī)可讀介質(zhì)中，包括用于向發(fā)送設(shè)備傳輸命令的計(jì)算機(jī)代碼，所述命令指示所述發(fā)送 設(shè)備應(yīng)當(dāng)如何使用按照推送型數(shù)據(jù)遞送協(xié)議的單播會(huì)話來(lái)傳輸內(nèi) 容；以及用于從所述發(fā)送設(shè)備接收信息的計(jì)算機(jī)代碼，所述信息涉及所述 單播會(huì)話，并且按照由所述傳輸?shù)拿钐峁┑乃鲋甘尽?br> 17. —種設(shè)備，包括 處理器；以及存儲(chǔ)器單元，其可通信地連接至所述處理器，并且包括用于向發(fā)送設(shè)備傳輸命令的計(jì)算機(jī)代碼，所述命令指示所述 發(fā)送設(shè)備應(yīng)當(dāng)如何使用按照推送型數(shù)據(jù)遞送協(xié)議的單播會(huì)話來(lái)傳輸 內(nèi)容；以及用于從所述發(fā)送設(shè)備接收信息的計(jì)算機(jī)代碼，所述信息涉及 所述單播會(huì)話，并且按照由所述傳輸?shù)拿钐峁┑乃鲋甘尽?br> 18. 如權(quán)利要求17的設(shè)備，其中，響應(yīng)于所述命令，所接收的 信息包括來(lái)自所述發(fā)送設(shè)備的當(dāng)前文件列表。
19. 如權(quán)利要求18的設(shè)備，其中，響應(yīng)于所述命令，所接收的 信息包括文件統(tǒng)一資源標(biāo)識(shí)符(URI)的列表。
20. 如權(quán)利要求18的設(shè)備，其中，響應(yīng)于所述命令，所接收的 信息包括文件遞送表(FDT)實(shí)例。
21. 如權(quán)利要求20的設(shè)備，其中所述FDT實(shí)例在所述單播會(huì)話 中接收。
22. 如權(quán)利要求n的設(shè)備，其中所述信息包括從所述發(fā)送設(shè)備 接收的至少一個(gè)特定文件。
23. 如權(quán)利要求17的設(shè)備，其中所述命令通知所述發(fā)送設(shè)備 不應(yīng)當(dāng)傳輸至少一個(gè)特定文件。
24. 如權(quán)利要求17的設(shè)備，其中所述命令通知所述發(fā)送設(shè)備暫 時(shí)停止數(shù)據(jù)傳輸，而不拆除所述單播會(huì)話。
25. 如權(quán)利要求17的設(shè)備，其中所述命令通知所述發(fā)送設(shè)備 應(yīng)當(dāng)恢復(fù)數(shù)據(jù)傳輸。
26. 如權(quán)利要求17的設(shè)備，其中所述命令進(jìn)一步指示以下至少 一個(gè)傳送對(duì)象的范圍，源塊，以及編碼符號(hào)。
27. 如權(quán)利要求17的設(shè)備，其中所述方法按照實(shí)時(shí)流式傳輸協(xié) 議(RTSP)來(lái)實(shí)現(xiàn)。
28. 如權(quán)利要求17的設(shè)備，其中所述存儲(chǔ)器單元進(jìn)一步包括計(jì) 算機(jī)代碼，用于在傳輸所述命令之前接收對(duì)所述查詢的應(yīng)答，所述應(yīng)答指示所述命令是否得到支持。
29. 如權(quán)利要求17的設(shè)備，其中所述命令在傳輸給所述發(fā)送設(shè) 備的SET—PARAMETER消息內(nèi)傳輸。
30. 如權(quán)利要求17的設(shè)備，其中所述命令在傳輸給所述發(fā)送設(shè) 備的GET—PARAMETERS消息內(nèi)傳輸。
31. 如權(quán)利要求17的設(shè)備，其中所述推送型數(shù)據(jù)遞送協(xié)議是單 向傳送文件遞送(FLUTE)協(xié)議。
32. —種方法，包括從接收設(shè)備接收命令，所述命令指示應(yīng)當(dāng)如何使用按照推送型數(shù)據(jù)遞送協(xié)議的單播會(huì)話來(lái)傳輸內(nèi)容；以及響應(yīng)于所述命令，向所述接收設(shè)備傳輸信息，所述信息涉及所述 單播會(huì)話，并且按照由所接收的命令提供的所述指示。
33. 如權(quán)利要求32的方法，其中所述信息包括傳輸至所述接收 設(shè)備的當(dāng)前文件列表。
34. 如權(quán)利要求33的方法，其中，響應(yīng)于所述命令，所述信息 包括傳輸至所述接收設(shè)備的文件統(tǒng)一資源標(biāo)識(shí)符(URI)的列表
35. 如權(quán)利要求33的方法，其中，響應(yīng)于所述命令，所述信應(yīng) 包括傳輸至所述接收設(shè)備的文件遞送表(FDT)實(shí)例。
36. 如權(quán)利要求35的方法，其中所述FDT實(shí)例是在所述單播會(huì) 話內(nèi)傳輸?shù)摹?br> 37. 如權(quán)利要求32的方法，其中所述信息包括傳輸至所述接收 設(shè)備的至少一個(gè)特定文件。
38. 如權(quán)利要求32的方法，其中所述命令指示至少一個(gè)特定 文件不應(yīng)傳輸至所述接收設(shè)備。
39. 如權(quán)利要求32的方法，其中所述命令指示應(yīng)當(dāng)暫時(shí)停止 對(duì)所述接收設(shè)備的數(shù)據(jù)傳輸，而不拆除所述單播會(huì)話。
40. 如權(quán)利要求32的方法，其中所述命令指示應(yīng)當(dāng)恢復(fù)對(duì)所 述接收設(shè)備的數(shù)據(jù)傳輸。
41. 如權(quán)利要求32的方法，其中所述命令進(jìn)一步指示以下至少 一個(gè)傳送對(duì)象的范圍，源塊，以及編碼符號(hào)。
42. 如權(quán)利要求32的方法，其中所述方法按照實(shí)時(shí)流式傳輸協(xié) 議(RTSP )實(shí)現(xiàn)。
43. 如權(quán)利要求32的方法，進(jìn)一步包括，在接收所述命令之前響應(yīng)于所述查詢，向所述接收設(shè)備傳輸應(yīng)答，所述應(yīng)答指示所述命令是否得到支持。
44. 如權(quán)利要求32的方法，其中所述命令在從所述接收設(shè)備接 收的SET—PARAMETER消息內(nèi)傳輸。
45. 如權(quán)利要求32的方法，其中所述命令在從所述接收設(shè)備接 收的GET—PARAMETERS消息內(nèi)傳輸。
46. 如權(quán)利要求32的方法，其中所述推送型數(shù)據(jù)遞送協(xié)議是單 向傳送文件遞送(FLUTE)協(xié)議。
47. —種計(jì)算機(jī)程序產(chǎn)品，包含在計(jì)算機(jī)可讀介質(zhì)中，包括用于從接收設(shè)備接收命令的計(jì)算機(jī)代碼，所述命令指示應(yīng)當(dāng)如何使用按照推送型數(shù)據(jù)遞送協(xié)議的單播會(huì)話來(lái)傳輸內(nèi)容；以及用于響應(yīng)于所述命令而向所述接收設(shè)備傳輸信息的計(jì)算機(jī)代碼， 所述信息涉及所述單播會(huì)話，并且按照由所接收的命令提供的所述指示。
48. —種設(shè)備，包括 處理器；以及存儲(chǔ)器單元，其可通信地連接至所述處理器，并且包括用于從接收設(shè)備接收命令的計(jì)算機(jī)代碼，所述命令指示應(yīng)當(dāng)如何使用按照推送型數(shù)據(jù)遞送協(xié)議的單播會(huì)話來(lái)傳輸內(nèi)容；以及 用于響應(yīng)于所述命令而向所述接收設(shè)備傳輸信息的計(jì)算機(jī)代碼，所述信息涉及所述單播會(huì)話，并且按照由所接收的命令提供的所述指示。
49. 如權(quán)利要求48的設(shè)備，其中所述信息包括傳輸至所述接收 設(shè)備的當(dāng)前文件列表。
50. 如權(quán)利要求49的設(shè)備，其中，響應(yīng)于所述命令，所述信息 包括傳輸至所述接收設(shè)備的文件統(tǒng)一資源標(biāo)識(shí)符(URI)的列表。
51. 如權(quán)利要求49的設(shè)備，其中，響應(yīng)于所述命令，所述信息 包括傳輸至所述接收設(shè)備的文件遞送表(FDT)實(shí)例。
52. 如權(quán)利要求51的設(shè)備，其中所述FDT實(shí)例是在所述單播會(huì) 話內(nèi)傳輸?shù)摹?br> 53. 如權(quán)利要求48的設(shè)備，其中所述信息包括傳輸至所述接收 設(shè)備的至少一個(gè)特定文件。
54. 如權(quán)利要求48的設(shè)備，其中所述命令指示至少一個(gè)特定 文件不應(yīng)傳輸至所述接收設(shè)備。
55. 如權(quán)利要求48的設(shè)備，其中所述命令指示應(yīng)當(dāng)暫時(shí)停止 對(duì)所述接收設(shè)備的數(shù)據(jù)傳輸，而不拆除所述單播會(huì)話。
56. 如權(quán)利要求48的設(shè)備，其中所述命令指示應(yīng)當(dāng)恢復(fù)對(duì)所 述接收設(shè)備的數(shù)據(jù)傳輸。
57. 如權(quán)利要求48的設(shè)備，其中所述命令進(jìn)一步指示以下至少 一個(gè)傳送對(duì)象的范圍，源塊，以及編碼符號(hào)。
58. 如權(quán)利要求48的設(shè)備，其中所述方法按照實(shí)時(shí)流式傳輸協(xié) 議(RTSP)實(shí)現(xiàn)。
59. 如權(quán)利要求48的設(shè)備，其中所述存儲(chǔ)器單元進(jìn)一步包括計(jì) 算機(jī)代碼，用于在接收所述命令之前從所述接收設(shè)備接收關(guān)于是否支持所述命令的查詢；以及 響應(yīng)于所述查詢，向所述接收設(shè)備傳輸應(yīng)答，所述應(yīng)答指示所述 命令是否得到支持。
60. 如權(quán)利要求48的設(shè)備，其中所述命令在從所述接收設(shè)備接 收的SET—PARAMETER消息內(nèi)傳輸。
61. 如權(quán)利要求48的設(shè)備，其中所述命令在從所述接收設(shè)備接 收的GET—PARAMETERS消息內(nèi)傳輸。
62. 如權(quán)利要求48的設(shè)備，其中所述推送型數(shù)據(jù)遞送協(xié)議是單 向傳送文件遞送(FLUTE)協(xié)議。
63. —種系統(tǒng)，包4舌接收設(shè)備，其配置用于傳輸命令，所述命令指示應(yīng)當(dāng)如何使用按 照推送型數(shù)據(jù)遞送協(xié)議的單播會(huì)話來(lái)傳輸內(nèi)容；以及發(fā)送設(shè)備，其配置用于接收所述命令，并且響應(yīng)于所述命令，向 所述接收設(shè)備傳輸信息，所述信息涉及所述單播會(huì)話，并且按照由 所述命令提供的所述指示。
全文摘要
一種用于在諸如FLUTE會(huì)話的單播會(huì)話中提供改進(jìn)會(huì)話控制的系統(tǒng)和方法。按照各種實(shí)施方式，定義一系列新的命令，其允許接收機(jī)執(zhí)行諸如以下的動(dòng)作請(qǐng)求將要遞送的文件列表，觸發(fā)對(duì)選定文件的遞送，要求不要遞送特定的文件，以及其他。由此，可以降低發(fā)送機(jī)與接收機(jī)之間的帶寬使用，并且可以優(yōu)化設(shè)備之間的數(shù)據(jù)流。
文檔編號(hào)H04W84/12GK101611639SQ200780048982
公開日2009年12月23日 申請(qǐng)日期2007年10月8日 優(yōu)先權(quán)日2006年10月30日
發(fā)明者I·鮑阿齊齊 申請(qǐng)人:諾基亞公司