CN1677971A - 实现多媒体广播/组播服务业务激活的方法 - Google Patents

Abstract

本发明公开了一种实现多媒体广播/组播服务(MBMS)业务激活的方法，包括以下步骤：a.当前需要接收组播业务的UE通过授权后，当前UE所属的SGSN判断自身是否存储有要求的MBMS承载能力，如果有，则将自身存储的要求的MBMS承载能力发送给当前UE；否则，直接执行步骤b；b.当前UE判断是否收到自身所属SGSN发来的要求的MBMS承载能力，如果未收到，则正常创建MBMS UE上下文，并结束当前流程；如果收到，则执行步骤c；c.判断要求的MBMS承载能力是否大于自身的MBMS承载能力，如果是，则UE以单播方式接收所需组播业务；否则，正常创建MBMS UE上下文。该方法可简化网络中各实体间的信令交互，降低网络复杂度，节约网络资源。

Description

实现多媒体广播/组播服务业务激活的方法

技术领域

本发明涉及业务激活技术，尤指一种实现多媒体广播/组播服务(MBMS)业务激活的方法。

背景技术

随着第三代移动通信技术的发展，第三代移动通信可以提供比第二代移动通信更高数据速率的服务，从而支持多种业务形式，比如：视频电话、图片下载、高速浏览Internet网络等服务。其中，有一类业务的特点是：能够同时给无线网络中定制了该业务的所有用户进行发送，比如：发送天气预报、新闻短片、体育比赛集锦等等。于是，第三代移动通信引入了广播/组播的概念。

参见图1所示，对于一个中间节点而言，比如节点10，无论其下游包含多少个期待接收数据的节点，其上游节点总是向该中间节点发送一份数据；该中间节点收到数据后，根据其下游期待接收数据的节点数量复制该数据，并向其下游各期待接收该数据的节点分发该数据，比如：节点10下游期待接收数据的节点包括节点101和节点102，节点10就将收到的数据复制两份。这样，组播/广播业务数据传输树的每一条分支都只有一份数据进行传输，占用一份传输资源，根节点与其下游节点的数据传输也是如此。组播业务和广播业务的区别点仅在于：组播业务只向订阅了某些信息的用户发送相应信息，广播业务则向无线网络中的所有用户发送信息。由以上描述可见，通过组播/广播业务同时向大量用户提供相同信息，能够极大地节省网络资源。

图2为支持广播/组播业务的无线网络结构示意图，如图2所示，现有第三代合作伙伴计划(3GPP)中，支持广播/组播业务的无线网络结构为广播/组播业务服务器(BM-SC)201，BM-SC 201通过Gmb接口或Gi接口与关口GPRS支持节点(GGSN，Gateway GPRS Support Node)202相连，一个BM-SC 201可与多个GGSN 202相连；GGSN 202通过Gn/Gp接口与服务GPRS支持节点(SGSN，Serving GPRS Support Node)203相连，一个GGSN 202可与多个SGSN203相连；SGSN 203可通过Iu接口与通用移动通信系统(UMTS)陆地无线接入网(UTRAN)204相连，然后UTRAN 204通过Uu接口与用户终端(UE)206相连，SGSN 203也可通过Iu/Gb接口与全球移动通信系统(GSM)增强无线接入网(GERAN)205相连，然后GERAN 205通过Um接口与UE 207相连。其中，BM-SC可以为BSC/RNC。

将图2与图1结合来看，BM-SC 201就相当于一个树状结构的根节点，BM-SC 201的下游节点就是GGSN 202，GGSN 202的下游节点就是SGSN 203，SGSN 203的下游节点就是UE 206、UE 207，当然，其中的GGSN、SGSN也可以有多个。可见，MBMS数据的发布是通过树状结构图进行的，一般要通过多个BSC/RNC、SGSN、GGSN实现。此外，一些承载资源需要在接入同一个MBMS承载业务的用户中进行共享，所以在MBMS发布树上的每个分支建立了相同的服务质量(QoS)。因为如上特性，在创建一个新的MBMS发布树的分支时，不能因为该新分支影响整个发布树的QoS，因此，在UMTS网络中，不能进行QoS协商。如果某些分支的QoS要求不能被网络接受，那么这些分支将不能建立。例如，当某个UE能支持的MBMS能力低于一个业务要求的MBMS能力时，这个UE将被网络拒绝接入这个MBMS组播业务。

在现有协议规范中，通过MBMS注册过程，BM-SC可以将针对一个MBMS组播承载业务所要求的承载能力，比如：标识UE接收该MBMS组播业务所要求的最小承载能力，也就是该MBMS承载业务可能使用的最大QoS能力，发送给GGSN、SGSN。当UE通过MBMS组播业务激活过程加入该MBMS承载业务时，网络需要验证该UE的MBMS承载能力是否满足要求。

用于保存MBMS承载能力的是MBMS承载上下文，该上下文包含定义一个MBMS业务承载的所有信息描述，该上下文在承载MBMS数据的所有节点创建。如表一所示，MBMS承载上下文包括：IP组播地址、接入点名称(APN)、临时移动组标识(TMGI)、状态(State)、要求的MBMS承载能力、QoS、MBMS服务区域、下行流节点列表、UEs数量等。其中，IP组播地址标识由该MBMS承载上下文描述的MBMS承载；APN为该IP组播地址已经被定义的接入点名称；TMGI为分配给MBMS承载的临时移动组标识；State为MBMS承载的活动性状态，包括：静止或激活；要求的MBMS承载能力为标识UE需要支持的最小承载能力；QoS为该MBMS承载要求的服务质量；MBMS服务区域为MBMS业务需要发送的区域；下行流节点列表为请求了MBMS承载，MBMS数据必须下发到的下行流节点列表；UEs数量该节点拥有的已经加入该组播业务的UE地数量。

参数	描述	RAN	SGSN	GGSN	BM-SC
						IP组播地址	IP组播地址标识由该MBMS承载上下文描述的MBMS承载	X	X	X	X
