專利名稱：組播數(shù)據(jù)的傳送的制作方法
技術領域：
本發(fā)明涉及用于傳送組播數(shù)據(jù)的方法和設備。具體地，本發(fā)明涉及通過其中一些節(jié)點不支持組播數(shù)據(jù)路由的網絡來傳送IP組播數(shù)據(jù)。
背景技術：
IP組播是一種用于從源高效地將IP內容傳送至終端用戶(“客戶端”)的機制。 IP組播與單播(一對一傳送)和廣播(一對全部傳送)的區(qū)別在于，它利用了基于網絡的 組播路由器(MC)來將單一輸入IP流分發(fā)至一組客戶端和/或屬于給定組播組的其他MC。 IP組播被認為是一種用于傳送如IP電視(IPTV)之類需要大量帶寬的服務的優(yōu)秀技術。IP組播的關鍵概念之一是組播組地址。希望接收組播內容的客戶端可以通過因特 網組管理協(xié)議(IGMP)加入IP組播組，以向上游MC注冊。MC自身一般使用協(xié)議獨立組播 (PIM)來建立分級結構的組播分發(fā)樹。然后，發(fā)送方可以簡單地向IP組播組地址發(fā)送分組， 使得該組中注冊的所有客戶端可以接收這些分組。在多媒體域中，大多數(shù)時候多媒體內容 被成幀為實時協(xié)議(RTP)分組，RTP分組在要組播傳送的用戶數(shù)據(jù)報協(xié)議(UDP)上層運行。IP電視(IPTV)是允許通過IP網絡傳送電視的多種服務的名稱。由于IP網絡的 靈活性，IPTV將允許針對用戶的更加個性化的服務，例如視頻點播，其中，信息通過單播或 組播IP流傳送給用戶。當前，控制這些流的主要方式是使用在IETF RFC 2326中定義的實 時流傳輸協(xié)議(RTSP)。RTSP未指定傳輸協(xié)議，但是可以例如用于建立和控制RTP媒體流。 RTSP在許多方面類似于用于通過因特網請求和交換信息的HTTP協(xié)議，但是定制用于對如 音頻和視頻之類的媒體進行流傳輸。RTSP允許客戶端向流傳輸服務器請求特定媒體流，并 指定了如PLAY和PAUSE之類的命令。RTSP本身不傳送連續(xù)流，而是控制流傳輸服務器進行 傳送。因此，RTSP支持單播或組播模式，這一選擇取決于網絡目的地址。在單播模式中， 媒體被發(fā)送至所請求的目的地和客戶端選擇的端口號。在組播模式中，向特定組播地址發(fā) 送服務器組播數(shù)據(jù)。組播IP地址和端口信息可以由服務器或客戶端來決定。對于數(shù)據(jù)傳送，多數(shù)實時媒體使用RTP作為傳輸協(xié)議，盡管RTSP并不與RTP捆綁。 RTP提供了端到端傳送服務，用于具有實時特性的流傳送，RTP由兩個部分組成。RTP承載 具有實時特性的數(shù)據(jù)，而RTP控制協(xié)議(RTCP)在正在進行的會話中監(jiān)控服務質量并傳遞信 肩、ο預期移動終端(如移動電話)的用戶希望使用IPTV服務。確實，這可能對于當前 正在安裝高容量蜂窩網絡(如3G網絡)的網絡運營商的商業(yè)模型而言很關鍵。移動TV為 移動屏幕提供了 TV服務，但是多于移至小屏幕的傳統(tǒng)TV。它向用戶提供了在任何時間任 何地點觀看TV內容的自由。除了觀看直播TV頻道和視頻剪輯之外，移動TV還提供了比傳 統(tǒng)TV更多的交互式TV體驗，如投票和聊天。隨著移動TV使用的增長，可以將蜂窩網絡升 級為滿足大量市場需求。當前，移動TV是經由通過點對點連接的流傳輸技術來提供的。在這種情況下，數(shù)據(jù)分組被發(fā)送至單一目的地。移動TV的大規(guī)模市場部署將需要點對多點連接的新網絡能力。這需要網絡和移動終端的支持。使用點對多點連接，可以同時向多個目的地發(fā)送數(shù)據(jù) 分組。圖1和2示意了蜂窩網絡中一個TV頻道的數(shù)據(jù)分組的單播(點對點)和組播(點 對多點)傳送。圖1是使用單播分組傳送TV頻道的網絡的單元的示意表示。移動TV提供 器101穿過骨干網向網關GPRS支持節(jié)點(GGSN) 102發(fā)送分組。GGSN標識訂閱TV頻道的用 戶的地址和位置，并將分組轉發(fā)至各個服務GPRS支持節(jié)點(SGSN) 103、104。SGSN 103、104 通過無線網絡105、106、107向使用移動終端111-118的終端用戶路由分組。每個終端用戶 需要其自身的數(shù)據(jù)流，因此必須從移動TV提供器101發(fā)送8個流，從GGSN 102向每個SGSN 103、104發(fā)送4個流。多個數(shù)據(jù)流被發(fā)送入每個無線網絡105-106?？梢哉J識到，這導致了 效率很低的網絡資源使用。圖2是使用組播分組來傳送TV頻道的相同網絡的單元的示意表示。骨干網102、 無線網絡105、106、107必須都支持組播分組的使用，網關節(jié)點必須能夠路由組播分組。移 動TV提供器101僅需要發(fā)送單一組播數(shù)據(jù)分組流。每個網關節(jié)點認識到這些分組是組播 的，并將相同數(shù)據(jù)流轉發(fā)至多于一個接收方。這確保了網絡資源的更高效利用，但是需要網 絡中的所有點都可以處理組播數(shù)據(jù)分組。在蜂窩網絡內，點對多點傳輸現(xiàn)在本質上基于IP組播。在GSM和UMTS蜂窩網絡 中引入3GPP多媒體廣播/組播服務(MBMS) (3GPP TS 23.246)標準化了該架構并提供了用 于MBMS承載服務的優(yōu)化傳輸(如點對多點傳輸)、點對多點(PTM)和點對點(PTP)承載之 間的選擇性合并和傳輸模式選擇的技術。它實現(xiàn)了無線網絡和核心網資源的高效利用，其 中側重無線接口效率。在MBMS中，術語“廣播”指的是向所有用戶傳送內容的能力。在蜂窩網絡中，這意 味著移動TV服務將被廣播至定義服務區(qū)的小區(qū)中的所有移動終端。另一方面，組播指的是 僅向參加了特定組播組的用戶傳送的服務。在蜂窩網絡中，這意味著僅將服務傳送至已經 簽約的移動終端。很明顯，需要將MBMS引入移動TV。在3GPP中，稱為廣播-組播服務中心(BM-SC)的邏輯組件在服務層為移動TV提 供器提供了 MBMS功能。BM-SC提供5個主要功能會員、安全、會話和傳送、代理和傳輸、以 及服務通告。3GPP版本6規(guī)定，BM-SC應當向GGSN發(fā)送組播IP分組。然而，在一些情況下，GGSN 可能不支持組播操作。因此，在3GPP版本7中提出了另一選擇以解決這一情況。BM-SC可 以將IP組播分組封裝在IP單播分組內，以向GGSN發(fā)送，這被稱為IP-in-IP并在IETFRFC 2003中描述。因此，需要一種能夠動態(tài)地在單播隧道中發(fā)送組播分組的媒體服務器。還需要提 供對單播分組中的IP組播分組的控制、封裝和恢復。還需要使用RTSP來控制這種封裝和 恢復。

