寻呼失败分析

CSFB寻呼失败案例分析案例标题：B2_PL二环路西HLF_H-2寻呼提升优化作者:郭晖摘要：B2_PL二环路西HLF_H-2小区寻呼成功率较低，且寻呼无影响次数较多。

关键词：寻呼无响应寻呼成功率低案例正文：背景从省公司平台提取csfb寻呼失败率较高的top小区。

B2_PL二环路西HLF_H-2小区，寻呼失败次数较多且寻呼无响应次数较多。

问题、任务描述省公司网优平台提取CSFB寻呼指标，该小区为当日top小区，寻呼失败次数较多，且无响应次数较多。

需针对该小区进行分析、优化。

分析与对策1、核查对应小区是否存在干扰或故障，如有先进行排障；无故障。

2、核查CSFB开关、最高优先级异系统等相关参数设置是否合理，包括4G与2、3G异系统互操作参数，确认参数上不会导致跨系统频选；所有参数按省公司要求进行配置，无异常。

3、分析TOP小区地理位置：小区处于tac边界。

4、提取位置更新对端TAC；(部分数据)发现该小区每天位置更新次数多达两千次，5、提取小区TA分布情况。

小区3.5KM以外用户接入较多，该小区存在过覆盖；怀疑该小区过覆盖至13990 TAC内频繁做位置更新，导致寻呼无响应次数较多。

6、提取小区间切换次数；目前OMC网管暂时无法提取小区TAU更新次数与空闲态重选次数。

参考小区间切换次数，判断小区重选间重选是否频繁。

小结：通过以上情况定位分析，由于该小区存在过覆盖至其他TAC内，TAU更新过于频繁，造成寻呼无响应次数较多。

优化方案：1、调整小区间重选偏置。

由0bm调整至3bm,2、调整小区方位角，俯仰角，控制小区覆盖。

处理结果：针对B2_PL二环路西HLF_H-2小区进行方位角与方位角进行调整。

指标优化前后对比：总计与回顾CSFB业务涉及2、4G网络多个网元、节点，且MSC侧寻呼指标最小统计范围为TA，很难定位优化。

近期CSFB服务厂家通过SGs、S1等接口的信息采集可以提供每个小区的寻呼次数及寻呼无响应情况，从而可以针对寻呼响应率低的TOP小区进行分析优化。

VoLTE呼叫失败分析指导书1VoLTE整体构架1.1网元及组网方式华为VoLTE解决方案的典型组网如图1所示。

通过在现有的CS网络上叠加部署IMS网络和LTE网络，提供端到端的QoS保障，为终端用户提供高质量的语音、视频呼叫和更为丰富的数据业务，从而帮助运营商从2G/3G网络逐步演进到LTE网络，完成纯语音到丰富语音的转型。

终端用户可以通过CSFB、Single Radio、Dual Radio等多种LTE终端设备，在LTE网络、2G/3G网络下接入。

当用户移出LTE信号区域时，系统可以将呼叫平滑切换到2G/3G网络。

除此之外，方案中还提供了统一的业务发放、网络管理、计费等功能。

图1华为VoLTE解决方案网络架构运营支撑层运营支撑层主要提供网管、签约数据存放、Web Portal统一操作、计费、设备管理等功能，由EMS、SPG、CCF、DM Server等功能实体组成。

业务层业务层主要由各种不同的应用服务器与资源服务器组成，提供各种业务（如融合Centrex、会议、IP短消息等）及业务能力（传统智能触发，锚定等）。

核心层核心层分为如下3个部分：IMS域、CS域和用户数据库。

1)IMS域各网元主要完成LTE用户注册、鉴权、会话路径控制、业务触发、路由选择、资源控制、域间互通、接入资源控制等功能。

2)CS域各网元主要实现LTE用户在2G/3G网络下的移动性管理和基本语音业务，包括注册、鉴权、锚定、传统智能、切换、CS语音回落等功能。

3)用户数据库按照部署方式，可分为融合HLR/HSS和分离HLR/HSS：a)融合HLR/HSS具有USCDB、HLR、IMS-HSS、SAE-HSS、DNS/ENUM等网络功能实体的功能。

b)当现网不使用融合HLR/HSS时，可采用分离HLR/HSS，支持在现网已存在的HLR、IMS-HSS和SAE-HSS上实现VoLTE业务。