APN	该IP组播地址已经被定义的接入点名称	X	X	X	待研究
						TMGI	分配给MBMS承载的临时移动组标识	X	X	X	X
State	MBMS承载的活动性状态(“静止”或“激活”)	待研究	X	X	X
						要求的MBMS承载能力	标识UE需要支持的最小承载能力		X	X	X
QoS	该MBMS承载要求的服务质量	X	X	X	X
						MBMS服务区域	MBMS业务需要发送的区域	X	X	X	X
下行流节点列表	请求了MBMS承载，MBMS数据必须下发到的下行流节点列表		X	X	X
						UEs数量	该节点拥有的已经加入该组播业务的UE地数量	待研究	X	X	待研究
待研究	待研究

                                    表一

MBMS组播业务激活过程将用户在网络中注册，使该用户可以接收一个特定组播MBMS承载业务的数据。激活是UE与网络之间的信令过程，该过程为每个激活了组播MBMS承载业务的用户在UE、SGSN、GGSN以及BSC/RNC建立MBMS UE上下文，建立MBMS UE上下文与普通PDP上下文建立相似。MBMS UE上下文包含UE已经加入的一个特定MBMS承载的特定信息。当UE加入一个MBMS承载时，MBMS UE上下文在UE、SGSN、GGSN被创建。在UE和SGSN，MBMS UE上下文作为UE的MM上下文的一部分保存；在GGSN，MBMS UE上下文单独保存。UE加入的每个MBMS承载有一个MBMSUE上下文。

参见表二所示，MBMS UE上下文有包括：IP组播地址、APN、TMGI、Linked NSAPI和IMSI等。其中，IP组播地址标识一个UE已经加入的MBMS承载；APN为该IP组播地址已经被定义的接入点名称；TMGI为分配给MBMS承载的临时移动组标识；Linked NSAPI为由UE去承载IGMP/MLD信令的PDP上下文的NSAPI；IMSI为用户标识；MBMS NSAPI标识一个MBMS UE上下文。

参数	定义	UE	SGSN	GGSN	RNC	BSC	BM-SC
								IP组播地址	IP组播地址标识一个UE已经加入的MBMS承载	X	X	X	X	Iu-XGb-待研究	待研究
APN	该IP组播地址已经被定义的接入点名称	X	X	X	X	Iu-XGb-待研究
							TMGI	分配给MBMS承载的临时移动组标识	X
Linked NSAPI	由UE去承载IGMP/MLD信令的PDP上下文的NSAPI	X	X
							IMSI	IMSI标识用户	(1)	(1)	X	(2)	待研究

MBMS_NSAPI

网络层业务接入点，标识一个MBMS UE上下文

X

X

X

                            表二

表二中，(1)表示在UE和SGSN中，IMSI在MM上下文中有效，MM上下文包含MBMS UE上下文；(2)表示在RNC中，IMSI在UE上下文中有效，UE上下文包含MBMS UE上下文。

如图3所示，现有MBMS组播业务激活流程包括以下步骤：

步骤301：通常UE需要激活某个MBMS组播业务时，先要与网络进行交互建立PDP上下文(PDP Context Activation)。

如果当前UE与网络建立了PDP上下文，则直接采用已建立的PDP上下文；如果当前UE没有与网络建立PDP上下文，那么，UE就先激活一个默认的PDP上下文，该PDP上下文的类型一般为尽力服务。该PDP上下文可以是一个用于基本IP业务，如WAP或因特网接入的PDP上下文；也可以是一个用于IP多媒体子系统(IMS)接入的信令PDP上下文。本例中，与默认PDP上下文对应的GGSN为GGSN1。

步骤302：当前UE通过上述建立的PDP上下文，发送一个IGMP加入消息或MLD加入消息给GGSN1，消息中通过IP组播地址标识用户期待接收的一个特定组播MBMS承载业务。这里，如果采用IPv4协议，则UE向GGSN1发IGMP加入消息IGMP Join；如果采用IPv6协议，则UE向MLD加入消息，本例中是采用IPv4协议。

步骤303：GGSN1收到IGMP/MLD加入请求后，给BM-SC发送一个MBMS授权请求MBMS Authorization Request，寻求对当前UE接收数据的授权，如果授权判决通过，则BM-SC将MBMS授权响应MBMS Authorization Response发送给GGSN1，该响应中携带有用于激活MBMS UE上下文的APN。如果授权判决未通过，则BM-SC向GGSN发送的MBMS授权响应中指示该UE不能授权接收MBMS数据，并结束本流程。

步骤304：GGSN1发送一个MBMS通知请求MBMS Notification Request给SGSN，该请求中包括IP组播地址、APN、Linked网络业务接入点标识(NSAPI)。其中，Linked NSAPI的设置等于GGSN收到加入请求时所使用PDP上下文的NASPI；IP组播地址等于UE在加入请求中的IP组播地址；APN可能与已经激活的默认PDP上下文的APN不同，在一些情况下，APN可能对应不同于接收IGMP/MLD加入请求的GGSN1。因为GGSN1可能收不到响应，比如SGSN或UE不支持MBMS的情况，此类情况下，GGSN1需要启动MBMS激活定时器。

步骤305：SGSN收到MBMS通知请求后，给UE发送一个请求MBMS上下文激活消息Request MBMS Context Activation，用于请求UE激活一个MBMSUE上下文，该消息中至少携带有IP组播地址、APN、Linked NSAPI、事务标识(TI)。其中，Linked NSAPI提供给UE将MBMS UE上下文与其在步骤302中发送的IGMP/MLD加入消息中的PDP上下文进行关联；TI由SGSN选择，其取值为没有被该UE其它激活的PDP上下文和MBMS UE上下文使用过的值。

步骤306：UE创建一个MBMS UE上下文后，给SGSN发送一个激活MBMS上下文请求Activate MBMS Context Request，该请求中包括：IP组播地址、APN、MBMS_NSAPI、MBMS承载能力。其中，IP组播地址用于标识UE启动加入/激活的MBMS组播业务；APN指示一个特定的GGSN；MBMS承载能力用于标识UE可以处理的最大QoS；MBMS_NSAPI由UE选择，其取值为没有被该UE其它激活的PDP上下文和MBMS UE上下文使用过的值。

