CN1549611A - Mbms业务上下文更新的方法 - Google Patents

Abstract

根据UE状态不同更新MBMS业务上下文的方法，如果SRNC决定在MBMS会话开始之前建立业务上下文，当用户设备状态转到URA_PCH时，SRNC向其他包含以该URA标识的小区所属的DRNC发送“MBMS附着”消息；其他接收到该消息的DRNC如果还没有建立业务上下文，就在此时建立，将用户设备标识，URA标识和业务标识都包含在上下文中；如果DRNC还没有向SGSN进行业务注册，就向SGSN发送“业务注册”消息；当MBMS业务开始时，SGSN会向所有注册的RNC发送“会话开始”消息；DRNC接收到“会话开始”后，就查看业务上下文中包含的小区标识和URA标识；DRNC统计每个小区中的UE数目，而对于处于URA的UE，DRNC要确保向URA包含的所有小区发送通知。本发明有效防止某些UE不能被寻呼，保证MBMS业务及时提供给所有的用户设备。

Description

MBMS业务上下文更新的方法

技术领域

本发明涉及第三带移动通信系统，特别涉及MBMS业务上下文更新的方法。

背景技术

MBMS是在第三代移动通信系统合作伙伴计划中正在为之制定相关标准以进行标准化的一项新业务。MBMS业务是一种单向的点到多点方式(即从单一数据源播发出多媒体数据经过网络传输被送到多个用户接收)的业务。这种业务的最大特点是它可以有效的利用无线资源和网络资源。MBMS业务主要用于无线通信网络系统中，如宽带码分多址通信系统，全球移动通信系统等。MBMS中业务数据的发送基本上要经过：数据源发送、中间网络传输、目的小区空中传输、用户接收这样几个过程。图1是一个能够提供MBMS业务的无线通信系统逻辑网络设备图，在该图中MBMS实际上利用了通用分组无线数据业务(以下简称GPRS)网络作为核心传输网络。如图12所示，广播及组播服务中心(以下简称BM-SC)是发送MBMS业务数据的数据源；网关GPRS支持节点(以下简称GGSN)用于GRPS网络与外部网络(如INTERNET网络)的连接；在MBMS业务中网关GPRS支持节点连接BM-SC并把MBMS数据发送到特定的服务GPRS支持节点(以下简称SGSN)；小区广播中心是小区广播的数据源，在MBMS中通过将小区广播中心与BM-SC互连，使小区广播中心可以提供MBMS业务宣告功能；SGSN用于对UE进行接入控制及移动管理同时把从GGSN来的MBMS数据发送到特定的无线单元控制器(以下简称RNC)中去；RNC用于控制一组基站并把多媒体数据传送到特定的基站中去；基站在RNC的控制下为某个小区的MBMS业务建立空中物理信道；用户终端设备(以下简称UE)是接收MBMS数据的终端设备。

图13中给出了MBMS业务从业务宣告、用户加入、业务通知、无线承载建立到最后用户离开的全部过程。

1301订阅建立起用户和服务提供商之间的联系，授权用户可以接收有关的MBMS服务。

1302业务宣告通知用户将要提供的MBMS业务。例如，系统要在下午7:00在北京市区转播一场足球赛。

1303加入表示用户加入一个组，即用户告诉网络他或她愿意接收这项组播业务。

1304 MBMS会话开始表示建立为MBMS数据传输建立网络资源。

1305 MBMS通知告知用户马上要进行的MBMS数据传输。

1306数据传输表示MBMS业务数据传输到用户的过程。

1307 MBMS会话结束表示当MBMS业务数据传输完成后，释放网络资源。

1308离开与1303加入相对应，表示用户要离开一个组，即不再想接收某个业务的数据。

为了支持MBMS业务，每个控制属于MBMS业务区域的小区的RNC会为每个业务维护一个业务上下文。每个CRNC的MBMS上下文都以业务标识作为索引。它以小区标识为第二索引，在其下面又包含一系列处于连接模式的用户设备标识。当CRNC决定承载类型，即该小区应该是点对点方式的承载还是点对多点方式的承载，就要依据各个小区中包含的UE的个数。

