專(zhuān)利名稱(chēng)：通過(guò)監(jiān)聽(tīng)消息為終端提供組播的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種流媒體業(yè)務(wù)的實(shí)現(xiàn)方法，尤其涉及一種通過(guò)監(jiān)聽(tīng)消息為終端提供組播的方法來(lái)實(shí)現(xiàn)流媒體業(yè)務(wù)。
背景技術(shù)：
流媒體業(yè)務(wù)是從Internet上發(fā)展起來(lái)的一種多媒體應(yīng)用業(yè)務(wù)，流媒體指使用流式傳輸技術(shù)的連續(xù)時(shí)基媒體，如音頻、視頻或多媒體文件。流媒體通信技術(shù)已廣泛應(yīng)用于社會(huì)的各個(gè)行業(yè)、各個(gè)領(lǐng)域，影響著人類(lèi)的生活方式和生活質(zhì)量，尤其在電話(huà)網(wǎng)(包括固定和移動(dòng)電話(huà)網(wǎng))、廣電網(wǎng)、計(jì)算機(jī)網(wǎng)上的應(yīng)用取得了迅猛發(fā)展。在Internet上流媒體技術(shù)廣泛應(yīng)用，如視頻點(diǎn)播、在線(xiàn)影院、遠(yuǎn)程醫(yī)療、遠(yuǎn)程教育、交互式電視等，滿(mǎn)足各個(gè)行業(yè)網(wǎng)絡(luò)化發(fā)展的需要。由于流媒體技術(shù)的目漸成熟、手機(jī)技術(shù)的突破以及移動(dòng)骨干網(wǎng)的擴(kuò)容，給無(wú)線(xiàn)終端帶來(lái)新的機(jī)遇和挑戰(zhàn)，也給用戶(hù)帶來(lái)新的視聽(tīng)感受。
采用單播的方法可以實(shí)現(xiàn)流媒體業(yè)務(wù)，如圖1所示，采用單播的方法實(shí)現(xiàn)流媒體業(yè)務(wù)包括以下步驟步驟100終端點(diǎn)擊流媒體門(mén)戶(hù)上的鏈接，采用HTTP協(xié)議向流媒體門(mén)戶(hù)發(fā)起請(qǐng)求，將包含獲得RTSP鏈接的請(qǐng)求消息發(fā)送給流媒體門(mén)戶(hù)，獲得RTSP(實(shí)時(shí)流協(xié)議)鏈接；步驟101終端發(fā)起建立RTSP連接的請(qǐng)求消息，與流媒體服務(wù)器協(xié)商RTP(實(shí)時(shí)傳輸協(xié)議)端口號(hào)；步驟102終端向流媒體服務(wù)器發(fā)起RTSP會(huì)話(huà)開(kāi)始的請(qǐng)求消息，請(qǐng)求播放流媒體；
步驟103流媒體服務(wù)器用RTP協(xié)議向終端播放流媒體的內(nèi)容；步驟104終端發(fā)起RTSP的會(huì)話(huà)結(jié)束的請(qǐng)求消息，請(qǐng)求終止播放流媒體。
采用單播的方法實(shí)現(xiàn)流媒體業(yè)務(wù)時(shí)，服務(wù)器和客戶(hù)機(jī)之間采用“一對(duì)一”的通訊模式，如果10個(gè)客戶(hù)機(jī)需要相同的數(shù)據(jù)，則服務(wù)器需要逐一傳送，重復(fù)10次相同的工作，由于服務(wù)器針對(duì)每個(gè)客戶(hù)機(jī)發(fā)送數(shù)據(jù)流，則服務(wù)器流量＝客戶(hù)機(jī)數(shù)量×客戶(hù)機(jī)流量；而且網(wǎng)絡(luò)中的交換機(jī)和路由器對(duì)數(shù)據(jù)只進(jìn)行轉(zhuǎn)發(fā)不進(jìn)行復(fù)制，因此在客戶(hù)數(shù)量大、每個(gè)客戶(hù)機(jī)流量大的流媒體應(yīng)用中服務(wù)器不堪重負(fù)。
目前，采用現(xiàn)有的3GPP定義的流媒體廣播組播的方法實(shí)現(xiàn)流媒體業(yè)務(wù)，可以解決上述流媒體應(yīng)用中，采用單播的方法實(shí)現(xiàn)流媒體業(yè)務(wù)時(shí)，服務(wù)器不堪重負(fù)的狀況。采用所述組播的方法實(shí)現(xiàn)流媒體業(yè)務(wù)時(shí)，服務(wù)器將數(shù)據(jù)發(fā)給組，客戶(hù)機(jī)與組之間采用“一對(duì)一組”的通訊模式，也就是加入了同一個(gè)組的客戶(hù)機(jī)可以接受到此組內(nèi)的所有數(shù)據(jù)；而且網(wǎng)絡(luò)中的交換機(jī)和路由器只向有需求者復(fù)制并轉(zhuǎn)發(fā)其所需數(shù)據(jù)?？蛻?hù)機(jī)可以向路由器請(qǐng)求加入或退出某個(gè)組，網(wǎng)絡(luò)中的路由器和交換機(jī)有選擇的復(fù)制并傳輸數(shù)據(jù)，即只將組內(nèi)數(shù)據(jù)傳輸給那些加入組的客戶(hù)機(jī)。這樣既能一次將數(shù)據(jù)傳輸給多個(gè)有需要(加入組)的客戶(hù)機(jī)，又能保證不影響其他不需要(未加入組)的客戶(hù)機(jī)的其他通訊，使需要相同數(shù)據(jù)流的客戶(hù)端加入相同的組共享一條數(shù)據(jù)流，節(jié)省了服務(wù)器的負(fù)載。
如圖2所示為現(xiàn)有的3GPP定義的流媒體廣播組播業(yè)務(wù)的流程，該流程是由業(yè)務(wù)通知1、會(huì)話(huà)開(kāi)始2、MBMS(流媒體廣播組播)通知3、數(shù)據(jù)傳輸4、幾個(gè)步驟組成的。和一般的單播流媒體業(yè)務(wù)不同，3GPP定義的多媒體廣播組播業(yè)務(wù)增加了業(yè)務(wù)通知1、MBMS通知3兩部分，會(huì)話(huà)開(kāi)始2、數(shù)據(jù)傳輸4、兩個(gè)步驟的流程在細(xì)節(jié)上也有較大的不同。
事實(shí)上，3GPP定義的多媒體廣播組播業(yè)務(wù)通過(guò)引入一個(gè)專(zhuān)門(mén)的組播信令信道MICH，能夠?qū)τ脩?hù)進(jìn)行業(yè)務(wù)通知1和MBMS通知3，也可以更好地控制會(huì)話(huà)開(kāi)始2、數(shù)據(jù)傳輸4時(shí)的資源使用。例如，3GPP定義的多媒體廣播組播業(yè)務(wù)能夠通過(guò)網(wǎng)絡(luò)主動(dòng)發(fā)起的MBMS通知流程，計(jì)算同一小區(qū)內(nèi)是否有足夠多的用戶(hù)想收看同一頻道，從而能夠決定使用組播業(yè)務(wù)信道還是多個(gè)單播業(yè)務(wù)信道來(lái)對(duì)這些用戶(hù)進(jìn)行服務(wù)，能夠更為精確地控制無(wú)線(xiàn)網(wǎng)絡(luò)的資源使用。
目前采用現(xiàn)有的3GPP定義的流媒體廣播組播方法實(shí)現(xiàn)流媒體業(yè)務(wù)的業(yè)務(wù)流程存在的缺點(diǎn)是終端和無(wú)線(xiàn)網(wǎng)絡(luò)需要支持專(zhuān)門(mén)的組播信令信道(MICH)，對(duì)終端與無(wú)線(xiàn)網(wǎng)絡(luò)之間的組網(wǎng)改動(dòng)較大。特別是當(dāng)3G網(wǎng)絡(luò)部署以后，對(duì)已投入使用的終端和無(wú)線(xiàn)網(wǎng)絡(luò)進(jìn)行如此大的改動(dòng)幾乎是不可接受的；在流程上與單播流媒體業(yè)務(wù)的流程有較大差別，終端需要實(shí)現(xiàn)兩套不同的流程。