步骤307：SGSN给步骤304中发送MBMS通知请求的GGSN发送MBMS通知响应MBMS Notification Response，该响应中携带有原因值，该原因值用于指示是否成功激活MBMS UE上下文，如果不成功，指示是由于SGSN或UE哪个实体为何而导致的。一旦收到不成功的响应消息、或GGSN1中MBMS激活定时器超时，GGSN1可能回退到3GPP29.061描述的IP组播接入规范。

这里，3GPP 29.061中对IP组播接入的描述是：在没有MBMS的情况下，让GGSN具有IP组播代理的功能，通过如下功能，可以在UMTS网络中提供点到点(PTP)的组播业务：

a)该GGSN维护加入了一个或多个组播组的移动台列表，当GGSN收到来自移动台的一个IGMP加入或MLD报告消息时，该列表进行建立/更新操作；

b)基于维护的移动台列表，发送组播路由信息到附着在分组域的路由器，从而允许这些路由器进行组播数据包的路由；

c)GGSN一旦收到组播数据包，将把该数据包进行拷贝，然后通过PTP方式发送给组内每个移动台。

步骤308：SGSN对当前UE执行安全功能，如：对UE鉴权，该步骤可以省略。

步骤309：SGSN根据步骤306的APN确定特定的GGSN，即实际提供所需MBMS业务的GGSN后，创建一个MBMS UE上下文，并向实际提供所需MBMS业务的GGSN发送创建MBMS上下文请求Create MBMS ContextRequest，该请求中包括IP组播地址、APN、MBMS_NSAPI，本例中，实际提供所需MBMS业务的GGSN为GGSN2。在实际应用中，GGSN1和GGSN2可以是同一个GGSN。

步骤310：GGSN2发送一个MBMS授权请求MBMS Authorization Request给BM-SC，寻求对UE的授权，授权判决结果在MBMS授权响应MBMSAuthorization Response中提供。

步骤311：如果GGSN2没有该MBMS承载业务的MBSM承载上下文信息，GGSN2发送一个MBMS注册请求MBMS Registration Request给BM-SC，相关过程在MBMS标准注册过程中都有规定；

如果BM-SC还未给该MBMS承载业务分配TMGI，BM-SC将分配一个新的TMGI，该TMGI将通过MBMS注册响应消息MBMS Registration Response传递给GGSN和SGSN，进一步通过激活MBMS上下文接受消息ActivateMBMS Context Accept发送给UE；

BM-SC向GGSN2发送的MBMS注册响应消息，包含该MBMS承载业务的MBMS承载上下文信息，并将该GGSN2加入MBMS承载上下文的下行流节点列表，相关内容在MBMS标准注册过程中都有规定。

如果GGSN2已有该MBMS承载业务的MBSM承载上下文信息，该步骤可以省略。

步骤312：GGSN创建一个MBMS UE上下文，并发送创建MBMS上下文响应Create MBMS Context Response给SGSN。

步骤313：如果SGSN没有该MBMS承载业务的MBMS承载上下文信息，SGSN发送一个MBMS注册请求MBMS Registration Request给GGSN，相关过程在MBMS标准注册过程中都有规定。

GGSN响应一个MBMS注册响应消息MBMS Registration Response，该消息中包含该MBMS承载业务的MBMS承载上下文信息，并将该SGSN的标识添加到MBMS承载上下文的下行流节点列表参数中，相关过程在MBMS标准注册过程中都有规定。

如果SGSN上已有该MBMS承载业务的MBSM承载上下文信息，该步骤可以省略。

步骤314：如果为该UE建立了至少一个分组域无线接入承载(PS RAB)，SGSN给RAN提供MBMS UE上下文。

步骤315：SGSN发送一个激活MBMS上下文接受消息Activate MBMSContext Accept给UE，该消息中含有MBMS承载能力。这里，MBMS承载能力标识用于该MBMS承载业务最大的QoS，UE在激活更多MBMS承载业务时，可能会考虑该MBMS承载能力。如果SGSN判定UE的MBMS承载能力低于当前所需MBMS业务要求的MBMS承载能力，则SGSN拒绝该激活一个MBMS UE上下文的请求，并指示一个恰当的理由，对已建立的MBMS UE上下文开始去激活过程。

从上述流程可以看出，对于所有情况下的UE，都必须执行到步骤315，也就是本流程的最后一步，才能判断出UE的MBMS承载能力是否低于所需MBMS业务要求的MBMS承载能力。对于低于要求的UE，前面过程已经为该UE建立了所有的承载，此时还需要发起对该UE的去激活过程。

对于一个没有保存要求的MBMS承载能力的网络节点，只需要进行一次注册过程后，该网络节点就会具有要求的MBMS承载能力的信息。如果再接入其它用户时，仍按照上面的方案执行，过程过于繁琐，增加了网络信令交互，降低了网络效率。

在步骤307中曾提到：GGSN可能回退到3GPP 29.061描述的IP组播接入规范，但3GPP 29.061描述的IP组播接入规范采用的是PTP方式，不能象点对多点(PTM)方式那样节省网络和无线接口的资源。而且，在上述过程中，对于被拒绝的UE，也并未提出采用其它机制使被拒绝用户能接收所需MBMS承载业务的方案，如此，大大降低了用户的满意度。

发明内容

有鉴于此，本发明的主要目的在于提供一种实现多媒体广播/组播服务业务激活的方法，使网络能对MBMS承载能力低于要求的UE请求及时处理，从而简化了网络中各实体间的信令交互，降低了网络复杂度，节约了网络资源。

为达到上述目的，本发明的技术方案是这样实现的：

一种实现多媒体广播/组播服务MBMS业务激活的方法，包括以下步骤：

a.当前需要接收组播业务的UE通过授权后，当前UE所属的SGSN判断自身是否存储有要求的MBMS承载能力，如果有，则将自身存储的要求的MBMS承载能力发送给当前UE；否则，直接执行步骤b；

