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

發(fā)明內(nèi)容
本發(fā)明的目的是針對現(xiàn)有3GPP采用的流媒體廣播組播方法所存在的缺點(diǎn)，提出一種基于終端發(fā)起的請求信息提供組播的方法，該方法兼容早期版本終端和無線網(wǎng)絡(luò)的在移動(dòng)網(wǎng)絡(luò)提供組播業(yè)務(wù)的方法，在終端和無線網(wǎng)絡(luò)之間無需提供專門的組播信令信道；可以實(shí)現(xiàn)象單播業(yè)務(wù)一樣的點(diǎn)擊播放，用戶體驗(yàn)良好。
為了實(shí)現(xiàn)上述目的，本發(fā)明提供的一種基于終端發(fā)起的請求信息提供組播的方法，包括以下步驟步驟1終端向網(wǎng)絡(luò)側(cè)的流媒體門戶發(fā)送與組播內(nèi)容對應(yīng)的RTSP鏈接請求消息，所述流媒體門戶向所述終端回復(fù)收到該消息的確認(rèn)消息，該終端獲得RTSP鏈接；步驟2所述終端向流媒體服務(wù)器發(fā)送基于所述RTSP鏈接的建立RTSP連接的請求消息；所述流媒體服務(wù)器與所述終端協(xié)商RTP端口號，并將協(xié)商后的RTP端口確認(rèn)消息回復(fù)到所述終端；步驟3所述終端向所述流媒體服務(wù)器發(fā)送基于所述RTSP鏈接的播放流媒體數(shù)據(jù)的請求消息；所述流媒體服務(wù)器向所述終端回復(fù)確認(rèn)消息；步驟4所述終端將包含所述組播內(nèi)容的消息發(fā)送給無線網(wǎng)絡(luò)中的無線網(wǎng)絡(luò)控制器，所述無線網(wǎng)絡(luò)控制器根據(jù)該消息，在所述終端的所述RTP端口與所述無線網(wǎng)絡(luò)控制器之間建立組播信道，并向所述終端傳輸所述流媒體數(shù)據(jù)。
上述技術(shù)方案中，由于通過步驟4中的所述終端將包含所述組播內(nèi)容的消息發(fā)送給無線網(wǎng)絡(luò)中的無線網(wǎng)絡(luò)控制器，從而導(dǎo)致發(fā)送的消息數(shù)較少，經(jīng)過的節(jié)點(diǎn)數(shù)也較少，因此消息時(shí)延較短，故障率也較低，這樣從點(diǎn)擊到播放的會(huì)話建立時(shí)延較短，頻道切換的時(shí)延也較短，用戶感受較好，無需在早期版本終端和無線網(wǎng)絡(luò)之間提供專門的組播信令信道；實(shí)現(xiàn)象單播業(yè)務(wù)一樣的點(diǎn)擊播放，用戶體驗(yàn)良好。
下面通過附圖和實(shí)施例，對本發(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ǎng)絡(luò)控制器將流媒體數(shù)據(jù)傳輸?shù)浇K端的具體過程的流程圖；圖6為圖4所示實(shí)施例的信令傳遞示意圖；圖7為本發(fā)明另一個(gè)具體實(shí)施例的信令傳遞示意圖。
具體實(shí)施例方式
參見圖3所示，圖3為本發(fā)明的原理流程圖，該流程包括以下步驟步驟200終端點(diǎn)擊流媒體門戶上的鏈接，向網(wǎng)絡(luò)側(cè)的流媒體門戶發(fā)送與組播內(nèi)容對應(yīng)的RTSP鏈接請求消息，在所述流媒體門戶接收到該請求后，所述流媒體門戶向所述終端回復(fù)收到該消息的確認(rèn)消息，該終端獲得RTSP鏈接；步驟201所述終端向流媒體服務(wù)器發(fā)送基于所述RTSP鏈接的建立RTSP連接的請求消息；所述終端與所述流媒體服務(wù)器協(xié)商RTP端口號；在所述終端與所述流媒體服務(wù)器進(jìn)行所述協(xié)商后，將協(xié)商后的RTP端口確認(rèn)消息回復(fù)到所述終端，完成與所述終端RTP端口號的協(xié)商；步驟202所述終端向所述流媒體服務(wù)器發(fā)送基于所述RTSP鏈接的播放流媒體數(shù)據(jù)的請求消息，請求播放流媒體；在所述流媒體服務(wù)器接收到該請求后，所述流媒體服務(wù)器向所述終端回復(fù)收到該請求的確認(rèn)消息；步驟203所述終端將包含所述組播內(nèi)容的消息發(fā)送給無線網(wǎng)絡(luò)中的無線網(wǎng)絡(luò)控制器，所述無線網(wǎng)絡(luò)控制器根據(jù)該消息，在所述終端的所述RTP端口與所述無線網(wǎng)絡(luò)控制器之間建立組播信道，并向所述終端傳輸所述流媒體數(shù)據(jù)。
參見圖4、圖6所示，圖4為本發(fā)明的一個(gè)具體實(shí)施例的流程圖，圖6為圖4所示實(shí)施例的信令傳遞示意圖，該實(shí)施例為當(dāng)無線網(wǎng)絡(luò)控制器為RNC時(shí)，基于終端發(fā)起的請求信息實(shí)現(xiàn)組播的流程，該流程包括以下步驟步驟300UE(終端)6點(diǎn)擊流媒體門戶上的鏈接，向網(wǎng)絡(luò)側(cè)的Portal(流媒體門戶)11發(fā)送包括與組播內(nèi)容對應(yīng)的RTSP鏈接請求的消息，在Portal11接收到該請求后，該P(yáng)ortal11向UE6回復(fù)收到該消息的確認(rèn)消息，UE6獲得組播內(nèi)容對應(yīng)的RTSP鏈接；該步驟300中，Portal11將UE6需要接收組播的頻道編號信息設(shè)置在所述確認(rèn)消息中向UE6回復(fù)發(fā)送；其中，該獲得RTSP鏈接的請求消息為HTTP GET111，該收到該請求的確認(rèn)消息為HTTP200 OK112；步驟301UE6向Server(流媒體服務(wù)器)12發(fā)送基于所述RTSP鏈接的建立RTSP連接的請求消息；UE6與Server12協(xié)商RTP端口號；在UE6與Server12進(jìn)行所述協(xié)商后，Server12將協(xié)商后的RTP端口確認(rèn)消息回復(fù)到UE6，完成與UE6的RTP端口號的協(xié)商；其中，該建立RTSP連接的請求消息為RTSP SETUP211，該確認(rèn)消息為RTSP200 OK212；步驟302UE6向Server12發(fā)送基于所述RTSP鏈接的播放流媒體數(shù)據(jù)的請求消息，請求播放流媒體；在Server12接收到該請求后，向UE6回復(fù)收到該請求的確認(rèn)消息；其中，該播放請求消息為RTSP PLAY311，該確認(rèn)消息為RTSP200 0K312；步驟303UE6將包含所述組播內(nèi)容的消息發(fā)送給無線網(wǎng)絡(luò)中的RNC7，該RNC7根據(jù)該消息，在UE6的所述RTP端口與RNC7之間建立組播信道，并向UE6傳輸所述流媒體數(shù)據(jù)。
該步驟303中，所述RNC7將與上述步驟300中，設(shè)置在所述確認(rèn)消息中所述頻道編號信息對應(yīng)的組播內(nèi)容的流媒體數(shù)據(jù)傳輸?shù)経E6。
在該實(shí)施例中，參見圖4、圖5、圖6所示，其中，圖5為圖4所示實(shí)施例的無線網(wǎng)絡(luò)控制器將流媒體數(shù)據(jù)傳輸?shù)浇K端的具體過程的流程圖。
上述步驟303的UE6將包含所述組播內(nèi)容的消息發(fā)送給RNC7，該RNC7在收到該消息后，將流媒體數(shù)據(jù)傳輸?shù)経E6的具體過程為步驟303aUE6將包含傳送流媒體的請求消息發(fā)送給RNC7，該消息中包含UE6需要接收組播頻道的編號信息，UE6將所述需要接收組播頻道的編號信息通知無線網(wǎng)絡(luò)中的RNC7；其中，該傳送流媒體的請求消息為Multicast Notification411；步驟303bRNC7根據(jù)所述組播頻道的編號信息，向UE6發(fā)送將信道更換為與所述組播頻道的編號信息相對應(yīng)的組播信道的消息；其中，該更換所述組播頻道的消息為Change Channel511；步驟303cUE6更換到所述組播信道，并向RNC7回復(fù)更換組播頻道的確認(rèn)消息，RNC7將與所述頻道編號信息對應(yīng)的組播內(nèi)容的流媒體數(shù)據(jù)傳輸?shù)経E6；其中，該更換組播頻道的確認(rèn)消息為Change Channel ACK512。
當(dāng)所述無線網(wǎng)絡(luò)控制器為AN時(shí)，即將圖5中的RNC7的相應(yīng)位置改成AN表示時(shí)，也可采用上述實(shí)施例中的步驟300-步驟303實(shí)現(xiàn)組播。
參見圖5、圖7所示，其中，圖7為本發(fā)明另一個(gè)具體實(shí)施例的信令傳遞示意圖，該實(shí)施例為當(dāng)無線網(wǎng)絡(luò)控制器為RNC，無線網(wǎng)中的網(wǎng)絡(luò)節(jié)點(diǎn)為SGSN(GPRS業(yè)務(wù)支持節(jié)點(diǎn))8、GGSN(GPRS網(wǎng)關(guān)節(jié)點(diǎn))9時(shí)，UE6通知SGSN8，SGSN8通知RNC7來實(shí)現(xiàn)組播。
在該實(shí)施例中，上述實(shí)施例流程圖中的步驟303a具體為UE6將包含傳送流媒體的請求消息發(fā)送給SGSN8；該SGSN8將所述傳送流媒體的確認(rèn)消息回復(fù)給UE6；SGSN8將包含傳送流媒體的請求消息發(fā)送給RNC7，該RNC7將所述傳送流媒體的確認(rèn)消息回復(fù)給SGSN8。
其中，所述傳送流媒體的請求消息分別為第一個(gè)MulticastNotification421、第二個(gè)Multicast Notification423，該確認(rèn)消息分別為第一個(gè)Multicast Notification ACK422、第二個(gè)Multicast NotificationACK424。
UE6將其標(biāo)識信息和需要接收的組播頻道的編號信息設(shè)置在所述傳送流媒體的請求消息中，發(fā)送給SGSN8，即該傳送流媒體的請求消息中不僅包含所述的標(biāo)識信息，而且還包含UE6需要接收的所述組播頻道的編號信息，以便使RNC7知道UE6對應(yīng)的需要接收所述組播頻道的編號信息。
UE6的標(biāo)識信息與UE6需要接收組播頻道的編號信息之間為一一對應(yīng)的關(guān)系。
基于上述實(shí)施例流程圖中的步驟303b，RNC7根據(jù)UE6的標(biāo)識信息與所述組播頻道的編號信息之間對應(yīng)的關(guān)系，向UE6發(fā)送將信道更換為與所述組播頻道的編號信息相對應(yīng)的組播信道的消息。
當(dāng)所述無線網(wǎng)絡(luò)控制器為AN，即將圖7中的RNC7的相應(yīng)位置改成AN表示時(shí)，且將無線網(wǎng)中的網(wǎng)絡(luò)節(jié)點(diǎn)SGSN8和GGSN9合并為網(wǎng)絡(luò)節(jié)點(diǎn)GSN10時(shí)，終端通知GSN10，GSN10通知AN也可以結(jié)合圖5和圖7所示的實(shí)施例來實(shí)現(xiàn)組播。
最后所應(yīng)說明的是，以上實(shí)施例僅用以說明本發(fā)明的技術(shù)方案而非限制，盡管參照較佳實(shí)施例對本發(fā)明進(jìn)行了詳細(xì)說明，本領(lǐng)域的普通技術(shù)人員應(yīng)當(dāng)理解，可以對本發(fā)明的技術(shù)方案進(jìn)行修改或者等同替換，而不脫離本發(fā)明技術(shù)方案的精神和范圍。
權(quán)利要求
1.一種基于終端發(fā)起的請求信息提供組播的方法，其特征在于，包括以下步驟步驟1終端向網(wǎng)絡(luò)側(cè)的流媒體門戶發(fā)送與組播內(nèi)容對應(yīng)的RTSP鏈接請求消息，所述流媒體門戶向所述終端回復(fù)收到該消息的確認(rèn)消息，該終端獲得RTSP鏈接；步驟2所述終端向流媒體服務(wù)器發(fā)送基于所述RTSP鏈接的建立RTSP連接的請求消息；所述流媒體服務(wù)器與所述終端協(xié)商RTP端口號，并將協(xié)商后的RTP端口確認(rèn)消息回復(fù)到所述終端；步驟3所述終端向所述流媒體服務(wù)器發(fā)送基于所述RTSP鏈接的播放流媒體數(shù)據(jù)的請求消息；所述流媒體服務(wù)器向所述終端回復(fù)確認(rèn)消息；步驟4所述終端將包含所述組播內(nèi)容的消息發(fā)送給無線網(wǎng)絡(luò)中的無線網(wǎng)絡(luò)控制器，所述無線網(wǎng)絡(luò)控制器根據(jù)該消息，在所述終端的所述RTP端口與所述無線網(wǎng)絡(luò)控制器之間建立組播信道，并向所述終端傳輸所述流媒體數(shù)據(jù)。
2.根據(jù)權(quán)利要求1所述的基于終端發(fā)起的請求信息提供組播的方法，其特征在于，所述步驟1中，所述流媒體門戶將所述終端需要接收組播的頻道編號信息設(shè)置在所述確認(rèn)消息中向所述終端回復(fù)發(fā)送；所述步驟4中，所述無線網(wǎng)絡(luò)控制器將與所述頻道編號信息對應(yīng)的組播內(nèi)容的流媒體數(shù)據(jù)傳輸?shù)剿鼋K端。
3.根據(jù)權(quán)利要求2所述的基于終端發(fā)起的請求信息提供組播的方法，其特征在于，所述終端將包含所述組播內(nèi)容的消息發(fā)送給無線網(wǎng)絡(luò)控制器，無線網(wǎng)絡(luò)控制器在收到該消息后，將流媒體數(shù)據(jù)傳輸?shù)剿鼋K端的具體過程為步驟41所述終端將包含傳送流媒體的請求消息發(fā)送給所述無線網(wǎng)絡(luò)控制器，該消息中包含所述終端需要接收組播頻道的編號信息；步驟42所述無線網(wǎng)絡(luò)控制器根據(jù)所述組播頻道的編號信息，向所述終端發(fā)送將信道更換為與所述組播頻道的編號信息相對應(yīng)的組播信道的消息；步驟43所述終端更換到所述組播信道，并向所述無線網(wǎng)絡(luò)控制器回復(fù)更換組播頻道的確認(rèn)消息，所述無線網(wǎng)絡(luò)控制器將與所述組播頻道的編號信息對應(yīng)的組播內(nèi)容的流媒體數(shù)據(jù)傳輸?shù)剿鼋K端。
4.根據(jù)權(quán)利要求3所述的基于終端發(fā)起的請求信息提供組播的方法，其特征在于，所述步驟41具體為所述終端將包含傳送流媒體的請求消息發(fā)送給所述網(wǎng)絡(luò)節(jié)點(diǎn)，所述網(wǎng)絡(luò)節(jié)點(diǎn)將所述傳送流媒體的確認(rèn)消息回復(fù)給所述終端；所述網(wǎng)絡(luò)節(jié)點(diǎn)將包含傳送流媒體的請求消息發(fā)送給所述無線網(wǎng)絡(luò)控制器，所述無線網(wǎng)絡(luò)控制器將所述傳送流媒體的確認(rèn)消息回復(fù)給所述網(wǎng)絡(luò)節(jié)點(diǎn)。
5.根據(jù)權(quán)利要求4所述的基于終端發(fā)起的請求信息提供組播的方法，其特征在于，所述終端將該終端的標(biāo)識信息和需要接收的組播頻道的編號信息設(shè)置在所述傳送流媒體的請求消息中，發(fā)送給所述網(wǎng)絡(luò)節(jié)點(diǎn)。
6.根據(jù)權(quán)利要求5所述的基于終端發(fā)起的請求信息提供組播的方法，其特征在于，所述終端的標(biāo)識信息與所述終端需要接收組播頻道的編號信息之間為一一對應(yīng)的關(guān)系。
7.根據(jù)權(quán)利要求6所述的基于終端發(fā)起的請求信息提供組播的方法，其特征在于，所述步驟42中，所述無線網(wǎng)絡(luò)控制器根據(jù)所述終端的標(biāo)識信息與所述組播頻道的編號信息之間對應(yīng)的關(guān)系，向所述終端發(fā)送將信道更換為與所述組播頻道的編號信息相對應(yīng)的組播信道的消息。
全文摘要
本發(fā)明涉及一種基于終端發(fā)起的請求信息提供組播的方法，其特征在于，包括以下步驟終端向網(wǎng)絡(luò)側(cè)的流媒體門戶發(fā)送包括與組播內(nèi)容對應(yīng)的RTSP鏈接請求的消息，終端獲得RTSP鏈接；終端向流媒體服務(wù)器發(fā)送基于RTSP鏈接的建立RTSP連接的請求消息；終端與流媒體服務(wù)器協(xié)商RTP端口號；終端向流媒體服務(wù)器發(fā)送基于RTSP鏈接的播放流媒體數(shù)據(jù)的請求消息；終端將包含所述組播內(nèi)容的消息發(fā)送給無線網(wǎng)絡(luò)中的無線網(wǎng)絡(luò)控制器，無線網(wǎng)絡(luò)控制器根據(jù)該消息，在終端的RTP端口與網(wǎng)絡(luò)節(jié)點(diǎn)之間建立組播信道，并向所述終端傳輸所述流媒體數(shù)據(jù)。本發(fā)明無需在早期版本終端和無線網(wǎng)絡(luò)之間提供專門的組播信令信道；可以實(shí)現(xiàn)象單播業(yè)務(wù)一樣的點(diǎn)擊播放，用戶體驗(yàn)良好。
文檔編號H04L12/00GK101022345SQ200610007499
公開日2007年8月22日 申請日期2006年2月14日 優(yōu)先權(quán)日2006年2月14日
發(fā)明者劉鴻, 黃宇紅, 江海濤, 劉京, 黨京, 閻志剛 申請人:中國移動(dòng)通信集團(tuán)公司