CN101159919A - 一种简化消息发送处理的方法 - Google Patents

Abstract

本发明公开了一种简化消息发送处理的方法，UE通过底层向网络侧发送消息，该方法包括以下步骤：a.根据底层的消息发送指示判断消息是否发送成功，如果消息发送成功，则启动定时器，否则，结束当前处理过程；b.判断定时器超时之前是否收到网络侧响应，如果收到，则停止定时器；如果定时器超时未收到响应，则结束当前处理流程。采用该方法能有效避免不必要的操作，减少用户终端的资源消耗。

Description

一种简化消息发送处理的方法

技术领域

本发明涉及消息发送技术，尤指一种多媒体广播/组播服务(MBMS)系统中用户终端(UE)侧简化底层消息发送处理的方法。

背景技术

组播和广播是一种从一个数据源向多个目标传送数据的技术。在传统移动通信网络中，小区组播业务或广播业务(CBS，Cell Broadcast Service)允许低比特率数据通过小区共享广播信道向所有用户发送，此种业务属于消息类业务。

现在，人们对移动通信的需求已不再满足于电话和消息业务，随着因特网(Internet)的迅猛发展，大量移动多媒体业务涌现出来。其中一些移动多媒体业务要求多个用户能同时接收相同数据，例如视频点播、电视广播、视频会议、网上教育、互动游戏等。这些移动多媒体业务与一般的数据业务相比，具有数据量大、持续时间长、时延敏感等特点。目前的网际协议(IP)组播和广播技术只适用于有线IP通信网络，不适用于移动通信网络，因为移动通信网络具有特定的网络结构、功能实体和无线接口，这些都与有线通信IP网络不同。

为了有效地利用移动通信网络资源，第三代移动通信全球标准化组织(3GPP)提出了移动通信网络的MBMS，从而在移动通信网络中提供一个数据源向多个用户发送数据的点到多点业务，实现网络资源共享，提高网络资源的利用率，尤其是空口接口资源。3GPP提出的MBMS不仅能实现纯文本低速率的消息类组播和广播，而且还能实现高速多媒体业务的组播和广播，这无疑顺应了未来移动数据发展的趋势。

图1为支持广播/组播业务的无线网络结构示意图，如图1所示，现有3GPP中，支持广播/组播业务的无线网络结构为广播/组播业务服务器(BM-SC)101，BM-SC 101通过Gmb接口或Gi接口与TPF关口GPRS支持节点(GGSN，Gateway GPRS Support Node)102相连，一个BM-SC 101可与多个TPF GGSN102相连；TPF GGSN 102通过Gn/Gp接口与服务GPRS支持节点(SGSN，ServingGPRS Support Node)103相连，一个GGSN 102可与多个SGSN 103相连；SGSN103可通过Iu接口与通用移动通信系统(UMTS)陆地无线接入网(UTRAN)104相连，然后UTRAN 104通过Uu接口与UE 106相连，SGSN 103也可通过Iu/Gb接口与全球移动通信系统(GSM)增强无线接入网(GERAN) 105相连，然后GERAN 105通过Um接口与UE 107相连。其中，GGSN和SGSN属于无线网络中核心网(CN)内的节点。

从图1给出的网络结构可以看出，为了支持MBMS业务，在第三代移动通信系统中增加了移动网功能实体--广播组播业务中心，即BM-SC，所述BM-SC为内容提供者的入口，用于授权和在移动网中发起MBMS承载业务，并按照预定时间计划传送MBMS内容。此外，在UE、UTRAN、GERAN、SGSN、GGSN等功能实体上增加了与MBMS相关的功能。

MBMS包括组播模式和广播模式，其中组播模式需要用户签约相应的组播组，进行业务激活，并产生相应的计费信息。由于组播模式和广播模式在业务需求上存在不同，导致各自的业务流程也不同，如图2和图3所示，图2为MSMS组播模式的业务流程示意图，图3为MSMS广播模式的业务流程示意图。

