CN1476259A - 多媒体广播和组播业务寻呼的方法 - Google Patents

Abstract

本发明提出了移动通信系统中多媒体广播与组播业务的寻呼方法。在该方法中把寻呼过程和无线资源建立过程合并起来并尽量减少上行响应。本发明扩展了现有PCHIubFP帧结构，在PCH IubFP帧中加入多媒体广播和组播业务指示位，PCH IubFP帧包括寻呼指示和寻呼消息，寻呼消息中承载了多媒体广播和组播业务的业务信息，在寻呼指示信道PICH帧结构中未用的12个比特中加入了对多媒体广播和组播业务标识或多媒体广播和组播业务寻呼指示。无线网络控制器RNC把寻呼指示信息和寻呼消息传送到基站(NodeB)以便在空中接口上发送。

Description

多媒体广播和组播业务寻呼的方法

技术领域

本发明涉及一种移动通信系统中对用户的寻呼方法，特别是涉及在移动通信系统中用于多媒体广播和组播业务中对用户的寻呼采用点对多点的组寻呼的方法。

背景技术(1)现有寻呼的基本操作过程

现有通信系统中的寻呼是一种点对点的基于用户的寻呼，其基本操作过程如图3所示：

移动终端注册到网络后，会被分配到一个寻呼组。对于一个寻呼组，有一个寻呼指示(以下简称PI)204，当属于一个寻呼组的终端被寻呼时，对应于这个寻呼组的寻呼指示PI会周期性的出现在寻呼指示信道(以下简称PICH)202上。

当终端在PICH上检测到对它的寻呼指示后，会从辅助公用控制物理信道(简称SCCPCH)201开始接收具体的寻呼消息。也就是说，PICH上只承载了寻呼指示信息，而寻呼消息是由SCCPCH来承载的。对于寻呼消息的解释是用户终端设备UE协议层上层的功能。

为了省电，终端在设计上采用了非连续接收(简称DRX)的方式。也就是说，终端在空闲模式下处于睡眠模式，在这种模式下终端有比较小的功率消耗。当终端检测到有它的寻呼指示后，才会唤醒去接收具体的寻呼消息。

终端对寻呼指示的监测也是周期性的，周期的大小由网络来决定。这个周期越大，终端从睡眠中醒来的机会越小，终端电池的待机时间也就越长，但这样做的代价是降低了终端对网络寻呼的反应速度。(2)现有的寻呼指示信道帧结构

PICH是一个用来承载寻呼指示的纯物理信道。3GPP规范TS25.211 v4.2.0对其进行了详细描述。图4描述了它的帧结构。

一个PICH无线帧长为10ms，由300个比特组成，其中288个比特用来承载寻呼指示，其余的12个比特被留作将来使用而不发送。一个寻呼指示(PI)由几个比特组成，根据一个PI的长度不同，一个PICH帧可以承载18，36，72或144个PI。Np用来表示一个PICH帧中PI的个数。

PI在帧中的位置是依据用户终端的国际移动用户标识号(简称IMSI)计算出的，计算方法如下：

PI＝DRX Index mod Np，这里，DRX Index＝IMSI div 8192，mod表示取模运算，div表示除法取整运算。

为了保证可靠传输，现有技术采用了以下基于SFN的滑动机制：

在上面的公式中，q表示寻呼指示在帧中的实际位置，SFN是系统帧号，随着时间的推移，SFN会发生变化。随着SFN的变化，寻呼指示的位置q会滑动。 表示取整运算，mod表示取模运算。

用P_q表示在q位置上的寻呼指示的取值，如果Pq＝1，表示寻呼指示有效，UE应该唤醒以读取寻呼消息，如果Pq＝0表示寻呼指示无效，UE不需要唤醒读取寻呼消息。寻呼指示P_q和PICH位的映射关系如下表(表1)所示：

         表1：寻呼指示P_q与PICH位的映射关系

               每帧寻呼指示的个数(Np)

                        Pq＝1

                        Pq＝0

                       Np＝18

        {b16q，...，b16q+15}＝{-1，-1，...，-

        {b16q，...，b16q+15}＝{+1，+1，...，+1}

                       Np＝36

         {b8q，...，b8q+7}＝{-1，-1，...，-1}

         {b8q，...，b8q+7}＝{+1，+1，...，+1}

                       NR＝72

         {b4q，...，b4q+3}＝{-1，-1，...，-1}

         {b4q，...，b4q+3}＝{+1，+1，...，+1}

                       Np＝144

                {b2q，b2q+1}＝{-1，-1}

                {b2q，b2q+1}＝{+1，+1}由表1可以看出，当Pq＝1时，组成该寻呼指示的比特都要设为‘-1’；当Pq＝0时，组成该寻呼指示的比特都要设为‘+1’。(3)现有的PCH IubFP帧结构

由于寻呼是由网络发起的，寻呼信息必须通过合适的方式传送到空中接口上以便于终端接收。图5是现有的寻呼信道基站和无线网络控制器接口帧协议(简称PCH IubFP)的帧结构。PCH IubFP用于在基站(简称NodeB)和无线网络控制器(简称RNC)之间传递寻呼信息。3GPP规范TS25.435v4.2.0对现有的PCH IubFP帧结构进行了详细描述。

PCH IubFP帧包括寻呼指示信息和寻呼消息。为了寻呼一个用户设备，会用到两个连续的PCH IubFP帧。第一个帧包含了寻呼指示信息，第二个帧包含了寻呼消息。对于图5中几个组成部分的说明如下：

·寻呼指示(PI)

描述：指示该帧中是否有寻呼指示位图。

  取值范围：{0＝没有寻呼指示位图，1＝有寻呼指示位图}。

  域长度：1比特

·寻呼指示位图示(PI-bitmap)

  描述：寻呼指示PI₀...PI_N-1的位图，第一个字节的第7个比特包含PI₀，第6个比特包含PI₁，第二个字节的第7个比特包含PI₈，以此类推。

取值范围：{18，36，72，144个寻呼指示}。

域长度：3，5，9，或1 8个字节(4)现有的寻呼和无线承载建立流程

3GPP规范TS 23.846 v1.1.0描述了MBMS业务寻呼和无线承载建立过程。图6是寻呼和无线承载建立的信令流程。下面是对流程中各个步骤的详细说明。

601 BM-SC通过GGSN发送数据给SGSN。

602 SGSN发送“MBMS通知”给UTRAN表明某个MBMS业务将要开始。

603 UTRAN在MBMS服务区域内给UE发送“MBMS通知”。

604 UTRAN发送“MBMS业务请求”消息给SGSN请求业务。

605 和606在UTRAN和SGSN之间建立无线接入承载(简称RAB)。

607 已经激活了MBMS业务的UE收到“MBMS通知”后发送“MBMS无线请求”消息给网络。

608 UTRAN在空中接口上建立起无线承载(简称RB)，并发送“MBMS无线分配”消息给UE。

609 当所有的无线资源建立成功后，就可以进行数据传输了。

610 数据传输结束后，要释放所用的网络资源。根据图6，603寻呼过程和608无线承载建立过程是独立进行的。(5)现有的寻呼消息

在3GPP规范TS25.331 v4.2.0中，现有的寻呼消息称为“Paging Type1”，当需要寻呼UE时，无线网络控制器(简称RNC)把“Paging Type 1”消息通过基站(简称Node B)发送到UE。

这条消息包括以下几方面的信息：

     -寻呼记录列表(Paging record list)，列出了消息所寻呼的UE的标识。

     -广播控制信道更新信息(BCCH modification info)，对系统广播信息的更新指示。

一条寻呼消息可以包含对多个UE的寻呼记录，称为“Paging record”。寻呼记录(Paging Record)包括以下几个参数：

     -寻呼原因(Paging cause)，表示发起寻呼的原因，目前规范中列举了以下几方面的原因：

                   ^*对话呼叫(Terminating Conversational Call)

                   ^*流呼叫(Terminating Streaming Call)

                   ^*交互式呼叫(Terminating Interactive Call)

                   ^*背景呼叫(Terminating Background Call)

                   ^*高优先级信令(Terminating High PrioritySignalling)

                   ^*低优先级信令(Terminating Low PrioritySignalling)

                   ^*未知原因(Terminating-cause unknown)

     -用户设备标识(UE Identity)，指明UE的标识，可以是国际移动用户标识(IMSI)，临时移动用户标识(TMSI)，分组临时移动用户标识(P-TMSI)，用户无线网络临时标识(U-RNTI)等等。UE通过检查用户设备标识来确认对自己的寻呼。

发明内容

由于现有移动通信系统中的寻呼技术是基于用户的点对点的寻呼，必须对每个此业务的用户一一寻呼，这样做既浪费无线资源又导致寻呼效率极低。所以针对现有移动通信系统的寻呼技术的上述问题，本发明提供了在现有寻呼机制的基础上提供一种在移动通信系统中用于多媒体广播和组播业务的对用户点对多点的组寻呼方法。通过点对多点的寻呼，利用共享的无线资源，使此业务的所有用户都可以同时被寻呼到，从而有效地利用样无线资源并提高寻呼的效率。

另外，由于现有的寻呼过程和无线资源建立过程是分开进行的。而在多媒体广播和组播业务MBMS业务中，由于接收同一种业务的用户是非常集中的，在一次寻呼和业务建立过程中，会有非常多的用户同时要求接入网络，从而造成终端到网络的上行链路的拥塞，为了减少拥塞的发生，本发提出了把寻呼过程和无线资源建立过程合并起来并尽量减少上行响应的寻呼方法。

此外，为了在现有寻呼机制的基础上提供对多媒体广播和组播业务MBMS业务的寻呼方式，本发明还设计出了能够承载多媒体广播和组播MBMS业务参数寻呼消息；在寻呼指示信道PICH帧结构中未用的12个比特中加入了对多媒体广播和组播业务MBMS业务标识号；以及扩展了现有PCH IubFP帧结构，把寻呼信息(包括寻呼指示信息和寻呼消息)从无线控制器RNC传送到基站(NodeB)以便在空中接口上发送。

根据本发明的在移动通信系统中提供MBMS对用户设备(UE)进行寻呼的方法，包括如下步骤：

(a)广播和组播业务中心(BM-SC)通过网关通用分组无线业务支持节点(GGSN)向服务通用分组无线业务支持节点(SGSN)发送数据；

(b)服务通用分组无线业务支持节点(SGSN)接收到网关通用分组无线业务支持节点(GGSN)发送的数据后，向无线网络控制器(RNC)发送多媒体广播和组播业务(MBMS)通知；

(c)无线网络控制器(RNC))收到来自服务通用分组无线业务支持节点(SGSN)的所述通知后，根据所述通知的内容组织寻呼信道无线网络控制器与基站接口帧协议(PCHIubFP)的帧，在所述帧协议(PCHIubFP)的帧中加入多媒体广播和组播业务MBMS指示位(MI)，所述帧协议(PCHIubFP)的帧中包含多媒体广播和组播业务(MBMS)的寻呼指示和寻呼消息，所述寻呼消息中承载多媒体广播和组播业务(MBMS)的业务信息；

(d)无线网络控制器(RNC)把所述帧协议(PCHIubFP)的帧发送到基站(Node B)；

(e)基站(Node B)接收所述帧协议(PCHIubFP)的帧之后，首先检查收到的所述帧协议(PCHIubFP)的帧中所述指示位(MI)，如果所述指示位(MI)为0，则表示所述帧协议(PCHIubFP)的帧是传统的寻呼，如果所述指示位(MI)为1，则表示所述帧协议(PCHIubFP)的帧中包含了多媒体广播和组播业务(MBMS)的业务信息；

