寻呼失败处理方法及装置与流程

本发明涉及通信领域，尤其涉及一种寻呼黑洞失败处理方法及装置。

背景技术：

寻呼黑洞是寻呼失败率大于一定阈值的区域，又可称为寻呼黑洞小区。

长期演进(Long Term Evolution，LTE)系统中，对于空闲态的用户设备设备(User，Equipment，UE)，当UE有业务到达时；或者对于空闲态或连接态的UE，当系统消息需要变更或者需要进行地震海啸预警或商业移动预警服务时，网络需要对相应的UE进行寻呼。寻呼流程通常是：为UE服务的移动管理实体(Mobile Management Entity，MME)向跟踪区域(Tracking Area，TA)范围内的所有演进型基站(演进型基站又可称为eNodeB或eNB)发送寻呼消息，当eNodeB接收到MME发送的寻呼消息时再向其管辖范围内的UE下发寻呼消息。

在LTE系统核心网架构中，服务网关(Serving Gateway，S-GW)保存UE的用户设备面上下文，如UE的网络协议(Internet Protocol，IP)地址和路由信息等，MME发送寻呼信息到eNodeB，并与S-GW进行信息交互；演进的通用陆地无线接入网(Evolution Universal Terrestrial Radio Access Network，E-UTRAN)可以包括多个eNB，接收到MME发送的寻呼消息的eNB会将寻呼消息发送到连接的小区。

EPS网络中的详细寻呼过程如图1所示，当S-GW需要向UE发送下行数据却发现因UE处于空闲状态，而没有用户设备连接时，则向UE注册的MME发送下行数据通知消息；MME首先确定UE所注册的跟踪区域列表(Tracking Area List，TAL)，再向该TAL里所有的eNB发送寻呼消息查找UE，消息中携 带有与该TA list中全部TA一一对应的跟踪区标识(Tracking Area Identifier，TAI)；eNB接收到该寻呼消息后，查找哪些小区属于TAL所包含的TA，向查找出的小区发送该寻呼消息；当前处于小区中的UE接收到该寻呼消息后，发送寻呼响应消息到与其所在小区相连的eNB，eNB通知MME寻呼已响应；MME则不继续向eNB下发寻呼消息。

寻呼成功率是移动通信系统的重要网络质量指标，它直接影响无线接入性与其它网络质量指标的优劣。若出现寻呼黑洞将直接影响寻呼成功率。在现有技术中通常采用以下三种方法进行寻呼黑洞的处理，以提高寻呼成功率。

第一，通过道路测试或者呼叫质量拨打测试(Call Quality Test，CQT)发现寻呼黑洞问题，然后再根据测量得到的下行电平值进行估计寻呼失败的原因。如果下行电平大于良好阈值，那么就认为是信道资源配置问题或者是上行覆盖问题，如果下行电平差(例如小于-95dBm)就认为是下行覆盖问题，上行覆盖在道路测试与CQT测试中是看不到的；故仅能对定位到部分寻呼黑洞，处理效果不佳。

第二，在没有监测LTE系统S1接口(或GSM系统A接口、UMTS系统Iu-CS接口)信令前，寻呼成功率指标只能通过MME(或MSC)的统计报告中提取，只能采集TA级别的寻呼成功率，通过MME下所有TA的寻呼成功率指标对比，发现寻呼较差的TA并关联到相应的地理范围，显然不能精确定位寻呼黑洞的位置所在，处理效率及处理效果都不够理想。

第三，在监测LTE系统S1接口信令后(或GSM系统A接口、UMTS系统Iu-CS接口)，可通过S1接口关键信令中提取寻呼无响应的统计，具体现象体现为MME在收到SGS口上MSC发来的寻呼消息后，在S1-MME口给用户设备所在TAC区的eNodeB下发寻呼消息，但未收到用户设备的任何响应。由于没有eNodeB返回的响应消息，从S1接口无法得到用户设备出现问题所在的接入网的小区识别码，(E-UTRAN Cell Indentifier，ECI)信息，只能从S1寻呼消息中拿到用户设备所处的跟踪区域码(Tracing Area Code，TAC)。根据用户设备最近一次发生业务的确定寻呼黑洞，但是实践证明这种方式确定的寻呼黑 洞准确度低，结果不可靠。

故提出一种能够精确定位出寻呼黑洞的方法是现有技术亟待解决的问题。

技术实现要素：

有鉴于此，本发明实施例期望提供一种寻呼黑洞失败处理方法及装置，能够至少部分解决上述问题。

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

本发明实施例第一方面提供一种寻呼失败处理方法，所述方法包括：

从通信网络接口提取表征寻呼失败的寻呼失败消息；

依据所述寻呼失败消息，确定出寻呼失败的用户设备的设备标识；

基于设备标识获取所述用户设备的与寻呼关联的关联信息；

