组管理支持增强

在当前多播业务模型中，请求接收多播业务数据的用户通过一个特定网络接口申请加入某个多播组。因此，用户不但要选择想要的多播业务，还要隐含地指明多播承载的类型和传输使用的网络。此外，在接收端多播业务的一个应用通常会在整个会话期间保持连接。为克服这个不灵活的缺陷，需要对多播用户业务和网络中多播承载业务的业务流进行“去耦合”（decoupling）操作。

组管理支持提供必要的机制来实现要求的去耦合。接收端会通过在多播业务的组管理中向一个网络层无关的组（network-layer-independent group）申请来表示它想要接收一个多播用户业务，而不是直接向一个网络层的多播组申请。考虑到资源管理决策，一个多播业务会话可以动态出现在不同的业务流和网络连接中，由此反映出接收端和所在位置可获得的接入网络的异构性。

如图11.6所示，组管理支持包含一个网络侧的环境感知式组管理实体和一个终端侧的多播中间设备。此外，要在组管理和终端的多播中间件间实现所需控制信令的扩展传输，需要使用一个多播信令信道。这些实体的详细介绍及它们对实现所需多播传输协作的作用将在下面介绍。

1.组管理实体

组管理支持在提供多播业务时有两个重要作用。首先，它为一个多播业务积累并维护当前多播接收端的信息，同时协助RM（Resource Manager，资源管理），通过提供用户的相关的环境信息及其他相关服务信息来进行决策。其次，它通过执行RM的决策为传输协作提供必要的会话管理功能。这个功能通过3个功能块实现，GMMF（Group Membership Management Function，组成员管理功能）、SCF（SessionControl Function，会话控制功能）和NMF（Network Management Function，网络管理功能）。这3个功能将在下面简略介绍。

GMMF用于多播业务中的组成员关系的收集和维护。它提供一组用于创建和管理多播组的功能原语集和其他的服务相关参数。功能原语可以分为两类，一类用于服务提供商在GM（Group Manager组管理者）中配置多播业务，另一类用于移动用户注册特定业务。SCF提供网络侧实现多播传输协作需要的会话管理功能。SCF的任务就是实现RM的决策。它以在接收端通过中间件管理网络层服务的方式，实现了会话层的控制平面机制。NMF处理网络侧配置，这是接入网的多播承载管理所必需的。例如，MBMS要求在多播承载业务建立前配置BM-SC（广播多播服务中心）中的多播承载层业务参数。NMF在SCF触发建立各自在接收端的多播承载层业务前为BM-SC提供需要的服务参数。同样，NMF在DVB网络中配置适当的DVB/IP网关或网关管理。

2.多播信令信道

多播数据传输协作中控制面的引入增加了网络的信令负载。一种传输控制信令的方法是对每个接收端单独发送信令信息。然而，由于大量潜在用户的存在，网络所需的信令负载可能会显著增加。因此，要使附加的控制面的影响尽可能低，这种信令的扩展传输极为关键。(www.xing528.com)

基于实际情况的分析显示，一个控制信令信息通常针对一个较大的接收子集。因此可以应用多播信令信道。多播信令信道能为大量接收端的控制面信令提供扩展传输。对于每个多播用户业务，需要在控制平面上使用一个单独的多播信令信道。用户向GM申请多播业务后，多播中间设备开始监听各自的多播信令信道以接收来自GM的通知。

3.多播中间设备

用户终端的组管理支持通过多播中间设备来实现，多播中间设备位于应用层下面，使低层传输和移动终端的网络层协议栈不必改变。中间设备的目的是在终端上管理SCF所示的网络层服务。此外，在整个多播会话生存期内，它向应用层屏蔽了基础网络连接的差异性。中间设备能拦截应用层对多播套接字的调用，以这种方式控制实际网络套接字的运行。

一旦用户选择申请一个多播业务，多播中间设备就开始监听由相应的服务声明指定的多播信令信道。申请后，网络中的GM控制多播会话并通过多播信令信道与终端的中间件交互。基于GM的通知，中间设备层打开或关闭各自接口上需要的多播网络套接字，建立或释放指定的多播承载并将接收到的会话数据传输到应用层程序。图11.7描述了多播中间设备的基本操作。下列服务实例更详细地阐述了步骤，并且给出了一个涉及组管理支持功能中不同实体间的必要信令的传输过程的概述。

图11.7 多播中间设备隐藏来自应用的不同承载业务