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

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


圖1為現(xiàn)有采用單播的方法實現(xiàn)流媒體業(yè)務(wù)的流程圖；圖2為現(xiàn)有采用3GPP定義的流媒體廣播組播方法實現(xiàn)流媒體業(yè)務(wù)的業(yè)務(wù)流程圖；圖3為本發(fā)明的原理流程圖；圖4為本發(fā)明的一個具體實施例的流程圖；圖5為圖4所示實施例的無線網(wǎng)絡(luò)控制器將流媒體數(shù)據(jù)傳輸?shù)浇K端的具體過程的流程圖；圖6為圖5的服務(wù)器通知RNC組播內(nèi)容的流程圖；圖7為圖4所示實施例的信令傳遞示意圖；圖8為本發(fā)明的另一個具體實施例的信令傳遞示意圖。
具體實施例方式
參見圖3所示，圖3為本發(fā)明的原理流程圖，該流程包括以下步驟步驟200終端點擊流媒體門戶上的鏈接，向網(wǎng)絡(luò)側(cè)的流媒體門戶發(fā)送與組播內(nèi)容對應(yīng)的RTSP鏈接請求消息，在所述流媒體門戶接收到該請求后，所述流媒體門戶向所述終端回復收到該消息的確認消息，該終端獲得RTSP鏈接；步驟201所述終端向流媒體服務(wù)器發(fā)送基于所述RTSP鏈接的建立RTSP連接的請求消息；所述終端與所述流媒體服務(wù)器協(xié)商RTP端口號；在所述終端與所述流媒體服務(wù)器進行所述協(xié)商后，將協(xié)商后的RTP端口確認消息回復到所述終端，完成與所述終端RTP端口號的協(xié)商；步驟202所述終端向所述流媒體服務(wù)器發(fā)送基于所述RTSP鏈接的播放流媒體數(shù)據(jù)的請求消息，請求播放流媒體；在所述流媒體服務(wù)器接收到該請求后，所述流媒體服務(wù)器向所述終端回復收到該請求的確認消息；步驟203所述流媒體服務(wù)器將包含所述組播內(nèi)容的消息發(fā)送給無線網(wǎng)絡(luò)控制器，所述無線網(wǎng)絡(luò)控制器根據(jù)該消息，在所述終端的所述RTP端口與所述無線網(wǎng)絡(luò)控制器之間建立組播信道，并向所述終端傳輸所述流媒體數(shù)據(jù)。
參見圖4、圖7所示，圖4為本發(fā)明的一個具體實施例的流程圖，圖7為圖4所示實施例的信令傳遞示意圖，該實施例為當無線網(wǎng)絡(luò)控制器為RNC時，基于服務(wù)器的播出指令實現(xiàn)組播的流程，該流程包括以下步驟步驟300UE(終端)6點擊流媒體門戶上的鏈接，向網(wǎng)絡(luò)側(cè)的Portal(流媒體門戶)11發(fā)送與組播內(nèi)容對應(yīng)的RTSP鏈接請求的消息，在Portal11接收到該請求后，該Portal11向UE6回復收到該消息的確認消息，UE6獲得組播內(nèi)容對應(yīng)的RTSP鏈接；該步驟300中，Portal11將UE6需要接收組播的頻道編號信息設(shè)置在所述確認消息中向UE6回復發(fā)送；其中，該獲得RTSP鏈接的請求消息為HTTP GET111，該收到該請求的確認消息為HTTP200 OK112；步驟301UE6向Server(流媒體服務(wù)器)12發(fā)送基于所述RTSP鏈接的建立RTSP連接的請求消息；UE6與Server12協(xié)商RTP端口號；在UE6與Server12進行所述協(xié)商后，Server12將協(xié)商后的RTP端口確認消息回復到UE6，完成與UE6的RTP端口號的協(xié)商；其中，該建立RTSP連接的請求消息為RTSP SETUP211，該確認消息為RTSP200 OK212；步驟302UE6向Server12發(fā)送基于所述RTSP鏈接的播放流媒體數(shù)據(jù)的請求消息，請求播放流媒體；在Server12接收到該請求后，向UE6回復收到該請求的確認消息；該步驟302中，UE6將上述步驟300中設(shè)置在所述確認消息中所述頻道編號信息發(fā)送到Server12；其中，該播放請求消息為RTSP PLAY311，該確認消息為RTSP200 OK312；步驟303Server12將包含所述組播內(nèi)容的消息發(fā)送給RNC7，該RNC7根據(jù)該消息，在UE6的所述RTP端口與RNC7之間建立組播信道，并向UE6傳輸所述流媒體數(shù)據(jù)。
該步驟303中，RNC7將與上述步驟300中，設(shè)置在所述確認消息中所述頻道編號信息對應(yīng)的組播內(nèi)容的流媒體數(shù)據(jù)傳輸?shù)経E6。
在該實施例中，參見圖4、圖5、圖6、圖7所示，其中，圖5為圖4所示實施例的無線網(wǎng)絡(luò)控制器將流媒體數(shù)據(jù)傳輸?shù)浇K端的具體過程的流程圖，圖6為圖5的服務(wù)器通知RNC組播內(nèi)容的流程圖。
上述步驟303的Server12將包含所述組播內(nèi)容的消息發(fā)送給RNC7，該RNC7在收到該消息后，將流媒體數(shù)據(jù)傳輸?shù)経E6的具體過程為步驟3031Server12將包含傳送流媒體的請求消息發(fā)送給RNC7，該消息中包含UE6需要接收組播頻道的編號信息，Server12將所述需要接收組播頻道的編號信息通知無線網(wǎng)絡(luò)中的RNC7；該RNC7將所述傳送流媒體的確認消息回復給Server12；其中，該傳送流媒體的請求消息為Multicast Notification411，該確認消息為Multicast Notification412；步驟3032RNC7根據(jù)所述組播頻道的編號信息，向UE6發(fā)送將信道更換為與所述組播頻道的編號信息相對應(yīng)的組播信道的消息；其中，該更換所述組播頻道的消息為Change Channel511；步驟3033UE6更換到所述組播信道，并向RNC7回復更換組播頻道的確認消息，RNC7將與所述組播頻道的編號信息對應(yīng)的的組播內(nèi)容的流媒體數(shù)據(jù)傳輸?shù)経E6；其中，該更換組播頻道的確認消息為Change Channel ACK512。
在該實施例中，所述步驟3031具體為Server12將包含傳送流媒體的請求消息發(fā)送給網(wǎng)絡(luò)節(jié)點，所述網(wǎng)絡(luò)節(jié)點將所述傳送流媒體的確認消息回復給UE6；所述網(wǎng)絡(luò)節(jié)點將包含傳送流媒體的請求消息發(fā)送給RNC7，該RNC7將所述傳送流媒體的確認消息回復給所述網(wǎng)絡(luò)節(jié)點；其中，Server12將包含傳送流媒體的請求消息發(fā)送給無線網(wǎng)的所述網(wǎng)絡(luò)節(jié)點，該網(wǎng)絡(luò)節(jié)點依次為網(wǎng)關(guān)及其下游業(yè)務(wù)支持節(jié)點，該下游業(yè)務(wù)支持節(jié)點將該消息發(fā)送給所述無線網(wǎng)絡(luò)控制器。
在該實施例中，步驟3031中的Server12將包含傳送流媒體的請求消息發(fā)送給RNC7的具體過程為步驟3031aServer12將包含傳送流媒體的請求消息發(fā)送給網(wǎng)關(guān)，該消息中包含UE6需要接收組播頻道的編號信息和UE6的標識信息，所述網(wǎng)關(guān)向Server12回復收到該消息的確認消息；步驟3031b所述網(wǎng)關(guān)將包含傳送流媒體的請求消息發(fā)送給其下游業(yè)務(wù)支持節(jié)點，該下游業(yè)務(wù)支持節(jié)點將該請求消息發(fā)送給RNC7。
參見圖5、圖6、圖8所示，圖8為本發(fā)明另一個具體實施例的信令傳遞示意圖，該實施例為當無線網(wǎng)絡(luò)控制器為RNC，網(wǎng)關(guān)為GGSN(GPRS網(wǎng)關(guān)節(jié)點)9，其下游業(yè)務(wù)支持節(jié)點為SGSN(GPRS業(yè)務(wù)支持節(jié)點)8時，Server12依次通知GGSN9、SGSN8、RNC7來實現(xiàn)組播。
上述實施例流程圖中的步驟3031a在本實施例中具體為Server12將包含傳送流媒體的請求消息發(fā)送給GGSN9，該消息中包含UE6需要接收組播頻道的編號信息和UE6的標識信息，該GGSN9向Server12回復收到該消息的確認消息；其中，該傳送流媒體的請求消息為Multicast Notification421，該確認消息為Multicast Notification ACK422；上述實施例流程圖中的步驟3031b在本實施例中具體為步驟3031bGGSN9將包含傳送流媒體的請求消息發(fā)送給SGSN8，該SGSN8向GGSN9回復收到該消息的確認消息；該SGSN8將該請求消息發(fā)送給RNC7，該RNC7向SGSN8回復收到該消息的確認消息；其中，該傳送流媒體的請求消息分別為第一個Multicast Notification423、第二個Multicast Notification425，該確認消息分別為第一個Multicast Notification ACK424、第二個Multicast Notification ACK426。
上述步驟3031-步驟3033中，UE6的標識信息與GGSN9之間、該GGSN9與SGSN8之間、該SGSN8與RNC7之間配置有相應(yīng)的對應(yīng)關(guān)系。
所述對應(yīng)關(guān)系的配置操作具體為在Server12上配置描述UE6的標識信息與GGSN9之間對應(yīng)關(guān)系的對應(yīng)表；在GGSN9上，配置描述該GGSN9與SGSN8之間對應(yīng)關(guān)系的對應(yīng)表；在該SGSN8上，配置描述該SGSN8與RNC7之間對應(yīng)關(guān)系的對應(yīng)表。
在上述3031-步驟3033中，當Server12將所述請求消息依次發(fā)送給GGSN9及SGSN8，直到RNC7接收到該消息的過程中，UE6的標識信息要根據(jù)所述對應(yīng)表中的對應(yīng)關(guān)系進行轉(zhuǎn)換，轉(zhuǎn)換成SGSN8及RNC7能識別的UE6的標識信息。
上述將UE6的標識信息根據(jù)所述對應(yīng)表中的對應(yīng)關(guān)系，轉(zhuǎn)換成SGSN8及RNC7能識別的UE6的標識信息可以采用以下方式在Server12上配置描述UE6的標識信息與GGSN9之間對應(yīng)關(guān)系的對應(yīng)表，該表可以為