基于所述关联信息，确定导致寻呼失败的寻呼黑洞小区和/或导致寻呼黑洞小区的原因。

优选地，所述从通信网络接口提取表征寻呼失败的寻呼失败消息，包括：从S1-MME接口采集寻呼失败消息；

所述依据所述寻呼失败消息，确定出寻呼失败的用户设备的设备标识，包括：解析从S1-MME接口采集的寻呼失败消息，确定寻呼失败的用户设备的设备标识；

所述基于设备标识获取所述用户设备的与寻呼关联的关联信息，包括：

基于所述设备标识确定出所述用户设备寻呼成功的跟踪区更新的目标小区；

所述基于所述关联信息，确定导致寻呼失败的寻呼黑洞小区和/或导致寻呼黑洞小区的原因，包括：确定与所述目标小区不属于同一跟踪区列表的小区为所述寻呼黑洞小区和/或确定同一MME内部的跟踪区更新导致了寻呼黑洞小区。

优选地，所述从通信网络接口提取表征寻呼失败的寻呼失败消息，包括：从S6a接口采集跨MME的跟踪区更新TAU完成消息及从SGs接口采集寻呼失 败消息；

所述基于设备标识获取所述用户设备的与寻呼关联的关联信息，包括：

基于所述设备标识确定出所述用户设备寻呼成功的跟踪区更新的目标小区；

所述基于所述关联信息，确定导致寻呼失败的寻呼黑洞小区和/或导致寻呼黑洞小区的原因，包括：确定与所述目标小区不属于同一跟踪区列表的小区为所述寻呼黑洞小区和/或确定跨MME的跟踪区更新导致了寻呼黑洞小区。

优选地，所述从通信网络接口提取表征寻呼失败的寻呼失败消息，包括：

从SGs接口或S1-MME接口的寻呼失败消息；其中，所述第一类用户设备为需要通过语音回流进行语音通信的用户设备；

所述基于设备标识获取所述用户设备的与寻呼关联的关联信息，包括：

依据从S6a接口采集第一类用户设备从第一通信制式网络重选回第二通信制式网络的注册信息；

所述基于所述关联信息，确定导致寻呼失败的寻呼黑洞小区和/或导致寻呼黑洞小区的原因，包括：

解析所述注册信息和所述寻呼失败消息，确定出所述注册信息及所述寻呼失败消息同时包括的设备标识；

若所述注册信息及所述寻呼失败消息同时包括的设备标识；

基于所述设备标识确定所述用户设备所述从第一通信制式网络重选回第二通信制式网络的目标小区；

确定所述第一类用户设备在所述第二通信制式网络最后连接的小区；

若所述从第一通信制式网络重选回第二通信制式网络的目标小区为所述第一类用户设备在所述第二通信制式网络最后连接的小区，则确定从所述第一通信制式网络重选回所述第二通信制式网络导致了所述寻呼黑洞小区。

优选地，所述从通信网络接口提取表征寻呼失败的寻呼失败消息，包括：

从SGs接口采集的寻呼失败消息；

所述基于设备标识获取所述用户设备的与寻呼关联的关联信息，包括：

确定所述寻呼失败消息中的设备标识是否包括在所述重附着消息中；

所述基于所述关联信息，确定导致寻呼失败的寻呼黑洞小区和/或导致寻呼黑洞小区的原因，包括：若所述寻呼失败消息中的设备标识有包括在所述重附着消息中，则确定小区的弱覆盖导致所述寻呼黑洞小区。

优选地，所述从通信网络接口提取表征寻呼失败的寻呼失败消息，包括：

依据从S1-MME接口和SGs接口采集的寻呼失败消息；

所述基于设备标识获取所述用户设备的与寻呼关联的关联信息，包括：

基于所述设备标识采集所述用户设备的寻呼失败的出现频次；

所述基于所述关联信息，确定导致寻呼失败的寻呼黑洞小区和/或导致寻呼黑洞小区的原因，包括：

若寻呼失败的所述设备标识的出现频次达到指定次数，则确定用户设备故障导致了所述寻呼黑洞小区。

优选地，所述基于所述关联信息，确定导致寻呼失败的寻呼黑洞小区和/或导致寻呼黑洞小区的原因，包括：

在寻呼失败发生时所在的时间窗口内，基于寻呼失败的设备标识检索所述用户设备在发送所述寻呼失败前执行最后一次网络事件时所连接的小区，确定该小区为所述寻呼黑洞小区。

优选地，所述方法还包括以下至少其中之一：

当跟踪区更新导致寻呼失败时，修改小区重选迟滞参数，以降低更新区更新频率；

当用户设备从第一通信制式网络重选回第二通信制式网络导致了寻呼失败时，修改重选参数，以降低重选频率；

当小区弱覆盖导致了寻呼失败时，调整小区天馈系统参数，以提高小区的覆盖范围的信号强度；