但是现在不同的UE可能处于不同的状态，在现有规范中处于连接模式的UE可能处于四个状态：小区公共信道模式(CELL_FACH)，小区专用信道模式(CELL_DCH)，小区寻呼信道模式(CELL_PCH)和UTRAN注册区寻呼信道模式(URA_PCH)。小区模式意味着UE在小区的级别上对RNC是可知的，UTRAN注册区模式意味着UE在UTRAN注册区的级别上对RNC是可知的。UTRAN注册区一般包括多个小区，而且这些小区可以分属于不同的RNC。URA与小区的关系如图7所示。CELL_FACH模式是说UE使用公共信道，在小区级别上对RNC是可见的。CELL_DCH模式是说UE使用专用信道，在小区级别上对RNC是可见的。CELL_PCH模式是说UE使用寻呼信道，在小区级别上对RNC是可见的。URA_PCH模式是说UE使用寻呼信道，在UTRAN注册区级别上对RNC是可见的。

在现有规范中，描述了当一个用户设备进入一个小区或者离开一个小区时的业务上下文更新的方式。图8描述的是当一个UE从SRNC控制下的小区移动到DRNC控制下的小区时，SRNC发送MBMS附着消息给DRNC，让DRNC在其相应的MBMS业务上下文中加入该用户的用户标识。在这条消息中，包含用户设备所在当前小区的小区标识和用户标识及业务标识。同样，图9描述的是SRNC发送MBMS离开消息给DRNC，让DRNC在其相应的业务上下文中删除该用户的用户标识。在这条消息中，包含旧小区的小区标识和用户标识及业务标识。SRNC如何知道用户设备的移动性，现有规范中是有描述的。对于CELL_FACH、CELL_PCH的用户，当用户设备进行小区重选择时，用户设备要向其SRNC发送小区更新消息，SRNC从而知道用户设备移动到另外的小区。对于CELL_DCH的用户设备，当用户设备报告其对临近小区的测量结果时，SRNC根据用户设备报告的信号质量决定是否为该用户设备在目的小区建立无线链路。而对于URA_PCH的用户设备，只有当其移动到其他的UTRAN注册区时，才向SRNC报告其目前所处的UTRAN注册区标识。SRNC只知道该用户设备所处的UTRAN注册区，而并不关心其所处的目的小区到底是哪一个。

该方法用在业务进行期间是比较有用的。CRNC可以只关心那些处于CELL_FACH、CELL_PCH和CELL_DCH的用户数目。只有利用这些用户统计出来的用户数目才比较准确，才能使CRNC准确决定是用点对点还是点对多点的承载模式。

当前的技术中存在两种建立业务上下文的方式，具体可从图10和图11中看出。

图10描述的是业务上下文的建立在MBMS会话开始之前。1101步骤中，UE加入MBMS业务，得到相应的业务标识等。如果有加入到MBMS组中的用户在会话开始之前进入PMM_CONNECTED状态，CN会通过1102“MBMS连接”消息将该用户设备加入的MBMS业务标识全部告知SRNC，如果SRNC还没有为这些或某些业务建立业务上下文，那么这时候SRNC就要为这些业务建立上下文。如果用户设备移动到其他的DRNC，SRNC会通过1103“MBMS附着请求”消息，将该用户加入的MBMS业务标识传递给DRNC。如果DRNC中还没有为这些或某些业务建立上下文，那么这时候DRNC就要为这些业务建立上下文。DRNC向SRNC发送1004“MBMS附着响应”，表示会给用户设备提供这种服务。按照这种方式，SRNC和DRNC中的上下文都是在会话开始之前建立的。当1005会话开始时，RNC会向某些区域发送1006“MBMS组通知”，激活UE以接收MBMS业务。那么DRNC中到底包不包含处于URA_PCH用户设备的用户标识呢？现有技术中并没有指明。如果DRNC中不包含这些用户设备的标识，那么当MBMS会话开始时，DRNC如何对这些用户设备进行组寻呼，是现有技术不能解决的问题。

