CN101094512A

CN101094512A - 一种在组播业务中建立用户上下文和承载上下文的方法

Info

Publication number: CN101094512A
Application number: CNA200610127689XA
Authority: CN
Inventors: 蔡建楠; 王志海
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2006-09-07
Filing date: 2006-09-07
Publication date: 2007-12-26

Abstract

一种在组播业务中建立用户上下文和承载上下文的方法，源SRNC发起SRNS重定位后，在重定位完成过程中，如果新的SGSN支持组播业务，对于每个在重定位准备过程收到的UE的每一个组播业务用户上下文，新的SGSN向该上下文对应的特殊GGSN发送更新组播业务用户上下文请求消息；特殊GGSN更新所述组播业务用户上下文的相应部分，向SGSN返回更新组播业务用户上下文响应消息；新的SGSN判断出所述组播业务用户上下文的更新是否成功，检测每一个更新成功的组播业务用户上下文是否已有相应的组播业务承载上下文，如果没有，则为该用户上下文创建一个组播业务承载上下文，并发起组播业务注册流程。本发明可以避免浪费系统资源。

Description

一种在组播业务中建立用户上下文和承载上下文的方法

技术领域

本发明涉及移动通信系统组播业务中建立用户上下文和承载上下文的方法。

背景技术

MBMS：Multimedia Broadcast/Multicast Service，组播和广播业务

GTP-C：GPRS Tunnelling Protocol for Control Plane。GPRS隧道协议控制面。

SGSN：Service GSN，服务GPRS支持节点，核心网侧负责移动性管理的网元。

GGSN：Gateway GSN，网关GPRS支持节点，核心网侧负责接入到和发送出核心网的网元。

TEID：Tunnel Entity Identity，隧道端点标识符，在一个网元里标识一个隧道；SGSN与GGSN间的GTP隧道通过TEID标识。

TEID-C：用于控制面的隧道端点标识。

TMGI：Temporary Mobile Group Identity。临时移动组标识

为了有效地利用移动网络资源，现有移动通信系统提出了使用组播和广播传输业务的思想，即MBMS。MBMS在移动网络中提供一个数据源向多个用户发送数据的点到多点业务，实现网络资源共享，提高网络资源的利用率，尤其是空口接口资源。MBMS提供两种方式：广播方式和组播方式。MBMS不仅能实现纯文本低速率的消息类组播和广播，而且还能实现高速多媒体业务的组播和广播，组播和广播业务MBMS基于WCDMA/GSM分组网，通过增加一些新的功能实体，如广播组播业务中心BM-SC，对已有的分组域功能实体如SGSN(分组服务节点)、GGSN(分组网关节点)、RAN(无线接入网络)和UE(用户终端)增加MBMS功能，并定义了新的逻辑共享信道来实现空口资源共享。移动通信系统下使用MBMS的网络架构如图1所示。

除了BM-SC以外，都是移动通信系统的承载网元，完成数据传输功能。GGSN与BM-SC之间的信令交换在Gmb参考点进行，实现MBMS的控制面，包括以下信令：

-GGSN建立MBMS的承载上下文并在BMSC注册。

-GGSN或者BM-SC释放MBMS承载上下文，GGSN在BM-SC去注册。

-BM-SC向GGSN通知会话开始和结束。

实现接入MBMS业务，需要一系列的步骤和信令交互，至少包括业务通知，用户加入广播或组播组(包括激活、注册等)的接入步骤，以及离开(包括去活、注销等)的步骤，

为了完成MBMS信令和MBMS业务数据传输的处理，现有MBMS机制对已有的分组域核心网功能实体SGSN和GGSN，增加了MBMS ServiceContext和MBMS UE Context两种上下文，分别用于记录某一个业务的相关信息，和用户的针对某个业务的上下文信息。

现有技术中，MBMS UE Context的建立由激活流程完成的。用户需要加入组播组时，发起激活流程，完成在网络侧用户上下文的建立。MBMSService Context的建立由注册流程完成的。两种上下文的建立经常是由一个条件触发，前后在一个流程中完成的。触发条件可以是：

