CN101946458B - 组播数据的传送 - Google Patents

组播数据的传送 Download PDF

Info

Publication number
CN101946458B
CN101946458B CN2008801266861A CN200880126686A CN101946458B CN 101946458 B CN101946458 B CN 101946458B CN 2008801266861 A CN2008801266861 A CN 2008801266861A CN 200880126686 A CN200880126686 A CN 200880126686A CN 101946458 B CN101946458 B CN 101946458B
Authority
CN
China
Prior art keywords
multicast
clean culture
destination address
multicastapackets
gateway node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN2008801266861A
Other languages
English (en)
Other versions
CN101946458A (zh
Inventor
吴毅成
陈琨
凌捷
谢锦扬
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of CN101946458A publication Critical patent/CN101946458A/zh
Application granted granted Critical
Publication of CN101946458B publication Critical patent/CN101946458B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1836—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with heterogeneous network architecture
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services

Abstract

本发明提供了一种用于在网络中传送组播媒体的方法和设备，在所述网络中，至少一些节点不支持组播分组的传送。向流传输服务器发送用于向网络中的网关节点发送封装在单播封包内的组播分组的RTSP SETUP请求。RTSP SETUP请求包括组播目的地址的细节以及网关节点的单播目的地址的细节，需要对当前定义的RTSP协议进行扩展，并使媒体服务器能够动态地在单播隧道中发送组播分组。

Description

组播数据的传送
技术领域
本发明涉及用于传送组播数据的方法和设备。具体地，本发明涉及通过其中一些节点不支持组播数据路由的网络来传送IP组播数据。
背景技术
IP组播是一种用于从源高效地将IP内容传送至终端用户(“客户端”)的机制。IP组播与单播(一对一传送)和广播(一对全部传送)的区别在于，它利用了基于网络的组播路由器(MC)来将单一输入IP流分发至一组客户端和/或属于给定组播组的其他MC。IP组播被认为是一种用于传送如IP电视(IPTV)之类需要大量带宽的服务的优秀技术。
IP组播的关键概念之一是组播组地址。希望接收组播内容的客户端可以通过因特网组管理协议(IGMP)加入IP组播组，以向上游MC注册。MC自身一般使用协议独立组播(PIM)来建立分级结构的组播分发树。然后，发送方可以简单地向IP组播组地址发送分组，使得该组中注册的所有客户端可以接收这些分组。在多媒体域中，大多数时候多媒体内容被成帧为实时协议(RTP)分组，RTP分组在要组播传送的用户数据报协议(UDP)上层运行。
IP电视(IPTV)是允许通过IP网络传送电视的多种服务的名称。由于IP网络的灵活性，IPTV将允许针对用户的更加个性化的服务，例如视频点播，其中，信息通过单播或组播IP流传送给用户。当前，控制这些流的主要方式是使用在IETF RFC 2326中定义的实时流传输协议(RTSP)。RTSP未指定传输协议，但是可以例如用于建立和控制RTP媒体流。RTSP在许多方面类似于用于通过因特网请求和交换信息的HTTP协议，但是定制用于对如音频和视频之类的媒体进行流传输。RTSP允许客户端向流传输服务器请求特定媒体流，并指定了如PLAY和PAUSE之类的命令。RTSP本身不传送连续流，而是控制流传输服务器进行传送。
因此，RTSP支持单播或组播模式，这一选择取决于网络目的地址。在单播模式中，媒体被发送至所请求的目的地和客户端选择的端口号。在组播模式中，向特定组播地址发送服务器组播数据。组播IP地址和端口信息可以由服务器或客户端来决定。
对于数据传送，多数实时媒体使用RTP作为传输协议，尽管RTSP并不与RTP捆绑。RTP提供了端到端传送服务，用于具有实时特性的流传送，RTP由两个部分组成。RTP承载具有实时特性的数据，而RTP控制协议(RTCP)在正在进行的会话中监控服务质量并传递信息。
预期移动终端(如移动电话)的用户希望使用IPTV服务。确实，这可能对于当前正在安装高容量蜂窝网络(如3G网络)的网络运营商的商业模型而言很关键。移动TV为移动屏幕提供了TV服务，但是多于移至小屏幕的传统TV。它向用户提供了在任何时间任何地点观看TV内容的自由。除了观看直播TV频道和视频剪辑之外，移动TV还提供了比传统TV更多的交互式TV体验，如投票和聊天。随着移动TV使用的增长，可以将蜂窝网络升级为满足大量市场需求。
当前，移动TV是经由通过点对点连接的流传输技术来提供的。在这种情况下，数据分组被发送至单一目的地。移动TV的大规模市场部署将需要点对多点连接的新网络能力。这需要网络和移动终端的支持。使用点对多点连接，可以同时向多个目的地发送数据分组。
图1和2示意了蜂窝网络中一个TV频道的数据分组的单播(点对点)和组播(点对多点)传送。图1是使用单播分组传送TV频道的网络的单元的示意表示。移动TV提供器101穿过骨干网向网关GPRS支持节点(GGSN)102发送分组。GGSN标识订阅TV频道的用户的地址和位置，并将分组转发至各个服务GPRS支持节点(SGSN)103、104。SGSN 103、104通过无线网络105、106、107向使用移动终端111-118的终端用户路由分组。每个终端用户需要其自身的数据流，因此必须从移动TV提供器101发送8个流，从GGSN 102向每个SGSN 103、104发送4个流。多个数据流被发送入每个无线网络105-106。可以认识到，这导致了效率很低的网络资源使用。
图2是使用组播分组来传送TV频道的相同网络的单元的示意表示。骨干网102、无线网络105、106、107必须都支持组播分组的使用，网关节点必须能够路由组播分组。移动TV提供器101仅需要发送单一组播数据分组流。每个网关节点认识到这些分组是组播的，并将相同数据流转发至多于一个接收方。这确保了网络资源的更高效利用，但是需要网络中的所有点都可以处理组播数据分组。
在蜂窝网络内，点对多点传输现在本质上基于IP组播。在GSM和UMTS蜂窝网络中引入3GPP多媒体广播/组播服务(MBMS)(3GPP TS 23.246)标准化了该架构并提供了用于MBMS承载服务的优化传输(如点对多点传输)、点对多点(PTM)和点对点(PTP)承载之间的选择性合并和传输模式选择的技术。它实现了无线网络和核心网资源的高效利用，其中侧重无线接口效率。
在MBMS中，术语“广播”指的是向所有用户传送内容的能力。在蜂窝网络中，这意味着移动TV服务将被广播至定义服务区的小区中的所有移动终端。另一方面，组播指的是仅向参加了特定组播组的用户传送的服务。在蜂窝网络中，这意味着仅将服务传送至已经签约的移动终端。很明显，需要将MBMS引入移动TV。
在3GPP中，称为广播-组播服务中心(BM-SC)的逻辑组件在服务层为移动TV提供器提供了MBMS功能。BM-SC提供5个主要功能：会员、安全、会话和传送、代理和传输、以及服务通告。
3GPP版本6规定，BM-SC应当向GGSN发送组播IP分组。然而，在一些情况下，GGSN可能不支持组播操作。因此，在3GPP版本7中提出了另一选择以解决这一情况。BM-SC可以将IP组播分组封装在IP单播分组内，以向GGSN发送，这被称为IP-in-IP并在IETFRFC 2003中描述。
因此，需要一种能够动态地在单播隧道中发送组播分组的媒体服务器。还需要提供对单播分组中的IP组播分组的控制、封装和恢复。还需要使用RTSP来控制这种封装和恢复。
发明内容
本发明提出了一种扩展RTSP协议的方式，使媒体服务器能够动态地在单播隧道中发送组播分组。
根据本发明的第一方面，提供了一种对网络中组播媒体的传送进行控制的方法，在所述网络中，至少一些节点不支持组播分组的传送。所述方法包括：向媒体服务器发送用于向网络中的网关节点发送封装在单播封包内的组播分组的请求。所述请求包括组播目的地址的细节，以及网关节点的单播目的地址的细节。
优选地，所述请求根据RTSP来形成，优选地，所述请求是RTSPSETUP消息，尽管可以认识到，也可以使用其他协议和发起消息。优选地，组播目的地址和网关节点单播目的地址的细节包括在所述请求的传输首部和扩展首部中。
在一个实施例中，所述媒体服务器可以是IP网络中的流传输服务器，在这种情况下，优选地，对流传输服务器的请求由网关节点发送。例如，所述网关节点可以是LAN的网关节点，并且能够将组播数据流转发至LAN内的客户端终端。在这种情况下，组播目的地址应当包括在对RTSP消息的传输首部的扩展中。
在另一实施例中，所述媒体服务器可以是移动TV服务器(BM-SC中的业务量处理组件)，在这种情况下，所述请求可以由广播控制器(BM-SC中的信号处理组件)发送，所述网关节点可以是GGSN。在这种情况下，包括在对RTSP消息的传输首部的扩展中的是GGSN单播目的地址。
一旦针对要发送至网关节点的、封装在单播封包内的组播分组做出了请求，则媒体服务器可以优选地对具有组播目的地址的组播分组中的流传输数据进行编码，然后将组播分组封装在单播封包内，以形成具有网关节点单播目的地址的单播分组。然后，单播分组被发送至网关节点。网关节点去除单播封包以恢复组播分组，并向组播目的地址发送组播分组。
根据本发明的第二方面，提供了一种用于在网络中传送IP组播数据的网关节点。所述网关节点包括：接收机，用于从客户端终端接收用于订阅组播频道的指令。处理器操作连接至接收机，并被配置为产生对流传输服务器的请求(优选为RTSP消息)，所述请求针对封装在单播封包内的组播分组，所述请求包括组播目的地址以及网关节点的单播目的地址的细节。发射机操作连接至处理器，并被配置为向流传输服务器发送所述请求。
根据本发明的第三方面，提供了BM-SC中的BCC组件。BCC包括：接收机，用于从GGSN接收用于建立到组播目的地址的组播流传送的指令。处理器操作连接至接收机，并被配置为产生对BM-SC的移动TV服务器组件的请求(优选为RTSP消息)，所述请求针对要发送至GGSN的、封装在单播封包内的组播分组。所述请求包括组播目的地址以及GGSN的单播目的地址的细节。发射机操作连接至处理器，并被配置为向移动TV服务器发送所述请求。
根据本发明的第四方面，提供了一种用于传送组播流媒体数据的媒体服务器。所述媒体服务器包括：接收机，用于接收向网关节点发送封装在单播封包内的组播分组的请求(优选为RTSP消息)，所述请求包括组播目的地址以及网关节点的单播目的地址的细节。处理器被配置为对组播分组中的媒体数据进行编码，并将组播分组封装在单播封包内作为单播分组。发射机被配置为向网关节点发送单播分组。
附图说明
图1是使用单播分组来传送TV频道的网络中的单元的示意表示。
图2是使用组播分组来传送TV频道的相同网络中的单元的示意表示。
图3是用于广播/组播服务中心(BM-SC)的适当架构的示意。
图4是示意了当GGSN不支持组播时将BM-SC配置为将组播IP分组封装在单播IP分组内并建立组播会话所需的步骤的信令图。
图5是因特网中的一些节点的示意表示，示出了向两个LAN传送组播分组。
图6示意了当至少一些网关节点不支持组播时从流传输服务器向客户端终端传送IP组播流时涉及的组件之间的信令。
图7是能够建立封装在单播分组内的流传输IP组播分组的传送的网关节点的示意表示。
图8是能够将IP组播分组封装在单播分组内并将其向网关发送的媒体服务器的示意表示。
具体实施方式
为了解释而非限制的目的，以下描述阐述了具体细节，如特定实施例、过程、技术等。在一些实例中，省略了对于公知方法、接口、电路和设备的详细描述，以免不必要的细节模糊描述。此外，在一些图中示出了各个块。可以认识到，这些块的功能可以使用各个硬件电路、使用与适当编程的数字微处理器或通用计算机相结合的软件程序和数据、使用专用集成电路和/或使用一个或多个数字信号处理器来实现。
对实时流传输协议(RTSP)的一些特征的简要描述将有助于理解本发明的实施例。RTSP广泛用作流传输领域中的控制协议。它负责建立和控制一个或多个时间同步的音频/视频流。它本身不传送连续流，而是控制流传输服务器来进行传送。
RTSP中规定的命令包括以下内容：
1.DESCRIBE。它用于检索呈现或媒体对象的描述(例如编码、网络地址等)。通常，会话描述协议(SDP)(在IETF RFC 2327中定义)用于定义呈现描述的格式。SDP信息还可以通过HTTP下载或其他会话通告方法来检索。
2.SETUP：它用于分配流传送的资源并启动会话。如果会话中涉及多个媒体流，则需要对它们分别进行建立。
3.PLAY：它用于在经由SETUP分配的一个或多个流上启动数据传输。
4.PAUSE：它用于暂时停止流，而不释放分配给该流的资源。
5.TEARDOWN：它用于停止数据传输，并释放与流相关联的资源。
RTSP协议中定义的其他命令包括OPTIONS、ANNOUNCE、RECORD、GET_PARAMETER、SET_PARAMETER和REDIRECT。
移动TV
在移动TV的一种适当架构中，BM-SC具有单独的组件用于处理信令和数据业务量，如图3所示。BM-SC 301包括广播控制器(BCC)321和移动TV服务器(MTV服务器)322。BCC 321负责使用针对MBMS广播会话建立和管理而设计的Diameter协议，穿过Gmb信令接口来与GGSN 302交换信令。MTV服务器负责通过针对MBMS数据传送而设计的Gi接口来向GGSN 302发送业务量。BCC 321与MTV服务器322之间的接口使用RTSP协议。
为了建立组播，使用RTSP SETUP方法。传输首部指示要使用哪个传输协议，并配置参数，如目的地址、压缩、组播生存期和单一流的目的端口。这些值不是由呈现描述确定的。
如果存在已经支持IP组播的GGSN，则BCC 321可以使用传输首部来传递组播信息，如下：
BCC-＞MTV:SETUP rtsp://live.example.com/concert/audio RTSP/1.0
          CSeq:2
          Transport:RTP/AVP；multicast；destination＝224.2.0.1；
                    port＝4002-4003；ttl＝16
MTV-＞BCC:RTSP/1.0 200 OK
          CSeq:2
          Transport:RTP/AVP；multicast；destination＝224.2.0.1；
                    port＝4002-4003；ttl＝16
          Session:0456804596
BCC-＞MTV:SETUP rtsp://live.example.com/concert/video RTSP/1.0
          CSeq:3
          Transport:RTP/AVP；multicast；destination＝224.2.0.1；
                    port＝4004-4005；ttl＝16
          Session:0456804596
MTV-＞BCC:RTSP/1.0 200 OK
          CSeq:3
          Transport:RTP/AVP；multicast；destination＝224.2.0.1；
                    port＝4004-4005；ttl＝16
          Session:0456804596
BCC-＞MTV:PLAY rtsp://live.example.com/concert RTSP/1.0
          CSeq:4
          Session:0456804596
MTV-＞BCC:RTSP/1.0 200 OK
          CSeq:4
          Session:0456804596
由此可以看出，在两个SETUP请求中，BCC 321使用传输首部通知MTV服务器322组播目的地址(224.2.0.1)、音频流的端口号(4002-4003)和视频流的端口号(4004-4005)、以及生存期信息(16)。
在接收PLAY请求之后，MTV服务器322使用“200 OK”进行响应，然后将组播IP分组直接传送至GGSN 302。在这种情况下，RTSP非常好地适应了建立组播会话的需要。
如上所述，在一些情况下，GGSN可能不支持组播操作。因此，在3GPP版本7中提出了另一选择以解决这一情况。BM-SC可以将IP组播分组封装在IP单播分组内，以向GGSN发送。这被称为IP-in-IP并在IETF RFC 2003中描述。
即使GGSN不具有IP组播支持，它也可以接收单播IP分组，去除单播封包以恢复封装的组播分组，然后将组播分组转发至SGSN。因此，MBMS广播仍可以如先前所提出的那样操作。唯一的差别在于，BM-SC与GGSN之间的业务量是单播传送(具有内部的组播分组)。
然而，在当前定义的RTSP中，流传输信道可以被建立为单播或组播。先前不可能请求媒体服务器发出在单播隧道内封装的组播分组。
因此，如果有一些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.0
          CSeq:2
          Transport:RTP/AVP；multicast；destination＝224.2.0.1；
                    port＝4002-4003；ttl＝16
          X-GGSN:150.236.42.5
MTV-＞BCC:RTSP/1.0 200 OK
          CSeq:2
          Transport:RTP/AVP；multicast；destination＝224.2.0.1；
                    port＝4002-4003；ttl＝16
          Session:0456804596
BCC-＞MTV:SETUP rtsp://live.example.com/concert/video RTSP/1.0
          CSeq:3
          Transport:RTP/AVP；multicast；destination＝224.2.0.1；
                    port＝4004-4005；ttl＝16
          X-GGSN:150.236.42.5
          Session:0456804596
MTV-＞BCC:RTSP/1.0 200 OK
          CSeq:3
          Transport:RTP/AVP；multicast；destination＝224.2.0.1；
                    port＝4004-4005；ttl＝16
          Session:0456804596
BCC-＞MTV:PLAY rtsp://live.example.com/concert RTSP/1.0
          CSeq:4
          Session:0456804596
MTV-＞BCC:RTSP/1.0 200 OK
          CSeq:4
          Session:0456804596
注意，除传输首部中包括的组播目的地址(224.2.0.1)、音频和视频端口号(4002-4003和4004-4005)以及生存期信息(16)之外，SETUP消息现在还包括提供GGSN 302的单播目的地址(150.236.42.5)的X-GGSN扩展首部。
在本示例中，一旦接收到PLAY请求，MTV服务器322就使用“200OK”消息来响应BCC 321，将组播IP分组封装入单播IP分组，然后将单播IP分组传送至X-GGSN首部中描述的目的地址150.236.42.5。
图4是示意了当GGSN不支持组播时，将BM-SC配置为将组播IP分组封装在单播IP分组内并建立组播会话所需的步骤的示意。这些步骤如下所述：
401：从BCC 321向GGSN 302发送Diameter重新认证请求(RAR)(开始)命令。使用该命令，BCC 321指示GGSN 302和蜂窝网络中的其他下游节点激活MBMS承载资源。
402：从GGSN 302向BCC 321返回Diameter重新认证回答(RAA)(开始)响应。通过RAA响应，GGSN 302通知BCC 321它是否支持组播。如果不支持组播(如本情况)，还包括用于接收媒体流的其单播IP地址。
403：从BCC 321向MTV服务器322发送RTSP SETUP消息，以建立一个流(例如音频流)。如上所述，SETUP消息包括组播目的地址以及作为X-GGSN首部的、GGSN的IP单播地址。MTV 322返回200 OK响应。
404：从BCC 321向MTV 322发送另一RTSP SETUP消息，以建立另一流(例如视频流)，包括组播目的地址和GGSN IP单播地址。MTV322返回另一200 OK响应。
405：从BCC 321向MTV服务器322发送RTSP PLAY消息。MTV322返回200 OK响应。
406：MTV服务器322将媒体内容封装入组播分组。
407：然后，将组播分组封装入IP单播分组。
408：从MTV服务器322向GGSN 302传送IP单播分组。
409：在会话结束时，BCC 321向MTV服务器322发送RTSPTEARDOWN消息。
因特网
类似系统还可以用于通过因特网传送的组播分组。如同在移动TV中那样，RTSP协议还广泛用于因特网上客户端与流传输服务器之间的会话管理。
在多数情况下，数据流是以单播模式传送的，不论它们是视频点播还是直播流。对于直播流，由于预期所有接收机接收相同的内容，因此如果可以以组播模式进行传送将更加高效。这种分组的组播将节约业务量路径中的带宽，还将减小流传输服务器的负载。
然而，如果通过因特网来执行组播传送，则需要业务量路径中的所有路由器都具有组播支持。此外，需要运营商的防火墙端口为输入组播分组开启。出于安全原因，一些防火墙禁用组播分组的接收。
典型地，IP组播更广泛地用于局域网(LAN)中，而不是贯穿整个因特网。因此，考虑与以上针对移动TV的描述类似的方案是现实的。可以从流传输服务器向LAN网关传送单播流。然后在LAN内部，可以以组播来传送单播的内容。
根据3GPP版本7提出的方法，媒体服务器可以将IP组播分组封装在单播分组内。然后，网关节点可以去除单播封包，并在局域网中对分组进行组播。然后，可以穿过因特网来发送组播分组，不论中间路由器是否提供组播支持。此外，仍可以实现组播固有的效率，因为从媒体服务器向网关节点仅需要一个传送信道，然后，网关节点将该分组组播至所有客户端。
按照这一提议，在RTSP信令接口上存在与移动TV相同的问题。按照当前定义的RTSP，网关节点不能要求媒体服务器发出封装在单播隧道内的组播分组。
这种功能和部署的实现需要一种网关节点，以下称为组播至单播GW，组播至单播GW具有两种主要功能：
1.在信号平面中，组播至单播GW代表LAN中的客户端向流传输服务器建立RTSP会话；
2.在业务量平面中，组播至单播GW将单播IP分组转换为组播IP分组，并向LAN中的客户端流传输组播分组。流传输服务器该将组播IP分组封装在单播IP分组内，并且组播至单播GW去除单播IP“封包”并直接对内部的组播IP分组进行组播。
参照图5可以理解这一点，图5是因特网中的一些节点的示意表示，示出了向两个LAN 506、507传送组播分组。每个LAN包括组播至单播GW 504、505和4个终端511-518。防火墙502、503保护每个组播至单播GW 504、505。流传输服务器501向组播至单播GW 504、505发送封装在单播“封包”内的组播IP分组。组播至单播GW 504、505从单播封包恢复组播分组，并将其以组播转发至其自身LAN内的终端。从流传输服务器501发送的单播分组可以通过不具有组播功能的路由器，还可以通过防火墙502、503。
在当前的RTSP协议中，必须以单播模式或组播模式来传送业务量。先前没有提供机制以确保可以指示流传输服务器将组播分组封装为单播分组。
因此，提出以与以上在移动TV上下文中的描述类似的方式来扩展RTSP协议。按照当前使用的RTSP，在传输首部中传递网关IP地址和端口号，使得知晓RTSP的防火墙允许业务量通过。RTSP的扩展涉及在扩展首部中传递组播目的地址、端口号和生存期信息。在以下示例中，扩展首部被标记为“X-Multicast-Transport”。
GW-＞SS:SETUP rtsp://live.example.com/concert/audio RTSP/1.0
        CSeq:2
        Transport:RTP/AVP；unicast；client_port＝3456-3457
        X-Multicast-Transport:destination＝224.2.0.1；
                              Port＝4002-4003；ttl＝16
SS-＞GW:RTSP/1.0 200 OK
        CSeq:2
        Transport:RTP/AVP；unicast；client_port＝3456-3457；
                  server_port＝5000-5001
        X-Multicast-Transport:destination＝224.2.0.1；
                              Port＝4002-4003；ttl＝16
        Session:0456804596
GW-＞SS:SETUP rtsp://live.example.com/concert/video RTSP/1.0
        CSeq:3
        Transport:RTP/AVP；unicast；client_port＝3458-3459
        X-Multicast-Transport:destination＝224.2.0.1；
                              Port＝4004-4005；ttl＝16
        Session:0456804596
SS-＞GW:RTSP/1.0 200 OK
        CSeq:3
        Transport:RTP/AVP；unicast；client_port＝3456-3457；
                  server_port＝5002-5003
        X-Multicast-Transport:destination＝224.2.0.1；
                              Port＝4004-4005；ttl＝16
        Session:0456804596
GW-＞SS:PLAY rtsp://live.example.com/concert RTSP/1.0
        CSeq:4
        Session:0456804596
SS-＞GW:RTSP/1.0 200 OK
        CSeq:4
        Session:0456804596
因此，在移动TV的情况下，除了先前已知的组播目的地址之外，RTSP SETUP消息还传递单播GGSN目的地址。在因特网的情况下，除了先前已知的网关单播目的地址之外，RTSP SETUP消息还传递组播目的地址和端口号。
因此，组播至单播网关504、505代表在其局域网中的客户端511-518，在信令平面中发送和接收RTSP消息。当客户端希望订阅组播流时，它可以使用例如因特网组管理协议(IGMP)或组播监听者发现(MLD)来发送“加入”请求。然后，组播至单播网关负责发送SETUP和PLAY请求。当特定组播至单播网关所服务的所有客户端都停止接收(例如通过发送IGMP或MLD离开消息)时，网关负责发送TEARDOWN请求。
一旦请求了组播流，流传输服务器将组播IP分组封装在单播封包内，并发送到组播至单播网关。在业务量平面中，组播至单播网关必须去除这些单播IP封包，并将内部的IP分组组播至其LAN中的客户端。
图6示意了在从流传输服务器501向组播至单播GW 504所服务的LAN 506中的第一和第二客户端终端511、512进行组播流的传送中涉及的、图5中所示的一些组件之间的信令。这些步骤如下：
601：第一客户端511向组播至单播GW 504发送IGMP或MLD加入命令，指示第一客户端要观看频道。
602：组播至单播GW 504向流传输服务器501发送两个RTSPSETUP消息，请求封装在单播封包中的组播分组。如上所述，RTSPSETUP消息包括组播细节和组播至单播GW 504的单播地址。
603：在本示例中，第二客户端512还向组播至单播GW 504发送IGMP或MLD加入命令，以订阅与第一客户端511相同的频道。已经在组播至单播GW 504与流传输服务器501之间进行的建立信令不受第二加入命令的影响。
604：一旦建立了会话，则组播至单播GW 504向流传输服务器501发送RTSP PLAY消息，指示流传输开始。
605：流传输服务器501将内容放入组播分组。
606：将组播分组封装在IP组播分组中。
607：流传输服务器向组播至单播GW 504发送IP组播分组。
608：组播至单播GW 504从其单播封包中提取组播分组。
609：组播至单播GW 504向第一和第二客户端终端511、512转发组播分组。
610：第二客户端终端512决定停止观看该频道并向组播至单播GW 504发送IGMP或MLD离开命令。由于第一客户端终端511仍订阅该频道，组播至单播GW 504不进行任何动作。
611：第一客户端终端511决定停止观看该频道并向组播至单播GW 504发送IGMP或MLD离开命令。在本示例中，这是LAN 506中离开该频道的最后一个客户端。
612：一旦最后一个客户端离开该频道，组播至单播GW 504向流传输服务器501发送RTSP TEARDOWN消息，以代表客户端关闭RTSP会话。
图7是用于提供IP组播服务的网关节点701的示意表示，网关节点701可以是参照图5和6描述的类型的组播至单播GW 504。网关节点包括：接收机702，用于在信号平面中从局域网内的客户端终端接收用于订阅组播的指令。微处理器703处理这些指令，并经由发射机704向流传输服务器发起要发送的RTSP建立信令，以请求封装在单播封包内的组播数据分组。微处理器确保建立信令提供组播目的地址的细节以及节点自身的单播地址的细节。在业务量平面上，当从流传输服务器接收到单播分组时，将其临时保存在存储器705中，同时微处理器703去除单播封包以提取封装在其中的组播分组。然后，发射机704向局域网中的客户端发送组播分组。
图8是用于提供IP组播服务的媒体服务器801的示意表示，媒体服务器801可以是参照图3和4描述的类型的MTV服务器322，或者参照图5和6描述的类型的流传输服务器501。媒体服务器801包括：接收机802，用于在信号平面中，从BCC 321或组播至单播GW 504接收用于发送封装在单播封包内的组播分组的指令。所述指令包含组播目的地址的细节，以及单播分组应当被发送至的网关节点的单播地址的细节。微处理器803处理这些指令并对组播分组内的内容(例如存储在存储器805中的内容)进行编码，然后将组播分组封装在单播封包内。发射机804通过局域网，在业务量平面上向网关节点发送单播IP分组。
可以认识到，根据上述实施例的变化仍落入本发明的范围内。例如，已经描述了BM-SC的一种可能架构，但是可以认识到，其他架构可能也是合适的。此外，已经特别参照在LAN内传送组播分组的网关节点描述了通过因特网的组播分组传送。可以认识到，可以想到其他配置。
此外，总体上参照对RTSP协议的可能扩展描述了本发明。可以认识到，也可以使用其他协议来执行建立封装在单播封包中的组播分组的传送所需的信令。例如，可以使用会话发起协议(SIP)来执行信令。
尽管已经详细示出和描述了各个实施例，但是权利要求不限于任何具体实施例或示例。以上描述不应被理解为暗示任何具体元件、步骤或功能是必不可少的，而使其必须被包括在权利要求的范围中。保护范围由权利要求来限定。

Claims (14)

1.一种对网络中组播媒体的传送进行控制的方法，在所述网络中，至少一些节点不支持组播分组的传送，所述方法包括：
向媒体服务器发送实时流传输协议“RTSP”消息，以请求媒体服务器向网络中的网关节点发送封装在单播封包内的组播分组；
其中，所述请求包括组播目的地址的细节，以及网关节点的单播目的地址的细节。
2.根据权利要求1所述的方法，其中，组播目的地址的细节和网关节点的单播目的地址的细节包括在所述请求的首部中。
3.根据权利要求1或2所述的方法，其中，所述媒体服务器是IP网络中的流传输服务器，其中，对流传输服务器的请求由网关节点发送。
4.根据权利要求3所述的方法，其中，网关节点的单播目的地址包括在所述请求的传输首部中，组播目的地址包括在所述请求的扩展首部中。
5.根据权利要求1或2所述的方法，其中，所述媒体服务器是广播/组播服务中心“BM-SC”中的业务量处理组件，所述请求由BM-SC中的信号处理组件发送，所述网关节点是网关GPRS支持节点“GGSN”。
6.根据权利要求5所述的方法，其中，组播目的地址包括在所述请求的传输首部中，网关节点的单播目的地址包括在所述请求的扩展首部中。
7.根据权利要求1或2所述的方法，还包括：
在媒体服务器处，对具有组播目的地址的组播分组中的流传输数据进行编码；
将组播分组封装在单播封包内，以形成具有网关节点的单播目的地址的单播分组；
将单播分组发送至网关节点；
在网关节点处，去除单播封包以恢复组播分组；以及
向组播目的地址发送组播分组。
8.一种用于在网络中传送IP组播数据的网关节点，包括：
接收机，用于从客户端终端接收用于订阅组播频道的指令；
处理器，操作连接至接收机，并被配置为产生对流传输服务器的实时流传输协议“RTSP”消息，以请求封装在单播封包内的组播分组，所述请求包括组播目的地址的细节以及网关节点的单播目的地址的细节；以及
发射机，操作连接至处理器，并被配置为向流传输服务器发送所述请求。
9.根据权利要求8所述的网关节点，其中，所述网关节点还被配置为：
接收包含封装在单播封包内的组播分组在内的单播分组；
从单播分组中恢复组播分组；以及
向组播目的地址发送恢复的组播分组。
10.一种广播/组播服务中心“BM-SC”中的信号处理组件，包括：
接收机，用于从网关GPRS支持节点“GGSN”接收用于建立到组播目的地址的组播流传送的指令；
处理器，操作连接至接收机，并被配置为产生对BM-SC的移动TV服务器组件的请求，所述请求针对要发送至GGSN的、封装在单播封包内的组播分组，所述请求包括组播目的地址以及GGSN的单播目的地址的细节；以及
发射机，操作连接至处理器，并被配置为向移动TV服务器发送所述请求。
11.根据权利要求10所述的信号处理组件，被配置为使得发送至移动TV服务器的请求是实时流传输协议“RTSP”消息。
12.一种用于传送组播流媒体数据的媒体服务器，包括：
接收机，用于接收用于向网关节点发送封装在单播封包内的组播分组的实时流传输媒体“RTSP”请求，所述请求包括组播目的地址的细节以及网关节点的单播目的地址的细节；
处理器，被配置为对组播分组中的媒体数据进行编码，并将组播分组封装在单播封包内作为单播分组；以及
发射机，被配置为向网关节点发送单播分组。
13.根据权利要求12所述的媒体服务器，其中，所述媒体服务器是IP网络中的流传输服务器，其中，所述请求是从网关节点接收的。
14.根据权利要求12所述的媒体服务器，其中，所述媒体服务器是广播/组播服务中心“BM-SC”中的业务量处理组件，所述请求是从BM-SC的信号处理组件接收的。
CN2008801266861A 2008-02-25 2008-02-25 组播数据的传送 Active CN101946458B (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2008/052270 WO2009106127A1 (en) 2008-02-25 2008-02-25 Delivery of multicast data

Publications (2)

Publication Number Publication Date
CN101946458A CN101946458A (zh) 2011-01-12
CN101946458B true CN101946458B (zh) 2013-11-20

Family

ID=39485148

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2008801266861A Active CN101946458B (zh) 2008-02-25 2008-02-25 组播数据的传送

Country Status (4)

Country Link
US (1) US8542622B2 (zh)
EP (1) EP2248300B1 (zh)
CN (1) CN101946458B (zh)
WO (1) WO2009106127A1 (zh)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101946458B (zh) * 2008-02-25 2013-11-20 艾利森电话股份有限公司 组播数据的传送
US9113440B2 (en) 2008-10-31 2015-08-18 Nec Corporation Mobile communication system, core network node, control station, base station, communication method and program
US20100309913A1 (en) * 2009-06-05 2010-12-09 Nick Herodotou Method and system for handling iptv multicast traffic in a home network
WO2011045887A1 (ja) * 2009-10-13 2011-04-21 日本電気株式会社 ゲートウェイ装置、移動通信システム、移動端末、パケット転送制御方法、移動端末の制御方法、及び非一時的なコンピュータ可読媒体
US9491735B2 (en) * 2010-12-19 2016-11-08 Motorola Solutions, Inc. System and method in a communication network of dynamically assigning a multimedia broadcast/multicast service bearer to a multicast channel
KR101774482B1 (ko) * 2011-04-05 2017-09-05 에스케이플래닛 주식회사 동영상 전송 시스템 및 그 전송방법, 및 동영상 재생 단말기 및 그 재생방법
US9148366B2 (en) * 2011-04-11 2015-09-29 Qualcomm Innovation Center, Inc. Interactive header compression in peer-to-peer communications
US9420259B2 (en) * 2011-05-24 2016-08-16 Comcast Cable Communications, Llc Dynamic distribution of three-dimensional content
US8887222B2 (en) 2011-09-14 2014-11-11 Qualcomm Incorporated Multicasting in a wireless display system
JP5991059B2 (ja) * 2012-07-27 2016-09-14 富士通株式会社 オフロード装置、ネットワークシステムおよびマルチキャストトラヒックのハンドオーバ方法
CN103916715B (zh) * 2014-04-11 2019-01-11 浙江宇视科技有限公司 基于网段的自适应监控方法及装置
US20160142219A1 (en) * 2014-11-13 2016-05-19 Qualcomm Incorporated eMBMS Multicast Routing for Routers
CN107770221B (zh) * 2016-08-19 2021-05-14 阿里巴巴集团控股有限公司 数据的传输方法、服务器转换装置、客户端转换装置及系统
CN108668178B (zh) * 2017-03-31 2020-12-04 华为技术有限公司 一种组播实现方法及相关网络设备
WO2019034005A1 (zh) 2017-08-14 2019-02-21 华为技术有限公司 一种组播方法及装置
CN109391909B (zh) * 2017-08-14 2021-05-14 华为技术有限公司 一种组播方法及装置
CN108270768A (zh) * 2017-11-28 2018-07-10 北京文香信息技术有限公司 一种基于rtsp/rtmp协议的单端口双向交互协议
CN110012437B (zh) * 2018-01-05 2021-02-23 华为技术有限公司 一种组播报文的发送方法、装置及系统
CN111447482A (zh) * 2020-05-13 2020-07-24 威盛电子股份有限公司 串流媒体同步播放方法及串流媒体同步播放系统
WO2021261175A1 (ja) * 2020-06-23 2021-12-30 日本電気株式会社 通信システム、通信装置、通信方法及び非一時的なコンピュータ可読媒体
CN114915589A (zh) * 2021-02-10 2022-08-16 华为技术有限公司 报文传输方法及装置
CN116074297A (zh) * 2021-10-29 2023-05-05 中国电信股份有限公司 视频传输方法、系统和相关设备
CN116055437A (zh) * 2023-04-03 2023-05-02 四川汉科计算机信息技术有限公司 一种本地多对象的消息转发方法、装置、计算机和介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101123527A (zh) * 2007-02-25 2008-02-13 华为技术有限公司 一种流媒体系统、信令转发设备以及流媒体发送方法

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6523696B1 (en) * 1996-10-15 2003-02-25 Kabushiki Kaisha Toshiba Communication control device for realizing uniform service providing environment
US6189039B1 (en) * 1997-04-10 2001-02-13 International Business Machines Corporation Selective tunneling of streaming data
FI20021832A0 (fi) * 2002-10-15 2002-10-15 Nokia Corp Menetelmä ja järjestelmä pakettidatan reitittämiseksi ja vuon valvomiseksi
SE0301053D0 (sv) * 2003-04-07 2003-04-07 Ericsson Telefon Ab L M Method and system in a communications network
US7925778B1 (en) * 2004-02-13 2011-04-12 Cisco Technology, Inc. Method and apparatus for providing multicast messages across a data communication network
FI20041075A0 (fi) * 2004-08-12 2004-08-12 Nokia Corp Tiedon lähettäminen ryhmälle vastaanottolaitteita
JP2006074132A (ja) * 2004-08-31 2006-03-16 Matsushita Electric Ind Co Ltd マルチキャスト通信方法及びゲートウェイ装置
US8442031B2 (en) * 2005-06-24 2013-05-14 Alcatel Lucent Method and apparatus for utilizing network services in a manner substantially transparent to service endpoints
US20070116051A1 (en) * 2005-11-23 2007-05-24 Chen An M Method and apparatus for transporting IP datagrams over FLO network
CN101946458B (zh) * 2008-02-25 2013-11-20 艾利森电话股份有限公司 组播数据的传送

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101123527A (zh) * 2007-02-25 2008-02-13 华为技术有限公司 一种流媒体系统、信令转发设备以及流媒体发送方法

Also Published As

Publication number Publication date
EP2248300A1 (en) 2010-11-10
US8542622B2 (en) 2013-09-24
EP2248300B1 (en) 2013-06-12
US20100329172A1 (en) 2010-12-30
CN101946458A (zh) 2011-01-12
WO2009106127A1 (en) 2009-09-03

Similar Documents

Publication Publication Date Title
CN101946458B (zh) 组播数据的传送
EP1421736B1 (en) Method and device for multicasting in a umts network
CN112369038B (zh) 用于在实时上行链路流式传输服务中分发媒体的方法
Cho et al. Improvement of channel zapping time in IPTV services using the adjacent groups join-leave method
TWI223532B (en) Method and apparatus for data packet transport in a wireless communication system using an Internet Protocol
CN101136814B (zh) 一种支持mbms业务的方法和装置
CN101238741B (zh) 用于广播即按即说群会话的方法和设备
CN101116306A (zh) 在分组交换网络上的按需多频道流会话
KR20070108169A (ko) 멀티미디어 브로드캐스트 멀티캐스트 서비스(ｍｂｍｓ)용개선된 자원 활용
MXPA04003141A (es) Metodo y aparato para el transporte de paquete de datos en un sistema de comunicaciones inalambrico utilizando un protocolo de internet.
JP2010098761A (ja) マルチキャスティング装置
CN102577304A (zh) 动态rtcp转发
US20090010193A1 (en) System and method of multicasting multimedia streams
WO2010020193A1 (zh) 一种提供实时场景的多媒体系统及其实现方法
US9288136B2 (en) Method and apparatus for in-band channel change for multicast data
CN101588251A (zh) 一种ims即时消息群发的方法及设备
KR100801612B1 (ko) 디지털 멀티미디어 방송과 동기화된 실시간 쌍방향 통신 방법
WO2009145293A1 (ja) サーバ装置と通信方法ならびにプログラム
KR100612674B1 (ko) 이동통신 시스템에서 양방향 멀티미디어 콘텐츠 서비스제공 방법
Bataa et al. A functional design of BM-SC to support mobile IPTV in LTE network
KR101844954B1 (ko) 멀티미디어 방송 서비스 시스템, 멀티미디어 방송 중계를 위한 무선 중계장치 및 그 멀티미디어 방송 중계방법
EP3588847A1 (en) Multicast signal transmitting and receiving method and device
KR101837161B1 (ko) 멀티미디어 방송 서비스 시스템, 멀티미디어 방송 중계를 위한 무선 중계장치 및 그 멀티미디어 방송 중계방법
Zafar et al. Supporting transcoding-based multicast groups
KR100621328B1 (ko) 멀티캐스팅에 관한 정보를 이용한 멀티미디어 스트리밍서비스 제공 방법 및 시스템

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant