CN108990151A - 寻呼合并方法、装置及网关和基站 - Google Patents

Abstract

本发明涉及一种寻呼合并方法、装置及网关和基站，从网关角度实施的寻呼合并方法，包括：将寻呼自定义消息发送给相应的基站；寻呼自定义消息用于指示基站通过空口、将解析寻呼自定义消息得到的寻呼消息传输给相应的UE；寻呼自定义消息为对低优先级的MME寻呼消息进行合并组建得到的。本申请通过寻呼合并的方式来缓解网元间的寻呼的压力，有效解决网关下挂多个基站场景下的多个寻呼消息高并发问题；减少信令开销，缓解了基站和网关的寻呼压力，同时对于用户来说业务分类并未影响用户体验，同时减小了基站和网关信令交互次数，提高了整个系统的可靠性和稳定性。

Description

寻呼合并方法、装置及网关和基站

技术领域

本申请涉及移动通信领域，特别是涉及一种寻呼合并方法、装置及网关和基站。

背景技术

HeNB(Home evolved Node B，家庭演进基站)是指在一个局部的区域里，一个办公室或者类似的小范围区域内，部署小的UTRA(Universal Terrestrial Radio Access)或E-UTRA(Evolved-Universal Terrestrial Radio Access)的小区，为用户提供类似无线局域网的局部无线接入服务。

HeNB源于最初为家庭场景设计，相对于传统的宏基站，特点小，低发射，智能化和组网灵活。进入LTE(Long Term Evolution，长期演进)时代以后，由于全球各国的LTE频段十分分散。跟进对50家已经公布频率规划的运营商统计，62％的LTE网络将部署2.1GHz或者更高频段，其中41％的网络在2.6G或者更高频段。受限于高频段覆盖劣势，而未来数据业务80％或者更多都发生在室内，仅仅依靠宏站时无法进行热点和室内覆盖，所以HeNB对于LTE网络建设至关重要。

在实现过程中，发明人发现传统技术中至少存在如下问题：随着智能手机和推送业务的增长，寻呼消息越来越多，对网络压力越来越大；而传统技术极易导致用户寻呼慢，网络侧以及空口资源紧张，或者寻呼不到等问题。

发明内容

基于此，有必要针对上述技术问题，提供一种能够缓解寻呼压力的寻呼合并方法、装置及网关和基站。

为了实现上述目的，一方面，本发明实施例提供了一种从网关角度实施的寻呼合并方法，包括：

将寻呼自定义消息发送给相应的基站；寻呼自定义消息用于指示基站通过空口、将解析寻呼自定义消息得到的寻呼消息传输给相应的UE；

寻呼自定义消息为对低优先级的MME寻呼消息进行合并组建得到的。

在其中一个实施例中，在将寻呼自定义消息发送给基站的步骤之前还包括步骤：

接收MME寻呼消息，并根据寻呼域与寻呼优先级，获取MME寻呼消息的优先级；

若MME寻呼消息的优先级为低优先级，则缓存低优先级的MME寻呼消息；

在缓存的时长满足预设缓存周期时，合并组建预设数量的低优先级的MME寻呼消息，得到寻呼自定义消息。

在其中一个实施例中，预设数量的取值范围为小于或等于256条。

在其中一个实施例中，还包括步骤：

若MME寻呼消息的优先级为高优先级，则将高优先级的MME寻呼消息传输给相应的基站；高优先级的MME寻呼消息用于指示基站寻呼相应的UE。

在其中一个实施例中，寻呼域包括CS域；MME寻呼消息为标准S1AP寻呼消息。

另一方面，本发明实施例还提供了一种从基站角度实施的寻呼合并方法，包括：

解析接收到的、网关发送的寻呼自定义消息；

通过空口，将解析寻呼自定义消息得到的寻呼消息传输给相应的UE。

在其中一个实施例中，还包括步骤：

根据接收到的、网关发送的高优先级的MME寻呼消息，寻呼相应的UE。

在其中一个实施例中，在解析接收到的、网关发送的寻呼自定义消息的步骤之前还包括步骤：