图11描述的是业务上下文的建立是在MBMS会话开始之后。当SRNC接收到从SGSN传过来的1101“会话开始”时，其中或者包含已经一个加入该MBMS组的用户设备标识，或者包含所有的加入该MBMS组的用户设备标识，SRNC向DRNC发送1102“MBMS附着”消息，将用户设备一个一个的或者一批一批的加入到DRNC中的业务上下文中。该消息中包含用户设备标识和其所在的小区标识。如果DRNC那时还没有建立该业务的上下文，那么这时候DRNC就建立上下文，并将用户设备的标识包含其中。DRNC向SRNC发送1103“MBMS附着响应”，表示会给用户设备提供这种服务。1104RNC查看是否要向某些小区发送1105“MBMS组通知”。按照这种方式，对于处于URA_PCH的用户设备，由于SRNC不知道其所处的确切小区，因此不能将其加入到DRNC的业务上下文中，然而如果不加入，DRNC有可能就寻呼不到这些用户。如果加入，DRNC不能很准确的统计用户数目。这都是现有技术中不能解决的问题。针对以上两种不同的建立业务上下文的方案，要解决问题的方法也是不一样的。

发明内容

本发明的目的是提供一种MBMS业务上下文更新的方法，尤其对那些处于URA_PCH的用户设备，对如何有效的寻呼到这些用户设备，如何准确的统计用户数目提出了新的解决方案。

为实现上述目的，按照本发明的一方面，一种根据UE状态不同更新MBMS业务上下文的方法，包括步骤：

a)如果SRNC决定在MBMS会话开始之前建立业务上下文，当用户设备状态转到URA_PCH时，SRNC向其他包含以该URA标识的小区所属的DRNC发送“MBMS附着”消息；

b)其他接收到该消息的DRNC如果还没有建立业务上下文，就在此时建立，将用户设备标识，URA标识和业务标识都包含在上下文中；

c)如果DRNC还没有向SGSN进行业务注册，就向SGSN发送“业务注册”消息；

d)当MBMS业务开始时，SGSN会向所有注册的RNC发送“会话开始”消息；

e)DRNC接收到“会话开始”后，就查看业务上下文中包含的小区标识和URA标识；

f)DRNC统计每个小区中的UE数目，而对于处于URA的UE，DRNC要确保向URA包含的所有小区发送通知。

按照本发明的另一方面，一种根据UE状态不同更新MBMS业务上下文的方法，包括步骤：

a)如果SRNC决定在MBMS会话开始之后建立业务上下文，当SRNC收到从SGSN的“会话开始”消息后，SRNC要向UE所处的DRNC发送“MBMS附着请求”消息；

b)会话请求中可能包含“连接模式的UE列表”和“寻呼范围”；

c)如果UE处于CELL_FACH和CELL_PCH状态，该消息中携带“小区标识”、“用户标识”和“业务标识”。对于只在MBMS上下文包含用户设备标识，但不在DRNC中包含用户设备上下文的UE，DRNC可以认为其属于CELL_PCH状态，要向这些UE所在的小区发送“MBMS通知”；

d)如果UE处于CELL_DCH状态，该消息中要携带“小区标识”、“用户标识”和“业务标识”。如果该UE同时从多条无线连路上接收数据，则该小区标识是由SRNC为UE选择的接收MBMS业务的小区标识，它包含在与UE有无线连路的小区当中。具体选择方式由SRNC决定；

e)如果UE处于URA_PCH状态，该消息中要携带“UTRAN注册区标识”、“用户标识”和“业务标识”。DRNC收到这条消息后，要向以“UTRAN注册区标识”标识的小区发送“MBMS通知”；

f)如果UE处于URA_PCH状态，这条消息要发往所有包含以URA标识小区的RNC；