1)用户需要接入某个MBMS业务，发起了MBMS激活请求，但网络侧的网元(如SGSN或GGSN)发现还没有该业务的承载上下文信息，就向其上游节点发起注册消息。激活流程如图2所示。

2)用户重定位流程中，新的SGSN发现还没有该业务的承载上下文，就向GGSN发起注册消息。随后又完成用户上下文的更新。重定位流程如图3所示。

激活流程发生在用户需要加入一个组播组。激活流程中的注册和创建上下文请求的步骤完成承载上下文和用户上下文的建立。说明如下：

101.如果没有已经建立好地PDP上下文，则UE激活一个通用的PDP上下文。使用的GGSN称为缺省GGSN(Default GGSN)。

102.通过默认的PDP上下文，UE向网络侧缺省GGSN发送IGMP(IPv4)或的MLD(IPv6)加入消息来表示愿意接收由IP组播地址标识的某个MBMS组播承载业务。

103.缺省GGSN向BM-SC发送MBMS授权请求，要求对UE进行授权从而能够接收数据。如果Trace被激活，该请求中可以包含Trace信息(附加MBMS Trace信息)。

104.BM-SC向缺省GGSN发送MBMS授权响应，响应中包含授权判决和用来建立MBMS UE上下文的APN，授权判决基于BM-SC成员功能中的签约数据来产生。如果MBMS授权响应表明UE授权不成功，则过程中止。

105.缺省GGSN向SGSN发送MBMS通知请求(IP组播地址、APN、相关联NSAPI)。其中相关联NSAPI和默认PDP上下文的NSAPI相等，IP组播地址是UE发起加入请求时的IP组播地址，APN不同于默认PDP上下文对应的APN，即：此时的APN解析的GGSN(即Specific GGSN，特殊GGSN)可能和接收加入请求的缺省GGSN不同。缺省GGSN开启MBMS激活定时器。

106.SGSN向发送MBMS通知请求的缺省GGSN发送MBMS通知响应，响应中包含是否能够进行MBMS上下文激活的原因。如果原因中表示不能进行MBMS上下文激活，则缺省GGSN不能继续发送有关通知请求的消息，过程中止。

107.SGSN向UE发送“请求激活MBMS上下文”(IP组播地址、APN、相关联NSAPI、TI)请求激活MBMS UE上下文。UE可通过相关联NSAPI将MBMS UE上下文和第二步中的默认PDP上下文相关联。TI由SGSN选择并且它的值要和该UE激活的所有其它PDP上下文及MBMS UE上下文不同。

108.UE建立MBMS UE上下文并向SGSN发送“激活MBMS上下文请求”(IP组播地址、APN、MBMS_NSAPI、MBMS承载能力)。其中IP组播地址标识UE要加入的MBMS组播业务，APN解析一个特殊GGSN，MBMS承载能力标识UE能够处理的最大QoS，MBMS_NSAPI由UE选择并且它的值和该UE激活的所有其它PDP上下文及MBMS UE上下文不同。如果SGSN中已经有了对应该MBMS承载业务的上下文信息，则它要验证UE的MBMS承载能力。如果SGSN验证UE的MBMS承载能力低于要求的MBMS承载能力，则拒绝UE的请求并指明原因。

109.如果SGSN不能建立MBMS UE上下文，则向缺省GGSN发送“MBMS通知拒绝请求”消息，其中包含拒绝的原因。

110.缺省GGSN收到消息后向SGSN发送响应。使得缺省GGSN不会继续发送“MBMS通知请求”消息，从而过程中止。

111.安全功能，如：认证UE.

112.在A/Gb模式下如果BSS trace激活，则SGSN向BSS发送“调用Trace消息”(Trace参考、Trace类型、Trigger标识、OMC标识)，其中的Trace参考和Trace类型来自HLR或OMC发来的Trace信息。