b.当前UE判断是否收到自身所属SGSN发来的要求的MBMS承载能力，如果未收到，则正常创建MBMS UE上下文，并结束当前流程；如果收到，则执行步骤c；

c.判断要求的MBMS承载能力是否大于自身的MBMS承载能力，如果是，则UE拒绝创建MBMS UE上下文；否则，正常创建MBMS UE上下文。

其中，步骤a所述判断之前进一步包括：

a1.需要接收组播业务的UE通过自身所属SGSN与网络进行交互建立分组数据协议上下文，并向网络发送加入消息；

a2.网络收到加入消息后，对发送加入消息的UE进行授权判决，如果授权未通过，则结束当前处理流程；如果授权通过，则向UE所属SGSN发送MBMS通知请求。

上述方案中，步骤c中所述UE拒绝创建MBMS UE上下文后进一步包括：

c11.当前UE向自身所属SGSN发送拒绝MBMS上下文请求消息；

c12.SGSN收到拒绝消息后，向对应的GGSN发送激活MBMS上下文失败消息，该消息中携带有失败原因，GGSN收到失败消息后，确定是否回退到单播方式的IP组播接入。

或者，步骤c中所述UE拒绝创建MBMS UE上下文后进一步包括：

c21.当前UE主动重新申请以单播方式接收所需的组播业务。

或者，步骤c中所述UE拒绝创建MBMS UE上下文后进一步包括：

c31.当前UE向自身所属SGSN发送拒绝MBMS上下文请求消息，并主动重新申请以单播方式接收所需的组播业务。

或者，步骤c11中当前UE向自身所属SGSN发送携带有自身MBMS承载能力的拒绝MBMS上下文请求消息，则步骤c12中SGSN收到拒绝消息后，进一步包括：

SGSN比较并确定收到的当前UE的MBMS承载能力小于自身存储的要求的MBMS承载能力后，再向对应的GGSN发送激活MBMS上下文失败消息，该消息中携带有失败原因，GGSN收到失败消息后，确定是否回退到单播方式的IP组播接入。

该方法进一步包括：当前UE在向SGSN发送拒绝MBMS上下文请求消息后，激活一个定时器，并判断在定时器时间内GGSN是否回退到单播方式的IP组播接入，如果回退，则停止定时器；如果定时器超时，则发送加入消息的UE重新申请以单播方式接收所需的组播业务。

当前UE确定要求的MBMS承载能力小于等于自身的MBMS承载能力后，UE将自身的MBMS承载能力发送给自身所属的SGSN，SGSN收到后，根据自身存储的要求的MBMS承载能力再次对UE的MBMS承载能力进行验证。当前UE确定要求的MBMS承载能力小于等于自身的MBMS承载能力后，还向自身所属SGSN发送成功进行MBMS承载能力比较的标识。

上述方案中，步骤b中如果当前UE未收到自身所属SGSN发来的要求的MBMS承载能力，则当前UE向自身所属SGSN发送携带有自身MBMS承载能力的激活MBMS UE上下文请求，然后继续按现有处理流程创建MBMS上下文，并且，在SGSN确定所需MBMS业务要求的MBMS承载能力大于当前UE的MBMS承载能力，去激活当前已建立的MBMS UE上下文后，SGSN向GGSN发送激活MBMS上下文失败消息，GGSN收到失败消息后，确定是否回退到单播方式的IP组播接入。其中，所述SGSN向GGSN发送激活MBMS上下文失败消息为：SGSN向与发送加入消息的UE建立初始PDP上下文的GGSN发送激活MBMS上下文失败消息；或为SGSN向曾与发送加入消息的UE创建MBMS UE上下文的GGSN发送激活MBMS上下文失败消息。

该方法进一步包括：当前UE在收到SGSN发来的激活MBMS上下文拒绝消息后，激活一定时器，并判断在定时器时间内GGSN是否回退到单播方式的IP组播接入，如果回退，则停止定时器；如果定时器超时，则发送加入消息的UE重新申请以单播方式接收所需的组播业务。

上述方案中，步骤b中如果当前UE未收到自身所属SGSN发来的要求的MBMS承载能力，则当前UE向自身所属SGSN发送携带有自身MBMS承载能力的激活MBMS UE上下文请求，然后继续按现有处理流程创建MBMS上下文，并且，在SGSN确定所需MBMS业务要求的MBMS承载能力大于当前UE的MBMS承载能力，去激活当前已建立的MBMS UE上下文后，当前UE重新申请以单播方式接收所需的组播业务；或者，在SGSN确定UE的MBMS承载能力低于当前所需MBMS业务要求的MBMS承载能力，当前UE收到SGSN发来的激活MBMS上下文拒绝消息后，重新申请以单播方式接收所需的组播业务。

上述方案中，所述激活MBMS UE上下文请求中进一步携带有未进行MBMS承载能力比较的标识。

本发明所提供的实现多媒体广播/组播服务业务激活的方法，当UE激活某个MBMS组播业务时，在UE与网络建立PDP上下文并得到当前UE授权后，SGSN请求UE激活MBMS上下文时，由UE侧判断自身MBMS承载能力是否满足要求，如此，只有在SGSN或GGSN未注册的情况下，需要执行完现有的整个MBMS业务激活过程，才能获知UE的MBMS承载能力是否满足要求；而对于SGSN或GGSN已注册的情况，如果不满足，根本不需要再建立MBMS上下文，从而省去了UE与网络之间复杂的信令交互，也避免出现激活MBMS上下文后又去激活的操作，简化了网络处理，减轻了网络负担。

本发明在实际应用中，还可以选择由UE和SGSN共同判断，以保证判决结果的可靠性，而且，也可以是MBMS业务激活流程更灵活多样。

