專利名稱：廣播組播業(yè)務(wù)中的接收上報方法以及接收上報處理裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，尤其涉及一種廣播組播業(yè)務(wù)中的接收上 報方法以及接收上報處理裝置。
背景技術(shù)：
在各種移動分組業(yè)務(wù)中，包括視頻點(diǎn)播、電視廣播、視頻會議、 網(wǎng)上教育、互動游戲等業(yè)務(wù)具有一個主要特征，就是訂閱該業(yè)務(wù)的
多個用戶同時^妻收相同的彰:據(jù)，而且這業(yè)務(wù)和一4殳凄t據(jù)相比，往往 具有并發(fā)用戶多、數(shù)據(jù)量大、持續(xù)時間長、時延敏感等特點(diǎn)。顯然， 對這類業(yè)務(wù)仍然沿用普通點(diǎn)到點(diǎn)傳輸方法，對于資源緊缺的移動通 信網(wǎng)絡(luò)而言是非常低效率的。為此，3GPP(第三代合作項目)針對 這一類廣"l番和組，燔業(yè)務(wù)的傳llr需求，在Release 6引入MBMS (Multimedia Broadcast Multicast Service,多々某體廣才番和纟Ji番業(yè)務(wù)) 技術(shù)，在移動網(wǎng)絡(luò)中提供一個數(shù)據(jù)源向多個用戶發(fā)送數(shù)據(jù)的點(diǎn)到多 點(diǎn)業(yè)務(wù)，實(shí)現(xiàn)網(wǎng)絡(luò)資源共享，提高網(wǎng)絡(luò)資源的利用率，尤其是空口 接口資源。3GPP定義的MBMS不僅能實(shí)現(xiàn)純文本低速率的消息類 組播和廣播，而且還能實(shí)現(xiàn)高速多媒體業(yè)務(wù)的組播和廣播，這無疑 順應(yīng)了未來移動數(shù)據(jù)發(fā)展的趨勢。
根據(jù)3GPP的規(guī)范"3GPP TS 26.346 Multimedia Broadcast /Multicast Service (MBMS )Protocols and codecs, V6.3.0, 2005-12，，， 基于MBMS的分發(fā)業(yè)務(wù)分三個功能層(如圖1所示)，即承載層
(Bearers ), 分發(fā)方法(Delivery Method )層與用戶業(yè)務(wù)(User Service)層。承載層是基于MBMS業(yè)務(wù)的基礎(chǔ)，提供了IP數(shù)據(jù)傳 輸?shù)臋C(jī)制，以一對多的方式傳輸組播和廣播業(yè)務(wù)。分發(fā)方法層提供 安全性及密鑰分發(fā)，采用前向糾4普FEC ( Forward-error-Correction ) 的可靠性控制，以及文件修復(fù)、分發(fā)驗證等功能。主要有兩種分發(fā) 方法，即下載(Download)和;危(Streaming)方法。用戶業(yè)務(wù)層主 要是各種應(yīng)用，不同的應(yīng)用采用不同的分發(fā)方法將內(nèi)容分發(fā)給 MBMS i丁閱用戶。
超文本才示準(zhǔn)i吾言HTML ( Hypertext Markup Language )是一種 用來對用Web瀏覽器表示的信息進(jìn)行編碼的特定標(biāo)志語言。可以 說，當(dāng)今世界互聯(lián)網(wǎng)的蓬勃發(fā)展，HTML立下了汗馬功勞?？墒?， HTML自身的特點(diǎn)使它蘊(yùn)藏了許多危機(jī)，隨著它不斷的發(fā)展，這些 危機(jī)不但沒有減弱，反而越來越突出，甚至成為了 HTML繼續(xù)發(fā)展 應(yīng)用的障石尋。可才廣展才示)隹i吾言XML ( extensible Markup Language ) 開創(chuàng)了 Web的新紀(jì)元，它建立了一種傳，俞結(jié)構(gòu)^>#^居的方法。
傳統(tǒng)上，確認(rèn)XML文件需要使用文件類型定義(DTD, Document Type Definition )，這是繼7 c自SGML( Standard Generalized Markup Language,標(biāo)準(zhǔn)通用標(biāo)i己i吾言)的。雖然DTD在以確i人為 目的的i殳置文件格式方面非常有用，他們也有4艮多的確定。XML Schema是W3C的推薦標(biāo)準(zhǔn)，于2001年5月正式發(fā)布，經(jīng)過數(shù)年 的大規(guī)模討論和開發(fā)，終于最終奠定下來，使得XML建模有了一 個國際標(biāo)準(zhǔn)。XML Schema—確定下來，立刻成為全J求^/H人的首選 XML環(huán)境下的建才莫工具，已經(jīng)基本取代了 DTD在XML剛剛成為 W3C推薦標(biāo)準(zhǔn)時的地位。按照W3C的定義，Schema是"一個XML 文件的結(jié)構(gòu)綁定和信息集管理的規(guī)則的集合"。
XML Schema的主要目的是用來定義一類XML文檔( 一個 XML Application )。因此才莫式的"實(shí)例文檔"形式常常用來描述一
個與凈爭定XML Schema珅目 一致的XML文4當(dāng)。事實(shí)上，文檔實(shí)例和 Schema文檔都不是必須要以文檔的形式存在，他們可以以在應(yīng)用 之間傳遞的字節(jié)流的形式存在，或者作為一個數(shù)據(jù)庫記錄或者作為 XML的"信息項"的集合而存在。
MBMS用戶業(yè)務(wù)與MBMS系統(tǒng)間的接口主要有三個實(shí)體廣 4番組4番業(yè)務(wù)中心(Broadcast Multicast Service Center,簡稱BM國SC )， 網(wǎng)關(guān)GPRS業(yè)務(wù)點(diǎn)(Gateway GPRS Serving Node,簡稱GGSN)以 及用戶設(shè)備(User Equipment,簡稱UE)。 MBMS用戶業(yè)務(wù)體系架 構(gòu)是基于UE側(cè)的MBMS接收才幾(MBMS receiver )和網(wǎng)絡(luò)側(cè)的廣 播組播業(yè)務(wù)中心。其中廣播組播業(yè)務(wù)中心的功能結(jié)構(gòu)如圖2所示。
如圖2所示，廣播組播業(yè)務(wù)中心主要具有如下功能
用戶業(yè)務(wù)發(fā)現(xiàn)與聲明(User Service Discovery/Announcement )， 提供業(yè)務(wù)描述以及業(yè)務(wù)內(nèi)容中的應(yīng)用參數(shù)給終端用戶。
密鑰i青求(Key Request)與注冊(Registration);充#呈，用于接 收密鑰以及密鑰更新。
密鑰分配(Key Distribution ),用于廣4番組4番業(yè)務(wù)中心分配接入 業(yè)務(wù)數(shù)據(jù)與分發(fā)內(nèi)容的密鑰資料。
會話與傳輸(Session and Transmission)功能，進(jìn)一步分為廣播" 組才番業(yè)務(wù)中心分發(fā)(MBMS Delivery )功能和關(guān)聯(lián)分發(fā)(Associated Delivery)功能。關(guān)聯(lián)分發(fā)功能為多媒體廣播和組播業(yè)務(wù)用戶業(yè)務(wù)、 多媒體廣播和組播業(yè)務(wù)分發(fā)方法及其會話提高輔助特征。其中， 3GPPTS 26.346支持的關(guān)聯(lián)分發(fā)流程有多媒體廣播和組播業(yè)務(wù)下 載接收機(jī)支持文件修復(fù)過程(File repair procedure )、接收上報流程
(reception reporting procedure )、以及多媒體廣播和組播業(yè)務(wù)流接收 才幾支持4妻4欠上才艮5充禾呈(reception reporting procedure )。
對于多媒體廣播和組播業(yè)務(wù)下載分發(fā)來說，接收上報流程用來 報告一個或多各文件的完全接收。對于多媒體廣播和組播業(yè)務(wù)流分 發(fā)來說，接收上報流程用來報告流的相關(guān)統(tǒng)計信息。
如果廣播組播業(yè)務(wù)中心提供請求接收上報信息的參數(shù)，那么多 々某體廣^番和組4番業(yè)務(wù)^妻收才幾應(yīng)確i人接收的內(nèi)容。
如果請求用于統(tǒng)計目的的接收上報，那么廣播組播業(yè)務(wù)中心可 以指定多媒體廣播和組播業(yè)務(wù)接收機(jī)可能執(zhí)行的接收上報的百分 比子集。
關(guān)聯(lián)分發(fā)流程的關(guān)聯(lián)流程描述實(shí)例(description instance )可以 通過如下方式分發(fā)到客戶端 一是在多媒體廣播和組播業(yè)務(wù)下載分 發(fā)會話之前與會話描述(session description )在用戶業(yè)務(wù)聲明與發(fā) 現(xiàn)一起分發(fā)；也可在多媒體廣播和組播業(yè)務(wù)下載分發(fā)會話帶內(nèi)分 發(fā)。在XML中，每個關(guān)聯(lián)分發(fā)流程入口 (entry)用一個元素 "associatedProcedureDescription，，來西己置。 一個關(guān)聯(lián)分發(fā);危禾呈的f斤 有酉己置參凄丈包含在元素"associatedProcedureDescription"的屬性中。 元素"associatedProcedureDescription"的元素(如"postFileRepair" 和"postReceptionReport")表示其配置的關(guān)聯(lián)流程。接收上報關(guān)聯(lián) 分發(fā)流程描述的XML Schema具有如下特征
(1 )具有 一 個表示基本流程類型的復(fù)合類型 ("basicProcedureType")，該類型主要包括 一個表示服務(wù)器統(tǒng)一 資源標(biāo)識的元素("serviceURT )， 一個表示多媒體廣播和組播業(yè)務(wù) 客戶端在多媒體廣播和組播業(yè)務(wù)數(shù)據(jù)傳輸結(jié)束后到開始上報流程 等待的時間的屬性("offsetTime")，該屬性是可選的，且為無符號
整型；具有一個表示多媒體廣播和組播業(yè)務(wù)客戶端初始化接收上報 流程的時間窗長度的屬性("randomTimePeroid，，)，該屬性是必須的， 且為無符號整型。
(2)具有一個表示接收上報類型的復(fù)合類型 ("reportProcedureType")，該類型繼7 義于"basicProcddureType"類 型，該類型具有一個屬性"samplePercentag"用來設(shè)置上報接收情 況的接收機(jī)的取樣的百分比。samplePercentage的取值范圍為0到 100，可帶小數(shù)，不過小數(shù)點(diǎn)后最多不超過3位(如67.323就可保 證精度了 )，該屬性的use屬性為"optional",缺省屬性值為"100"; 具有一個布爾類型的屬性"forceTimelndependence"，該屬性表示 UE是否用文件修復(fù)點(diǎn)到點(diǎn)連接來發(fā)送接收上報消息，該屬性的use 屬性值為"optional",缺省屬性為"false";具有一個表示上報類型 的屬性"reportType"，該屬性的類型為"xs:string"類型，該屬性的 use屬性值為"optional"。
(3 )該接收上才艮關(guān)聯(lián)分發(fā)流程描述的XML Schema具有一個 元素 "postReceptionReport " ， it元素的 type 屬寸生 <直為 "reportProcedureType", ^亥元素的minOccurs屬寸生值為"0"。
在現(xiàn)有技術(shù)一 MBMS接收上報(reception reporting )關(guān)聯(lián)分發(fā) 流程描述的XML Schema中，屬性"reportType"的use屬性寸直為 "optional",即屬性"reportType"是可選的。而屬性"reprotType" 表示的是接收上報的類型，根據(jù)3GPPTS 26.36的定義，只存在三 種上才艮類型，即RAck類型，StaR類型和StaR-all類型。為RAck 類型時， <又<又才艮告成功接收文4牛，而不才艮告詳細(xì)細(xì)節(jié)。為StaR類 型時，才艮告文件成功4妄收(如RAck)及用于統(tǒng)計分析的接收詳細(xì) 信息。為StaR-all類型時，需報告文件成功接收及用于統(tǒng)計分析的 接收詳細(xì)信息，還得報告文件失敗接收。由于屬性reportType是可 選的，這樣在不指定上報類型的類型時，接收端將不知道采用何種
類型的上報方式，這沖羊會導(dǎo)致系統(tǒng)處理錯誤。另一方面，屬性
reportType只能取RAck、 StaR、 StaR-all三種類型中的一種，而才支 術(shù)一只是簡單的將其定義為"xs:string"類型，這樣一方面可能會導(dǎo) 致XML格式的非良好性，另一方面也可能導(dǎo)致客戶端無法識別上 報類型而導(dǎo)致錯誤。

發(fā)明內(nèi)容
針對現(xiàn)有技術(shù)中由于接收上報關(guān)聯(lián)分發(fā)流程的XML Schema設(shè) 計不合理可能導(dǎo)致接收端無法識別接收上報類型，從而導(dǎo)致無法及 時實(shí)施接收上報而S1起錯誤，本發(fā)明提供了 一種廣播組播業(yè)務(wù)中的 接收上報方法以及一種接收上報處理裝置。
本發(fā)明的廣播組播業(yè)務(wù)中的接收上報方法包括以下步驟步驟 S302,廣播組播業(yè)務(wù)中心生成接收上報關(guān)聯(lián)分發(fā)流程描述文件并將 描述文件發(fā)送至一個或多個用戶設(shè)備，其中，描述文件包括要求用 戶設(shè)備發(fā)送的接收上報消息的類型信息；步驟S304， 一個或多個用 戶設(shè)備接收到接收上報關(guān)聯(lián)分發(fā)流程描述文件后對其進(jìn)行解析并 確定要求的接收上報消息的上報類型；以及步驟S306,用戶設(shè)備生 成要求類型的接收上報消息并將其發(fā)送至接收上報服務(wù)器。
上述的接收上報消息的類型信息可以通過接收上報消息類型 (ReportType)的類型來限定。接收上報消息類型的類型必須是以 下三個枚舉值中的一個接收確認(rèn)RAck、成功接收的統(tǒng)計報告 StaR、以及所有內(nèi)容接收的統(tǒng)計報告StaR-all。接收上報消息類型 的缺省類型為4妻^)欠確i人RAck。
上述的接收上報消息的類型信息可以通過將接收上報消息類 型綁定于一個簡單類型來限定。該簡單類型包括以下三個枚舉值
接收確認(rèn)RAck、成功接收的統(tǒng)計報告StaR、以及所有內(nèi)容接收的 統(tǒng)計才艮告StaR-all。 4妄收上才艮消息類型的缺省類型為接收確i人RAck。
在接收上報消息的類型信息為接收確認(rèn)類型RAck的情況下， 用戶設(shè)備上報成功接收文件的信息，不上報成功接收的詳細(xì)信息。
在要求的接收上報消息的類型信息為成功接收的統(tǒng)計報告 StaR的情況下，用戶設(shè)備上報成功接收統(tǒng)計報告的信息、成功接收 文件的信息以及用于進(jìn)4于統(tǒng)計分析的詳細(xì)信息。
在要求的接收上報消息的類型信息為所有內(nèi)容接收的統(tǒng)計報 告StaR-all的情況下，用戶設(shè)備上報成功接收文件的信息、成功接 收統(tǒng)計才艮告的信息、用于進(jìn)^f于統(tǒng)計分析的信息、以及接收文件失敗 的4言息。
本發(fā)明的接收上報處理裝置包括用戶業(yè)務(wù)聲明模塊，用于生 成接收上報關(guān)聯(lián)分發(fā)流程描述文件并將描述文件發(fā)送至交互分發(fā) 模塊或會話與傳輸模塊，其中，描述文件包括要求用戶設(shè)備發(fā)送的 接收上報消息的類型信息；交互分發(fā)模塊，用于在與一個或多個用 戶i殳備進(jìn)4亍交互的情況下，將4妄收上才艮關(guān)聯(lián)分發(fā)流程描述文件發(fā)送 至一個或多個用戶設(shè)備；以及會話與傳輸模塊，用于在與一個或多 個用戶設(shè)備進(jìn)行會話的情況下，將接收上報關(guān)聯(lián)分發(fā)流程描述文件 發(fā)送至一個或多個用戶i殳備。
上述的接收上報消息的類型信息可以通過接收上報消息類型 的類型來限定。接收上報消息類型的類型必須是以下三個枚舉值之 一接收確認(rèn)RAck、成功接收的統(tǒng)計報告StaR、以及所有內(nèi)容接 收的統(tǒng)計報告StaR-all。接收上報消息類型的缺省類型為接收確認(rèn) RAck。
上述的接收上凈艮消息的類型信息可以通過將上凈艮消息類型一
個簡單類型來限定。簡單類型包括以下至少一個枚舉值接收確認(rèn) RAck、成功接收的統(tǒng)計報告StaR、以及所有內(nèi)容接收的統(tǒng)計報告 StaR-all。接收上才艮消息的缺省類型為接收確認(rèn)RAck。
在接收上報消息的類型信息為接收確認(rèn)類型RAck的情況下， 指示用戶設(shè)備上報成功接收文件的信息，不上報成功接收的詳細(xì)信 息。
在要求的接收上報消息的類型信息為成功接收的統(tǒng)計報告 StaR的情況下，指示用戶設(shè)備上報成功接收統(tǒng)計報告的信息、成功 接收文件的信息以及用于進(jìn)行統(tǒng)計分析的詳細(xì)信息。
在要求的接收上報消息的類型信息為所有內(nèi)容接收的統(tǒng)計報 告StaR-all的情況下，指示用戶設(shè)備上報成功接收文件的信息、成 功接收統(tǒng)計報告的信息、用于進(jìn)行統(tǒng)計分析的信息、以及接收文件 失敗的信息。
本發(fā)明能夠使接收上報關(guān)聯(lián)分發(fā)流程的XML Schema設(shè)計更加 合理，使接收端正確地識別接收上報類型，從而避免實(shí)施接收上報 而引起錯誤。


附圖提供本發(fā)明的進(jìn)一步理解，并結(jié)合到本申請中構(gòu)成本申請 的 一部分，與說明書 一起i兌明本發(fā)明的實(shí)施例以解釋本發(fā)明的原 理。在附圖中，
圖1是根據(jù)現(xiàn)有技術(shù)的多媒體廣播和組播業(yè)務(wù)功能層的示意
圖2是才艮據(jù)現(xiàn)有才支術(shù)的廣4番組4番業(yè)務(wù)中心的功能結(jié)構(gòu)的示意
圖3是根據(jù)本發(fā)明的廣播和組播業(yè)務(wù)中的接收上報方法的流程 圖；以及
圖4是根據(jù)本發(fā)明的廣播組播業(yè)務(wù)處理裝置的示意圖。
具體實(shí)施例方式
以下將參考附圖詳細(xì)描述本發(fā)明。
圖3是根據(jù)本發(fā)明的廣播和組播業(yè)務(wù)中的接收上報方法的流程 圖。如圖3所示，本發(fā)明的廣播組播業(yè)務(wù)中的接收上報方法包括以 下步驟步驟S302，廣播組播業(yè)務(wù)中心生成接收上報關(guān)聯(lián)分發(fā)流程 描述文件并將描述文件發(fā)送至一個或多個用戶設(shè)備，其中，描述文 件包括要求用戶設(shè)備發(fā)送的接收上報消息的類型信息；步驟S304， 一個或多個用戶設(shè)備接收到接收上報關(guān)聯(lián)分發(fā)流程描述文件后對 其進(jìn)行解析并確定要求的接收上報消息的上報類型；以及步驟 S306,用戶設(shè)備生成要求類型的接收上報消息并將其發(fā)送至接收上 報服務(wù)器。
上述的接收上報消息的類型信息可以通過接收上報消息類型 的類型來限定。接收上報消息類型的類型必須是以下三個枚舉值之 一接收確認(rèn)RAck、成功接收的統(tǒng)計報告StaR、以及所有內(nèi)容接 收的統(tǒng)計報告StaR-all。接收上報消息類型的缺省類型為接收確認(rèn) RAck。
上述的接收上報消息的類型信息可以通過將接收上報消息的 類型綁定于一個簡單類型來限定。該簡單類型包括以下三個枚舉 值接收確認(rèn)RAck、成功接收的統(tǒng)計才艮告StaR、以及所有內(nèi)容4妻
收的統(tǒng)計才艮告StaR-all。接收上凈艮消息類型的缺省類型為接收確認(rèn) RAck。
在接收上報消息的類型信息為接收確認(rèn)類型RAck的情況下， 用戶設(shè)備上報成功接收文件的信息，不上報成功接收的詳細(xì)信息。
在要求的接收上報消息的類型信息為成功接收的統(tǒng)計報告 StaR的情況下，用戶設(shè)備上報成功接收統(tǒng)計報告的信息、成功接收 文件的信息以及用于進(jìn)4于統(tǒng)計分析的詳細(xì)信息。
在要求的接收上報消息的類型信息為所有內(nèi)容接收的統(tǒng)計報 告StaR-all的情況下，用戶設(shè)備上報成功接收文件的信息、成功接 收統(tǒng)計才艮告的信息、用于進(jìn)行統(tǒng)計分析的信息、以及接收文件失敗 的4言息。
圖4是才艮據(jù)本發(fā)明的廣4番組4番業(yè)務(wù)處理裝置的示意圖。如圖4 所示，本發(fā)明的接收上才艮處理裝置400包括用戶業(yè)務(wù)聲明模塊402， 用于生成接收上報關(guān)聯(lián)分發(fā)流程描述文件并將描述文件發(fā)送至交 互分發(fā)模塊或會話與傳輸模塊，其中，描述文件包括要求用戶設(shè)備 發(fā)送的接收上報消息的類型信息；交互分發(fā)模塊404，用于在與一 個或多個用戶設(shè)備進(jìn)行交互的情況下，將接收上報關(guān)聯(lián)分發(fā)流程描 述文件發(fā)送至一個或多個用戶設(shè)備；以及會話與傳輸模塊406，用 于在與一個或多個用戶設(shè)備進(jìn)行會話的情況下，將接收上報關(guān)聯(lián)分 發(fā)流程描述文件發(fā)送至一個或多個用戶設(shè)備。
上述的接收上報消息的類型信息可以通過接收上報消息類型 的類型來限定。接收上報消息類型的類型必須是以下三個枚舉值之 一接收確i人RAck、成功接收的統(tǒng)計才艮告StaR、以及所有內(nèi)容接 收的統(tǒng)計才艮告StaR-all。接收上才艮消息類型的缺省值為接收確i人 RAck。
上述的接收上凈艮消息的類型信息可以通過將接收上凈艮消息類
型綁定于一個簡單類型來限定。簡單類型包括以下三個枚舉值接 收確認(rèn)RAck、成功接收的統(tǒng)計報告StaR、以及所有內(nèi)容接收的統(tǒng) 計報告StaR-all。接收上報消息類型的缺省類型為接收確認(rèn)RAck。
在接收上報消息的類型信息為接收確認(rèn)類型RAck的情況下， 指示用戶設(shè)備上報成功接收文件的信息，不上報成功接收的詳細(xì)信息。
在要求的接收上報消息的類型信息為成功接收的統(tǒng)計報告 StaR的情況下，指示用戶設(shè)備上報成功接收統(tǒng)計報告的信息、成功 接收文件的信息以及用于進(jìn)行統(tǒng)計分析的詳細(xì)信息。
在要求的接收上報消息的類型信息為所有內(nèi)容接收的統(tǒng)計報 告StaR-all的情況下，指示用戶設(shè)備上報成功接收文件的信息、成 功接收統(tǒng)計報告的信息、用于進(jìn)行統(tǒng)計分析的信息、以及接收文件 失敗的信息。
本發(fā)明的多媒體廣播組播中關(guān)聯(lián)分發(fā)流程中接收上報的XML Schema 設(shè)計，包含 一 個表示接收上報的元素 ("postReceptionReport")，并具有:i口下凈爭4正
(1) 具有一個表示上報類型的屬性，該屬性的use屬性值為 "optional",該屬性的缺省屬性為"RAck";將該屬性記為 "reportType，，，則用XML Schema規(guī)范表示為
<xs:attribute name="reportType，， use=，，optional，， default=，，RAck，，/>
(2) 如(1)所述，該表示上報類型的屬性(reportType)的 type屬性為"reportTypeType"，該"reportTypeType"表示上報類型 的類型，該類型有三個枚舉(enumeration)值("RAck"， "StaR",
"StaR-all")，即(1)中表示上才艮類型的屬性(reportType)只能取 "RAck"、 "StaR，,、 "StaR-all，，三者中之一。
設(shè)置reportType為RAck (Reception Acknowledgement,接收確 認(rèn))，僅報告成功接收文件，而不報告詳細(xì)細(xì)節(jié)。
設(shè)置reportType為 StaR ( Statistical Reporting for successful reception,成功接收統(tǒng)計報告)，報告文件成功接收(如RAck)及 用于統(tǒng)計分析的接收詳細(xì)信息。
設(shè)置reportType為StaR-all ( Statistical Reporting for all content reception,所有內(nèi)容接收的統(tǒng)計報告)，同StaR，需報告文件成功接 收及用于統(tǒng)計分析的接收詳細(xì)信息，還得報告文件失敗接收。
用XML Schema規(guī)范表示如下
<xs : simpleType name =，，reportTypeType，，> <xs : restriction base ="xs:string">
<xs : enumeration value ="RAck，7> <xs : enumeration value ="StaR，7> <xs: enumeration value ="StaR—all，V> </xs:restriction> </xs: simpleType>
<xs : attribute name= "reportType" type= "reportTypeType" use-，，optional" default ="RAck，7>
(3 )如(1 )所述，該表示上報類型的屬性(reportType)綁 定于一個簡單類型，該簡單類型有三個才文舉值("RAck"， "StaR"， "StaR-all")，即(1)中表示上報類型的屬性(reportType)只能取 "RAck"， "StaR"， "StaR-all"三者中之一。
i殳置reportType為RAck， 4又才艮告成功接*)欠文4牛，而不才艮告詳 纟田細(xì)節(jié)。
設(shè)置reportType為StaR，報告文件成功接收(如RAck)及用 于統(tǒng)計分析的接收詳細(xì)信息。
設(shè)置reportType為StaR-all，同StaR，需報告文件成功接收及 用于統(tǒng)計分析的接收詳細(xì)信息，還得報告文件失敗接收。
用XML Schema規(guī)范表示如下
<xs : attribute name = "reportType" use =，，optional，， default =，，RAck，，> <xs : simpleType >
<xs : restriction base ="xs:string，，>
<xs : enumeration value = "RAck，7> <xs : enumeration value = "StaR，7> <xs: enumeration value =，，StaR —all，7> </xs:restriction> </xs: simpleType> </xs: attribute>
(4)如(2)或(3)所述，具有一個用來設(shè)置上報接收情況 的4妄》1欠才幾的取才羊的百分比的屬性，i己為samplePercentage 。 samplePercentage的取值范圍為0到100,可帶小數(shù)，不過小數(shù)點(diǎn)后 最多不超過3位(如67.323就可保i正泮奇度了 )。 samplePercentage用 于StaR和StaR-all,但不用于RAck。當(dāng)sample的值為100時，處 于關(guān)聯(lián)會話的UE將發(fā)送接收報告。對于報告類型為StaR和 StaR-all，且samplePercentage的4直小于100， UE 4尋產(chǎn)生一個0與 100之間均勻分布的隨枳4t,當(dāng)這個隨積4t小于samplePercentage 的值時，UE發(fā)送接收報告。用XML Schema規(guī)范表示如下
<xs:attribute name=，，samplePercentage" type='，xs:decimal，， use="optional "default ="100"/>
(5 )如(2 )或(3 )所述，還具有一個表示UE是否用丈件修 復(fù)點(diǎn)到點(diǎn)連接來發(fā)送接收上報消息的屬性，記為 forceTimelndependence ，該屬性為布爾類型且可選，默認(rèn)值為 "false",當(dāng)該屬性為真時，UE將不使用文件修復(fù)點(diǎn)到點(diǎn)連接來發(fā) 送接收上報消息，否則可以發(fā)起點(diǎn)到點(diǎn)連接來發(fā)送接收上報消息。 用XML Schema ^見范表示力口下
〈xs:attributename=，，forceTimeIndependence" type=，，xs:Boolean，， use=，，optional，， default=，，false，7>
(6 )基于(1 )、 ( 2 )、 ( 4 )、 ( 5 )設(shè)計接收上報關(guān)聯(lián)分發(fā)流程 的XML Schema具有如下特征
(a) 具有一個表示基本流程類型的復(fù)合類型 ("basicProcedureType")，該類型主要包括 一個表示服務(wù)器統(tǒng)一
資源標(biāo)識的元素("serviceURT ), —個表示MBMS客戶端在MBMS 數(shù)據(jù)傳輸結(jié)束后到開始上報流程等待的時間的屬性("offsetTime"), 該屬性是可選的，且為無符號整型；具有一個表示MBMS客戶端 初始4b4妾收上才艮流禾呈的時間窗長度的屬性("randomTimePeroid"), 該屬性是必須的，且為無符號整型。
(b) 具有一個表示接收上報類型的復(fù)合類型 ("reportProcedureType" ), i亥類型繼牙義于"basicProcddureType"類
型，該類型具有一個屬性"samplePercentag"用來設(shè)置上報接收情況 的才妄收沖幾的取樣的百分比。samplePercentage的取^直范圍為O到100， 可帶小數(shù)，不過小數(shù)點(diǎn)后最多不超過3位(如67.323就可保證精度 了 )，該屬性的use屬性為"optional",缺省屬性值為"100";具有 一個布爾類型的屬性"forceTimelndependence",該屬性表示UE是
否用文件修復(fù)點(diǎn)到點(diǎn)連接來發(fā)送接收上報消息，該屬性的use屬性 值為"optional",缺省屬性為"false";具有一個表示上報類型的屬 性"r印ortType"，上報類型的屬性(r印ortType )的類型屬性為
"reportTypeType"，該"reportTypeType"表示上報類型的類型，該 類型有三個才史舉^f直(，，RAck，，， "StaR "， "StaR-all")， reportType屬 性的use屬性值為"optional",上報類型的屬性的缺省屬性為
"RAck"。
(c)該接收上報關(guān)聯(lián)分發(fā)流程描述的XML Schema具有一個 元素 "postReceptionReport" , it元素的 type 屬'性4直為 "reportProcedureType", i亥元素的minOccurs屬寸生l直為"0"。
(7 )基于(1 )、 ( 3 )、 ( 4 )、 ( 5 )設(shè)計接收上報關(guān)聯(lián)分發(fā)流程 的XML Schema具有如下特4正
(a) 具有一個表示基本流程類型的復(fù)合類型 ("basicProcedureType")，該類型主要包括 一個表示服務(wù)器統(tǒng)一
資源標(biāo)識的元素("serviceURT，)， 一個表示MBMS客戶端在MBMS 數(shù)據(jù)傳輸結(jié)束后到開始上報流程等待的時間的屬性("offsetTime"), 該屬性是可選的，且為無符號整型；具有一個表示MBMS客戶端 初始化接收上報流程的時間窗長度的屬性("randomTimePeroid"), 該屬性是必須的，且為無符號整型。
(b) 具有一個表示接收上報類型的復(fù)合類型 ("reportProcedureType"),該類型繼《義于"basicProcddureType"類
型，該類型具有一個屬性"samplePercentag"用來設(shè)置上報接收情況 的4妻jR才幾的取才羊的百分比。samplePercentage的取值范圍為0到100， 可帶小數(shù)，不過小數(shù)點(diǎn)后最多不超過3位(如67.323就可保證精度 了 ),該屬性的use屬性為"optional",缺省屬性值為"100";具有 一個布爾類型的屬性"forceTimelndependence",該屬性表示UE是
否用文件修復(fù)點(diǎn)到點(diǎn)連接來發(fā)送接收上報消息，該屬性的use屬性 值為"叩tional",缺省屬性為"false";具有一個表示上報類型的屬 性"r印ortType"，該表示上才艮類型的屬性(reportType)綁定于一個 簡單類型，該簡單類型有三個枚舉值("RAck"， "StaR"， "StaR-all")， 上報類型的屬性的use屬性值為"optional", reportType屬性的缺省 屬性為"RAck"。
(c)該接收上報關(guān)聯(lián)分發(fā)流程描述的XML Schema具有一個 元素 "postReceptionReport" ， i亥元素的 type 屬'l"生值為 "reportProcedureType"， i亥元素6勺minOccurs屬寸生4直為 "0"。
根據(jù)上述(6 )或(7 )的XML Schema,廣播組播業(yè)務(wù)中心生 成相應(yīng)的接收上報關(guān)聯(lián)分發(fā)流程描述實(shí)例，如果要求不止是上報成 功的詳細(xì)信息，還要求上報失敗的信息，且要求UE—旦進(jìn)入關(guān)聯(lián) 會話就將用點(diǎn)到點(diǎn)鏈接發(fā)送接收上報信息，則相應(yīng)的接收上報分發(fā) 流程描述實(shí)例如下
< xml version-" 1.0" encoding="UTF-8" > <associatedProcedureDescription
xmlns="urn:3gpp:metadata:2005:MBMS:associatedProcedure" xmlns:xsi="http:〃www.w3.org/2001/XMLSchema-instance"> <postReceptionReport offsetTime="5" randomTimePeriod=" 10" reportType=" StaR-all" samplePercentage=" 100" forceTimeIndependence="0"> <serviceURI>"http:〃mbmsreport.example.com/path/report—script"</serviceURI> </postReceptionReport> </associatedProcedureDescription>
廣^"組4番業(yè)務(wù)中心的用戶業(yè)務(wù)聲明才莫塊生成上述接收上才艮關(guān) 聯(lián)分發(fā)流程描述文件，然后在與用戶設(shè)備進(jìn)行會話時通過會話傳輸 模塊或在與用戶設(shè)備進(jìn)行交互時通過交互聲明模塊發(fā)送給用戶設(shè) 備。當(dāng)一個內(nèi)容項完全接收或一個會話完成時，用戶i殳備必須確定 廣播組播業(yè)務(wù)中心是否請求其發(fā)送接收上報。用戶設(shè)備通過分析關(guān) 聯(lián)分發(fā)流程描述接收上報流程的參數(shù)，確定上報類型以及相關(guān)的信 息，并選擇適當(dāng)?shù)臅r間和服務(wù)器發(fā)送接收上報消息。
本發(fā)明針對現(xiàn)有才支術(shù)中由于4妻收上才艮關(guān)聯(lián)分發(fā)流程的XML Schema設(shè)計不合理可能導(dǎo)致4妄收端無法識別4妾收上才艮類型而導(dǎo)致 錯誤的情況，對原有方案進(jìn)行了改進(jìn)。 一方面給表示上報類型的屬 性增加一個缺省屬性，其值為"RAck",這樣在沒有指定上報類型 的屬性值時，就采用其默認(rèn)值"RAck"。另一方面，該表示上"t艮類 型的屬性的類型屬性為"reportTypeType"，該屬性"reportTypeType" 表示上報類型的類型，該屬性有三個枚舉值("RAck"， "StaR"， "StaR-all"),或?qū)⒈硎旧蠄箢愋偷膶傩越壎ㄓ谝粋€簡單類型，該簡 單類型有三個才文舉值("RAck"， "StaR"， "StaR-all")，這樣表示上 報類型的屬性只能取"RAck"， "StaR，，， "StaR-all"三者中之一，從 而不會導(dǎo)致接收端無法識別上報類型的錯誤。
以上^f叉為本發(fā)明的優(yōu)選實(shí)施例而已，并不用于限制本發(fā)明，對 于本領(lǐng)域的技術(shù)人員來說，本發(fā)明可以有各種更改和變化。凡在本 發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進(jìn)等，均 應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。
權(quán)利要求
1.一種廣播組播業(yè)務(wù)中的接收上報方法，其特征在于，包括以下步驟步驟S302，廣播組播業(yè)務(wù)中心生成接收上報關(guān)聯(lián)分發(fā)流程描述文件并將所述描述文件發(fā)送至一個或多個用戶設(shè)備，其中，所述描述文件包括要求所述用戶設(shè)備發(fā)送的接收上報消息的類型信息；步驟S304，所述一個或多個用戶設(shè)備接收到所述接收上報關(guān)聯(lián)分發(fā)流程描述文件后對其進(jìn)行解析并確定要求的接收上報消息的上報類型；以及步驟S306，所述用戶設(shè)備生成要求類型的接收上報消息并將其發(fā)送至接收上報服務(wù)器。
2. 根據(jù)權(quán)利要求1所述的接收上報方法，其特征在于，所述接收 上報消息的類型信息通過接收上報消息類型(ReportType)的 類型來限定。
3. 根據(jù)權(quán)利要求2所述的接收上報方法，其特征在于，所述接收 上報消息類型的類型是以下三個枚舉值之一接收確認(rèn)RAck、 成功4妄收的統(tǒng)計才艮告StaR、以及所有內(nèi)容接收的統(tǒng)計才艮告 StaR-all。
4. 根據(jù)權(quán)利要求3所述的接收上報方法，其特征在于，所述接收 上才艮消息類型的缺省類型為接收確i人RAck。
5. 4艮據(jù)4又利要求1所述的4妾收上4艮方法，其特4正在于，所述接收 上報消息的類型信息通過將上報消息類型綁定于一個簡單類 型來限定。
6. 根據(jù)權(quán)利要求5所述的接收上報方法，其特征在于，所述簡單 類型包括以下三個才文舉值接收確i人RAck、成功接收的統(tǒng)計 報告StaR、以及所有內(nèi)容接收的統(tǒng)計報告StaR-all。
7. 根據(jù)權(quán)利要求6所述的接收上報方法，其特征在于，所述接收 上報消息類型的缺省類型為接收確認(rèn)RAck。
8. 根據(jù)權(quán)利要求4或7所述的接收上報方法，其特征在于，在所 述接收上報消息的類型信息為接收確認(rèn)類型RAck的情況下， 所述用戶設(shè)備上報成功接收文件的信息，不上報成功接收的詳 細(xì)信息。
9. 根據(jù)權(quán)利要求4或7所述的接收上報方法，其特征在于，在所 述要求的接收上報消息的類型信息為成功接收的統(tǒng)計報告 StaR的情況下，所述用戶設(shè)備上報成功接收統(tǒng)計報告的信息、 成功接收文件的信息以及用于進(jìn)行統(tǒng)計分析的詳細(xì)信息。
10. 根據(jù)權(quán)利要求4或7所述的接收上報方法，其特征在于，在所 述要求的接收上報消息的類型信息為所有內(nèi)容接收的統(tǒng)計報 告StaR-all的情況下，所述用戶設(shè)備上報成功接收文件的信息、 成功接收統(tǒng)計^^艮告的信息、用于進(jìn)行統(tǒng)計分析的信息、以及接 收文件失敗的信息。
11. 一種接收上"t艮處理裝置，其特征在于包括用戶業(yè)務(wù)聲明模塊，用于生成接收上報關(guān)聯(lián)分發(fā)流程描 述文件并將所述描述文件發(fā)送至交互分發(fā)纟莫塊或會話與傳輸 才莫塊，其中，所述描述文件包4舌要求所述用戶i更備發(fā)送的接收上^R消息的類型信息；所迷交互分發(fā)模塊，用子在與一個或多個用戶設(shè)備進(jìn)衧 交互的情況下，將所述接收上報關(guān)聯(lián)分發(fā)流程描述文件發(fā)送至 所述一個或多個用戶設(shè)備；以及所述會話與傳輸模塊，用于在與一個或多個用戶設(shè)備進(jìn) 行會話的情況下，將所述接收上報關(guān)聯(lián)分發(fā)流程描述文件發(fā)送 至所述一個或多個用戶"i殳備。
12. 根據(jù)權(quán)利要求11所述的接收上報處理裝置，其特征在于，所 述接收上報消息的類型信息通過接收上報消息類型(ReportType)的類型來限定。
13. 根據(jù)權(quán)利要求12所述的接收上報處理裝置，其特征在于，所 述接收上報消息類型的類型是以下三個枚舉值之一接收確認(rèn) RAck、成功接收的統(tǒng)計才艮告StaR、以及所有內(nèi)容4妻收的統(tǒng)計 報告StaR-all。
14. 根據(jù)權(quán)利要求13所述的接收上報處理裝置，其特征在于，所 述接收上報消息類型的缺省類型為接收確認(rèn)RAck。
15. 根據(jù)權(quán)利要求11所述的接收上報處理裝置，其特征在于，所 述接收上報消息的類型信息通過將所述上報消息類型綁定于 一個簡單類型來限定。
16. 根據(jù)權(quán)利要求15所述的接收上報處理裝置，其特征在于，所 述簡單類型包括以下三個枚舉值接收確認(rèn)RAck、成功接收 的統(tǒng)計報告StaR、以及所有內(nèi)容接收的統(tǒng)計報告StaR-all。
17. 才艮據(jù)斥又利要求16所述的接收上才艮處理裝置，其特4正在于，所 述接收上才艮消息類型的缺省類型為接收確認(rèn)RAck。
18. 根據(jù)權(quán)利要求14或17所述的接收上報處理裝置，其特征在于， 在所述接收上報消息的類型信息為接收確認(rèn)類型RAck的情 況下，指示所述用戶設(shè)備上報成功接收文件的信息，不上報成 功接*)欠的詳細(xì)4言息。
19. 根據(jù)權(quán)利要求14或17所述的接收上報處理裝置，其特征在于， 在所述要求的接收上報消息的類型信息為成功接收的統(tǒng)計報 告StaR的情況下，指示所述用戶設(shè)備上報成功接收統(tǒng)計報告 的信息、成功接收文件的信息以及用于進(jìn)行統(tǒng)計分析的詳細(xì)信 息。120. 根據(jù)權(quán)利要求14或17所述的接收上報處理裝置，其特征在于， 在所述要求的接收上報消息的類型信息為所有內(nèi)容接收的統(tǒng) 計報告StaR-all的情況下，指示所述用戶設(shè)備上報成功接收文 件的信息、成功接收統(tǒng)計^^艮告的信息、用于進(jìn)行統(tǒng)計分析的信 息、以及接收文件失敗的信息。
全文摘要
本發(fā)明提供了一種廣播組播業(yè)務(wù)中的接收上報方法以及一種接收上報處理裝置，其中，該方法包括步驟S302，廣播組播業(yè)務(wù)中心生成接收上報關(guān)聯(lián)分發(fā)流程描述文件并將所述描述文件發(fā)送至一個或多個用戶設(shè)備，其中，所述描述文件包括要求所述用戶設(shè)備發(fā)送的接收上報消息的類型信息；步驟S304，所述一個或多個用戶設(shè)備接收到所述接收上報關(guān)聯(lián)分發(fā)流程描述文件后對其進(jìn)行解析并確定要求的接收上報消息的上報類型；以及步驟S306，所述用戶設(shè)備生成要求類型的接收上報消息并將其發(fā)送至接收上報服務(wù)器。本發(fā)明通過指示用戶設(shè)備上報特定類型的接收上報消息，使得不會發(fā)生接收上報類型的錯誤，提高了廣播組播業(yè)務(wù)的效率。
文檔編號H04L12/56GK101110722SQ20061009944
公開日2008年1月23日 申請日期2006年7月20日 優(yōu)先權(quán)日2006年7月20日
發(fā)明者余榮道, 濤 吳 申請人:華為技術(shù)有限公司