113.SGSN创建MBMS UE上下文后，向特殊GGSN发送“创建MBMS上下文的请求”(IP组播地址、APN、MBMS_NSAPI、IMSI、MSISDN、RAI、IMEI-SV、RAT类型、MS时间区、GGI/SAI、Trace参考、Trace类型、Trigger标识、OMC标识、附加MBMS Trance信息)，其中Trace参考、Trace类型、Trigger标识和OMC标识是SGSN从HLR或OMC发来的Trace信息中复制的，并且仅在GGSN Trace激活的情况下存在，附加MBMS Trace信息在BM-SC Trace激活的情况下存在。

114.特殊GGSN向BM-SC发送“MBMS授权请求”(IMSI、MSISDN、RAI、IMEI-SV、RAT类型、MS时间区、GGI/SAI、附加MBMS Trance信息)对UE进行授权，其中附加MBMS Trace信息在BM-SC Trace激活的情况下存在。

115.BM-SC回MBMS授权响应，MBMS授权响应中包含了授权判决信息，BM-SC创建MBMS UE上下文。

116.如果特殊GGSN中没有关于某个MBMS承载业务的MBMS承载上下文信息，则特殊GGSN向BM-SC发送“MBMS注册请求”，见“MBMS注册过程”。如果没有分配的TMGI，则BM-SC分配TMGI，这个TMGI通过“MBM注册响应”消息传递给特殊GGSN和SGSN，通过“激活MBMS上下文接受”消息传递给UE。

117.BM-SC向特殊GGSN发送“MBMS注册响应”消息，其中包含了对应某个MBMS承载业务的MBMS承载上下文信息，并且在自己上下文信息中的“下行节点列表”参数中增加特殊GGSN的标识，见“MBMS注册过程”。

118.特殊GGSN创建MBMS UE上下文，并向SGSN发送创建MBMS上下文响应。

119.如果SGSN中没有相应的MBMS承载上下文信息，则SGSN向特殊GGSN发送“MBMS注册请求”，见“MBMS注册过程”。

120.特殊GGSN向SGSN发送“MBMS注册响应”消息，其中包含MBMS承载上下文信息，同时GGSN在自己上下文信息中的“下行节点列表”参数中增加SGSN的标识，见“MBMS注册过程”。

121.如果至少存在一个PS RAB，则SGSN向Iu模式下的RAN提供MBMS UE上下文。

122.如果在Iu模式下Trace被激活，则SGSN向RAN发送“调用Trace信息”消息(Trace参考、Trace类型、Trigger标识、OMC标识)，其中的Trace参考和Trace类型来自HLR或OMC发来的Trace信息。

123.SGSN向UE发送“激活MBMS上下文接受”消息(TMGI、MBMS承载能力)其中MBMS承载能力标识该MBMS承载业务使用的最大Qos，UE在激活其它MBMS业务时可作为参考。如果在第六步中不能验证UE的MBMS承载能力，可以在此时进行验证，如果SGSN证实UE的MBMS承载能力低于要求的承载能力，则SGSN拒绝激活MBMS上下文的请求，并去活已经建立的MBMS UE上下文。

重定位流程发生在用户移动到了新的位置区，而该位置区属于不同于现有SGSN(简称为旧的SGSN)的一个新的SGSN。流程中和创建上下文相关的步骤是注册流程和更新上下文流程。说明如图3所示：

201.源服务无线网络控制器SRNC(Source Rnc)决定执行SRNS(源无线网络子系统)重定位。

202.源SRNC发送要求重定位(Reocation Required)消息给旧的SGSN，发起重定位准备过程。

203.旧的SGSN从目标RNC ID来确定SRNS重定位是SGSN局内的重定位还是SGSN局间的重定位。如果是SGSN SRNS之间的重定位，SGSN发送前转重定位请求(Forward Relocation Request)消息给新SGSN。同时在旧的SGSN中启动一个定时器。前转重定位请求消息只适用于SGSNSRNS之间的重定位情况。如果MS加入了组播业务，旧的SGSN在前转重定位请求消息(Forward Relocation Request)中带上MBMS UE上下文。