發(fā)明內(nèi)容
本發(fā)明的目的是針對(duì)現(xiàn)有3GPP采用的流媒體廣播組播方法所存在的缺點(diǎn)，提出一種通過(guò)監(jiān)聽(tīng)消息提供組播的方法。該方法兼容早期版本終端和無(wú)線(xiàn)網(wǎng)絡(luò)的在移動(dòng)網(wǎng)絡(luò)提供組播業(yè)務(wù)的方法，在終端和無(wú)線(xiàn)網(wǎng)絡(luò)之間無(wú)需提供專(zhuān)門(mén)的組播信令信道；可以實(shí)現(xiàn)象單播業(yè)務(wù)一樣的點(diǎn)擊播放，用戶(hù)體驗(yàn)良好。
為了實(shí)現(xiàn)上述目的，本發(fā)明提供的一種通過(guò)監(jiān)聽(tīng)消息為終端提供組播的方法，包括以下步驟步驟1終端向網(wǎng)絡(luò)側(cè)的流媒體門(mén)戶(hù)發(fā)送與組播內(nèi)容對(duì)應(yīng)的RTSP鏈接請(qǐng)求消息，所述流媒體門(mén)戶(hù)向所述終端回復(fù)收到該消息的確認(rèn)消息，該終端獲得RTSP鏈接；步驟2所述終端向流媒體服務(wù)器發(fā)送基于所述RTSP鏈接的建立RTSP連接的請(qǐng)求消息；所述流媒體服務(wù)器與所述終端協(xié)商RTP端口號(hào)，并將協(xié)商后的RTP端口確認(rèn)消息回復(fù)到所述終端；步驟3所述終端向所述流媒體服務(wù)器發(fā)送基于所述RTSP鏈接的播放流媒體數(shù)據(jù)的請(qǐng)求消息；所述流媒體服務(wù)器向所述終端回復(fù)確認(rèn)消息；步驟4無(wú)線(xiàn)網(wǎng)絡(luò)控制器通過(guò)監(jiān)聽(tīng)消息，獲取上述步驟2及步驟3中所述終端與所述流媒體服務(wù)器之間傳遞的報(bào)文消息的報(bào)文信息，與所述終端的RTP端口建立組播信道，并向該終端傳輸所述組播內(nèi)容的流媒體數(shù)據(jù)。
上述技術(shù)方案中，由于在所述步驟4中，無(wú)線(xiàn)網(wǎng)絡(luò)控制器通過(guò)監(jiān)聽(tīng)的方式獲取所述終端要接收頻道的編號(hào)的信息，因此，無(wú)線(xiàn)網(wǎng)絡(luò)控制器解析應(yīng)用層報(bào)文，則可以發(fā)現(xiàn)用戶(hù)是否經(jīng)過(guò)認(rèn)證；無(wú)需在早期版本終端和無(wú)線(xiàn)網(wǎng)絡(luò)之間提供專(zhuān)門(mén)的組播信令信道；可以實(shí)現(xiàn)象單播業(yè)務(wù)一樣的點(diǎn)擊播放，用戶(hù)體驗(yàn)良好。
下面通過(guò)附圖和實(shí)施例，對(duì)本發(fā)明的技術(shù)方案做進(jìn)一步的詳細(xì)描述。


