MBMS激活与去激活详解

MBMS多播服务激活流程由UE启动，UE借此将其接收MBMS用户服务数据的请求进行注册。这个流程能够启动MBMS多播承载路径的建立（如果在此之前承载路径的建立还没有被同区域的其他UE触发的话），并且在UE、SGSN、GGSN和UTRAN为已激活MBMS承载服务建立MBMS UE上下文。

图6.5向我们展示了MBMS多播服务激活流程的信令流概况。执行激活通常需要借助默认的“尽力而为式”（best-effort）的单播PDP上下文，感兴趣接收端必须为使用IGMP或MLD的组管理信令建立这个上下文。在接下来的内容里，我们将更详细地描述图6.5的每个步骤，REQ和RES分别是请求和响应的缩写。

1）UE通过事先建立的默认PDP上下文向GGSN发送IGMP或MLD成员信息报告，以标识出它有兴趣加入的MBMS承载服务的IP多播地址。这个IP多播地址是从MBMS服务声明获知的。

图6.5 MBMS服务激活流程

2）GGSN截获这个IGMP或MLD成员信息报告，从中提取出IP多播地址，并且（如果这是第一次接收到那个UE发来的报告）尝试为这个正在激活的UE从BM-SC处获取MBMS授权。BM-SC中的组成员信息功能可能会检查用户是否进行了合法订制。如果是的话，BM-SC就在MBMS授权响应中提供用于创建UE上下文的APN。如果授权失败，这个流程就终止。

3）GGSN发送MBMS通知请求，从而为SGSN提供IP多播地址、APN以及PDP上下文的已连接NSAPI，其中IGMP信令接收于PDP上下文。然后SGSN在MBMS通知响应中向GGSN表明这个流程是否能够继续进行，也就是说，UE和SG-SN是否都支持MBMS。

4）接下来，SGSN通过MBMS上下文激活消息，在UE端启动MBMS UE上下文激活，以提供IP多播地址、APN、已连接的NSAPI和唯一的TI。

5）UE利用SGSN提供的参数创建MBMS UE上下文，并且向SGSN发送激活MBMS上下文请求，提供UE用到的所有参数以标识这个UE上下文，这些参数中包括UE自己的MBMS承载功能，以表明它可以提供的最佳QoS。如果SGSN中已经存在一个MBMS承载上下文，SGSN接下来就会验证支持UE的MBMS承载功能不低于MBMS会话的要求。如果这样，UE的激活MBMS上下文请求就被拒绝。否则就继续下面的流程，并通过激活MBMS上下文认可消息向UE表明现时流程的成功结束。

6）如果出于某些原因并没有建立MBMS UE上下文，SGSN就会将这一失败通知给GGSN。这是由MBMS通知拒绝请求消息来表明失败，从而完成这个通知。然后GGSN删除所有相关状态，并且用MBMS通知拒绝响应向SGSN表明这个流程的结束。

7）可能执行UE认证等安全性功能。

8）SGSN创建MBMS UE上下文，并向GGSN发送创建MBMS上下文请求，我们用多播承载服务的相关APN标识这个请求。请求中除了包含IP多播地址、APN和MBMS NSAPI之外，还包含多个UE相关参数，例如IMSI、MSISDN（Mobile Subscriber ISDN Number，移动用户的ISDN号码）、用户的电话号码或者IMEI。

9）接下来GGSN向BM-SC发送MBMS授权请求，以尝试获取UE的授权。授权成功后，BM-SC为用户创建MBMS UE上下文，并通过MBMS授权响应向GGSN通知授权的结果。授权成功后，GGSN创建MBMS UE上下文，并向SGSN发送创建MBMS上下文响应。如果GGSN没有已激活服务的MBMS承载上下文，它就触发MBMS注册流程的执行，这个流程将在接下来的内容里详细介绍。类似地，如果已激活服务不存在MBMS承载上下文，SGSN就触发MBMS注册流程的执行。如果对UE来说至少存在一个分组交换RAN，SGSN还会通过MBMS UE建立连接流程为RAN提供UE上下文。

MBMS多播承载服务也可以不用IGMP或MLD的承载控制信令来激活。在这种情况下，UE直接向GGSN发送激活MBMS上下文请求，从而省略上面的步骤1～步骤4。(www.xing528.com)

图6.6描述了将MBMS UE上下文从UE和其他网络元素移除的MBMS多播服务去激活流程。与必须由UE启动的激活流程不同，去激活流程可以由UE、GGSN、SGSN或者BM-SC启动。UE启动的去激活流程开始于步骤1，如果去激活流程不基于IGMP或MLD的话，就开始于步骤6。由BM-SC启动的去激活流程开始于步骤3，而GGSN启动的去激活流程开始于步骤4。SGSN启动的去激活流程开始于步骤5。MBMS去激活流程的描述如下所示：

1）UE通过默认的PDP上下文，发送一个IGMP或者MLD成员信息报告，以表明它想要退订的MBMS多播服务的IP多播地址。

2）GGSN接收到退出消息后，向BM-SC发送退出指示，并提供那个UE的IP多播地址、APN和UE的IMSI。

3）BM-SC检验指定IP多播地址处是否存在MBMS承载服务，并且向GGSN发送UE移除请求，在请求中提供IP多播地址、作为多播承载服务标识符的APN和作为UE身份证明的IMSI。

4）GGSN向SGSN发送MBMS UE去激活请求，同时提供IP多播地址、APN和IMSI。SGSN通过向GGSN反馈MBMS UE去激活响应，以确认收到了这条消息。

5）SGSN发送MBMS去激活UE上下文请求，以启动UE处的MBMS UE上下文的删除。基于与消息一起提供的TI，UE能够识别出需要删除的MBMS UE上下文。MBMS UE上下文的成功删除是通过MBMS去激活UE上下文响应来确认的。如果不使用基于IGMP或MLD的信令，那么MBMS UE上下文的删除也可以由UE启动。在这种情况下，改由UE发送MBMS去激活UE上下文请求。

6）如果这个UE连接到了RAN，那么SGSN就向RAN发送MBMS UE断开连接请求，并提供IP地址、APN和TMGI。RAN删除MBMS UE上下文，并发送MBMS UE断开连接响应来确认删除成功。

7）RAN分析是否为用户保留现有的承载资源，并可能释放因这个UE而已经在使用的指定承载资源或共享承载资源。

8）然后SGSN通过向持有MBMS UE上下文的GGSN发送删除MBMS上下文请求，启动GGSN处的MBMS UE上下文的删除。每个UE上下文分别用MBMS NSAPI来标识。

图6.6 MBMS服务去激活流程

9）GGSN删除MBMS UE上下文，并向BM-SC发送去激活指示，以确认去激活成功。而BM-SC也删除MBMS UE上下文，并向GGSN发送确认信息。如果GGSN不再有对某MBMS多播服务感兴趣的用户，并且MBMS承载上下文的下行节点名单为空，GGSN就执行MBMS注销。MBMS注销流程将在下一小节进行描述。GGSN向SGSN发送MBMS UE上下文去激活的确认信息，而SGSN也估计用户数，和MBMS承载上下文中的下行节点名单，从而潜在地触发MBMS注销流程，以更新传输树。