g)当RNC收到“MBMS附着请求”消息，如果它还没有为该业务建立上下文，那么就在此时建立，然后将接收到的“业务标识”、“小区标识”、“UTRAN注册区标识”和“用户标识”包含到该业务的上下文中；

i)RNC向UE发送“MBMS通知”。

按照本发明的另一方面，一种向用户设备发送MBMS通知的方法，包括步骤：

a)RNC只统计那些包含在小区下面的用户，而不统计那些处于“UTRAN注册区标识”下的用户设备；

b)如果那些小区用户数目没有超过RNC定义的点对点与点对多点转换的界限，在发送“MBMS通知”时要设置“RRC连接需要”，否则设置为“RRC连接不需要”；

c)DRNC根据需要决定是否向某些小区发送“MBMS通知”，并相应地设置“RRC连接需要”或者“RRC连接不需要”；

d)当处于URA_PCH状态的UE接收到“MBMS通知”，并且指示“RRC连接需要”，它要向SRNC发送“小区更新”，更新理由是“MBMS统计”；

e)SRNC接收到从URA_PCH用户设备发送的“小区更新”，就将UE状态设置为CELL_FACH或者其他以小区为粒度的状态，如CELL_PCH、CELL_DCH；

f)SRNC根据UE现在所处的小区位置，向控制该小区的RNC发送“MBMS附着请求”消息。该消息包含“用户设备标识”、“小区标识”和“业务标识”；

g)SRNC向其他UE所处的URA内涉及的所有RNC发送“MBMS分离请求”。该消息包含“用户设备标识”、“UTRAN注册区标识”和“业务标识”。

本发明给出了一种根据UE状态不同，更新业务上下文的解决方法，有效的防止某些UE不能被寻呼的可能，从而保证MBMS业务能及时提供给所有的用户设备。

附图说明

图1是UE从CELL_FACH转到CELL_PCH时对MBMS上下文的更新过程；

图2是UE从CELL_DCH转到CELL_PCH时对MBMS上下文的更新过程；

图3是UE从CELL_FACH转到URA_PCH时对MBMS上下文的更新过程；

图4是UE从CELL_DCH转到CELL_PCH时对MBMS上下文的更新过程；

图5是UE在UPA_PCH进行URA更新时对MBMS上下文的更新过程；

图6是对UE进行MBMS通知的过程；

图7是URA与小区的关系图；

图8是CRNC上下文更新—附着流程图；

图9是CRNC上下文更新—分离流程图；

图10是CRNC上下文更新流程一；

图11是CRNC上下文更新流程二；

图12是MBMS系统结构示意图；

图13是MBMS组播业务流程。

具体实施方式

SRNC根据用户设备的状态不同对业务上下文的更新不同。在已有方案一的基础上，当SRNC发现用户移动出当前小区时，要更新新旧小区对应的业务上下文。

当SRNC要改变UE的状态时，除非显式用“MBMS分离”更新DRNC的业务上下文，否则DRNC不能因为UE在DRNC中上下文的删除而将UE标识从MBMS上下文中删除。

当SRNC决定将用户状态改变成URA_PCH时，它要向所有包含在该URA的小区的所属DRNC发送“MBMS附着”消息，该消息中包含URA ID，将该用户设备包含在这些DRNC的业务上下文中。

当UE从一个URA更新到另外一个URA时，SRNC将该UE标识从旧的URA的小区的所属DRNC删除，并向新的URA包含的小区所属的DRNC发送“MBMS附着”消息，将UE标识添加到新的DRNC中去。

SRNC根据用户状态的不同，发送不同的消息到DRNC。在已有方案二的基础上，当SRNC要向DRNC发送“MBMS附着”消息时，要根据UE的状态的不同，该消息所包含的参数也不同。

当用户状态为CELL_FACH、CELL_PCH时，“MBMS附着”消息中应该包含“用户设备标识”和“用户所在小区的小区标识”。

当用户状态为CELL_DCH时，“MBMS附着”消息中应该包含“用户设备标识”和“SRNC选定小区的小区标识”。

