專利名稱：一種實現(xiàn)分布式接納控制的系統(tǒng)和方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，具體涉及一種在接入網(wǎng)域?qū)崿F(xiàn)分布式接納控制的 系統(tǒng)和方法。
背景技術(shù)：
隨著通信技術(shù)的發(fā)展，多媒體通信正逐漸普及，用戶可以使用用戶終端 與多媒體通信系統(tǒng)進(jìn)行數(shù)據(jù)通信，以接受來自多媒體通信系統(tǒng)的越來越多的
多媒體服務(wù)，如包括網(wǎng)際協(xié)議電視(IPTV)組播業(yè)務(wù)在內(nèi)的視頻廣播服 務(wù)等。
但是，在目前提供的基于數(shù)字用戶線(DSL)寬帶接入的IPTV組播業(yè) 務(wù)中，尚無法為用戶終端提供可保證的服務(wù)質(zhì)量，而是只能提供相對服務(wù)質(zhì) 量，該相對服務(wù)質(zhì)量只能保證用戶終端的IPTV組播業(yè)務(wù)有相對高的優(yōu)先級。 在IPTV組播業(yè)務(wù)只能提供相對服務(wù)質(zhì)量的情況下，當(dāng)某個接入設(shè)備上IPTV 業(yè)務(wù)的帶寬申請已經(jīng)超過了該接入設(shè)備可提供的下行帶寬時，會導(dǎo)致所有的 節(jié)目視頻出現(xiàn)隨機(jī)丟包現(xiàn)象；該隨機(jī)丟包現(xiàn)象將使正在為用戶終端提供的所 有業(yè)務(wù)受到不同程度的影響。
為了能向正接收IPTV組播業(yè)務(wù)的用戶終端提供可保證的服務(wù)質(zhì)量，目 前通常需要限制用戶終端可同時點播的頻道數(shù)目，或是在網(wǎng)絡(luò)前期規(guī)劃時根 據(jù)用戶情況建立能滿足極端條件下帶寬要求的寬帶接入網(wǎng)，但上述方式顯然 都會隨著用戶需求的增長而變得不再適用。
可見，由于目前無法為用戶提供可保證服務(wù)質(zhì)量的IPTV組播業(yè)務(wù)，因 而嚴(yán)重降低了用戶滿意度。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明實施例的主要目的在于提供一種實現(xiàn)分布式接納控制的
系統(tǒng)，以提供可保證服務(wù)質(zhì)量的IPTV組播業(yè)務(wù)，提高用戶滿意度。
本發(fā)明實施例的另一目的在于提供一種實現(xiàn)分布式接納控制的方法，以提
供可保證服務(wù)質(zhì)量的IPTV組播業(yè)務(wù)，提高用戶滿意度。
為達(dá)到上述目的，本發(fā)明實施例的技術(shù)方案是這樣實現(xiàn)的 本發(fā)明實施例公開了實現(xiàn)分布式接納控制的系統(tǒng)，應(yīng)用于IPTV組播業(yè)務(wù)，
該系統(tǒng)包括
中心資源管理和策略生成模塊，用于根據(jù)網(wǎng)絡(luò)通信環(huán)境生成業(yè)務(wù)控制策略， 并將生成的業(yè)務(wù)控制策略發(fā)送給接納控制點；
接納控制點，用于根據(jù)收到的業(yè)務(wù)控制策略對用戶終端的IPTV組播頻 道加入請求進(jìn)行接納控制，并根據(jù)接納控制結(jié)果接受或拒絕用戶終端的 IPTV組播頻道加入請求。
本發(fā)明實施例還公開了實現(xiàn)分布式接納控制的方法，應(yīng)用于IPTV組播業(yè) 務(wù)，該方法包括
根據(jù)網(wǎng)絡(luò)通信環(huán)境生成業(yè)務(wù)控制策略并發(fā)送給接納控制點；接納控制點 根據(jù)收到的業(yè)務(wù)控制策略對用戶終端的IPTV組播頻道加入請求進(jìn)行接納控 制，并根據(jù)接納控制結(jié)果接受或拒絕用戶終端的IPTV組播頻道加入請求。
與現(xiàn)有技術(shù)相比，本發(fā)明實施例所提供的系統(tǒng)和方法均可保證，由分布 式的控制節(jié)點AN和EN,根據(jù)集中生成的保證服務(wù)質(zhì)量的IPTV組播業(yè)務(wù)的 業(yè)務(wù)控制策略，對發(fā)自用戶終端的組播加入請求進(jìn)行包括接入權(quán)限控制和資 源接納控制在內(nèi)的接納控制，并根據(jù)接納控制結(jié)果接受或拒絕用戶終端加入 組播頻道的請求。本發(fā)明實施例的系統(tǒng)和方法均使得用戶終端可以被提供可 保證的服務(wù)質(zhì)量，這能夠明顯提高用戶滿意度。