接入层接入层主要实现LTE用户的接入，支持对LTE用户的移动性管理等功能。

关于NB-IoT eDRX时钟问题导致寻呼失败问题案例一、问题描述用户来电反映深圳的NB-IoT网络在eDRX模式下，客户定制的APN下行无法下发。

二、原因分析2.1现场测试分析现场测试，用户所在区域RSRP达到-64dBm，SINR值达到了12dB，如下图所示。

图1 NB-IoT信号测试图从测试数据可以看出，用户所在区域NB信号覆盖良好，上行灌包也正常，因此可以排除无线覆盖类问题。

2.2后台指标分析查询后台服务小区无告警，关键指标正常:图2 服务小区指标2.3信令跟踪分析Uu信令表明用户终端主动发起释放：图3 Uu口信令在Uu口信令跟踪中，用户终端能正常附着网络，但马上主动释放连接，怀疑客户终端或模组问题。

联系用户，用户表示其终端在示波器上一直是有信号的，初步排除客户终端问题，怀疑MME与基站侧的基准时间存在偏差，导致eDRX模式下NB寻呼失败。

2.4时间同步分析eDRX特性对eNB与MME时间同步诉求如图4所示。

图4 eDRX特性时间同步诉求说明：●寻呼消息是MME与UE约定的，到了这个时刻附近UE会启动接收窗口。

其它时间UE处于休眠状态，可以省电●为了减少寻呼消息的缓存时间，MME只在寻呼快到的时刻发寻呼消息（提前1~2秒发送）。

●要求MME、eNB、UE之间时间同步，由于eNB与UE本身是同步的；所以要求MME与eNB之间同步。

●为了满足UE和MME侧对寻呼消息的约定，协议要求MME和eNodeB满足时间同步，同步精度为为1~2秒。

●MME以及eNB侧分别接入各自的时间参考基准，就可以满足eNB和MME的同步。

2.5eDRX参数核查检查现网时间同步配置，情况如下：●eNB侧与MME侧时标对齐，因为eNB和MME会根据各自的时标计算超帧号，如果不对齐超帧号就不一致。

●通用场景里的GPS时标相差闰秒值（比如：以GPS起始，基于1980/1/6号的起始时间，截止2018年闰秒相差18秒，后续每1~2年闰秒会增加1秒，所以每半年需要审视IERS官方网以站发布的闰秒差进行调整。

VoLTE无法寻呼案例分析一、问题现象：在进行VoLTE测试时，在做UE主被叫测试时，发现UE处在idle状态下，无法被寻呼到。

二、问题分析1.基站故障问题：对测试基站进行告警查看，无任何告警，查询历史告警，也无异常。

在该基站下作数据业务，也为发行异常，排除基站故障引起的可能性；2.核心网设置问题：对核心网侧发端进行抓包，确定Paging已经发出。

3.参数设置问题：在基站侧，确定是否收到Paging包。

若收不到，那么，就要排查传输。

若收到，就是eNodeB本身的问题。

4.而确定基站是否收到Paging方法有2种。

可以上前台用Wireshark抓包，也可以后台通过信令确定是否收到Paging消息。

使用后台系统工具-----统一信令跟踪，对Paging进行跟踪。

因此，确定，基站自身收到核心网发来的Paging消息，问题排查，关注基站本身。

三、优化方案1.终端UE收到的寻呼消息中如果带有UE ID列表，终端需要用自己的UE ID来跟寻呼消息中携带的UE ID一一进行匹配，以判断此寻呼消息是否是在呼叫自己。

同时，在寻呼消息中如果所指示Paging ID是S-TMSI，则表示本次寻呼是一个正常的业务呼叫；如果Paging ID是IMSI，则表示本次寻呼是一次异常的呼叫，用于网络侧的错误恢复，此种情况下终端需要重新做一次附着(Attach)过程。

2.从传输信道角度来看，最终由PDSCH下行共享物理信道承载寻呼信息。

在接收寻呼消息之前，终端UE需要先去监听PDCCH物理信道，然后根据PDCCH物理信道上是否有携带P-RNTI，来判断网络在本次寻呼周期是否有发寻呼消息给自己。