当用户状态为URA_PCH时，“MBMS附着”消息中应该包含“用户设备标识”和“用户所在URA的URA标识”。

MBMS通知消息的发送与响应。当RNC要向UE发送响应时，它要根据查看UE的状态决定是否发送MBMS通知。

如果RNC收到从SGSN发送的“MBMS会话开始”，其中携带“寻呼区域”。那么在这些区域要发送MBMS通知。

如果RNC的MBMS业务上下文中有些UE标识没有相应的UE上下文，那么RNC认为这些UE在CELL_PCH状态，在这些UE所处的小区发送MBMS通知。

如果RNC的MBMS业务上下文中有些UE处于URA范围内，那么RNC应该向这些UE所在的URA包含的小区发送MBMS通知。

处于小区可见粒度下的UE接收到MBMS通知，不论RRC连接是否需要，都不需要有其他动作。

而对于处于URA_PCH状态的UE，如果所在小区需要RRC连接，那么就要发起“小区更新”，其中包含新的更新原因“MBMS统计”。

新的“MBMS附着请求”消息。该消息中要包含新的参数：“URA标识”或者“URA标识列表”。

新的“MBMS小区更新”消息。该消息中包含新的参数：更新原因为“MBMS统计”。

实施例

1)UE状态从CELL_FACH转到CELL_PCH时上下文更新的操作

图1给出了UE从CELL_FACH转到CELL_PCH时的过程。

当101SRNC决定将UE的状态从CELL_FACH转到CELL_PCH时，SRNC向UE发送102“无线承载重配置”或者“小区更新确认”等TS 25.331中描述的可以完成该功能的消息，让UE转换到CELL_PCH状态。当用户设备完成状态转换和相应的资源释放后，发送103“无线承载重配置完成”到SRNC，告知状态转换成功104，并且释放了相应无线资源。

SRNC接着要求DRNC释放到分配给该UE的无线资源。SRNC向DRNC发送105“公共传输信道资源释放请求”，DRNC删除该UE相对应的无线资源，释放UE在DRNC中的上下文。该消息中包含一个新增加的参数“MBMS指示”。该参数明确告诉DRNC，不要将MBMS业务上下文中该用户设备的标识删除掉，即明确指示要在MBMS上下文中保留该UE标识。

或者DRNC默认，如果没有接收到对于该UE的“MBMS分离”消息，就在MBMS业务上下文中保留该UE的标识。然后DRNC向SRNC发送106“公共传输信道资源释放响应”，告知SRNC该用户的无线资源已经释放。当107会话开始时，DRNC要向UE看是否需要发送MBMS通知。

2)UE状态从CELL_DCH转到CELL_PCH时的操作

图2给出了UE从CELL_DCH转到CELL_PCH时的过程。

当201SRNC决定将UE的状态从CELL_DCH转到CELL_PCH时，SRNC向UE发送202“无线承载重配置”或者“小区更新确认”等TS 25.331中描述的可以完成该功能的消息，让UE转换到CELL_PCH状态。当用户设备完成状态转换和相应的资源释放后，发送203“无线承载重配置完成”到SRNC，告知状态转换成功204，并且释放了相应无线资源。

SRNC接着要求DRNC释放到分配给该UE的无线资源。SRNC向DRNC发送205“无线链路删除请求”，DRNC删除该UE相对应的无线资源，释放UE在DRNC中的上下文。该消息中包含一个新增加的参数“MBMS指示”。该参数明确告诉DRNC，不要将MBMS业务上下文中该用户设备的标识删除掉，即明确指示要在MBMS上下文中保留该UE标识。

或者DRNC默认，如果没有接收到对于该UE的“MBMS分离”消息，就在MBMS业务上下文中保留该UE的标识。然后DRNC向SRNC发送206“无线链路删除响应”，告知SRNC该用户的无线链路已经删除。当207会话开始时，RNC查看是否要向UE发送MBMS通知。

3)UE状态从CELL_FACH转到URA_PCH时上下文更新的操作

图3给出了UE从CELL_FACH转到URA_PCH时的过程。