表1UE6的標識信息為其所在的IP地址信息，由于UE6所在的IP地址信息為10.1.2.2，并且其所對應(yīng)的IP地址段為10.1.2.0/24，因此，Server12根據(jù)該地址段信息，先在表1中查詢該地址段信息對應(yīng)的GGSN編號，查到該編號為GGSN1，即GGSN9的編號信息為GGSN1；然后Server12將包含傳送流媒體的請求消息發(fā)送給GGSN9，該請求消息中至少設(shè)置了UE6的IP地址信息及UE6需要接收組播頻道的編號信息；在GGSN9上，配置描述該GGSN9與SGSN8之間對應(yīng)關(guān)系的對應(yīng)表，該表為

表2GGSN9根據(jù)收到的所述請求消息中的UE6的IP地址信息，先在表2中查詢該地址段信息對應(yīng)的SGSN編號，查到該編號為SGSN1，即SGSN8的編號信息為SGSN1；然后GGSN9將包含傳送流媒體的請求消息發(fā)送給SGSN8，該請求消息中至少設(shè)置了UE6的IP地址信息及UE6需要接收組播頻道的編號信息；Server12，該請求消息中至少設(shè)置了UE6的IP地址信息及UE6需要接收組播頻道的編號信息；在SGSN8上，配置描述該SGSN8與RNC7之間對應(yīng)關(guān)系的對應(yīng)表，該表為

