UMTS动态多播技术深度解析

在MBMS中，多播路由通过一种自下而上的方式产生。下游节点通知各自的上游父节点请求接收指定的多播业务。然而，这需要执行额外的位置更新流程。如果由于多播组成员的移动性，造成位置更新频繁发生，重建多播树将会造成很大的成本消耗。在很多情况下，重建整个多播树明显不是最优的方案。

在另一方面，多播路由也可以通过让每个节点动态地决定哪个下游节点希望接收多播信息来自上而下地进行，类似于单播路由的生成方法。在这种方法中，不需要改变现有的位置更新流程，不但能使多播机制有效应对移动性和组动态问题，还能节省网络成本。

图9.1给出了UMTS网络的一个子集。在这个架构中，有两个SGSN连接到GGSN，另外还有3个RNC和9个Node B。BM-SC是多播业务源。我们假设BM-SC和GGSN处于同一位置。在多播中，只有拥有多播用户的Node B才能转发多播包。因此在图9.1中，Node B1、Node B3、Node B4和Node B8能接收到BM-SC发出的多播包。为了在网络中动态地确定多播包的路由，需要执行以下步骤：

1）BM-SC发送多播包，并将其发送给已经注册接收多播业务的GGSN。

2）GGSN接收多播包，同时通过查询多播路由记录来决定哪个下游SGSN在它们各自的服务区域内拥有多播用户。“下游”是指一个节点相对于另外一个节点和相对于多播数据流传输走向的相对拓扑位置关系。在图9.1中，GGSN复制多播包并将其发送给SGSN1和SGSN2。

3）两个目的SGSN都接收到多播包，然后查询各自的多播路由记录，来决定哪些RNC可以接收多播包。在这种做法中，SGSN可能会寻呼状态为PMM-IDLE的已注册的多播用户。

4）目的RNC接收到多播包后将其转发给已经为多播应用建立了适当无线承载的Node B。在图9.1中，就是指Node B1、Node B3、Node B4和Node B8。而在RNC没有跟踪任何小区级的多播用户的情况下，可能会涉及寻呼流程。(www.xing528.com)

5）多播用户通过WCDMA空中接口接收多播包。

图9.1 UMTS中多播消息发送

但是，在不修改现有的UMTS路由和移动性管理机制的情况下，执行上述动态多播方案是很困难的。相对地，基于广播方式或一对多单播方式的多播方案则非常容易实现，只需对现有的UMTS功能做微小修改。通过使用广播方式，多播消息被简单地发送到网络中的所有节点。因此图9.1中尽管在Node B2、Node B5、Node B6、Node B7和Node B9没有多播用户，所有的9个Node B都会接收到多播数据。通过一对多单播，每个多播报文分组分别发送给多播组中每个成员。在图9.1中，以Node B1为例，它将接收到同一个多播消息的3份副本。因此，在考虑带宽使用的情况下，广播和一对多单播都不是最优方案。一对多路由方案的效率取决于网络中用户组的分布。

现在描述我们提出的动态多播机制，它可以用最少的分组副本来进行多播传输，同时保持对移动性和组动态的快速响应性。我们描述各个网络节点都维护怎样的多播记录，这些记录如何建立，又是如何通过标准位置更新流程来维护，以及这些多播数据分组是如何向多播组的用户发送的。