当301SRNC决定将UE的状态从CELL_FACH转到URA_PCH时，SRNC向UE发送302“无线承载重配置”或者“小区更新确认”等TS 25.331中描述的可以完成该功能的消息，让UE转换到UPA_PCH状态。当用户设备完成状态转换和相应的资源释放后，发送303“无线承载重配置完成”到SRNC，告知状态转换成功304，并且释放了相应无线资源。

SRNC接着要求DRNC释放到分配给该UE的无线资源。SRNC向DRNC发送305“公共传输信道资源释放请求”，DRNC删除该UE相对应的无线资源，释放UE在DRNC中的上下文。该消息中包含一个新增加的参数“MBMS指示”。该参数明确告诉DRNC，不要将MBMS业务上下文中该用户设备的标识删除掉，即明确指示要在MBMS上下文中保留该UE标识。

或者DRNC默认，如果没有接收到对于该UE的“MBMS分离”消息，就在MBMS业务上下文中保留该UE的标识。然后DRNC向SRNC发送306“公共传输资源释放响应”，告知SRNC该用户的无线资源已经释放。

如果UE当前所处的小区属于的URA包含多个RNC控制的小区，这一信息是在当前DRNC给SRNC发送“上行信令传输指示”时告诉SRNC的，那么SRNC要向所有的其他RNC发送307“MBMS附着”消息，该消息中包含“UE标识”和“URA标识”和“MBMS业务标识列表”。如果这些其他的DRNC还没有建立业务的上下文，那么就在这时候建立。并且将该“URA标识”和“UE标识”保存在这些业务的上下文中。向SRNC发送308“MBMS附着响应”。如果这些DRNC还没有向SGSN注册，那么DRNC向SGSN发送309“业务注册”消息给SGSN，SGSN可以在其业务上下文中将该RNC加入，以便当MBMS会话开始是，给这些RNC发送310“会话开始”消息。

4)UE状态从CELL_DCH转到URA_PCH时的操作

图4给出了UE从CELL_DCH转到URA_PCH时的过程。

当401SRNC决定将UE的状态从CELL_DCH转到URA_PCH时，SRNC向UE发送402“无线承载重配置”或者“小区更新确认”等TS 25.331中描述的可以完成该功能的消息，让UE转换到CELL_PCH状态。当用户设备完成状态转换和相应的资源释放后，发送403“无线承载重配置完成”到SRNC，告知状态转换成功404，并且释放了相应无线资源。

SRNC接着要求DRNC释放到分配给该UE的无线资源。SRNC向DRNC发送405“无线链路删除请求”，DRNC删除该UE相对应的无线资源，释放UE在DRNC中的上下文。该消息中包含一个新增加的参数“MBMS指示”。该参数明确告诉DRNC，不要将MBMS业务上下文中该用户设备的标识删除掉，即明确指示要在MBMS上下文中保留该UE标识。

或者DRNC默认，如果没有接收到对于该UE的“MBMS分离”消息，就在MBMS业务上下文中保留该UE的标识。

然后DRNC向SRNC发送406“无线链路删除响应”，告知SRNC该用户的无线链路已经删除。

如果UE当前所处的小区属于的URA包含多个RNC控制的小区，这一信息是在当前DRNC给SRNC发送“无线链路建立响应”或者“无线链路增加响应”时告诉SRNC的，那么SRNC要向所有的其他RNC发送407“MBMS附着”消息，该消息中包含“UE标识”和“URA标识”和“MBMS业务标识列表”。如果这些其他的DRNC还没有建立业务的上下文，那么就在这时候建立。并且将该“URA标识”和“UE标识”保存在这些业务的上下文中，向SRNC发送408“MBMS附着响应”。如果这些DRNC还没有向SGSN注册，那么DRNC向SGSN发送409“业务注册”消息给SGSN，SGSN可以在其业务上下文中将该RNC加入，以便当MBMS会话开始是，给这些RNC发送410“会话开始”消息。

