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

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

Info

Publication number
CN1266898C
CN1266898C CNB2004100316034A CN200410031603A CN1266898C CN 1266898 C CN1266898 C CN 1266898C CN B2004100316034 A CNB2004100316034 A CN B2004100316034A CN 200410031603 A CN200410031603 A CN 200410031603A CN 1266898 C CN1266898 C CN 1266898C
Authority
CN
China
Prior art keywords
mbms
bearing capacity
sgsn
context
current
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
CNB2004100316034A
Other languages
English (en)
Other versions
CN1642132A (zh
Inventor
张海
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to CNB2004100316034A priority Critical patent/CN1266898C/zh
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to PCT/CN2005/000382 priority patent/WO2005099286A1/zh
Priority to EP20050738124 priority patent/EP1737254B1/en
Priority to JP2007505357A priority patent/JP4425307B2/ja
Priority to US10/594,646 priority patent/US8842593B2/en
Priority to AT05738124T priority patent/ATE424697T1/de
Priority to DE200560013072 priority patent/DE602005013072D1/de
Publication of CN1642132A publication Critical patent/CN1642132A/zh
Application granted granted Critical
Publication of CN1266898C publication Critical patent/CN1266898C/zh
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/40—Connection management for selective distribution or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种实现多媒体广播/组播服务(MBMS)业务激活的方法，包括以下步骤：a.当前需要接收组播业务的UE通过授权后，向自身所属的SGSN发送携带有自身MBMS承载能力的信息；关键是该方法还包括：b.所述SGSN判断自身是否存储有要求的MBMS承载能力，如果没有，则继续创建MBMS UE上下文，并结束当前处理流程；否则，执行步骤c；c.判断当前要接收组播业务的UE的MBMS承载能力是否小于SGSN中存储的要求的MBMS承载能力，如果是，则SGSN拒绝激活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可能回退到3GPP 29.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通过授权后，向自身所属SGSN发送携带有自身MBMS承载能力信息的请求；
关键在于，该方法还包括：
b.所述SGSN判断自身是否存储有要求的MBMS承载能力，如果没有，则继续创建MBMS UE上下文，并结束当前处理流程；否则，执行步骤c；
c.判断当前要接收组播业务的UE的MBMS承载能力是否小于SGSN中存储的要求的MBMS承载能力，如果是，则SGSN拒绝来自UE的激活MBMS UE上下文的请求；否则，继续创建MBMS UE上下文。
其中，步骤a具体包括：
a1.当前需要接收组播业务的UE通过自身所属SGSN与网络进行交互建立分组数据协议上下文，并向网络发送加入消息；
a2.网络收到加入消息后，对发送加入消息的当前UE进行授权判决，如果授权未通过，则结束当前处理流程；如果授权通过，则网络允许发送加入消息的当前UE激活MBMS UE上下文，该当前UE向自身所属的SGSN发送携带有自身MBMS承载能力的信息。
步骤c中SGSN拒绝激活MBMS UE上下文的请求后，进一步包括：
SGSN向当前UE发送激活MBMS上下文拒绝消息，该消息中携带有拒绝原因；SGSN向GGSN发送激活MBMS上下文失败消息，该消息中携带有失败原因，GGSN收到失败消息后，确定是否回退到单播方式的IP组播接入。
或者，步骤c中SGSN拒绝激活MBMS UE上下文的请求后，进一步包括：
c11.SGSN向当前UE发送激活MBMS上下文拒绝消息，该消息中携带有拒绝原因；
c12.所述UE收到拒绝消息后，重新申请以单播方式接收所需的组播业务。
或者，步骤c中SGSN拒绝激活MBMS UE上下文的请求后，进一步包括：
c21.SGSN向GGSN发送激活MBMS上下文失败消息，该消息中携带有失败原因，GGSN收到失败消息后，确定是否回退到单播方式的IP组播接入。
上述方案中，所述SGSN向当前UE发送的激活MBMS上下文拒绝消息中，进一步携带有该UE所需MBMS承载业务要求的MBMS承载能力。
该方法进一步包括：当前UE在收到SGSN发来的激活MBMS上下文拒绝消息后，激活一定时器，并判断在定时器时间内GGSN是否回退到单播方式的IP组播接入，如果回退，则停止定时器；如果定时器超时，则当前UE重新申请以单播方式接收所需的组播业务。
该方法进一步包括：UE在向自身所属SGSN发送携带有自身MBMS承载能力的信息后，激活一定时器，并判断在定时器时间内，是否收到激活MBMS上下文接受消息或者GGSN是否回退到单播方式的IP组播接入，如果是，则停止定时器；如果定时器超时，则当前UE重新中请以单播方式接收所需的组播业务。
上述方案中，所述SGSN向当前UE发送的激活MBMS上下文拒绝消息中携带该UE所需MBMS承载业务要求的MBMS承载能力，则步骤c12中UE收到拒绝消息后，先将要求的MBMS承载能力与自身的MBMS承载能力进行比较，如果要求的MBMS承载能力大于自身的MBMS承载能力，再重新申请以单播方式接收所需的组播业务。
上述方案中，所述SGSN向当前UE发送的激活MBMS上下文拒绝消息中携带该UE所需MBMS承载业务要求的MBMS承载能力，则UE收到激活MBMS上下文拒绝消息后，将要求的MBMS承载能力与自身的MBMS承载能力进行比较，如果要求的MBMS承载能力大于自身的MBMS承载能力且GGSN未进行回退，再重新申请以单播方式接收所需的组播业务。
步骤b中如果SGSN中未存储要求的MBMS承载能力，则继续执行现有MBMS业务激活流程中创建MBMS UE上下文的过程，并且，在SGSN确定UE的MBMS承载能力低于当前所需MBMS业务要求的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重新申请以单播方式接收所需的组播业务。
上述方案中，所述SGSN向当前UE发送的激活MBMS上下文拒绝消息中携带该UE所需MBMS承载业务要求的MBMS承载能力，则UE收到激活MBMS上下文拒绝消息后，将要求的MBMS承载能力与自身的MBMS承载能力进行比较，如果要求的MBMS承载能力大于自身的MBMS承载能力且GGSN未进行回退，再重新申请以单播方式接收所需的组播业务。
步骤b中如果SGSN中未存储要求的MBMS承载能力，则继续执行现有MBMS业务激活流程中创建MBMS UE上下文的过程，并且，在SGSN确定UE的MBMS承载能力低于当前所需MBMS业务要求的MBMS承载能力，去激活当前已建立的MBMS UE上下文后，当前UE重新申请以单播方式接收所需的组播业务；或者，在SGSN确定UE的MBMS承载能力低于当前所需MBMS业务要求的MBMS承载能力，当前UE收到SGSN发来的激活MBMS上下文拒绝消息后，重新申请以单播方式接收所需的组播业务。这种情况下，所述SGSN向当前UE发送的激活MBMS上下文拒绝消息中携带该UE所需MBMS承载业务要求的MBMS承载能力，则UE收到拒绝消息后，先将要求的MBMS承载能力与自身的MBMS承载能力进行比较，如果要求的MBMS承载能力大于自身的MBMS承载能力，再重新申请以单播方式接收所需的组播业务。
本发明所提供的实现多媒体广播/组播服务业务激活的方法，当UE激活某个MBMS组播业务时，在UE与网络建立PDP上下文的过程中，SGSN收到UE的MBMS承载能力后，就进行UE的MBMS承载能力是否满足要求的判断，如此，只有在SGSN或GGSN未注册的情况下，需要执行完现有的整个MBMS业务激活过程，才能获知UE的MBMS承载能力是否满足要求；而对于SGSN或GGSN已注册的情况，如果不满足，根本不需要再建立MBMS UE上下文，从而省去了UE与网络之间复杂的信令交互，也避免出现激活MBMS UE上下文后又去激活的操作，简化了网络处理，减轻了网络负担。
本发明在实际应用中，还可以选择由SGSN和UE共同判断，以保证判决结果的可靠性，而且，也可以是MBMS业务激活流程更灵活多样。
另外，对于MBMS承载能力不满足要求的UE，SGSN可以直接拒绝或改变提供服务的方式，所述改变提供服务的方式是指：由GGSN主动回退执行3GPP 29.061描述的IP组播接入规范，令UE通过PTP方式接收组播业务；或是由UE主动重新申请，以单播方式接收组播业务。如此，可使被拒绝的用户通过其它途径接收所需的组播业务，进而提高了用户的满意度以及网络的使用率，增加了网络运营商的收益；而且，使组播业务的接收方式更灵活多样。
附图说明
图1为组播业务的传输原理示意图；
图2为支持广播/组播业务的无线网络结构示意图；
图3为现有技术中MBMS组播业务激活的处理流程图；
图4为本发明方法的处理流程示意图；
图5为本发明实施例一的具体处理流程图；
图6为本发明实施例二的具体处理流程图；
图7为本发明实施例三的具体处理流程图；
图8为本发明实施例四的具体处理流程图；
图9为本发明实施例五的具体处理流程图；
图10为本发明实施例六的具体处理流程图；
图11为本发明实施例七的具体处理流程图。
具体实施方式
本发明的核心思想是：当UE激活某个MBMS组播业务时，在UE与网络建立PDP上下文的阶段，SGSN收到UE的MBMS承载能力后，就进行UE的MBMS承载能力是否满足要求的判断，然后，根据判断结果进行相应处理，如此，可提前处理激活MBMS承载业务的请求。
本发明实现多媒体广播/组播服务业务激活的方法，如图4所示，具体包括以下步骤：
步骤401：需要接收某个组播业务的UE，先通过自身所属的SGSN与网络建立PDP上下文，并通过所建立的PDP上下文向网络发送加入消息。这里，一般是向当前所建立的PDP上下文对应的GGSN发送加入消息。
步骤402～405：网络对当前发送加入消息的UE进行授权判决，如果授权通过，则网络允许UE激活MBMS UE上下文，当前UE向自身所属的SGSN发送携带有自身MBMS承载能力的消息；否则，结束当前处理流程。
网络对当前UE进行授权判决的具体过程是：如图3中步骤303～306所示，GGSN收到当前UE发送的加入消息后，向BM-SC发送MBMS授权请求，寻求对当前UE接收数据的授权；BM-SC对当前UE进行授权判决后，向GGSN返回MBMS授权响应，如果授权通过，则该MBMS授权响应中携带有特定GGSN APN的响应消息，GGSN收到后，向SGSN发MBMS通知请求；SGSN收到后，请求当前UE激活MBMS UE上下文；UE收到请求后，返回携带有自身MBMS承载能力的响应消息；如果授权未通过，则该MBMS授权响应中携带有当前UE不能接收MBMS数据的指示，并结束当前处理流程。
步骤406：SGSN收到UE的MBMS承载能力后，判断自身是否存储有要求的MBMS承载能力，如果有，则执行步骤407，否则，继续按图3中步骤307～315所示的现有MBMS业务激活流程进行处理，并结束当前处理流程。
通常，SGSN获得某个MBMS承载业务要求的MBMS承载能力可以有两种途径：通过MBMS注册过程获取；或是预先通过运营商进行的网络配置获取。对于通过MBMS注册获取MBMS承载能力的情况，只有在SGSN、GGSN第一次注册时，SGSN、GGSN存在没有存储MBMS承载业务要求的MBMS承载能力的问题，只要SGSN、GGSN已经过注册，相应SGSN、GGSN中都会存储有MBMS承载业务要求的MBMS承载能力。
步骤407～408：判断所收到的UE的MBMS承载能力是否小于SGSN中存储的要求的MBMS承载能力，如果是，则SGSN拒绝激活MBMS UE上下文的请求；否则，继续按图3中步骤307～315所示的现有MBMS业务激活流程进行处理，完成MBMS UE上下文的创建，只是在步骤315中不再对UE的MBMS承载能力进行判断。
在步骤408中，SGSN拒绝激活MBMS UE上下文的请求之后，SGSN还可以分别将激活MBMS UE上下文失败的消息通知GGSN或UE，或是同时通知GGSN和UE，GGSN或UE可以根据需要重新转换或重新申请接收组播业务的方式。
这里，SGSN向GGSN发送的激活MBMS上下文失败消息可以直接采用现有技术处理流程中的MBMS通知响应消息，在该响应消息中携带激活失败指示；也可以采用单独的消息指示GGSN激活MBMS UE上下文失败。
实施例一：
本实施例中，SGSN中已存有相关MBMS承载能力的信息，并且，在SGSN收到UE的MBMS承载能力后进行比较的结果是：UE的MBMS承载能力大于等于要求的MBMS承载能力。这种情况下，实现多媒体广播/组播服务业务激活的方法如图5所示，包括以下步骤：
步骤501～506：与现有技术中步骤301～306的所有描述完全相同。
步骤507：SGSN收到当前发送加入消息的UE发来的携带有其MBMS承载能力的激活MBMS上下文请求Activate MBMS Context Request后，根据自身存储的所需MBMS承载业务要求的MBMS承载能力来判断，UE的MBMS承载能力是否小于所需MBMS承载业务要求的MBMS承载能力；得到UE的MBMS承载能力大于等于要求的MBMS承载能力的结果后，SGSN将UE的MBMS承载能力满足要求的比较结果通知当前发送加入消息的UE，UE收到允许消息后，继续执行步骤508；当然，也可以不通知UE比较结果，直接进入步骤508。
步骤508～511：与现有技术中步骤307～310的所有描述完全相同。
步骤512：与现有技术中步骤312的所有描述完全相同。
步骤513：与现有技术中步骤314的所有描述完全相同。
步骤514：SGSN发送一个激活MBMS上下文接受消息Activate MBMSContext Accept给UE，该消息中含有MBMS承载能力。这里，MBMS承载能力标识用于该MBMS承载业务最大的QoS，UE在激活更多MBMS承载业务时，可能会考虑该MBMS承载能力。
实施例二：
本实施例中，SGSN中已存有相关MBMS承载能力的信息，在SGSN收到UE的MBMS承载能力后进行比较的结果是：UE的MBMS承载能力小于要求的MBMS承载能力；得到比较结果后，SGSN拒绝该MBMS上下文请求的同时，向UE发送激活MBMS上下文拒绝消息，并且，SGSN也向GGSN发送激活MBMS上下文失败消息。这种情况下，实现多媒体广播/组播服务业务激活的方法如图6所示，包括以下步骤：
步骤601～步骤606：与现有技术中步骤301～306的所有描述完全相同。
步骤607～608：SGSN收到当前发送加入消息的UE发来的携带有其MBMS承载能力的激活MBMS上下文请求Activate MBMS Context Request后，根据自身存储的所需MBMS承载业务要求的MBMS承载能力来判断，UE的MBMS承载能力是否小于所需MBMS承载业务要求的MBMS承载能力；得到UE的MBMS承载能力小于要求的MBMS承载能力的结果后，SGSN拒绝当前的激活MBMS上下文请求。
步骤609：SGSN向UE发送激活MBMS上下文拒绝消息，该消息中携带有失败的原因指示，还可以携带所需MBMS承载业务要求的MBMS承载能力。
步骤610：SGSN向GGSN发送激活MBMS上下文失败消息，指示因为承载能力导致失败，GGSN可以根据实际情况确定是否回退到3GPP 29.061描述的IP组播接入规范。
实施例三：
本实施例中，SGSN中已存有相关MBMS承载能力的信息，在SGSN收到UE的MBMS承载能力后进行比较的结果是：UE的MBMS承载能力小于要求的MBMS承载能力；得到比较结果后，SGSN拒绝该MBMS上下文请求的同时，仅向UE发送激活MBMS上下文拒绝消息。这种情况下，实现多媒体广播/组播服务业务激活的方法如图7所示，包括以下步骤：
步骤701～708：与实施例二中步骤601～608的所有描述全部相同。
步骤709：SGSN向UE发送激活MBMS上下文拒绝消息，该消息中携带有失败的原因指示，还可以携带所需MBMS承载业务要求的MBMS承载能力。
步骤710：UE收到激活MBMS上下文拒绝消息后，重新申请进行3GPP29.061描述的IP组播接入规范，采用单播方式，即点到点(PTP)的方式来接收所需的组播业务。
对于本实施例，如果在步骤709 SGSN向UE发送激活MBMS上下文拒绝消息中，携带有所需MBMS承载业务要求的MBMS承载能力，那么，UE收到激活MBMS上下文拒绝消息后，也可以将所收到消息中要求的MBMS承载能力与自身的MBMS承载能力再做一次比较，得到自身MBMS承载能力小于要求的MBMS承载能力后，再重新中请以单播方式接收所需的组播业务。
实施例四：
本实施例中，SGSN中已存有相关MBMS承载能力的信息，在SGSN收到UE的MBMS承载能力后进行比较的结果是：UE的MBMS承载能力小于要求的MBMS承载能力；得到比较结果后，SGSN拒绝该MBMS上下文请求，然后向GGSN发送激活MBMS上下文失败消息。这种情况下，实现多媒体广播/组播服务业务激活的方法如图8所示，包括以下步骤：
步骤801～808：与实施例二中步骤601～608的所有描述全部相同。
步骤809：SGSN向GGSN发送激活MBMS上下文失败消息，指示因为承载能力导致失败，GGSN可以根据实际情况确定是否回退到3GPP 29.061描述的IP组播接入规范。
实施例五：
本实施例中，SGSN中已存有相关MBMS承载能力的信息，在SGSN收到UE的MBMS承载能力后进行比较的结果是：UE的MBMS承载能力小于要求的MBMS承载能力；得到比较结果后，SGSN拒绝该MBMS上下文请求，然后向GGSN发送激活MBMS上下文失败消息，之后再向UE发送激活MBMS上下文拒绝消息。这种情况下，实现多媒体广播/组播服务业务激活的方法如图9所示，包括以下步骤：
步骤901～908：与实施例二中步骤601～608的所有描述全部相同。
步骤909：SGSN向GGSN发送激活MBMS上下文失败消息，指示因为承载能力导致失败，GGSN可以根据实际情况确定是否回退到3GPP 29.061描述的IP组播接入规范。
步骤910：SGSN向UE发送激活MBMS上下文拒绝消息，该消息中携带有失败的原因指示，还可以携带所需MBMS承载业务要求的MBMS承载能力。
在上述五个实施例中，对于实施例二和实施例五，最后一个步骤都是SGSN向GGSN发送激活MBMS上下文失败消息，GGSN收到后可能会回退到3GPP29.061描述的IP组播接入规范，那么，对于GGSN不回退的情况，UE也可以在收到SGSN发来的激活MBMS上下文拒绝消息后，激活一个定时器，开始计时，同时判断GGSN是否执行回退，如果在定时器超时前GGSN执行回退，则停止相应的定时器；如果定时器超时，则UE重新申请进行3GPP 29.061描述的IP组播接入规范，采用单播方式即PTP的方式来接收所需的组播业务。
对于实施例四，UE在给SGSN发送激活MBMS上下文请求Activate MBMSContext Request后，激活一个定时器，开始计时。在定时器超时前，如果收到激活MBMS上下文接受消息，或者GGSN执行回退，则停止相应的定时器；如果定时器到时，没有收到激活MBMS上下文接受消息，或GGSN没有执行回退，则UE重新申请进行3GPP 29.061描述的IP组播接入规范，采用单播方式即PTP的方式来接收所需的组播业务。
对于实施例二和实施例五，如果在SGSN向UE发送激活MBMS上下文拒绝消息中，携带有所需MBMS承载业务要求的MBMS承载能力，那么，UE收到激活MBMS上下文拒绝消息后，也可以将所收到消息中要求的MBMS承载能力与自身的MBMS承载能力再做一次比较，得到自身MBMS承载能力小于要求的MBMS承载能力后，如果发现GGSN也未进行回退，则再重新申请以单播方式接收所需的组播业务。
实施例六：
本实施例中，SGSN中未存储相关MBMS承载能力的信息，但MBMS UE上下文成功激活，那么，先按现有技术流程继续处理，到最后一个步骤再比较UE的MBMS承载能力，并且，对于UE的MBMS承载能力小于要求的MBMS承载能力的情况，不仅对已建立的MBMS UE上下文去激活，而且SGSN要向GGSN发送激活MBMS上下文失败消息，GGSN根据实际情况确定是否回退到3GPP 29.061描述的IP组播接入。这种情况下，实现多媒体广播/组播服务业务激活的方法如图10所示，具体包括以下步骤：
步骤1001～1006：与现有技术中步骤301～306的所有描述完全相同。
步骤1007～1008：SGSN收到当前发送加入消息的UE发来的携带有其MBMS承载能力的激活MBMS上下文请求Activate MBMS Context Request后，发现自身未存储相关的MBMS承载能力，也就是说，该SGSN未进行注册，则SGSN无法判定UE的MBMS承载能力是否满足要求，所以，SGSN直接给发送MBMS通知请求的GGSN1返回MBMS通知响应，该响应中携带有原因，该原因用于指示是否成功激活MBMS UE上下文，以及如果不成功是由SGSN还是UE导致的。本实施例中，指示已成功进行MBMS UE上下文激活。
步骤1009～1015：与现有技术中步骤308～314的所有描述基本相同，其中，步骤1012和步骤1014是不能省略的。
步骤1016：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上下文的请求，向UE发送一个激活MBMS上下文拒绝消息，并指示一个恰当的理由，对已建立的MBMS UE上下文开始去激活过程，然后执行步骤1017。本实施例就是：UE的MBMS承载能力低于当前所需MBMS业务要求的MBMS承载能力的情况。
步骤1017：完成MBMS UE上下文去激活过程后，SGSN向GGSN1或GGSN2发送激活MBMS上下文失败消息，指示因为承载能力导致失败，GGSN1或GGSN2可以根据实际情况确定是否回退到3GPP 29.061描述的IP组播接入规范。
本实施中，对于GGSN不回退的情况，UE可以在步骤1016收到SGSN发来的激活MBMS上下文拒绝消息后，激活一个定时器，开始计时，同时判断GGSN是否执行回退，如果在定时器超时前GGSN执行回退，则停止相应的定时器；如果定时器超时，则UE重新申请进行3GPP 29.061描述的IP组播接入规范，采用单播方式即PTP的方式来接收所需的组播业务。
在本实施例中，如果在步骤1016 SGSN向UE发送激活MBMS上下文拒绝消息中，携带有所需MBMS承载业务要求的MBMS承载能力，那么，UE收到激活MBMS上下文拒绝消息后，也可以将所收到消息中要求的MBMS承载能力与自身的MBMS承载能力再做一次比较，得到自身MBMS承载能力小于要求的MBMS承载能力后，如果发现GGSN也未进行回退，则再重新申请以单播方式接收所需的组播业务。
实施例七：
本实施例中，SGSN中未存储相关MBMS承载能力的信息，但MBMS UE上下文成功激活，那么，先按现有技术流程继续处理，到最后一个步骤再比较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的方式来接收所需的组播业务。
在本实施例中，如果在步骤1116SGSN向UE发送激活MBMS上下文拒绝消息中，携带有所需MBMS承载业务要求的MBMS承载能力，那么，UE收到激活MBMS上下文拒绝消息后，也可以将所收到消息中要求的MBMS承载能力与自身的MBMS承载能力再做一次比较，得到自身MBMS承载能力小于要求的MBMS承载能力后，再重新申请以单播方式接收所需的组播业务。
在实际应用中，对于实施例六和实施例七的情况，也可以只完成去激活过程，就结束MBMS的业务激活流程，不再继续执行步骤1017或步骤1117。
以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (16)

1、一种实现多媒体广播/组播服务MBMS业务激活的方法，包括以下步骤：
a.当前需要接收组播业务的UE通过授权后，向自身所属SGSN发送携带有自身MBMS承载能力信息的请求；
其特征在于，该方法还包括：
b.所述SGSN判断自身是否存储有要求的MBMS承载能力，如果没有，则继续创建MBMS UE上下文，并结束当前处理流程；否则，执行步骤c；
c.判断当前要接收组播业务的UE的MBMS承载能力是否小于SGSN中存储的要求的MBMS承载能力，如果是，则SGSN拒绝来自UE的激活MBMS UE上下文的请求；否则，继续创建MBMS UE上下文。
2、根据权利要求1所述的方法，其特征在于，步骤a具体包括：
a1.当前需要接收组播业务的UE通过自身所属SGSN与网络进行交互建立分组数据协议上下文，并向网络发送加入消息；
a2.网络收到加入消息后，对发送加入消息的当前UE进行授权判决，如果授权未通过，则结束当前处理流程；如果授权通过，则网络允许发送加入消息的当前UE激活MBMS UE上下文，该当前UE向自身所属的SGSN发送携带有自身MBMS承载能力的信息。
3、根据权利要求1所述的方法，其特征在于，步骤c中SGSN拒绝激活MBMS UE上下文的请求后，进一步包括：
SGSN向当前UE发送激活MBMS上下文拒绝消息，该消息中携带有拒绝原因；SGSN向GGSN发送激活MBMS上下文失败消息，该消息中携带有失败原因，GGSN收到失败消息后，确定是否回退到单播方式的IP组播接入。
4、根据权利要求1所述的方法，其特征在于，步骤c中SGSN拒绝激活MBMS UE上下文的请求后，进一步包括：
c11.SGSN向当前UE发送激活MBMS上下文拒绝消息，该消息中携带有拒绝原因；
c12.所述UE收到拒绝消息后，重新申请以单播方式接收所需的组播业务。
5、根据权利要求1所述的方法，其特征在于，步骤c中SGSN拒绝激活MBMS UE上下文的请求后，进一步包括：
c21.SGSN向GGSN发送激活MBMS上下文失败消息，该消息中携带有失败原因，GGSN收到失败消息后，确定是否回退到单播方式的IP组播接入。
6、根据权利要求3或4所述的方法，其特征在于，所述SGSN向当前UE发送的激活MBMS上下文拒绝消息中，进一步携带有该UE所需MBMS承载业务要求的MBMS承载能力。
7、根据权利要求3所述的方法，其特征在于，该方法进一步包括：当前UE在收到SGSN发来的激活MBMS上下文拒绝消息后，激活一定时器，并判断在定时器时间内GGSN是否回退到单播方式的IP组播接入，如果回退，则停止定时器；如果定时器超时，则当前UE重新申请以单播方式接收所需的组播业务。
8、根据权利要求5所述的方法，其特征在于，该方法进一步包括：UE在向自身所属SGSN发送携带有自身MBMS承载能力的信息后，激活一定时器，并判断在定时器时间内，是否收到激活MBMS上下文接受消息或者GGSN是否回退到单播方式的IP组播接入，如果是，则停止定时器；如果定时器超时，则当前UE重新申请以单播方式接收所需的组播业务。
9、根据权利要求4所述的方法，其特征在于，所述SGSN向当前UE发送的激活MBMS上下文拒绝消息中携带该UE所需MBMS承载业务要求的MBMS承载能力，则步骤c12中UE收到拒绝消息后，先将要求的MBMS承载能力与自身的MBMS承载能力进行比较，如果要求的MBMS承载能力大于自身的MBMS承载能力，再重新申请以单播方式接收所需的组播业务。
10、根据权利要求3所述的方法，其特征在于，所述SGSN向当前UE发送的激活MBMS上下文拒绝消息中携带该UE所需MBMS承载业务要求的MBMS承载能力，则UE收到激活MBMS上下文拒绝消息后，将要求的MBMS承载能力与自身的MBMS承载能力进行比较，如果要求的MBMS承载能力大于自身的MBMS承载能力且GGSN未进行回退，再重新申请以单播方式接收所需的组播业务。
11、根据权利要求1所述的方法，其特征在于，步骤b中如果SGSN中未存储要求的MBMS承载能力，则继续执行现有MBMS业务激活流程中创建MBMS UE上下文的过程，并且，在SGSN确定UE的MBMS承载能力低于当前所需MBMS业务要求的MBMS承载能力，去激活当前已建立的MBMS UE上下文后，SGSN向GGSN发送激活MBMS上下文失败消息，GGSN收到失败消息后，确定是否回退到单播方式的IP组播接入。
12、根据权利要求11所述的方法，其特征在于，该方法进一步包括：当前UE在收到SGSN发来的激活MBMS上下文拒绝消息后，激活一定时器，并判断在定时器时间内GGSN是否回退到单播方式的IP组播接入，如果回退，则停止定时器；如果定时器超时，则当前UE重新申请以单播方式接收所需的组播业务。
13、根据权利要求11所述的方法，其特征在于，所述SGSN向GGSN发送激活MBMS上下文失败消息为：SGSN向与当前UE建立初始PDP上下文的GGSN发送激活MBMS上下文失败消息；或为SGSN向曾与当前UE创建MBMS UE上下文的GGSN发送激活MBMS上下文失败消息。
14、根据权利要求11所述的方法，其特征在于，所述SGSN向当前UE发送的激活MBMS上下文拒绝消息中携带该UE所需MBMS承载业务要求的MBMS承载能力，则UE收到激活MBMS上下文拒绝消息后，将要求的MBMS承载能力与自身的MBMS承载能力进行比较，如果要求的MBMS承载能力大于自身的MBMS承载能力且GGSN未进行回退，再重新中请以单播方式接收所需的组播业务。
15、根据权利要求1所述的方法，其特征在于，步骤b中如果SGSN中未存储要求的MBMS承载能力，则继续执行现有MBMS业务激活流程中创建MBMS UE上下文的过程，并且，在SGSN确定UE的MBMS承载能力低于当前所需MBMS业务要求的MBMS承载能力，去激活当前已建立的MBMS UE上下文后，当前UE重新申请以单播方式接收所需的组播业务；或者，在SGSN确定UE的MBMS承载能力低于当前所需MBMS业务要求的MBMS承载能力，当前UE收到SGSN发来的激活MBMS上下文拒绝消息后，重新申请以单播方式接收所需的组播业务。
16、根据权利要求15所述的方法，其特征在于，所述SGSN向当前UE发送的激活MBMS上下文拒绝消息中携带该UE所需MBMS承载业务要求的MBMS承载能力，则UE收到拒绝消息后，先将要求的MBMS承载能力与自身的MBMS承载能力进行比较，如果要求的MBMS承载能力大于自身的MBMS承载能力，再重新申请以单播方式接收所需的组播业务。
CNB2004100316034A 2004-03-29 2004-03-29 一种实现多媒体广播/组播服务业务激活的方法 Expired - Lifetime CN1266898C (zh)

Priority Applications (7)

Application Number Priority Date Filing Date Title
CNB2004100316034A CN1266898C (zh) 2004-03-29 2004-03-29 一种实现多媒体广播/组播服务业务激活的方法
EP20050738124 EP1737254B1 (en) 2004-03-29 2005-03-25 Method for activating multimedia broadcast/multicast service
JP2007505357A JP4425307B2 (ja) 2004-03-29 2005-03-25 マルチメディアブロードキャスト／マルチキャストサービスの起動方法
US10/594,646 US8842593B2 (en) 2004-03-29 2005-03-25 Method for activating multimedia broadcast/multicast service
PCT/CN2005/000382 WO2005099286A1 (en) 2004-03-29 2005-03-25 Method for activating multimedia broadcast/multicast service
AT05738124T ATE424697T1 (de) 2004-03-29 2005-03-25 Verfahren zum aktivieren eines multimedia- broadcast/multicast-dienstes
DE200560013072 DE602005013072D1 (de) 2004-03-29 2005-03-25 Verfahren zum aktivieren eines multimedia-broadcast/multicast-dienstes

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CNB2004100316034A CN1266898C (zh) 2004-03-29 2004-03-29 一种实现多媒体广播/组播服务业务激活的方法

Publications (2)

Publication Number Publication Date
CN1642132A CN1642132A (zh) 2005-07-20
CN1266898C true CN1266898C (zh) 2006-07-26

Family

ID=34868498

Family Applications (1)

Application Number Title Priority Date Filing Date
CNB2004100316034A Expired - Lifetime CN1266898C (zh) 2004-03-29 2004-03-29 一种实现多媒体广播/组播服务业务激活的方法

Country Status (7)

Country Link
US (1) US8842593B2 (zh)
EP (1) EP1737254B1 (zh)
JP (1) JP4425307B2 (zh)
CN (1) CN1266898C (zh)
AT (1) ATE424697T1 (zh)
DE (1) DE602005013072D1 (zh)
WO (1) WO2005099286A1 (zh)

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7792984B2 (en) * 2003-01-23 2010-09-07 International Business Machines Corporation Systems and methods for the distribution of bulk data using multicast routing that mitigates network traffic on subnets
CN100379221C (zh) * 2004-01-08 2008-04-02 华为技术有限公司 一种多媒体组播业务的注册方法
CN100421520C (zh) * 2005-09-05 2008-09-24 华为技术有限公司 一种基于移动网络的ip组播***和方法
CN100411377C (zh) * 2005-10-31 2008-08-13 华为技术有限公司 一种组播业务激活方法
CN100407812C (zh) * 2005-12-20 2008-07-30 华为技术有限公司 一种实现小区多媒体广播业务的方法
EP1811736A1 (en) * 2006-01-18 2007-07-25 Matsushita Electric Industrial Co., Ltd. Providing service data of a bidirectional service (IMS, e.g. PoC, conference) by using a downlink multicast service (e.g. MBMS)
CN1859403B (zh) * 2006-02-09 2010-05-12 华为技术有限公司 在客户端/服务器模式业务***中进行能力协商的方法
US7953006B2 (en) * 2006-02-09 2011-05-31 Nokia Corporation Handling multiple point-to-multipoint services
CN1859406A (zh) * 2006-02-14 2006-11-08 华为技术有限公司 一种多媒体广播/组播业务激活的方法
CN100428749C (zh) * 2006-02-14 2008-10-22 华为技术有限公司 一种多媒体广播/组播业务组播激活的方法
CN101052150B (zh) * 2006-04-07 2010-05-12 华为技术有限公司 一种多媒体多播/广播业务控制方法及网络结点
CN100459549C (zh) * 2006-06-26 2009-02-04 华为技术有限公司 一种加入广播/多播业务服务方法及装置
WO2008082572A1 (en) * 2006-12-29 2008-07-10 Interdigital Technology Corporation Method and apparatus for transmitting and receiving multimedia broadcast multicast services via a dedicated downlink carrier
CN101227352B (zh) * 2007-01-15 2011-02-09 华为技术有限公司 用户终端紧急注册到ip连接接入网络的方法及***
KR101147580B1 (ko) 2007-01-30 2012-05-21 닛본 덴끼 가부시끼가이샤 이동 통신 시스템, 멀티캐스트 데이터 분배 방법, 코어 네트워크 장치, 및 액세스 네트워크 장치
GB2458885A (en) * 2008-03-20 2009-10-07 Nec Corp Accepting or rejecting a connection request based upon capability information of a user device
US9066354B2 (en) * 2008-09-26 2015-06-23 Haipeng Jin Synchronizing bearer context
CN102045691B (zh) * 2009-10-10 2014-06-11 中兴通讯股份有限公司 获取物联网设备组别标识的方法及装置
US9204415B2 (en) 2009-10-30 2015-12-01 Panasonic Intellectual Property Corporation Of America Communication system and apparatus for status dependent mobile services
CN102158911A (zh) * 2010-02-11 2011-08-17 华为技术有限公司 机器对机器业务的承载建立方法及网络传输设备
US8577385B2 (en) * 2010-12-31 2013-11-05 Motorola Solutions, Inc. Method and system for delivering media to a plurality of mobile devices in a cell with a group transport function
CN103581860A (zh) * 2012-07-23 2014-02-12 中兴通讯股份有限公司 用户设备辅助信息拒绝方法、装置和***
US20140105125A1 (en) * 2012-10-16 2014-04-17 Qualcomm Incorporated Criteria for ue-initiated bearer deactivation when maximum number of active bearers has been reached
US9521077B2 (en) * 2013-07-22 2016-12-13 Verizon Patent And Licensing Inc. Network connection via a proxy device using a generic access point name
CN104640077B (zh) * 2013-11-08 2019-10-11 中兴通讯股份有限公司 一种集群通信的方法及***、用户设备和网络侧设备
WO2015096160A1 (zh) * 2013-12-27 2015-07-02 华为技术有限公司 一种保持业务连续性的方法及设备
EP3096573B1 (en) * 2014-01-13 2018-10-24 LG Electronics Inc. Downlink data transfer method
JP2017531385A (ja) * 2014-09-15 2017-10-19 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． 進化型マルチメディアブロードキャスト／マルチキャストサービス処理ネットワーク要素及び進化型マルチメディアブロードキャスト／マルチキャストサービスブロードキャスト方法

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6426945B1 (en) * 1998-10-06 2002-07-30 Nokia Telecommunications, Oy Method and apparatus for providing resource discovery using multicast scope
WO2003019840A2 (en) * 2001-08-23 2003-03-06 Bamboo Mediacasting Inc. Multicast transmission in packet based cellular networks
US6701155B2 (en) * 2002-01-11 2004-03-02 Nokia Corporation Network initialized packet data protocol context activation for multicast/broadcast services
JP4002204B2 (ja) * 2002-04-09 2007-10-31 三星電子株式会社 移動通信システムにおけるマルチメディア放送／マルチキャストサービスのための制御情報伝送装置及びその方法
CN1177433C (zh) * 2002-04-19 2004-11-24 华为技术有限公司 一种移动网络中广播多播业务源的管理方法
AU2003204003B9 (en) 2002-05-03 2005-06-02 Qualcomm Incorporated Apparatus and method for multimedia broadcast/multicast service in a mobile communication system
KR20040014706A (ko) 2002-08-10 2004-02-18 삼성전자주식회사 멀티캐스트 멀티미디어 방송 서비스를 제공하는 이동 통신시스템에서 제어 메시지 송수신 방법
KR20040016540A (ko) * 2002-08-17 2004-02-25 삼성전자주식회사 멀티캐스트 멀티미디어 방송 서비스를 제공하는 이동 통신시스템에서 핸드오버시 데이터 송수신 장치 및 방법
US7391724B2 (en) * 2002-10-09 2008-06-24 Spyder Navigations, L.L.C. System and method with policy control function for multimedia broadcast/multicast system services
KR100594101B1 (ko) * 2003-01-20 2006-06-30 삼성전자주식회사 비추적 영역에서 멀티캐스트 멀티미디어 방송 서비스를제공하는 시스템 및 방법
US20070201430A1 (en) * 2005-12-29 2007-08-30 Telefonaktiebolaget Lm Ericsson (Publ) Implicit secondary PDP context activation method

Also Published As

Publication number Publication date
EP1737254B1 (en) 2009-03-04
US8842593B2 (en) 2014-09-23
US20080232292A1 (en) 2008-09-25
CN1642132A (zh) 2005-07-20
DE602005013072D1 (de) 2009-04-16
JP2007531425A (ja) 2007-11-01
EP1737254A1 (en) 2006-12-27
EP1737254A4 (en) 2007-05-09
ATE424697T1 (de) 2009-03-15
WO2005099286A1 (en) 2005-10-20
JP4425307B2 (ja) 2010-03-03

Similar Documents

Publication Publication Date Title
CN1266898C (zh) 一种实现多媒体广播/组播服务业务激活的方法
CN1306766C (zh) 多媒体广播组播业务***中业务识别和路由方法
CN1303799C (zh) 一种控制多媒体广播/组播服务会话进行的方法
CN1684414A (zh) 一种多媒体广播/组播业务的会话开始方法
CN1268089C (zh) 多媒体广播/组播服务业务数据传输的方法
CN1592167A (zh) 支持mbms后向兼容性的方法
US20070014291A1 (en) Method for multimedia broadcast/multicast service registration
CN1751458A (zh) 在无线通信网络中用于支持无线终端的移动性的装置和方法
CN1457165A (zh) 移动通信***中多媒体广播/多播服务的设备和方法
CN1836389A (zh) 在支持多媒体广播组播业务的移动通信***中用专用信道对用户设备分页的方法
CN1756429A (zh) 多媒体广播/组播业务中小区信息变化的通知方法
CN100346596C (zh) 多媒体广播/组播服务业务激活的方法
CN1859305A (zh) 一种多媒体广播/组播业务中建立gtp隧道的方法
CN1581744A (zh) 为mbms业务提供多种qos的方法
CN1717076A (zh) 一种实现集群业务的***和方法
CN101047976A (zh) 一种多媒体广播/组播业务中授权失败处理方法及***
CN1677971A (zh) 实现多媒体广播/组播服务业务激活的方法
CN1691676A (zh) 多媒体广播/组播业务中确定接收用户数目的方法
CN1968451A (zh) 一种确定使用组播/广播业务时间的方法及***
CN1180639C (zh) 多播业务中选择无线信道配置的方法
CN1794859A (zh) 一种实现多媒体组播广播业务去激活的方法
CN1933439A (zh) 用户加入多组播/广播业务的实现方法及装置
CN1747399A (zh) 一种实现多媒体广播/组播业务调度的业务传输方法
CN1665318A (zh) 引入mbms业务标识的方法
CN1489314A (zh) 在sgsn和ggsn中建立和清除mbms业务的方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
EE01 Entry into force of recordation of patent licensing contract

Application publication date: 20050720

Assignee: APPLE Inc.

Assignor: HUAWEI TECHNOLOGIES Co.,Ltd.

Contract record no.: 2015990000755

Denomination of invention: Method for realizing multimedia broadcast/multi cast service business activation

Granted publication date: 20060726

License type: Common License

Record date: 20150827

LICC Enforcement, change and cancellation of record of contracts on the licence for exploitation of a patent or utility model
CX01 Expiry of patent term
CX01 Expiry of patent term

Granted publication date: 20060726