(f)基站(Node B)读取所述的寻呼指示以构建寻呼指示信道(PICH)，利用寻呼指示信道(PICH)未用的最后12个比特承载临时多媒体广播和组播业务组标识(MBMS TMGI)或多媒体广播和组播业务(MBMS)寻呼指示；

(g)基站(Node B)读取多媒体广播和组播业务(MBMS)寻呼消息以构建承载多媒体广播和组播业务(MBMS)寻呼消息的辅助公用控制物理信道(SCCPCH)，

(h)基站(Node B)发送承载有寻呼指示的寻呼指示信道(PICH)帧和承载有寻呼消息的辅助公用控制物理信道(SCCPCH)帧供用户设备(UE)读取；

(i)用户设备(UE)首先检查寻呼指示信道(PICH)，如果用户设备(UE)已经激活了多媒体广播和组播业务(MBMS)的业务，则读取寻呼指示信道(PICH)的最后12个比特，来确定当前所寻呼的业务是否是它所需要的；如果业务匹配，用户设备(UE)接下来读辅助公用控制物理信道(SCCPCH)以获得多媒体广播和组播业务(MBMS)寻呼消息；

(j)如果用户设备(UE)接收到的所述寻呼消息中包含无线承载参数，则用户设备(UE)在寻呼过程中建立无线承载，否则用户设备(UE)在寻呼过程中不建立无线承载。

另外，在上述步骤(j)之后，用户设备(UE)根据系统的要求决定是否要向网络发送寻呼响应消息。

此外，在上述步骤(c)中所述寻呼指示包括寻呼指示位图(MBMS PIbitmap)，并分别将多媒体广播和组播业务(MBMS)指示(MI)和所述寻呼指示位图(MBMS PI bitmap)放置在所述帧协议(PCHIubFP)的帧结构中的未用部分和可扩展部分。或者，在上述步骤(c)中所述寻呼指示包括多媒体广播和组播业务(MBMS)组标识掩码(TMGI mask)，并分别将多媒体广播和组播业务(MBMS)指示(MI)和所述多媒体广播和组播业务(MBMS)组标识掩码(TMGI mask)放置在所述帧协议(PCHIubFP)的帧结构中的未用部分和可扩展部分。或者，在上所述步骤(c)中的所述多媒体广播和组播业务(MBMS)指示(MI)放置在所述帧协议(PCHIubFP)的帧结构中的未用部分。

对于PICH帧结构，可以采用现有技术留作将来使用的最后的12个比特用来承载MBMS业务标识TMGI。对这12个比特的利用方式有三种。第一种方式是，可以把所述寻呼指示信道(PICH)未用的12个比特分成Nm个组，组的个数Nm可以固定的，也可以是变化的，Nm的取值可以为1，2，3，4，6，12；每一个组存放一个多媒体广播和组播业务MBMS寻呼指示(MPI)，对于每一个所述临时多媒体广播和组播业务(MBMS)组标识(TMGI)，都会获得一个多媒体广播和组播业务(MBMS)寻呼指示(MPI)，其计算方法是，MPI＝(TMGI div 8192)mod Nm，其中，MPI为用所述每个组表示的多媒体广播和组播业务(MBMS)寻呼指示，TMGI表示临时多媒体广播和组播业务(MBMS)组标识，div表示除法取整运算，mod表示取模运算。第二种方式是，把寻呼指示信道(PICH)未用的12个比特分成m个多媒体广播和组播业务(MBMS)寻呼指示组(MPG)，组的个数m可以固定的，也可以是变化的，m的取值可以为1，2，3，4，6，12，所述每一个组存放一个多媒体广播和组播业务(MBMS)的组标识掩码(TMGI mask)，组标识掩码计算方法是，TMGI mask＝TMGImod(2^12/m)，组标识掩码在12个比特中的组位置(MPG_i)的计算方法是，i＝TMGI mod m，其中TMGI表示临时多媒体广播和组播业务(MBMS)组标识，TMGI mask组标识掩码，mod表示取模运算，i表示组位置。第三种方式是，在寻呼指示信道(PICH)未用的12个比特中取几个比特作为多媒体广播和组播业务(MBMS)寻呼指示。

对于MBMS业务信息的寻呼消息，本发明给出了两种MBMS寻呼消息方案。