5)UE在URA_PCH时进行URA更新

图5描述了在URA_PCH的用户设备进行URA更新时MBMS上下文更新的过程。当501处于URA_PCH状态的UE发现其移动到了另外的URA下时，UE要发起502“URA更新”消息，告知SRNC它现在的位置已经由一个旧的URA移动到了一个新的URA。当SRNC决定UE的状态仍然处于URA_PCH503时，这可能因为UE没有新的数据要传输，SRNC向所有包含以URA标识的小区所属的RNC发送506“MBMS附着”消息，其中包含用户设备标识和URA标识，及UE加入的业务标识列表。当这些DRNC收到该消息时，如果还没有相应业务的上下文，则在此时建立。然后将用户设备标识，及其所属的URA标识一起添加到业务上下文中，然后向SRNC发送508“业务注册”。SRNC向旧URA所涉及的DRNC发送504“MBMS分离请求”。当DRNC将UE标识从其MBMS业务上下文中删除后，返回505“MBMS分离响应”，通知SRNC结果。

6)会话开始时，向UE发送MBMS通知

图6描述了会话开始时向UE发送MBMS通知的过程。

RNC决定向哪个小区发送MBMS通知，要根据下面三种不同情况选择：

对于PMM_IDLE状态的UE，SGSN会通知RNC对这部分UE进行通知的范围，一般以“寻呼范围”为指示。这个“寻呼范围”一般包含在“会话开始”消息中。当RNC接收到该“寻呼范围”后，就将其映射成为小区列表。PMM_IDLE是SGSN标识UE的一个状态，与PMM_CONNECTED相对。

对于处于CELL_PCH的用户设备，RNC发现只在MBMS上下文中有其用户设备标识，而在RNC中没有保存UE的上下文。对这类UE，RNC要负责在该UE所处的小区对其进行MBMS通知。

对于处于URA_PCH的用户设备，RNC对所有在URA范围的UE在URA范围内进行MBMS通知。

RNC根据上下文中的记录，统计每个小区中包含的用户数目。统计过程中，只能统计处于小区范围内的UE数目。如果该小区属于被通知的区域，并且用户数目大于点对点与点对多点的转换门限，在所发送的602“MBMS组通知”中要包含“RRC连接不需要”指示。相反，如果用户数目小于点对点与点对多点的转换门限，在所发送的“MBMS组通知”中要包含“RRC连接需要”指示。如果该小区属于不必被通知的区域，那么RNC就根据用户数目来决定是建立点对点信道，还是点对多点信道。

7)UE接收到寻呼后的不同操作

根据图6：如果UE接收到寻呼，要根据UE的不同状态来进行操作。

处于CELL_PCH的状态的用户设备接收到602“MBMS组通知”，不需要做任何操作，只需要根据RNC指示进行承载建立。

处于URA_PCH的状态的用户设备接收到602“MBMS组通知”，并且该通知指示“RRC连接需要”，UE需要向RNC发送603“小区更新”消息，更新原因设置为“MBMS统计”。当SRNC接收到该消息后，发现更新原因为“MBMS统计”，SRNC要将UE状态转换成为CELL_FACH。这样可以保证UE在小区范围内对RNC是可见的。便于RNC准确统计用户数目。SRNC要向旧URA设计的RNC发送606“MBMS分离请求”，而向UE现在所在小区的DRNC发送604“MBMS附着请求”。DRNC分别以607“MBMS分离响应”或605“MBMS附着响应”作为确定回答。

处于URA_PCH的状态的用户设备接收到602“MBMS组通知”，并且该通知指示“RRC连接需要”，UE不需要向RNC发送“小区更新”消息，只需要根据RNC其他指示进行承载建立。

Claims (6)

1、一种根据UE状态不同更新MBMS业务上下文的方法，包括步骤：

a)如果SRNC决定在MBMS会话开始之前建立业务上下文，当用户设备状态转到URA_PCH时，SRNC向其他包含以该URA标识的小区所属的DRNC发送“MBMS附着”消息；