在接收到网关发送的消息时，根据消息ID标识对网关发送的消息进行识别，确认网关发送的消息为寻呼自定义消息或高优先级的MME寻呼消息。

一种从网关角度实施的寻呼合并装置，包括：

网关寻呼发送模块，用于将寻呼自定义消息发送给相应的基站；寻呼自定义消息用于指示基站通过空口、将解析寻呼自定义消息得到的寻呼消息传输给相应的UE；寻呼自定义消息为对低优先级的MME寻呼消息进行合并组建得到的。

一种从基站角度实施的寻呼合并装置，包括：

基站寻呼接收模块，用于解析接收到的、网关发送的寻呼自定义消息；

基站寻呼发送模块，用于通过空口，将解析寻呼自定义消息得到的寻呼消息传输给相应的UE。

另一方面，本发明实施例提供了一种网关，网关用于执行上述从网关角度实施的寻呼合并方法的步骤。

在其中一个实施例中，网关为HeNB-GW。

一方面，本发明实施例提供了一种基站，基站用于执行上述从基站角度实施的寻呼合并方法的步骤。

在其中一个实施例中，基站为HeNB。

一种寻呼合并系统，包括网关以及基站；还包括MME以及UE；MME通过网关连接各基站；基站连接对应的UE。

网关用于执行上述从网关角度实施的寻呼合并方法的步骤；

基站用于执行上述从基站角度实施的寻呼合并方法的步骤。

在其中一个实施例中，网关为HeNB-GW；基站为HeNB。

一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述任一项寻呼合并方法的步骤。

上述技术方案中的一个技术方案具有如下优点和有益效果：

将核心网下发的多条低优先级寻呼消息合并成寻呼自定义消息，并下发给相应的基站。基站收到寻呼自定义消息以后，进行解析然后根据空口寻呼定义条数下发空口；本申请通过寻呼合并的方式来缓解网元间的寻呼的压力，有效解决网关下挂多个基站场景下的多个寻呼消息高并发问题；减少信令开销，缓解了基站和网关的寻呼压力，同时对于用户来说业务分类并未影响用户体验(未影响低优先级用户的寻呼消息)，同时减小了基站和网关信令交互次数，提高了整个系统的可靠性和稳定性。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请个的其它特征、目的和优点将会变得更明显：

图1为一个实施例中寻呼合并方法的应用环境图；

图2为一个实施例中从网关角度实施的寻呼合并方法的第一示意性流程示意图；

图3为一个实施例中从网关角度实施的寻呼合并方法的第二示意性流程示意图；

图4为一个实施例中从基站角度实施的寻呼合并方法的第一示意性流程示意图；

图5为一个实施例中从网关角度实施的寻呼合并装置的结构框图；

图6为一个实施例中从基站角度实施的寻呼合并装置的结构框图；

图7为另一个实施例中寻呼合并装置的结构框图；

图8为一个实施例中寻呼合并系统的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

若果运营商在某一较集中的范围内部署大规模的HeNB，大量HeNB产生的大量SCTP(Stream Control Transmission Protocol，流控制传输协议)消息和UDP(User Datagramprotocol，用户数据报协议)/IP(Internet Protocol，网络互连协议)通道会对MME(Mobility Management Entity，网络节点)/S-GW(Serving GateWay，服务网关)性能负荷提出更高的要求，部署一个独立的HeNB-GW(小基站网关)来处理这些大量的消息和通道，将会减少HeNB数量的增加对MME/S-GW的影响。E-UTRAN框架需要部署一个HeNB-GW从而使HeNB和EPC(Evolved Packet Core，4G核心网络)之间的S1接口能够支持大量的HeNB。

对于LTE系统来说，寻呼消息的大幅度增长是由于智能手机快速休眠的模式推送业务带来的。智能手机快速休眠是节约电池，但在下行数据到达，需要MME频繁的寻呼唤醒UE来接收数据。随着智能手机和推送业务的增长，寻呼消息越来越多，对网络压力越来越大。尤其对于一个HeNB-GW连接多个HeNB的网络部署下，由于HeNB可能同属于同一个TA(Tracking Are，跟踪区)列表，这样对于每个HeNB都会收到大量的寻呼消息。通常HeNB都是受限于价格处理性能远不如宏站，所以此场景会导致用户寻呼慢，网络侧以及空口资源紧张，或者寻呼不到等问题。