当所述用户设备的软件故障导致寻呼失败时，通知所述用户设备。

本发明实施例第二方面提供一种寻呼失败处理装置，所述装置包括：

提取单元，用于从通信网络接口提取表征寻呼失败的寻呼失败消息；

第一确定单元，用于依据所述寻呼失败消息，确定出寻呼失败的用户设备的设备标识；

获取单元，用于基于设备标识获取所述用户设备的与寻呼关联的关联信息；

第二确定单元，用于基于所述关联信息，确定导致寻呼失败的寻呼黑洞小区和/或导致寻呼黑洞小区的原因。

优选地，所述提取单元，具体用于：从S1-MME接口采集寻呼失败消息；

所述第一确定单元，具体用于解析从S1-MME接口采集的寻呼失败消息，确定寻呼失败的用户设备的设备标识；

所述获取单元，具体用于基于所述设备标识确定出所述用户设备寻呼成功的跟踪区更新的目标小区；

所述第二确定单元，具体用于确定与所述目标小区不属于同一跟踪区列表的小区为所述寻呼黑洞小区和/或确定同一MME内部的跟踪区更新导致了寻呼黑洞小区。

优选地，所述提取单元，具体用于从S6a接口采集跨MME的跟踪区更新TAU完成消息及从SGs接口采集寻呼失败消息；

所述获取单元，具体用于基于所述设备标识确定出所述用户设备寻呼成功的跟踪区更新的目标小区；

所述第二确定单元，用于确定与所述目标小区不属于同一跟踪区列表的小区为所述寻呼黑洞小区和/或确定跨MME的跟踪区更新导致了寻呼黑洞小区。

优选地，所述提取单元，具体用于从SGs接口或S1-MME接口的寻呼失败消息；其中，所述第一类用户设备为需要通过语音回流进行语音通信的用户设备；

所述获取单元，具体用于依据从S6a接口采集第一类用户设备从第一通信制式网络重选回第二通信制式网络的注册信息；

所述第二确定单元，用于解析所述注册信息和所述寻呼失败消息，确定出所述注册信息及所述寻呼失败消息同时包括的设备标识；若所述注册信息及所述寻呼失败消息同时包括的设备标识；基于所述设备标识确定所述用户设备所 述从第一通信制式网络重选回第二通信制式网络的目标小区；确定所述第一类用户设备在所述第二通信制式网络最后连接的小区；若所述从第一通信制式网络重选回第二通信制式网络的目标小区为所述第一类用户设备在所述第二通信制式网络最后连接的小区，则确定从所述第一通信制式网络重选回所述第二通信制式网络导致了所述寻呼黑洞小区。

优选地，所述提取单元，用于从SGs接口采集的寻呼失败消息；

所述获取单元，用于确定所述寻呼失败消息中的设备标识是否包括在所述重附着消息中；

所述第二确定单元，具体用于若所述寻呼失败消息中的设备标识有包括在所述重附着消息中，则确定小区的弱覆盖导致所述寻呼黑洞小区。

优选地，所述提取单元，具体用于依据从S1-MME接口和SGs接口采集的寻呼失败消息；

所述获取单元，用于基于所述设备标识采集所述用户设备的寻呼失败的出现频次；

所述第二确定单元，具体用于若寻呼失败的所述设备标识的出现频次达到指定次数，则确定用户设备故障导致了所述寻呼黑洞小区。

优选地，所述第二确定单元，具体用于在寻呼失败发生时所在的时间窗口内，基于寻呼失败的设备标识检索所述用户设备在发送所述寻呼失败前执行最后一次网络事件时所连接的小区，确定该小区为所述寻呼黑洞小区。

优选地，所述装置还包括：

调整单元，用于执行以下至少其中之一：

当跟踪区更新导致寻呼失败时，修改小区重选迟滞参数，以降低更新区更新频率；

当用户设备从第一通信制式网络重选回第二通信制式网络导致了寻呼失败时，修改重选参数，以降低重选频率；

当小区弱覆盖导致了寻呼失败时，调整小区天馈系统参数，以提高小区的覆盖范围的信号强度；

当所述用户设备的软件故障导致寻呼失败时，通知所述用户设备。

本发明实施例所述的寻呼黑洞失败处理方法及装置，将分析寻呼失败消息，提取寻呼失败的用户设备的设备标识，通过关联信息，再分析关联信息就能够简便快速的确定出寻呼失败的原因或精确定位出寻呼黑洞小区。

附图说明

图1为本发明实施例提供的第一种寻呼失败处理方法的流程示意图；

图2为本发明实施例所述方法应用的一种通信系统的结构示意图；

图3为本发明实施例提供的一种寻呼失败处理装置的结构示意图；

图4为本发明实施例提供的一种无线环境示意图；