發(fā)明內容
本發(fā)明提出了一種擴展RTSP協(xié)議的方式，使媒體服務器能夠動態(tài)地在單播隧道 中發(fā)送組播分組。
根據(jù)本發(fā)明的第一方面，提供了一種對網絡中組播媒體的傳送進行控制的方法， 在所述網絡中，至少一些節(jié)點不支持組播分組的傳送。所述方法包括向媒體服務器發(fā)送用 于向網絡中的網關節(jié)點發(fā)送封裝在單播封包內的組播分組的請求。所述請求包括組播目的 地址的細節(jié)，以及網關節(jié)點的單播目的地址的細節(jié)。優(yōu)選地，所述請求根據(jù)RTSP來形成，優(yōu)選地，所述請求是RTSPSETUP消息，盡管可 以認識到，也可以使用其他協(xié)議和發(fā)起消息。優(yōu)選地，組播目的地址和網關節(jié)點單播目的地 址的細節(jié)包括在所述請求的傳輸首部和擴展首部中。在一個實施例中，所述媒體服務器可以是IP網絡中的流傳輸服務器，在這種情況 下，優(yōu)選地，對流傳輸服務器的請求由網關節(jié)點發(fā)送。例如，所述網關節(jié)點可以是LAN的網 關節(jié)點，并且能夠將組播數(shù)據(jù)流轉發(fā)至LAN內的客戶端終端。在這種情況下，組播目的地址 應當包括在對RTSP消息的傳輸首部的擴展中。在另一實施例中，所述媒體服務器可以是移動TV服務器(BM-SC中的業(yè)務量處理 組件)，在這種情況下，所述請求可以由廣播控制器(BM-SC中的信號處理組件)發(fā)送，所述 網關節(jié)點可以是GGSN。在這種情況下，包括在對RTSP消息的傳輸首部的擴展中的是GGSN 單播目的地址。一旦針對要發(fā)送至網關節(jié)點的、封裝在單播封包內的組播分組做出了請求，則媒 體服務器可以優(yōu)選地對具有組播目的地址的組播分組中的流傳輸數(shù)據(jù)進行編碼，然后將組 播分組封裝在單播封包內，以形成具有網關節(jié)點單播目的地址的單播分組。然后，單播分組 被發(fā)送至網關節(jié)點。網關節(jié)點去除單播封包以恢復組播分組，并向組播目的地址發(fā)送組播 分組。根據(jù)本發(fā)明的第二方面，提供了一種用于在網絡中傳送IP組播數(shù)據(jù)的網關節(jié)點。 所述網關節(jié)點包括接收機，用于從客戶端終端接收用于訂閱組播頻道的指令。處理器操作 連接至接收機，并被配置為產生對流傳輸服務器的請求(優(yōu)選為RTSP消息)，所述請求針對 封裝在單播封包內的組播分組，所述請求包括組播目的地址以及網關節(jié)點的單播目的地址 的細節(jié)。發(fā)射機操作連接至處理器，并被配置為向流傳輸服務器發(fā)送所述請求。根據(jù)本發(fā)明的第三方面，提供了 BM-SC中的BCC組件。BCC包括接收機，用于從 GGSN接收用于建立到組播目的地址的組播流傳送的指令。處理器操作連接至接收機，并被 配置為產生對BM-SC的移動TV服務器組件的請求(優(yōu)選為RTSP消息)，所述請求針對要 發(fā)送至GGSN的、封裝在單播封包內的組播分組。所述請求包括組播目的地址以及GGSN的 單播目的地址的細節(jié)。發(fā)射機操作連接至處理器，并被配置為向移動TV服務器發(fā)送所述請 求。根據(jù)本發(fā)明的第四方面，提供了一種用于傳送組播流媒體數(shù)據(jù)的媒體服務器。所 述媒體服務器包括接收機，用于接收向網關節(jié)點發(fā)送封裝在單播封包內的組播分組的請 求(優(yōu)選為RTSP消息)，所述請求包括組播目的地址以及網關節(jié)點的單播目的地址的細節(jié)。 處理器被配置為對組播分組中的媒體數(shù)據(jù)進行編碼，并將組播分組封裝在單播封包內作為 單播分組。發(fā)射機被配置為向網關節(jié)點發(fā)送單播分組。