第一种是对现有的“Paging Type 1”消息进行改造，在现有寻呼消息“寻呼类型1(Paging Type 1)”中的“寻呼原因(Paging Cause)”定义中增加一个元素“终端多媒体广播和组播业务呼叫(Terminating MBMSCall”，在现有寻呼消息“寻呼类型1(Paging Type 1)”中的“用户设备识别(UE Identity)”定义中增加一个元素“多媒体广播和组播业务的组标识(MBMS TMGI)，呼消息“寻呼类型1(Paging Type 1)”中可以包含多媒体广播和组播业务服务识别(MBMS Service ID)。寻呼消息“寻呼类型1(Paging Type 1)”中还可以包含响应标志(ResponseIndicator)、激活时间(Activation time)。另一种是设计一个新的寻呼消息，称为“多媒体广播和组播业务寻呼(MBMS Paging)”。该消息可以包含以下几方面的信息：

 -多媒体广播和组播业务标识(MBMS TMGI)；

 -多媒体广播和组播业务服务标识(MBMS Service ID)；

     响应指示(Response Indicator)；

     激活时间(Activation time)。

另外，在以上的两种寻呼中还可以包含无线承载参数，无线承载参数可以包括：无线承载信息(RB info)，传输信道信息(TrCH info)，物理信道信息(PhyCH info)，码信息(Code info)，传输格式集(TFS)，传输格式合并集(TFCS)，激活时间(Activation time)。

附图说明

下面结合附图对本发明进行详细描述，以便更好地理解本发明的目的、特征和优点。图1是MBMS系统结构示意图；图2是MBMS组播业务流程图；图3是现有的寻呼过程示意图；图4是现有的PICH帧结构图；图5是现有的PCH IubFP帧结构图；图6是现有的寻呼过程和无线承载建立过程的图；图7是第一方案的MBMS PICH帧结构(Nm＝3)图；图8是第二方案的MBMS PICH帧结构(m＝3)图；图9是MBMS PICH位图举例示意图；图10是第一方案的PCH IubFP帧结构图；图11是第二方案的PCH IubFP帧结构图；图12是MBMS业务流程图；图13是MBMS寻呼信令流程图；图14是UTRAN寻呼处理流程图；图15是基站对PCH IubFP的处理的示意图。

具体实施方式

多媒体广播和组播业务(简称MBMS)是由第三代伙伴计划(简称3GPP)提出并正在进行标准化的一项新业务。MBMS业务是一种单向的点对多点的业务，这种业务的最大特点是它可以有效的利用无线资源和网络资源。

MBMS业务有两种模式：组播(multicast)和广播(broadcast)。组播与广播的区别在于，在接收组播业务前，需要向服务提供商提前订阅，加入相关的组播组(multicast group)，接收组播业务需要付费。系统在发送组播或广播业务之前，要进行寻呼，以通知用户马上要进行的业务。

本发明用于在多媒体广播和组播业务MBMS组播和广播业务中对用户终端设备(简称UE)的寻呼。

下面参考图1描述多媒体广播和组播业务MBMS系统结构MBMS网络结构以通用分组无线业务(以下简称GPRS)核心网为基础，并增加了新的网络单元。广播和组播业务中心(以下简称BM-SC)101是MBMS系统的业务控制中心。网关GPRS支持节点(以下简称GGSN)102和服务GPRS支持节点(以下简称SGSN)103构成了MBMS业务的传输网络，为数据的传输提供路由。归属位置寄存器(以下简称HLR)106保存与用户有关的数据，可以提供用户鉴权等服务。UMTS陆地无线接入网(以下简称UTRAN)104在空中接口上为MBMS服务提供无线资源。Uu107表示终端和接入网之间的无线接口。用户终端设备(以下简称UE)105是用来接收数据的终端设备。MBMS业务所用的无线资源不是用户专用的，而是由此业务的所有用户共享的。

下面参考图2描述MBMS组播业务流程。

首先，在步骤S000“订阅”，建立起用户和服务提供商之间的联系，授权用户可以接收有关的MBMS服务。然后，在步骤S001“业务广告”，服务提供商通知用户将要提供的业务。例如，系统要在下午7:00在北京市区转播一场足球赛。如果用户愿意接收服务提供商要提供的业务，则在步骤S002“加入”，用户表示加入一个组，即用户告诉网络他或她愿意这项组播业务。在步骤S003“MBMS组播模式承载建立”，为MBMS数据传输建立网络资源。然后，在步骤S004“MBMS通知”，通知用户马上要进行的MBMS数据传输。在步骤S005“数据传输”，表示MBMS业务数据传输到用户的过程。在步骤006“MBMS组播模式承载释放”，表示当MBMS业务数据传输完成后，释放网络资源。在步骤S007“离开”与S002“加入”相对应，表示用户要离开一个组，即不再想接收某个业务的数据。

本发明重点研究了004“MBMS通知”过程，在本发明中，“MBMS通知”被称为“多媒体广播和组播业务寻呼(MBMS paging)”。

下面结合附图12，描述本发明的用于在多媒体广播和组播业务(MBMS)中对用户终端设备UE进行寻呼的流程。

首先，BM-SC901通过GGSN902向SGSN903发送数据。

然后，SGSN903接收到GGSN902发送的数据后，向无线网络控制器904(简称RNC)发送MBMS通知(MBMS Notification)，告知有关的MBMS业务信息。

接着，RNC904收到来自SGSN的MBMS通知后，根据通知的内容组织寻呼信道无线网络控制器与基站接口帧协议(简称PCHIubFP)的帧，在PCHIubFP的帧中加入MBMS指示位(MI)，PCHIubFP的帧中包含MBMS的寻呼指示和寻呼消息，寻呼消息中承载多媒体广播和组播业务(MBMS)的业务信息，在组织PCHIubFP的帧之后，RNC904把PCHIubFP的帧发送到基站905(Node B)。

基站接收PCHIubFP的帧之后，首先检查收到的PCHIubFP的帧中指示位(简称MI)，如果MI为0，则表示PCHIubFP的帧是传统的寻呼，如果所述MI为1，则表示PCHIubFP的帧中包含了多媒体广播和组播业务(MBMS)的业务信息；

基站905读取寻呼指示以构建寻呼指示信道(简称PICH)，利用PICH未用的最后12个比特承载临时MBMS组标识(简称TMGI)或MBMS寻呼指示；基站905(Node B)读取多媒体广播和组播业务(MBMS)寻呼消息以构建承载MBMS寻呼消息的辅助公用控制物理信道(SCCPCH)。然后，基站905(Node B)发送承载有寻呼指示的PICH帧和承载有寻呼消息的辅助公用控制物理信道(SCCPCH)帧供用户设备(UE)907读取。

用户设备(UE)907首先检查PICH，如果用户设备(UE)已经激活了多媒体广播和组播业务(MBMS)的业务，则读取PICH的最后12个比特，来确定当前所寻呼的业务是否是它所需要的；如果业务匹配，用户设备UE907接下来读SCCPCH以获得MBMS寻呼消息。

如果RNC在进行业务寻呼之前能够确定无线承载参数，那么就可以在MBMS寻呼消息中加入无线承载参数，从而实现寻呼过程和无线承载建立过程的合并。

根据用户数目的多少，无线承载参数有两种，点到多点的无线承载和点到点的无线承载，如果用户多则采用点到多点的无线承载，如果用户少，则采用点到点的无线承载。RNC确定无线承载参数的方式有多种，例如可以采用默认的点到多点的无线承载，或者RNC从其它渠道获得用户数目的信息。

UE接收到寻呼消息后，就可以根据消息中的无线承载参数建立相应的无线资源，而不需要在后续过程再进行无线承载建立过程，从而简化了信令流程。

另外，无线承载参数可以包括：无线承载信息(RB info)，传输信道信息(TrCH info)，物理信道信息(PhyCH info)，码信息(Code info)，传输格式集(TFS)，传输格式合并集(TFCS)，激活时间(Activation time)。

此外，UE根据寻呼消息的要求决定是否发送响应消息给基站控制器RNC；如果寻呼消息要求发送响应消息给RNC，则用户终端设备UE发送寻呼响应给RNC；如果寻呼消息不要求发送响应消息给RNC，则用户终端设备UE不发送寻呼响应给RNC。

如果BM-SC要求RNC发回寻呼响应，则RNC通过SGSN和GGSN发送寻呼响应给广播和组播业务中心BM-SC，否则基站控制器RNC不通过SGSN和GGSN发送寻呼响应给广播和组播业务中心BM-SC。

PCH IubFP帧结构

为了支持多媒体广播和组播业务MBMS寻呼，本发明提出了三种PCHIubFP帧结构方案，分别对应于下面将要描述的寻呼指示信道PICH帧结构的三种方案。

方案1)