图5为本发明实施例提供的另一种无线环境的示意图；

图6为本发明实施例提供的第二种寻呼失败处理方法的流程示意图。

具体实施方式

以下结合说明书附图及具体实施例对本发明的技术方案做进一步的详细阐述。

方法实施例：

如图1所示，本实施例提供了一种寻呼失败处理方法，所述方法包括：

步骤S110：从通信网络接口提取表征寻呼失败的寻呼失败消息；

步骤S120：依据所述寻呼失败消息，确定出寻呼失败的用户设备的设备标识；

步骤S130：基于设备标识获取所述用户设备的与寻呼关联的关联信息；

步骤S140：基于所述关联信息，确定导致寻呼失败的寻呼黑洞小区和/或导致寻呼黑洞小区的原因。

本实施例所述的寻呼失败处理方法可应用于通信网络的任意一个网元中，具体如基站、移动管理实体MME或服务网关SG等设备中。

如图2所示为本发明实施例所述寻呼失败处理方法可能应用的通信网络， 在该通信网络中包括移动管理实体MME、基站收发台BTS节点nodeB、演进型基站eNodeB、基站控制器BSC、无线网络控制器RNC、媒体网关MGW、归属签约用户服务器HSS，长期演进系统LTE中的演进型基站eNodeB。在图2中所述MME包括MME1和MME2。在HSS和MME之间的接口为S6a接口。在MME和MSC之间的接口为SGs接口。在MSC和MGW之间的接口为MC接口。在MME和eNodeB之间的接口为S1-MME接口。用户设备通过eNodeB可接入网络。图2中的TAC表示的跟踪区码，不同的TAC的表示归属于不同的跟踪区。在图2中展示有TAC1、TAC2和TAC3这三个不同的跟踪区码。图2中展示的所述S6a接口、SGs接口、S1-MME接口都可为步骤S110中所述的通信接口。

在进行寻呼时，寻呼的信令中都会携带有被寻呼用户设备的设备标识。这里的设备标识可为国际移动用户识别码(International Mobile Subscriber Identification Number，IMSI)或通信网络为用户设备临时分配的临时识别码(Temporary Mobile Subscriber Identity，TMSI)。同样在表征寻呼失败的寻呼失败消息中，也可以获得所述用户标识，故在步骤S120通过解析所述寻呼失败消息确定出寻呼失败的设备标识。而这些用户设备当前可能驻留目标小区在某一个小区或可能希望切入某一个目标小区。在进行寻呼时，若寻呼失败显然，导致失败的小区应该位于所述目标小区的附近，故在本实施例的步骤S130中基于设备标识获取所述用户设备的与寻呼关联的关联信息。在步骤S140中基于所述关联信息，确定导致寻呼失败的寻呼黑洞小区和/或导致寻呼黑洞小区的原因。在步骤S130和步骤S140中把可能户寻呼先关联的关联信息采集起来，并最终通过比对分析等，可确定出寻呼黑洞小区。若确定了寻呼黑洞小区，确定了导致寻呼黑洞小区的原因，就能提供对应的寻呼黑洞处理策略，从而降低寻呼失败的概率。

本实施例提供了一种从通信接口采集能够表征寻呼失败的寻呼失败消息，通过解析寻呼失败消息确定出寻呼失败的用户设备UE，进而根据UE的所在小区及UE的操作等能够简便精确的确定出寻呼黑洞小区及原因。

上述步骤S110至步骤S140的实现方式有多种，以下介绍几种可实现方式：

方式一：

作为本实施例所述的方法，所述步骤S110可包括：从S1-MME接口采集寻呼失败消息。所述步骤S120可包括：解析从S1-MME接口采集的寻呼失败消息，确定寻呼失败的用户设备的设备标识。所述步骤S130可包括：基于所述设备标识确定出所述用户设备寻呼成功的跟踪区更新的目标小区；；步骤S140可包括：确定与所述目标小区不属于同一跟踪区列表的小区为所述寻呼黑洞小区和/或确定同一MME内部的跟踪区更新导致了寻呼黑洞小区。在本实施例中会从图2所示的S1-MM1接口上采集所述寻呼失消息。若SGs接口的寻呼时报消息和S1-MM1接口的寻呼失败消息中都有同一用户设备的设备标识，可认为是基于MME内部的TAU导致了寻呼失败。由于TAU总是发生在不同的TA或TAL之间。在本实施例中首先确定出找到寻呼成功的目标小区，若寻呼成功的目标小区所在的TA或TAL就不会出现因TA或TAL导致寻呼失败的现象，故在本实施例中首先确定出寻呼黑洞小区应该不在与所述寻呼成功的目标小区在同一个TA或TAL，这样就可以缩小寻呼黑洞小区，再根据所述寻呼失败消息的来源从而能够确定出导致寻呼失败的原因为同一个MME内的跟踪区更新。