204.新SGSN发送重定位请求消息给目标RNC请求建立RAB。

205.目标RNC应发送重定位请求确认消息给新SGSN。

206.当目标RNC和新SGSN之间的用户数据传送资源已分配好，并且新SGSN已为SRNS的重定位准备就绪，则新的SGSN发送前转重定位响应消息给旧的SGSN。前转重定位响应消息只适用于SGSN SRNS内部(局间)的重定位。如果新的SGSN支持MBMS，则在前转重定位响应消息(ForwardRelocation Response)中指示它的MBMS支持情况。

207.旧的SGSN发送重定位命令给源SRNC，继续SRNS的重定位。

208.源SRNC为受数据转发制约的RAB开始转发数据到目标RNC。

以上是重定位准备过程。

209.从旧的SGSN接收到重定位命令消息后，源RNC应启动数据转发定时器。当重定位准备过程成功终止，且SRNC准备完毕，源SRNC发送重定位提交消息(SRNS上下文)给目标RNC，触发SRNS重定位的执行。

210.当接收到重定位执行触发时，目标RNC应发送重定位监测消息给新的SGSN。对“不涉及UE”的SRNS重定位类型，重定位执行触发是对来自Iur接口的重定位提交消息的接受。当重定位监测消息被发送时，目标RNC应启动SRNC运行。

211.发送重定位检测消息后，目标SRNC发送RAN移动信息给MS。

212.MS给目标SRNC回RAN移动信息确认。

以上是重定位执行过程。

213.目标SRNC通过发送重定位完成消息给新SGSN发起重定位完成过程。重定位完成过程的目的是由目标SRNC向CN表明SRNS重定位的完成。

214.新的SGSN给旧的SGSN发送前转重定位完成消息，通知旧的SGSN重定位过程的完成。

215.旧的SGSN会给新的SGSN回前转重定位完成确认消息。

216.新的SGSN给缺省GGSN(Default GGSN)发送更新PDP上下文请求。

217.缺省GGSN给新的SGSN回更新PDP上下文响应消息。

218.如果新的SGSN支持MBMS，它针对收到的每个MBMS UE上下文检测是否有相应MBMS承载上下文。对于每个在SGSN中还未存在的MBMS承载上下文，SGSN创建一个MBMS承载上下文(置于″Standby″状态)，并发起MBMS注册流程。

219.旧的SGSN给源Rnc发送Iu释放请求。

220.源Rnc会给SGSN回Iu释放完成消息。

221.如果在步骤206中新SGSN指示不支持MBMS，则原来的SGSN通过发起去激活流程将SGSN、GGSN和BM-SC中UE的所有MBMS UE上下文去激活。

222.如果原来的SGSN在该MBMS承载业务上不再有MBMS UE上下文且相应MBMS承载上下文的″list of downstream nodes″为空，则SGSN发起MBMS注销流程。

223.如果新的SGSN支持MBMS，对于每个在步骤203收到的MBMS UE上下文，新的SGSN向相关的GGSN发送更新MBMS UE上下文请求消息(携带服务网络标识，MS Time Zone，CGI/SAI，RAT Type，附加的MBMS追踪信息)。

224.GGSN更新这些MBMS UE上下文的相应部分，并且返回更新MBMS UE上下文响应消息。GGSN将更新后的服务网络标识发送给BM-SC。是否需要包括CGI/SAI，则根据定义在3GPP TS 23.060 15.1.1a节中定义的规则执行。

225.如果GGSN从新SGSN收到新的或更新的附加的MBMS追踪信息，GGSN发送一个激活追踪消息给BM-SC。

226.重定位流程完成以后，后续需要完成一个路由更新过程。不支持MBMS的SGSN在路由区域更新接受消息中不指示MBMS特性支持。另一方面，如果SGSN支持MBMS，到UE的路由区域更新接受消息指示网络支持MBMS。