3.终端在一个DRX的周期内，可以只在相应的寻呼无线帧(PF)上的寻呼时刻(PO)先去监听PDCCH上是否携带有P—RNTI，进而去判断相应的PDSCH上是否有承载寻呼消息。

如果在PDCCH上携带有P—RNTI，就按照PDCCH上指示的PDSCH的参数去接收PDSCH上的数据；如果终端在PDCCH上未解析出P—RNTI，则无需再去接收PDSCH物理信道，就可以依照DRX周期进入休眠。

WCDMA RNO 寻呼问题分析指导书(仅供内部使用）For internal use onlyHUAWEI华为技术有限公司Huawei Technologies Co., Ltd.版权所有侵权必究All rights reservedWCDMA RNO 寻呼问题分析指导书内部公开WCDMA RNO 寻呼问题分析指导书内部公开目录1概述 (8)2寻呼问题分析过程 (9)2.1 问题分析流程 (9)2.2 网络信息收集 (10)2.2.1 话统 (10)2.2.2 告警 (12)2.2.3 用户投诉 (13)2.2.4 网络规划优化历史记录 (13)2.2.5 无线参数配置 (14)2.3 确定优化目标 (14)2.4 寻呼问题定位 (14)2.4.1 确定基本定位方向 (14)2.4.2 寻呼丢失直接原因 (15)2.4.3 寻呼丢失原因深入分析 (15)2.4.4 其它原因分析 (16)2.5 寻呼问题优化 (16)2.6 优化验证 (16)3寻呼典型问题分析 (16)3.1 寻呼区域规划过大 (16)3.1.1 问题分析 (16)3.1.2 优化措施 (18)3.2 C N寻呼重发次数和时间间隔设置不合理 (18)3.2.1 问题分析 (18)3.2.2 优化措施 (19)3.3 U TRAN寻呼重发次数和时间间隔设置不合理 (19)3.3.1 问题分析 (19)3.3.2 优化措施 (19)3.4 C N使用了全网寻呼 (19)3.4.1 问题分析 (19)3.4.2 优化措施 (19)3.5 D RX寻呼周期系数设置不合理 (20)3.5.1 问题分析 (20)3.5.2 优化措施 (21)3.6 N P值设置不合理 (21)3.6.1 问题分析 (21)3.6.2 优化措施 (21)3.7 C N寻呼使用的UE标识 (22)3.7.1 问题分析 (22)3.7.2 优化措施 (22)3.8 U TRAN应激活IMSI ATTACH和DETACH功能 (22)3.8.1 问题分析 (22)3.8.2 优化措施 (23)3.9 寻呼类信道功率配比过低 (23)3.9.1 问题分析 (23)3.9.2 优化措施 (23)3.10 存在覆盖盲区 (24)3.10.1 问题分析 (24)WCDMA RNO 寻呼问题分析指导书内部公开3.10.2 优化措施 (24)3.11 手机性能问题 (24)3.11.1 问题分析 (24)3.11.2 优化措施 (24)4遗留问题 (24)图目录图1典型UE被叫流程 (9)图2寻呼问题分析流程 (10)图3系统消息1解析 (23)表目录表1 RNC寻呼话统指标 (11)表2 UMSC寻呼话统指标 (12)表3 SGSN寻呼话统指标 (12)表4 用户投诉信息表 (13)表5 CN ID使用IMSI时寻呼区域计算结果表 (17)表6 IMSI ATTACH和DETACH标识 (22)WCDMA RNO 寻呼问题分析指导书内部公开WCDMA RNO 寻呼问题分析指导书关键词：寻呼、寻呼区域、寻呼重发摘要：本文首先阐述了寻呼问题解决的一般流程，然后针对寻呼过程可能会出现的典型问题进行详细分析并给出其优化措施。

关于提高佛山系统寻呼成功率的分析报告一、系统寻呼成功率概述系统寻呼成功率反映了系统寻呼成功响应次数与忙时总寻呼次数的百分比指标。

MS在做被叫时，MSC向同一LAC内的所有小区发送寻呼命令，由各小区在PCH 上发出寻呼消息。

所以在OMCR统计报告中同一LAC内各小区的PAGE_REQ_FROM_MSC应完全相等。

其他过程与移动台主叫类似。

具体的寻呼流程如下：。

二、影响系统寻呼成功率低的主要原因分析影响系统寻呼成功率低的原因主要有两个方面：交换部分和无线部分。

而具体影响到系统成功率的主要因素有：1)无线信号覆盖范围的不连续性导致的寻呼失败问题。