为此，传统技术大致包括以下两个方面：1.通过增加一些UE(User Equipment，用户设备)标示或者基站信息指示给MME或者HeNB-GW，这样减少寻呼信令；2.通过丢弃低优先级的寻呼来提升高优先级用户体验。对于方法1，通常修改的地方比较多，并且改动复杂涉及多个网元，但是即便能精确寻呼，随着基站支持的用户数增大，还是存在寻呼压力；对于方法2，丢弃部分用户的寻呼，必然导致低优先级的用户体验变差，影响用户的体验。而本申请通过寻呼合并减轻信令开销，进而解决寻呼并发问题。

本申请提供的寻呼合并方法，可以应用于如图1所示的应用环境中。具体的，一个基站网关102连接多个基站104；核心网根据数据网关的下行数据标示对空闲态的UE发起寻呼，这里可能是全网寻呼也可能是精确寻呼；基站网关102接收寻呼消息，并传输给相应的基站104；基站104用来发送寻呼消息给底层模块，最终寻呼相应的UE；而UE用来接收基站的寻呼消息。其中，基站网关102可以但不限于是各种网关，例如HeNB-GW；基站104可以是HeNB；UE可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备；核心网可以包含MME和数据网关。

在一个实施例中，如图2所示，提供了一种寻呼合并方法，以该方法应用于图1中的基站网关为例进行说明，包括以下步骤：

步骤202，将寻呼自定义消息发送给相应的基站；寻呼自定义消息用于指示基站通过空口、将解析寻呼自定义消息得到的寻呼消息传输给相应的UE。

其中，寻呼自定义消息为对低优先级的MME寻呼消息进行合并组建得到的；具体的，可由基站网关对低优先级的MME寻呼消息进行合并组建得到。

需要说明的是，MME寻呼消息指的是MME发送给基站网关的寻呼消息，即核心网下发的Paging(寻呼)，经由MME传输给基站网关；而低优先级的MME寻呼消息，可以指经基站网关对寻呼进行分类后得到的、优先级较低的寻呼消息，即优先级低于预设等级的寻呼消息(该预设等级可以是依据寻呼域、寻呼优先级以及实时性等消息属性设立的)；相应的，本申请中高优先级的MME寻呼消息，可以指经基站网关对寻呼进行分类后得到的、优先级较高的寻呼消息，即优先级高于预设等级的寻呼消息。

在一个具体的示例中，基站网关将多个标准消息组合在一起，进而得到寻呼自定义消息；正常情况下，一条网络侧寻呼消息只有一条寻呼记录，而本申请中的寻呼自定义消息是对标准网络寻呼消息的合并组建；具体的，可参照36413协议(其中，r10版本新增的一个寻呼优先级字段)，新定义一个寻呼自定Paging User Define(即寻呼自定义消息)，如下表表1所示：

表1-寻呼自定义消息的定义

IE/Group Name	Presence	Range
			Message Type	M
Paging define List		1
			Paging Define List item		1 to<256>
>UE Identity Index value	M
			>UE Paging Identity	M
>Paging DRX	O
			>CN Domain	M
>List of TAIs		1
			>>TAI List Item		1 to<maxnoofTAIs>
>>>TAI	M
			>CSG Id List		0..1
>>CSG Id		1 to<maxnoofCSGId>
			>Paging Priority	O

上述标准网络寻呼消息，可以指核心网下发的Paging(寻呼)；进一步的，本申请的基站网关可以根据实际需求，对Paging进行分类(例如，实时寻呼消息和非实时寻呼消息、高优先级的MME寻呼消息和低优先级的MME寻呼消息)；进一步的，对实时类业务的Paging(即实时寻呼消息)或高优先级的MME寻呼消息立即下发，对非实时类的Paging(即非实时寻呼消息)或低优先级的MME寻呼消息存放在缓冲区，进而进行合并组装得到寻呼自定义消息并下发。