下面参见图10说明方案1的PCH IubFP帧结构，它对应于下面将要描述的寻呼指示信道PICH帧结构的方案1。在帧结构的未用部分，加入了与多媒体广播和组播业务MBMS业务相关的信息。

在该方案帧结构中，加入了MBMS指示位MI和MBMS寻呼指示位图。MI指示在负载(payload)中是否有MBMS寻呼指示位图。考虑到系统的后向兼容性，MBMS寻呼指示位图被放在帧结构中负载的扩展部分。

下面是MI和多媒体广播和组播业务MBMS寻呼指示位图的详细说明。●MBMS指示(MI)描述：它指示在负载中是否有MBMS寻呼指示位图。取值范围：{0＝在负载中没有MBMS寻呼指示位图，1＝在负载中有MBMS寻呼指示位图}。域长度：1比特。●MBMS寻呼指示位图(MBMS PI-bitmap)描述：MBMS寻呼指示位图PI₀...PI_Nm-1。第一个字节的第7个比特代表MBMS PI₀，第6个比特代表MBMS PI₁，...，第0个比特代表MBMS PI₇。第二个字节的第7个比特代表MBMS PI₈，...第3个比特代表MBMS PI₁₁。这里的MBMS PI与后面描述的寻呼指示信道PICH帧结构第一种方案中的MPI相对应。取值范围：{1，2，3，4，6或12个MBMS寻呼指示}域长度：2个字节方案2)

下面参见图11说明方案2的PCH IubFP帧结构，它对应寻呼指示信道PICH帧结构的方案2。该方案与方案1类似，但是对帧结构中各元素的定义和解释不相同。

在该方案PCH IubFP帧结构中，加入了MBMS指示位MI和MBMSTMGI掩码(或称为MBMS TMGI mask)。MI指示在负载(payload)中是否有MBM TMGI掩码。考虑到系统的后向兼容性，MBMS TMGI掩码被放在帧结构中负载的扩展部分。

下面是MI和MBMS TMGI掩码的详细说明。●MBMS指示(MI)描述：它指示在帧结构负载中是否有MBMS TMGI掩码。取值范围：{0＝没有MBMS TMGI掩码，1＝有MBMS TMGI掩码}。域长度：1比特。

TMGI掩码的计算在下面将要描述的PICH帧结构中进行了描述，与PICH中未用的12个比特相对应，它所占用的长度为12个比特。

方案3)该方案与下面将要描述的PICH方案3相对应，只在PCH IubFP帧结构未用部分中加入MBMS指示(MI)，而不需要在负载中增加寻呼指示信息。在这种情况下，基站(NodeB))在收到无线网络控制器(简称RNC)发来的PCH IubFP帧后，只需读取MI，根据MI的值，设定PICH帧结构第三种方案中MBMS寻呼指示位。用户终端设备(简称UE)根据PICH帧中的MBMS寻呼指示决定是否要读MBMS寻呼消息以确认具体的MBMS业务信息，如TMGI等。

寻呼指示信道PICH帧结构

对于PICH帧结构，本发明采用现有技术留作将来使用的最后的12个比特5来承载MBMS业务标识TMGI。对这12个比特的利用方式有三种。下面详细说明。

方案1)

下面结合图7描述了方案1的寻呼指示信道PICH帧结构。

可以把所述寻呼指示信道(PICH)未用的这12个比特可以分成几个组，每个组可以用来表示一个多媒体广播和组播业务MBMS寻呼指示(简称MPI)。之所以把这12个比特分成几个组，是为了同时对多种多媒体广播和组播业务MBMS业务进行寻呼，提高寻呼的效率。

如果12个比特分成“Nm”组，则每个组有12/Nm个比特，其中Nm＝{1，2，3，4，6，12}。Nm的取值可以是固定的也可以是变化的。如果Nm的取值是可变的，在RNC进行寻呼之前，UE必需获得当前的Nm值。UE可以通过系统信息广播或者其它信令获得Nm的值。MBMS寻呼指示MPI的计算可以遵循以下方法：

MPI＝DRX Index mod Nm，其中DRX Index＝TMGI div 8192；

为了保证可靠传输，可以采用现有技术中的滑动机制：

在上面的公式中，q表示寻呼指示在帧中的实际位置，SFN是系统帧号，随着时间的推移，SFN会发生变化。随着SFN的变化，MBMS寻呼指示的位置q会不同。

