專利名稱：：用于在下載遞送期間實現(xiàn)mbms切換的系統(tǒng)和方法
技術(shù)領(lǐng)域：
：本發(fā)明涉及當(dāng)客戶機設(shè)備從MBMS覆蓋區(qū)移動到MBMS中斷區(qū)(MBMS-outagearea)時MBMS文件下載會話的切換。
背景技術(shù)：
：這部分旨在提供權(quán)利要求中所陳述的本發(fā)明的背景或上下文。此處的描述可以包括可被推行但卻不一定是先前已被構(gòu)思或推行的概念。因此，除非文中另外指出，在這部分中所描述的內(nèi)容對本申請中的說明書和權(quán)利要求書而言并不是現(xiàn)有技術(shù)，并且不因為被包括在該部分中而承認(rèn)是現(xiàn)有技術(shù)。近些年來，移動廣播解決方案已被不同的組織標(biāo)準(zhǔn)化，諸如第三代合作伙伴項目(3GPP)MBMS服務(wù)。MBMS是可以經(jīng)由現(xiàn)有GSM和UMTS蜂窩網(wǎng)絡(luò)來提供的廣播服務(wù)。3GPPMBMS使得能夠向移動用戶在資源高效的情況下遞送流行的多媒體內(nèi)容。MBMS客戶機可以經(jīng)由下載遞送、流式遞送以及流式遞送和下載遞送的組合來接收內(nèi)容。MBMS是在3GPPRelease6(版本6)中描述的特征。然而，MBMS僅可以被運營商部署在少數(shù)區(qū)域中，在這樣的區(qū)域中，對流行內(nèi)容進(jìn)行廣播/多播分發(fā)是成本高效的。當(dāng)MBMS訂戶移動到?jīng)]有MBMS覆蓋的區(qū)域時，運營商可以以單播模式分發(fā)MBMS內(nèi)容。在這樣的使用情況中，要求應(yīng)用/傳輸層信令，以便確保在MBMS內(nèi)容的廣播/多播模式接收與單播模式接收之間的無縫切換。關(guān)于MBMS用戶服務(wù)擴展的3GPPSA4Release7工作項目的目標(biāo)之一是指定用于按照單播模式(通過流式和交互承載)的MBMS內(nèi)容分發(fā)所需要的應(yīng)用/傳輸層信令。另一目標(biāo)是指定用于MBMS內(nèi)容遞送的優(yōu)化技術(shù)。以下的表l示出了3GPPSA4中用于在廣播/多播與單播模式中將^f吏用的協(xié)議之間的映射的當(dāng)前工作假設(shè)。表l<table>tableseeoriginaldocumentpage8</column></row><table>-用于會活控制的RTSP-用于媒體傳輸?shù)腞TP-用于在相同RTSP務(wù)活中的文件下載的FLUTE/UDP在因特網(wǎng)工程任務(wù)組(IETF)請求注解(RFC)3926中討論了基于單向傳輸?shù)奈募f送(FLUTE)協(xié)議，可在www.ietf.org/rfc/rfc3926.txt處獲得(通過引用的方式將其納入文中)。在IETFRFC768中討論了用戶數(shù)據(jù)才艮協(xié)i義(UDP),其可在www.ietf.org/rfc/rfc0768.txt處獲得(通過引用的方式將其納入文中)。在IETFRFC3550中討論了RTP—用于實時應(yīng)用的傳輸協(xié)議，其可在www.ietf.org/rfc/rfc3550.txt處獲得(通過引用的方式將其納入文中)。在開放移動聯(lián)盟WAP-230-WSP中討論了無線會話協(xié)i義(WSP)，其可在wwwI.wapforum.org/tech/documents/WAP-ZSO-WSPJOOlOTOS-a.pdf處獲得(通過引用的方式將其納入文中)。在IETFRFC2326中討論了實時流式協(xié)議(RTSP)，其可在www.ietf.org/rfc/rfc2326.txt處獲得(通過引用的方式將其納入文中)。3GPP分組交換流式服務(wù)(PSS)是使得能夠在移動設(shè)備中進(jìn)行分組交換流式傳輸?shù)?GPP解決方案。PSS定義了使得流式服務(wù)能夠用于移動設(shè)備的協(xié)議和媒體編解碼器。PSS基于用于會話建立和控制的RTSP。當(dāng)前在3GPP中定義了3GPP分組交換流式服務(wù)增強(PSSe)。這些增強的目的是為了定義對3GPPPSSReleaseNo.6的擴展，以便優(yōu)化流式服務(wù)。可以在3GPPTS26.233V6.0.0(2004-09)中找到對于PSS的概括性描述Transparentend-to-endpacketswitchedstreamingservice(PSS);Generaldescription(Release6)，可在www.3gpp.org/ftp/Specs/archive/26_series/26.233處獲得(通過引用的方式將其納入文中)。對于"僅下載"使用情況，當(dāng)前沒有完整地指定MBMS切換機制。開放移動聯(lián)盟(OMA)-PUSH(推送)M是一個用于實現(xiàn)這樣的切換的選項，但卻存在^艮多缺陷。OMA-PUSH系統(tǒng)一般根據(jù)3GPPTSG-SA4#41TdocS4-060662中的提議如下。在該系統(tǒng)中，如果MBMS用戶裝備(UE)在其歸屬網(wǎng)絡(luò)之外，并且如果4^供了接入地址(例如作為單播接入URI(unicastAccessURI))的屬性在遞送方法描述中是可用的，那么MBMSUE向BM-SC注冊其MBMS下載服務(wù)。單播月良務(wù)遞送注^Hf求包括MBMS用戶服務(wù)的標(biāo)識(例如作為MBMS用戶服務(wù)的serviceld(服務(wù)ID))，以及用戶i殳備的標(biāo)識(例如作為MBMSUE的移動臺綜合月良務(wù)數(shù)字網(wǎng)(MSISDN)。MBMSUE使用HTTP請求方法GET作出單播服務(wù)遞送注冊請求。在因特網(wǎng)工程任務(wù)組(IETF)請求注解(RFC)2616(1999年6月)中詳細(xì)討論了HTTP:"HypertextTransferProtocol—HTTP/1.1"(可在www.ietf.org/rfc/rfc2616.txt處獲得，并且通過引用的方式將其納入文中)。MBMSUE的serviceld和MSISDN被編碼到URI查詢部分中，這在IETFSTD0066/RFC3986(2005年1月)中進(jìn)行了詳細(xì)的討論"UniformResourceIdentifier(URI)，，(可在www.ietf.org/rfc/rfc3986.txt處獲得，并且通過引用的方式將其納入文中)，如以下所定義的，在HTTPGET請求中包括該URI查詢部分GET/unicastRegserviceId=urn:3gpp:0010120123hotdog&MSISDN=436642012345HTTP/1.1Host:bmsc.example.comMBMS下載遞送會話可以含有一個或多個文件。在FLUTE文件遞送表(FDT)中描述了所述文件。如果MBMS下載遞送方法含有超過一個的文件，那么如J.Palme、A.Hopmann、N.Shelness在IETFRFC2557(1999年3月)的"MIMEEncapsulationofAggregateDocuments,suchasHTML(MHTML)，，(可在www.ietf.org/rfc/rfc3986.txt處獲得，并且通過引用的方式將其納入文中)中所定義的多部分MIME(MultipartMIME)被用來將所述文件封裝到聚合服務(wù)通告文檔中。根據(jù)如在OMAPushOTA(推送空中下載)協(xié)議(2001年4月25日)WAP-235-PushOTA-20010425隱a中所討論的OMAPushOver國the-Air(OTA)規(guī)范，來格式化在HTTP推送承載上的MBMS下載，其可在www.openmobilealliance.org/tech/affiliates/wap/wap-235-pushota-20010425-a.pdf處獲得(通過引用的方式將其納入文中)。在HTTP推送承載上使用OTA-HTTP。如在OMAPushOTA協(xié)議中所指定的使用了應(yīng)用端口尋址。要使用的應(yīng)用ID由OMA命名機構(gòu)(OMNA)來分配，如在OMAOMNA注冊PUSH應(yīng)用ID列表www.openmobilealliance.org/tech/omna/omna-push-app-id.htm中所討論的(通過引用的方式將其納入文中)。如果使用GZip壓縮工具，則會包括內(nèi)容編碼報頭。OMA-PUSH方法有許多缺陷。例如，在該布置中，廣播-多播服務(wù)中心(BM-SC)沒有關(guān)于MBMS客戶機的狀態(tài)的任何信息，即，BM-SC不知道哪些對象、源塊或符號將要經(jīng)由OTA-HTTP被遞送到MBMS客戶機。在接收到以上引用的單播注冊請求之后，BM-SC的行為是不清楚的。然而，BM-SC可以表現(xiàn)為兩種方式中的任何一種。如果FLUTE會話涉及各種尺寸的多個對象，那么BM-SC不得不經(jīng)由OTA-HTTP會話來傳輸FLUTE會話的所有對象，包括客戶機已經(jīng)在FLUTE會話中接收到的對象。這造成很大的資源浪費?？蛇x地，在接收到上述注冊請求之后，BM-SC可以經(jīng)由OTA-HTTP僅發(fā)送剩余對象，在這種情況下，客戶機在所接收到的數(shù)據(jù)中具有一些"孔"。在這種情形下，客戶機不具有從它停止接收FLUTE傳輸?shù)狞c以來以;^從BM-SC開始經(jīng)由OTA-HTTP發(fā)送數(shù)據(jù)的點以來的任何數(shù)據(jù)。另外，在OTA-HTTP會話的結(jié)束處，客戶機仍然不得不發(fā)起另一HTTP會話，用于對不完整對象/源塊的點到點(PtP)修復(fù)。盡管在兩個HTTP會話可以被組合成一個的情況下可減少信令開銷，然而在這些情形中，一個HTTP^4t由BM-SC發(fā)起，而另一HTTP^t由客戶機發(fā)起。如果文件遞送表(FDT)是動態(tài)的，那么每當(dāng)存在更新的FDT時，BM-SC服務(wù)器都可以進(jìn)行對客戶機的OMA-PUSH操作。在這種情況下，客戶機不需要進(jìn)行對FDT更新的任何輪詢。然而，以上引用的缺陷仍舊存在。另一在下載遞送期間用于實現(xiàn)MBMS切換的選項涉及在單播系統(tǒng)上使用FLUTE/UDP。然而，這種方法要求不必要的開銷來包括FLUTE報頭和轉(zhuǎn)發(fā)糾錯(FEC)修復(fù)符號。特別地，F(xiàn)LUTE報頭和FEC修復(fù)符號對于點到點遞送來說都是不必要的。另外，對于FLUTE/UDP傳輸，還必須建立新的RTSP會活。除以上之外，在MBMSTS26.346v7.2.0中所指定的PtP修復(fù)請求/響應(yīng)機制也可以被擴展用于在少數(shù)特殊環(huán)境下的MBMS切換使用情況。當(dāng)MBMS客戶^U^MBMS-覆蓋區(qū)移動到MBMS-中斷區(qū)中時，其可以觸發(fā)PtP文件修復(fù)機制?？蛻魴C然后嘗試進(jìn)行對于到該點為止所接收到的所有對象的所有源塊的FEC解碼，確定缺失符號的數(shù)目/身份，并且通過包括所有要求的細(xì)節(jié)(例如，文件URI、源塊號(SBN)、缺失符號的數(shù)目、缺失符號的編碼符號ID(ESI)等)來向修復(fù)服務(wù)器發(fā)送HTTPGET請求。如果客戶機已經(jīng)接收到FDT，并且如果該FDT對FLUTE會話的其余部分保持為靜態(tài)，那么它知道在FLUTE會話的剩余部分中將期望哪些文件URI/對象?？蛻魴C然后可以向修復(fù)服務(wù)器請求當(dāng)前對象中的剩余源塊以及當(dāng)前會活中的剩余對象。因而，MBMS客戶機也可以重用用于MBMS切換使用情況的PtP修復(fù)請求機制。不幸的是，F(xiàn)DT《艮有可能是動態(tài)的，即，在相同的FLUTE會話中可能存在所傳送的FDT的新實例。因此，客戶機不能假定FDT是靜態(tài)的，因為FLUTE明確允許FDT是動態(tài)的，并且它允許在FLUTE會話的帶內(nèi)遞送FDT的新實例。因此，PtP修復(fù)請求機制往往不能過載以便覆蓋MBMS切換使用情況。因此，提供一種既可以被用于靜態(tài)FDT又可以被用于動態(tài)FDT但卻不過度使用開銷的解決方案將是令人期望的。
發(fā)明內(nèi)容本發(fā)明的各種實施例涉及使用HTTP/1.1"組塊(chunked)"模式來在推送式模式(push-likemode)中遞送會話的FDT的更新。多部分多用途因特網(wǎng)郵件擴展(MIME)消息的每個部分由內(nèi)容類型報頭中所聲明的邊界隔開。不期望在消息有效載荷中出現(xiàn)的任何串都可以被用作分隔符。所述多部分mime消息的每個部分還必須指定該部分的內(nèi)容類型。為了允許推送對FLUTE會話的內(nèi)容的遞送，每個FDT實例被編碼為多部分MIME消息的一個部分，并且作為單獨的組塊凈iL良送。接收機可以解譯每個所述單獨的組塊，以便從所述組塊中提取FDT實例。所述消息的每個部分的內(nèi)容類型被設(shè)置為"text(文本)/xml"或另一MIMI類型，以便指示所述內(nèi)容是FDT實例。在解析所述FDT實例和更新所述FDT之后，所述接收機能夠標(biāo)識所述會活的哪些文件是感興趣的，并且可以進(jìn)行HTTPGET請求iM^索特定的文件。所iU良務(wù)器可以使用HTTP的連對艮頭字段(其具有被設(shè)置為"closed(閉合)"的值)來指示所述會話的結(jié)束。利用本發(fā)明的各種實施例，不需要對OTA-HTTP或OTA-WSP的完整實現(xiàn)來實現(xiàn)推送遞送，因為文件修復(fù)功能已要求對HTTP/1.1的支持。12從以下結(jié)合附圖進(jìn)行的詳細(xì)描述中，本發(fā)明的這些和其它的優(yōu)勢和特征及其組織和操作方式一起將變得顯而易見，其中，遍及以下描述的若干附圖中，同樣的元件具有同樣的標(biāo)記。圖l是示出了實現(xiàn)本發(fā)明實施例的過程的流程圖2是示出了根據(jù)本發(fā)明的一個實施例在文件下載會話期間的MBMS切換的示圖3是示出了根據(jù)本發(fā)明實施例經(jīng)由多個組塊從服務(wù)器向客戶機終端傳輸多個FDT實例的示圖4是可以在本發(fā)明的實現(xiàn)中使用的電子設(shè)備的透視圖；以及圖5是圖4的電子設(shè)備的電路的示意性示圖。具體實施例方式本發(fā)明的各種實施例涉及使用HTTP/1.1"組塊"模式來以推送式模式遞送^的FDT的更新。在HTTP/1.1中定義了組塊模式，以便支持來自服務(wù)器的動態(tài)內(nèi)容生成和遞送。在幾個情況中，Web服務(wù)器可以不知道內(nèi)容的確切長度。組塊模式是一種傳送編碼的形式，它允許將內(nèi)容分成已知長度的組塊，然后每個組塊可以在消息部分中被發(fā)送到接收機。HTTP1.1組塊模式通常與持久連接一起使用，這允許推送型遞送。使用多部分/混合內(nèi)容類型來傳輸消息的內(nèi)容，且消息的每個部分作為單獨的組塊被遞送。接收機可以解譯每個單獨的組塊，以便從組塊中提取FDT實例。消息的每個部分的內(nèi)容類型凈皮，沒置為"text/xml"或另一MIME類型來指示該內(nèi)容是FDT實例。在解析FDT實例并且更新FDT之后，接收機能夠標(biāo)識會話的哪些文件是感興趣的，并且可以進(jìn)行HTTPGET請求**索特定文件。服務(wù)器可以使用HTTP的連接報頭字段(其具有被設(shè)置為"閉合"的值)來指示會話的結(jié)束。圖2較為詳細(xì)地示出了根據(jù)本發(fā)明的一個實施例的MBMS切換過程，其中在切換前和切換時，根據(jù)FLUTE協(xié)議對組塊進(jìn)行廣播/多播。如圖2中所示，一旦組塊被發(fā)送用于單播接收，新的傳輸對象標(biāo)識符(TOI)便被用于所述組塊，并且用于所述組塊的源塊號(SBN)被重置。圖l是示出了可以實現(xiàn)本發(fā)明實施例的過程的流程圖。在圖1中的IOO處，曾處于MBMS覆蓋區(qū)內(nèi)的終端離開MBMS覆蓋區(qū)。在105處，該終端從服務(wù)通告中檢索單播接入URI。在110處，該終端建立與HTTP或Web服務(wù)器的持久TCP連接。在115處，該終端向HTTP服務(wù)器發(fā)送GET請求。請求URL與單播接入URI相同，其在HTTP服務(wù)器處唯一標(biāo)識了FLUTE會話。以下是關(guān)于請求可如何出現(xiàn)的樣例GET/flute—seriveserviceId=2987324HTTP/1.1Host:www.example.com在120處，HTTP服務(wù)器將從終端接收到的請求標(biāo)識為對發(fā)起FLUTE會話的單播遞送的請求，并且基于"serviceld(服務(wù)ID)"參數(shù)來標(biāo)識服務(wù)，其中"serviceld"^!t與服務(wù)通告所指示的serviceld相同。在125處，HTTP服務(wù)器創(chuàng)建響應(yīng)消息。該響應(yīng)消息指示它是否愿意服務(wù)該終端。以下是包括了關(guān)于HTTP服務(wù)器愿意服務(wù)該終端的指示的樣例響應(yīng)HTTP/1.1200OKContent-type:multipart/mixed(內(nèi)容-類型多部分/混合)Transfer-encoding:chunked(傳送-編碼組塊)在130處，新的FDT實例變得可用。當(dāng)新的FDT實例變得可用時，在135處，HTTP服務(wù)器創(chuàng)建新的組塊，并且將新的FDT實例作為多部分MIMI消息的新的部分來派送。這在每次新的FDT實例變得可用時被重復(fù)。圖3是示出了在125的HTTP響應(yīng)消息已被發(fā)送之后經(jīng)由多個組塊從HTTP服務(wù)器向終端傳輸FDT實例的示圖。在140處，接收機接收并檢查組塊，并ibf目應(yīng)地更新其FDT。隨后，在140處所表示的，接收機可以發(fā)送GET請求，以便檢索感興趣的文件。圖4和圖5示出了一個代表性的電子設(shè)備12，在電子設(shè)備12內(nèi)可以實現(xiàn)本發(fā)明。然而，應(yīng)當(dāng)理解，本發(fā)明并不旨在限于電子設(shè)備12的一個特14定類型。圖4和圖5的電子設(shè)備12包括外殼30、液晶顯示器形式的顯示器32、鍵板34、擴音器36、耳機38、電池40、紅外端口42、天線44、根據(jù)本發(fā)明一個實施例的UICC形式的智能卡46、讀卡器48、無線電接口電路52、編解碼器電路54、控制器56、存儲器58以及電池80。各個電路和元件都是本領(lǐng)域中的已知類型，例如諾基亞移動電話系列。移動電話。文中所描述的各種實施例是在方法步驟或過程的一般情景中描述的，通過在計算機可讀^h質(zhì)中體現(xiàn)的計算機程序產(chǎn)品，可以在一個實施例中實現(xiàn)所述方法步驟或過程，所述計算機程序產(chǎn)品包括了由計算機在聯(lián)網(wǎng)環(huán)境中執(zhí)行的諸如程序代碼的計算機可執(zhí)行指令。計算機可讀介質(zhì)可以包括可裝卸的和不可裝卸的存^i殳備，包括但不限于只讀存儲器(ROM)、隨機訪問存儲器(RAM)、光盤(CD)、數(shù)字通用盤(DVD)等。一般地，程序模塊包括實施特定任務(wù)或?qū)崿F(xiàn)特定抽象數(shù)據(jù)類型的例程、程序、對象、組件、數(shù)據(jù)結(jié)構(gòu)等。計算機可執(zhí)行指令、關(guān)聯(lián)數(shù)據(jù)結(jié)構(gòu)以及程序模塊代表用于執(zhí)行文中所公開的方法的步驟的程序代碼的例子。這樣的可執(zhí)行指令或關(guān)聯(lián)數(shù)據(jù)結(jié)構(gòu)的特定序列代表用于實現(xiàn)在這樣的步驟中所描述的功能的對應(yīng)動作的例子。驟或過程、相關(guān)步驟或過程、比較步驟或過程以及判決步驟或過程的邏輯，可以完成各種實施例的軟件和Web實現(xiàn)。應(yīng)當(dāng)注意，如文中以及在以下權(quán)利要求中所使用的措辭"組件"和"模塊"，旨在包括使用一行或多行軟件代碼的實現(xiàn)和/或硬件實現(xiàn)和/或用于接收手動輸入的裝備。已經(jīng)出于說明和描述的目的給出了對本發(fā)明實施例的前述描述。以上描述并不旨在是窮舉性的或是將本發(fā)明的實施例限制于所公開的精確形式，根據(jù)前述教導(dǎo)的修改和變型是可能的，或者可以從本發(fā)明的實踐中獲得這些修改和變型。選擇并描述了文中所討論的實施例是為了解釋各種實施例的原理和特性及其實際應(yīng)用，以便使本領(lǐng)域的技術(shù)人員能夠在各種實施例中利用本發(fā)明并且使各種修改適合于所設(shè)想的特定使用。文中所描述的實施例的特征可以被組合在方法、裝置、模塊、系統(tǒng)和計算機程序產(chǎn)品的所有可能的組合中。權(quán)利要求1.一種方法，其包括在退出多媒體廣播/多播服務(wù)(MBMS)服務(wù)區(qū)之后，建立與超文本傳送協(xié)議(HTTP)服務(wù)器的持久TCP連接；向所述HTTP服務(wù)器發(fā)送第一GET請求；從所述HTTP服務(wù)器接收響應(yīng)消息，其指示所述HTTP服務(wù)器愿意提供服務(wù)；以及每當(dāng)新的文件遞送表(FDT)實例變得可用時，從所述HTTP服務(wù)器接收在數(shù)據(jù)組塊中的所述新的FDT實例。2.根據(jù)權(quán)利要求1的方法，其進(jìn)一步包括在接收到所述新的FDT實例時，更新FDT來反映所述新的FDT實例。3.根據(jù)權(quán)利要求1的方法，其進(jìn)一步包括發(fā)送第二GET請求，以便從所述HTTP服務(wù)器獲得感興趣的文件。4.根據(jù)權(quán)利要求l的方法，其中，所述數(shù)據(jù)組塊是多用途因特網(wǎng)郵件擴展(MIME)消息的一部分。5.根據(jù)權(quán)利要求1的方法，其中，所述持久TCP連接是使用從之前的服務(wù)通告中所接收的單播接入URI來建立的。6.才艮據(jù)權(quán)利要求5的方法，其中，所述第一GET請求包括與所述單播接入URI相同的請求URL。7.—種體現(xiàn)在計算機可讀介質(zhì)中的計算機程序產(chǎn)品，其包括用于實施根據(jù)權(quán)利要求1的過程的計算機代碼。8.—種裝置，其包括處理器；以及存儲單元，所述存儲單元在通信上被連接到所述處理器并且包括用于在退出多媒體廣播/多播服務(wù)(MBMS)服務(wù)區(qū)之后建立與超文本傳送協(xié)i義(HTTP)服務(wù)器的持久TCP連接的計算機代碼；用于向所述HTTP服務(wù)器發(fā)送第一GET請求的計算機代碼；用于處理從所述HTTP服務(wù)器所接收的指示所述HTTP服務(wù)器愿意提供服務(wù)的響應(yīng)消息的計算機代碼；以及用于每當(dāng)新的文件遞&(FDT)實例變得可用時，從所述HTTP服務(wù)器接收在數(shù)據(jù)組塊中的所述新的FDT的計算機代碼.9.根據(jù)權(quán)利要求8的裝置，其中所述存儲單元進(jìn)一步包括用于在接收到所述新的FDT時，更新FDT來反映新的FDT實例的計算機代碼。10.根據(jù)權(quán)利要求8的裝置，其中所述存儲單元進(jìn)一步包括用于發(fā)送第二GET請求以便從所述HTTP服務(wù)器獲得感興趣的文件的計算機代碼。11.根據(jù)權(quán)利要求8的裝置，其中，所述數(shù)據(jù)組塊是多用途因特網(wǎng)郵件擴展(MIME)消息的一部分。12.根據(jù)權(quán)利要求8的裝置，其中，所述持久TCP連接是使用從之前的服務(wù)通告中所接收的單播接入URI來建立的。13.根據(jù)權(quán)利要求12的裝置，其中，所述笫一GET請求包括與所述單播接入URI相同的請求URL。14.一種方法，其包括從已經(jīng)退出MBMS服務(wù)區(qū)的多媒體廣播/多播服務(wù)(MBMS)終端接收第一GET請求；將所述第一GET請求標(biāo)識為所述MBMS終端對J^FLUTE會活的單播遞送的請求；在決定服務(wù)所述MBMS終端時，向所述接收機發(fā)送響應(yīng)消息；以及每當(dāng)新的文件遞送表(FDT)實例變得可用時，在數(shù)據(jù)組塊中向所述MBMS終端發(fā)送所述新的FDT實例。15.根據(jù)權(quán)利要求14的方法，其中，所述數(shù)據(jù)組塊是多用途因特網(wǎng)郵件擴展(MIME)消息的一部分。16.根據(jù)權(quán)利要求14的方法，其中，所述第一GET請求包括與來自之前的服務(wù)通告的單播接入URI相同的請求URL。17.根據(jù)權(quán)利要求14的方法，其進(jìn)一步包括從所述MBMS終端接收對于獲得感興趣的文件的第二GET請求；以及響應(yīng)于所述第二GET請求，向所述MBMS終端發(fā)送所述感興趣的文件。18.根據(jù)權(quán)利要求14的方法，其進(jìn)一步包括使用服務(wù)ID參數(shù)來標(biāo)識由所述MBMS終端所請求的服務(wù)，所述服務(wù)ID參數(shù)與在之前的服務(wù)通告中所含有的標(biāo)識相同。19.一種體現(xiàn)在計算機可讀介質(zhì)中的計算機程序產(chǎn)品，其用于實施根據(jù)權(quán)利要求14的過程。20.—種裝置，其包括處理器；以及存儲單元，所述存儲單元在通信上被連接到所述處理器并且包括用于處理從已經(jīng)退出MBMS服務(wù)區(qū)的多媒體廣播/多播服務(wù)(MBMS)終端所接收的第一GET請求的計算機代碼；用于將所述第一GET請求標(biāo)識為所述MBMS終端對發(fā)起FLUTE會話的單播遞送的請求的計算機代碼；用于在決定服務(wù)所述MBMS終端時，向所述接收機發(fā)送響應(yīng)消息的計算機代碼；以及用于每當(dāng)新的文件遞&(FDT)實例變得可用時，在數(shù)據(jù)組塊中向所述MBMS終端發(fā)送所述新的FDT實例的計算機代碼。21.根據(jù)權(quán)利要求20的裝置，其中，所述數(shù)據(jù)組塊是多用途因特網(wǎng)郵件擴展(MIME)消息的一部分。22.根據(jù)權(quán)利要求20的裝置，其中，所述第一GET請求包括與來自之前的服務(wù)通告的單播接入URI相同的請求URL。23.根據(jù)權(quán)利要求20的裝置，其中，所述存儲單元進(jìn)一步包括用于處理所接收的對于獲得感興趣的文件的第二GET請求的計算機代碼；以及用于響應(yīng)于所述第二GET請求，向所述MBMS終端發(fā)送所述感興趣的文件的計算機代碼。24.根據(jù)權(quán)利要求20的裝置，其中所述存儲單元進(jìn)一步包括用于使用服務(wù)ID參數(shù)來標(biāo)識由所述MBMS終端所請求的服務(wù)的計算機代碼，所述服務(wù)ID參數(shù)與在之前的服務(wù)通告中所含有的標(biāo)識相同。25.—種系統(tǒng)，其包括多媒體廣播/多播服務(wù)(MBMS)終端；以及超文本傳送協(xié)議(HTTP)服務(wù)器，其中，所述MBMS終端被配置以便在退出多媒體廣播/多播服務(wù)(MBMS)服務(wù)區(qū)之后，建立與所述HTTP服務(wù)器的持久TCP連接；以及向所述HTTP服務(wù)器發(fā)送第一GET請求；并且其中，所述HTTP月良務(wù)器^L配置以便將所述第一GET請求標(biāo)識為所述MBMS終端對發(fā)起FLUTE會話的單播遞送的請求；當(dāng)決定服務(wù)所述MBMS終端時，向所述接收機發(fā)送響應(yīng)消息；以及每當(dāng)新的文件遞i^(FDT)實例變得可用時，在數(shù)據(jù)組塊中向所述MBMS終端發(fā)送所述新的FDT實例。26.根據(jù)權(quán)利要求25的系統(tǒng)，其中所述MBMS終端被進(jìn)一步配置以便在接收到所述新文件遞i^時，更新所述MBMS終端的FDT來反映所述新的FDT實例。27.根據(jù)權(quán)利要求25的系統(tǒng)，其中所述MBMS終端被進(jìn)一步配置以便發(fā)送第二GET請求，以l更從所述HTTP服務(wù)器獲得感興趣的文件，并且其中，所述HTTP服務(wù)器被進(jìn)一步配置以便響應(yīng)于所述第二GET請求，向所述MBMS終端發(fā)送所述感興趣的文件。28.根據(jù)權(quán)利要求25的系統(tǒng)，其中，所述數(shù)據(jù)組塊是多用途因特網(wǎng)郵件擴展(MIME)消息的一部分。29.根據(jù)權(quán)利要求25的系統(tǒng)，其中，所述持久TCP連接是使用從之前的服務(wù)通告中所接收的單播接入URI來建立的。全文摘要一種改進(jìn)的系統(tǒng)和方法，用于在下載遞送期間實現(xiàn)多媒體廣播/多播服務(wù)(MBMS)切換。本發(fā)明的各種實施例涉及使用HTTP/1.1“組塊”模式來在推送式模式中遞送會話的文件遞送表(FDT)的更新。為了允許對FLUTE會話的內(nèi)容的推送遞送，每個FDT實例被編碼為多部分MIME消息的一個部分，并且作為單獨的組塊被發(fā)送。接收機可以解譯每個所述單獨的組塊，以便從所述組塊提取FDT實例。所述消息的每個部分的內(nèi)容類型被設(shè)置成“text/xml”或另一MIMI類型，以便指示所述內(nèi)容是FDT實例。在解析所述FDT實例并且更新所述FDT之后，所述接收機能夠標(biāo)識所述會話的哪些文件是感興趣的，并且可以進(jìn)行HTTPGET請求來檢索特定的文件。文檔編號H04W80/06GK101589630SQ200880003052公開日2009年11月25日申請日期2008年1月8日優(yōu)先權(quán)日2007年1月10日發(fā)明者I·布阿茲茲,R·韋旦薩姆申請人:諾基亞公司