表3SGSN8根據(jù)收到的所述請求消息中的UE6的IP地址信息，先在表3中查詢該地址段信息對應(yīng)的IMSI編號和RNC的編號，查到該編號為IMSI2，該RNC的編號為RNC1，即RNC7的編號信息為RNC1；然后SGSN8將包含傳送流媒體的請求消息發(fā)送給所述RNC7，該請求消息中至少設(shè)置了UE6對應(yīng)的IMSI編號信息IMSI2及UE6需要接收組播頻道的編號信息；UE6的標識信息根據(jù)所述對應(yīng)表中的對應(yīng)關(guān)系，經(jīng)過上述一系列轉(zhuǎn)換過程，轉(zhuǎn)換成SGSN8及RNC7能識別的UE6的標識信息。
另一個實施例為當無線網(wǎng)絡(luò)控制器為AN，即將圖6中的RNC7的相應(yīng)位置改成AN表示，且將無線網(wǎng)的網(wǎng)關(guān)GGSN9和其下游業(yè)務(wù)支持節(jié)點SGSN8合并為網(wǎng)絡(luò)節(jié)點GSN10時，也可以使用上述步驟300-步驟303來實現(xiàn)流媒體業(yè)務(wù)。
并且，在該實施例中，上述實施例中的步驟3031具體為Server12將包含多點傳送流媒體的請求消息發(fā)送給GSN10，該消息中至少包含終端的標識和該終端要接收的頻道的編號的信息，GSN10回復確認消息給流媒體服務(wù)器；上述實施例中的步驟3032具體為GSN10進一步將該消息發(fā)送給AN，AN回復確認消息。同樣，基于上述轉(zhuǎn)換的機理，當Server12將所述請求消息發(fā)送給GSN10，直到RNC7接收到該消息的過程中，UE6的標識信息要根據(jù)在GSN上配置的所述對應(yīng)表中的對應(yīng)關(guān)系，進行一定的轉(zhuǎn)換，轉(zhuǎn)換成所述AN能識別的UE6的標識信息。
最后所應(yīng)說明的是，以上實施例僅用以說明本發(fā)明的技術(shù)方案而非限制，盡管參照較佳實施例對本發(fā)明進行了詳細說明，本領(lǐng)域的普通技術(shù)人員應(yīng)當理解，可以對本發(fā)明的技術(shù)方案進行修改或者等同替換，而不脫離本發(fā)明技術(shù)方案的精神和范圍。
權(quán)利要求
1.一種基于服務(wù)器的播出指令提供組播的方法，其特征在于，包括以下步驟步驟1終端向網(wǎng)絡(luò)側(cè)的流媒體門戶發(fā)送與組播內(nèi)容對應(yīng)的RTSP鏈接請求消息，所述流媒體門戶向所述終端回復收到該消息的確認消息，該終端獲得RTSP鏈接；步驟2所述終端向流媒體服務(wù)器發(fā)送基于所述RTSP鏈接的建立RTSP連接的請求消息；所述流媒體服務(wù)器與所述終端協(xié)商RTP端口號，并將協(xié)商后的RTP端口確認消息回復到所述終端；步驟3所述終端向所述流媒體服務(wù)器發(fā)送基于所述RTSP鏈接的播放流媒體數(shù)據(jù)的請求消息；所述流媒體服務(wù)器向所述終端回復確認消息；步驟4所述流媒體服務(wù)器將包含所述組播內(nèi)容的消息發(fā)送給無線網(wǎng)絡(luò)控制器，所述無線網(wǎng)絡(luò)控制器根據(jù)該消息，在所述終端的所述RTP端口與所述無線網(wǎng)絡(luò)控制器之間建立組播信道，并向所述終端傳輸所述流媒體數(shù)據(jù)。
2.根據(jù)權(quán)利要求1所述的基于服務(wù)器的播出指令提供組播的方法，其特征在于，所述步驟1中，所述流媒體門戶將所述終端需要接收組播的頻道編號信息設(shè)置在所述確認消息中向所述終端回復發(fā)送；所述步驟3中，所述終端將所述頻道編號信息發(fā)送到所述流媒體服務(wù)器；所述步驟4中，所述無線網(wǎng)絡(luò)控制器將與所述頻道編號信息對應(yīng)的組播內(nèi)容的流媒體數(shù)據(jù)傳輸?shù)剿鼋K端。
3.根據(jù)權(quán)利要求2所述的基于服務(wù)器的播出指令提供組播的方法，其特征在于，所述流媒體服務(wù)器將包含所述組播內(nèi)容的消息發(fā)送給無線網(wǎng)絡(luò)控制器，無線網(wǎng)絡(luò)控制器在收到該消息后，將流媒體數(shù)據(jù)傳輸?shù)剿鼋K端的具體過程為步驟41所述流媒體服務(wù)器將包含傳送流媒體的請求消息發(fā)送給無線網(wǎng)絡(luò)控制器，該消息中包含所述終端需要接收組播頻道的編號信息；步驟42所述無線網(wǎng)絡(luò)控制器根據(jù)所述組播頻道的編號信息，向所述終端發(fā)送將信道更換為與所述組播頻道的編號信息相對應(yīng)的組播信道的消息；步驟43所述終端更換到所述組播信道，并向所述無線網(wǎng)絡(luò)控制器回復更換組播頻道的確認消息，所述無線網(wǎng)絡(luò)控制器與所述組播頻道的編號信息對應(yīng)的的組播內(nèi)容的流媒體數(shù)據(jù)傳輸?shù)剿鼋K端。
4.根據(jù)權(quán)利要求3所述的基于服務(wù)器的播出指令提供組播的方法，其特征在于，所述步驟41具體為所述流媒體服務(wù)器將包含傳送流媒體的請求消息發(fā)送給網(wǎng)絡(luò)節(jié)點，所述網(wǎng)絡(luò)節(jié)點將所述傳送流媒體的確認消息回復給所述終端；所述網(wǎng)絡(luò)節(jié)點將包含傳送流媒體的請求消息發(fā)送給所述無線網(wǎng)絡(luò)控制器，所述無線網(wǎng)絡(luò)控制器將所述傳送流媒體的確認消息回復給所述網(wǎng)絡(luò)節(jié)點。
5.根據(jù)權(quán)利要求4所述的基于服務(wù)器的播出指令提供組播的方法，其特征在于，所述流媒體服務(wù)器將包含傳送流媒體的請求消息發(fā)送給所述無線網(wǎng)絡(luò)控制器的具體過程為所述流媒體服務(wù)器將包含傳送流媒體的請求消息發(fā)送給無線網(wǎng)的所述網(wǎng)絡(luò)節(jié)點，該網(wǎng)絡(luò)節(jié)點依次為網(wǎng)關(guān)及其下游業(yè)務(wù)支持節(jié)點，該下游業(yè)務(wù)支持節(jié)點將該消息發(fā)送給所述無線網(wǎng)絡(luò)控制器。
6.根據(jù)權(quán)利要求5所述的基于服務(wù)器的播出指令提供組播的方法，其特征在于，所述流媒體服務(wù)器將包含傳送流媒體的請求消息發(fā)送給所述無線網(wǎng)絡(luò)控制器的具體過程為步驟411所述流媒體服務(wù)器將包含傳送流媒體的請求消息發(fā)送給網(wǎng)關(guān)，該消息中包含所述終端需要接收組播頻道的編號信息和所述終端的標識信息，所述網(wǎng)關(guān)向所述流媒體服務(wù)器回復收到該消息的確認消息；步驟412所述網(wǎng)關(guān)將包含傳送流媒體的請求消息發(fā)送給其下游業(yè)務(wù)支持節(jié)點，該下游業(yè)務(wù)支持節(jié)點將該請求消息發(fā)送給無線網(wǎng)絡(luò)控制器。
7.根據(jù)權(quán)利要求6所述的基于服務(wù)器的播出指令提供組播的方法，其特征在于，所述終端的標識信息與所述網(wǎng)關(guān)之間、該網(wǎng)關(guān)與其下游業(yè)務(wù)支持節(jié)點之間、該下游業(yè)務(wù)支持節(jié)點與無線網(wǎng)絡(luò)控制器之間配置有相應(yīng)的對應(yīng)關(guān)系。
8.根據(jù)權(quán)利要求7所述的基于服務(wù)器的播出指令提供組播的方法，其特征在于，所述對應(yīng)關(guān)系的配置操作具體為在所述流媒體服務(wù)器上配置描述所述終端的標識信息與所述網(wǎng)關(guān)之間對應(yīng)關(guān)系的對應(yīng)表；在網(wǎng)關(guān)上，配置描述該網(wǎng)關(guān)與其下游業(yè)務(wù)支持節(jié)點之間對應(yīng)關(guān)系的對應(yīng)表；在該下游業(yè)務(wù)支持節(jié)點上，配置描述該下游業(yè)務(wù)支持節(jié)點與無線網(wǎng)絡(luò)控制器之間對應(yīng)關(guān)系的對應(yīng)表。
9.根據(jù)權(quán)利要求8所述的基于服務(wù)器的播出指令提供組播的方法，其特征在于，在所述步驟4的具體操作中，當所述流媒體服務(wù)器將所述請求消息依次發(fā)送給所述網(wǎng)關(guān)、其下游業(yè)務(wù)支持節(jié)點及無線網(wǎng)絡(luò)控制器時，所述請求消息中的所述終端的標識信息根據(jù)所述對應(yīng)表中的對應(yīng)關(guān)系轉(zhuǎn)換成所述下游業(yè)務(wù)支持節(jié)點及所述無線網(wǎng)絡(luò)控制器能識別的終端的標識信息。
全文摘要
本發(fā)明涉及一種基于服務(wù)器的播出指令提供組播的方法，包括以下步驟終端向網(wǎng)絡(luò)側(cè)的流媒體門戶發(fā)送包括與組播內(nèi)容對應(yīng)的RTSP鏈接請求的消息，終端獲得RTSP鏈接；終端向流媒體服務(wù)器發(fā)送基于RTSP鏈接的建立RTSP連接的請求消息；終端與流媒體服務(wù)器協(xié)商RTP端口號；終端向流媒體服務(wù)器發(fā)送基于RTSP鏈接的播放流媒體數(shù)據(jù)的請求消息；流媒體服務(wù)器將包含所述組播內(nèi)容的消息發(fā)送給無線網(wǎng)絡(luò)控制器，無線網(wǎng)絡(luò)控制器根據(jù)該消息，在終端的RTP端口與無線網(wǎng)絡(luò)控制器之間建立組播信道，并向所述終端傳輸所述流媒體數(shù)據(jù)。本發(fā)明無需在早期版本終端和無線網(wǎng)絡(luò)之間提供專門的組播信令信道；可以實現(xiàn)象單播業(yè)務(wù)一樣的點擊播放，用戶體驗良好。
文檔編號H04N7/24GK101022401SQ200610007500
公開日2007年8月22日 申請日期2006年2月14日 優(yōu)先權(quán)日2006年2月14日
發(fā)明者劉鴻, 黃宇紅, 江海濤, 劉京, 黨京, 閻志剛 申請人:中國移動通信集團公司