需要说明的是，通常情况下，寻呼的主要目的是为了建立起UE到EPC(核心网)的信令连接，以便进行后续的信令或数据传输。

基于本申请，通过寻呼自定义消息减少了基站的寻呼压力，同时通过解析寻呼自定义消息可直接通过空口并发最大16条寻呼记录，节约了基站的空口资源。且本申请操作简单，缓解了和多个基站之间链路的寻呼压力。本申请应用于图1所示的网络架构系统，对系统改动较小，涉及的网元较少，提升了整个系统的寻呼能力，同时缓解了部分网元间的寻呼压力，有效地解决了在高并发寻呼业务场景下的资源浪费问题。

在一个实施例中，如图3所示，提供了一种寻呼合并方法，以该方法应用于图1中的基站网关为例进行说明，包括以下步骤：

步骤302，接收MME寻呼消息，并根据寻呼域与寻呼优先级，获取MME寻呼消息的优先级；

步骤304，若MME寻呼消息的优先级为低优先级，则缓存低优先级的MME寻呼消息；

步骤306，在缓存的时长满足预设缓存周期时，合并组建预设数量的低优先级的MME寻呼消息，得到寻呼自定义消息。

步骤308，将寻呼自定义消息发送给相应的基站；寻呼自定义消息用于指示基站通过空口、将解析寻呼自定义消息得到的寻呼消息传输给相应的UE。

进一步的，在一个具体的实施例中，还包括步骤：

步骤310，若MME寻呼消息的优先级为高优先级，则将高优先级的MME寻呼消息传输给相应的基站；高优先级的MME寻呼消息用于指示基站寻呼相应的UE。

具体而言，MME根据下行数据，组装相应的MME寻呼消息下发给基站网关。基站网关接收MME下发的寻呼消息；

基站网关对寻呼进行分类，例如通过寻呼消息类的优先级和寻呼域进行综合判断；若将寻呼消息分类为低优先级寻呼(即低优先级的MME寻呼消息)，则开启周期性定时器，对低优先级寻呼进行缓存，定时器超时(即缓存的时长满足预设缓存周期)组建寻呼自定义消息下发给相应的基站。其中，本申请利用定时器搜集低优先级的寻呼，进而用来合并寻呼自定义消息。

而若将寻呼消息分类为高优先级寻呼(即高优先级的MME寻呼消息)，则将高优先级寻呼直接发送给基站，由基站寻呼相应的UE。

在一个具体的示例中，寻呼域包括CS(Circuit Switched Domain，电路交换域)域；MME寻呼消息为标准S1AP寻呼消息。

具体而言，基站网关接收MME发送的MME寻呼消息，并对MME寻呼消息的类型进行分类，可通过寻呼消息类的优先级(即寻呼优先级)和寻呼域进行综合判断，对CS域(CircuitSwitched Domain，电路交换域)寻呼以及高优先级的寻呼(例如寻呼优先级0-2)定义为高优先级(即高优先级的MME寻呼消息)寻呼，其他类寻呼定义为低优先级寻呼(即低优先级的MME寻呼消息)。

需要说明的是，寻呼优先级的实质可以是现有协议定义的、寻呼消息中的可选字段(即Paging Priority)，例如可参见36413协议中第9.1.6节定义的寻呼标准；而有些MME发送的寻呼消息里可能未携带这个字段；对此，基于本申请，可依据寻呼优先级和寻呼域进行综合判断，进而获取到寻呼消息的优先级。

在一个具体的示例中，预设数量的取值范围为小于或等于256条。

具体而言，基站网关查看缓存是否存在寻呼消息，若无则不进行处理，若有寻呼消息，则需要重组寻呼自定义消息，自定义寻呼消息最大的寻呼条数为256。

若缓存未超过256，则组建一条寻呼自定义消息给相应基站。

若缓存超过256，则根据256定义一个寻呼自定义消息，组建多条寻呼自定义消息，并发送给相应基站。