圖1是使用單播分組來傳送TV頻道的網絡中的單元的示意表示。
圖2是使用組播分組來傳送TV頻道的相同網絡中的單元的示意表示。圖3是用于廣播/組播服務中心(BM-SC)的適當架構的示意。圖4是示意了當GGSN不支持組播時將BM-SC配置為將組播IP分組封裝在單播IP 分組內并建立組播會話所需的步驟的信令圖。圖5是因特網中的一些節(jié)點的示意表示，示出了向兩個LAN傳送組播分組。圖6示意了當至少一些網關節(jié)點不支持組播時從流傳輸服務器向客戶端終端傳 送IP組播流時涉及的組件之間的信令。圖7是能夠建立封裝在單播分組內的流傳輸IP組播分組的傳送的網關節(jié)點的示
意表不。圖8是能夠將IP組播分組封裝在單播分組內并將其向網關發(fā)送的媒體服務器的
不意表不。
具體實施例方式為了解釋而非限制的目的，以下描述闡述了具體細節(jié)，如特定實施例、過程、技術 等。在一些實例中，省略了對于公知方法、接口、電路和設備的詳細描述，以免不必要的細節(jié) 模糊描述。此外，在一些圖中示出了各個塊?？梢哉J識到，這些塊的功能可以使用各個硬件 電路、使用與適當編程的數(shù)字微處理器或通用計算機相結合的軟件程序和數(shù)據(jù)、使用專用 集成電路和/或使用一個或多個數(shù)字信號處理器來實現(xiàn)。對實時流傳輸協(xié)議(RTSP)的一些特征的簡要描述將有助于理解本發(fā)明的實施 例。RTSP廣泛用作流傳輸領域中的控制協(xié)議。它負責建立和控制一個或多個時間同步的音 頻/視頻流。它本身不傳送連續(xù)流，而是控制流傳輸服務器來進行傳送。RTSP中規(guī)定的命令包括以下內容1. DESCRIBE。它用于檢索呈現(xiàn)或媒體對象的描述(例如編碼、網絡地址等)。通 常，會話描述協(xié)議(SDP)(在IETF RFC 2327中定義)用于定義呈現(xiàn)描述的格式。SDP信息 還可以通過HTTP下載或其他會話通告方法來檢索。2. SETUP 它用于分配流傳送的資源并啟動會話。如果會話中涉及多個媒體流，則 需要對它們分別進行建立。3. PLAY 它用于在經由SETUP分配的一個或多個流上啟動數(shù)據(jù)傳輸。4. PAUSE 它用于暫時停止流，而不釋放分配給該流的資源。5. TEARDOffN 它用于停止數(shù)據(jù)傳輸，并釋放與流相關聯(lián)的資源。RTSP 協(xié)議中定義的其他命令包括 OPTIONS、ANNOUNCE、RECORD、GET_PARAMETER、 SET_PARAMETER 和 REDIRECT。移動TV在移動TV的一種適當架構中，BM-SC具有單獨的組件用于處理信令和數(shù)據(jù)業(yè)務 量，如圖3所示。BM-SC 301包括廣播控制器(BCC) 321和移動TV服務器(MTV服務器)322。 BCC 321負責使用針對MBMS廣播會話建立和管理而設計的Diameter協(xié)議，穿過Gmb信令接 口來與GGSN 302交換信令。MTV服務器負責通過針對MBMS數(shù)據(jù)傳送而設計的Gi接口來向 GGSN 302發(fā)送業(yè)務量。BCC 321與MTV服務器322之間的接口使用RTSP協(xié)議。為了建立組播，使用RTSP SETUP方法。傳輸首部指示要使用哪個傳輸協(xié)議，并配置參數(shù)，如目的地址、壓縮、組播生存期和單一流的目的端口。這些值不是由呈現(xiàn)描述確定 的。 如果存在已經支持IP組播的GGSN，則BCC 321可以使用傳輸首部來傳遞組播信 息，如下BCC- > MTV:SETUP rtsp://live. example, com/concert/audio RTSP/1. 0CSeq: 2Transport: RTP/AVP ；multicast ；destination = 224. 2. 0. 1 ；port = 4002-4003 ；ttl = 16MTV-> BCC: RTSP/1. 0 200 OKCSeq: 2Transport: RTP/AVP ；multicast ；destination = 224. 2. 0. 1 ；port = 4002-4003 ；ttl = 16Session:0456804596BCC- > MTV:SETUP rtsp://live. example, com/concert/video RTSP/1. 0CSeq: 3Transport: RTP/AVP ；multicast ；destination = 224. 2. 0. 1 ；port = 4004-4005 ；ttl = 16Session:0456804596MTV-> BCC: RTSP/1. 0 200 OKCSeq: 3Transport: RTP/AVP ；multicast ；destination = 224. 2. 0. 1 ；port = 4004-4005 ；ttl = 16Session:0456804596BCC- > MTV:PLAY rtsp://live. example, com/concert RTSP/1. 0CSeq: 4Session:0456804596MTV-> BCC: RTSP/1. 0 200 OKCSeq: 4Session:0456804596由此可以看出，在兩個SETUP請求中，BCC 321使用傳輸首部通知MTV服務
器322組播目的地址(224.2.0. 1)、音頻流的端口號(4002-4003)和視頻流的端口號 (4004-4005)、以及生存期信息(16)。在接收PLAY請求之后，MTV服務器322使用“200 0K”進行響應，然后將組播IP分 組直接傳送至GGSN 302。在這種情況下，RTSP非常好地適應了建立組播會話的需要。如上所述，在一些情況下，GGSN可能不支持組播操作。因此，在3GPP版本7中提出 了另一選擇以解決這一情況。BM-SC可以將IP組播分組封裝在IP單播分組內，以向GGSN 發(fā)送。這被稱為IP-in-IP并在IETF RFC 2003中描述。即使GGSN不具有IP組播支持，它也可以接收單播IP分組，去除單播封包以恢復 封裝的組播分組，然后將組播分組轉發(fā)至SGSN。因此，MBMS廣播仍可以如先前所提出的那樣操作。唯一的差別在于，BM-SC與GGSN之間的業(yè)務量是單播傳送(具有內部的組播分 組)。然而，在當前定義的RTSP中，流傳輸信道可以被建立為單播或組播。先前不可能 請求媒體服務器發(fā)出在單播隧道內封裝的組播分組。因此，如果有一些GGSN不支持組播，則BCC 321不僅需要向MTV服務器322提供 與組播相關的信息(組播地址)，還需要向其提供GGSN的單播隧道目的地信息(例如GGSN 302)。為了傳遞組播和單播傳輸信息，需要一些專用的RTSP擴展。在移動TV方案中，傳 輸首部用于與通常一樣傳遞組播信息，并引入被稱為X-GGSN的擴展首部。在X-GGSN首部 中，包含目的地單播地址。以下是針對該場景的RTSP信令的示例BCC- > MTV:SETUP rtsp://live. example, com/concert/audio RTSP/1. 0CSeq: 2Transport: RTP/AVP ；multicast ；destination = 224. 2. 0. 1 ；port = 4002-4003 ；ttl = 16X-GGSN:150. 236. 42. 5MTV-> BCC: RTSP/1. 0 200 OKCSeq: 2Transport: RTP/AVP ；multicast ；destination = 224. 2. 0. 1 ；port = 4002-4003 ；ttl = 16Session:0456804596BCC- > MTV:SETUP rtsp://live. example, com/concert/video RTSP/1. 0CSeq: 3Transport: RTP/AVP ；multicast ；destination = 224. 2. 0. 1 ；port = 4004-4005 ；ttl = 16X-GGSN:150. 236. 42. 5Session:0456804596MTV-> BCC: RTSP/1. 0 200 OKCSeq: 3Transport: RTP/AVP ；multicast ；destination = 224. 2. 0. 1 ；port = 4004-4005 ；ttl = 16Session:0456804596BCC- > MTV:PLAY rtsp://live. example, com/concert RTSP/1. 0CSeq: 4Session:0456804596MTV-> BCC: RTSP/1. 0 200 OKCSeq: 4Session:0456804596注意，除傳輸首部中包括的組播目的地址(224.2.0. 1)、音頻和視頻端口號
(4002-4003和4004-4005)以及生存期信息(16)之外，SETUP消息現(xiàn)在還包括提供GGSN302的單播目的地址(150. 236. 42. 5)的X-GGSN擴展首部。在本示例中，一旦接收到PLAY請求，MTV服務器322就使用“2000K”消息來響應 BCC 321，將組播IP分組封裝入單播IP分組，然后將單播IP分組傳送至X-GGSN首部中描 述的目的地址150. 236. 42. 5。圖4是示意了當GGSN不支持組播時，將BM-SC配置為將組播IP分組封裝在單播 IP分組內并建立組播會話所需的步驟的示意。這些步驟如下所述401 從BCC 321向GGSN 302發(fā)送Diameter重新認證請求(RAR)(開始)命令。 使用該命令，BCC 321指示GGSN 302和蜂窩網絡中的其他下游節(jié)點激活MBMS承載資源。402 從GGSN 302向BCC 321返回Diameter重新認證回答(RAA)(開始)響應。 通過RAA響應，GGSN 302通知BCC 321它是否支持組播。如果不支持組播(如本情況)，還 包括用于接收媒體流的其單播IP地址。403 從BCC 321向MTV服務器322發(fā)送RTSP SETUP消息，以建立一個流(例如音 頻流)。如上所述，SETUP消息包括組播目的地址以及作為X-GGSN首部的、GGSN的IP單播 地址。MTV 322返回200 OK響應。404 從BCC 321向MTV 322發(fā)送另一 RTSP SETUP消息，以建立另一流(例如視頻 流)，包括組播目的地址和GGSN IP單播地址。MTV322返回另一 200 OK響應。405 從 BCC 321 向 MTV 服務器 322 發(fā)送 RTSP PLAY 消息。MTV322 返回 200 OK 響應。406 =MTV服務器322將媒體內容封裝入組播分組。407 然后，將組播分組封裝入IP單播分組。408 從MTV服務器322向GGSN 302傳送IP單播分組。409 在會話結束時，BCC 321向MTV服務器322發(fā)送RTSPTEARD0WN消息。因特網類似系統(tǒng)還可以用于通過因特網傳送的組播分組。如同在移動TV中那樣，RTSP協(xié) 議還廣泛用于因特網上客戶端與流傳輸服務器之間的會話管理。在多數(shù)情況下，數(shù)據(jù)流是以單播模式傳送的，不論它們是視頻點播還是直播流。對 于直播流，由于預期所有接收機接收相同的內容，因此如果可以以組播模式進行傳送將更 加高效。這種分組的組播將節(jié)約業(yè)務量路徑中的帶寬，還將減小流傳輸服務器的負載。然而，如果通過因特網來執(zhí)行組播傳送，則需要業(yè)務量路徑中的所有路由器都具 有組播支持。此外，需要運營商的防火墻端口為輸入組播分組開啟。出于安全原因，一些防 火墻禁用組播分組的接收。典型地，IP組播更廣泛地用于局域網(LAN)中，而不是貫穿整個因特網。因此，考 慮與以上針對移動TV的描述類似的方案是現(xiàn)實的?？梢詮牧鱾鬏敺掌飨騆AN網關傳送 單播流。然后在LAN內部，可以以組播來傳送單播的內容。根據(jù)3GPP版本7提出的方法，媒體服務器可以將IP組播分組封裝在單播分組內。 然后，網關節(jié)點可以去除單播封包，并在局域網中對分組進行組播。然后，可以穿過因特網 來發(fā)送組播分組，不論中間路由器是否提供組播支持。此外，仍可以實現(xiàn)組播固有的效率， 因為從媒體服務器向網關節(jié)點僅需要一個傳送信道，然后，網關節(jié)點將該分組組播至所有 客戶端。
按照這一提議，在RTSP信令接口上存在與移動TV相同的問題。按照當前定義的 RTSP，網關節(jié)點不能要求媒體服務器發(fā)出封裝在單播隧道內的組播分組。這種功能和部署的實現(xiàn)需要一種網關節(jié)點，以下稱為組播至單播GW，組播至單播 Gff具有兩種主要功能1.在信號平面中，組播至單播GW代表LAN中的客戶端向流傳輸服務器建立RTSP 會話；2.在業(yè)務量平面中，組播至單播GW將單播IP分組轉換為組播IP分組，并向LAN 中的客戶端流傳輸組播分組。流傳輸服務器該將組播IP分組封裝在單播IP分組內，并且 組播至單播GW去除單播IP “封包”并直接對內部的組播IP分組進行組播。參照圖5可以理解這一點，圖5是因特網中的一些節(jié)點的示意表示，示出了向兩個 LAN 506、507傳送組播分組。每個LAN包括組播至單播GW 504、505和4個終端511-518。防 火墻502、503保護每個組播至單播GW 504、505。流傳輸服務器501向組播至單播GW 504、 505發(fā)送封裝在單播“封包”內的組播IP分組。組播至單播GW 504、505從單播封包恢復組 播分組，并將其以組播轉發(fā)至其自身LAN內的終端。從流傳輸服務器501發(fā)送的單播分組 可以通過不具有組播功能的路由器，還可以通過防火墻502、503。在當前的RTSP協(xié)議中，必須以單播模式或組播模式來傳送業(yè)務量。先前沒有提供 機制以確?？梢灾甘玖鱾鬏敺掌鲗⒔M播分組封裝為單播分組。因此，提出以與以上在移動TV上下文中的描述類似的方式來擴展RTSP協(xié)議。按 照當前使用的RTSP，在傳輸首部中傳遞網關IP地址和端口號，使得知曉RTSP的防火墻允許 業(yè)務量通過。RTSP的擴展涉及在擴展首部中傳遞組播目的地址、端口號和生存期信息。在 以下示例中，擴展首部被標記為“X-Multicast-Transport”。Gff- > SS:SETUP rtsp://live. example, com/concert/audio RTSP/1. 0CSeq: 2Transport:RTP/AVP ；unicast ；client—port = 3456-3457X-Multicast-Transport:destination = 224. 2. 0. 1 ；Port = 4002-4003 ；ttl = 16SS- > Gff: RTSP/1. 0 200 OKCSeq: 2Transport:RTP/AVP ；unicast ；client—port = 3456-3457 ；server_port = 5000-5001X-Multicast-Transport:destination = 224. 2. 0. 1 ；Port = 4002-4003 ；ttl = 16Session:0456804596Gff- > SS:SETUP rtsp://live. example, com/concert/video RTSP/1. 0CSeq: 3Transport:RTP/AVP ；unicast ；client—port = 3458-3459X-Multicast-Transport:destination = 224. 2. 0. 1 ；Port = 4004-4005 ；ttl = 16Session:04568045960148]
0149]
0150]
0151]
0152]
0153]
0154]
0155]
0156]
0157]
SS- > Gff:RTSP/1. 0 200 OK
CSeq:3
Transport RTP/AVP ；unicast ；client_port = 3456—3457 ；
server_port = 5002-5003 X-Multicast-Transportdestination = 224. 2. 0. 1 ；
Port = 4004-4005 ；ttl = 16
Session:0456804596 Gff- > SSPLAY rtsp://live. example, com/concert RTSP/1. 0
CSeq:4
Session:0456804596
0158] SS- > Gff:RTSP/1. 0 200 OK
0159]
0160]
CSeq:4
Session:0456804596因此，在移動TV的情況下，除了先前已知的組播目的地址之外，RTSP SETUP消息 還傳遞單播GGSN目的地址。在因特網的情況下，除了先前已知的網關單播目的地址之夕卜， RTSP SETUP消息還傳遞組播目的地址和端口號。因此，組播至單播網關504、505代表在其局域網中的客戶端511-518，在信令平面 中發(fā)送和接收RTSP消息。當客戶端希望訂閱組播流時，它可以使用例如因特網組管理協(xié) 議(IGMP)或組播監(jiān)聽者發(fā)現(xiàn)(MLD)來發(fā)送“加入”請求。然后，組播至單播網關負責發(fā)送 SETUP和PLAY請求。當特定組播至單播網關所服務的所有客戶端都停止接收(例如通過發(fā) 送IGMP或MLD離開消息)時，網關負責發(fā)送TEARD0WN請求。一旦請求了組播流，流傳輸服務器將組播IP分組封裝在單播封包內，并發(fā)送到組 播至單播網關。在業(yè)務量平面中，組播至單播網關必須去除這些單播IP封包，并將內部的 IP分組組播至其LAN中的客戶端。圖6示意了在從流傳輸服務器501向組播至單播GW 504所服務的LAN 506中的 第一和第二客戶端終端511、512進行組播流的傳送中涉及的、圖5中所示的一些組件之間 的信令。這些步驟如下601 第一客戶端511向組播至單播GW 504發(fā)送IGMP或MLD加入命令，指示第一
客戶端要觀看頻道。602 組播至單播GW 504向流傳輸服務器501發(fā)送兩個RTSPSETUP消息，請求封裝 在單播封包中的組播分組。如上所述，RTSPSETUP消息包括組播細節(jié)和組播至單播GW 504 的單播地址。603 在本示例中，第二客戶端512還向組播至單播GW 504發(fā)送IGMP或MLD加入命 令，以訂閱與第一客戶端511相同的頻道。已經在組播至單播GW 504與流傳輸服務器501 之間進行的建立信令不受第二加入命令的影響。604 一旦建立了會話，則組播至單播GW 504向流傳輸服務器501發(fā)送RTSP PLAY 消息，指示流傳輸開始。605 流傳輸服務器501將內容放入組播分組。606 將組播分組封裝在IP組播分組中。
607 流傳輸服務器向組播至單播GW 504發(fā)送IP組播分組。608 組播至單播GW 504從其單播封包中提取組播分組。609 組播至單播GW 504向第一和第二客戶端終端511、512轉發(fā)組播分組。610 第二客戶端終端512決定停止觀看該頻道并向組播至單播GW 504發(fā)送IGMP 或MLD離開命令。由于第一客戶端終端511仍訂閱該頻道，組播至單播GW 504不進行任何 動作。611 第一客戶端終端511決定停止觀看該頻道并向組播至單播GW 504發(fā)送IGMP 或MLD離開命令。在本示例中，這是LAN 506中離開該頻道的最后一個客戶端。612 一旦最后一個客戶端離開該頻道，組播至單播GW 504向流傳輸服務器501發(fā) 送RTSP TEARDOffN消息，以代表客戶端關閉RTSP會話。圖7是用于提供IP組播服務的網關節(jié)點701的示意表示，網關節(jié)點701可以是參 照圖5和6描述的類型的組播至單播GW 504。網關節(jié)點包括接收機702，用于在信號平面 中從局域網內的客戶端終端接收用于訂閱組播的指令。微處理器703處理這些指令，并經 由發(fā)射機704向流傳輸服務器發(fā)起要發(fā)送的RTSP建立信令，以請求封裝在單播封包內的組 播數(shù)據(jù)分組。微處理器確保建立信令提供組播目的地址的細節(jié)以及節(jié)點自身的單播地址的 細節(jié)。在業(yè)務量平面上，當從流傳輸服務器接收到單播分組時，將其臨時保存在存儲器705 中，同時微處理器703去除單播封包以提取封裝在其中的組播分組。然后，發(fā)射機704向局 域網中的客戶端發(fā)送組播分組。圖8是用于提供IP組播服務的媒體服務器801的示意表示，媒體服務器801可以 是參照圖3和4描述的類型的MTV服務器322，或者參照圖5和6描述的類型的流傳輸服 務器501。媒體服務器801包括接收機802，用于在信號平面中，從BCC 321或組播至單播 Gff 504接收用于發(fā)送封裝在單播封包內的組播分組的指令。所述指令包含組播目的地址的 細節(jié)，以及單播分組應當被發(fā)送至的網關節(jié)點的單播地址的細節(jié)。微處理器803處理這些 指令并對組播分組內的內容(例如存儲在存儲器805中的內容)進行編碼，然后將組播分 組封裝在單播封包內。發(fā)射機804通過局域網，在業(yè)務量平面上向網關節(jié)點發(fā)送單播IP分 組?？梢哉J識到，根據(jù)上述實施例的變化仍落入本發(fā)明的范圍內。例如，已經描述了 BM-SC的一種可能架構，但是可以認識到，其他架構可能也是合適的。此外，已經特別參照 在LAN內傳送組播分組的網關節(jié)點描述了通過因特網的組播分組傳送?？梢哉J識到，可以 想到其他配置。此外，總體上參照對RTSP協(xié)議的可能擴展描述了本發(fā)明?？梢哉J識到，也可以使 用其他協(xié)議來執(zhí)行建立封裝在單播封包中的組播分組的傳送所需的信令。例如，可以使用 會話發(fā)起協(xié)議(SIP)來執(zhí)行信令。盡管已經詳細示出和描述了各個實施例，但是權利要求不限于任何具體實施例或 示例。以上描述不應被理解為暗示任何具體元件、步驟或功能是必不可少的，而使其必須被 包括在權利要求的范圍中。保護范圍由權利要求來限定。
權利要求
一種對網絡中組播媒體的傳送進行控制的方法，在所述網絡中，至少一些節(jié)點不支持組播分組的傳送，所述方法包括向媒體服務器發(fā)送用于向網絡中的網關節(jié)點發(fā)送封裝在單播封包內的組播分組的請求；其中，所述請求包括組播目的地址的細節(jié)，以及網關節(jié)點的單播目的地址的細節(jié)。
2.根據(jù)權利要求1所述的方法，其中，發(fā)送至媒體服務器的請求是實時流傳輸協(xié)議 “RTSP” 消息。
3.根據(jù)權利要求1或2所述的方法，其中，組播目的地址的細節(jié)和網關節(jié)點的單播目的 地址的細節(jié)包括在所述請求的首部中。
4.根據(jù)權利要求1、2或3所述的方法，其中，所述媒體服務器是IP網絡中的流傳輸服 務器，其中，對流傳輸服務器的請求由網關節(jié)點發(fā)送。
5.根據(jù)權利要求4所述的方法，其中，網關節(jié)點的單播目的地址包括在所述請求的傳 輸首部中，組播目的地址包括在所述請求的擴展首部中。
6.根據(jù)權利要求1、2或3所述的方法，其中，所述媒體服務器是廣播/組播服務中心 “BM-SC”中的業(yè)務量處理組件，所述請求由BM-SC中的信號處理組件發(fā)送，所述網關節(jié)點是 網關GPRS支持節(jié)點“GGSN”。
7.根據(jù)權利要求6所述的方法，其中，組播目的地址包括在所述請求的傳輸首部中，網 關節(jié)點的單播目的地址包括在所述請求的擴展首部中。
8.根據(jù)之前任一權利要求所述的方法，還包括在媒體服務器處，對具有組播目的地址的組播分組中的流傳輸數(shù)據(jù)進行編碼；將組播分組封裝在單播封包內，以形成具有網關節(jié)點的單播目的地址的單播分組；將單播分組發(fā)送至網關節(jié)點；在網關節(jié)點處，去除單播封包以恢復組播分組；以及向組播目的地址發(fā)送組播分組。
9.一種用于在網絡中傳送IP組播數(shù)據(jù)的網關節(jié)點，包括 接收機，用于從客戶端終端接收用于訂閱組播頻道的指令；處理器，操作連接至接收機，并被配置為產生對流傳輸服務器的請求，所述請求針對封 裝在單播封包內的組播分組，所述請求包括組播目的地址的細節(jié)以及網關節(jié)點的單播目的 地址的細節(jié)；以及發(fā)射機，操作連接至處理器，并被配置為向流傳輸服務器發(fā)送所述請求。
10.根據(jù)權利要求9所述的網關節(jié)點，被配置為使得發(fā)送至流傳輸服務器的請求是實 時流傳輸協(xié)議“RTSP”消息。
11.根據(jù)權利要求9或10所述的網關節(jié)點，其中，所述網關節(jié)點還被配置為 接收包含封裝在單播封包內的組播分組在內的單播分組；從單播分組中恢復組播分組；以及 向組播目的地址發(fā)送恢復的組播分組。
12.—種廣播/組播服務中心“BM-SC”中的信號處理組件，包括接收機，用于從網關GPRS支持節(jié)點“GGSN”接收用于建立到組播目的地址的組播流傳 送的指令；處理器，操作連接至接收機，并被配置為產生對BM-SC的移動TV服務器組件的請求，所 述請求針對要發(fā)送至GGSN的、封裝在單播封包內的組播分組，所述請求包括組播目的地址 以及GGSN的單播目的地址的細節(jié)；以及發(fā)射機，操作連接至處理器，并被配置為向移動TV服務器發(fā)送所述請求。
13.根據(jù)權利要求12所述的信號處理組件，被配置為使得發(fā)送至移動TV服務器的請求 是實時流傳輸協(xié)議“RTSP”消息。
14.一種用于傳送組播流媒體數(shù)據(jù)的媒體服務器，包括接收機，用于接收用于向網關節(jié)點發(fā)送封裝在單播封包內的組播分組的請求，所述請 求包括組播目的地址的細節(jié)以及網關節(jié)點的單播目的地址的細節(jié)；處理器，被配置為對組播分組中的媒體數(shù)據(jù)進行編碼，并將組播分組封裝在單播封包 內作為單播分組；以及發(fā)射機，被配置為向網關節(jié)點發(fā)送單播分組。
15.根據(jù)權利要求14所述的媒體服務器，其中，所述媒體服務器是IP網絡中的流傳輸 服務器，其中，所述請求是從網關節(jié)點接收的。
16.根據(jù)權利要求14所述的媒體服務器，其中，所述媒體服務器是廣播/組播服務中心 “BM-SC”中的業(yè)務量處理組件，所述請求是從BM-SC的信號處理組件接收的。
17.根據(jù)權利要求14至16中任一項所述的媒體服務器，其中，所述請求是實時流傳輸 協(xié)議“ RTSP ”請求。
全文摘要
本發(fā)明提供了一種用于在網絡中傳送組播媒體的方法和設備，在所述網絡中，至少一些節(jié)點不支持組播分組的傳送。向流傳輸服務器發(fā)送用于向網絡中的網關節(jié)點發(fā)送封裝在單播封包內的組播分組的RTSP SETUP請求。RTSP SETUP請求包括組播目的地址的細節(jié)以及網關節(jié)點的單播目的地址的細節(jié)，需要對當前定義的RTSP協(xié)議進行擴展，并使媒體服務器能夠動態(tài)地在單播隧道中發(fā)送組播分組。
文檔編號H04L12/18GK101946458SQ200880126686
公開日2011年1月12日 申請日期2008年2月25日 優(yōu)先權日2008年2月25日
發(fā)明者凌捷, 吳毅成, 謝錦揚, 陳琨 申請人:艾利森電話股份有限公司