由上述重定位流程中的触发条件和步骤可以看到，在SGSN和GGSN中，针对某一个MBMS业务，MBMS承载上下文的建立和MBMS用户上下文的建立是两个相对独立的过程，没有一个次序的概念。这样存在的问题是，一个上下文建立完成了，另一个上下文建立失败了，就会删除那个刚建立好的上下文。比如在重定位流程中，新的SGSN向特殊GGSN发送更新MBMS用户上下文，如果特殊GGSN不存在此上下文，导致更新失败，如果此时SGSN刚建立完成MBMS承载上下文，就可能导致该MBMS承载上下文的删除。从而造成对系统资源的浪费。

发明内容

本发明要解决的问题是提出一种在组播业务中建立用户上下文和承载上下文的方法，可以避免浪费系统资源。

经研究，用户上下文失败的因素是多于承载上下文的，因为用户上下文在创建时会涉及签约内容，在更新时涉及对方网元是否存在该用户的MBMS上下文等问题。而承载上下文涉及的是两个网元之间的协商问题，除非连接中断，否则很难出现失败的问题。

为了解决上述技术问题，本发明提供了一种在组播业务中建立用户上下文和承载上下文的方法，包括以下步骤：

(a)源SRNC发起SRNS重定位后，在重定位完成过程中，如果新的SGSN支持组播业务，对于每个在重定位准备过程收到的UE的每一个组播业务用户上下文，新的SGSN向该上下文对应的特殊GGSN发送更新组播业务用户上下文请求消息；

(b)特殊GGSN更新所述组播业务用户上下文的相应部分，向SGSN返回更新组播业务用户上下文响应消息；

(c)新的SGSN判断出所述组播业务用户上下文的更新是否成功，检测每一个更新成功的组播业务用户上下文是否已有相应的组播业务承载上下文，如果没有，则为该用户上下文创建一个组播业务承载上下文，并发起组播业务注册流程。

在一较佳实施例中，所述步骤(a)中，在重定位完成过程中，是在完成了新的SGSN和缺省GGSN之间完成PDP上下文响应消息的更新后，新的SGSN再向所述特殊GGSN发送更新组播业务用户上下文请求消息。

在一较佳实施例中，所述步骤(a)中，源SRNC发起SRNS重定位后，在重定位准备阶段，旧的SGSN发送前转重定位请求消息给新SGSN，如果MS加入了组播业务，该消息中带有组播业务用户上下文。

在一较佳实施例中，所述步骤(d)之后还包括步骤：如果GGSN从新SGSN收到新的或更新的附加的组播业务追踪信息，GGSN发送一个激活追踪消息给BM-SC。

在一较佳实施例中，所述步骤(c)中，新的SGSN为用户上下文创建一个组播业务承载上下文时，是将其置为″待命″状态。

在一较佳实施例中，所述步骤(b)中，特殊GGSN向SGSN返回更新组播业务用户上下文响应消息中指示了更新成功或失败的信息；所述步骤(c)中，新的SGSN据此判断出所述组播业务用户上下文的更新是否成功。

由上可知，本发明在SGSN上如果组播业务承载上下文和组播业务用户上下文都需要创建或更新时，优先建立或更新用户上下文，在完成用户上下文的操作，再进行承载上下文的操作。本发明通过优先建立或更新用户上下文，在完成用户上下文的操作，或可以确认能够完成用户上下文的操作之后，再进行承载上下文的操作。避免了在用户上下文建立失败后，需要删除刚建立完成的组播业务承载上下文的现象，从而避免了系统资源的浪费。

附图说明

图1是移动通信系统下使用MBMS的网络架构图。

图2是现有MBMS激活的流程图。

图3是现有重定位流程中的MBMS上下文建立的流程图。

图4是本发明实施例的重定位流程图。

具体实施方式