圖1為現(xiàn)有采用單播的方法實(shí)現(xiàn)流媒體業(yè)務(wù)的流程圖；圖2為現(xiàn)有采用3GPP定義的流媒體廣播組播方法實(shí)現(xiàn)流媒體業(yè)務(wù)的業(yè)務(wù)流程圖；圖3為本發(fā)明的原理流程圖；圖4為本發(fā)明的一個(gè)具體實(shí)施例的流程圖；圖5為圖4所示實(shí)施例的無(wú)線(xiàn)網(wǎng)絡(luò)控制器將流媒體數(shù)據(jù)傳輸?shù)浇K端的具體過(guò)程的流程圖；圖6為圖5的監(jiān)聽(tīng)操作的流程圖；圖7為圖4所示實(shí)施例的信令傳遞示意圖。
具體實(shí)施例方式
參見(jiàn)圖3，圖3為本發(fā)明的原理流程圖，該流程包括以下步驟步驟200終端點(diǎn)擊流媒體門(mén)戶(hù)上的鏈接，向網(wǎng)絡(luò)側(cè)的流媒體門(mén)戶(hù)發(fā)送與組播內(nèi)容對(duì)應(yīng)的RTSP鏈接請(qǐng)求消息，在所述流媒體門(mén)戶(hù)接收到該請(qǐng)求后，所述流媒體門(mén)戶(hù)向所述終端回復(fù)收到該消息的確認(rèn)消息，該終端獲得RTSP鏈接；
步驟201所述終端向流媒體服務(wù)器發(fā)送基于所述RTSP鏈接的建立RTSP連接的請(qǐng)求消息；所述終端與所述流媒體服務(wù)器協(xié)商RTP端口號(hào)；在所述終端與所述流媒體服務(wù)器進(jìn)行所述協(xié)商后，將協(xié)商后的RTP端口確認(rèn)消息回復(fù)到所述終端，完成與所述終端RTP端口號(hào)的協(xié)商；步驟202所述終端向所述流媒體服務(wù)器發(fā)送基于所述RTSP鏈接的播放流媒體數(shù)據(jù)的請(qǐng)求消息，請(qǐng)求播放流媒體；在所述流媒體服務(wù)器接收到該請(qǐng)求后，所述流媒體服務(wù)器向所述終端回復(fù)收到該請(qǐng)求的確認(rèn)消息；步驟203；無(wú)線(xiàn)網(wǎng)絡(luò)控制器通過(guò)監(jiān)聽(tīng)消息，獲取上述步驟201及步驟202中所述終端與所述流媒體服務(wù)器之間傳遞的報(bào)文消息的報(bào)文信息，獲取所述終端要接收頻道的編號(hào)的信息，與所述終端的RTP端口建立組播信道，并向該終端傳輸所述組播內(nèi)容的流媒體數(shù)據(jù)。
參見(jiàn)圖4、圖7所示，圖4為本發(fā)明的一個(gè)具體實(shí)施例的流程圖，圖7為圖4所示實(shí)施例的信令傳遞示意圖，該實(shí)施例為當(dāng)無(wú)線(xiàn)網(wǎng)絡(luò)控制器為RNC，時(shí)，通過(guò)監(jiān)聽(tīng)消息來(lái)實(shí)現(xiàn)流媒體業(yè)務(wù)，該實(shí)施例的流程包括以下步驟步驟300UE(終端)6點(diǎn)擊流媒體門(mén)戶(hù)上的鏈接，向網(wǎng)絡(luò)側(cè)的Portal(流媒體門(mén)戶(hù))11發(fā)送與組播內(nèi)容對(duì)應(yīng)的RTSP鏈接請(qǐng)求的消息，在Portal11接收到該請(qǐng)求后，該P(yáng)ortal11向UE6回復(fù)收到該消息的確認(rèn)消息，UE6獲得組播內(nèi)容對(duì)應(yīng)的RTSP鏈接；該步驟300中，Portal11將UE6需要接收組播的頻道編號(hào)信息設(shè)置在所述確認(rèn)消息中向UE6回復(fù)發(fā)送；其中，該獲得RTSP鏈接的請(qǐng)求消息為HTTP GET111，該收到該請(qǐng)求的確認(rèn)消息為HTTP200 OK112；步驟301UE6向Server(流媒體服務(wù)器)12發(fā)送基于所述RTSP鏈接的建立RTSP連接的請(qǐng)求消息；UE6與Server12協(xié)商RTP端口號(hào)；在UE6與Server12進(jìn)行所述協(xié)商后，Server12將協(xié)商后的RTP端口確認(rèn)消息回復(fù)到UE6，完成與UE6的RTP端口號(hào)的協(xié)商；
其中，該建立RTSP連接的請(qǐng)求消息為RTSP SETUP211，該確認(rèn)消息為RTSP200 OK212；步驟302UE6向Server12發(fā)送基于所述RTSP鏈接的播放流媒體數(shù)據(jù)的請(qǐng)求消息，請(qǐng)求播放流媒體；在Server12接收到該請(qǐng)求后，向UE6回復(fù)收到該請(qǐng)求的確認(rèn)消息；該步驟302中，UE6將上述步驟300中設(shè)置在所述確認(rèn)消息中所述頻道編號(hào)信息發(fā)送到Server12；其中，該播放請(qǐng)求消息為RTSP PLAY311，該確認(rèn)消息為RTSP200 OK312；步驟303RNC7通過(guò)監(jiān)聽(tīng)消息，獲取上述步驟301及步驟302中UE6與Server12之間傳遞的報(bào)文消息的報(bào)文信息，獲取UE6要接收頻道的編號(hào)的信息，與UE6的RTP端口建立組播信道，并向該UE6傳輸所述組播內(nèi)容的流媒體數(shù)據(jù)；該步驟303中，RNC7將與上述步驟300中，設(shè)置在所述確認(rèn)消息中所述頻道編號(hào)信息對(duì)應(yīng)的組播內(nèi)容的流媒體數(shù)據(jù)傳輸?shù)経E6。
在該實(shí)施例中，參見(jiàn)圖4、圖5、圖7所示，其中，圖5圖4所示實(shí)施例的無(wú)線(xiàn)網(wǎng)絡(luò)控制器將流媒體數(shù)據(jù)傳輸?shù)浇K端的具體過(guò)程的流程圖；RNC7在監(jiān)聽(tīng)所述報(bào)文消息的信息后，將流媒體數(shù)據(jù)傳輸?shù)経E6的具體過(guò)程為步驟3031RNC7通過(guò)監(jiān)聽(tīng)UE6與Server12之間的傳遞的所述報(bào)文消息411，獲取UE6要接收頻道的編號(hào)的信息；步驟3032RNC7根據(jù)所述組播頻道的編號(hào)信息，向UE6發(fā)送將信道更換為與所述組播頻道的編號(hào)信息相對(duì)應(yīng)的組播信道的消息；其中，該消息為Change Channel511；步驟3033UE6更換到所述組播信道，并向RNC7回復(fù)更換組播頻道的確認(rèn)消息，RNC7將與所述組播頻道的編號(hào)信息對(duì)應(yīng)的組播內(nèi)容的流媒體數(shù)據(jù)傳輸?shù)経E6；其中，該更換組播頻道的確認(rèn)消息為Change Channel ACK512。
在該實(shí)施例中，參見(jiàn)圖4、圖5、圖6、圖7所示，其中，圖6為圖5的監(jiān)聽(tīng)操作的流程圖，上述步驟3031具體為步驟3031a源IP地址不同的Server12收到UE6需要接收組播頻道的編號(hào)信息后，將該信息封裝在所述報(bào)文消息中，回復(fù)給UE6；步驟3031bRNC7根據(jù)所述源IP地址，判斷發(fā)送者為提供所述組播頻道的Server12后，獲取所述組播頻道的編號(hào)信息；步驟3031c當(dāng)RNC7監(jiān)聽(tīng)到源IP地址相同的Server12回復(fù)給UE6的報(bào)文消息時(shí)，判斷監(jiān)聽(tīng)到的該報(bào)文消息的次數(shù)是否到兩次，是，執(zhí)行步驟3031d，否，則執(zhí)行步驟3031e；步驟3031d判斷出該報(bào)文消息中包含的所述信息為所述終端需要接收組播頻道的編號(hào)信息；執(zhí)行步驟3031f；步驟3031e繼續(xù)監(jiān)聽(tīng)所述報(bào)文消息；步驟3031f結(jié)束。
上述步驟3031a還可以為Server12收到不同的UE6需要接收組播頻道的編號(hào)信息后，將該信息封裝在所述報(bào)文消息中，使用不同的端口號(hào)將該消息回復(fù)給UE6。
當(dāng)所述無(wú)線(xiàn)網(wǎng)絡(luò)控制器為AN時(shí)，即將圖7中的RNC7的相應(yīng)位置改成AN表示時(shí)，也可采用上述實(shí)施例中的步驟300-步驟303實(shí)現(xiàn)組播。
參見(jiàn)圖4、圖5、圖6、圖7所示，另一個(gè)實(shí)施例為當(dāng)無(wú)線(xiàn)網(wǎng)絡(luò)控制器為RNC，無(wú)線(xiàn)網(wǎng)中的網(wǎng)絡(luò)節(jié)點(diǎn)為GGSN(GPRS網(wǎng)關(guān)節(jié)點(diǎn))9時(shí)，所述GGSN9通過(guò)監(jiān)聽(tīng)消息為UE6提供組播的方法來(lái)實(shí)現(xiàn)組播。
在該實(shí)施例中也可以采用上述實(shí)施例中的步驟300-步驟303的原理來(lái)實(shí)現(xiàn)組播，其中，所述網(wǎng)絡(luò)側(cè)的GGSN9通過(guò)監(jiān)聽(tīng)并將所述報(bào)文信息發(fā)送到RNC7的具體過(guò)程為GGSN9通過(guò)監(jiān)聽(tīng)UE6和Server12之間的所述報(bào)文消息，獲得UE6需要接收組播頻道的編號(hào)信息，將該編號(hào)信息和UE6的標(biāo)識(shí)信息封裝在傳送流媒體的請(qǐng)求消息中，發(fā)送給RNC7。
上述實(shí)施例中的步驟3031b-步驟3031f的所述網(wǎng)絡(luò)節(jié)點(diǎn)通過(guò)監(jiān)聽(tīng)終端和流媒體服務(wù)器之間的所述報(bào)文消息，在本實(shí)施例的具體過(guò)程為GGSN9根據(jù)所述源IP地址判斷發(fā)送者為Server12后，獲取所述組播頻道的編號(hào)信息；當(dāng)GGSN9監(jiān)聽(tīng)到所述源IP地址相同的Server12回復(fù)給UE6的報(bào)文消息時(shí)，判斷監(jiān)聽(tīng)到的該報(bào)文消息的次數(shù)是否到兩次，是，則判斷出該報(bào)文消息中包含的所述信息為UE6需要接收組播頻道的編號(hào)信息；否，則繼續(xù)監(jiān)聽(tīng)所述報(bào)文消息。
在上述實(shí)施例中，當(dāng)所述網(wǎng)絡(luò)節(jié)點(diǎn)為SGSN時(shí)，也可以采用上述實(shí)施例中的步驟300-步驟303的原理來(lái)實(shí)現(xiàn)組播。
上述實(shí)施例中，當(dāng)所述無(wú)線(xiàn)網(wǎng)絡(luò)控制器為AN，即將圖7中的RNC7的相應(yīng)位置改成AN表示時(shí)，且將無(wú)線(xiàn)網(wǎng)中的網(wǎng)絡(luò)節(jié)點(diǎn)SGSN8和GGSN9合并為網(wǎng)絡(luò)節(jié)點(diǎn)GSN10時(shí)，也可以采用上述實(shí)施例中的步驟300-步驟303的原理來(lái)實(shí)現(xiàn)組播。
最后所應(yīng)說(shuō)明的是，以上實(shí)施例僅用以說(shuō)明本發(fā)明的技術(shù)方案而非限制，盡管參照較佳實(shí)施例對(duì)本發(fā)明進(jìn)行了詳細(xì)說(shuō)明，本領(lǐng)域的普通技術(shù)人員應(yīng)當(dāng)理解，可以對(duì)本發(fā)明的技術(shù)方案進(jìn)行修改或者等同替換，而不脫離本發(fā)明技術(shù)方案的精神和范圍。
權(quán)利要求
1.一種通過(guò)監(jiān)聽(tīng)消息為終端提供組播的方法，其特征在于，包括以下步驟步驟1終端向網(wǎng)絡(luò)側(cè)的流媒體門(mén)戶(hù)發(fā)送與組播內(nèi)容對(duì)應(yīng)的RTSP鏈接請(qǐng)求消息，所述流媒體門(mén)戶(hù)向所述終端回復(fù)收到該消息的確認(rèn)消息，該終端獲得RTSP鏈接；步驟2所述終端向流媒體服務(wù)器發(fā)送基于所述RTSP鏈接的建立RTSP連接的請(qǐng)求消息；所述流媒體服務(wù)器與所述終端協(xié)商RTP端口號(hào)，并將協(xié)商后的RTP端口確認(rèn)消息回復(fù)到所述終端；步驟3所述終端向所述流媒體服務(wù)器發(fā)送基于所述RTSP鏈接的播放流媒體數(shù)據(jù)的請(qǐng)求消息；所述流媒體服務(wù)器向所述終端回復(fù)確認(rèn)消息；步驟4無(wú)線(xiàn)網(wǎng)絡(luò)控制器通過(guò)監(jiān)聽(tīng)消息，獲取上述步驟2及步驟3中所述終端與所述流媒體服務(wù)器之間傳遞的報(bào)文消息的報(bào)文信息，與所述終端的RTP端口建立組播信道，并向該終端傳輸所述組播內(nèi)容的流媒體數(shù)據(jù)。
2.根據(jù)權(quán)利要求1所述的通過(guò)監(jiān)聽(tīng)消息為終端提供組播的方法，其特征在于，所述步驟1中，所述流媒體門(mén)戶(hù)將所述終端需要接收組播的頻道編號(hào)信息設(shè)置在所述確認(rèn)消息中向所述終端回復(fù)發(fā)送；所述步驟3中，所述終端將所述頻道編號(hào)信息發(fā)送到所述流媒體服務(wù)器；所述步驟4中，所述無(wú)線(xiàn)網(wǎng)絡(luò)控制器將與所述頻道編號(hào)信息對(duì)應(yīng)的組播內(nèi)容的流媒體數(shù)據(jù)傳輸?shù)剿鼋K端。
3.根據(jù)權(quán)利要求1或2所述的通過(guò)監(jiān)聽(tīng)消息為終端提供組播的方法，其特征在于，所述步驟4中，所述無(wú)線(xiàn)網(wǎng)絡(luò)控制器通過(guò)監(jiān)聽(tīng)所述終端與所述流媒體服務(wù)器之間傳遞的報(bào)文消息獲取所述報(bào)文信息，或者所述網(wǎng)絡(luò)側(cè)的網(wǎng)絡(luò)節(jié)點(diǎn)通過(guò)監(jiān)聽(tīng)所述終端與所述流媒體服務(wù)器之間傳遞的報(bào)文消息，將所述報(bào)文信息發(fā)送到所述無(wú)線(xiàn)網(wǎng)絡(luò)控制器。
4.根據(jù)權(quán)利要求3所述的通過(guò)監(jiān)聽(tīng)消息為終端提供組播的方法，其特征在于，所述無(wú)線(xiàn)網(wǎng)絡(luò)控制器在監(jiān)聽(tīng)所述報(bào)文消息的信息后，將流媒體數(shù)據(jù)傳輸?shù)剿鼋K端的具體過(guò)程為步驟41無(wú)線(xiàn)網(wǎng)絡(luò)控制器監(jiān)聽(tīng)所述終端與所述流媒體服務(wù)器之間傳遞的所述報(bào)文消息，獲取所述終端需要接收組播頻道的編號(hào)信息；步驟42所述無(wú)線(xiàn)網(wǎng)絡(luò)控制器根據(jù)所述組播頻道的編號(hào)信息，向所述終端發(fā)送將信道更換為與所述組播頻道的編號(hào)信息相對(duì)應(yīng)的組播信道的消息；步驟43所述終端更換到所述組播信道，并向所述無(wú)線(xiàn)網(wǎng)絡(luò)控制器回復(fù)更換組播頻道的確認(rèn)消息，聽(tīng)述無(wú)線(xiàn)網(wǎng)絡(luò)控制器將與所述組播頻道的編號(hào)信息對(duì)應(yīng)的組播內(nèi)容的流媒體數(shù)據(jù)傳輸?shù)剿鼋K端。
5.根據(jù)權(quán)利要求3所述的通過(guò)監(jiān)聽(tīng)消息為終端提供組播的方法，其特征在于，所述步驟41具體為步驟411源IP地址不同的所述流媒體服務(wù)器收到所述終端需要接收組播頻道的編號(hào)信息后，將該信息封裝在所述報(bào)文消息中，回復(fù)給所述終端；步驟412所述無(wú)線(xiàn)網(wǎng)絡(luò)控制器根據(jù)所述源IP地址，判斷發(fā)送者為所述流媒體服務(wù)器后，獲取所述組播頻道的編號(hào)信息；當(dāng)所述無(wú)線(xiàn)網(wǎng)絡(luò)控制器監(jiān)聽(tīng)到源IP地址相同的所述流媒體服務(wù)器回復(fù)給所述終端的報(bào)文消息時(shí)，判斷監(jiān)聽(tīng)到的該報(bào)文消息的次數(shù)是否到兩次，是，則判斷出該報(bào)文消息中包含的所述信息為所述終端需要接收組播頻道的編號(hào)信息；否，則繼續(xù)監(jiān)聽(tīng)所述報(bào)文消息。
6.根據(jù)權(quán)利要求5所述的通過(guò)監(jiān)聽(tīng)消息為終端提供組播的方法，其特征在于，所述步驟411為所述流媒體服務(wù)器收到不同的所述終端需要接收組播頻道的編號(hào)信息后，將該信息封裝在所述報(bào)文消息中，使用不同的端口號(hào)將該消息回復(fù)給所述終端。
7.根據(jù)權(quán)利要求3所述的通過(guò)監(jiān)聽(tīng)消息為終端提供組播的方法，其特征在于，所述網(wǎng)絡(luò)側(cè)的網(wǎng)絡(luò)節(jié)點(diǎn)通過(guò)監(jiān)聽(tīng)并將所述報(bào)文信息發(fā)送到所述無(wú)線(xiàn)網(wǎng)絡(luò)控制器的具體過(guò)程為網(wǎng)絡(luò)節(jié)點(diǎn)通過(guò)監(jiān)聽(tīng)終端和流媒體服務(wù)器之間的所述報(bào)文消息，獲得所述終端需要接收組播頻道的編號(hào)信息，將該編號(hào)信息和所述終端的標(biāo)識(shí)信息封裝在傳送流媒體的請(qǐng)求消息中，發(fā)送給所述無(wú)線(xiàn)網(wǎng)絡(luò)控制器。
8.根據(jù)權(quán)利要求7所述的通過(guò)監(jiān)聽(tīng)消息為終端提供組播的方法，其特征在于，所述網(wǎng)絡(luò)節(jié)點(diǎn)通過(guò)監(jiān)聽(tīng)終端和流媒體服務(wù)器之間的所述報(bào)文消息的具體過(guò)程為網(wǎng)絡(luò)節(jié)點(diǎn)根據(jù)所述源IP地址判斷發(fā)送者為所述流媒體服務(wù)器后，獲取所述組播頻道的編號(hào)信息；當(dāng)所述網(wǎng)絡(luò)節(jié)點(diǎn)監(jiān)聽(tīng)到所述源IP地址相同的所述流媒體服務(wù)器回復(fù)給所述終端的報(bào)文消息時(shí)，判斷監(jiān)聽(tīng)到的該報(bào)文消息的次數(shù)是否到兩次，是，則判斷出該報(bào)文消息中包含的所述信息為所述終端需要接收組播頻道的編號(hào)信息；否，則繼續(xù)監(jiān)聽(tīng)所述報(bào)文消息。
全文摘要
本發(fā)明涉及一種通過(guò)監(jiān)聽(tīng)消息為終端提供組播的方法，包括以下步驟終端向網(wǎng)絡(luò)側(cè)的流媒體門(mén)戶(hù)發(fā)送包括與組播內(nèi)容對(duì)應(yīng)的RTSP鏈接請(qǐng)求的消息，終端獲得RTSP鏈接；終端向流媒體服務(wù)器發(fā)送基于RTSP鏈接的建立RTSP連接的請(qǐng)求消息；終端與流媒體服務(wù)器協(xié)商RTP端口號(hào)；終端向流媒體服務(wù)器發(fā)送基于RTSP鏈接的播放流媒體數(shù)據(jù)的請(qǐng)求消息；無(wú)線(xiàn)網(wǎng)絡(luò)控制器獲取所述終端與所述流媒體服務(wù)器之間傳遞的報(bào)文消息的報(bào)文信息，與所述終端的RTP端口建立組播信道，并向該終端傳輸所述組播內(nèi)容的流媒體數(shù)據(jù)。本發(fā)明無(wú)需在早期版本終端和無(wú)線(xiàn)網(wǎng)絡(luò)之間提供專(zhuān)門(mén)的組播信令信道；可以實(shí)現(xiàn)象單播業(yè)務(wù)一樣的點(diǎn)擊播放，用戶(hù)體驗(yàn)良好。
文檔編號(hào)H04L29/06GK101022344SQ200610007498
公開(kāi)日2007年8月22日 申請(qǐng)日期2006年2月14日 優(yōu)先權(quán)日2006年2月14日
發(fā)明者劉鴻, 黃宇紅, 江海濤, 劉京, 黨京, 閻志剛 申請(qǐng)人:中國(guó)移動(dòng)通信集團(tuán)公司