而基站在接收到各寻呼自定义消息时，对寻呼自定义消息进行解析以及空口下发；基站在接收到高优先级的MME寻呼消息时，可直接寻呼相应的UE

基于本申请，通过寻呼自定义消息减少了基站的寻呼压力，同时通过解析寻呼自定义消息可直接通过空口并发最大16条寻呼记录，节约了基站的空口资源。且本申请操作简单，缓解了和多个基站之间链路的寻呼压力。应用于图1所示的网络架构系统，本申请改动较小，涉及的网元较少，提升了整个系统的寻呼能力，同时缓解了部分网元间的寻呼压力，有效地解决了在高并发寻呼业务场景下的资源浪费问题。

进一步的，基站网关对低优先级的MME寻呼消息进行合并组建得到寻呼自定义消息；从而在实际应用中，通过本申请对业务分类，并发非高优先级的用户，并未影响低优先级用户体验；此外，可优先寻呼高优先级的用户，进而改善高优先级用户的体验。

在一个实施例中，如图4所示，提供了一种寻呼合并方法，以该方法应用于图1中的基站为例进行说明，包括以下步骤：

步骤402，解析接收到的、网关发送的寻呼自定义消息；

步骤404，通过空口，将解析寻呼自定义消息得到的寻呼消息传输给相应的UE。

在一个具体的实施例中，还包括步骤：

根据接收到的、网关发送的高优先级的MME寻呼消息，寻呼相应的UE。

具体而言，基站在接收到寻呼自定义消息时，对寻呼自定义消息进行空口Paging组包(可含多个寻呼记录)后，发送寻呼消息给底层模块，最终寻呼相应的UE。

其中，空口Paging组包可以指把网络侧下发的消息解析，并组建成空口的寻呼消息；正常情况下，一条网络侧寻呼消息只有一条寻呼记录，而本申请中的寻呼自定义消息是对标准网络寻呼消息的合并组建；而空口一条寻呼消息可以有16个寻呼记录。

需要说明的是，对于空口来说，一条寻呼消息可以携带16条寻呼记录，对应于网络侧的16条寻呼消息；寻呼记录可以指空口寻呼消息携带的信元；寻呼消息可以是网络侧寻呼消息也可以指空口寻呼消息。

进一步的，对于寻呼自定义消息，基站要先解析自定义寻呼中携带的寻呼条数，进而按空口预设条数(最大16条)寻呼记录一组进行下发，若大于16则有需要发送多条空口合并的寻呼消息。

此外，基站可根据相应的时刻调度出寻呼消息，最终UE收到寻呼消息，发起相应的连接建立，随后进行数据收发。其中，采用空口发寻呼消息，可在相应的寻呼时刻进行；而相应的时刻可以依据相关公式计算得到。

需要说明的是，上述16条寻呼消息对应于网络侧的16条寻呼消息，对于空口的寻呼消息来说就是16个寻呼记录。其中，预设条数可根据网络侧下发的寻呼自定义消息里面的寻呼个数决定。

在一个具体的实施例中，在解析接收到的、网关发送的寻呼自定义消息的步骤之前还可以包括步骤：

在接收到网关发送的消息时，根据消息ID标识对网关发送的消息进行识别，确认网关发送的消息为寻呼自定义消息或高优先级的MME寻呼消息。

具体而言，基站在接收到网关发送的消息后，可先判断是寻呼自定义消息或者是寻呼标准消息(即高优先级的MME寻呼消息)，如果是寻呼标准消息则直接发送给相应的UE。

其中，网络侧S1下发的每一条消息都有ID(IDentity)标识(即消息ID标识)；本申请新定义了一个标识字段：对于寻呼标准消息，可以是id-Paging

ProcedureCode::＝10；而对于寻呼自定义消息，可以是id-PagingUserDefine

ProcedureCode::＝200。进而基站可判断出网关发送的消息是寻呼自定义消息或者是寻呼标准消息，从而进行相关的处理。