圖1為本發(fā)明一較佳實施例的實現(xiàn)資源接納控制的系統(tǒng)結(jié)構(gòu)及原理圖2為本發(fā)明一較佳實施例的實現(xiàn)資源接納控制的流程圖。
具體實施例方式
下面結(jié)合附圖及具體實施例對本發(fā)明詳細(xì)說明。
本發(fā)明實施例所提供的實現(xiàn)分布式接納控制的系統(tǒng)應(yīng)用于寬帶接入網(wǎng)
IPTV組播業(yè)務(wù)。
該系統(tǒng)主要包括中心資源管理和策略生成(Central Resouce Policy Manager Function, CRPMF )模塊以及作為分布接納控制點的接入節(jié)點(AN ) 和/或接入網(wǎng)邊緣節(jié)點(EN)。其中，CRPMF模塊能根據(jù)IPTV組播業(yè)務(wù)的 Q o S需求、用戶業(yè)務(wù)簽約數(shù)據(jù)和網(wǎng)絡(luò)資源狀況實時統(tǒng)計情況動態(tài)生成分發(fā)給 各分布接納控制點的業(yè)務(wù)控制策略。
在實際應(yīng)用中，作為可實現(xiàn)的功能，接納控制點分布于AN和/或EN上。
AN能根據(jù)配置的業(yè)務(wù)控制策略對來自用戶終端的IPTV組播頻道加入 請求信息進(jìn)行包括頻道接入權(quán)限控制和資源接納控制在內(nèi)的接納控制，并根 據(jù)接納控制結(jié)果進(jìn)行決策，接受或拒絕來自用戶終端的IPTV組播頻道加入 請求，在AN復(fù)制組播頻道視頻流。
當(dāng)AN需進(jìn)一步要求EN向下復(fù)制組播視頻流時，EN能根據(jù)配置的業(yè) 務(wù)控制策略，對AN代理發(fā)出的IPTV組播頻道加入請求信息實施資源接納 控制過程，并根據(jù)接納控制結(jié)果進(jìn)行決策，接受或拒絕來自用戶終端的IPTV 組播頻道加入請求，在EN復(fù)制組播頻道視頻流。
AN和EN還可以將各自的接納控制結(jié)果返回給用戶終端。參見圖1, 圖1為本發(fā)明一較佳實施例的實現(xiàn)資源接納控制的系統(tǒng)結(jié)構(gòu)及原理圖。圖1 中顯示了一個完整的IPTV組播業(yè)務(wù)的網(wǎng)絡(luò)架構(gòu)。
其中，作為用戶終端，機(jī)頂盒(STB) 111、計算機(jī)112可以與接入節(jié) 點(AN) 120相連，AN 120則通過匯聚設(shè)備(AgN) 130與邊緣節(jié)點(EN) 140相連，EN 140通過城域網(wǎng)中的電視業(yè)務(wù)路由器(Video-SR) 150與IPTV 頭端系統(tǒng)160相連；再有，CRPMF 100分別與AN 120、 EN 140相連。其中，
IPTV頭端系統(tǒng)160負(fù)責(zé)提供組播頻道的頻道內(nèi)容。在實際的網(wǎng)絡(luò)實現(xiàn)時， IPTV頭端系統(tǒng)160通常會將頻道內(nèi)容下發(fā)并存儲在Video-SR 150中；在用 戶終端申請頻道內(nèi)容時，該頻道內(nèi)容會經(jīng)過Video-SR 150下發(fā)，并在EN 140 和AN 120上以組播復(fù)制方式被發(fā)送到用戶終端。
在實際應(yīng)用中，CRPMF 100能根據(jù)獲得的IPTV組播業(yè)務(wù)的QoS需求、 用戶的網(wǎng)絡(luò)接入簽約數(shù)據(jù)以及全網(wǎng)資源的狀況統(tǒng)計信息，生成IPTV組播業(yè) 務(wù)所需的保證質(zhì)量(Guaranteed-QoS )的業(yè)務(wù)控制策略，并將生成的業(yè)務(wù)控 制策略分發(fā)給分布式接納控制點AN 120、 EN 140。
發(fā)給AN120的業(yè)務(wù)控制策略包括用戶可接入組播頻道列表和用戶接 入頻道策略。用戶可接入組播頻道列表列出了用戶終端可以接入的組播頻 道；用戶接入頻道策略包括但不限于用戶可以接入的最多的頻道數(shù)目。 AN根據(jù)收到的業(yè)務(wù)控制策略，可在最靠近用戶的接納控制點就實施對用戶 的頻道接入權(quán)限的控制；這既可保證網(wǎng)絡(luò)的安全性，又能最快處理用戶的頻 道接入請求，從而改善用戶體驗。
發(fā)給AN120和EN 140的業(yè)務(wù)控制策略還包括針對IPTV組播業(yè)務(wù)的 QoS控制策略，使得組播頻道的媒體流能在AN和EN按IPTV組播業(yè)務(wù)制 定的業(yè)務(wù)等級得到控制處理。
CRPMF 100中的中心資源管理功能從AN 120、EN140實時或定時獲取 全網(wǎng)網(wǎng)絡(luò)資源狀況， 一旦網(wǎng)絡(luò)資源狀況發(fā)生了變化(如網(wǎng)絡(luò)因某種原因壅 塞、發(fā)生鏈路倒換、用戶線路因環(huán)境變化而速率下降等)，中心資源管理功 能可獲得這些信息并通知給策略生成功能，由策略生成功能對業(yè)務(wù)控制策略 進(jìn)行動態(tài)修改。實際應(yīng)用中，中心資源管理功能可以在網(wǎng)絡(luò)的網(wǎng)管中實現(xiàn)， 也可以存在于獨立的CRPMF設(shè)備中。
AN 120和EN 140都是能夠進(jìn)行資源接納控制的通信節(jié)點，具有目前的 AN和EN所不具有的資源接納控制能力。
分布式的AN 120和EN 140,能根據(jù)各自控制區(qū)域的資源狀況和使用 情況，相對獨立地作出各自的IPTV組播業(yè)務(wù)的接納控制。其中，AN 120控
制的資源區(qū)域包括AN及AN以下用戶線環(huán)路部分，EN140控制的資源區(qū)域 包括EN及EN到AN區(qū)間的部分。
具體而言，AN 120可以用目前比較常見的DSLAM實現(xiàn)，AN120可實 現(xiàn)的功能有
(1 )進(jìn)行組播視頻流復(fù)制；
(2) 支持因特網(wǎng)組管理協(xié)議代理(IGMP Proxy)功能，能夠以接收到 的IGMP加入請求報文觸發(fā)AN上的接納控制決策過程；
(3) 實現(xiàn)用戶帳號和端口、媒體訪問控制(MAC) /IP地址之間的綁
定；
(4 )收集分析在AN控制域內(nèi)的業(yè)務(wù)和網(wǎng)絡(luò)資源狀況和使用情況。 (5)對請求業(yè)務(wù)的用戶終端進(jìn)行接納控制決策；
AN 120所能實現(xiàn)的接納控制包括頻道接入權(quán)限控制和AN資源接納控 制；AN資源接納控制包括業(yè)務(wù)資源接納控制、網(wǎng)絡(luò)總資源接納控制。
其中，頻道接入權(quán)限控制，用于判斷是否允許用戶終端加入某個組播頻 道，以及用戶終端已接入的組播頻道總數(shù)是否在策略限定的范圍內(nèi)，并根據(jù) 判斷結(jié)果接受或拒絕用戶終端加入該組播頻道。具體而言，AN 120可以查 找業(yè)務(wù)控制策略中的可接入組播頻道列表，并根據(jù)表中所記錄的用戶終端可 加入的組播頻道，判斷用戶終端是否有權(quán)加入其所請求的組播頻道，如果無 權(quán)，則拒絕用戶終端加入該組播頻道；AN120還可以查詢業(yè)務(wù)控制策略中的 用戶接入頻道策略，比較該用戶終端被允許接入的組播頻道數(shù)量，如果用戶 終端已申請的組播頻道數(shù)量等于該用戶終端被允許接入的組播頻道數(shù)量， AN 120則拒絕用戶終端當(dāng)前的加入組播頻道的請求。
用戶業(yè)務(wù)資源接納控制，用于檢測網(wǎng)絡(luò)分配給AN 120的IPTV組播業(yè)
務(wù)的業(yè)務(wù)資源以及分配給用戶的IPTV組播業(yè)務(wù)的業(yè)務(wù)資源的狀況和使用情
況，并實時判斷檢測到的上述資源中的業(yè)務(wù)可用資源是否足夠用于所新申請
的組播頻道媒體流，再根據(jù)判斷結(jié)果接受或拒絕用戶終端加入組播頻道的請
求。具體而言，如果檢測到的所述業(yè)務(wù)可用資源中有一種或兩種業(yè)務(wù)資源不
夠用于申請組播頻道媒體流，AN 120就拒絕用戶終端加入組播頻道的請求。 網(wǎng)絡(luò)總資源的接納控制，用于檢測AN 120的網(wǎng)絡(luò)總的可用資源和用戶 終端物理線路上網(wǎng)絡(luò)總的可用資源，并判斷檢測到的上述網(wǎng)絡(luò)總的可用資源 是否足夠用于申請組播頻道媒體流，再根據(jù)判斷結(jié)果接受或拒絕用戶終端加 入組播頻道的請求。具體而言，如果檢測到的所述網(wǎng)絡(luò)總的可用資源中有一 種或兩種資源不夠用于申請組播頻道媒體流，AN 120就拒絕用戶終端加入 組播頻道的請求。
在實際應(yīng)用中，AN 120還是IPTV組播業(yè)務(wù)服務(wù)質(zhì)量策略執(zhí)行實體， 可以執(zhí)行目前比較常見的排隊、打標(biāo)簽、優(yōu)先級控制等業(yè)務(wù)QoS策略控制。 與AN 120類似，EN 140同樣具有一定的資源接納控制能力。 在實際組網(wǎng)中，EN 140可以是提供單一業(yè)務(wù)的多個寬帶業(yè)務(wù)邊緣節(jié)點 之一；也可以是提供多個業(yè)務(wù)的寬帶業(yè)務(wù)邊緣節(jié)點。具體而言，EN 140可 以用目前比較常見的寬帶網(wǎng)關(guān)(Broadcast Network Gateway ， BNG )實現(xiàn)， EN 140可實現(xiàn)的功能有
(1 )進(jìn)行組播視頻流復(fù)制；
(2 )支持IGMP Proxy功能，能夠以接收到IGMP報文作為EN資源接 納控制的觸發(fā)；而且，終結(jié)IGMP報文，還可將IGMP轉(zhuǎn)換為組播路由協(xié) 議并發(fā)往Video-SR;
(3) 收集并分析在EN控制域內(nèi)的業(yè)務(wù)資源和網(wǎng)絡(luò)總資源的狀況和使 用情況
(4) 對請求業(yè)務(wù)的用戶終端進(jìn)行資源接納控制；
EN 140所能實現(xiàn)的接納控制是EN資源接納控制，包括業(yè)務(wù)資源接 納控制、網(wǎng)絡(luò)總資源的接納控制。
其中，業(yè)務(wù)資源接納控制，用于檢測EN下行方向針對IPTV業(yè)務(wù)的業(yè) 務(wù)資源的狀況和使用情況，并判斷檢測到的所述業(yè)務(wù)資源中的可用資源是否 足夠用于所申請的組播頻道媒體流，再根據(jù)判斷結(jié)果接受或拒絕用戶終端加 入組播頻道的請求。具體而言，如果檢測到的所述業(yè)務(wù)可用資源不夠用于申
請組播頻道媒體流，EN 140就拒絕用戶終端加入組播頻道的請求。
網(wǎng)絡(luò)總資源接納控制，用于檢測EN 140的網(wǎng)絡(luò)總資源，并判斷檢測到 的網(wǎng)絡(luò)總資源中的可用資源是否足夠用于申請組播頻道媒體流，再根據(jù)判斷 結(jié)果接受或拒絕用戶終端加入組播頻道的請求。具體而言，如果檢測到的 EN 140的網(wǎng)絡(luò)總的可用資源不夠用于申請組播頻道媒體流，EN 140就拒絕 用戶終端加入組播頻道的請求。
在實際應(yīng)用中，EN 140還是QoS策略執(zhí)行實體，可以執(zhí)行目前比4交常 見的排隊、打標(biāo)簽、優(yōu)先級控制等QoS策略控制。通常，可以將AN120、 EN 140所能實現(xiàn)的基于接納控制的業(yè)務(wù)QoS策略控制稱為可保證服務(wù)質(zhì)量 的業(yè)務(wù)策略控制；當(dāng)然，G-QoS業(yè)務(wù)策略控制包含上述業(yè)務(wù)QoS策略控制。 前述的IGMP Proxy功能通常包括以下幾點
(1 )在接納控制允許的情況下，檢查被申請的組播頻道的頻道內(nèi)容是 否已存在于本組播復(fù)制點，如果已存在，就更新組播轉(zhuǎn)發(fā)表，將所述頻道內(nèi) 容復(fù)制到收到組播申請的設(shè)備端口 (對于AN而言是用戶端口 ，對于EN而 言就是相應(yīng)的AN IPTV組播業(yè)務(wù)端口 )；否則，向上一級媒體流復(fù)制點續(xù) 傳用戶終端要加入所述組播頻道的申請。
(2)處理IGMP快速離開報文
收到用戶終端發(fā)送的用于快速離開的消息后，不發(fā)送指定組播頻道的查 詢消息，而是直接停止向用戶終端轉(zhuǎn)發(fā)用戶終端要離開的組播頻道的頻道內(nèi) 容；并且，直到所接入的用戶終端都離開了指定的組播頻道時，才向上一級 媒體流復(fù)制點發(fā)送用于快速離開的所述消息。
IGMP Proxy機(jī)制使得已包含用戶終端所申請的組播頻道的組播流復(fù) 制節(jié)點能夠終結(jié)來自用戶終端的IGMP報文；否則，該組播流復(fù)制節(jié)點則向 上一級媒體流復(fù)制點續(xù)傳所述IGMP報文，以快速建立最短的組播路徑。以 上所述的IGMP Proxy功能是由IGMP Proxy模塊實現(xiàn)的。
需要說明的是AN120和EN140之所以能夠?qū)崿F(xiàn)各自的接納控制，是 因為CRPMF 100能夠根據(jù)IPTV業(yè)務(wù)QoS需求、用戶簽約數(shù)據(jù)和網(wǎng)絡(luò)資源
狀況實時或定時統(tǒng)計情況，動態(tài)生成可保證服務(wù)質(zhì)量的業(yè)務(wù)控制策略并下
發(fā)。AN 120和EN 140收到來自CRPMF 100的業(yè)務(wù)控制策略后，就可以根 據(jù)收到的業(yè)務(wù)控制策略實現(xiàn)包括資源接納控制在內(nèi)的G-QoS策略控制。
并且，AN 120和EN 140還分別實現(xiàn)網(wǎng)絡(luò)資源及拓樸管理功能，以-使通 過網(wǎng)絡(luò)資源及拓樸管理獲知網(wǎng)絡(luò)資源信息，并根據(jù)獲知的網(wǎng)絡(luò)資源信息以及 收到的所述業(yè)務(wù)控制策略進(jìn)行G-QoS策略控制。該網(wǎng)絡(luò)資源信息還被送往 CRPMF 100，做為網(wǎng)絡(luò)資源狀況的實時或定時統(tǒng)計信息，并用于生成業(yè)務(wù)控 制策略或動態(tài)修改已生成的業(yè)務(wù)控制策略。所述網(wǎng)絡(luò)資源及拓樸管理功能是 由網(wǎng)絡(luò)資源及拓樸管理模塊實現(xiàn)的。
再有，為了保證AN 120能夠正確識別IPTV組播業(yè)務(wù)，CRPMF 100通 常需要根據(jù)AN 120所具備的L2、 L3能力生成基于相應(yīng)L2、 L3能力的用戶 業(yè)務(wù)控制策略的配置文件；并將業(yè)務(wù)控制策略以配置文件的形式下發(fā)給AN 120。 AN 120收到并保存來自CRPMF 100的用戶業(yè)務(wù)控制策略的配置文件， 并在后續(xù)的IPTV業(yè)務(wù)控制過程中應(yīng)用保存的配置文件實現(xiàn)G-QoS策略控 制。
AN 120/EN 140中進(jìn)行資源及拓樸管理的功能實體，能夠管理AN 120/EN 140各自控制區(qū)域的網(wǎng)絡(luò)資源，如預(yù)留或釋放資源；還可以在AN 120/EN 140進(jìn)行接納控制決策時提供網(wǎng)絡(luò)資源信息，如IPTV組播業(yè)務(wù)的 業(yè)務(wù)可用資源、AN 120/EN 140的網(wǎng)絡(luò)總的可用資源。當(dāng)然，資源及拓樸管 理功能實體中還可保存并提供用戶終端的拓樸信息等。
具體而言，AN 120的資源及拓樸管理功能實體，能夠管理AN120以及 AN120以下用戶環(huán)路的資源信息，如獲知、更新甚至提供用戶線路上單個 業(yè)務(wù)已用的和可用的資源，和/或用戶線路上可為所有業(yè)務(wù)使用的網(wǎng)絡(luò)總的 資源情況以及已用的、可用的資源。
通常，為AN120進(jìn)行資源及拓樸管理的資源及拓樸管理功能實體，能 檢查出AN 120和用戶終端間的用戶物理環(huán)路隨環(huán)境等因素導(dǎo)致的速率變 化，還能計算出被IPTV組播業(yè)務(wù)或其它業(yè)務(wù)實際耗費掉的資源，并且在可
用資源上表現(xiàn)出來。
EN 140的資源及拓樸管理功能實體，能夠管理EN 140以及EN 140到 AN120區(qū)間的的網(wǎng)絡(luò)資源信息，如獲知、更新甚至提供網(wǎng)絡(luò)拓樸信息和業(yè) 務(wù)資源使用情況，計算出業(yè)務(wù)資源或網(wǎng)絡(luò)總資源剩余的可用資源，還能檢查 出EN 140和AN 120區(qū)間因網(wǎng)絡(luò)故障等原因?qū)е碌木W(wǎng)絡(luò)可用資源的變化。
為了保證使用用戶終端的用戶能夠有較好的用戶體驗，AN 120和EN 140還可以進(jìn)一步支持目前比較常見的IGMP快速離開機(jī)制，以實現(xiàn)頻道的 快速切換。
以上描述用靜態(tài)方式體現(xiàn)出了 AN 120、和EN 140在接納控制方面所能 實現(xiàn)的功能；下面，以動態(tài)方式對IPTV組播業(yè)務(wù)接納控制過程進(jìn)行描述。
在實際應(yīng)用中，用戶可以使用用戶終端向IPTV業(yè)務(wù)運營商注冊，訂購 所需的組播業(yè)務(wù)，包括節(jié)目頻道和節(jié)目質(zhì)量；IPTV運營商會將所訂業(yè)務(wù)所 需的業(yè)務(wù)QoS需求通知CRPMF 100。
當(dāng)用戶要使用用戶終端使用所訂IPTV組播業(yè)務(wù)時，需先進(jìn)行認(rèn)證。在 認(rèn)i正過程中，用戶終端的IP地址、MAC地址、網(wǎng)絡(luò)側(cè)端口等配置信息以及 帳號、用戶接入帶寬、優(yōu)先等級等用戶簽約數(shù)據(jù)均會被網(wǎng)絡(luò)接入運營商和 IPTV業(yè)務(wù)運營商獲得，并會被通知給CRPMF 100。
CRPMF 100可以根據(jù)收到用戶配置信息和簽約數(shù)據(jù)以及接入的網(wǎng)絡(luò)能 力和狀況、業(yè)務(wù)QoS需求，針對該用戶生成可保證服務(wù)質(zhì)量的業(yè)務(wù)控制策 略并下發(fā)給AN 120和EN 140。 AN 120和EN 140則保存來自CRPMF 100 的業(yè)務(wù)控制策略。
在后續(xù)通信過程中，當(dāng)用戶希望收看所訂IPTV業(yè)務(wù)中的某個組播頻道 的節(jié)目時，用戶可以使用用戶終端向AN 120發(fā)送加入頻道請求；AN 120 接收來自用戶終端的加入頻道請求，根據(jù)G-QoS控制策略對用戶終端進(jìn)行 包括接入權(quán)限控制和AN資源接納控制在內(nèi)的接納控制決策過程。當(dāng)然，AN 120進(jìn)行所述接納控制決策過程之前，可以先檢查用戶報文的網(wǎng)絡(luò)端口以及 IP地址、MAC地址是否綁定匹配，如果不匹配，則丟棄該用戶的報文。
實際上，CRPMF 100下發(fā)給AN 120和EN 140的業(yè)務(wù)控制策略中，包 含有AN 120和EN 140用于進(jìn)行資源接納控制的策略；AN 120和EN140可 以從自己的資源及拓樸管理功能實體中獲取業(yè)務(wù)和網(wǎng)絡(luò)總資源可用信息，并 根據(jù)所獲取信息以及保存的業(yè)務(wù)控制策略，對來自用戶終端的頻道加入請求 進(jìn)行資源接納控制。
AN 120進(jìn)行的所述接納控制過程通常為
AN 120對用戶終端進(jìn)行包括頻道接入權(quán)限控制和AN資源接納控制在 內(nèi)的接納控制。具體而言，頻道接入權(quán)限控制包括可接入組播頻道表查詢、 用戶接入頻道策略執(zhí)行；AN資源接納控制包括用戶業(yè)務(wù)資源的接納控制、 網(wǎng)絡(luò)總資源的接納控制。
其中，頻道接入權(quán)限控制
可接入組播頻道表查詢AN 120查找G-QoS業(yè)務(wù)控制策略中的可接入 組播頻道表，并根據(jù)表中所記錄的用戶終端可加入的組播頻道，判斷用戶終 端是否有權(quán)加入其所請求的組播頻道，如果無權(quán)，則拒絕用戶終端加入該組 播頻道。
用戶接入頻道策略執(zhí)行AN 120比較自身記錄的用戶終端已申請的組 播頻道數(shù)量和該用戶終端被允許接入的最大組播頻道數(shù)量，如果用戶終端已 申請的組播頻道數(shù)量等于該用戶終端被允許接入的最大組播頻道數(shù)量，AN 120則拒絕用戶終端當(dāng)前的加入組播頻道的請求。
用戶業(yè)務(wù)資源接納控制AN 120檢測網(wǎng)絡(luò)分配給自身的IPTV組播業(yè) 務(wù)的業(yè)務(wù)資源以及分配給用戶終端的IPTV組播業(yè)務(wù)的業(yè)務(wù)資源，如果才企測 到的所述業(yè)務(wù)資源中的剩余可用資源有一種或兩種已不夠新請求加入組播 頻道的資源所需，AN 120就拒絕用戶終端本次加入組播頻道的請求。
AN側(cè)網(wǎng)絡(luò)總資源接納控制AN 120檢查所控資源區(qū)間的網(wǎng)絡(luò)總資源， 如果檢測到所述網(wǎng)絡(luò)總資源中的剩余可用資源不夠新請求加入的組播頻道 的資源所需，AN 120就拒絕用戶終端加入組播頻道的請求。
在AN 120所進(jìn)行的以上接納控制操作中，頻道接入權(quán)限控制操作由頻200610149971.8
說明書第11/15頁
道接入權(quán)限控制模塊和頻道策略執(zhí)行模塊配合實現(xiàn)。具體而言，頻道接入權(quán) 限控制模塊中設(shè)置有用于進(jìn)行可接入組播頻道表查詢的可接入組播頻道表 查詢模塊，還設(shè)置有用于進(jìn)行用戶接入頻道策略查詢的用戶接入頻道策略查 詢模塊。
當(dāng)可接入組播頻道表查詢模塊、用戶接入頻道策略查詢模塊完成各自的 查詢操作時，分別將查詢結(jié)果(可接入組播頻道表查詢模塊的查詢結(jié)果為用 戶終端可加入的組播頻道，用戶接入頻道策略查詢模塊的查詢結(jié)果為業(yè)務(wù)提 供方規(guī)定的頻道策略，如用戶終端已申請的組播頻道數(shù)量)發(fā)送給頻道策略 執(zhí)行模塊，由頻道策略執(zhí)行模塊根據(jù)自身保存的頻道策略以及收到的查詢結(jié)
果對用戶終端的請求進(jìn)行相應(yīng)處理，如根據(jù)查找到的用戶終端可加入的組 播頻道判斷用戶終端是否有權(quán)加入其所請求的組播頻道，如果無權(quán)，則拒絕 用戶終端加入該組播頻道；比較查找到的用戶終端已申請的組播頻道數(shù)量和 該用戶終端被允許接入的最大組播頻道數(shù)量，如果用戶終端已申請的組播頻 道數(shù)量等于該用戶終端被允許接入的最大組播頻道數(shù)量，則拒絕用戶終端當(dāng) 前的加入組播頻道的請求。
AN資源接納控制操作由AN資源接納控制模塊實現(xiàn)，該模塊中設(shè)置有 用于進(jìn)行用戶業(yè)務(wù)資源接納控制的用戶業(yè)務(wù)資源接納控制模塊，還設(shè)置有用 于進(jìn)行AN側(cè)網(wǎng)絡(luò)總資源接納控制的AN側(cè)網(wǎng)絡(luò)總資源接納控制模塊。
當(dāng)經(jīng)過上述的接入權(quán)限控制和AN資源接納控制之后，如果AN 120沒 有拒絕用戶終端加入組4番頻道的請求，那么AN 120則接受用戶終端加入組 播頻道的請求。
實際使用中
AN 120可以只進(jìn)行AN頻道接入權(quán)限控制中的可接入組播頻道表查詢； AN 120可以只進(jìn)行AN資源控制中的網(wǎng)絡(luò)總資源接納控制。 AN 120對用戶終端完成接納控制決策后，會得到相應(yīng)的接納控制結(jié)果， 即接受或拒絕用戶終端加入組播頻道的請求(如果是拒絕，則包含有拒絕 的原因；AN 120可以將該接納控制結(jié)果發(fā)送給用戶終端。再有，當(dāng)接受了用戶終端加入組播頻道的請求時，AN 120需要將該組 播頻道的頻道內(nèi)容發(fā)送給用戶終端。AN 120的IGMP Proxy模塊需判斷這 是否是它首次從所有用戶終端收到的針對所述組播頻道的加入請求，如果不 是，說明該頻道的媒體流已復(fù)制到AN 120 了， AN 120中的組播復(fù)制模塊 只要將所述媒體流復(fù)制一份到用戶端口就可以了；否則，AN就需向上一級 組播復(fù)制點EN 140轉(zhuǎn)發(fā)用戶終端的加入頻道請求。
收到AN 120轉(zhuǎn)發(fā)的用戶終端的加入頻道請求時，EN 140可以從自身的 資源及拓樸管理功能實體中獲取業(yè)務(wù)和網(wǎng)絡(luò)總資源信息，并根據(jù)所獲取信息 以及保存的業(yè)務(wù)控制策略，對來自用戶終端的頻道加入請求進(jìn)行資源接納控 制。
EN 140進(jìn)行的所述接納控制過程通常為
EN 140對用戶請求進(jìn)行包含EN資源控制在內(nèi)的業(yè)務(wù)策略控制，所述 EN資源控制包括IPTV業(yè)務(wù)資源接納控制、網(wǎng)絡(luò)總資源接納控制。
其中，IPTV業(yè)務(wù)資源接納控制EN 140檢查所控資源區(qū)間的IPTV業(yè) 務(wù)的業(yè)務(wù)資源，如果檢測到的所述業(yè)務(wù)資源中的剩余可用資源不夠新請求加 入的組播頻道的資源所需，EN 140就拒絕用戶終端加入組播頻道的請求。
EN側(cè)網(wǎng)絡(luò)總資源接納控制EN 14 0檢查所控資源區(qū)間的網(wǎng)絡(luò)總的可用 資源，如果檢測到所述網(wǎng)絡(luò)總資源中的剩余可用資源不夠新請求加入的組播 頻道的資源所需，EN 140就拒絕用戶終端加入組播頻道的請求。
EN 140所進(jìn)行的EN資源控制操作由EN資源控制模塊實現(xiàn)，該模塊中 設(shè)置有用于進(jìn)行IPTV業(yè)務(wù)資源接納控制的IPTV業(yè)務(wù)資源接納控制模塊， 還設(shè)置有用于進(jìn)行EN側(cè)網(wǎng)絡(luò)總資源接納控制的EN側(cè)網(wǎng)絡(luò)總資源接納控制 模塊。
當(dāng)經(jīng)過上述的EN資源接納控制之后，如果EN 140沒有拒絕用戶終端 加入組播頻道的請求，那么EN 140則接受用戶終端加入組播頻道的請求。 在實際應(yīng)用中，EN 140可以只進(jìn)行EN資源接納控制中的網(wǎng)絡(luò)總資源接納控制。
E N4 0對用戶終端完成資源接納控制后，會得到相應(yīng)的接納控制結(jié)果， 即接受或拒絕用戶終端加入組播頻道的請求；EN 140可以將該接納控制 結(jié)果通過AN 120發(fā)送給用戶終端。
再有，當(dāng)接受了用戶終端加入組播頻道的請求時，EN 140需要將該組 播頻道的媒體流復(fù)制到對應(yīng)的AN 120的IPTV組播業(yè)務(wù)端口 。具體過程為 EN 140的IGMP Proxy模塊需判斷這是否是它首次從所有AN代理收到的 針對所述組播頻道的加入請求如果不是，說明該頻道的媒體流已復(fù)制到 EN140了， EN 140的組播復(fù)制模塊只要將所述媒體流復(fù)制一份到所述AN 的IPTV組播業(yè)務(wù)端口就可以了；否則，EN 140終結(jié)IGMP報文，以其它 的組播路由報文向IPTV組播業(yè)務(wù)的邊緣路由器Video-SR申請下發(fā)所述的 組播頻道媒體流。
向用戶終端下發(fā)組播頻道媒體流的操作是由組播控制模塊實現(xiàn)的，該組 播控制模塊可以設(shè)置于AN 120、 EN 140等通信實體中。
為了能夠向用戶終端發(fā)送前述的接納控制結(jié)果，需要對目前所應(yīng)用的 IGMP協(xié)議進(jìn)行擴(kuò)展，如增加一種IGMP控制報文類型0x48，作為IGMP 響應(yīng)(Response Inform)報文；通過在0x48類型報文中攜帶接納拒絕結(jié)果 和接納拒絕原因，以表示出用戶終端的加入頻道請求不被接受的原因，如 0x48的接納拒絕原因值取1時代表用戶終端無組播頻道接入權(quán)限；0x48的 接納拒絕原因值取2時代表用戶終端加入的組播頻道超額；0x48的接納拒 絕原因值取3時代表當(dāng)前無法提供足夠的業(yè)務(wù)資源；0x48的接納拒絕原因 值取4時代表當(dāng)前無法提供足夠的網(wǎng)絡(luò)總資源。
針對新增的類型為0x48的所述IGMP響應(yīng)控制報文而言，可以利用用 戶終端的源MAC/IP地址作為該IGMP控制報文的目的地址，并以單播的方 式將該IGMP響應(yīng)控制報文發(fā)送給用戶終端。
如果將圖1所示原理以流程表示，相應(yīng)流程則如圖2所示；圖2為本發(fā) 明 一 較佳實施例的實現(xiàn)資源接納控制的流程圖，該流程包括以下步驟
步驟201:用戶注冊IPTV業(yè)務(wù)，CRPMF模塊生成G-QoS業(yè)務(wù)控制策
略并下發(fā)給AN、 EN。，
步驟202: AN接收來自用戶終端的加入頻道請求，根據(jù)CRPMF模塊 所下發(fā)的G-QoS業(yè)務(wù)控制策略，對用戶終端進(jìn)行包括頻道接入權(quán)限控制和 AN資源接納控制在內(nèi)的接納控制。
步驟203: AN判斷是否向上一級組播復(fù)制點轉(zhuǎn)發(fā)加入頻道請求，如果 是，進(jìn)入步驟205;否則，進(jìn)入步驟204。
步驟204: AN根據(jù)接納控制結(jié)果接受或拒絕用戶終端加入組播頻道的 請求，還可以進(jìn) 一 步將接納控制結(jié)果通知用戶終端。
步驟205: AN向作為上一級組播復(fù)制點的EN轉(zhuǎn)發(fā)加入頻道請求。
步驟206: EN接收來自AN的加入頻道請求，根據(jù)CRPMF模塊所下發(fā) 的G-QoS業(yè)務(wù)控制策略，進(jìn)行EN資源接納控制。
步驟207: EN判斷是否向上一級組播復(fù)制點轉(zhuǎn)發(fā)加入頻道請求，如果 是，進(jìn)入步驟209;否則，進(jìn)入步驟208。
步驟208: EN根據(jù)接納控制結(jié)果接受或拒絕用戶終端加入組播頻道的 請求，還可以進(jìn) 一 步將接納控制結(jié)果通知用戶終端。
步驟209: EN向Video-SR轉(zhuǎn)發(fā)加入頻道請求。
步驟210: Video-SR將來自IPTV業(yè)務(wù)頭端系統(tǒng)160的、用戶終端^"求 加入的組播頻道的頻道內(nèi)容發(fā)送給用戶終端。
由圖2所示步驟可見，與圖1類似，CRPMF模塊與AN, EN相互配合 可以實現(xiàn)對用戶IPTV組播業(yè)務(wù)的接納控制；用戶終端在順利通過所述資源 接納控制后接收其所請求的組播頻道的媒體流，并且該媒體流是按照用戶訂 制的IPTV業(yè)務(wù)所需的業(yè)務(wù)QoS策略發(fā)送給用戶終端的。
后續(xù)如果再有其它用戶終端請求接收組播頻道的頻道內(nèi)容，該用戶終端 仍要接受所述資源接納控制，如果當(dāng)前資源不能滿足該用戶終端的需求，該 用戶終端的請求會被拒絕；之前已通過資源接納控制并接收頻道媒體流的用 戶終端，其接收的頻道媒體流的業(yè)務(wù)質(zhì)量并不會受到影響。顯然，用戶終端 可以被提供可保證的服務(wù)質(zhì)量，這能夠明顯提高用戶滿意度。
在實際應(yīng)用中，可以將IPTV組播業(yè)務(wù)QoS需求、用戶簽約數(shù)據(jù)、網(wǎng)絡(luò)
資源情況中的 一 個或任意多個稱為網(wǎng)絡(luò)通信環(huán)境。
由以上所述可以看出，本發(fā)明實施例所提供的實現(xiàn)分布式接納控制的系 統(tǒng)和方法，使得用戶終端可獲得保證服務(wù)質(zhì)量的IPTV組播業(yè)務(wù)，這能夠明
顯提高用戶滿意度。
權(quán)利要求
1、一種實現(xiàn)分布式接納控制的系統(tǒng)，應(yīng)用于網(wǎng)際協(xié)議電視IPTV組播業(yè)務(wù)，其特征在于，該系統(tǒng)包括中心資源管理和策略生成模塊，用于根據(jù)網(wǎng)絡(luò)通信環(huán)境生成業(yè)務(wù)控制策略，并將生成的業(yè)務(wù)控制策略發(fā)送給接納控制點；接納控制點，用于根據(jù)收到的業(yè)務(wù)控制策略對用戶終端的IPTV組播頻道加入請求進(jìn)行接納控制，并根據(jù)接納控制結(jié)果接受或拒絕用戶終端的IPTV組播頻道加入請求。
2、 如權(quán)利要求l所述的系統(tǒng)，其特征在于，中心資源管理和策略生成^f莫塊 根據(jù)業(yè)務(wù)應(yīng)用的更改請求、網(wǎng)絡(luò)資源、拓樸信息中的至少一種進(jìn)一步用于對生 成的業(yè)務(wù)控制策略進(jìn)行更新。
3、 如權(quán)利要求l所述的系統(tǒng)，其特征在于，所述接納控制點分布在接入節(jié) 點AN和/或接入網(wǎng)邊緣節(jié)點EN。
4、 如權(quán)利要求3所述的系統(tǒng)，其特征在于，所述接納控制點位于AN,該 AN中的接納控制點設(shè)置有用于進(jìn)行所述接納控制的頻道接入權(quán)限控制模塊和 AN資源接納控制模塊；其中，頻道接入權(quán)限控制模塊，用于確定用戶終端是否有權(quán)加入其所請求 的組播頻道；AN資源接納控制模塊，用于確定是否有足夠資源以供用戶終端加入組播 頻道。
5、 如權(quán)利要求3所述的系統(tǒng)，其特征在于，所述接納控制點位于EN,該 EN中的接納控制點設(shè)置有IPTV業(yè)務(wù)資源接納控制模塊和/或EN側(cè)網(wǎng)絡(luò)總資源 接納控制模塊；其中，IPTV業(yè)務(wù)資源接納控制模塊，用于檢查EN所控資源區(qū)間的IPTV 業(yè)務(wù)的業(yè)務(wù)資源，如果檢測到的所述業(yè)務(wù)資源中的剩余可用資源不夠用戶終端 請求加入的組播頻道的資源所需，就拒絕用戶終端加入組播頻道的請求； EN側(cè)網(wǎng)絡(luò)總資源接納控制模塊，用于檢查EN所控資源區(qū)間的網(wǎng)絡(luò)總的可 用資源，如果檢測到所述網(wǎng)絡(luò)總資源中的剩余可用資源不夠用戶終端請求加入 的組播頻道的資源所需，就拒絕用戶終端加入組播頻道的請求。
6、 如權(quán)利要求4所述的系統(tǒng)，其特征在于，所述頻道接入權(quán)限控制模塊中 設(shè)置有可接入組播頻道表查詢模塊和/或用戶接入頻道策略查詢模塊；其中，可接入組播頻道表查詢模塊，用于查找可接入組播頻道表中所記錄 的用戶終端可加入的組播頻道，并將查詢結(jié)果發(fā)送給相連的頻道策略執(zhí)行模塊；用戶接入頻道策略查詢模塊，用于檢查業(yè)務(wù)提供方所規(guī)定的頻道策略，并 將查詢結(jié)果發(fā)送給相連的頻道策略執(zhí)行模塊；頻道策略執(zhí)行模塊，用于根據(jù)自身保存的頻道策略以及收到的查詢結(jié)果對 用戶終端的加入組，潘頻道請求進(jìn)行處理。
7、 如權(quán)利要求4所述的系統(tǒng)，其特征在于，所述AN資源接納控制模塊中 設(shè)置有AN側(cè)網(wǎng)絡(luò)總資源接納控制模塊和/或用戶業(yè)務(wù)資源接納控制模塊；其中，用戶業(yè)務(wù)資源接納控制模塊，用于檢測網(wǎng)絡(luò)分配給AN的IPTV組 播業(yè)務(wù)的業(yè)務(wù)資源以及分配給用戶終端的IPTV組播業(yè)務(wù)的業(yè)務(wù)資源，如果檢 測到的所述業(yè)務(wù)資源中的剩余可用資源有一種或兩種已不夠用戶終端請求加入 組播頻道的資源所需，就拒絕用戶終端本次加入組播頻道的請求；AN側(cè)網(wǎng)絡(luò)總資源接納控制模塊，用于檢查AN所控資源區(qū)間的網(wǎng)絡(luò)總資 源，如果檢測到所述網(wǎng)絡(luò)總資源中的剩余可用資源不夠用戶終端請求加入的組 播頻道的資源所需，就拒絕用戶終端加入組播頻道的請求。
8、 如權(quán)利要求1至7任一項所述的系統(tǒng)，其特征在于，進(jìn)一步在AN和/ 或EN中設(shè)置有網(wǎng)絡(luò)資源及拓樸管理模塊，用于通過網(wǎng)絡(luò)資源及拓樸管理獲知 網(wǎng)絡(luò)資源信息，并將獲知的網(wǎng)絡(luò)資源信息提供給AN、 EN、中心資源管理和策 略生成模塊。
9、 如權(quán)利要求1至7任一項所述的系統(tǒng)，其特征在于，進(jìn)一步設(shè)置因特網(wǎng) 組管理協(xié)議代理IGMP Proxy模塊，用于截獲用戶終端加入組播頻道的請求， 并應(yīng)用該請求觸發(fā)接納控制點進(jìn)行接納控制操作。
10、 如權(quán)利要求9所述的系統(tǒng)，其特征在于，所述IGMP Proxy模塊，進(jìn) 一步用于將進(jìn)行接納控制操作所生成的結(jié)果發(fā)送給用戶終端。
11、 如權(quán)利要求9所述的系統(tǒng)，其特征在于，進(jìn)一步在設(shè)置有所述接納控 制點的AN和/或EN中設(shè)置組播控制模塊，用于向用戶終端下發(fā)其所請求的播 頻道媒體流。
12、 如權(quán)利要求1所述的系統(tǒng)，其特征在于，所述網(wǎng)絡(luò)通信環(huán)境是IPTV 組播業(yè)務(wù)QoS需求、用戶簽約數(shù)據(jù)、網(wǎng)絡(luò)資源情況中的一種或多種。
13、 一種實現(xiàn)分布式接納控制的方法，應(yīng)用于IPTV組播業(yè)務(wù)，其特征在 于，該方法包括根據(jù)網(wǎng)絡(luò)通信環(huán)境生成業(yè)務(wù)控制策略并發(fā)送給接納控制點；接納控制點根 據(jù)收到的業(yè)務(wù)控制策略對用戶終端的IPTV組播頻道加入請求進(jìn)行接納控制， 并根據(jù)接納控制結(jié)果接受或拒絕用戶終端的IPTV組播頻道加入請求。
14、 如權(quán)利要求13所述的方法，其特征在于，生成所述業(yè)務(wù)控制策略的方 法為根據(jù)作為網(wǎng)絡(luò)通信環(huán)境的IPTV組播業(yè)務(wù)QoS需求、用戶簽約數(shù)據(jù)、網(wǎng)絡(luò) 資源情況中的一種或多種，動態(tài)生成IPTV組播業(yè)務(wù)所需的保證服務(wù)質(zhì)量的業(yè) 務(wù)控制策略。
15、 如權(quán)利要求13或14所述的方法，其特征在于，CRPMF根據(jù)業(yè)務(wù)應(yīng)用 的更改請求、網(wǎng)絡(luò)資源、拓樸信息中的至少一種進(jìn)一步更新所述業(yè)務(wù)控制策略。
16、 如權(quán)利要求13所述的方法，其特征在于，進(jìn)行的所述接納控制包括 AN確定用戶終端是否有權(quán)加入其所請求的組播頻道，以及確定是否有足夠資 源以供用戶終端加入組播頻道。
17、 如權(quán)利要求13所述的方法，其特征在于，進(jìn)行的所述接納控制包括 AN確定用戶終端是否有權(quán)加入其所請求的組播頻道，還確定是否有足夠資源以供用戶終端加入組播頻道；并在確定用戶終端有權(quán)加入其所請求的組播 頻道、并且AN資源接納控制模塊確定有足夠資源以供用戶終端加入組播頻道 時，進(jìn)行以下兩種操作中的至少一種檢查EN所控資源區(qū)間的IPTV業(yè)務(wù)的業(yè)務(wù)資源，如果檢測到的所述業(yè)務(wù)資 源中的剩余可用資源不夠用戶終端請求加入的組播頻道的資源所需，就拒絕用 戶終端加入組播頻道的請求；檢查EN所控資源區(qū)間的網(wǎng)絡(luò)總的可用資源，如果檢測到所述網(wǎng)絡(luò)總資源 中的剩余可用資源不夠用戶終端請求加入的組播頻道的資源所需，就拒絕用戶 終端加入組播頻道的請求。
18、 如權(quán)利要求16或17所述的方法，其特征在于，所述確定用戶終端是 否有權(quán)加入其所請求的組播頻道的操作是查找可接入組播頻道表，并根據(jù)表中所記錄的用戶終端可加入的組播頻道， 判斷用戶終端是否有權(quán)加入其所請求的組播頻道，如果無權(quán)，則拒絕用戶終端 加入該組播頻道；所述確定用戶終端是否有權(quán)加入其所請求的組播頻道的操作進(jìn)一步包括 比較用戶終端已申請的組播頻道數(shù)量和該用戶終端被允許接入的最大組播頻道 數(shù)量，如果用戶終端已申請的組播頻道數(shù)量等于該用戶終端被允許接入的最大 組播頻道數(shù)量，則拒絕用戶終端當(dāng)前的加入組播頻道的請求。
19、 如權(quán)利要求16或17所述的方法，其特征在于，所述確定是否有足夠 資源以供用戶終端加入組播頻道的操作，是以下兩種操作中的至少一種檢測網(wǎng)絡(luò)分配給AN的IPTV組播業(yè)務(wù)的業(yè)務(wù)資源以及分配給用戶終端的 IPTV組播業(yè)務(wù)的業(yè)務(wù)資源，如果檢測到的所述業(yè)務(wù)資源中的剩余可用資源有一 種或兩種已不夠用戶終端請求加入組播頻道的資源所需，就拒絕用戶終端本次 加入組播頻道的請求；檢查AN所控資源區(qū)間的網(wǎng)絡(luò)總資源，如果檢測到所述網(wǎng)絡(luò)總資源中的剩 余可用資源不夠用戶終端請求加入的組播頻道的資源所需，就拒絕用戶終端加 入組播頻道的請求。
20、 如權(quán)利要求13、 14、 16或17所述的方法，其特征在于，進(jìn)一步通過 網(wǎng)絡(luò)資源及拓樸管理分別獲知與AN、 EN、生成業(yè)務(wù)控制策略的通信實體相關(guān) 的網(wǎng)絡(luò)資源信息，并將獲知的網(wǎng)絡(luò)資源信息提供給相應(yīng)的AN、 EN的接納控制 點和生成業(yè)務(wù)控制策略的通信實體。
21、 如權(quán)利要求13、 14、 16或17所述的方法，其特征在于，所述接納控 制操作是在截獲到用戶終端加入組播頻道的請求時觸發(fā)的。
22、 如權(quán)利要求13、 14、 16或17所述的方法，其特征在于，在用戶纟冬端 加入組播頻道的請求被接受時，進(jìn)一步以組播方式向用戶終端下發(fā)其所請求的 播頻道i某體流。
23、 如權(quán)利要求13、 14、 16或17所述的方法，其特征在于，進(jìn)一步將進(jìn) 行接納控制操作所生成的結(jié)果發(fā)送給用戶終端。
24、 如權(quán)利要求23所述的方法，其特征在于，所述將進(jìn)行接納控制操作所 生成的結(jié)果發(fā)送給用戶終端的實現(xiàn)方式為以擴(kuò)展IGMP的方式增加作為響應(yīng)信息的IGMP控制報文類型，并在增加 的控制報文中攜帶IGMP頻道加入請求被接受或被拒絕的信息，再將攜帶有所 述信息的IGMP控制報文發(fā)送給用戶終端。
25、 如權(quán)利要求24所述的方法，其特征在于，IGMP頻道加入請求被拒絕 的所述信息中，包含有IGMP頻道加入請求被拒絕的原因信息。
全文摘要
本發(fā)明實施例公開的實現(xiàn)分布式接納控制的系統(tǒng)和方法，均應(yīng)用于網(wǎng)際協(xié)議電視(IPTV)組播業(yè)務(wù)，可由中心資源管理和策略生成(CRPMF)模塊生成業(yè)務(wù)控制策略并發(fā)送給接納控制點；接納控制點根據(jù)收到的業(yè)務(wù)控制策略對用戶終端的IPTV組播頻道加入請求進(jìn)行接納控制，并根據(jù)接納控制結(jié)果接受或拒絕用戶終端的IPTV組播頻道加入請求。本發(fā)明實施例公開的系統(tǒng)和方法，均能為用戶終端提供可保證服務(wù)質(zhì)量的IPTV組播業(yè)務(wù)，可明顯提高用戶滿意度。
文檔編號H04L29/08GK101166194SQ20061014997
公開日2008年4月23日 申請日期2006年10月19日 優(yōu)先權(quán)日2006年10月19日
發(fā)明者宮小玉 申請人:華為技術(shù)有限公司