專利名稱：一種組播/廣播業(yè)務(wù)實(shí)現(xiàn)方法和系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及組播/廣播業(yè)務(wù)，特別涉及一種組播/廣播業(yè)務(wù)實(shí)現(xiàn)方法和系統(tǒng)。
技術(shù)背景SIP ( Session Initiation Protocol,會話發(fā)起協(xié)議)是由IETF (Interne工程 任務(wù)組)制訂的多々某體通信系統(tǒng)框架協(xié)議之一，是用于建立、改變或結(jié)束多媒 體會話的應(yīng)用層協(xié)議，與RTP (Real-time Transport Protocol ，實(shí)時(shí)傳輸協(xié)議；) /RTCP (Real-time Transport Control Protocol,實(shí)時(shí)傳輸控制協(xié)議)、SDP( Session Description Protocol,會i舌4笛述協(xié)i義)、RTSP ( Real 一 Time Streaming Protocol, 實(shí)時(shí)傳送流4某體協(xié)議)、DNS (DomainName Server域名服務(wù)器)等協(xié)議配合， 共同完成IMS (IP Multimedia Subsystem, IP (Internet Protocol,國際互聯(lián)網(wǎng) 協(xié)議)多媒體子系統(tǒng))中的會話建立及媒體協(xié)商； 一旦建立會話，媒體流將使 用RTP協(xié)議在承栽層中直接傳送，在一次會話中可以靈活的交互多種媒體。由于SIP基于公開的Internet標(biāo)準(zhǔn)，在語音、數(shù)據(jù)業(yè)務(wù)結(jié)合和互通方面具 有天然優(yōu)勢，能跨越媒體和設(shè)備實(shí)現(xiàn)呼叫控制，支持豐富的媒體格式，可動態(tài) 增/刪媒體流，容易實(shí)現(xiàn)更加豐富的業(yè)務(wù)特性，同時(shí)，SIP支持智能向業(yè)務(wù)和終 端側(cè)發(fā)展從而減輕網(wǎng)絡(luò)負(fù)擔(dān)，其本身支持包括動態(tài)注冊機(jī)制、位置管理機(jī)制、 重定向機(jī)制等應(yīng)用層移動性功能以及呈現(xiàn)Presence/Fork/訂閱特性，便于擴(kuò)展新 業(yè)務(wù)，而且協(xié)議簡單，具有公認(rèn)的擴(kuò)展?jié)摿Γ虼溯兜昧税ㄔ贗MS及NGN (Next Generation Network,下一代網(wǎng)絡(luò))中的越來越多的應(yīng)用。在通訊和IT技術(shù)高度發(fā)展的今天，隨著跨鏈路層傳輸介質(zhì)的IP技術(shù)的出 現(xiàn)，互聯(lián)網(wǎng)(Internet)應(yīng)用的迅速普及，與此同時(shí)，人們也不再滿足于單一的 語音通信方式，而需要全新的多媒體通信方式，移動通訊網(wǎng)絡(luò)和固定通訊網(wǎng)絡(luò) 的IP化、Internet和電信網(wǎng)絡(luò)的融合已無可爭議地成為業(yè)界公認(rèn)的發(fā)展方向。 為滿足越來越突出的IP多媒體應(yīng)用的普遍需求，3GPP (3rd Generation Partnership Project,第三代移動通信標(biāo)準(zhǔn)化伙伴項(xiàng)目)在分組承載網(wǎng)基礎(chǔ)上引 入的全I(xiàn)P業(yè)務(wù)網(wǎng)絡(luò)架構(gòu)的IP多媒體子系統(tǒng)IMS，目標(biāo)是按照個性化用戶數(shù)據(jù)， 屏蔽用戶接入方式，控制業(yè)務(wù)能力的開放程度，提供多媒體的通信體驗(yàn)。IMS是3GPP R5階段增加的WCDMA網(wǎng)絡(luò)中疊加在已有分組域之上的一 個子系統(tǒng)，采用分組域?yàn)槠渖蠈涌刂菩帕詈汀┠丑w傳輸?shù)某休d通道，引入SIP協(xié) 議作為業(yè)務(wù)控制協(xié)議，利用SIP簡單、易擴(kuò)展、士某體組合方便的特點(diǎn)，通過將 業(yè)務(wù)控制與承載控制分離，提供豐富的多々某體業(yè)務(wù)；IMS中主要的功能實(shí)體包 括控制用戶注冊、會話控制等功能的呼叫控制實(shí)體CSCF (Call Session Control Function,呼叫會話控制功能)、提供各種業(yè)務(wù)邏輯控制功能的應(yīng)用服務(wù)器AS、 集中管理用戶簽約數(shù)據(jù)的HSS (Home Subscriber Server,歸屬用戶服務(wù)器)以 及用于實(shí)現(xiàn)與電路交換網(wǎng)互通的MGCF (Media Gateway Control Function,媒 體網(wǎng)關(guān)控制功能)/ IM-MGW (Instant messaging Media Gateway ，即時(shí)消息媒 體網(wǎng)關(guān))，用戶通過當(dāng)前所在地代理節(jié)點(diǎn)P-CSCF (Proxy-CSCF，代理CSCF) 接入IMS,會話和業(yè)務(wù)觸發(fā)控制及與AS (Application Server,應(yīng)用服務(wù)器)的 業(yè)務(wù)控制交互則由其注冊地的歸屬域服務(wù)節(jié)點(diǎn)S-CSCF (Subscriber-CSCF，歸 屬CSCF)完成。NGN(下一代網(wǎng)絡(luò))是基于分組技術(shù)的融合型網(wǎng)絡(luò)，以分組交換為主，采 用承載與控制分離的架構(gòu)，它繼承了原有PSTN (Public Switch Telephone Network,公共交換電話網(wǎng))固定網(wǎng)絡(luò)的所有業(yè)務(wù)，也同時(shí)夠繼承了移動網(wǎng)絡(luò) 的業(yè)務(wù)能力。NGN綜合了固定電話網(wǎng)、移動電話網(wǎng)和IP網(wǎng)絡(luò)的優(yōu)勢，使得模 擬用戶、數(shù)字用戶、移動用戶、ADSL (Asymmetrical Digital Subscriber Loop非 對稱數(shù)字用戶環(huán)線)用戶、ISDN (Integrated Services Digital Network,綜合業(yè) 務(wù)數(shù)字網(wǎng))用戶、IP窄帶網(wǎng)絡(luò)用戶、IP寬帶網(wǎng)絡(luò)用戶甚至是通過衛(wèi)星接入的用 戶都能作為下一代網(wǎng)絡(luò)中的一員相互通信。
NGN整體架構(gòu)中包4舌NASS (Network Attachment Sub-system,網(wǎng)絡(luò)附著 子系統(tǒng))和RACS (Resource and Admission Control Subsystem,資源及許可控 制子系統(tǒng))，NASS是網(wǎng)絡(luò)附著子系統(tǒng)，其主要用于對用戶設(shè)備進(jìn)行動態(tài)配置， 進(jìn)行用戶接入驗(yàn)證，進(jìn)行接入資源授權(quán)，進(jìn)行接入網(wǎng)配配置和用戶位置管理等。如圖1所示，RACS的功能架構(gòu)包括CPE( Customer Premises Equipment (i.e. (routed) modem, residential gateway, integrated access device,用戶前端設(shè)備)，CPE是用戶前端設(shè)備，提供將用戶終 端(如PC)接入網(wǎng)絡(luò)的能力；A-RACF (Access-Resource and Admission Control Function,接入-資源及許 可控制功能)，A-RACF接受SPDF的請求，對用戶的請求進(jìn)行接納控制，另夕卜， A-RACF也需要對來自于SPDF的策略輸入進(jìn)行整合以保證所有資源請求不會 超出接入線能力范圍；RCEF( Resource Control Enforcement Function,資源控制執(zhí)行功能)，RCEF 在A-RACF的控制下執(zhí)行策略強(qiáng)制功能，如執(zhí)行接入提供商的定制策略，對授 權(quán)流量進(jìn)行門控等；SPDF (Service-based Policy Decision Function,基于業(yè)務(wù)的策略決策功能)， SPDF接受AF的資源請求，根據(jù)網(wǎng)路運(yùn)營商策略對該請求進(jìn)行處理，并按需 向A-RACF和/或BGF發(fā)送進(jìn)一步的資源請求，資源請求的結(jié)果返回給AF;BGF (Border Gateway Function,邊界網(wǎng)關(guān)功能)，BGF是一個分組到分組 的網(wǎng)關(guān)，它在SPDF的控制下執(zhí)行策略并進(jìn)行必要的網(wǎng)絡(luò)地址轉(zhuǎn)換功能；L2T Point是二層協(xié)議的終結(jié)點(diǎn)；Access Node—般指二層/三層接入局端設(shè)備，提供多用戶線路接入，并對 用戶流量進(jìn)行匯聚的功能，如xDSL接入技術(shù)中的DSLAM。流媒體業(yè)務(wù)或IPTV業(yè)務(wù)是近幾年迅速發(fā)展的一種新業(yè)務(wù)，流媒體業(yè)務(wù)利 用流式傳輸技術(shù)，在包交換網(wǎng)絡(luò)上傳輸多媒體文件，包括4見頻、音頻等文件內(nèi) 容。這些內(nèi)容在訪問時(shí)無需完全下載就可以立即播放。流々某體實(shí)現(xiàn)的關(guān)鍵技術(shù) 就是流式傳輸4支術(shù)，而流式傳輸4支術(shù)是把連續(xù)的浮見頻和音頻〗言息經(jīng)過處理后^C 上網(wǎng)站服務(wù)器，讓用戶一邊下栽一邊觀看、收聽，而不需要等整個文件下載到 自己機(jī)器后才可以觀看的網(wǎng)絡(luò)傳輸技術(shù)。以D類IP地址發(fā)送業(yè)務(wù)的技術(shù)，用于發(fā)送者同時(shí)向多個接收者(大于等 于一個)發(fā)送相同業(yè)務(wù)內(nèi)容時(shí)，因?yàn)橄嗤瑑?nèi)容只需要向指定組播地址發(fā)送一份 即可，因而可以有效降低業(yè)務(wù)發(fā)送方和傳輸網(wǎng)絡(luò)的負(fù)載。為了獲取組播內(nèi)容，內(nèi)容接收方(用戶)通iti口入業(yè)務(wù)組播組(如使用IGMP (Internet Group Management Protocol因特網(wǎng)組管理協(xié)議)協(xié)議)來要求鄰接的 路由器發(fā)送業(yè)務(wù)內(nèi)容給自己，而路由器之間則通過組播路由協(xié)議(如PIM-SM (Protocol Independent Multicast-Sparse Mode協(xié)i義無關(guān)紐j番-稀疏;漢式(協(xié)i義)) (協(xié)議無關(guān)組播-稀疏模式)協(xié)議等)與其它路由器交互以建立組播轉(zhuǎn)發(fā)路徑，這使用組播技術(shù)傳送業(yè)務(wù)流，無論接收方有多少，業(yè)務(wù)發(fā)送方只需要發(fā)送一 個數(shù)據(jù)流。組播數(shù)據(jù)在從業(yè)務(wù)發(fā)送點(diǎn)到接收方的傳送路徑上的傳送點(diǎn)之間只產(chǎn) 生單一的數(shù)據(jù)流，顯而易見使用組播技術(shù)可以減輕發(fā)送者(業(yè)務(wù)提供方)的負(fù) 荷，并且可以有效利用網(wǎng)絡(luò)資源。應(yīng)用層組播通過在節(jié)點(diǎn)之間運(yùn)行承載在單播技術(shù)上的協(xié)議進(jìn)行一點(diǎn)到多 點(diǎn)/多點(diǎn)到多點(diǎn)的數(shù)據(jù)發(fā)送，由于不依賴于IP組播技術(shù)，因此可以間接避開/解 決IP組播的所謂信源可信，可靠組成員管理，組播數(shù)據(jù)安全等問題。應(yīng)用層組播的應(yīng)用意味著終端和服務(wù)器可以作為節(jié)點(diǎn)建立關(guān)聯(lián)關(guān)系，從而 不需要對網(wǎng)絡(luò)中間實(shí)體提出附加的需求；但此類方案卻對終端提出了附加的需 求，即需要特定的應(yīng)用層組播協(xié)議以維護(hù)節(jié)點(diǎn)關(guān)系，這對于通信網(wǎng)絡(luò)來講未必 是最佳選擇?，F(xiàn)有技術(shù)一在現(xiàn)有基于IP網(wǎng)絡(luò)的業(yè)務(wù)系統(tǒng)中，若需要向多個用戶傳遞相同內(nèi)容，則 一般會考慮使用IP組^N支術(shù)向用戶傳遞內(nèi)容。如圖2所示，為使用IP組播技 頁術(shù)開展業(yè)務(wù)的一個示意，其過程為1 、 UE ( User Equipment,用戶設(shè)備)通過業(yè)務(wù)接口 ，如HTTP (Hyper Text Transport Protocol ，超級文本傳送協(xié)議)等，獲得業(yè)務(wù)組播地址；UE使用IGMP 通知路由器加入該組播組；2、 傳輸/核心網(wǎng)路由器之間通過三層組播路由協(xié)議(如PIM-SM等)建立 組播轉(zhuǎn)發(fā)表；3、 業(yè)務(wù)流以組播報(bào)文方式從組播源發(fā)送給UE。以上方案是一個標(biāo)準(zhǔn)的組播應(yīng)用流程，要求接入網(wǎng)和傳輸/核心網(wǎng)均支持組 播功能，在UE和路由器之間使用IGMP協(xié)議，在路由器之間則使用組播路由 協(xié)議，如PIM-SM等。上述方案中由于媒體服務(wù)器對用戶是否正在接收內(nèi)容沒有機(jī)制感知，其在 商業(yè)運(yùn)營中遇到一定的困難即無法對用戶進(jìn)行驗(yàn)證和進(jìn)行準(zhǔn)確的計(jì)費(fèi)。另夕卜， IP組播也存在其固有缺陷，包括無法進(jìn)行組成員管理驗(yàn)證，無法保障媒體源 可信，無法限制媒體流分發(fā)范圍等問題。目前有一種機(jī)制是通過在接入設(shè)備上 配置對應(yīng)于用戶線路的組播權(quán)限表對用戶的IGMP/MLD (Internet Group Management Protocol,因特網(wǎng)組管理協(xié)i義/Multicast Listener Discovery,組才番偵 聽者發(fā)現(xiàn)(協(xié)議))請求進(jìn)行過濾來間接解決類似問題。另外，對于現(xiàn)有技術(shù)一， 如果核心傳輸網(wǎng)不支持IP組播技術(shù)，則無法在核心網(wǎng)絡(luò)側(cè)以IP組播技術(shù)發(fā)送 々某體流，其應(yīng)用受到一定的限制?，F(xiàn)有技術(shù)二針對現(xiàn)有技術(shù)一的缺點(diǎn)，同時(shí)也是針對IP組播技術(shù)的固有缺點(diǎn)，目前出 現(xiàn)了應(yīng)用層組播技術(shù)。到多點(diǎn)/多點(diǎn)到多點(diǎn)的數(shù)據(jù)發(fā)送，由于不依賴于IP組播技術(shù)，因此可以間接避 開/解決IP組播的所謂信源可信，可靠組成員管理，組播數(shù)據(jù)安全等問題。 應(yīng)用層組播目前的一類應(yīng)用是以終端和服務(wù)器作為功能節(jié)點(diǎn)在其間建立 動態(tài)的關(guān)聯(lián)或者鏈路關(guān)系，在發(fā)送數(shù)據(jù)時(shí)以服務(wù)器和多個節(jié)點(diǎn)所建立的傳輸關(guān) 系以單播方式發(fā)送媒體流數(shù)據(jù)，但數(shù)據(jù)在該邏輯網(wǎng)絡(luò)中的分發(fā)可能是分層復(fù)制 的，因而也可以取得和IP組播類似的傳輸資源優(yōu)化效果。此類方案可以不需要對網(wǎng)絡(luò)中間實(shí)體提出附加的需求；但一般卻對終端提 出了附加的需求，即需要特定的應(yīng)用層組播協(xié)議以維護(hù)節(jié)點(diǎn)關(guān)系，這對于通信 網(wǎng)絡(luò)來講未必是最佳選擇。發(fā)明內(nèi)容本發(fā)明提供一種組播/廣播業(yè)務(wù)的實(shí)現(xiàn)方法和系統(tǒng)，用以解決現(xiàn)有核心網(wǎng)側(cè) 不支持IP組播方法時(shí)，如何以單播方式實(shí)現(xiàn)組播/廣播業(yè)務(wù)的問題。 為解決上述技術(shù)問題，本發(fā)明提供如下技術(shù)方案 一種組播/廣播業(yè)務(wù)實(shí)現(xiàn)方法，包括如下步驟接入網(wǎng)側(cè)傳輸處理模塊和核心網(wǎng)側(cè)媒體提供設(shè)備之間為組播/廣播業(yè)務(wù)建 立傳輸通道；所述媒體提供設(shè)備通過所述傳輸通道將組播/廣播媒體流單播給所述傳輸 處理4莫塊；所述傳輸處理模塊根據(jù)所述組播/廣播媒體流的組播/廣播々某體流參數(shù)進(jìn)行 組播/廣4番。所述方法中，至少兩個組播/廣播業(yè)務(wù)復(fù)用同一條傳輸通道；或者 為每一個組播/廣播業(yè)務(wù)分別建立一條傳輸通道。較佳的，所述方法中，所述傳輸處理模塊和媒體提供設(shè)備根據(jù)預(yù)先存儲在 本地的相關(guān)參數(shù)建立所述傳輸通道。 上述方法進(jìn)一步包括如下步驟終端通過中間處理模塊向應(yīng)用處理模塊請求建立所述組播/廣播業(yè)務(wù)； 所述應(yīng)用處理模塊向終端返回所述組播/廣播業(yè)務(wù)的組播地址； 所述終端根據(jù)所述組播地址加入接收所述組播/廣播媒體流的組播組。 較佳的，所述方法中通過如下步驟建立傳輸通道終端通過中間處理模塊向應(yīng)用處理模塊請求建立所述組播/廣播業(yè)務(wù)；所述應(yīng)用處理模塊向媒體提供設(shè)備請求媒體資源，并接收所迷媒體提供設(shè)備返回的建立所述傳輸通道的相關(guān)參數(shù)和組播/廣播媒體流參數(shù)；所述應(yīng)用處理;f莫塊向中間處理^t塊發(fā)送攜帶所述傳輸通道相關(guān)參數(shù)和組 播/廣播媒體流參數(shù)的業(yè)務(wù)響應(yīng)；所述中間處理模塊向傳輸處理模塊發(fā)送攜帶所述傳輸通道相關(guān)參數(shù)和組 播/廣播媒體流參數(shù)的資源請求；所述傳輸處理模塊判斷所述組"l番/廣播業(yè)務(wù)的傳輸通道是否已經(jīng)建立，如果 是則根據(jù)所述組播/廣播媒體流參數(shù)組播/廣播從該傳輸通道上接收的組播/廣 播媒體流；否則根據(jù)所述相關(guān)參數(shù)與媒體提供設(shè)備之間建立所述傳輸通道，并 根據(jù)所述組播/廣播媒體流參數(shù)組播/廣播從該傳輸通道上接收的組播/廣播媒 體流。上述方法進(jìn)一步包括如下步驟所述傳輸處理模塊建立所述傳輸通道后或確認(rèn)所述傳輸通道已經(jīng)建立后， 向所述中間處理才莫塊返回資源請求響應(yīng)；所述中間處理模塊向所述終端返回?cái)y帶所述組播/廣播媒體流參數(shù)的業(yè)務(wù) 成功響應(yīng)；所述終端收到所述業(yè)務(wù)成功響應(yīng)后，根據(jù)所述組播/廣播媒體流參數(shù)加入接 收所述組^^/廣纟番i某體流的組播組。上述方法進(jìn)一步還包括:所述應(yīng)用處理模塊為每一個組播/廣播業(yè)務(wù)分配一 個唯一的業(yè)務(wù)流標(biāo)識，并且所述應(yīng)用處理模塊在發(fā)送給所述中間處理模塊的業(yè)務(wù)響應(yīng)中攜帶對應(yīng)的 業(yè)務(wù)流標(biāo)識；所述中間處理模塊在發(fā)送給所述傳輸處理模塊的資源請求中攜帶所述業(yè) 務(wù)流標(biāo)識，所述傳輸處理模塊記錄所述業(yè)務(wù)流標(biāo)識并根據(jù)記錄信息判斷是否已
經(jīng)為相應(yīng)的組播/廣插4某體流建立了傳輸通道。如果分配了業(yè)務(wù)流標(biāo)識，所述方法進(jìn)一步還包括所述中間處理模塊在發(fā)送給所述終端的業(yè)務(wù)響應(yīng)中攜帶所述業(yè)務(wù)流標(biāo)識， 所述終端利用所述業(yè)務(wù)流標(biāo)識在后續(xù)流程的相關(guān)消息中標(biāo)識或匹配所述組播/ 廣播業(yè)務(wù)。上述所有方法中，所述終端和中間處理模塊之間通過SIP協(xié)議、HTTP協(xié) 議或RTSP協(xié)議實(shí)現(xiàn)信息交互；所述中間處理模塊和應(yīng)用處理模塊之間通過SIP 協(xié)議、HTTP協(xié)議或RTSP協(xié)議實(shí)現(xiàn)信息交互；所述中間處理模塊和傳輸處理 模塊之間通過COPS協(xié)議、R248協(xié)議或Diameter協(xié)議實(shí)現(xiàn)信息交互。并且通 過擴(kuò)展會話描述協(xié)議SDP攜帶建立所述傳輸通道的相關(guān)參數(shù)、組播/廣播媒體 流參數(shù)或業(yè)務(wù)流標(biāo)識。上述方法中，所述傳輸通道的類型包括封裝模式。其中，所述封裝模式的 傳輸通道包括隧道，建立所述隧道的相關(guān)參數(shù)至少包括隧道類型、媒體傳輸 設(shè)備端的隧道地址和隧道端口 。所述隧道可以是GRE隧道?；蛘?，所述傳輸通道的類型包括映射;f莫式，建立所述映射模式傳輸通道的 相關(guān)參數(shù)至少包括映射模式類型、媒體傳輸設(shè)備端的單播地址和端口。上述方法中，所述組播/廣播媒體流參數(shù)至少包括IP組播/廣播地址和端口 。進(jìn)一步，所述傳輸處理模塊建立用戶配置表，以用戶標(biāo)識為索引保存每一 個用戶對應(yīng)的組播/廣播媒體流參數(shù)，并根據(jù)該用戶配置表驗(yàn)證請求所述組播/ 廣播媒體流的用戶終端的合法性。本發(fā)明還提供一種組^^/廣播業(yè)務(wù)實(shí)現(xiàn)系統(tǒng)，包括終端和位于核心網(wǎng)側(cè)的媒 體提供設(shè)備，還包括位于接入網(wǎng)側(cè)的傳輸處理模塊，其中，所述傳輸處理模 塊分別通過IP網(wǎng)絡(luò)連接終端和媒體提供設(shè)備；所述傳輸處理模塊和媒體提供設(shè)備之間為組播/廣播業(yè)務(wù)建立傳輸通道；所述媒體提供設(shè)備通過所述傳輸通道將組播/廣播媒體流單播給所述傳輸 處理模塊；
所述傳輸處理才莫塊才艮據(jù)所述組播/廣插4某體流對應(yīng)的組播/廣播媒體流參數(shù) 向終端進(jìn)行組播/廣播。進(jìn)一步，所述系統(tǒng)還包括應(yīng)用處理模塊和中間處理模塊，其中所迷應(yīng)用 處理模塊通過接口連接中間處理模塊，所述中間處理模塊分別通過接口連接所 述終端、傳輸處理4莫塊和媒體提供設(shè)備；終端通過中間處理才莫塊向應(yīng)用處理模塊請求建立所述組播/廣播業(yè)務(wù)；所述應(yīng)用處理才莫塊向媒體提供設(shè)備請求々某體資源，并接收所述媒體提供設(shè) 備返回的建立所述傳輸通道的相關(guān)參數(shù)和組播/廣播媒體流參數(shù)；所述應(yīng)用處理才莫塊向中間處理模塊發(fā)送攜帶所述傳輸通道相關(guān)參數(shù)和組 播/廣播媒體流參數(shù)的業(yè)務(wù)響應(yīng)；所述中間處理;f莫塊向傳輸處理模塊發(fā)送攜帶所述傳輸通道相關(guān)參數(shù)和組 播/廣播媒體流參數(shù)的資源請求；所述傳輸處理模塊判斷所述組播/廣播業(yè)務(wù)的傳輸通道是否已經(jīng)建立，如杲 是則根據(jù)所述組播/廣播媒體流參數(shù)組播/廣播從該傳輸通道上接收的組播/廣 播媒體流，否則根據(jù)所述相關(guān)參數(shù)與媒體提供設(shè)備之間建立所述傳輸通道。較佳的，所述中間處理模塊包括下一代網(wǎng)絡(luò)NGN中的應(yīng)用功能實(shí)體AF; 所述傳輸處理模塊具體包括NGN中的如下子功能實(shí)體基于業(yè)務(wù)的策略決策 功能實(shí)體SPDF、接入-資源及許可控制功能實(shí)體A-RACF、資源控制執(zhí)行功能 實(shí)體RCEF和邊界網(wǎng)關(guān)功能實(shí)體BGF,其中所述SPDF通過接口連接所述中 間處理實(shí)體，所述A-RACF連接在SPDF和RCEF之間，所述BGF分別連接 SPDF和RCEF，所述RCEF通過IP網(wǎng)絡(luò)連接終端，所述BGF通過IP網(wǎng)絡(luò)連 接媒體提供設(shè)備。較佳的，所述應(yīng)用處理模塊包括IP多媒體子系統(tǒng)IMS中的應(yīng)用服務(wù)器AS; 所述中間處理模塊包括IMS中的相關(guān)功能實(shí)體。所述邊界網(wǎng)關(guān)功能實(shí)體BGF 可以為如下之一支持MBMS的GPRS網(wǎng)絡(luò)中的GGSN; 3GPP2所定義的 BCMCS網(wǎng)絡(luò)中的BSN; DVB-H網(wǎng)絡(luò)中的IPE。較佳的，所述傳輸處理模塊中包括存儲子才莫塊，用于存儲用戶配置表，該 用戶配置表中以用戶標(biāo)識為索引保存每一個用戶對應(yīng)的組播/廣播媒體流參數(shù)， 所述傳輸處理模塊根據(jù)該用戶配置表驗(yàn)證請求所迷組播/廣播媒體流的用戶終 端的合法性。本發(fā)明有益效果如下本發(fā)明技術(shù)方案利用建立業(yè)務(wù)的信令過程，在接入網(wǎng)邊界實(shí)體和核心網(wǎng)絡(luò) 中媒體提供設(shè)備之間建立應(yīng)用層傳輸通道，媒體提供設(shè)備通過傳輸通道將組播 /廣播業(yè)務(wù)流單播到接入網(wǎng)邊界實(shí)體，然后接入網(wǎng)邊界實(shí)體再利用IP組播技術(shù) 將業(yè)務(wù)流組播/廣播與其連接的終端，解決了核心網(wǎng)不支持組播情況下進(jìn)行組播 /廣播業(yè)務(wù)流單播傳送的問題，節(jié)省了核心網(wǎng)和接入網(wǎng)之間的傳輸資源；本發(fā)明技術(shù)方案還可以保證媒體提供設(shè)備接收的組播/廣播媒體流的可信 性和組播/廣播數(shù)據(jù)的安全性，并利用用戶配置表實(shí)現(xiàn)對接收組播/廣播業(yè)務(wù)終 端的合法性進(jìn)行驗(yàn)證；另外，為建設(shè)可管理，可運(yùn)營的電信級組播網(wǎng)絡(luò)給出了 有力的技術(shù)支持。