另外，对于MBMS承载能力不满足要求的UE，可以改变提供服务的方式，所述改变提供服务的方式是指：由GGSN主动回退执行3GPP 29.061描述的IP组播接入规范，令UE通过PTP方式接收组播业务；或是由UE主动重新申请，以单播方式接收组播业务。如此，可使被拒绝的用户通过其它途径接收所需的组播业务，进而提高了用户的满意度以及网络的使用率，增加了网络运营商的收益；而且，使组播业务的接收方式更灵活多样。

附图说明

图1为组播业务的传输原理示意图；

图2为支持广播/组播业务的无线网络结构示意图；

图3为现有技术中MBMS组播业务激活的处理流程图；

图4为本发明方法的处理流程示意图；

图5为本发明实施例一的具体处理流程图；

图6为本发明实施例二的具体处理流程图；

图7为本发明实施例三的具体处理流程图；

图8为本发明实施例四的具体处理流程图；

图9为本发明实施例五的具体处理流程图；

图10为本发明实施例六的具体处理流程图；

图11为本发明实施例七的具体处理流程图。

具体实施方式

本发明的核心思想是：当UE激活某个MBMS组播业务时，在UE与网络建立PDP上下文并得到当前UE授权后，SGSN请求UE激活MBMS上下文时，在请求中携带所需MBMS业务要求的MBMS承载能力，由UE侧判断自身MBMS承载能力是否满足要求，然后，根据判断结果进行相应处理，如此，可提前处理激活MBMS承载业务的请求。

本发明实现多媒体广播/组播服务业务激活的方法，如图4所示，具体包括以下步骤：

步骤401～402：需要接收某个组播业务的UE，先通过自身所属的SGSN与网络建立PDP上下文，并通过所建立的PDP上下文向网络发送加入消息，这里，一般是向当前所建立的PDP上下文对应的GGSN发送加入消息。

网络收到加入消息后，对当前发送加入消息的UE进行授权判决，判断授权是否通过，如果通过，则执行步骤403；否则，结束当前处理流程。

网络对当前UE进行授权判决的具体过程是：如图3中步骤303～306所示，GGSN1收到当前UE发送的加入消息后，向BM-SC发送MBMS授权请求，寻求对当前UE接收数据的授权；BM-SC对当前UE进行授权判决后，向GGSN1返回MBMS授权响应，如果授权通过，则该MBMS授权响应中携带有特定GGSN APN的响应消息，GGSN1收到后，向SGSN发MBMS通知请求；如果授权未通过，则该MBMS授权响应中携带有当前UE不能接收MBMS数据的指示，并结束当前处理流程。

步骤403～404：SGSN判断自身是否存储有要求的MBMS承载能力，如果有，则SGSN向发送加入消息的UE发送携带有所需MBMS业务要求的MBMS承载能力的请求MBMS上下文激活；否则，SGSN向相应UE发送的请求MBMS上下文激活消息中不携带所需MBMS业务要求的MBMS承载能力。

通常，SGSN获得某个MBMS承载业务要求的MBMS承载能力可以有两种途径：通过MBMS注册过程获取；或是预先通过运营商进行的网络配置获取。对于通过MBMS注册获取MBMS承载能力的情况，只有在SGSN、GGSN第一次注册时，SGSN、GGSN存在没有存储MBMS承载业务要求的MBMS承载能力的问题，只要SGSN、GGSN已经过注册，相应SGSN、GGSN中都会存储有MBMS承载业务要求的MBMS承载能力。

步骤405：UE收到请求MBMS上下文激活消息后，判断该消息中是否携带有所需MBMS业务要求的MBMS承载能力，如果有，则执行步骤406；如果没有，则继续按图3中步骤306～315所示的现有MBMS业务激活流程进行处理，只是在步骤306向SGSN发送的激活MBMS上下文请求中携带有未进行MBMS承载能力比较的标识，并结束当前处理流程。

步骤406～407：UE判断SGSN发来的要求的MBMS承载能力是否大于自身的MBMS承载能力，如果是，则UE拒绝创建MBMS UE上下文；否则，继续按图3中步骤306～315所示的现有MBMS业务激活流程进行处理，完成MBMS上下文的创建，只是在步骤306向SGSN发送的激活MBMS上下文请求中携带有已成功进行MBMS承载能力比较的标识，并且在步骤315中不再对UE的MBMS承载能力进行判断。

在步骤407中，UE除了拒绝创建MBMS UE上下文，还可以主动重新申请以单播方式接收所需的组播业务；或是向SGSN发送请求MBMS上下文激活拒绝，SGSN收到UE发来的请求MBMS上下文激活拒绝，还可以向GGSN发送激活MBMS上下文失败消息，GGSN可以根据需要确定是否回退到以单播方式接收组播业务。

这里，SGSN向GGSN发送的激活MBMS上下文失败消息可以直接采用现有技术处理流程中的MBMS通知响应消息，在该响应消息中携带激活失败指示；也可以采用单独的消息指示GGSN激活MBMS上下文失败。这种情况下，如果GGSN确定不进行回退，则UE也可以在一段时间后，主动申请以单播方式接收组播业务。

实施例一：

本实施例中，SGSN中已存有相关MBMS承载能力的信息，并且，UE侧对MBMS承载能力的比较结果是：要求的MBMS承载能力小于等于UE的MBMS承载能力。这种情况下，实现多媒体广播/组播服务业务激活的方法如图5所示，包括以下步骤：

步骤501～504：与现有技术中步骤301～304的所有描述完全相同。

步骤505～506：SGSN收到MBMS通知请求后，给UE发送一个请求MBMS上下文激活消息Request MBMS Context Activation，用于请求UE激活一个MBMS上下文，该消息中至少携带有IP组播地址、APN、Linked NSAPI、事务标识(TI)。其中，Linked NSAPI提供给UE将MBMS UE上下文与其在步骤502中发送的IGMP/MLD加入消息中的PDP上下文进行关联；TI由SGSN选择，其取值为没有被该UE其它激活的PDP上下文和MBMS UE上下文使用过的值。

同时，SGSN判断出自身存储有要求的MBMS承载能力，因此，在请求MBMS上下文激活消息中还要携带要求的MBMS承载能力。