表示取整运算，mod表示取模运算。

如果Nm＝1，则表示所有的12个比特为一组，那么这12个比特只是用做有没有MBMS寻呼的指示，UE收到该指示后，要接着检查寻呼消息的内容，以确认当前所寻呼的MBMS业务。

用P_q表示在q位置上的寻呼指示的取值，如果Pq＝1，表示寻呼指示有效，UE应该唤醒以读取寻呼消息，如果Pq＝0表示寻呼指示无效，UE不需要唤醒读取寻呼消息。MBMS寻呼指示在PICH上的位映射关系如下表(表2)所示：

      表2：MBMS寻呼指示P_q和PICH位的映射关系

       12个比特中MBMS寻呼指示的个数(Nm)

                    P_q＝1

                    P_q＝0

                    Nm＝1

           {b_288+12q，...，b_288+12q+11}

               ＝{-1，-1，...，-1}

           {b_288+12q，…，b_288+12q+11}

               ＝{+1，+1，...，+1}

                    Nm＝2

           {b_288+6q，...，b_288+6q+5}

              ＝{-1，-1，...，-1}

           {b_288+6q，...，b_288+6q+5}

              ＝{+1，+1，...，+1}

                    Nm＝3

            {b_288+4q，...，b_288+4q+3}

               ＝{-1，-1，...，-1}

            {b_288+4q，...，b_288+4q+3}

               ＝{+1，+1，...，+1}

                    Nm＝4

            {b_288+3q，...，b_288+3q+2}

                ＝{-1，-1，-1}

            {b_288+3q，...，b_288+3q+2}

               ＝{+1，+1，+1}

                    Nm＝6

         {b_288+2q，b_288+2q+1}＝{-1，-1}

         {b_288+2q，b_288+2q+1}＝{+1，+1}

                    Nm＝12

                {b_288+1q}＝{-1}

                {b_288+1q}＝{+1}

由表2可以看出，当Pq＝1时，组成该寻呼指示的比特都要设为‘-1’；当Pq＝0时，组成该寻呼指示的比特都要设为‘+1’。

方案2)

图8描述了方案2的PICH帧结构。在该方案中，12个比特被分成几个组，称为MBMS寻呼指示组(简称MPG)。每个MPG可以承载一个TMGI掩码。

如果12个比特分成“m”组，则每个组有12/m个比特，其中m＝{1，2，3，4，6，12}。m的取值可以是固定的也可以是变化的。如果m的取值是可变的，在RNC进行寻呼之前，UE必需获得当前的m值。UE可以通过系统信息广播或者其它信令获得m的值。

如果用“I”表示每个组的比特数，则I＝12/m。每个组的最大值n＝2^I-1。例如：如果m＝3，则I＝4，n＝2⁴-1＝15。

TMGI掩码的计算如下：

TMGI mask＝TMGI mod(n+1)；

TMGI所在的组为MPG_i，i＝TMGI mod m。mod为取模运算。

例如：如果TMGI＝59，m＝3，

        则TMGI mask＝59 mod 16＝11；

        59 mod 3＝2，此TMGI将会在MPG2。

根据这个例子，PICH的位图如图9所示。

方案3)

在PICH帧结构未用的12个比特中取出几个比特作为MBMS寻呼指示。激活了MBMS业务的UE读取PICH这几个比特后，如果发现这几个比特指示有MBMS寻呼，则继续读取寻呼消息以获得和确认MBMS业务标识(TMGI)和业务信息。多媒体广播和组播业务MBMS寻呼消息

为了支持基于业务的多媒体广播和组播业务MBMS组寻呼，需要提出能够承载多媒体广播和组播业务MBMS业务信息的寻呼消息。RNC首先把寻呼消息通过PCH IubFP发送到基站，然后基站通过SCCPCH把寻呼消息发送到用户设备。本发明给出了两种MBMS寻呼消息方案，一种是对现有的“Paging Type 1”消息进行改造，另一种是设计一个新的寻呼消息称为“MBMS Paging”。具体如下。方案1)

该方案对现有的“寻呼类型1(Paging Type 1)”进行扩充，在消息内容里增加了MBMS业务相关的信息。具体实施方案如下：

在消息中的寻呼原因(Paging Cause)里增加一个新的项，称为终端多媒体广播和组播业务呼叫(Terminating MBMS Call)，

在消息中的用户设备识别(UE Identity)里增加一个新的项“TMGI”，在这里TMGI并不是真正的UE的标识，而是MBMS业务的标识。

如果需要在寻呼消息中包括无线承载参数，例如，RB Info，TrCH info，PhyCH Info，Code Information，TFCS，TFCS，Activation time等，那么可以在消息中加入这些参数。UE根据这些参数可以建立相应的无线资源。

消息中还可以包含其它的与MBMS业务相关的信息。

已经激活了MBMS业务的UE，在收到寻呼消息后，可以检查消息中的TMGI以确认是否需要准备接收MBMS业务。

方案2)

该方案给出了一个新的MBMS寻呼消息。该消息可以包含以下几方面的信息：

        -临时多媒体广播和组播业务组标识(TMGI)；

        -多媒体广播和组播业务服务标识(MBMS Service ID)；

        -响应指示(Response Indicator)。

这个消息中包含了所寻呼MBMS业务的基本信息，例如：TMGI，Service ID等。消息中还可以包含其它的与MBMS业务相关的信息。

“响应指示(Response Indicator)”用来指示UE是否需要对此寻呼消息做出响应。如果RNC不需要UE对此寻呼做出响应在，可以减少上行信令的负担。

如果需要，消息中还可以包含无线承载参数，无线承载参数包含了承载MBMS业务的所需要的参数，例如：无线承载信息(RB Info)，传输信道信息(TrCH info)，物理信道信息(PhyCH Info)，码信息(CodeInformation)，传输格式集(TFS)，传输格式合并集(TFCS)，激活时间(Activation time)等。UE收到此寻呼后可以根据消息中的RB参数为MBMS业务建立相应的无线资源。MBMS寻呼信令流程