圖1為RACS功能架構(gòu)示意圖；圖2為現(xiàn)有IP組播:R術(shù)實(shí)現(xiàn)組播業(yè)務(wù)的原理示意圖； 圖3為本發(fā)明所述組播/廣播業(yè)務(wù)實(shí)現(xiàn)系統(tǒng)主要結(jié)構(gòu)示意圖； 圖4為本發(fā)明所述組播/廣播業(yè)務(wù)實(shí)現(xiàn)方法的主要流程示意圖； 圖5為本發(fā)明實(shí)施例一所述組播業(yè)務(wù)實(shí)現(xiàn)系統(tǒng)主要結(jié)構(gòu)示意圖； 圖6為本發(fā)明實(shí)施例一所述組播業(yè)務(wù)實(shí)現(xiàn)方法的主要流程示意圖； 圖7為本發(fā)明實(shí)施例二所述組播業(yè)務(wù)實(shí)現(xiàn)系統(tǒng)主要結(jié)構(gòu)示意圖。
具體實(shí)施方式
本發(fā)明為解決現(xiàn)有技術(shù)存在的問題，提出以下技術(shù)構(gòu)思 在進(jìn)行組播/廣播業(yè)務(wù)時(shí)，由位于接入網(wǎng)邊界的傳輸處理模塊和位于核心網(wǎng) 側(cè)的組播/廣播業(yè)務(wù)的媒體提供設(shè)備之間建立單播傳輸通道，媒體提供設(shè)備通過所述傳輸通道將被請求的組播/廣播媒體流羊播給傳輸處理模塊;傳輸處理模塊 再采用IP組播技術(shù)，將所述組播/廣播媒體流組播/廣播給終端。如圖3所示，圖3為本發(fā)明所述實(shí)現(xiàn)組播/廣播業(yè)務(wù)的系統(tǒng)主要結(jié)構(gòu)示意圖， 其中包括如下實(shí)體功能中間處理模塊，為接入通信核心網(wǎng)的用戶提供呼叫控制、路由接續(xù)等功能， 可以將呼叫路由到被叫用戶終端，也可以將呼叫路由到應(yīng)用處理模塊；應(yīng)用處理;f莫塊，用于處理用戶請求，在這里進(jìn)^f亍業(yè)務(wù)邏輯處理；媒體提供設(shè)備，位于核心網(wǎng)側(cè)，可以接受應(yīng)用處理模塊的請求或者控制為 終端傳送指定的媒體文件或者媒體流，應(yīng)用處理模塊對媒體提供設(shè)備的請求可 以經(jīng)中間處理模塊傳遞給々某體提供設(shè)備；傳輸處理模塊，位于接入網(wǎng)邊界，可以接受中間處理模塊的請求對業(yè)務(wù)流 的傳輸進(jìn)行控制，也可以接受中間處理模塊的指示與媒體提供設(shè)備建立聯(lián)系獲 取特定的媒體流。終端可以向應(yīng)用處理才莫塊請求特定的組播/廣播業(yè)務(wù)，如IPTV業(yè)務(wù)； 各功能實(shí)體之間通過如下接口實(shí)現(xiàn)通信連接El:為終端和中間處理模塊的接口；終端通過此接口向應(yīng)用處理模塊請求 業(yè)務(wù)，其請求須經(jīng)過中間處理模塊的處理到達(dá)應(yīng)用處理模塊；El接口協(xié)議可 以是SIP, HTTP, RTSP等；E2:為中間處理模塊和應(yīng)用處理模塊的接口；中間處理模塊通過此接口進(jìn) 行終端和應(yīng)用處理模塊之間信令的轉(zhuǎn)接；E2接口協(xié)議可以是SIP, HTTP, RTSP 等；E3:為中間處理模塊和媒體提供設(shè)備之間的接口；中間處理模塊通過此接 口轉(zhuǎn)接應(yīng)用處理模塊向媒體提供設(shè)備的媒體資源請求；E3接口協(xié)議可以是 SIP , Diameter, H.248等； E4:為中間處理才莫塊和傳輸處理才莫塊的接口 ；中間處理才莫塊可以通過此接 口請求傳輸處理模塊進(jìn)行傳輸通道控制，指示傳輸控制模塊從媒體提供設(shè)備獲 得特定的媒體流等；E4接口協(xié)議可以是COPS (Common Open Policy Server 通用開放策略服務(wù)(協(xié)議)，用于在策略服務(wù)器和客戶端設(shè)備之間交換策略信 息的查詢協(xié)議)，H.248, Diameter等。終端和傳輸處理模塊之間、傳輸處理模塊和媒體提供設(shè)備之間分別通過IP 網(wǎng)絡(luò)連接。實(shí)現(xiàn)本發(fā)明上述技術(shù)構(gòu)思時(shí)，通過終端和應(yīng)用處理模塊之間的信令協(xié)商建 立單播組播/廣播業(yè)務(wù)的傳輸通道，傳輸通道為建立在媒體提供設(shè)備和傳輸處理 模塊之間的應(yīng)用層組播。在協(xié)商過程中，應(yīng)用處理模塊在相關(guān)信令中攜帶用于 建立傳輸通道所需的相關(guān)^L相關(guān)參數(shù)實(shí)際就是對所使用的應(yīng)用層組播方式 的描述，可以是封裝模式和映射模式。封裝模式是指媒體提供設(shè)備向傳輸處理模塊發(fā)送的組播/廣播媒體流是將 原始的IP組播/廣4番媒體流當(dāng)作某種傳送協(xié)議的負(fù)載進(jìn)行發(fā)送的機(jī)制，如可以 使用GRE ( Generic Routing Encapsulation通用路由封裝)隧道，或者IPSec所 定義的隧道機(jī)制等進(jìn)行組播/廣^番媒體流的封裝和發(fā)送。映射模式是指媒體提供設(shè)備對媒體流以某種傳輸機(jī)制對原始媒體流進(jìn)行 傳輸，對其不再進(jìn)行其它封裝；在此媒體流中選取其^R文特征用于接收對端識別特定的組播/廣插^某體流，如可以選#^某體報(bào)文的源地址和源端口作為其識別 特征；當(dāng)媒體流到達(dá)傳輸?shù)膶Χ藭r(shí)(這里是傳輸處理模塊)，由對端根據(jù)預(yù)先 協(xié)商(或者配置)的結(jié)果從此媒體流中提取特定組播/廣播流對應(yīng)的媒體流的機(jī) 制。當(dāng)協(xié)商過程的信令經(jīng)過中間處理模塊路由、呼叫控制時(shí)，由中間處理模塊 根據(jù)這些信息請求傳輸處理模塊建立到媒體提供設(shè)備的媒體傳輸通道；由于傳 輸處理4莫塊和媒體提供設(shè)備之間使用應(yīng)用層組播技術(shù)進(jìn)4亍i某體傳輸，因而可以 解決核心網(wǎng)不支持IP組播的問題；另外，即使核心網(wǎng)支持IP組播，因?yàn)榛?br> 應(yīng)用層組播技術(shù)的應(yīng)用處理模塊或者媒體提供設(shè)備可以對傳輸處理模塊的應(yīng) 用層組播傳輸通道建立請求進(jìn)行驗(yàn)證，從而可以避免組播流向非法實(shí)體發(fā)送。如圖4所示，以組播業(yè)務(wù)為例，說明本發(fā)明所迷組播/廣播業(yè)務(wù)的主要實(shí)現(xiàn) 流程，具體包括如下步驟5101、 終端發(fā)出組播業(yè)務(wù)請求，該組播業(yè)務(wù)請求經(jīng)中間處理模塊路由到應(yīng) 用處理模塊；5102、 應(yīng)用處理模塊向媒體提供設(shè)備請求該組播業(yè)務(wù)的媒體資源；應(yīng)用處理模塊向媒體提供設(shè)備請求組播業(yè)務(wù)的媒體資源，媒體提供設(shè)備相 應(yīng)的向應(yīng)用處理模塊響應(yīng)處理結(jié)果，這里媒體提供設(shè)備可以向應(yīng)用處理模塊返 回如下信息 <應(yīng)用層組播類型，應(yīng)用層組播通道描述參數(shù)>;其中<應(yīng)用層組 播類型>可以是封裝模式或者映射模式；其中 <應(yīng)用層組播通道描述參數(shù)>對于 封裝模式可能使用隧道技術(shù)，則可能包括<隧道類型，隧道本端地址，隧道本 端端口>等，但不限于此；對于映射模式可以使用傳輸層參數(shù)進(jìn)行標(biāo)識，如< 本端單播地址，本端端口>等，也可以增加其它擴(kuò)展參數(shù)用于描述，不限于此。 另夕卜，還需要給出相關(guān)組播媒體流^:，包括如<組播地址，組播端口〉等信息；應(yīng)用處理才莫塊還可以為每一個組^"業(yè)務(wù)的々某體流分配一個唯一對應(yīng)的業(yè) 務(wù)流標(biāo)識，該業(yè)務(wù)流標(biāo)識用于對組播媒體流進(jìn)行唯一標(biāo)識，后續(xù)相關(guān)信令中同 時(shí)攜帶該業(yè)務(wù)流標(biāo)識。5103、 應(yīng)用處理;f莫塊通過中間處理才莫塊向終端發(fā)送業(yè)務(wù)響應(yīng)消息，該響應(yīng) 消息中攜帶<業(yè)務(wù)流標(biāo)識，組播媒體流參數(shù)，應(yīng)用層組播類型，應(yīng)用層組播通 道描述參數(shù)>等，該業(yè)務(wù)響應(yīng)消息在到達(dá)終端之前需要經(jīng)過中間處理模塊的處 理；5104、 中間處理模塊根據(jù)來自應(yīng)用處理模塊的業(yè)務(wù)響應(yīng)消息中的信息，向 傳輸處理模塊進(jìn)行資源請求，該資源請求中攜帶<業(yè)務(wù)流標(biāo)識，組播媒體流參 數(shù)，應(yīng)用層組播類型，應(yīng)用層組播通道描述#>等；S105 、傳輸處理模塊根據(jù)中間處理模塊所傳遞的應(yīng)用層組播類型和應(yīng)用層 組播通道描述參數(shù)等建立和媒體提供設(shè)備的傳輸通道，該傳輸通道用于后續(xù)媒體流的單播發(fā)送；多個組播業(yè)務(wù)可以復(fù)用同一條傳輸通道，傳輸處理模塊通過其中攜帶的組 播業(yè)務(wù)流參數(shù)和/或業(yè)務(wù)流標(biāo)識區(qū)分不同業(yè)務(wù)，也可以為每一個業(yè)務(wù)分別建立一 條傳輸通道。這里，傳輸通道的建立可以是封裝才莫式或者映射模式，若兩種才莫式下傳輸 處理模塊都可以主動向應(yīng)用處理模塊進(jìn)行傳輸通道建立請求，則這里直接建立 就可以了。若某種模式下需要應(yīng)用處理模塊預(yù)先知道發(fā)送對端的地址信息，即 傳輸處理模塊的地址信息，則在步驟S101中或者在終端和應(yīng)用處理模塊協(xié)商 的中間過程中，中間處理模塊需要在經(jīng)過其處理的協(xié)商信令中增加傳輸處理模 塊的地址信息，該地址信息可以是傳輸處理模塊的地址或端口信息，也可以包 括其它附加信息；該信息不需要終端理解，只需要增加在傳遞給應(yīng)用處理模塊 的信令中即可。業(yè)務(wù)流標(biāo)識可以用于后續(xù)請求的優(yōu)化處理，即當(dāng)后續(xù)有其它用戶終端請求 同一個組播業(yè)務(wù)媒體流時(shí)，傳輸處理模塊可以通過匹配該業(yè)務(wù)流標(biāo)識進(jìn)行識 別，從而不需要再重新建立傳輸通道。傳輸處理模塊需要保存業(yè)務(wù)流標(biāo)識(如果存在)以及組播媒體流參數(shù)，如 果存在業(yè)務(wù)流標(biāo)識，則以此標(biāo)識進(jìn)行后續(xù)請求的優(yōu)化處理，即如果標(biāo)識相同， 則傳輸處理模塊不需要再建立傳輸通道；若業(yè)務(wù)流標(biāo)識不存在，則使用組播媒 體流參數(shù)進(jìn)行后續(xù)請求的優(yōu)化處理。另外，傳輸處理模塊中可以設(shè)置存儲子模塊，用于存儲用戶配置表，用戶 配置表用來以用戶標(biāo)識(如以用戶IP為標(biāo)識)為索引保存各用戶的組播媒體 流參數(shù)，可以用于檢查用戶組播權(quán)限等，防止非法用戶加入IP組播組。對于映射模式而言，傳輸處理實(shí)體從傳輸通道中識別出特定映射標(biāo)識的媒 體流之后，可以采用此組播媒體流^lt對該媒體流按IP組播方式重新打包， 則仍然可以在從傳輸模塊到終端的傳輸路徑上使用IP組播技術(shù)進(jìn)行媒體流傳 送。5106、 傳輸處理模塊向中間處理4莫塊發(fā)送響應(yīng)結(jié)果，如杲成功建立傳輸通 道，則響應(yīng)結(jié)果為成功響應(yīng)，否則響應(yīng)結(jié)果為失敗響應(yīng)；響應(yīng)結(jié)果中可以攜帶業(yè)務(wù)流標(biāo)識用于請求匹配。5107、 中間處理;f莫塊收到成功響應(yīng)后，向終端發(fā)送業(yè)務(wù)響應(yīng)，其中攜帶< 業(yè)務(wù)流標(biāo)識，組播媒體流參數(shù)>等；這里，中間處理模塊在發(fā)送給終端的業(yè)務(wù)響應(yīng)中沒有發(fā)送業(yè)務(wù)層組播描述 信息，因?yàn)檫@個信息是在網(wǎng)絡(luò)側(cè)所使用的，并不需要傳遞到終端。終端使用現(xiàn)有的IP組播機(jī)制，使用組播々某體流參數(shù)加入組播組；業(yè)務(wù)流 標(biāo)識可以用于在后續(xù)流程中的業(yè)務(wù)層信令中，標(biāo)識本次請求的組播業(yè)務(wù)。5108、 終端在收到業(yè)務(wù)響應(yīng)后，可能和應(yīng)用處理模塊進(jìn)行進(jìn)一步的媒體協(xié) 商直至協(xié)商結(jié)束。在協(xié)商成功后，媒體流通過傳輸通道從媒體提供設(shè)備單播到傳輸處理模 塊，傳輸處理模塊根據(jù)使用的應(yīng)用層組播模式作相應(yīng)的處理1、 在封裝模式下從封裝報(bào)文中提取出IP組播報(bào)文，對該組播報(bào)文傳輸處 理模塊可以不加修改的向下游實(shí)體轉(zhuǎn)發(fā)，如可以直接發(fā)送給終端；2、 在映射模式下根據(jù)映射參數(shù)，如可以根據(jù)報(bào)文的目的地址和端口，根 據(jù)映射關(guān)系表，此映射表可以包含〈IP目的地址(單播)，目的端口〉到〈IP組 播地址，組播目的端口>的對照關(guān)系，傳輸處理模塊收到特定媒體流時(shí)，可以 把該媒體報(bào)文的地址修改為組播媒體流參數(shù)所給出的IP組播地址和端口等， 然后繼續(xù)向下游實(shí)體轉(zhuǎn)發(fā)。當(dāng)然，傳輸處理模塊也可以對從上面兩種模式提取出的媒體流進(jìn)行其它處理。這里需要說明的是，中間處理模塊向傳輸處理模塊進(jìn)行資源請求的時(shí)才M艮據(jù)業(yè)務(wù)請求過程的不同可能有所變化；如只有當(dāng)中間處理才莫塊確認(rèn)終端和應(yīng) 用處理模塊的業(yè)務(wù)請求成功時(shí)才開始進(jìn)行資源請求；終端和業(yè)務(wù)處理模塊之間的業(yè)務(wù)協(xié)商可能需要多次才能完成，這時(shí)資源請求過程可能發(fā)生在協(xié)商的中間 階段，但應(yīng)在雙方完全結(jié)束協(xié)商之前。因此，上述業(yè)務(wù)流程+的步驟順序只是 為了說明發(fā)明思路，其在具體實(shí)施時(shí)存在多種可能的合理變化。圖4所示流程中，在終端請求建立組播業(yè)務(wù)的過程中，傳遞建立傳輸通道 的相關(guān)參數(shù)，實(shí)際上，這些相關(guān)參數(shù)可以預(yù)先分別配置到傳輸處理模塊和士某體 提供設(shè)備上，根據(jù)組播業(yè)務(wù)的特性，傳輸處理模塊和媒體提供設(shè)備之間隨時(shí)保 持所述傳輸通道單播組播媒體流，應(yīng)用處理模塊在收到終端的業(yè)務(wù)請求時(shí)，將 相應(yīng)的IP組播地址發(fā)送給終端，終端根據(jù)IP組播地址申請加入到組播組中， 接收傳輸處理模塊發(fā)送的組播媒體流。下面進(jìn)一步以具體實(shí)施例并結(jié)合附圖詳細(xì)說明本發(fā)明技術(shù)方案。實(shí)施一、如圖5所示，傳輸處理模塊可以實(shí)例化為TISPANNGN中RACS，其中， 終端、應(yīng)用處理模塊、中間處理模塊、媒體提供設(shè)備以及接口 El、 E2、 E3、 E4等的功能前文中給出，這里不再重復(fù)描述。SPDF, A-RACF， RCEF， BGF 等屬于RACS的定義，與相關(guān)標(biāo)準(zhǔn)(ETSI ES 282 003 TISPAN RACS )保持一 致，具體功能在后續(xù)流程中一并給出。另夕卜，中間處理模塊包含或?qū)崿F(xiàn)了 RACS標(biāo)準(zhǔn)中所定義的AF(Application Function,應(yīng)用功能)功能。如圖6所示，基于圖5所示系統(tǒng)結(jié)構(gòu)，實(shí)現(xiàn)組播業(yè)務(wù)包括如下步驟5201、 終端發(fā)出組播業(yè)務(wù)請求，該請求經(jīng)中間處理模塊路由到應(yīng)用處理模塊；5202、 應(yīng)用處理模塊向媒體提供設(shè)備請求媒體資源，媒體提供設(shè)備相應(yīng)的 向應(yīng)用處理模塊響應(yīng)處理結(jié)果，這里媒體提供設(shè)備可以向應(yīng)用處理模塊返回如 下信息 <應(yīng)用層組播類型，應(yīng)用層組播通道描述參數(shù)>;其中<應(yīng)用層組播類 型>可以是封裝模式或者映射模式；其中 <應(yīng)用層組播通道描述參數(shù)>對于封裝 模式可能使用隧道技術(shù)，則可能包括<隧道類型，隧道本端地址，隧道本端 口>等，但不限于此；對于映射模式可以使用傳輸層參數(shù)進(jìn)行標(biāo)識，如<本端單 播地址，本端端口>等，前述本端都是指媒體傳輸設(shè)備端，相關(guān)參數(shù)中也可以 增加其它擴(kuò)展參數(shù)用于描迷，不限于此。另外，還需要給出相關(guān)組播媒體流參數(shù)，包括如<組播地址，組播端口〉等信息；對于媒體提供設(shè)備而言，其發(fā)送媒體流時(shí)根據(jù)應(yīng)用層組播模式的不同 作如下不同處理1、 在封裝模式下，媒體提供設(shè)備向傳輸處理模塊發(fā)送的組播數(shù)據(jù)流是將 原始的IP組播數(shù)據(jù)流當(dāng)作某種傳送協(xié)議的負(fù)栽進(jìn)行發(fā)送，如可以使用GRE隧 道，或者IPSec所定義的IPinIP機(jī)制進(jìn)行組播媒體數(shù)據(jù)的封裝和發(fā)送。2、 在映射模式下，媒體提供設(shè)備對媒體流以某種傳輸機(jī)制對原始媒體流 進(jìn)行傳輸，對其不再進(jìn)行其它封裝；當(dāng)媒體流到達(dá)傳輸?shù)膶Χ藭r(shí)(這里是傳輸 處理模塊)由對端4艮據(jù)預(yù)先協(xié)商(或者配置)的結(jié)杲(例如映射關(guān)系表)從此 媒體流中提取特定組播流對應(yīng)的媒體流，如可以使用RTP傳送方式，傳輸對端 可以通過RTP流的IP地址和端口對媒體流加以區(qū)分。同樣，應(yīng)用處理模塊還可以為每一個組播業(yè)務(wù)的媒體流在分配一個唯一對 應(yīng)的業(yè)務(wù)流標(biāo)識，該業(yè)務(wù)流標(biāo)識用于對組播媒體流進(jìn)行唯一標(biāo)識，后續(xù)流程中同時(shí)攜帶該業(yè)務(wù)流標(biāo)識，關(guān)于該業(yè)務(wù)流標(biāo)識參見實(shí)施例一，后續(xù)不再重復(fù)描述。5203、 應(yīng)用處理模塊通過包含AF功能的中間處理模塊向終端發(fā)送業(yè)務(wù)響 應(yīng)消息，該響應(yīng)消息中攜帶<業(yè)務(wù)流標(biāo)識，組播媒體流參數(shù)，應(yīng)用層組播類型， 應(yīng)用層組播通道描述參數(shù)>等，該業(yè)務(wù)響應(yīng)消息在到達(dá)終端之前需要經(jīng)過中間 處理模塊的處理；5204、 AF根據(jù)應(yīng)用處理模塊響應(yīng)消息中的信息向RACS進(jìn)行資源請求， 這里AF向SPDF發(fā)送的請求攜帶〈業(yè)務(wù)流標(biāo)識，組播媒體流參數(shù)，應(yīng)用層組播 類型，應(yīng)用層組播通道描述參數(shù)>等；5205、 這里，與SPDF連接的BGF可能有多個，SPDF可以根據(jù)多種條件 進(jìn)行BGF的選擇，如BGF負(fù)載，BGF能力等；選定BGF后，SPDF保存請求
中攜帶的業(yè)務(wù)流標(biāo)識和當(dāng)前選擇的BGF;后續(xù)需要將相關(guān)請求發(fā)送到同一個 BGF,否則如杲選了不同的BGF，則每一個BGF都要和媒體提供設(shè)備建立傳 輸通道。5206、 SPDF根據(jù)請求信息向BGF進(jìn)一步進(jìn)行資源請求，該請求中攜帶< 業(yè)務(wù)流標(biāo)識，組播々某體流參數(shù)，應(yīng)用層組播類型，應(yīng)用層組播通道描述參數(shù)， 用戶線路標(biāo)識和/或用戶IP〉等；其中用戶線路標(biāo)識(該用戶線路標(biāo)識可以用 于用戶傳輸面的控制)可以從A-RACF獲得，而A-RACF的線路標(biāo)識信息則 可能來自于NASS;5207、 BGF在收到上述請求后，根據(jù)應(yīng)用層組播通道參數(shù)(例如隧道描 述參數(shù))與媒體提供設(shè)備建立傳輸通道，該傳輸通道用于后續(xù)媒體流的發(fā)送。應(yīng)用層組播通道參數(shù)就是媒體提供設(shè)備在步驟S202中反饋給應(yīng)用處理模 塊的信息。傳輸通道的建立可以是封裝模式或者映射模式，若兩種模式下BGF都可 以主動向應(yīng)用處理模塊進(jìn)行傳輸通道建立請求，則這里直接建立就可以了。若 某種模式下需要應(yīng)用處理模塊預(yù)先知道發(fā)送對端的地址信息(這里是BGF )， 則在步驟S201中或者在終端和應(yīng)用處理模塊協(xié)商的中間過程中，中間處理模 塊需要在兩者的協(xié)商信令經(jīng)過其處理時(shí)在其中增加BGF的地址信息，該信息 可以是BGF的地址和端口信息，也可以包括其它附加信息；該信息不需要終 端理解，只需要增加在傳遞給應(yīng)用處理模塊的信令中即可。在這里對于封裝模式，若使用隧道機(jī)制，則可以是GRE或者IPSec所定 義的IPinIP;對于映射模式，則可能僅根據(jù)IP和端口對媒體流加以區(qū)分。同樣，BGF上可以保存用戶配置表，用于用戶組播權(quán)限的檢查等；對于映 射模式而言，在從傳輸通道中識別出特定的媒體流之后，BGF可以采用此組播 媒體流參數(shù)對該媒體流按IP組播方式重新打包，則仍然可以在從BGF到終端 的傳輸路徑上使用IP組播技術(shù)進(jìn)行媒體流傳送。5208、 BGF保存〈業(yè)務(wù)流標(biāo)識，組播媒體流參數(shù)，用戶線路標(biāo)識和/或用戶ip〉等；這里用戶線路標(biāo)識和/或用戶ip將用于處理后續(xù)請求時(shí)進(jìn)行匹配，即當(dāng)af 收到具有相同業(yè)務(wù)流標(biāo)識的請求時(shí)，它只需要記錄用戶線路標(biāo)識和/或用戶ip 并將其與業(yè)務(wù)流標(biāo)識關(guān)聯(lián)即可；用戶線路標(biāo)識和/或用戶ip和組播媒體流參數(shù) 則可以用于對組管理請求的權(quán)p艮驗(yàn)證處理，和上面的驗(yàn)證不同，這里指是否允 許用戶加入對應(yīng)的組播組以接收媒體流，驗(yàn)證失敗則拒絕發(fā)送組播媒體流給用 戶，驗(yàn)證通過則允許用戶加入對應(yīng)的組播組以接收士某體流。s209、 bgf向spdf發(fā)送資源請求響應(yīng)，指出處理結(jié)果；其響應(yīng)中可以攜 帶業(yè)務(wù)流標(biāo)識用于請求匹配；52010、 spdf向中間處理才莫塊中的af發(fā)送資源請求響應(yīng)，指出處理結(jié)果； 其響應(yīng)中可以攜帶業(yè)務(wù)流標(biāo)識用于請求匹配；52011、 af收到成功響應(yīng)后，向終端發(fā)送業(yè)務(wù)響應(yīng)，其中攜帶<業(yè)務(wù)流標(biāo) 識，組播媒體流參數(shù)>等；這里af在發(fā)送給終端的響應(yīng)中沒有發(fā)送它收到的 應(yīng)用層組播參數(shù)，因?yàn)檫@個信息是在網(wǎng)絡(luò)側(cè)所使用的，并不需要傳遞到終端；52012、 終端在收到業(yè)務(wù)響應(yīng)后，可能和應(yīng)用處理才莫塊進(jìn)行進(jìn)一步的^f某體 協(xié)商直至協(xié)商結(jié)束。在協(xié)商成功后，媒體流從媒體提供設(shè)備傳遞到bgf，傳輸 處理模塊根據(jù)使用的應(yīng)用層組播模式作相應(yīng)的處理1、 在封裝模式下從封裝報(bào)文中提取出ip組播報(bào)文，對該組播報(bào)文傳輸處 理模塊可以不加修改的向下游實(shí)體轉(zhuǎn)發(fā)，如可以直接發(fā)送給終端；2、 在映射模式下根據(jù)映射參數(shù)，如可以根據(jù)報(bào)文的目的地址和端口，把 特定媒體流區(qū)分出來，對該媒體流可以把該媒體報(bào)文的地址修改為組播媒體流 參數(shù)所給出的ip組播地址和端口等，可以將修改的結(jié)果繼續(xù)向下游實(shí)體轉(zhuǎn)發(fā)。當(dāng)然，傳輸處理模塊也可以對從上面兩種模式提取出的媒體流進(jìn)行其它處理。這里需要說明的是，中間處理模塊中的af向racs進(jìn)行資源請求的時(shí)機(jī) 根據(jù)業(yè)務(wù)請求過程的不同可能有所變化；如只有當(dāng)af確認(rèn)終端和應(yīng)用處理模
塊的業(yè)務(wù)請求成功時(shí)才開始進(jìn)行資源請求，對于需要多次信令交互才能完成終 端和業(yè)務(wù)處理模塊協(xié)商的應(yīng)用，這時(shí)資源請求過程可能發(fā)生在協(xié)商的中間階 段，但應(yīng)在雙方完全結(jié)束協(xié)商之前。因此，上迷業(yè)務(wù)流程中的步驟順序只是為 了說明發(fā)明思路，其在具體實(shí)施時(shí)存在多種合理/可能的變化。另外，如果考慮在RCEF上進(jìn)行組管理請求(IGMP或者M(jìn)LD等)的控 制，則SPDF在確定了 BGF之后，也可以通過A-RACF向RCEF下發(fā)用于對 組管理請求進(jìn)行策略檢查的BGF的地址；當(dāng)RCEF收到終端的IGMP或者M(jìn)LD 請求時(shí)，它可以向BGF請求進(jìn)行組管理驗(yàn)證，其接口可以使用Diameter等， 但不限于此。組管理具體指IP組播成員管理，IGMP/MLD分別是對應(yīng)用IPv4/IPv6的組 成員管理協(xié)議， 一般用于終端和路由器之間，終端向路由器進(jìn)行成員報(bào)告/加入 /離開組播組，路由器據(jù)此判斷是否向用戶發(fā)送組播流；可以在路由器上進(jìn)行 IGMP/MLD權(quán)限判斷，也就是承載層組播控制。當(dāng)然，SPDF也可以通過A-RACF向RCEF傳遞<(用戶線路標(biāo)識)和/或(用 戶IP)，媒體組播地址>的關(guān)聯(lián)信息，則RCEF可以直接根據(jù)這些信息對用戶的 組管理請求進(jìn)行匹配以防止非法內(nèi)容請求。當(dāng)完成上述過程后，媒體提供設(shè)備可以對用戶所請求的頻it/媒體內(nèi)容進(jìn)行 IP組播方式的封裝，然后再將其通過隧道傳送到BGF處；BGF從隧道中取出 IP組播數(shù)據(jù)后就可以向網(wǎng)絡(luò)的下游節(jié)點(diǎn)發(fā)送了。到這里，對于核心網(wǎng)不支持IP 組播或者支持IP組播但希望使用應(yīng)用層組播技術(shù)(這里是隧道傳輸)的問題 已經(jīng)解決；BGF向下游節(jié)點(diǎn)以何種方式發(fā)送也可以有多種方式，這里為了闡述 的完整性予以il明。根據(jù)接入網(wǎng)支持的組播技術(shù)，可以有以下應(yīng)用場景1、支持MBMS (Multimedia Broadcast Multicast Service,多媒體廣播組播 業(yè)務(wù))當(dāng)本發(fā)明上述4支術(shù)方案應(yīng)用于支持MBMS的GPRS (General Packet Radio Service,通用分組無線業(yè)務(wù))網(wǎng)絡(luò)時(shí)，可以i人為GGSN ( Gateway GPRS Support Node,網(wǎng)關(guān)GPRS支持節(jié)點(diǎn))是RCEF和BGF合一的結(jié)果，或者說不存在RCEF 實(shí)體；這樣，根據(jù)前述方案，可以在媒體提供設(shè)備和GGSN之間建立應(yīng)用層組 播媒體傳輸通道，媒體內(nèi)容以應(yīng)用層組播方式下發(fā)到GGSN, GGSN對J 某體內(nèi) 容作處理后向下游下發(fā)；在GGSN處下發(fā)的數(shù)據(jù)采用MBMS組播技術(shù)。在MBMS網(wǎng)絡(luò)中原有的組播控制是由GGSN向BM-SC進(jìn)行請求的，這 里我們通過RACS向GGSN直接下發(fā)組^"策略信息，如上述流程中步驟S206 中SPDF向BGF的請求；這樣可以使GGSN直接進(jìn)行組管理請求的策略匹酉己。2、 支持IGMP/MLD,并支持IP組播處理以適用于xDSL網(wǎng)絡(luò)狀況的TISPANNGN架構(gòu)來說，其中傳輸層的Access Node可以映射到DSLAM, RCEF+L2TF (Layer 2 Termination Function, 2層終 結(jié)功能)可以映射到BRAS。這里可以在BGF和媒體提供設(shè)備之間建立應(yīng)用層組播傳輸通道用于組播 數(shù)據(jù)的傳遞；BGF把組播內(nèi)容從隧道中取出后發(fā)送給下游節(jié)點(diǎn)，在這里就是 RCEF。在這里BGF并不進(jìn)行組播數(shù)據(jù)流的復(fù)制分發(fā)；根據(jù)用戶使用的協(xié)議不 同，目前一般復(fù)制分發(fā)點(diǎn)放在RCEF (BRAS )或者AccessNode ( DSLAM)上， 這在目前接入網(wǎng)中已是成熟技術(shù)。3、 支持BCMCS ( Broadcast and Multicast Service,廣播及組播服務(wù))的應(yīng) 用方式對于3GPP2所定義的BCMCS網(wǎng)絡(luò)，在具體應(yīng)用時(shí)可以將BSN看作圖6 所示的BGF，在業(yè)務(wù)過程中選定BSN，使其作為應(yīng)用層組播的一個節(jié)點(diǎn)和媒 體提供節(jié)點(diǎn)建立應(yīng)用層組播傳輸通道用于組4番媒體流的傳輸；在BSN收到相 關(guān)的組播媒體流之后再向下游節(jié)點(diǎn)轉(zhuǎn)發(fā)，如直接發(fā)送給終端。4、 支持DVB-H (Digital Video Broadcasting-Handheld,數(shù)字視頻廣播-手 持方式)網(wǎng)絡(luò)中的應(yīng)用方式對于DVB組織所定義的DVB-H網(wǎng)絡(luò)，在具體應(yīng)用時(shí)可以將IPE (IP Encapsulator， IP封裝器)看作圖6所示的BGF，在業(yè)務(wù)過程中選定IPE，使其 作為應(yīng)用層組播的一個節(jié)點(diǎn)和媒體提供節(jié)點(diǎn)建立應(yīng)用層組播傳輸通道用于組 播媒體流的傳輸；在IPE收到相關(guān)的組播媒體流之后再向下游節(jié)點(diǎn)轉(zhuǎn)發(fā)，如直 接發(fā)送給終端。 實(shí)施例二、如圖7所示，為在圖6基礎(chǔ)上采用IMS作為應(yīng)用處理模塊時(shí)的邏輯架構(gòu)圖， 其中對于IMScore進(jìn)行了簡略表示，其具體規(guī)范在3GPP已有定義；這里終端 用于和應(yīng)用服務(wù)器(AS)進(jìn)行業(yè)務(wù)協(xié)商，請求應(yīng)用服務(wù)器提供服務(wù)。代理CSCF (P-CSCF)用于轉(zhuǎn)發(fā)終端和服務(wù)CSCF(S-CSCF)之間的請求和響應(yīng)消息。服務(wù) CSCF用于根據(jù)觸發(fā)規(guī)則把業(yè)務(wù)請求消息觸發(fā)到應(yīng)用服務(wù)器(AS),對消息進(jìn) 行路由；AS用于向用戶提供業(yè)務(wù)，與終端進(jìn)行必要的業(yè)務(wù)協(xié)商；根據(jù)協(xié)商的 結(jié)果向MRFC ( Media Resource Function Controller,々某體資源功能控制器)提 出媒體資源請求；MRFC接收AS的媒體資源請求并控制MRFP( Media Resource Function Processor,媒體資源功能處理器)進(jìn)行媒體資源的分配。MRFP受 MRFC的控制向終端提供媒體資源，如提供視頻/音頻節(jié)目流。其它實(shí)體如 SPDF， A-RACF, RCEF， BGF等在RACS架構(gòu)中已有說明。另夕卜， 一般MRFC 和MRFP也合稱為MRF (Multimedia Resource Function,媒體資源功能)，在 下面的流程中為了描述筒潔，以MRF表示。另外需要指出，除了中間處理模塊實(shí)例化為IMScore之外，這里MRF作 為媒體提供設(shè)備，而應(yīng)用處理模塊則由AS (應(yīng)用服務(wù)器)承擔(dān)，P-CSCF則實(shí) 現(xiàn)了 RACS架構(gòu)中所述的AF功能。仍參閱圖7所示，基于IMS實(shí)現(xiàn)組播業(yè)務(wù)的主要流程簡述如下終端發(fā)出組播業(yè)務(wù)請求，其請求經(jīng)P-CSCF路由到S-CSCF,再由S-CSCF 觸發(fā)到到應(yīng)用服務(wù)器AS進(jìn)行處理；這與一般的IMS請求路由過程并沒有什么 不同；應(yīng)用服務(wù)器(AS)向MRF請求媒體資源，MRF相應(yīng)的向AS響應(yīng)處理結(jié) 果，其中攜帶應(yīng)用層組^^相關(guān)參數(shù)等；AS在這里可以分配一個業(yè)務(wù)流標(biāo)識，該標(biāo)識用于對組播媒體流進(jìn)行唯一 標(biāo)識；隨后AS向終端發(fā)送業(yè)務(wù)響應(yīng)消息，該消息攜帶<業(yè)務(wù)流標(biāo)識，組播々某 體流參數(shù)，應(yīng)用層組播參數(shù)>等，其中組播媒體流參數(shù)和應(yīng)用層組播參數(shù)可以 通過擴(kuò)展SDP攜帶在SIP中的SDP中；這個響應(yīng)消息在到達(dá)終端之前需要經(jīng) 過P-CSCF的處理；中間過程和實(shí)施一相同，只是最終由SPDF返回的資源請求響應(yīng)是發(fā)送給 P-CSCF的。P-CSCF收到成功響應(yīng)后，向終端發(fā)送業(yè)務(wù)響應(yīng)，其中攜帶<業(yè)務(wù) 流標(biāo)識，組播媒體流參數(shù)>等；終端在收到業(yè)務(wù)響應(yīng)后，可能和應(yīng)用處理模塊 進(jìn)行進(jìn)一步的媒體協(xié)商直至協(xié)商結(jié)束。需要說明的是，P-CSCF向RACS進(jìn)行資源請求的時(shí)才M艮據(jù)業(yè)務(wù)請求過程 的不同可能有所變化；如只有當(dāng)P-CSCF確認(rèn)終端和業(yè)務(wù)處理^f莫塊的業(yè)務(wù)請求 成功時(shí)才開始進(jìn)行資源請求，對于使用SIP進(jìn)行業(yè)務(wù)請求時(shí)而言可能存在終端 和AS的多次協(xié)商，這時(shí)資源請求過程可能發(fā)生在協(xié)商的中間階段，但應(yīng)在雙 方完全結(jié)束協(xié)商之前，如P-CSCF可能在收到AS的SIP 200 ok響應(yīng)時(shí)才開始 資源請求過程，因此流程也有可能有所變化，但其處理的基本思想不變。本發(fā)明可以通過擴(kuò)展SDP攜帶業(yè)務(wù)流標(biāo)識和隧道參數(shù)，這里給出擴(kuò)展說 明。另外，需要指出，由于SDP是非獨(dú)立協(xié)議，可以攜帶在SIP， HTTP, RTSP 等中，因此這里的擴(kuò)展并不限定于SIP使用。這里可以通過在SDP中為業(yè)務(wù)流標(biāo)識和隧道參數(shù)分別定義一個attribute 來進(jìn)行，如下a-MID:業(yè)務(wù)流標(biāo)識這個擴(kuò)展屬性可以對SDP的*某體行(m)加以描述，也可以作為全局屬性 出現(xiàn)；條件是SDP中所有的媒體流屬于同一個媒體組且將在同一個隧道中傳 輸；其中業(yè)務(wù)流標(biāo)識由應(yīng)用處理模塊分配，只需要保障其標(biāo)識的全網(wǎng)唯一性即 可。 a= APP-MULTICAST隱DATA: appType appParameters ， networkProcess，這個擴(kuò)展屬性可以對SDP的媒體行(m)加以描述，也可以作為全局屬性 出現(xiàn)，條件是SDP中所有的媒體流將通過同一個隧道傳輸；其中 APP-MULTICAST-DATA為屬性名；appType為應(yīng)用層組播類型，可以是封裝模式(如encap)和映射模式(如 locate);appParameters為應(yīng)用層組播特定模式下的描述參數(shù)； networkProcess則指出此屬性需要在網(wǎng)絡(luò)內(nèi)處理而不應(yīng)發(fā)送給終端。 若^f吏用隧道才莫式，則可以采用類似下述定義方式a= APP-MULTICAST-DATA : appType tunnelType tunnel-server-address tunnel-port ' ，ip， | ，udp， | ，tcp， ， networkProcess ，這個擴(kuò)展屬性可以對SDP的媒體行(m)加以描述，也可以作為全局屬性 出現(xiàn)，條件是SDP中所有的媒體流將通過同一個隧道傳輸；其中APP-MULTICAST-DATA為屬性名；appType為應(yīng)用層組播類型；tunnelType為隨道類型；tunnel-server-address為隨道月良務(wù)器地址；tunnel-port為隧道端口 ；'，ip，l 'udp，l，tcp"表示建立UDP隧道，TCP隧道或者IP隧道； ，networkProcess，支持此屬性需要在網(wǎng)絡(luò)內(nèi)處理而不應(yīng)發(fā)送給終端。 針對映射模式根據(jù)上述可以很容易給出類似定義，不再贅述。 另夕卜，上述擴(kuò)展屬性的表示并非唯一，只是為了說明發(fā)明思想給出的實(shí)例， 對于不同的隧道協(xié)議其參數(shù)可能不同。 上述擴(kuò)展機(jī)制在具體使用時(shí)可以如下終端和應(yīng)用處理模塊進(jìn)行業(yè)務(wù)協(xié)商，在信令中指出需要建立BGF和MRF之 間的隧道(封裝組播流)用于傳送媒體數(shù)據(jù)；應(yīng)用處理模塊向終端的響應(yīng)信息
可以如下 v=0o=astv 890844730 2890844732 IN IP4 as.example.coma=MID:aabbccddeeffm=audio 65422 RTP/AVP 0a=rtpmap:0 PCMU/8000c=IN IP4 multicat—addressa= APP-MULTICAST-DATA: encap GRE mrf-unicast.example.com PortX ipnetworkProcess a=sendonlym=video 65113 RTP/AVP 31 a=rtpmap:32 MPV簡OO c=IN IP4 multicat—addressa= APP-MULTICAST-DATA: encap GRE mrf-unicast.example.com PortY ip tworkProcess a=sendonly上述信息表示々某體內(nèi)容屬同一個業(yè)務(wù)流標(biāo)識aabbccddeeff;所需建立的 應(yīng)用層隧道為封裝模式，具體采用隧道方式為GRE (Generic Routing Encapsulation，通用路由封裝)類型，隧道對端地址為mrf-unicast.example.com, 端口為40004等。在該交互信令經(jīng)過中間處理模塊處理時(shí)，AF根據(jù)SDP描述信息請求進(jìn)行 隧道的建立，AF傳遞所述隧道信息到SPDF請求傳輸層進(jìn)行隧道建立，SPDF 根據(jù)前述方案進(jìn)行具體的隧道建立過程。這里給出的擴(kuò)展方案是希望應(yīng)用在前述的流程中，前面對應(yīng)用方案已有描 述，不再贅述。顯然，本領(lǐng)域的技術(shù)人員可以對本發(fā)明進(jìn)行各種改動和變型而不脫離本發(fā) 明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權(quán)利要求及 其等同技術(shù)的范圍之內(nèi)，則本發(fā)明也意圖包含這些改動和變型在內(nèi)。
權(quán)利要求
1、一種組播/廣播業(yè)務(wù)實(shí)現(xiàn)方法，其特征在于，包括如下步驟接入網(wǎng)側(cè)傳輸處理模塊和核心網(wǎng)側(cè)媒體提供設(shè)備之間為組播/廣播業(yè)務(wù)建立傳輸通道；所述媒體提供設(shè)備通過所述傳輸通道將組播/廣播媒體流單播給所述傳輸處理模塊；所述傳輸處理模塊根據(jù)所述組播/廣播媒體流的組播/廣播媒體流參數(shù)進(jìn)行組播/廣播。
2、 如權(quán)利要求l所述的方法，其特征在于，至少兩個組播/廣播業(yè)務(wù)復(fù)用 同一條傳輸通道；或者為每一個組播/廣播業(yè)務(wù)分別建立一條傳輸通道。
3、 如權(quán)利要求1所述的方法，其特征在于，所述方法中，所述傳輸處理 才莫塊和媒體提供設(shè)備根據(jù)預(yù)先存儲在本地的相關(guān)參數(shù)建立所述傳輸通道。
4、 如權(quán)利要求3所述的方法，其特征在于，所述方法中還包括如下步驟 終端通過中間處理才莫塊向應(yīng)用處理模塊請求建立所述組播/廣播業(yè)務(wù)； 所述應(yīng)用處理模塊向終端返回所述組播/廣播業(yè)務(wù)的組播地址； 所述終端根據(jù)所述組播地址加入接收所述組播/廣播媒體流的組播組。
5、 如權(quán)利要求l所述的方法，其特征在于，所述方法還包括如下步驟 終端通過中間處理才莫塊向應(yīng)用處理模塊請求建立所述組播/廣播業(yè)務(wù)； 所述應(yīng)用處理模塊向媒體提供設(shè)備請求媒體資源，并接收所述媒體提供設(shè)備返回的建立所述傳輸通道的相關(guān)參數(shù)和組播/廣播媒體流參數(shù)；所述應(yīng)用處理模塊向中間處理模塊發(fā)送攜帶所述傳輸通道相關(guān)參數(shù)和組播/廣播媒體流參數(shù)的業(yè)務(wù)響應(yīng)；所述中間處理模塊向傳輸處理模塊發(fā)送攜帶所述傳輸通道相關(guān)參數(shù)和組播/廣播媒體流l^t的資源請求；所述傳輸處理模塊判斷所述組播/廣播業(yè)務(wù)的傳輸通道是否已經(jīng)建立，如果是則根據(jù)所述組播/廣播媒體流參數(shù)組播/廣播從該傳輸通道上接收的組播/廣播媒體流；否則根據(jù)所述相關(guān)參數(shù)與媒體提供設(shè)備之間建立所述傳輸通道，并 根據(jù)所述組播/廣播媒體流參數(shù)組播/廣播從該傳輸通道上接收的組播/廣播媒 體流。
6、 如權(quán)利要求5所述的方法，其特征在于，所述方法中還包括如下步驟 所述傳輸處理模塊建立所述傳輸通道后或確認(rèn)所述傳輸通道已經(jīng)建立后，向所述中間處理模塊返回資源請求響應(yīng)；所述中間處理模塊向所述終端返回?cái)y帶所述組播/廣播々某體流參數(shù)的業(yè)務(wù) 成功響應(yīng)；所述終端收到所述業(yè)務(wù)成功響應(yīng)后，根據(jù)所述組播/廣播纟某體流參數(shù)加入接 收所述組播/廣播媒體流的組播組。
7、 如權(quán)利要求6所述的方法，其特征在于，所述方法中還包括所述應(yīng) 用處理^f莫塊為每一個組播/廣播業(yè)務(wù)分配一個唯一的業(yè)務(wù)流標(biāo)識，并且所述應(yīng)用處理模塊在發(fā)送給所述中間處理模塊的業(yè)務(wù)響應(yīng)中攜帶對應(yīng)的 業(yè)務(wù)流標(biāo)識；所述中間處理模塊在發(fā)送給所述傳輸處理模塊的資源請求中攜帶所述業(yè) 務(wù)流標(biāo)識，所述傳輸處理模塊記錄所述業(yè)務(wù)流標(biāo)識并根據(jù)記錄信息判斷是否已 經(jīng)為相應(yīng)的組播/廣播媒體流建立了傳輸通道。
8、 如權(quán)利要求7所述的方法，其特征在于，所述方法中還包括 所述中間處理模塊在發(fā)送給所述終端的業(yè)務(wù)響應(yīng)中攜帶所述業(yè)務(wù)流標(biāo)識，所述終端利用所述業(yè)務(wù)流標(biāo)識在后續(xù)流程的相關(guān)消息中標(biāo)識或匹配所述組播/ 廣播業(yè)務(wù)。
9、 如權(quán)利要求5-8任一所述的方法，其特征在于如下之一 所述終端和中間處理模塊之間通過SIP協(xié)議、HTTP協(xié)議或RTSP協(xié)議實(shí)現(xiàn)信息交互；所述中間處理模塊和應(yīng)用處理模塊之間通過SIP協(xié)議、HTTP協(xié)議或RTSP 協(xié)-議實(shí)規(guī)z像息交互；所述中間處理模塊和傳輸處理模塊之間通過COPS協(xié)議、H.248協(xié)議或 Diameter協(xié)議實(shí)現(xiàn)信息交互。
10、 如權(quán)利要求9所述的方法，其特征在于，通過擴(kuò)展會話描述協(xié)議SDP 攜帶建立所述傳輸通道的相關(guān)參數(shù)、組播/廣播媒體流參數(shù)或業(yè)務(wù)流標(biāo)識。
11、 如權(quán)利要求3或5所述的方法，其特征在于，所述傳輸通道的類型包 括封裝模式。
12、 如權(quán)利要求11所述的方法，其特征在于，所述封裝模式的傳輸通道 包括隧道，建立所述隧道的相關(guān)參數(shù)至少包括隧道類型、媒體提供設(shè)備端 的隧道地址和隧道端口 。
13、 如權(quán)利要求12所述的方法，其特征在于，所述隧道是GRE隧道。
14、 如權(quán)利要求3或5所述的方法，其特征在于，所述傳輸通道的類型包 括映射模式，建立所述映射模式傳輸通道的相關(guān)參數(shù)至少包括映射模式類型、 媒體提供設(shè)備端的單播地址和端口 。
15、 如權(quán)利要求l所述的方法，其特征在于，所述組播/廣播媒體流參數(shù)至 少包括IP組播/廣播地址和端口。
16、 如權(quán)利要求5所述的方法，其特征在于，所述傳輸處理模塊建立用戶 配置表，以用戶標(biāo)識為索引保存每一個用戶對應(yīng)的組播/廣播媒體流參數(shù)，并根 據(jù)該用戶配置表驗(yàn)證請求所述組播/廣播士某體流的用戶終端的合法性。
17、 一種組播/廣播業(yè)務(wù)實(shí)現(xiàn)系統(tǒng)，包括終端和位于核心網(wǎng)側(cè)的媒體提供設(shè) 備，其特征在于，所述系統(tǒng)還包括位于接入網(wǎng)側(cè)的傳輸處理模塊，其中，所 述傳輸處理模塊分別通過IP網(wǎng)絡(luò)連接終端和媒體提供設(shè)備；所述傳輸處理模塊和媒體提供設(shè)備之間為組播/廣播業(yè)務(wù)建立傳輸通道；處理4莫塊；所述傳輸處理模塊根據(jù)所述組播/廣播媒體流對應(yīng)的組播/廣播媒體流參數(shù)向終端進(jìn)4亍組#番/廣4番。
18、 如權(quán)利要求17所述的組播/廣播業(yè)務(wù)實(shí)現(xiàn)系統(tǒng)，其特征在于，所述系 統(tǒng)還包括應(yīng)用處理模塊和中間處理模塊，其中所述應(yīng)用處理模塊通過接口連 接中間處理模塊，所述中間處理模塊分別通過接口連接所述終端、傳輸處理模 塊和媒體提供設(shè)備；終端通過中間處理模塊向應(yīng)用處理模塊請求建立所述組播/廣播業(yè)務(wù)；所述應(yīng)用處理模塊向媒體提供設(shè)備請求媒體資源，并接收所述媒體提供設(shè) 備返回的建立所述傳輸通道的相關(guān)參數(shù)和組播/廣播媒體流參數(shù)；所述應(yīng)用處理模塊向中間處理模塊發(fā)送攜帶所述傳輸通道相關(guān)參數(shù)和組 播/廣播媒體流參數(shù)的業(yè)務(wù)響應(yīng)；所述中間處理模塊向傳輸處理模塊發(fā)送攜帶所述傳輸通道相關(guān)參數(shù)和組 播/廣播媒體流參數(shù)的資源請求；所述傳輸處理模塊判斷所述組播/廣播業(yè)務(wù)的傳輸通道是否已經(jīng)建立，如果 是則根據(jù)所述組播/廣播媒體流參數(shù)組播/廣播從該傳輸通道上接收的組播/廣 播媒體流，否則根據(jù)所述相關(guān)參數(shù)與媒體提供設(shè)備之間建立所述傳輸通道。
19、 如權(quán)利要求17所述的組播/廣播業(yè)務(wù)實(shí)現(xiàn)系統(tǒng)，其特征在于，所述傳 輸通道為封裝4莫式傳輸通道或映射模式傳輸通道。
20、 如權(quán)利要求17所述的組播/廣播業(yè)務(wù)實(shí)現(xiàn)系統(tǒng)，其特征在于 所述中間處理模塊包括下一代網(wǎng)絡(luò)NGN中的應(yīng)用功能實(shí)體AF; 所述傳輸處理模塊具體包括NGN中的如下子功能實(shí)體基于業(yè)務(wù)的策略決策功能實(shí)體SPDF、接入-資源及許可控制功能實(shí)體A-RACF、資源控制執(zhí)行 功能實(shí)體RCEF和邊界網(wǎng)關(guān)功能實(shí)體BGF，其中所述SPDF通過接口連接所述中間處理實(shí)體，所述A-RACF連接在SPDF 和RCEF之間，所述BGF分別連接SPDF和RCEF,所述RCEF通過IP網(wǎng)絡(luò) 連接終端，所述BGF通過IP網(wǎng)絡(luò)連接媒體提供設(shè)備。
21、 如權(quán)利要求17所述的組播/廣播業(yè)務(wù)實(shí)現(xiàn)系統(tǒng)，其特征在于 所述應(yīng)用處理模塊包括IP多媒體子系統(tǒng)IMS中的應(yīng)用服務(wù)器AS; 所述中間處理^^莫塊包括IMS中的相關(guān)功能實(shí)體。
22、 如權(quán)利要求21所迷的組播/廣播業(yè)務(wù)實(shí)現(xiàn)系統(tǒng)，其特征在于，所述邊 界網(wǎng)關(guān)功能實(shí)體BGF可以為如下之一支持MBMS的GPRS網(wǎng)絡(luò)中的GGSN; 3GPP2所定義的BCMCS網(wǎng)絡(luò)中的BSN; DVB-H網(wǎng)絡(luò)中的IPE。
23、 如權(quán)利要求18所述的組播/廣播業(yè)務(wù)實(shí)現(xiàn)系統(tǒng)，其特征在于，所述傳 輸處理模塊中包括存儲子模塊，用于存儲用戶配置表，該用戶配置表中以用戶 標(biāo)識為索引保存每一個用戶對應(yīng)的組播/廣播媒體流參數(shù)，所述傳輸處理模塊根 據(jù)該用戶配置表驗(yàn)證請求所述組播/廣播媒體流的用戶終端的合法性。
全文摘要
本發(fā)明涉及組播/廣播業(yè)務(wù)，特別涉及一種組播/廣播業(yè)務(wù)實(shí)現(xiàn)方法和系統(tǒng)，用以解決現(xiàn)有核心網(wǎng)側(cè)不支持IP組播方法時(shí)，如何以單播方式實(shí)現(xiàn)組播/廣播業(yè)務(wù)的問題。本發(fā)明在進(jìn)行組播/廣播業(yè)務(wù)時(shí)，由位于接入網(wǎng)邊界的傳輸處理模塊和位于核心網(wǎng)側(cè)的組播/廣播業(yè)務(wù)的媒體提供設(shè)備之間建立單播傳輸通道，媒體提供設(shè)備通過所述傳輸通道將被請求的組播/廣播媒體流單播給傳輸處理模塊；傳輸處理模塊再采用IP組播技術(shù)，將所述組播/廣播媒體流組播/廣播給終端。在核心網(wǎng)側(cè)不支持IP組播方法時(shí)，實(shí)現(xiàn)了組播/廣播業(yè)務(wù)的單播。
文檔編號H04L12/18GK101155053SQ20061015269
公開日2008年4月2日 申請日期2006年9月25日 優(yōu)先權(quán)日2006年9月25日
發(fā)明者軍 嚴(yán), 吳向陽, 李金成 申請人:華為技術(shù)有限公司