方式二：

所述步骤S110可包括：从S6a接口采集跨MME的跟踪区更新TAU完成消息及从SGs接口采集寻呼失败消息；所述步骤S120可包括：解析TAU完成消息及寻呼失败消息，确定出所述TAU完成消息及所述寻呼失败消息同时包括的设备标识；所述步骤S130可包括：基于所述设备标识确定出所述用户设备寻呼成功的跟踪区更新的目标小区；所述步骤S140可包括：确定与所述目标小区不属于同一跟踪区列表的小区为所述寻呼黑洞小区和/或确定跨MME的跟踪区更新导致了寻呼黑洞小区。

在本实施例中所述S6a接口采集跨MME TAU完成消息，显然此时用户设备存在着跨MME的TAU。若所述TAU完成消息和所述寻呼失败消息均包括统 一设备标识，则很有可能是跨MME的TAU导致的寻呼失败。且基于与同一MME内的TAU的一样，与寻呼成功的目标小区在同一TA或TAL中的小区为非寻呼黑洞小区，再结合用户设备的目标地址就可以缩小寻呼黑洞小区的范围，从而精确的确定出寻呼黑洞小区。

方式三：

所述步骤S110可包括：依据从S6a接口采集第一类用户设备从第一通信制式网络重选回第二通信制式网络的注册信息及SGs或S1-MME接口的寻呼失败消息；其中，所述第一类用户设备为需要通过语音回流进行语音通信的用户设备；这里的第一通信制式网络可包括第二代2G网络或第三代3G网络。所述第二通信制式网络可包括第四代网络4G。所述第一类用户设备可为需要在进行语音通话等语音通信操作时，回流的用户设备，如苹果手机等。

所述步骤S130可包括：依据从S6a接口采集第一类用户设备从第一通信制式网络重选回第二通信制式网络的注册信息。所述步骤S140可包括：解析所述注册信息和所述寻呼失败消息，确定出所述注册信息及所述寻呼失败消息同时包括的设备标识；若所述注册信息及所述寻呼失败消息同时包括的设备标识；基于所述设备标识确定所述用户设备所述从第一通信制式网络重选回第二通信制式网络的目标小区；确定所述第一类用户设备在所述第二通信制式网络最后连接的小区；若所述从第一通信制式网络重选回第二通信制式网络的目标小区为所述第一类用户设备在所述第二通信制式网络最后连接的小区，则确定从所述第一通信制式网络重选回所述第二通信制式网络导致了所述寻呼黑洞小区。

利用本实施例所述的方法，能够筛选出导致寻呼黑洞的原因是否是重选造成的，具有实现简便的特点。

方式四：

所述步骤S110可包括：从SGs接口采集的寻呼失败消息；所述步骤S130可包括：确定所述寻呼失败消息中的设备标识是否包括在所述重附着消息中；所述步骤S140可包括：若所述寻呼失败消息中的设备标识有包括在所述重附着消息中，则确定小区的弱覆盖导致所述寻呼黑洞小区。

本实施例通过所述重附着信息和寻呼失败消息的结合分析，可确定出是否是由重附着导致了所述寻呼黑洞小区，显然就简便的确定出了导致寻呼失败的原因。

方式五：

所述步骤S110可包括：依据从S1-MME接口和SGs接口采集的寻呼失败消息；所述步骤S130可包括：基于所述设备标识采集所述用户设备的寻呼失败的出现频次；所述步骤S140可包括：若寻呼失败的所述设备标识的出现频次达到指定次数，则确定用户设备故障导致了所述寻呼黑洞小区。

在本实施例中可根据同一个用户设备的是否总是频繁的出现寻呼失败，从而确定出是否是用户设备出现故障，从而避免误认为是通信网络参数导致寻呼失败的。在具体实现时，可首先采用前述方式一至凡是四中的方式排出上述导致寻呼黑洞小区和导致寻呼失败的原因后，再利用本方式所述的方法，来确定是否是用户设备故障。

在本实施例中所述用户设备故障可包括用户设备的软件故障和硬件故障两种，具体是哪一种可需要后续分析。

方式六：

所述步骤S140还可包括：在寻呼失败发生时所在的时间窗口内，基于寻呼失败的设备标识检索所述用户设备在发送所述寻呼失败前执行最后一次网络事件时所连接的小区，确定该小区为所述寻呼黑洞小区。

本实施例还提供了另一种有别于前述实施例中的所述确定寻呼黑洞小区的方法，在本实施例中若用户设备发生寻呼失败，而寻呼失败之前，所述用户设备还与通信网络的接入网络有过多次网络事件的执行，通常网络事件的执行都伴随着信息交互，如信号质量测量结果上报事件等。若用户设备执行了所述网络事件，很大几率上用户设备没有故障，而最后一次执行所述网络事件所连接的小区，很有可能就是在用户设备未大范围移动的场景下时的寻呼黑洞小区。