如图2所示，MBMS组播业务涉及的处理过程包括：签约(Subscription)、服务宣告(Service announcement)、用户加入(Joining)、会话开始(Session Start)、MBMS通知(MBMS notfication)、数据传送(Data transfer)、会话结束(SessionStop)和用户退出(Leaving)。其中，签约过程用来让用户预先订阅所需的MBMS服务；服务宣告过程用于由BM-SC宣告当前能提供的服务；用户加入过程即MBMS组播业务激活过程，UE在加入过程中，通知网络自身愿意成为当前组播组的成员，接收对应业务的组播数据，该加入过程会在网络和加入组播组的UE中创建记录UE信息的MBMS UE上下文；会话开始过程中，BM-SC准备好数据传输，通知网络建立相应核心网和接入网的承载资源；MBMS通知过程用于通知UE MBMS组播会话即将开始；在数据传送过程中，BM-SC通过会话开始过程中建立的承载资源将数据传输给UE，MBMS业务在UTRAN和UE间传输时有两种模式：点对多点(PTM)模式和点对点(PTP)模式，PTM模式通过MTCH逻辑信道发送相同的数据，所有加入组播业务或对广播业务感兴趣的UE都可以接收，PTP模式通过DTCH逻辑信道发送数据，只有相应的一个UE可以收到；会话结束过程用于将会话开始过程建立的承载资源释放；用户退出过程使组内的订户离开组播组，即用户不再接收组播数据，该过程会将相应MBMS UE上下文删除。

如图3所示，MBMS广播业务涉及的处理过程与MBMS组播业务类似，只是在会话开始之前，不需要执行签约过程和用户加入过程，并且，在会话结束之后，不需要执行用户退出过程。

在组播模式业务和广播模式业务的数据传送阶段，MBMS业务在UTRAN和UE间传输信息的方式有两种模式：点到多点(PTM)模式和点到点(PTP)模式。其中，PTM模式通过MBMS点到多点业务信道(MTCH)发送相同的数据，所有加入组播业务或对广播业务感兴趣的UE都可以接收；PTP模式通过专用业务信道(DTCH)发送数据，只有相应的一个UE可以接收到。

在MBMS PTM传输模式中，相关的无线控制信息包括业务信息、接入信息、无线承载信息、频率层收敛(FLC)信息等，都由无线资源控制(RRC)层通过逻辑信道如MBMS点到多点控制信道(MCCH)发送。MCCH的协议栈结构如图4所示，MCCH的协议单元由上至下依次为：RRC层、无线链路控制层(RLC)、介质访问控制层(MAC)、物理层(PHY)。

在MBMS系统中，为了决定每个给定MBMS业务最优的传输模式，引入了MBMS计数过程，即：UTRAN使用计数过程来估计一个小区内对某个MBMS业务感兴趣的UE的个数，所述计数过程根据UE所处状态的不同而不同。

在目前的体系中，根据RRC连接是否建立，将UE分为空闲(Idle)模式和RRC连接(RRC Connected)模式两种。其中，未与UTRAN设备建立RRC连接的UE处于Idle模式，该模式下的UE只能通过非接入层(NAS)的标识如IMSI来区分；已与UTRAN设备建立RRC连接的UE处于RRC Connected模式，该模式下的UE分配了无线网络临时标识(RNTI)作为该UE在公共传输信道上的标识。

对于处于RRC Connected模式的UE，又根据RRC连接的层次和UE能使用的传输信道的类型将UE划分为不同状态，其中，CELL_PCH状态、CELL_FACH状态和CELL_DCH状态的UE在小区的层次上可以区分，URA_PCH状态的UE在UTRAN登记区(URA)层次上可以区分。CELL_DCH状态的UE被分配了专用的物理信道，可使用专用传输信道和共享信道以及它们的组合；CELL_FACH状态的UE在下行要连续的监控一个公共的传输信道(FACH)，上行分配缺省的公共信道(RACH)；CELL_PCH和URA_PCH状态的UE采用不连续接收(DRX)的方式通过相关的PICH信道监控一个寻呼信道(PCH)，这两种状态下没有任何上行活动。

通常，MBMS计数过程由无线网络控制器(RNC)发起，当一个MBMS业务会话开始需要建立无线承载且RNC认为需要时，RNC下发通知消息，并通过接入信息发送概率因子，收到通知消息的Idle模式下的UE读取接入信息，如果通过了概率因子检测，则发起RRC连接建立过程来响应计数；收到通知消息的URA_PCH状态和CELL_PCH状态下的UE读取接入信息，如果通过了概率因子检测，则发起小区更新过程来响应计数；收到通知消息的CELL_FACH状态下的UE，则通过其它的计数响应消息来响应计数。这里，进行概率因子检测是为了避免不同UE在接入过程中发生碰撞，使UE的接入尽量离散化，具体做法是：随机产生一个0～1之间的随机数，比较所产生的随机数与设定的概率因子，如果小于，则通过概率因子检测，否则不通过概率因子检测。