图13是MBMS寻呼的信令流程图，下面各个操作步骤详细说明。

701 BM-SC通过GGSN向SGSN发送数据。

702 SGSN发送“MBMS通知”通知UTRAN当前业务的TMGI和服务区域。

703 UTRAN和SGSN之间建立RAB。

704 UTRAN发送“MBMS寻呼”给UE，通知UE马上要进行的MBMS数据传输，还可能包含无线承载参数。如果包含无线承载参数，UE可以建立相关的无线资源，而不再需要另外的无线承载建立过程。如果消息中不包含无线承载参数，那么需要专门的无线承载建立过程来建立相关的无线资源。

705 如果UE在收到寻呼消息时在空闲模式，要进行无线资源控制(简称RRC)连接的建立过程。如果UE已经在RRC连接模式，此过程是不需要的。

706 UE发送寻呼响应给UTRAN。如果UTRAN对MBMS寻呼响应不做处理，根据UTRAN的要求，则此过程也可以省略，以减少上行信令。

707 UTRAN通过SGSN和GGSN发送寻呼响应给BM-SC，根据BM-SC的要求，在某些情况下，此消息也可以不发送。

下面结构图14描述UTRAN内对MBMS寻呼的处理流程。

当RNC从SGSN收到801“MBMS通知”，它会802分析将要到来的业务，并构造PCH IubFP帧，然后803发送到基站。

804 基站分析FP帧，并构造PICH和SCCPCH。一种方案，UE在每次醒来读PICH时检查PICH的最后12个比特，这种情况下，805PICH和807SCCPCH要重复一段时间，让所有的用户都能收到。另一种方案，UE从网络得到一个时钟，它在时钟到时才启动MBMS寻呼的接收。

806 UE检查PICH最后的12个比特后，如果所寻呼的业务是它所需要的，它会启动SCCPCH以接收相应的寻呼消息。UE分析寻呼消息后，如果是有效的，它会建立无线承载并发送寻呼响应给RNC。

下面结合图15描述了基站对PCH IubFP帧的处理流程。基站首先检查收到的PCH IubFP帧结构中的MI，如果MI＝0，则表示此PCH IubFP帧是传统的寻呼，与MBMS没有关系，可以进行相应的处理。如果MI＝1，则表示此帧的负载(payload)中包含MBMS PI位图或MBMS TMGImask，则在处理完毕普通的寻呼消息后，接着读取MBMS寻呼指示以构建PICH的最后12个比特，读取MBMS寻呼消息以构建SCCPCH。最后基站发送承载有寻呼指示和寻呼消息PICH帧和SCCPCH帧供用户终端读取。

发明的效果1.减少了终端的功率消耗，增加了终端设备的待机时间

本发明中，UE对MBMS寻呼的接收采用了非连续接收方式，可以减少终端的功率消耗。另外，本发明所提出的MBMS寻呼利用了现有非连续接收周期(在每个周期，UE要唤醒去读取PICH信道)，没有设计新的针对MBMS的非连续接收周期，因而没有增加UE的唤醒次数。2.非常高的寻呼效率

本发明中的MBMS寻呼是一种基于业务的点到多点的组寻呼，提高了寻呼效率和对无线资源的利用率，避免了寻呼信道的拥塞。3.后向兼容性

本发明充分利用了现有系统中的寻呼资源，对PICH帧结构，PCH IubFP帧结构以及寻呼消息进行了重新设计，对现有的寻呼没有任何影响，使系统具有后向兼容性。面列出了本发明中的引用的图纸。

Claims (17)

1、一种在移动通信系统中为提供多媒体广播和组播业务(MBMS)对用户终端设备(UE)进行寻呼的方法，该方法包括如下步骤：

(a)广播和组播业务中心(BM-SC)通过网关通用分组无线业务支持节点(GGSN)向服务通用分组无线业务支持节点(SGSN)发送数据；

(b)服务通用分组无线业务支持节点(SGSN)接收到网关通用分组无线业务支持节点(GGSN)发送的数据后，向无线网络控制器(RNC)发送多媒体广播和组播业务(MBMS)通知；

(c)无线网络控制器(RNC)收到来自服务通用分组无线业务支持节点(SGSN)的所述通知后，根据所述通知的内容组织寻呼信道无线网络控制器与基站接口帧协议(PCH IubFP)的帧，在所述帧协议(PCH IubFP)的帧中加入多媒体广播和组播业务(MBMS)指示位(MI)，所述帧协议(PCH IubFP)的帧中包含多媒体广播和组播业务(MBMS)的寻呼指示和寻呼消息，所述寻呼消息中承载多媒体广播和组播业务(MBMS)的业务信息；

(d)无线网络控制器(RNC)把所述帧协议(PCH IubFP)的帧发送到基站(Node B)；

(e)基站(Node B)接收所述帧协议(PCH IubFP)的帧之后，首先检查收到的所述帧协议(PCH IubFP)的帧中所述指示位(MI)，如果所述指示位(MI)为0，则表示所述帧协议(PCH IubFP)的帧是传统的寻呼，如果所述指示位(MI)为1，则表示所述帧协议(PCH IubFP)的帧中包含了多媒体广播和组播业务(MBMS)的业务信息；

(f)基站(Node B)读取所述的寻呼指示以构建寻呼指示信道(PICH)，利用寻呼指示信道(PICH)未用的最后12个比特承载临时多媒体广播和组播业务组标识(MBMS TMGI)或多媒体广播和组播业务(MBMS)寻呼指示；

(g)基站(Node B)读取多媒体广播和组播业务(MBMS)寻呼消息以构建承载多媒体广播和组播业务(MBMS)寻呼消息的辅助公用控制物理信道(SCCPCH)，