b)其他接收到该消息的DRNC如果还没有建立业务上下文，就在此时建立，将用户设备标识，URA标识和业务标识都包含在上下文中；

c)如果DRNC还没有向SGSN进行业务注册，就向SGSN发送“业务注册”消息；

d)当MBMS业务开始时，SGSN会向所有注册的RNC发送“会话开始”消息；

e)DRNC接收到“会话开始”后，就查看业务上下文中包含的小区标识和URA标识；

f)DRNC统计每个小区中的UE数目，而对于处于URA的UE，DRNC要确保向URA包含的所有小区发送通知。

2.根据权利要求1所述的方法，其特征在于：“MBMS附着”消息中包含“URA标识列表”，和“每个URA下的用户设备标识列表”。

3.一种根据UE状态不同更新MBMS业务上下文的方法，包括步骤：

a)如果SRNC决定在MBMS会话开始之后建立业务上下文，当SRNC收到从SGSN的“会话开始”消息后，SRNC要向UE所处的DRNC发送“MBMS附着请求”消息；

b)会话请求中可能包含“连接模式的UE列表”和“寻呼范围”；

c)如果UE处于CELL_FACH和CELL_PCH状态，该消息中携带“小区标识”、“用户标识”和“业务标识”。对于只在MBMS上下文包含用户设备标识，但不在DRNC中包含用户设备上下文的UE，DRNC可以认为其属于CELL_PCH状态，要向这些UE所在的小区发送“MBMS通知”；

d)如果UE处于CELL_DCH状态，该消息中要携带“小区标识”、“用户标识”和“业务标识”。如果该UE同时从多条无线连路上接收数据，则该小区标识是由SRNC为UE选择的接收MBMS业务的小区标识，它包含在与UE有无线连路的小区当中。具体选择方式由SRNC决定；

e)如果UE处于URA_PCH状态，该消息中要携带“UTRAN注册区标识”、“用户标识”和“业务标识”。DRNC收到这条消息后，要向以“UTRAN注册区标识”标识的小区发送“MBMS通知”；

f)如果UE处于URA_PCH状态，这条消息要发往所有包含以URA标识小区的RNC；

g)当RNC收到“MBMS附着请求”消息，如果它还没有为该业务建立上下文，那么就在此时建立，然后将接收到的“业务标识”、

“小区标识”、“UTRAN注册区标识”和“用户标识”包含到

该业务的上下文中；

h)RNC向UE发送“MBMS通知”。

4.根据权利要求3所述的方法，其特征在于：“MBMS附着”消息中包含“URA标识”，和“用户设备标识”。

5.一种向用户设备发送MBMS通知的方法，包括步骤：

a)RNC只统计那些包含在小区下面的用户，而不统计那些处于“UTRAN注册区标识”下的用户设备；

b)如果那些小区用户数目没有超过RNC定义的点对点与点对多点转换的界限，在发送“MBMS通知”时要设置“RRC连接需要”，否则设置为“RRC连接不需要”；

c)DRNC根据需要决定是否向某些小区发送“MBMS通知”，并相应地设置“RRC连接需要”或者“RRC连接不需要”；

d)当处于URA_PCH状态的UE接收到“MBMS通知”，并且指示“RRC连接需要”，它要向SRNC发送“小区更新”，更新理由是“MBMS统计”；

e)SRNC接收到从URA_PCH用户设备发送的“小区更新”，就将UE状态设置为CELL_FACH或者其他以小区为粒度的状态，如CELL_PCH、CELL_DCH；

f)SRNC根据UE现在所处的小区位置，向控制该小区的RNC发送“MBMS附着请求”消息。该消息包含“用户设备标识”、“小区标识”和“业务标识”；

g)SRNC向其他UE所处的URA内涉及的所有RNC发送“MBMS分离请求”。该消息包含“用户设备标识”、“UTRAN注册区标识”和“业务标识”。

6.根据权利要求5所述的方法，其特征在于：小区更新消息里包含新的更新原因“MBMS统计”。

Images