步骤507：UE收到请求MBMS上下文激活消息后，判断出该消息中携带有要求的MBMS承载能力，则将要求的MBMS承载能力与自身的MBMS承载能力进行比较，得到要求的MBMS承载能力小于等于自身MBMS承载能力的结果。

同时，UE创建一个MBMS UE上下文后，给SGSN发送一个激活MBMS上下文请求Activate MBMS Context Request，该请求中包括：IP组播地址、APN、MBMS_NSAPI、MBMS承载能力。其中，IP组播地址用于标识UE启动加入/激活的MBMS组播业务；APN指示一个特定的GGSN；MBMS承载能力用于标识UE可以处理的最大QoS，该信息是可选的；MBMS_NSAPI由UE选择，其取值为没有被该UE其它激活的PDP上下文和MBMS UE上下文使用过的值。由于要求的MBMS承载能力小于等于UE自身的MBMS承载能力，所以，UE发送的激活MBMS上下文请求中还携带有已成功进行MBMS承载能力比较的标识，表示UE的MBMS承载能力符合当前所需MBMS承载业务的要求。

步骤508～511：与现有技术中步骤306～310的所有描述完全相同。

步骤512：与现有技术中步骤312的所有描述完全相同。

步骤513：与现有技术中步骤314的所有描述完全相同。

步骤514：SGSN发送一个激活MBMS上下文接受消息Activate MBMSContext Accept给UE，该消息中可能含有MBMS承载能力。这里，MBMS承载能力标识用于该MBMS承载业务最大的QoS，UE在激活更多MBMS承载业务时，可能会考虑该MBMS承载能力。

由于步骤507中UE向SGSN发送的激活MBMS上下文请求中携带有成功进行MBMS承载能力比较的标识，所以，本步骤不再对UE的MBMS承载能力进行验证。

在本实施例的步骤507中，如果UE向SGSN发送的激活MBMS上下文请求中携带UE的MBMS承载能力，那么，在步骤508中，SGSN收到UE发送的激活MBMS上下文请求后，可以根据自身存储的MBMS承载能力再对UE的MBMS承载能力进行一次比较验证，验证成功后再按现有流程继续执行。

实施例二：

本实施例中，SGSN中已存有相关MBMS承载能力的信息，并且，UE侧对MBMS承载能力的比较结果是：要求的MBMS承载能力大于UE的MBMS承载能力；得到比较结果后，UE向SGSN发拒绝MBMS上下文请求消息，之后，SGSN也向GGSN发送激活失败消息。这种情况下，实现多媒体广播/组播服务业务激活的方法如图6所示，包括以下步骤：

步骤601～步骤605：与实施例一中步骤501～505的所有描述完全相同。

步骤606～607：UE收到请求MBMS上下文激活消息后，判断出该消息中携带有要求的MBMS承载能力，则将要求的MBMS承载能力与自身的MBMS承载能力进行比较，得到要求的MBMS承载能力大于自身MBMS承载能力的结果；UE向SGSN发送拒绝MBMS上下文请求消息。

这里，UE向SGSN发送的拒绝MBMS上下文请求消息可以直接采用现有技术处理流程中的激活MBMS UE上下文请求消息，该消息中携带有UE的MBMS承载能力、UE判决失败的结果；也可以采用单独的消息指示激活MBMS上下文失败。

步骤608：SGSN收到拒绝MBMS上下文请求消息后，向GGSN发送激活MBMS上下文失败的消息，指示因为承载能力导致失败，GGSN可以根据实际情况确定是否回退到3GPP 29.061描述的IP组播接入规范。

对于GGSN不回退的情况，UE可以在向SGSN发送拒绝MBMS上下文请求消息后，激活一个定时器，开始计时，同时判断GGSN是否执行回退，如果在定时器超时前GGSN执行回退，则停止相应的定时器；如果定时器超时，则UE重新申请进行3GPP 29.061描述的IP组播接入规范，采用单播方式即PTP的方式来接收所需的组播业务。

实施例三：

本实施例中，SGSN中已存有相关MBMS承载能力的信息，并且，UE侧对MBMS承载能力的比较结果是：要求的MBMS承载能力大于UE的MBMS承载能力；得到比较结果后，UE直接重新申请以单播方式接收组播业务。这种情况下，实现多媒体广播/组播服务业务激活的方法如图7所示，包括以下步骤：

步骤701～706：与实施例二中步骤601～606的所有描述全部相同。

步骤707：UE重新申请进行3GPP 29.061描述的IP组播接入规范，采用单播方式，即点到点(PTP)的方式来接收所需的组播业务。

实施例四：

本实施例中，SGSN中已存有相关MBMS承载能力的信息，并且，UE侧对MBMS承载能力的比较结果是：要求的MBMS承载能力大于UE的MBMS承载能力；得到比较结果后，UE向SGSN发拒绝MBMS上下文请求消息，之后，UE直接重新申请以单播方式接收组播业务。这种情况下，实现多媒体广播/组播服务业务激活的方法如图8所示，包括以下步骤：

步骤801～807：与实施例二中步骤601～607的所有描述全部相同。

步骤808：UE重新申请进行3GPP 29.061描述的IP组播接入规范，采用单播方式，即点到点(PTP)的方式来接收所需的组播业务。实际上，步骤808也可以与步骤807同时进行。

实施例五：

本实施例中，SGSN中已存有相关MBMS承载能力的信息，并且，UE侧对MBMS承载能力的比较结果是：要求的MBMS承载能力大于UE的MBMS承载能力；得到比较结果后，UE向SGSN发拒绝MBMS上下文请求消息，之后，SGSN再对MBMS承载能力比较一次。这种情况下，实现多媒体广播/组播服务业务激活的方法如图9所示，包括以下步骤：

步骤901～906：与实施例二中步骤601～607的所有描述全部相同。

步骤907：得到MBMS承载能力的比较结果后，UE向SGSN发送拒绝MBMS上下文请求消息，该消息中一定要携带UE的MBMS承载能力。