2)参数设置不合理导致的寻呼失败问题，如：寻呼信道配置，寻呼方式（golbal paging or local paging），寻呼等待时长等， T3212、T3113、隐含关机时长等。

3)无线干扰或外界干扰引起的寻呼解码失败导致的寻呼失败，及网络设计规划阶段LAC规划不合理等造成的寻呼成功率低问题。

4)手机不在服务区域及手机注册问题导致的寻呼失败问题。

5)无法寻呼也是一种比较常见的现象。

MSC向BSS发寻呼消息时包含LAC、cell ID，BSS或MSC处的cell ID一定要一致，否则MSC发送的CI BSC无法识别则BSC不做寻呼。

会使得有些cell内的用户一直无法做被叫，但其它的业务正常。

BSS经常接收一些非法的cell ID，会使BSC的负荷大量增加，从而影响正常工作。

三、如何提高寻呼成功率的措施及建议目前佛山系统中我们主要通过结合交换侧及无线侧涉及影响寻呼成功率方面问题的分析及处理来改善和提高系统寻呼成功率指标。

3.1 交换侧问题分析交换优化可以有限的提高寻呼成功率，主要是在寻呼策略方面以及多种数据上的处理，包括对HLR,VLR数据的处理等方法。

以下是佛山系统中交换侧对提高系统寻呼成功率的分析：寻呼信令流程:因此交换部分对提高系统寻呼成功率具体可做的主要工作有：1.通过缩短IMSI_DETACH时长（无线T3212时长相应缩短），使不在服务区的用户尽早被交换机置为关机状态，不向其发起寻呼，提高寻呼成功率。

从正常的呼叫流程来分析手机一次未接通原因一、正常呼叫流程中被叫用户的信令图二、从信令流程的理论上分析一次未接通的原因因为所有一次未接通用户投诉都听到手机回铃音，因此主叫通路已经建立，未接通的原因都是被叫通路建立过程中出现问题而造成的，因此我们主要针对被叫手机信令进行详细分析。

被叫一次未接通都是寻呼无响应造成的，而寻呼无响应就是信令Paging Response没有正常上报，Paging Response没有上报的原因：1、空口Paging消息没有下发。

2、PCH过载，BTS没有下发Paging Request。

3、下行质量差以及空口质量差，MS在空口没有收到BTS下发的Paging Request。

4、空口质量差，MS没有在空口接入SDCCH信道。

5、SDCCH拥塞，MS没有接入SDCCH信道。

6、MS上行质量差，在SDCCH信道建立连接过程中失败。

7、BSC没有下发IMMEDIATE ASSIGN COMMAND消息。

8、BTS没有下发IMMEDIATE ASSIGN COMMAND消息。

9、由于空口原因，MS没有收到BTS下发IMMEDIATE ASSIGN COMMAND。

10、由于空口原因，MS收到BTS下发IMMEDIATE ASSIGN COMMAND没有上报Paging Response。

三、从现场拨测跟踪信令分析一次未接通原因现场我们针对多款手机进行大量的拨打测试，发现无论网络质量如何，都会出现这种一次未接通现象。

只是信号较弱、干扰较大、信道拥塞的情况下，一次未接通现象频繁出现。

我们发现一个共同的规律：所有的一次未接通现象的信令流程中，在A口没有看到Paging Response上报，即是在N侧三次寻呼下发之后，15s超时还没有寻呼到，也就是寻呼无响应或者寻呼响应超时导致。

因此我分析一次未接通主要细分原因就是空口质量、上下行质量、SDCCH拥塞、PCH过载等造成的，还有一部分主要原因是网络覆盖较弱时手机上下行接入参数设者不合理引起的。

GSM网络寻呼成功率的分析及处理GSM网络寻呼成功率是衡量网络性能的重要指标之一、寻呼是指移动设备接收基站发出的呼叫通知，以便及时进行通信。

在GSM网络中，寻呼成功率的高低直接影响到用户通信的质量和体验。