(h)基站(Node B)发送承载有寻呼指示的寻呼指示信道(PICH)帧和承载有寻呼消息的辅助公用控制物理信道(SCCPCH)帧供用户设备(UE)读取；

(i)用户设备(UE)首先检查寻呼指示信道(PICH)，如果用户设备(UE)已经激活了多媒体广播和组播业务(MBMS)的业务，则读取寻呼指示信道(PICH)的最后12个比特，来确定当前所寻呼的业务是否是它所需要的；如果业务匹配，用户设备(UE)接下来读辅助公用控制物理信道(SCCPCH)以获得多媒体广播和组播业务(MBMS)寻呼消息；

(j)如果用户设备(UE)接收到的所述寻呼消息中包含无线承载参数，则用户设备(UE)在寻呼过程中建立无线承载，否则用户设备(UE)在寻呼过程中不建立无线承载。

2、根据权利要求1所述的方法，其特征在于，在所述步骤(i)之后，用户设备(UE)根据系统的要求决定是否要向网络发送寻呼响应消息。

3、根据权利要求1所述的方法，其特征在于，在所述步骤(c)中所述寻呼指示包括寻呼指示位图(MBMS PI bitmap)，并分别将多媒体广播和组播业务(MBMS)指示(MI)和所述寻呼指示位图(MBMS PI bitmap)放置在所述帧协议(PCHIubFP)的帧结构中的未用部分和可扩展部分。

4、根据权利要求1所述的方法，其特征在于，在所述步骤(c)中所述寻呼指示包括多媒体广播和组播业务(MBMS)组标识掩码(TMGImask)，并分别将多媒体广播和组播业务(MBMS)指示(MI)和所述多媒体广播和组播业务(MBMS)组标识掩码(TMGI mask)放置在所述帧协议(PCHIubFP)的帧结构中的未用部分和可扩展部分。

5、根据权利要求1所述的方法，其特征在于，所述步骤(c)中的所述多媒体广播和组播业务(MBMS)指示(MI)放置在所述帧协议(PCHIubFP)的帧结构中的未用部分。

6、根据权利要求3所述的方法，其特征在于，把所述寻呼指示信道(PICH)未用的12个比特分成Nm个组，组的个数Nm可以固定的，也可以是变化的，Nm的取值可以为1，2，3，4，6，12；每一个组存放一个多媒体广播和组播业务MBMS寻呼指示(MPI)，对于每一个所述临时多媒体广播和组播业务(MBMS)组标识(TMGI)，都会获得一个多媒体广播和组播业务(MBMS)寻呼指示(MPI)，其计算方法是，MPI＝(TMGI div8192)mod Nm，其中，MPI为用所述每个组表示的多媒体广播和组播业务(MBMS)寻呼指示，TMGI表示临时多媒体广播和组播业务(MBMS)组标识，div表示除法取整运算，mod表示取模运算。

7、根据权利要求4所述的方法，其特征在于，把寻呼指示信道(PICH)未用的12个比特分成m个多媒体广播和组播业务(MBMS)寻呼指示组(MPG)，组的个数m可以固定的，也可以是变化的，m的取值可以为1，2，3，4，6，12，所述每一个组存放一个多媒体广播和组播业务(MBMS)的组标识掩码(TMGI mask)，组标识掩码计算方法是，TMGImask＝TMGI mod(2^12/m)，组标识掩码在12个比特中的组位置(MPG _i)的计算方法是，i＝TMGI mod m，其中TMGI表示临时多媒体广播和组播业务(MBMS)组标识，TMGI mask组标识掩码，mod表示取模运算，i表示组位置。

8、根据权利要求5所述的方法，其特征在于，在寻呼指示信道(PICH)未用的12个比特中取几个比特作为多媒体广播和组播业务(MBMS)寻呼指示。

9、根据权利要求1所述的方法，其特征在于，在现有寻呼消息“寻呼类型1(Paging Type 1)”中的“寻呼原因(Paging Cause)”定义中增加一个元素“终端多媒体广播和组播业务呼叫(Terminating MBMS Call)”，在现有寻呼消息“寻呼类型1(Paging Type 1)”中的“用户设备识别(UEIdentity)”定义中增加一个元素“多媒体广播和组播业务(MBMS)的组标识(TMGI)”。

10、根据权利要求9所述的方法，其特征在于，寻呼消息“寻呼类型1(Paging Type 1)”中可以包含多媒体广播和组播业务服务识别(MBMSService ID)。

11、根据权利要求9所述的方法，其特征在于，寻呼消息“寻呼类型1(Paging Type 1)”中可以包含响应标志(Response Indicator)。

12、根据权利要求9所述的方法，其特征在于，寻呼消息“寻呼类型1(Paging Type 1)”中可以包含激活时间(Activation time)。

13、根据权利要求1所述的方法，其特征在于，所述寻呼消息采用“多媒体广播和组播业务寻呼(MBMS Paging)”。

14、根据权利要求13所述的方法，其特征在于，所述“多媒体广播和组播业务寻呼(MBMS Paging)”消息中包含多媒体广播和组播业务标识(TMGI)和多媒体广播和组播业务服务识别(MBMS Service ID)。

15、根据权利要求13所述的方法，其特征在于，“多媒体广播和组播业务寻呼(MBMS Paging)”消息中可以包含响应标志(ResponseIndicator)。

16、根据权利要求13所述的方法，其特征在于，“多媒体广播和组播业务寻呼(MBMS Paging)”消息中可以包含激活时间(Activation time)。

17、根据权利要求1所述的方法，其特征在于，所述无线承载参数可以包括：无线承载信息(RB info)，传输信道信息(TrCH info)，物理信道信息(PhyCH info)，码信息(Code info)，传输格式集(TFS)，传输格式合并集(TFCS)，激活时间(Activation time)。

Images