在Idle模式UE的计数过程中，UE通过发送RRC连接请求消息RRCCONNECTION REQUEST来发起RRC连接建立过程，当RRC CONNECTIONREQUEST消息用于MBMS计数时，在UE侧RRC的发送过程如下：

当RRC CONNECTION REQUEST消息的内容设置好后，UE在上行公共控制信道(CCCH)上发送设置好的RRC CONNECTION REQUEST消息，并设置状态变量V300的值为1；RRC CONNECTION REQUEST消息经由UE侧协议栈的RLC层、MAC层发出，MAC层在消息发出后会产生一个指示，指示消息发送成功或失败，同时启动一定时器T318，并设置计数器N300的值为0。这里，V300、N300和T318分别为标准协议规定的状态变量、计数器和定时器的变量名。

在定时器T318超时前，如果UE收到UTRAN侧的响应消息，则说明UE的RRC连接建立过程成功，定时器T318停止；否则，等待网络侧响应消息直到定时器超时。当定时器T318超时时，如果状态变量V300的值大于计数器N300的值，则认为UE的RRC连接建立过程失败，UE进入Idle模式；并且，UE执行协议规定的从RRC Connected模式进入到Idle模式后的一系列动作，然后结束整个处理过程；否则，在上行CCCH上发送新的RRC CONNECTIONREQUEST消息，并使状态变量V300的值递增。

从上述处理过程可以看出，现有技术方案存在以下问题：目前，无论MAC层发送RRC CONNECTION REQUEST消息成功还是失败，UE都会启动定时器T318，但实际上，如果MAC层指示RRC CONNECTION REQUEST消息发送失败，是没有必要再启动定时器T318，此时应认为计数过程已经结束。

发明内容

有鉴于此，本发明的主要目的在于提供一种简化消息发送处理的方法，能有效避免不必要的操作，减少用户终端的资源消耗。

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

一种简化消息发送处理的方法，UE通过底层向网络侧发送消息，该方法包括以下步骤：

a.根据底层的消息发送指示判断消息是否发送成功，如果消息发送成功，则启动定时器，否则，结束当前处理过程；

b.判断定时器超时之前是否收到网络侧响应，如果收到，则停止定时器；如果定时器超时未收到响应，则结束当前处理流程。

基于上述方案，步骤a之前，该方法进一步包括：设置计数器初始值，并配置计数器门限值；步骤a中在结束当前处理流程之前，进一步包括：判断当前计数器值是否小于等于计数器门限值，如果是，则启动定时器，否则，结束当前处理流程；步骤b中在结束当前处理流程之前，进一步包括：判断当前计数器值是否小于等于计数器门限值，如果是，则重新向网络侧发送消息，且修改当前计数器值，返回步骤a；否则，结束当前处理流程。

其中，所述计数器初始值设置为1；所配置的计数器门限值为0。

上述方案中，所述配置计数器门限值为：网络侧配置计数器的门限值，并通过标准消息发送给UE。所配置的计数器门限值为当前计数器值的最大值，则所述修改当前计数器值为将当前计数器值递增；或者，所配置的计数器门限值为当前计数器值的最小值，则所述修改当前计数器值为将当前计数器值递减。

步骤a之前，该方法还可以进一步包括：设置计数器初始值为1；步骤a之前或在步骤a中启动定时器的同时，进一步包括：设置计数器门限值为0；步骤b中在结束当前处理流程之前，进一步包括：判断并确定当前计数器值大于计数器门限值。

上述方案中，在所述结束当前处理流程之前，该方法进一步包括：UE进入空闲模式，并执行从连接模式到空闲模式的所有操作。所述消息为RRC消息、或为计数响应消息；所述底层为MAC层。其中，所述RRC消息为RRC连接请求消息、或为小区更新消息。

本发明所提供的简化消息发送处理的方法，由于UE根据MAC层的消息发送成功指示和消息发送失败指示对后续操作分别进行不同的处理，使得在消息发送失败后不再启动定时器，避免了不必要的定时器操作，减少了用户终端资源和功率的消耗，降低了UE的成本。对于只发送一次消息的情况，本发明还省去了对计数器和状态变量的设置和判断，简化了操作步骤，降低了复杂度。

附图说明

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

图2为MSMS组播模式的业务流程示意图；

图3为MSMS广播模式的业务流程示意图；