基于上述确定寻呼失败原因或确定寻呼黑洞小区的方式，以下提供一下针对每一种寻呼失败的后续处理方法；故所述方法还包括：

所述方法还包括以下至少其中之一：

当跟踪区更新导致寻呼失败时，修改小区重选迟滞参数，以降低更新区更新频率；这里的跟踪区更新可包括同一MME下的跟踪区更新，和跨MME的跟踪区更新；

当用户设备从第一通信制式网络重选回第二通信制式网络导致了寻呼失败时，修改重选参数，以降低重选频率；

当小区弱覆盖导致了寻呼失败时，调整小区天馈系统参数，以提高小区的覆盖范围的信号强度；

当所述用户设备的软件故障导致寻呼失败时，通知所述用户设备。

这里的软件故障可包括用户设备内部的软件冲突或进程吊死导致的寻呼无响应等现象。在本实施例中可控制网络向该用户设备发送通知，通知或控制用户设备重启或更换正常的用户设备，以提高寻呼成功率。

当然，所述用户设备包括第一类用户设备和第二类用户设备；所述第一类用户设备需要通过语音回流进行语音通信的用户设备；所述第二类用户设备为所述第一类用户设备以外的用户设备。针对两类不同的用户设备。所述步骤S110可包括：当所述用户设备为所述第一类用户设备时，从SGs接口、S1接口、S6a接口及MC接口提取所述寻呼失败消息；和/或，当所述用户设备为所述第二类用户设备时，从S1接口和S6A接口提取所述寻呼失败消息。

设备实施例：

如图3所示，本实施例提供一种寻呼失败处理装置，所述装置包括：

提取单元110，用于从通信网络接口提取表征寻呼失败的寻呼失败消息；

第一确定单元120，用于依据所述寻呼失败消息，确定出寻呼失败的用户设备的设备标识；

获取单元130，用于基于设备标识获取所述用户设备的与寻呼关联的关联信息；

第二确定单元140，用于基于所述关联信息，确定导致寻呼失败的寻呼黑洞小区和/或导致寻呼黑洞小区的原因。

本实施例中所述提取单元110和所述获取单元130都可包括通信接口，可用于从各个接口采集或接收所述寻呼失败消息或关联信息。所述提取单元110和所述获取单元130可对应于同一个通信接口，也可以对应于不同的通信接口。

所述第一确定单元120和所述第二确定单元140可对应于处理器或处理电路。所述处理器可包括应用处理器、中央处理器、微处理器、数字信号处理器或可编程阵列等。所述处理电路可包括专用集成电路。

所述装置内还可包括存储介质。所述存储介质分别与所述通信接口和所述处理器或处理电路相连。所述存储介质可为非瞬间存储介质，可用于存储可执行代码。所述处理器或处理电路通过执行所述可执行代码实现上述功能。处理器或处理电路通过总线等装置内部的通信接口与所述存储介质相连。

本实施例所述的装置，可为能够实现方法实施例中所述方法的实施硬件，同样具有能够快速分析出导致寻呼失败的原因和/或精确定位出寻呼失败黑洞小区的特点。

以下提供几种所述装置的可选结构。

结构一：

所述提取单元110，具体用于：从S1-MME接口采集寻呼失败消息；

所述获取单元130，具体用于基于所述设备标识确定出所述用户设备寻呼成功的跟踪区更新的目标小区；

所述第二确定单元140，具体用于确定与所述目标小区不属于同一跟踪区列表的小区为所述寻呼黑洞小区和/或确定同一MME内部的跟踪区更新导致了寻呼黑洞小区。

结构二：

所述提取单元110，具体用于从S6a接口采集跨MME的跟踪区更新TAU完成消息及从SGs接口采集寻呼失败消息；

所述获取单元130，具体用于基于所述设备标识确定出所述用户设备寻呼成功的跟踪区更新的目标小区；

所述第二确定单元140，用于确定与所述目标小区不属于同一跟踪区列表 的小区为所述寻呼黑洞小区和/或确定跨MME的跟踪区更新导致了寻呼黑洞小区。

结构三：

所述提取单元110，具体用于从SGs接口或S1-MME接口的寻呼失败消息；其中，所述第一类用户设备为需要通过语音回流进行语音通信的用户设备；

所述获取单元130，具体用于依据从S6a接口采集第一类用户设备从第一通信制式网络重选回第二通信制式网络的注册信息；

所述第二确定单元140，用于解析所述注册信息和所述寻呼失败消息，确定出所述注册信息及所述寻呼失败消息同时包括的设备标识；若所述注册信息及所述寻呼失败消息同时包括的设备标识；基于所述设备标识确定所述用户设备所述从第一通信制式网络重选回第二通信制式网络的目标小区；确定所述第一类用户设备在所述第二通信制式网络最后连接的小区；若所述从第一通信制式网络重选回第二通信制式网络的目标小区为所述第一类用户设备在所述第二通信制式网络最后连接的小区，则确定从所述第一通信制式网络重选回所述第二通信制式网络导致了所述寻呼黑洞小区。