上述从基站角度实施的寻呼合并方法中，从用户角度来看，通过对业务分类，优先寻呼高优先级的用户，并发非高优先级的用户，高优先级用户体验得到改善，并未影响低优先级用户体验。从基站来看，通过自定义的寻呼消息减少了基站的寻呼压力，同时通过解析自定义寻呼消息可直接通过空口并发最大16条寻呼记录，节约了基站的空口资源。从HeNB-GW看，本申请操作简单，缓解了和多个基站之间链路的寻呼压力。从网络架构系统的角度来看，本申请改动较小，涉及的网元较少，提升了整个系统的寻呼能力，同时缓解了部分网元间的寻呼压力，有效地解决了在高并发寻呼业务场景下的资源浪费问题。

应该理解的是，虽然图2-4的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2-4中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图5所示，提供了一种从网关角度实施的寻呼合并装置，包括：

网关寻呼发送模块510，用于将寻呼自定义消息发送给相应的基站；寻呼自定义消息用于指示基站通过空口、将解析寻呼自定义消息得到的寻呼消息传输给相应的UE；寻呼自定义消息为对低优先级的MME寻呼消息进行合并组建得到的。

在一个具体的实施例中，还包括：

网关寻呼接收模块520，用于接收MME发送的MME寻呼消息；

网关寻呼处理模块530，用于根据寻呼域与寻呼优先级，获取MME寻呼消息的优先级；

网关寻呼缓存模块540，用于若MME寻呼消息的优先级为低优先级，则缓存低优先级的MME寻呼消息；以及在缓存的时长满足预设缓存周期时，合并组建预设数量的低优先级的MME寻呼消息，得到寻呼自定义消息。

在一个具体的实施例中，

网关寻呼发送模块510，还用于若MME寻呼消息的优先级为高优先级，则将高优先级的MME寻呼消息传输给相应的基站；高优先级的MME寻呼消息用于指示基站寻呼相应的UE。

在一个具体的实施例中，预设数量的取值范围为小于或等于256条。

在一个具体的实施例中，寻呼域包括CS域；MME寻呼消息为标准S1AP寻呼消息。

在一个实施例中，如图6所示，提供了一种从基站角度实施的寻呼合并装置，包括：

基站寻呼接收模块610，用于解析接收到的、网关发送的寻呼自定义消息；

基站寻呼发送模块620，用于通过空口，将解析寻呼自定义消息得到的寻呼消息传输给相应的UE。

在一个具体的实施例中，基站寻呼接收模块610，用于接收网关发送的高优先级的MME寻呼消息；

基站寻呼发送模块620，用于根据所述高优先级的MME寻呼消息，寻呼相应的UE。

在一个具体的实施例中，基站寻呼接收模块610，还用于在接收到网关发送的消息时，根据消息ID标识对网关发送的消息进行识别，确认网关发送的消息为寻呼自定义消息或高优先级的MME寻呼消息。

关于寻呼合并装置(从网关角度实施的寻呼合并装置或从基站角度实施的寻呼合并装置)的具体限定可以参见上文中对于寻呼合并方法(从网关角度实施的寻呼合并方法或从基站角度实施的寻呼合并方法)的限定，在此不再赘述。上述寻呼合并装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

如图7所示，下面结合一个具体的实例对本申请进行阐述，从HENB、HeNB-GW角度说明，本申请减少了信令开销，缓解了HENB和HeNB-GW的寻呼压力。

UE：用来接收基站的寻呼消息；

HENB：用来解析寻呼自定义消息，同时通过空口信令合并多条寻呼记录(36.331协议允许最大16条)；

HeNB-GW：用来对MME的寻呼消息进行分类，同时对低优先级的寻呼消息进行缓存，周期性的触发寻呼自定义消息；

MME：根据下行数据，组装相应的标准S1AP寻呼消息下发给HeNB-GW。

对于寻呼自定义消息的说明：参照36413协议，新定义一个寻呼自定Paging UserDefine，如图2所示：其中最大的合并寻呼的条数是256条。

如图7所示，HeNB-GW可以包括四个模块，HENB涉及两个模块。

HeNB-GW寻呼接收模块：用于接收MME下发的寻呼消息并解析；