因此，对GSM网络寻呼成功率进行分析和处理是网络优化和改进的重要任务。

1.分析寻呼成功率下降的原因：-基站覆盖不足。

若基站覆盖面积有限，信号弱或遭遇遮挡,可能导致寻呼失败。

-空闲模式间隙配置错误。

空闲模式间隙用于设备在待机状态下的信号接收，配置错误会导致设备未能及时接收到寻呼请求。

-快速寻呼失败。

一些设备响应寻呼请求的时间较长，导致快速寻呼失败率升高。

2.进行寻呼成功率提升的处理方法：-增加基站数量或调整基站位置，提升覆盖范围和信号强度，以确保设备可以及时接收到寻呼请求。

-优化空闲模式间隙配置，减少设备在待机状态下可能发生的寻呼失败情况。

-优化网络参数，根据实际需求调整寻呼超时时间，降低快速寻呼失败率。

-定期进行寻呼成功率的监测和分析，及时发现问题并进行故障排查和修复。

3.寻呼成功率分析的方法：-统计基站的寻呼请求次数和成功次数，计算寻呼成功率。

-对不同地理区域和时段的寻呼成功率进行分布分析，找出存在问题的地区和时间段。

-结合其他关键指标，如载频利用率、话务量等，进行相关性分析，了解寻呼成功率与其他因素的关联程度。

-使用数据挖掘和机器学习算法，对寻呼成功率进行预测和优化。

4.数据分析及处理工具和技术：-使用数据库和数据仓库进行数据存储和管理，以支持大规模数据的分析和查询。

- 数据可视化工具，如Tableau、Power BI等，用于绘制寻呼成功率的趋势图和分布图，方便分析和决策。

- 使用Python、R等编程语言，结合数据分析和机器学习库，进行数据处理和建模。

-使用监测工具和测试设备，对网络信号和寻呼能力进行实时监测和测量。

总之，GSM网络寻呼成功率的分析和处理对于优化网络性能具有重要意义。

通过仔细分析寻呼成功率下降的原因，采取相应的处理方法，结合数据分析和监测工具，可以及时发现和解决网络问题，提升用户通信质量和体验。

CDMA网络呼叫建立失败原因的分析徐丹陈允升马灵中国联通东莞分公司网络运行维护部【摘要】:详细分析了CDMA移动台无线侧呼叫建立的信令流程，呼叫建立失败的原因，并提出相应的解决思路及方法。

【关键词】：呼叫流程相关信令呼叫失败产生原因解决方法1．引言呼叫建立成功率是衡量CDMA移动通信网网络质量的一个重要指标，也是定点质量测试(CQT)和道路测试(DT)结果的重要组成部分，所以呼叫建立的成功与否直接关系到CDMA移动通信网的网络质量。

呼叫建立过程分为语音主叫过程、语音寻呼过程、数据业务主叫过程及短消息业务建立过程，在这些过程中导致呼叫建立失败有多种多样的原因，本文主要阐述语音主叫过程、语音寻呼过程及短消息业务建立过程中的一些信令流程及解决思路，重点分析在无线侧导致呼叫建立失败的原因。

对于语音和数据业务，主叫过程定义为从终端发起起呼消息开始，到终端发送服务连接完成消息为止。

对于短消息业务来讲，又分为短—短消息和长—短消息，具体将会在后文详细阐述。

2．语音主叫过程2.1 主叫流程及相关信令一般语音业务主叫流程如下图表示：图1 语音主叫流程图从图中可以看到，一般语音主叫由若干个信令处理阶段组成。

某一个阶段上如果出现问题都可能会导致主叫失败。

各处理阶段具体含义如下：阶段1：Origination Message On Access Channel终端在上行链路接入信道上发送一个起呼消息请求服务。

阶段2：Base Station ACK On Paging Channel基站在收到终端发出的起呼消息后，在下行寻呼信道上发送响应消息进行确认。

同时，基站会与系统进行一些配置协商，申请系统资源和基站资源。

在所有配置和资源都具备的情况下，基站在前向业务信道开始发送空业务数据帧，方便终端进行捕获。

阶段3：Channel Assignment Message On Paging Channel & Cell Null Traffic Data基站在下行寻呼信道发送信道指配消息，引导终端捕获前向业务信道。