步骤908～909：SGSN收到当前发送加入消息的UE发来的携带有其MBMS承载能力的拒绝MBMS上下文请求消息后，根据自身存储的所需MBMS承载业务要求的MBMS承载能力来判断，UE的MBMS承载能力是否小于所需MBMS承载业务要求的MBMS承载能力；同样得到UE的MBMS承载能力小于要求的MBMS承载能力的结果后，SGSN向GGSN发送激活MBMS上下文失败的消息，指示因为承载能力导致失败，GGSN可以根据实际情况确定是否回退到3GPP 29.061描述的IP组播接入规范。

对于GGSN不回退的情况，UE可以在向SGSN发送拒绝MBMS上下文请求消息后，激活一个定时器，开始计时，同时判断GGSN是否执行回退，如果在定时器超时前GGSN执行回退，则停止相应的定时器；如果定时器超时，则UE重新申请进行3GPP 29.061描述的IP组播接入规范，采用单播方式即PTP的方式来接收所需的组播业务。

实施例六：

本实施例中，SGSN中未存储相关MBMS承载能力的信息，那么，基本按现有技术流程处理，到最后一个步骤再比较UE的MBMS承载能力，并且，对于UE的MBMS承载能力小于要求的MBMS承载能力的情况，不仅对已建立的MBMS UE上下文去激活，而且SGSN要向GGSN发送激活失败消息，GGSN根据实际情况确定是否回退到3GPP 29.061描述的IP组播接入。这种情况下，实现多媒体广播/组播服务业务激活的方法如图10所示，具体包括以下步骤：

步骤1001～1004：与现有技术中步骤301～304的所有描述完全相同。

步骤1005～1006：SGSN收到MBMS通知请求后，给UE发送一个请求MBMS上下文激活消息Request MBMS Context Activation，用于请求UE激活一个MBMS上下文，该消息中至少携带有IP组播地址、APN、Linked NSAPI、事务标识(TI)。其中，Linked NSAPI提供给UE将MBMS UE上下文与其在步骤1002中发送的IGMP/MLD加入消息中的PDP上下文进行关联；TI由SGSN选择，其取值为没有被该UE其它激活的PDP上下文和MBMS UE上下文使用过的值。

同时，SGSN判断出自身没有存储有要求的MBMS承载能力，因此，在请求MBMS上下文激活消息中不携带任何要求的MBMS承载能力。

步骤1007：UE收到请求MBMS上下文激活消息后，判断出该消息中未携带要求的MBMS承载能力，则创建一个MBMS UE上下文后，给SGSN发送一个激活MBMS上下文请求Activate MBMS Context Request，该请求中包括：IP组播地址、APN、MBMS_NSAPI、MBMS承载能力。其中，IP组播地址用于标识UE启动加入/激活的MBMS组播业务；APN指示一个特定的GGSN；MBMS承载能力用于标识UE可以处理的最大QoS，该信息是可选的，但在本实施例中，该信息是必须携带的；MBMS_NSAPI由UE选择，其取值为没有被该UE其它激活的PDP上下文和MBMS UE上下文使用过的值。由于SGSN发来的请求MBMS上下文激活消息中未携带MBMS承载能力，所以，UE发送的激活MBMS上下文请求中要携带未进行MBMS承载能力比较的标识。

步骤1008～1015：与现有技术中步骤307～314的所有描述基本相同，其中，步骤1012和步骤1014是不能省略的。

步骤1016：由于步骤1007中UE向SGSN发送的激活MBMS上下文请求中携带有表示未进行MBMS承载能力比较的标识，也就是说，在本步骤之前，UE或SGSN都未对UE的MBMS承载能力进行验证。因此，SGSN根据自身存储的MBMS承载能力，判断UE的MBMS承载能力是否低于当前所需MBMS业务要求的MBMS承载能力，如果不是，则SGSN发送一个激活MBMS上下文接受消息Activate MBMS Context Accept给UE，该消息中含有MBMS承载能力，同时结束当前处理流程。这里，MBMS承载能力标识用于该MBMS承载业务最大的QoS，UE在激活更多MBMS承载业务时，可能会考虑该MBMS承载能力。

如果UE的MBMS承载能力低于当前所需MBMS业务要求的MBMS承载能力，SGSN拒绝该激活一个MBMS上下文的请求，向UE发送一个激活MBMS上下文拒绝消息，并指示一个恰当的理由，对已建立的MBMS UE上下文开始去激活过程，然后执行步骤1017。本实施例就是：UE的MBMS承载能力低于当前所需MBMS业务要求的MBMS承载能力的情况。

步骤1017：完成MBMS UE上下文去激活过程后，SGSN向GGSN1或GGSN2发送激活失败消息，指示因为承载能力导致失败，GGSN1或GGSN2可以根据实际情况确定是否回退到3GPP 29.061描述的IP组播接入规范。

本实施中，对于GGSN不回退的情况，UE可以在步骤1016收到SGSN发来的激活MBMS上下文拒绝消息后，激活一个定时器，开始计时，同时判断GGSN是否执行回退，如果在定时器超时前GGSN执行回退，则停止相应的定时器；如果定时器超时，则UE重新申请进行3GPP 29.061描述的IP组播接入规范，采用单播方式即PTP的方式来接收所需的组播业务。

实施例七：

本实施例中，SGSN中未存储相关MBMS承载能力的信息，SGSN中未存储相关MBMS承载能力的信息，那么，基本按现有技术流程处理，到最后一个步骤再比较UE的MBMS承载能力，并且，对于UE的MBMS承载能力小于要求的MBMS承载能力的情况，不仅对已建立的MBMS UE上下文去激活；同时，UE收到激活MBMS上下文拒绝消息，重新申请采用单播方式接收当前组播业务。这种情况下，实现多媒体广播/组播服务业务激活的方法如图11所示，具体包括以下步骤：

步骤1101～1116：与实施例六中步骤1001～1016的所有描述完全相同。

步骤1117：UE在收到激活MBMS上下文拒绝消息，或完成MBMS UE上下文去激活过程后，UE重新申请进行3GPP 29.061描述的IP组播接入规范，采用单播方式即PTP的方式来接收所需的组播业务。