HeNB-GW寻呼处理模块：一方面用于对寻呼进行分类，例如优先级等级为0-2或者CS寻呼的消息定义为高优先级业务，另一方面对高优先级的业务的寻呼直接转发给寻呼发送模块。

HeNB-GW寻呼缓存模块：用于开启周期性定时器，对低优先级的寻呼进行缓存，定时器超时组建自定义寻呼消息下发给寻呼发送模块。

HeNB-GW寻呼发送模块：用于发寻呼消息或者寻呼自定义消息给基站。

HENB寻呼接收模块：用于接收HeNB-GW寻呼消息，对寻呼自定义消息进行空口paging组包(可含多个寻呼记录)。

HENB寻呼发送模块：用来发送寻呼消息给底层模块，最终寻呼相应的UE。

以上寻呼合并装置的具体的实施方式可以如下所述：

(1)核心网根据数据网关的下行数据标示对空闲态的UE发起寻呼，这里可能是全网寻呼也可能是精确寻呼。

(2)HeNB-GW寻呼接收模块接收寻呼消息，HeNB-GW寻呼处理模块解析寻呼消息，同时对寻呼消息的类型进行分类，可通过寻呼消息类的优先级和寻呼域进行综合判断，对CS域(Circuit Switched Domain，电路交换域)寻呼以及高优先级的寻呼(例如寻呼优先级0-2)定义为高优先级，其他类寻呼定义为低优先级寻呼。

(3)HeNB-GW寻呼处理模块对高优先级的寻呼直接发送给HENB-GW寻呼发送模块，转发给HENB。

(4)HeNB-GW寻呼处理模块对低优先级的寻呼则发送给HENB-GW寻呼缓存模块；

(5)HENB-GW寻呼缓存模块开启一个周期性的定时器T0，该定时器的周期建议做到可配置，这样可以根据不同的应用场景进行配置。

(6)周期定时器T0超时以后，HENB-GW寻呼缓存模块查看缓存是否存在寻呼消息，若无则不进行处理，若有寻呼消息，则需要重组自定义寻呼消息，自定义寻呼消息最大的寻呼条数256。若无未超过256则组建一条寻呼自定义消息给寻呼发送模块。

(7)若缓存超过256，则HENB-GW寻呼缓存模块根据256定义一个寻呼自定义消息，组建多条寻呼自定义消息，并发送给HENB-GW寻呼发送模块。

(8)HENB-GW寻呼发送模块收到消息以后，则发送给相应的HeNB。

(9)HENB寻呼接收模块收到寻呼消息以后，判断是寻呼自定义消息或者是寻呼标准消息，寻呼标准消息则直接发送给HENB寻呼发送模块。

(10)对于寻呼自定义消息，HENB寻呼接收模块则要先解析自定义寻呼中携带的寻呼条数，按空口最大16条一组下发给HENB寻呼发送模块，若大于16则有需要发送多条空口合并的寻呼消息给HENB寻呼发送模块。

(11)HENB寻呼发送模块根据相应的时刻调度出寻呼消息，最终UE收到寻呼消息，发起相应的连接建立，随后进行数据收发。

应用本申请，可以有效的解决Paging并发问题，提升整个系统的寻呼能力，同时能缓解网元间的寻呼压力，有效的解决在高并发寻呼业务场景下的资源浪费问题，同时又能满足普通业务和高优先级业务的用户体验。而在实际应用中，通过空口的寻呼和基站的日志以及抓包就可确认使用了本申请的方案。

在一个实施例中，提供了一种网关，网关用于执行上述从网关角度实施的寻呼合并方法的步骤。

在一个具体的实施例中，网关为HeNB-GW。

在一个实施例中，提供了一种基站，基站用于执行上述从基站角度实施的寻呼合并方法的步骤。

在一个具体的实施例中，基站为HeNB。

在一个实施例中，如图8所示，提供了一种寻呼合并系统，包括上述网关以及上述基站；还包括MME以及UE；MME通过网关连接各基站；基站连接对应的UE

网关用于执行上述从网关角度实施的寻呼合并方法的步骤。

基站用于执行上述从基站角度实施的寻呼合并方法的步骤。