结构四：

所述提取单元110，用于从SGs接口采集的寻呼失败消息；

所述获取单元130，用于确定所述寻呼失败消息中的设备标识是否包括在所述重附着消息中；

所述第二确定单元140，具体用于若所述寻呼失败消息中的设备标识有包括在所述重附着消息中，则确定小区的弱覆盖导致所述寻呼黑洞小区。

结构五：

所述提取单元110，具体用于依据从S1-MME接口和SGs接口采集的寻呼失败消息；

所述获取单元130，用于基于所述设备标识采集所述用户设备的寻呼失败的出现频次；

所述第二确定单元140，具体用于若寻呼失败的所述设备标识的出现频次 达到指定次数，则确定用户设备故障导致了所述寻呼黑洞小区。

结构五：

所述第二确定单元140，具体用于在寻呼失败发生时所在的时间窗口内，基于寻呼失败的设备标识检索所述用户设备在发送所述寻呼失败前执行最后一次网络事件时所连接的小区，确定该小区为所述寻呼黑洞小区。

结构六：

所述装置还包括：

调整单元，用于执行以下至少其中之一：

当跟踪区更新导致寻呼失败时，修改小区重选迟滞参数，以降低更新区更新频率；

当用户设备从第一通信制式网络重选回第二通信制式网络导致了寻呼失败时，修改重选参数，以降低重选频率；

当小区弱覆盖导致了寻呼失败时，调整小区天馈系统参数，以提高小区的覆盖范围的信号强度；

当所述用户设备的软件故障导致寻呼失败时，通知所述用户设备。

上述六种所述寻呼失败处理装置的结构可用于实现上述寻呼失败的处理，同样具有能够简便快速确定出导致寻呼失败的原因、精确定位出寻呼黑洞小区及实现简便的特点。

以下结合上述任意实施例提供两个具体示例。

示例一：

本示例所述的寻呼失败处理方法包括：

步骤100：从SGs接口采集寻呼失败关键信令，从S1-MME接口采集TAU成功的关键信令以及从23G网络重选回4G网络的注册消息，从S6a接口采集MME与HSS设备交互的信令消息，即跨MME的TAU complete消息。

步骤200，信息关联和寻呼失败的解析。所述步骤200又可分为步骤210至步骤260中几个分步骤。

步骤210，将SGs接口寻呼失败信令消息与S1-MME(MME与eNB接口)寻呼失败消息进行关联，剔除SGs接口呼损；从S1-MME接口采集的寻呼失败消息中解析用户的IMSI和TMSI信息，筛选出TAU成功的目标小区，关联与用户相关的对应的TAU request信令点(S1接口包含于eNB向MME发送的Initial UE message消息中，在Uu接口包含于UE向eNB发出的RRC Connection Setup Complete消息中)与TAU接收信令点。S1接口包含于MME向eNB发送的初始化内容设立请求(Initial context setup request)消息中。这里的SGs接口呼损可为SGs接口呼损是指电路域回落CSFB仪表采集SGs接口信令消息，以MSC发给MME的寻呼消息为原始数据，采集MME反馈给MSC的信令消息，有指示寻呼成功下发的，有指示寻呼直接失败的(IMSI Detached状态)，还有寻呼消息下发后无响应的，SGs接口呼损是指：MSC发给MME的寻呼消息总数减去MME给MSC反馈的寻呼成功下发的总数。

如图4所示，查找TAU成功的目标小区所在的无线环境，从LTE网络邻区关系列表中查找以目标小区为邻区的LTE小区列表，剔除与目标小区在同一个TA/TAL的无线小区，将在不同TA/TAL的小区定义为由MME内部TAU造成寻呼黑洞疑似小区。这里的寻呼黑洞疑似小区或图4中所示的疑似小区为被重点怀疑为寻呼黑洞小区的小区。

步骤220：从S6a接口采集跨MME的TAU complete消息，从网络侧为其分配新的全球唯一临时标识(Globally Unique Temporary Identifier，GUTI)中解析用户IMSI和TMSI信息，与SGs接口寻呼失败信令消息相关联，与S1-MME口采集的寻呼失败消息关联，筛选出TAU成功的目标小区。如图4所示，查找TAU成功的目标小区所在的无线环境，从LTE网络邻区关系列表中查找以目标小区为邻区的LTE小区列表，剔除与目标小区在同一个TA/TAL的无线小区，将在不同TA/TAL的小区定义为跨MME间TAU造成的寻呼黑洞疑似小区。每一条由MSC发出的寻呼消息都会携带被叫手机号码，这里系统自动把被叫手机号码翻译成IMSI消息，SGs接口、S1-MME 接口寻呼失败的消息中也解析出IMSI消息，IMSI消息是全球唯一的用户USIM卡标识。

