3G移动网络中的组播与广播

来管理一个动态数据分配树。在IP组播时，核心网的每个节点都向服务注册用户的下游节点来转发MBMS数据。

下面的例子给出了使用流媒体业务时移动广播实现方式的优势。图2中的几个手机电视用户分别观看三类不同频道的流媒体，它们通过单播方式来实现。在这种情况下每个用户与流媒体服务器间都要建立一条独立的流媒体连接。服务器和网络业务的负载与用户的数目直接相关。在该例子中由于总共有10个用户使用该业务，因此流媒体服务器必须处理10个流媒体连接。不难看出，随着用户数目的增加，服务器的负载将迅速增加，同时核心网和无线接入网的业务量也会大大增加。

图2　非MBMS支持的手机电视业务

图3给出了同样情况下由MBMS支持的手机电视业务。在此情况下服务器只向MBMS BM-SC传送三个媒体流，每个频道一个。每个频道的数据流在核心网内根据需要单独的进行复制。从图中可以清楚的看出，此时的流媒体服务器只需要同时处理三个媒体流。在无线侧MBMS方式使用了三条并行的广播信道，这样就可以很好地解决了无线侧的瓶颈问题。其实在3GPP2中BCMCS也是这样实现的。

图3　MBMS支持的手机电视业务

此外，MBMS和BCMCS除了支持上述的流媒体传送方式外，MBMS还支持任意文件从一个数据源到多个接收者的高效下载。目前，MMS的传送也是采用点到点方式，在将来MMS系统可以通过标准接口与BM-SC相连，从而便可以通过MBMS来传送MMS业务，这样可以方便地通过MMS来向用户发送视频片断和体育赛事。与MBMS不同的是，在BCMCS中对文件传送业务所需的协议没有作出明确的规定。

通过MBMS的广播/组播方式来传送文件是需要特别注意的。我们知道，在下行方向广播和组播都是单向传送的。因此传输控制协议（TCP）是不能使用的，因为TCP协议需要一条双向连接。为此因特网工程任务组（IETF）提出了单向传输的文件传送（FLUTE）架构。FLUTE架构中是将用户数据报协议（UDP）作为它的底层传输协议。然而UDP是不可靠的，因此FLUTE通过增加前向纠错码（FEC）来增加对封装数据的保护。但是我们知道，再强的纠错方式也不能保证传输的毫无差错，因此MBMS还定义了点到点的文件修复过程。在广播数据传送完成后，如果发现文件有错，接收者便可以连接到修复服务器上并要求对出错的数据重传，这样MBMS便可以保证文件传输的可靠性了。

四、典型的MBMS工作流程

图4给出了MBMS的典型工作流程。BCMCS的工作流程也是类似的，为了描述的简洁，此处仅用MBMS来说明。

图4　MBMS会话的典型流程

开始，特定的MBMS业务信息被送到业务服务器中，该信息通常看作是业务通知。业务通知提供了相应的业务信息和终端如何访问它。将MBMS业务通知传送给终端用户可以有多种实现方式。最简单的实现方式就是将其存储在Web服务器中，用户可以通过超文本传输协议（HTTP）或者无线应用协议（WAP）来下载。当然也可以利用现存的短信或者彩信的推送（push）机制来传送该业务通知。还可以利用专门的MBMS业务通知信道来传送。

在终端用户接收到业务通知后，用户使用业务的方式取决于业务是广播方式还是组播方式。如果业务是广播方式，那么用户终端只需要简单的"调谐"到相应的信道（在业务通知中有详细的参数描述）上就可以了。如果业务是组播方式，那么用户必须向网络发起会话加入（session join）请求，这样用户便会成为相应MBMS业务组的一位成员，因而可以接收到组播业务的数据了。

在传输开始时，BM-SC必须向GGSN发送会话开始（session start）请求。然后GGSN将分配所需的因特网资源，并将该请求前转到相应的SGSN，这些SGSN同样根据业务质量（QoS）来分配所需的无线资源。最后，MBMS业务组中的终端将被通知要开始传送组播业务数据了。

服务器接着将多媒体数据发送给BM-SC，随后BM-SC会将这些数据转发到MBMS的承载层。这样数据便会发送到加入MBMS业务组的所有终端了。

最后，服务器发送会话结束（session stop）通知，表示数据传输阶段已经结束。想离开MBMS组播业务的终端用户，可以向网络发送业务离开（service leave）请求，随后网络便将该用户从MBMS业务组中删除。

五、无线接入网中广播和组播的承载

对于MBMS和BCMCS，GSM、WCDMA和CDMA2000都分别已经定义了广播和组播的承载方式。由于广播和组播无线承载必须同时服务多个用户，因此许多为高速、双向点到点通信开发的速率、容量增强功能都无法使用。换句话说，信号不能分别适应每个用户，它必须要保证最差无线条件下用户的通信，因