在一个具体的实施例中，网关为HeNB-GW；基站为HeNB。

本领域技术人员可以理解，图8中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述任一项寻呼合并方法(从网关角度实施的寻呼合并方法、从基站角度实施的寻呼合并方法或寻呼合并方法)的步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (17)

1.一种寻呼合并方法，其特征在于，包括：

将寻呼自定义消息发送给相应的基站；所述寻呼自定义消息用于指示所述基站通过空口、将解析所述寻呼自定义消息得到的寻呼消息传输给相应的UE；

所述寻呼自定义消息为对低优先级的MME寻呼消息进行合并组建得到的。

2.根据权利要求1所述的寻呼合并方法，其特征在于，在将寻呼自定义消息发送给基站的步骤之前还包括步骤：

接收MME寻呼消息，并根据寻呼域与寻呼优先级，获取所述MME寻呼消息的优先级；

若所述MME寻呼消息的优先级为低优先级，则缓存所述低优先级的MME寻呼消息；

在所述缓存的时长满足预设缓存周期时，合并组建预设数量的所述低优先级的MME寻呼消息，得到所述寻呼自定义消息。

3.根据权利要求2所述的寻呼合并方法，其特征在于，所述预设数量的取值范围为小于或等于256条。

4.根据权利要求2所述的寻呼合并方法，其特征在于，还包括步骤：

若所述MME寻呼消息的优先级为高优先级，则将所述高优先级的MME寻呼消息传输给相应的基站；所述高优先级的MME寻呼消息用于指示所述基站寻呼相应的UE。

5.根据权利要求2至4任意一项所述的寻呼合并方法，其特征在于，所述寻呼域包括CS域；所述MME寻呼消息为标准S1AP寻呼消息。

6.一种寻呼合并方法，其特征在于，包括：

解析接收到的、网关发送的寻呼自定义消息；

通过空口，将解析所述寻呼自定义消息得到的寻呼消息传输给相应的UE。

7.根据权利要求6所述的寻呼合并方法，其特征在于，还包括步骤：

根据接收到的、所述网关发送的高优先级的MME寻呼消息，寻呼相应的UE。

8.根据权利要求7所述的寻呼合并方法，其特征在于，在解析接收到的、网关发送的寻呼自定义消息的步骤之前还包括步骤：

在接收到网关发送的消息时，根据消息ID标识对所述网关发送的消息进行识别，确认所述网关发送的消息为所述寻呼自定义消息或所述高优先级的MME寻呼消息。

9.一种寻呼合并装置，其特征在于，包括：

网关寻呼发送模块，用于将寻呼自定义消息发送给相应的基站；所述寻呼自定义消息用于指示所述基站通过空口、将解析所述寻呼自定义消息得到的寻呼消息传输给相应的UE；所述寻呼自定义消息为对低优先级的MME寻呼消息进行合并组建得到的。

10.一种寻呼合并装置，其特征在于，包括：

基站寻呼接收模块，用于解析接收到的、网关发送的寻呼自定义消息；

基站寻呼发送模块，用于通过空口，将解析所述寻呼自定义消息得到的寻呼消息传输给相应的UE。

11.一种网关，其特征在于，所述网关用于执行权利要求1至5中任一项所述寻呼合并方法的步骤。

12.根据权利要求11所述的网关，其特征在于，所述网关为HeNB-GW。

13.一种基站，其特征在于，所述基站用于执行权利要求6至8中任一项所述寻呼合并方法的步骤。

14.根据权利要求13所述的基站，其特征在于，所述基站为HeNB。

15.一种寻呼合并系统，其特征在于，包括网关以及若干基站；还包括MME以及UE；所述MME通过所述网关连接各所述基站；所述基站连接对应的所述UE；

所述网关用于执行权利要求1至5中任一项所述寻呼合并方法的步骤；

所述基站用于执行权利要求6至8中任一项所述寻呼合并方法的步骤。

16.根据权利要求15所述的寻呼合并系统，其特征在于，所述网关为HeNB-GW；所述基站为HeNB。

17.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至8中任一项所述的方法的步骤。