本实施例流程优化了原流程中新SGSN与GGSN交互建立组播业务(本发明不针对广播业务)上下文的步骤，如下：

301-317.同背景技术描述中重定位流程的步骤201-217；

即：源SRNC(Source Rnc)决定执行SRNS重定位，完成了重定位准备过程和重定位执行过程。其中，在重定位准备阶段，旧的SGSN发送前转重定位请求消息给新SGSN，如果MS加入了组播业务，该消息中带有组播业务UE上下文。而在重定位完成过程，新的SGSN和缺省GGSN之间完成了PDP上下文响应消息的更新。

318-319.同背景技术描述中重定位流程的步骤219-220；

即：旧的SGSN和源Rnc之间完成Iu口资源的释放。应注意的是，该两步操作与新的SGSN与缺省GGSN之间的PDP上下文更新，以后下面要提到的组播业务用户上下文更新是在两个SGSN上的动作，并没有必然的先后关系。

320.同背景技术描述中重定位流程的223步骤；

即：如果新的SGSN支持组播业务，对于每个在步骤203收到的组播业务UE上下文，新的SGSN向该上下文对应的特殊GGSN(Specific GGSN)发送更新组播业务用户上下文请求消息。

321.同背景技术描述中重定位流程的224步骤；

即：特殊GGSN更新这些组播业务用户上下文的相应部分，如果完成更新，向SGSN返回更新组播业务UE上下文成功的响应消息。如果更新失败，可以返回一个指示更新失败的响应消息。

322.同背景技术描述中重定位流程的步骤218；

即：新的SGSN判断各个组播业务UE上下文的更新是否成功，对于每一个更新成功的组播业务UE上下文，检测是否有相应组播业务承载上下文。对于每个在SGSN中还未存在的组播业务承载上下文，新的SGSN创建一个组播业务承载上下文(置于″待命(Standby)″状态)，并发起组播业务注册流程。

以上步骤320～322是在新的SGSN支持组播业务时才执行的，如果支持的话，原来的SGSN是不执行以下步骤323～324的。

323-324.同背景技术描述中重定位流程的步骤221-222；

325-326.同背景技术描述中重定位流程的步骤225-226。

即：如果GGSN从新SGSN收到新的或更新的附加的组播业务追踪信息，GGSN发送一个激活追踪消息给BM-SC。重定位流程完成以后，后续需要完成一个路由更新过程。不支持组播业务的SGSN在路由区域更新接受消息中不指示组播业务特性支持。另一方面，如果SGSN支持组播业务，到UE的路由区域更新接受消息指示网络支持组播业务。

Claims

1、一种在组播业务中建立用户上下文和承载上下文的方法，包括以下步骤：

2、如权利要求2所述的方法，其特征在于：

所述步骤(a)中，在重定位完成过程中，是在完成了新的SGSN和缺省GGSN之间完成PDP上下文响应消息的更新后，新的SGSN再向所述特殊GGSN发送更新组播业务用户上下文请求消息。

3、如权利要求1所述的方法，其特征在于：

所述步骤(a)中，源SRNC发起SRNS重定位后，在重定位准备阶段，旧的SGSN发送前转重定位请求消息给新SGSN，如果MS加入了组播业务，该消息中带有组播业务用户上下文。

4、如权利要求1所述的方法，其特征在于：

所述步骤(d)之后还包括步骤：如果GGSN从新SGSN收到新的或更新的附加的组播业务追踪信息，GGSN发送一个激活追踪消息给BM-SC。

5、如权利要求1所述的方法，其特征在于：

所述步骤(c)中，新的SGSN为用户上下文创建一个组播业务承载上下文时，是将其置为″待命″状态。

6、如权利要求1所述的方法，其特征在于：

所述步骤(b)中，特殊GGSN向SGSN返回更新组播业务用户上下文响应消息中指示了更新成功或失败的信息；所述步骤(c)中，新的SGSN据此判断出所述组播业务用户上下文的更新是否成功。