图4为MCCH的协议栈结构图；

图5为本发明方法一实施例的实现流程图；

图6为本发明方法另一实施例的实现流程图；

图7为本发明方法又一实施例的实现流程图。

具体实施方式

本发明的核心思想是：根据底层对消息发送成功或失败的指示，确定是否启动定时器。这里，所述消息是指能够告知RNC当前用户终端可以接收特定MBMS业务的消息，比如：RRC消息、或其它计数响应消息，其中，RRC消息可以是RRC CONNECTION REQUEST消息、或小区更新消息CELL UPDATE等；所述底层是指MAC层。以下仅以发送RRC CONNECTION REQUEST消息，且由MAC层产生消息发送成功或失败指示为例。

在实际应用中，RRC CONNECTION REQUEST消息可能发送一次或多次，相应的，在消息发送次数不同的情况下，对计数器和状态变量的处理也不同。下面通过不同的实施例具体说明本发明中RRC CONNECTION REQUEST消息发送的处理过程。

实施例一：

本实施例中，RRC CONNECTION REQUEST消息只发送一次，并且，RRCCONNECTION REQUEST消息发送过程中对计数器和状态变量的处理按现有标准协议的规定进行。

如图5所示，本实施例中RRC CONNECTION REQUEST消息发送的处理过程包括以下步骤：

步骤501：RRC CONNECTION REQUEST消息的内容设置好后，UE在上行CCCH信道上发送设置好的RRC CONNECTION REQUEST消息，并设置状态变量V300的值为1；

步骤502～503：判断MAC层的消息发送指示为消息发送成功还是发送失败，如果指示消息发送成功，则启动定时器T318，并设置计数器N300的值为0；如果指示消息发送失败，执行步骤508；

在实际应用中，计数器N300的值可以在启动定时器的同时设置，也可以在步骤502之前设置。

步骤504～505：判断在定时器T318超时前UE是否收到UTRAN侧的响应消息，如果收到，则停止定时器T318，认为UE的RRC连接建立过程成功，结束当前的处理流程；如果定时器T318超时未收到响应，则执行步骤506；

步骤506～507：判断状态变量V300的值是否大于计数器N300的值，如果是，则执行步骤508；否则，在上行CCCH信道上发送新的RRC CONNECTIONREQUEST消息，修改状态变量V300的值，返回步骤502。

这里，计数器N300的值相当于状态变量V300的门限值。由于本实施例仅考虑发送一次RRC CONNECTION REQUEST消息的情况，所以在计数器N300值和状态变量V300值的设置上，就考虑到使状态变量V300大于计数器N300，以避免再次发送RRC CONNECTION REQUEST消息的情况发生。

步骤508：UE的RRC连接建立过程失败，UE进入Idle模式，并执行协议规定的从RRC Connected模式进入到Idle模式后的一系列动作，然后，结束当前的处理流程。

实施例二：

本实施例中，RRC CONNECTION REQUEST消息只发送一次，并且，由于RRC CONNECTION REQUEST消息仅发送一次，所以不考虑对计数器和状态变量的处理，包括对计数器和状态变量的设置和比较判断。

如图6所示，本实施例中RRC CONNECTION REQUEST消息发送的处理过程包括以下步骤：

步骤601：RRC CONNECTION REQUEST消息的内容设置好后，UE在上行CCCH信道上发送设置好的RRC CONNECTION REQUEST消息；

步骤602～603：判断MAC层的消息发送指示为消息发送成功还是发送失败，如果指示消息发送成功，则启动定时器T318；如果指示消息发送失败，执行步骤606；

步骤604～605：判断在定时器T318超时前UE是否收到UTRAN侧的响应消息，如果收到，则停止定时器T318，认为UE的RRC连接建立过程成功，结束当前的处理流程；如果定时器T318超时未收到响应，则执行步骤606；

步骤606：UE的RRC连接建立过程失败，UE进入Idle模式，并执行协议规定的从RRC Connected模式进入到Idle模式后的一系列动作，然后，结束当前的处理流程。

实施例三：

本实施例中，RRC CONNECTION REQUEST消息发送多次。那么，如图7所示，本实施例中RRC CONNECTION REQUEST消息发送的处理过程包括以下步骤：