在实际应用中，对于实施例六和实施例七的情况，也可以只完成去激活过程，就结束MBMS的业务激活流程，不再继续执行步骤1017或步骤1117。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (14)

1、一种实现多媒体广播/组播服务MBMS业务激活的方法，其特征在于，包括以下步骤：

a.当前需要接收组播业务的UE通过授权后，当前UE所属的SGSN判断自身是否存储有要求的MBMS承载能力，如果有，则将自身存储的要求的MBMS承载能力发送给当前UE；否则，直接执行步骤b；

b.当前UE判断是否收到自身所属SGSN发来的要求的MBMS承载能力，如果未收到，则正常创建MBMS UE上下文，并结束当前流程；如果收到，则执行步骤c；

c.判断要求的MBMS承载能力是否大于自身的MBMS承载能力，如果是，则UE拒绝创建MBMS UE上下文；否则，正常创建MBMS UE上下文。

2、根据权利要求1所述的方法，其特征在于，步骤a所述判断之前进一步包括：

a1.需要接收组播业务的UE通过自身所属SGSN与网络进行交互建立分组数据协议上下文，并向网络发送加入消息；

a2.网络收到加入消息后，对发送加入消息的UE进行授权判决，如果授权未通过，则结束当前处理流程；如果授权通过，则向UE所属SGSN发送MBMS通知请求。

3、根据权利要求1所述的方法，其特征在于，步骤c中所述UE拒绝创建MBMS UE上下文后进一步包括：

c11.当前UE向自身所属SGSN发送拒绝MBMS上下文请求消息；

c12.SGSN收到拒绝消息后，向对应的GGSN发送激活MBMS上下文失败消息，该消息中携带有失败原因，GGSN收到失败消息后，确定是否回退到单播方式的IP组播接入。

4、根据权利要求1所述的方法，其特征在于，步骤c中所述UE拒绝创建MBMS UE上下文后进一步包括：

c21.当前UE主动重新申请以单播方式接收所需的组播业务。

5、根据权利要求1所述的方法，其特征在于，步骤c中所述UE拒绝创建MBMS UE上下文后进一步包括：

c31.当前UE向自身所属SGSN发送拒绝MBMS上下文请求消息，并主动重新申请以单播方式接收所需的组播业务。

6、根据权利要求3所述的方法，其特征在于，步骤c11中当前UE向自身所属SGSN发送携带有自身MBMS承载能力的拒绝MBMS上下文请求消息，则步骤c12中SGSN收到拒绝消息后，进一步包括：

SGSN比较并确定收到的当前UE的MBMS承载能力小于自身存储的要求的MBMS承载能力后，再向对应的GGSN发送激活MBMS上下文失败消息，该消息中携带有失败原因，GGSN收到失败消息后，确定是否回退到单播方式的IP组播接入。

7、根据权利要求3或6所述的方法，其特征在于，该方法进一步包括：当前UE在向SGSN发送拒绝MBMS上下文请求消息后，激活一个定时器，并判断在定时器时间内GGSN是否回退到单播方式的IP组播接入，如果回退，则停止定时器；如果定时器超时，则发送加入消息的UE重新申请以单播方式接收所需的组播业务。

8、根据权利要求1所述的方法，其特征在于，当前UE确定要求的MBMS承载能力小于等于自身的MBMS承载能力后，UE将自身的MBMS承载能力发送给自身所属的SGSN，SGSN收到后，根据自身存储的要求的MBMS承载能力再次对UE的MBMS承载能力进行验证。

9、根据权利要求1或8所述的方法，其特征在于，当前UE确定要求的MBMS承载能力小于等于自身的MBMS承载能力后，向自身所属SGSN发送成功进行MBMS承载能力比较的标识。

10、根据权利要求1所述的方法，其特征在于，步骤b中如果当前UE未收到自身所属SGSN发来的要求的MBMS承载能力，则当前UE向自身所属SGSN发送携带有自身MBMS承载能力的激活MBMS UE上下文请求，然后继续按现有处理流程创建MBMS上下文，并且，在SGSN确定所需MBMS业务要求的MBMS承载能力大于当前UE的MBMS承载能力，去激活当前已建立的MBMS UE上下文后，SGSN向GGSN发送激活MBMS上下文失败消息，GGSN收到失败消息后，确定是否回退到单播方式的IP组播接入。

11、根据权利要求10所述的方法，其特征在于，该方法进一步包括：当前UE在收到SGSN发来的激活MBMS上下文拒绝消息后，激活一定时器，并判断在定时器时间内GGSN是否回退到单播方式的IP组播接入，如果回退，则停止定时器；如果定时器超时，则发送加入消息的UE重新申请以单播方式接收所需的组播业务。

12、根据权利要求10所述的方法，其特征在于，所述SGSN向GGSN发送激活MBMS上下文失败消息为：SGSN向与发送加入消息的UE建立初始PDP上下文的GGSN发送激活MBMS上下文失败消息；或为SGSN向曾与发送加入消息的UE创建MBMS UE上下文的GGSN发送激活MBMS上下文失败消息。

13、根据权利要求1所述的方法，其特征在于，步骤b中如果当前UE未收到自身所属SGSN发来的要求的MBMS承载能力，则当前UE向自身所属SGSN发送携带有自身MBMS承载能力的激活MBMS UE上下文请求，然后继续按现有处理流程创建MBMS上下文，并且，在SGSN确定所需MBMS业务要求的MBMS承载能力大于当前UE的MBMS承载能力，去激活当前已建立的MBMS UE上下文后，当前UE重新申请以单播方式接收所需的组播业务；或者，在SGSN确定UE的MBMS承载能力低于当前所需MBMS业务要求的MBMS承载能力，当前UE收到SGSN发来的激活MBMS上下文拒绝消息后，重新申请以单播方式接收所需的组播业务。

14、根据权利要求10至13任一项所述的方法，其特征在于，所述激活MBMS UE上下文请求中进一步携带有未进行MBMS承载能力比较的标识。

Images