步骤230：从S6a接口采集的23G重选回4G的注册消息(3GPP-Updated-Location)，从小区选择结束后的TAU消息中解析用户IMSI和TMSI信息，与SGs、S1-MME口采集的寻呼失败消息关联，筛选出由23G向4G重选的目标小区，解析TAU accept消息，按照TAU示意图查找TAU成功的目标小区，定义为A小区，检查其所在的无线环境，并根据用户IMSI和TMSI信息核查用户在4G网络最后一次业务连接所在的无线小区，定义为B，对比A小区与B小区是否为同一小区，如相同，则定义为234G系统间重选导致的寻呼黑洞疑似小区；如不同，则定义B小区为234G系统间重选导致的寻呼黑洞疑似小区。在图5中显示的就是在进行重选回时的无线环境。

步骤240：在S1-MME接口采集Reattach消息，解析出上报消息的eNB小区以及用户IMSI和TMSI信息，与SGs接口寻呼失败信令消息相关联，将关联到的寻呼无响应事件归类到无线小区，将其定义为由弱覆盖引起的隐式分离而导致的寻呼黑洞疑似小区。这里的弱覆盖表示基站发送的信号强度不够强。

步骤250：在SGs接口采集寻呼无响应事件，与S1-MME接口的寻呼无响应关联，解析出相关的用户IMSI和TMSI信息，剔除前几步筛选出的疑似寻呼黑洞小区及已关联过的用户IMSI和TMSI后，核对余下的用户IMSI和TMSI，如果发现某个或某几个IMSI和TMSI多次反复出现，将其定义为由用户设备及用户设备内部软件冲突或进程吊死造成的寻呼无响应。

步骤260：在SGs接口采集寻呼无响应事件，与S1-MME接口的寻呼无响应关联，解析出相关的用户IMSI和TMSI信息，剔除前几步筛选出的疑似寻呼黑洞小区及已关联过的用户IMSI和TMSI后，采用现有的寻呼黑洞定位方法，在寻呼无响应事件的发生时刻向前和向后在一个长时间窗口内，按照用户IMSI和TMSI信息检索距离最近的网络事件所在eNB小区，将其 定位为疑似寻呼黑洞小区。

步骤300，为了减少寻呼失败，对网路进行有优化。所述优化步骤可包括步骤310至步骤340。

步骤310：对于TAU导致寻呼无响应的寻呼黑洞小区，修改其小区重选迟滞CellQoffset，规避跨TAC频繁TAU，提升寻呼成功率；

步骤320：对于2G、3G重选回4G进行注册的寻呼黑洞小区，修改其系统间重选参数，规避频繁2B、3G\4G网络间重选，提升寻呼成功率；

步骤330:对于由弱覆盖引起的隐式分离而导致的寻呼黑洞疑似小区，调整小区天馈系统，压缩有效覆盖范围，来避免出现LTE下行信号不可及或下行可及而上行功率不足导致的寻呼无响应；

步骤340：对于由用户设备及用户设备内部软件冲突或进程吊死造成的寻呼无响应，需及时通过用户进行重启或更换用户设备。

示例二：

如图6所示，本示例所述方法包括：

步骤S301：从SGs接口采集寻呼失败关键信令，从S1-MME接口采集TAU成功的关键信令以及从23G网络重选回4G网络的注册消息，从S6a接口采集MME与HSS设备交互的信令消息，即跨MME的TAU complete消息。

步骤S302：将SGs接口寻呼失败信令消息与S1-MME(MME与eNB接口)寻呼失败消息进行关联，筛选出由MME内部TAU造成寻呼黑洞疑似小区、跨MME间TAU造成的寻呼黑洞疑似小区、234G系统间重选导致的寻呼黑洞疑似小区、由弱覆盖引起的隐式分离而导致的寻呼黑洞疑似小区、由终端及终端内部软件冲突或进程吊死造成的寻呼无响应及疑似寻呼黑洞小区。

步骤S303：对于TAU导致寻呼无响应的寻呼黑洞小区，修改其小区重选迟滞；对于23G重选回4G进行注册的寻呼黑洞小区，修改其系统间重选参数；对于由弱覆盖引起的隐式分离而导致的寻呼黑洞疑似小区，调整小区 天馈系统；对于由终端及终端内部软件冲突或进程吊死造成的寻呼无响应，及时通过用户进行重启或更换终端。

本发明示例中所述的寻呼失败关键信令、寻呼失败信令消息、无响应消息或无响应事件都可为上述寻呼失败消息的一种，再次就不再一一举例了。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理模块中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易 想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。