步骤701：RRC CONNECTION REQUEST消息的内容设置好后，UE在上行CCCH信道上发送设置好的RRC CONNECTION REQUEST消息，并设置状态变量V300的值为1；同时，UE配置计数器N300的值。这里，计数器N300的初始化值是由网络侧配置的，并由网络侧通过一条标准消息发送给UE，UE根据所收到消息中携带的参数配置计数器的初始值，具体处理过程为标准规定的已有流程，在此不再赘述。

步骤702～704：判断MAC层的消息发送指示为消息发送成功还是发送失败，如果指示消息发送成功，则启动定时器T318；如果指示消息发送失败，则判断状态变量V300的值是否小于等于计数器N300的值，如果小于等于，则启动定时器T318；如果大于，则执行步骤709。

步骤705～706：判断在定时器T318超时前UE是否收到UTRAN侧的响应消息，如果收到，则停止定时器T318，认为UE的RRC连接建立过程成功，结束当前的处理流程；如果定时器T318超时未收到响应，则执行步骤707。

步骤707～708：判断状态变量V300的值是否小于等于计数器N300的值，如果是，则UE在上行CCCH信道上发送新的RRC CONNECTION REQUEST消息，并修改状态变量V300的值，返回步骤702；否则执行步骤709。

这里，计数器N300的值相当于状态变量V300的门限值，状态变量V300相当于消息发送次数的实际计数值。如果状态变量V300的值设置为1，计数器N300的值配置为0，则属于本实施例中的一种特例，这种情况下，相当于RRCCONNECTION REQUEST消息仅发送一次。

步骤708中，修改状态变量V300的值有两种实现方案：一种是，如果计数器N300的值为状态变量V300的最大值，则修改是将状态变量V300的值递增，比如每次加1；另一种是，如果计数器N300的值为状态变量V300的最小值，则修改是将状态变量V300的值递减，比如每次减1。本实施例中，是将状态变量V300的值递增。

步骤709：UE的RRC连接建立过程失败，UE进入Idle模式，并执行协议规定的从RRC Connected模式进入到Idle模式后的一系列动作，然后，结束当前的处理流程。

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

Claims (10)

1.一种简化消息发送处理的方法，其特征在于，UE通过底层向网络侧发送消息，该方法包括以下步骤：

a.根据底层的消息发送指示判断消息是否发送成功，如果消息发送成功，则启动定时器，否则，结束当前处理过程；

b.判断定时器超时之前是否收到网络侧响应，如果收到，则停止定时器；如果定时器超时未收到响应，则结束当前处理流程。

2.根据权利要求1所述的方法，其特征在于，步骤a之前，该方法进一步包括：设置计数器初始值，并配置计数器门限值；

步骤a中在结束当前处理流程之前，进一步包括：判断当前计数器值是否小于等于计数器门限值，如果是，则启动定时器，否则，结束当前处理流程；

步骤b中在结束当前处理流程之前，进一步包括：判断当前计数器值是否小于等于计数器门限值，如果是，则重新向网络侧发送消息，且修改当前计数器值，返回步骤a；否则，结束当前处理流程。

3.根据权利要求2所述的方法，其特征在于，所述计数器初始值设置为1；所配置的计数器门限值为0。

4.根据权利要求2所述的方法，其特征在于，所述配置计数器门限值为：网络侧配置计数器的门限值，并通过标准消息发送给UE。

5.根据权利要求2所述的方法，其特征在于，所配置的计数器门限值为当前计数器值的最大值，则所述修改当前计数器值为将当前计数器值递增；

或者，所配置的计数器门限值为当前计数器值的最小值，则所述修改当前计数器值为将当前计数器值递减。

6.根据权利要求1所述的方法，其特征在于，步骤a之前，该方法进一步包括：设置计数器初始值为1；

步骤a之前或在步骤a中启动定时器的同时，进一步包括：设置计数器门限值为0；

步骤b中在结束当前处理流程之前，进一步包括：判断并确定当前计数器值大于计数器门限值。

7.根据权利要求1至6任一项所述的方法，其特征在于，在所述结束当前处理流程之前，该方法进一步包括：UE进入空闲模式，并执行从连接模式到空闲模式的所有操作。

8.根据权利要求1至6任一项所述的方法，其特征在于，所述消息为RRC消息、或为计数响应消息；所述底层为MAC层。

9.根据权利要求8所述的方法，其特征在于，所述RRC消息为RRC连接请求消息、或为小区更新消息。

10.根据权利要求8所述的方法，其特征在于，在所述结束当前处理流程之前，该方法进一步包括：UE进入空闲模式，并执行从连接模式到空闲模式的所有操作。

Images