影响GSM网络系统寻呼成功率因素分析及优化措施

影响GSM网络系统寻呼成功率因素分析及优化措施

【摘要】随着用户对网络通信质量的要求也不断提高，运营商纷纷加强对自身服务的改善，其中就包括如何提高寻呼成功率。本文结合笔者多年工作经验，重点就影响GSM网络系统寻呼成功率的因素进行分析，并提出一些有效的优化措施，以期指导实践。

【关键词】GSM网络；寻呼成功率；PCH控制；解决措施

随着移动通信事业的快速发展，我国移动电话普及率的不断提高，网络容量日益增加，运营商对无线网络性能指标的稳定性的要求也有所提高，特别是涉及到用户体验方面的指标，这就迫使运营商要不断优化无线网络以提高网络质量和稳定性。移动通信的网络优化工作十分复杂，它包括无线网络、用户分布、测试评估和频率资源等方面的内容。寻呼成功率作为GSM网络系统中的一项重要质量指标，对来电接通率和无线系统接通率等网络质量指标具有重要的影响，若该项指标偏低，则表示网络系统的接通能力和寻呼能力低下，这也是引起用户投诉的主要原因之一。本文重点就影响GSM网络寻呼成功率的几个重要因素进行分析。

1.影响网络寻呼成功率的因素分析

1.1 网络覆盖效果

覆盖盲区和弱覆盖区是影响网络系统寻呼成功率的一项重要负面因素。一方面，我们可以通过路测或话务统计中测量报告（MR）来发现问题覆盖区域，对于这类区域一般建议规划基站、调整基站天线挂高及俯仰角来增强覆盖。另一方面，网络中可能存在一些参数设置不合理造成的人为问题覆盖区域。可以检查小区主B（主频）的发射功率、小区最小接入电平（ACCMIN）、随机接入错误门限（Rach）等参数，并依据实际情况控制每个基站的覆盖区域，以达到较好的覆盖效果。

1.2 位置区的划分

网络中位置区的划分不易过大和过小。位置区过小，手机频繁移动发生的位置更新次数较多，增加了系统的信令流量；反之，位置区过大，一个用户的寻呼消息会在许多的小区中发送，给PCH信道带来了较大的负荷同时增加了Abis口的信令流量。在进行位置区大小划分时，要充分估算位置区的容量，并考虑节假日、重大活动的冗余量。

位置区的边界区域在规划中也需要重点考虑，禁止将位置区交界划分在人流大的区域。

1.3 寻呼策略的选择

指派成功率和切换成功率专题分析解析

TCH指派成功率（不含切换）的优化 目前，无线系统接通率是联通总部考核的指标之一，从下面的无线系统接通率的公式可以看出，TCH分配成功率对该指标的优劣具有非常重要的影响，同时TCH指派成功率的提升对改善网络的寻呼成功率等指标也是有着积极意义的。 为此，我们专门对TCH指派成功率进行了专题优化。 首先分析TCH指派失败的成因，TCH指派失败的原因主要有五个方面：直接重试（directed retry）过程导致的失败、没有无线资源可用（no radio resource）导致的失败、无线接口故障返回SD（radio interface failure reversion to old channel）导致的失败、无线接口消息错误（radio interface message failure）导致的失败和其它原因（all other cause）导致的失败。其中以没有无线资源可用的原因所占的比例最大。 由上表列出了1月8日到1月25日20：00～21：00TCH指派失败的统计，可以看出，正是由于“没有无线资源可用”的原因导致的TCH指派失败次数主要集中在没有无线资源可用（no radio resource）导致的失败，这是由于TCH拥塞而造成的，而且随着TCH分配失败的次数越来越多，没有无线资源可用（no radio resource）导致的失败所占比例也越来越高，因此，解决TCH拥塞是提高TCH分配成功率的根本方法。缓解TCH拥塞可以通过减扩容

恒大新城12341小区扩容后拥塞情况得以解决，TCH指派成功率上升；

七星路林业大厦14352小区拥塞情况得以解决，TCH指派成功率上升； 高岭收费站18371小区扩容后拥塞情况得到解决，但是30号又出现拥塞，经检查发现 有一块载频TPU:0故障，经过测试恢复工作，若再出现退服则建议及时更换； 安吉路尾18583小区扩容后拥塞情况得以解决，TCH指派成功率上升；

影响寻呼成功率的因素

GSM网寻呼成功率指标的优化方法(2009-04-01 13:50:21) 标签：gsm网寻呼成功率优化指标分类：知识积累 1. 影响寻呼成功率的因素 网元MSC、BSC、BTS、MS，以及网络覆盖、干扰、信道拥塞以及设备硬件等因素都会影响到系统的寻呼成功率，例如： λ硬件故障 λ传输问题 λ参数设置问题 λ干扰问题 λ覆盖问题 λ上下行平衡问题 λ其它原因。 1.1 硬件故障 当出现TRX或合路器故障的情况时，将会造成MS难以相应寻呼，寻呼成功率下降。 1.2 传输问题 由于各种情况导致的Abis接口、A接口链路等传输质量不好，传输链路不稳定，也会导致寻呼成功率上升。 1.3 参数设置问题 BSC侧和MSC侧的一些参数设置会影响寻呼成功率，主要包括： MSC侧寻呼相关参数：

1．N侧位置更新时间（IMSI隐形分离定时器）：2．首次寻呼方式： 3．首次寻呼间隔： 4．二次寻呼方式： 5．二次寻呼间隔： 6．三次寻呼方式： 7．三次寻呼间隔： 8．MSC重发寻呼次数： 9．全网下发寻呼： 10．预寻呼功能： 11．位置更新优化（MSC软参）： 12．呼叫早释功能（MSC软参）： 13．寻呼优化控制（MSC软参）： BSC侧寻呼相关参数： 14．CCCH信道配置： 15．RACH最小接入电平： 16．MS最小接收信号等级 17．基站寻呼重发次数 18．接入允许保留块数

19．相同寻呼间帧数编码 20．MS最大重发次数 21．SDCCH动态分配允许 22．随机接入错误门限 23．T3212(周期性位置更新定时器) 24．RACH忙门限 25．CCCH负荷门限 26．Abis流量控制允许 27．A口协作寻呼开关（软参） 28．寻呼生存周期（软参29） 1.4 干扰问题 当存在网内、网外干扰时，都会影响系统的接入成功率，这样就直接影响到系统寻呼响应，使寻呼成功率下降。 1.5 覆盖问题 可能影响寻呼成功率的覆盖问题： 1．不连续覆盖(盲区) 由于基站所覆盖的区域地形复杂（如山区公路）、地势起伏，无线传播环境复杂，信号受阻挡，覆盖不连续等造成MS无法响应寻呼。 2. 室内覆盖差

GSM无线网络优化流程华为寻呼成功率分析

GSM无线网络优化-STS数据采集分析（华为分册） 四川移动网管中心 技术支持中心 2020年8月16日

2010-07-27版本号：

目录 第1章、寻呼成功率的定义...................... 错误!未定义书签。 1、NSS的定义................................ 错误!未定义书签。 2、BSS的定义................................ 错误!未定义书签。 3、 NSS的寻呼成功率和BSS的寻呼成功率的差异 . 错误!未定义书签。 4、信令流程及统计点.......................... 错误!未定义书签。第2章、BSS侧相关因素分析及提高手段 .......... 错误!未定义书签。 1、BSS侧相关因素............................ 错误!未定义书签。 2、分析流程图................................ 错误!未定义书签。 3、寻呼成功率问题定位及BSS侧提高寻呼成功率的措施错误!未定义 书签。 、硬件和传输上存在问题 ................... 错误!未定义书签。 、寻呼过载和突发性大话务占用SDCCH信道 ... 错误!未定义书签。 、参数配置上的问题....................... 错误!未定义书签。 、干扰问题影响寻呼成功率 ................. 错误!未定义书签。 、覆盖问题影响寻呼成功率 ................. 错误!未定义书签。 、上下行平衡问题影响寻呼成功率 ........... 错误!未定义书签。

3G寻呼量较少网络下寻呼成功率指标较低问题分析专题

3G寻呼量较少网络下寻呼成功率指标较低 问题分析专题

目录 一、背景介绍 (3) 二、故障现象描述 (3) 三、原因分析及定位 (4) 四、处理方法介绍 (12) 五、经验总结 (12) 2 / 122

一、背景介绍 随着全省3G网络建设步伐的加快，各地3G网络覆盖范围快速增加，紧跟建设步伐的网络优化活动也大规模开展。盐城公司在本地的3G网络优化过程中遇到了一些端局下3G寻呼成功率较低问题。例如在NJGS24等2/3G融合端局，在3G无线覆盖水平明显较2G存在较大差距的情况下，从端局话务统计上看，3G网络的寻呼成功率明显偏低，本文就此问题进行了分析。 本专题主要包含如下内容： ◆现象描述 ◆原因分析与定位 ◆处理方法介绍 ◆经验总结 二、故障现象描述 端局接入RNC数据增加后，近日交换侧指标监控发现，建湖NJGS24下一个RNC下挂的5个3G LAC的寻呼成功率较低，最低的甚至为0。相关的统计指标如下。 3 / 123

4 / 124 表1 3月8日晚间寻呼统计表 从上表中，我们可以得出一个规律： 1、Iu 口的第一次寻呼次数低。5个LAC 中只有1个覆盖县城的LAC 的一次寻呼次数达到100次以上，其他乡镇的LAC 一次寻呼次数都在30次一下，甚至有的一个晚忙时只有7次。 2、重复寻呼次数远远高于一次寻呼总次数。 3、一次寻呼次数越多的LAC ，它的寻呼成功率越高。这5个 LAC 中，次数较多的成功率越高，次数越少成功率越低。例如D156,3个时段的成功率在80％以上，其他4个LAC 最高的只有36％，最低的只有0％。 下面是市区一个端局下的3G LAC 寻呼指标统计： 表2 寻呼较多的一个LAC 的成功率统计 从上表可以看出，市区的一个LAC 下的寻呼次数在达到几千次后，一次寻呼成功率的指标明显高于寻呼次数只有几十次的乡镇覆盖区的LAC 。 三、原因分析及定位 分析指标偏低可能出现的原因： ? 核心网和无线侧关于寻呼相关的软参设置不合理； ? 实际寻呼次数与端局话统的数据有误差； ? 无线环境特别恶劣，造成寻呼得不到用户终端的响应； ? 其他可能性，如核心网统计指标点的定义问题等。

LTE基站寻呼拥塞率问题分析处理

LTE基站寻呼拥塞率问题分析处理 【摘要】实际现网由于用户量不多，基站负荷较小，4G网络在当前的业务需求以及寻呼策略下，一般的不太容易出现拥塞。本例中描述的是一起单站信道板（BPL）故障 导致寻呼拥塞，由面到点，再通过后台打印进程内容定位出故障位置。给处理寻 呼拥塞积累了一些分析思路。 【关键字】寻呼拥塞寻呼消息堆积 【故障现象】 在滁州日常KPI指标统计中，发现4月22日的网络的寻呼拥塞率从平时的0.00%突变到0.01%。 图1 滁州整网寻呼拥塞率 【告警信息】 检查告警信息，发现并没有大规模基站故障告警，只有部分零散的新开基站存在告警，但不会导致整网的寻呼拥塞率高。 【原因分析】 寻呼拥塞率KPI分析： 寻呼拥塞率=寻呼记录发送不成功次数/混户籍路应发送次数*100%

主要是指eNB由于资源限制原因导致寻呼消息发送失败的情况。 由于目前现网是网络容量大于需求，正常情况下不会出现寻呼拥塞。从核心网的同事了解到当前的寻呼策略是按照最近一次活动的TA寻呼和TA LIST寻呼相结合的。第一次在最近一次活动的TA下寻呼一次，如果寻呼不到，则在相应的TA LIST 范围内进行寻呼。 表1 LTE网络寻呼的参数设置 导致寻呼拥塞的原因可能有： 无线测配置的寻呼参数配置失当或者网络的TA划分不合理： 检查寻呼参数设置如下：

表2 现网寻呼参数的设置 其中nB和T属于协议参数，别的属于算法参数； 广播的基站所用的寻呼周期（T），在UE使用时还有一个参数，叫做UE的专用寻呼周期，两者取小作为UE的实际使用的寻呼周期。该UE的专用寻呼周期（取值范围与小区寻呼周期的相同）来自于UE 自己上报的NAS消息，在寻呼UE时，由核心网在寻呼消息中通知基站。 2、硬件配置问题： 由面到点，查询全网的寻呼拥塞率指标，发现全部集中在滁州学院宿舍楼室分的8槽位BPL板的4/5/6三个小区，如下图： 图2 滁州学院宿舍楼室分寻呼拥塞率 综上，检查滁州学院宿舍楼的参数配置，可以排除寻呼信道不够用的情况；检查滁州学院宿舍楼室分的TAC规划，网管配置跟规划的一致，同个TAC下只有28个站点，排除TAC规划问题。而且检查滁州学院宿舍楼室分无告警。 进一步在BPL1的产品进程（Product），输入g_pdwRnluFrm 然后再读地址的值，发现系统时间没有变化。系统帧号和子帧号不变，

案例-关于NB-IoT eDRX时钟问题导致寻呼失败问题案例

关于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官方网以站发布的闰秒差进行调整。 ●eNB侧采用频率同步提供业务SFN帧连续偏置，利用NTP计算超帧号；可以确保eNB 侧与MME侧的超帧对齐，超帧整体有10秒，超帧偏差有+/- 5秒，为了满足eDRX

关于寻呼成功率的提高方式

关于寻呼成功率的提高方式 1.位置区更新、小区重选等都会影响PAGING。 https://www.wendangku.net/doc/289161090.html,C划分和LAC区容量分析，合理的设置位置区范围，避免基站LAC插话现象。这样可以减少所有BSC 系统从交换接收寻呼消息的负担，保证在一个LAC区内尽快把所有寻呼消息发出去。 3.手机是否在服务区将直接影响系统所发寻呼消息能否被手机响应，保证手机在服务区则需要网络的覆盖达到一定要求。因此网络的健全程度将从根本上制约无线系统接通率的提高。寻呼成功率反映的是网络的覆盖问题， 4.减少网络干扰（外界干扰、CDMA干扰、一些特殊机关部门的干扰机）； 5.交换追出寻呼无响应多的小区，针对性的解决； 6.通常情况下，网络拥塞是影响无线系统接通率提不上去最大的因素。如果出现信令信道拥塞，就可能造成寻呼消息丢失，直接影响寻呼成功率。 7.处理传输等影响较大的硬件问题（射频单元、CDU、天馈系统等）。小区信号不稳定时，寻呼成功率会相当差。如此，需要尽可能少用微波传输。 8.有时候断站会影响相邻LAC的寻呼成功率的 9.用户的个人行为，比如正在进行短信、彩信的发送等。短信中心的寻呼机制也应关注。我们曾碰到一个案例，由于新建的短信中心的寻呼重发次数与其它短信中心不同，导致全网寻呼成功率大幅下降。 14.如果上下行信号不平衡，可能出现上行或下行信号很差，导致寻呼不到。 寻呼成功率的定义（C4.9）： l寻呼响应次数（C11.3）/ 寻呼请求次数（C11.1）

a MSC判断为1次移动台被呼，向被呼MS当前的服务区域所属的BS发送寻呼请求(Paging Re quest)。并启动定时器T3113。上报1次“寻呼次数”。 b BS在前向寻呼信道上传送寻呼消息（page），寻呼消息中带有移动台地址。 c MS通过接入信道应答Page Res ponse消息。 d BS收到寻呼响应消息后，上报1次“寻呼响应”。BS构造A1口的Paging Response消息，通过完全层3消息发送给MSC，并启动定时器T303。 e BS收到Page Res ponse消息，给MS应答基站证实指令（Base Station A cknowledgment Order ）。 MSC向BS发送指配请求（Assignme nt Re quest）消息，BS调用资源分配接口，分配无线信道的相关无线资源；然后配置业务信道单元。MSC收到寻呼响应消息后，F 停止定时器T3113。这条消息中同时带有MSC指定的地面电路。MSC启动定时器T10。BS收到来自MSC的指配请求（Assignme nt Request）消息后，

寻呼成功率优化

1寻呼成功率优化 1.1概述 寻呼成功率是移动通讯系统中一项基本功能。他直接影响来话接通率和系统接通率等其它网络指标，影响用户的感受。 寻呼成功率由MSC统计，该指标优化提高要通过交换和无线优化共同努力解决。指标定义如下 寻呼成功率：寻呼相应次数/寻呼请求次数×100％ 寻呼响应次数：只MSC收到的PAGING RES消息的总和，包括重复寻呼的响应，统计点为MSC 寻呼请求次数：指MSC首次发送的PAGING消息的总和，统计点为MSC。 1.2寻呼流程简介 寻呼成功率主要涉及到A接口和空口的流程： A1：MSC发来的电路业务请求次数 B1：Abis口电路业务寻呼下发次数 C1：Abis口电路业务寻呼成功次数。

当MSC从VLR中获得MS的LAC后，将向该LAC区域所有BSC发送PAGING消息。BSC收到消息后，向该BSC所属全部小区发送Paging Command。基站收到寻呼命令后，将在无线信道的该IMSI或TMSI所在寻呼组的寻呼子信道上发送Paging Request，该消息携带被寻呼用户的TMSI或IMSI。MS收到Paging Request 后，通过RACH请求分配SDCCH。BSC确认后激活相应的SDCCH信道后，在AGCH信道通过 immediate assignment 将该SD信道指配给MS。MS占用该SD信道成功后，发送Paging Response。BSC将该消息转发给MSC，完成一次寻呼。 1.3寻呼丢失原因分析 1.3.1电路寻呼损失的分析 如下图所示我们根据寻呼的基本信令流程，将寻呼损失分为3部分，再结合现网无线与交换的统计，对无线侧的寻呼损失进行量化分析。（因为MSC与BSC之间，BSC和BTS之间为有线连接，几乎不存在信令在传送过程中的丢失，为了简化分析我们不考虑MSC，BSC和BTS三者之间的信令丢失）。

寻呼成功率信令流程

寻呼原理 当一个位置区下的移动台被寻呼时，MSC就会通过基站控制器(BSC)向这一位置区内的所有BSC发出寻呼消息，BSC收到寻呼消息后，向该BSC下属于此位置区的所有小区发出寻呼命令消息?当基站收到寻呼命令后，将在该寻呼组所属的寻呼子信道上发出寻呼请求消息，该消息中携带有被寻呼用户的IMSI或者TMSI号码。移动台在收到寻呼请求消息后，通过随机接入信道(RACH)请求分配SDCCH。BSC则在确认基站激活了所需的SDCCH 信道后，在接入允许信道(AGCH)通过立即指配命令消息，将该SDCCH指配给移动台。移动台则使用该SDCCH发送寻呼响应(Paging Resp)消息给BSC，BSC将PagingResp消息转发给MSC，完成一次成功的无线寻呼? 如下图1： 寻呼相关指标定义: 从寻呼信令流程中我们得出几个主要可能影响寻呼成功率的对应节点，每个节点所对应的指标计算公式如下：

MSC 寻呼成功率定义： (PAGING_NPAG1RESUCC+PAGING_NPAG2RESUCC)/(PAGING_NPAG1LOTOT+ PAGING_NPAG1GLTOT) LAC寻呼成功率定义： (LOCAREAST_NLAPAG1RESUCC+LOCAREAST_NLAPAG2RESUCC)/ (LOCAREAST_NLAPAG1LOTOT) UM口寻呼成功率定义： sum(RANDOMACC_RAANPAG + RNDACCEXT_ RAAPAG1 + RNDACCEXT_ RAAPAG2) / LOCAREAST_ NLAPAG1LOTOT 随机接入成功率： RANDOMACC_CNROCNT / (RANDOMACC_ RAACCFA +RANDOMACC_CNROCNT) SD建立成功率： CLSDCCH_CMSESTAB /CELTCHFP_ TFCONGPGSM

VoLTE呼叫失败案例分析(华为修订版)

VoLTE呼叫失败案例分析0327 一、被叫未收到Paging消息导致呼叫失败（网格46） 问题描述： Xxx·xxx，被叫未收到寻呼消息（期间未进行过TAU，只有小区重选）导致呼叫建立失败。需要进一步跟踪确认MME是否未下发对应寻呼。 主叫15:09:23.182发起通话请求，对应SIP消息Invite，在随后的15:09:27.829→ 15:12:46.611 一共发起三次呼叫尝试，但MS2均未收到寻呼消息，呼叫超时，通话失败。 主叫上一次正常发起呼叫请求

被叫上一次通话正常收到寻呼消息 Paging消息里核心网分配给被叫的TMSI标识（在图中对ＴＭＳＩ加框）

从xxx到xxx主叫连续3次呼叫失败 3次主叫呼叫期间被叫均处于idle态

Paging消息里没有被叫TMSI标识 从ｘｘｘ到ｘｘｘ时间段内被叫所收到的Paging消息里没有携带被叫TMSI标识 在图中标识出哪些字段是ＴＭＳＩ

二、主被叫魏收到QCI1建立命令导致呼叫未建立（网格61博华 路路段） 问题描述： 主叫发出INVITE消息后，被叫收到对应寻呼并完成RRC连接以及QCI9和QCI5的承载，以及INVITE消息，但主被叫均未收到来自网络侧的QCI1 EPC Bearer建立命令，语音承载未建立，导致呼叫失败。需要核心网侧检查失败原因。 （后续3次通话均因为主被叫未建立专有承载QCI=1导致呼叫失败） 主叫发起通话请求后建立QCI=5和QCI=9但未建立QCI=1 圈出QCI9和QCI5的建立event

被叫收到寻呼请求前建立QCI=5和QCI=9但之后未建立QCI=1 圈出QCI9和QCI5的建立event RRC配置消息里被叫的默认承载QCI=9激活

浅谈提高寻呼成功率的几种方法

浅谈提高寻呼成功率的几种方法 摘要在过去一年中，北京CDMA网络寻呼成功率有了较大幅度攀升。本文详细说明了提高寻呼成功率的几种方法，并介绍了其在北京现网中的实际应用情况。 关键词寻呼成功率CDMA SCI ISPAGING 1．引言 在CDMA网络中，寻呼成功率的公式为“（寻呼成功总次数/寻呼请求总次数）*100%”。其中寻呼请求总次数统计了MSC发出对被叫用户的寻呼消息的次数；寻呼成功总次数统计的是MSC收到被叫用户的寻呼响应消息的次数。 寻呼成功率是关系网络通信质量的一个重要指标，不但衡量了手机是否能够接收到交换机下发的寻呼消息，而且也考察了交换机是否能收到手机上发的寻呼响应消息。 2003年春天，北京CDMA网络的寻呼成功率较低。通过1年多的努力，该项指标上升了将近5个百分点，成果显著。在此，谈谈我们在提高寻呼成功率方面的一些经验和方法，供大家借鉴。 2.方法一：提高网络覆盖率 这是提高寻呼成功率最容易想到的方法。网络覆盖的面积大了，手机移动到无信号地区的概率自然就减小了，其能够成功响应寻呼消息的概率也就增加了。 然而网络不是一天建成的，网络覆盖空洞和弱覆盖地区也不是旦夕间灰飞烟灭的。因此，在实际实施中，这却是花费时间最长，需要长期积累才能看出明显效果的方法。但“不积跬步无以致千里，不积小流无以致江河”。这恰恰是这我们应该长期坚持努力的方向。 2003年是北京CDMA网络的建设年，基站覆盖的广度和深度都有了质的飞越。不论城区还是郊区的覆盖率都大为提升，成为寻呼成功率持续上升的重要保证。其中最为明显的一个例证是2003年年末伴随着地铁站台的全面覆盖，北京C网寻呼成功率迅速攀升了0.5个百分点。 3.方法二：减轻寻呼信道负荷 如图3.1所示，在CDMA系统中，一个80ms的寻呼信道时隙分成4个20ms的子时隙，每个子时隙中仅能容纳最多一条寻呼消息。因此，一个寻呼信道时隙中最多容纳4个寻呼消息。

LTE网络寻呼容量评估

LTE网络寻呼容量评估

目录

1概述 1.1TAC介绍 LTE网络现行寻呼策略为：精准寻呼+普通的寻呼，即UE上次驻留的eNodeB发起寻呼->精准寻呼2S响应超时寻呼下级，最近TAC ->精准寻呼2S响应超时寻呼下级，TAL->精准寻呼2S响应超时重新寻呼， TAL ->寻呼6S超时后重新寻呼，TAL ->寻呼6S超时后寻呼失败。 注：若UE在一个eNodeB下的驻留时间小于2分钟（eNodeB粘性时长），MME将跳过该UE对应的寻呼规则中“最近eNodeB”的寻呼范围，直接跳转到下一级范围（TAC或TA List）进行寻呼。 TAC区作为LTE网络寻呼过程中重要的一环，配置即不能过大也不能过小： 过大：会导致核心侧、无线侧资源消耗过大，引起过载、挤占业务信道资源或需要的配置过高问题。 过小：会导致TAC级寻呼成功率偏低、从而触发过多不心要的TAC List级寻呼，并导致TAC编号资源紧张。 1.2TAC区约束条件 TAC区最大寻呼能力需要考虑以下2方面的约束条件： 1、核心侧MME现网配置条件下的寻呼能力。 2、无线侧寻呼对空口资源占用合理比例下的寻呼能力。 2TAC寻呼能力分析 2.1核心侧MME分析 核心网进行TAC合并的条件是，一个TAL下挂基站数量不超过150，否则在用户数突增情况下可能造成MME侧设备的负荷问题。 TAL下TAC数量减少对核心网设备负荷的影响在5%左右。 统计现网TAL下挂基站数目情况，150个基站以上的TAL数目达到53个，其中衡水最高达到一个TAL下面825个BBU（TAL:18929），部分过大的TAL需要进行分裂后再进行TAC合并。

寻呼失败分析

寻呼失败问题分析 1.概述 在寻呼无响应分析中，通常可以分为以下几个原因： ●位置更新原因：即当发生寻呼时，手机恰巧进行跨局位置更新，导致寻呼失败。 ●呼叫建立冲突：MS在开始建立通话到SDCCH信道分配前的时间段，VLR还未标记MS 状态，系统将寻呼MS，但MS未监听寻呼消息。 ●终端断电：MS非正常关机到MSC/VLR中隐关机计时器超时前的时间内，对该MS的寻 呼，MS无法相应，终端异常操作反映在终端发生寻呼失败后的第一个成功的网络事件是IMSI ATTACH ●弱覆盖或盲区：MS处于弱覆盖或盲区内，造成MS的寻呼无响应。根据后续发生业务 的时间，暂时起名为瞬间弱覆盖（10分钟内）或长期弱覆盖（10分钟后）。 ●其它：手机异常，手机死机，寻呼丢失，基站工作异常等 从G1的寻呼失败错误分布看，其中弱覆盖或盲区的原因，占总寻呼失败的90%以上，因此对弱覆盖的研究是寻呼失败的主要原因之一。 我们认为，引起这种弱覆盖的原因可能有以下两种情况： 1.手机进入弱覆盖区，容易脱网和入网的边界区 2.基站的paging丢失、SDCCH拥塞、AGCH阻塞，导致无法分配到SDCCH信道，无法 上发paging response消息。 前者，受限于现有网络的覆盖状况；后者，设备性能、配置、参数等设置有关。 为了更加精确的了解瞬间弱覆盖小区，我们将时间从10分钟内改为2分钟内，这样统计的结果可能更加接近实际弱覆盖小区。 统计结果如下： 寻呼失败后2分钟内发生新业务的小区排序如下：

寻呼失败后2-5分钟内发生新业务的小区排序如下： 2.数据分析 我们选择17157_1313和17157_6071两个小区为例，分析可能的产生原因。 2.1RMS报告弱覆盖数据分析 17157_1313：园丁花园3 上行弱覆盖（-95dBm以下）的比例为（67179+17380）/2580381= 3.28% 下行：质量电平分布如下：

VoLTE语音呼叫失败的分析思路

《VoLTE小经验》：VoLTE打VoLTE语音呼叫失败的分析思路 1、若主叫VoLTE SBC未收到invite消息时，需检查主叫侧EPC及无线问题。 2、若主叫VoLTE SBC收到invite消息后，未转发至主叫S-CSCF时，则主叫资源预留失败，需检查： 1) 主叫PGW是否开启带宽向上取整功能。 2) 主叫VoLTE SBC发送至主叫PCRF的AAR消息中，是否携带主叫上下行带宽信息、UE的IP地址等。 3) 主叫VoLTE SBC是否收到主叫PCRF的AAA消息和RAR消息（携带UE位置信息）。 4) 主叫L-DRA是否正确转发VoLTE SBC与PCRF之间的信令消息。 3、若主叫计费错误或被叫号码识别错误，需检查主叫VoLTE SBC发送至主叫 S-CSCF消息中，PANI头域是否填写sbc-domain且GCID是否翻译正确。 4、若被叫路由至CS域，需检查： 1) 主叫S-CSCF号码分析局数据配置是否正确。 2) 主叫ENUM/DNS码号数据配置是否正确。 5、若主/被叫业务触发错误（如未触发/重复触发AS等），需检查：

1) 主叫/被叫S-CSCF触发主叫/被叫AS顺序（即SiFC配置）是否正确。 2) 被叫SCCAS收到HSS的T-ADS信息，是否包含IMS Voice over PS Supported。 6、被叫UE回落2G接续，需检查HSS中UE能力是否为支持SRVCC及MME在UE注册过程中是否上报了此能力。 7、若被叫SCC AS收到100trying但未收到183消息至定时器超时，SCC AS在电路域重试导被叫UE回落，需检查CS retry的定时器是否大于EPC寻呼超时定时器。 8、若被叫VoLTE SBC未收到183消息时，需检查被叫侧EPC及无线问题。 9、若被叫VoLTE SBC收到488消息，则编解码信息协商失败，需检查主被叫UE支持编解码信息情况。 10、若被叫VoLTESBC收到183消息后，未转发至被叫S-CSCF时，则被叫资源预留失败，需检查： 1) 被叫PGW是否开启带宽向上取整功能。 2) 被叫VoLTE SBC发送至被叫PCRF的AAR消息中，是否携带被叫上下行带宽信息、UE的IP地址等。 3) 被叫VoLTE SBC是否收到被叫PCRF的AAA消息和RAR消息（携带UE位置信息）。 4) 被叫L-DRA是否正确转发VoLTESBC与PCRF之间的信令消息。 11、若被叫位置信息获取失败，需检查被叫VoLTE SBC发送至被叫S-CSCF消息中，PANI 头域是否填写sbc-domain。

寻呼成功率优化指导

寻呼成功率优化指导 1 寻呼成功率的计算方法 2006年，联通将寻呼成功率纳入考核指标，88%达标，94%满分。寻呼 成功率的计算方法如下： 寻呼成功率＝寻呼响应次数/寻呼请求次数*100% 其中，寻呼响应次数定义：本地区所有MSC收到的PAGING RES消息的响 应总和，包括二次寻呼响应。统计点为MSC。 寻呼请求次数定义：本地区所有MSC发出的PAGING消息的总和，不包括 二次寻呼的消息。统计点为MSC。 2 影响寻呼成功率的因素 寻呼成功率是一个系统级的问题，涉及MSC、BSC、BTS、MS以及网 络的覆盖情况等。影响MSC寻呼成功率的因素主要有： 1、基站覆盖情况； 2、MSC的寻呼策略； 3、信令信道是否拥塞； 4、位置区划分的合理性、上下行平衡情况； 5、寻呼相关参数设置。如：上下行接入门限参数、周期位置时间（T3212） 等。 3 BSS侧提高寻呼成功率的措施 3.1 开启BTS寻呼重发功能 为了提高寻呼成功率和寻呼效率，基站侧增加了寻呼重发功能，这样可 以解决一些由于偶尔的无线链路传输质量差而造成的移动台暂时无法正 确接收寻呼命令问题，而对于持续的无线链路传输质量差而造成的移动 台暂时无法正确接收寻呼命令问题继续依赖于MSC侧的寻呼重发来解 决。另外，由于基站侧实现了寻呼重发，减少了MSC侧寻呼重发量，一 定程度上降低了整个网络侧的信令负载。

修改参数“寻呼次数”（小区属性表）开启BTS寻呼重发功能（建议设 置为4次）。 参数“寻呼次数”含义：在BTS2X基站中本参数用于BTS决定寻呼重 发，它与MSC内配置的寻呼次数共同控制寻呼的重发次数，总共的寻呼 次数近似为两者相乘值。华为BSC没有重发机制，收到一条寻呼消息处 理一条寻呼消息。华为BTS支持寻呼重发机制。 3.2 合理设置MSC周期位置更新时间 适当减小MSC周期位置更新时间，且设置BSC的周期位置更新定时器 T3212稍小于MSC周期位置更新时间（建议将BSC的周期性位置更新 时间值设置比MSC周期性位置更新时间小5～10分钟），有利于寻呼成 功率的提高。当MSC 附着分离定时器（Detach Timer）超时后，VLR 将把处于覆盖盲区或关机的手机设置为隐性关机，此时MSC也不会下发 寻呼。 在保证不发生信令过载的条件下，适当减小BSC、MSC周期位置更新时 间。 注意：同一位置区下不同BSC的周期位置更新时间设置为一致，并且 BSC的周期位置更新时间小于MSC的周期位置更新时间。 3.3 适当降低“RACH最小接入电平” 参数“RACH最小接入电平”（小区属性表）设置越小，对提高寻呼成 功率越有利。参数“RACH最小接入电平”最小可以设置为0（表示对上 行接入电平不限制）。由于影响寻呼成功率和掉话率的网优参数是互相 制约的，通过降低“RACH 最小接入电平”可以提高寻呼成功率，但会 造成掉话率增加。 3.4 适当降低“MS最小接收信号等级” 参数“MS最小接收信号等级”表示MS接入系统所需要的最小接收信号 电平，缺省值为8。为了提高寻呼成功率，可以适当降低该参数。该参数 设置过低同样会导致掉话增加，需要采取优化掉话的措施。 3.5 适当增大“MS最大重发次数” 参数“MS最大重发次数”（系统消息数据表）表示MS在同一次立即指 配进程中允许发送Channel Request消息次数的上限。参数设置值越大， 试呼的成功率越高，接通率越高，但同时RACH信道的负荷也越大。 参数“MS最大重发次数”缺省值为4次，为了提高“寻呼成功率”，可 以设置该参数为7次，但要密切关注RACH信道的负荷。

中国联通LTECSFB失败原因分析201811

CSFB失败原因与信令特征对应表

目录 1概述 (4) 1.1前言 (4) 2失败类型：CSFB主叫失败 (4) 2.1失败原因：终端回落到了弱覆盖的2G小区,终端在2G的接续过程中掉话 (4) A接口： (6) 3失败类型：CSFB被叫失败 (7) 3.1失败原因：用户处在2个TA重叠的覆盖范围, 经常在两个TA之间来回重选， 做被叫时正在重选过程中导致的CSFB被叫时失败 (7) 3.2失败原因：未部署MTRF功能情况下 UE跨MSC Pool回落，导致的CSFB被叫失 败7 3.3失败原因：诺西ENodeB的CSFB功能未打开，导致的CSFB被叫失败 (8) 3.4失败原因：阿朗ENodeB的CSFB LICENSE功能未打开，导致的CSFB被叫失败。 9 3.5失败原因：诺西MME软件缺陷，当用户正在进行X2切换时，MME并没有等待该 切换完成后重新下发Paging消息，最终导致寻呼未正常下发.诺西计划在14年6月的NS31中解决。 (11) 3.6失败原因：手机终端设置黑名单或来电防火墙引起CSFB被叫失败 (12) 3.7失败原因：回落2G后发生LAC改变,改变后的LAC所属BSC(华为）的GSM小区 未开启CSFB功能，导致主叫失败 (13) 3.8失败原因：阿朗ENODEB采用BitMap方式下发GSM回落频点导致CSFB接通失败 15 3.9失败原因： .回落邻区漏配、少配或者优先级不当引起回落失败 (16) 3.10失败原因：诺西MME的BUG造成7108D等单卡双待手机存在联合附着. 引起 双待手机被叫失败 (17) 3.11失败原因： ENODEB将ESR(TAU)错误分发至另外一个SGSN，引起被叫无法接 续（大唐、中兴ENDOBE) (17) 3.12失败原因：伪基站干扰，CSFB手机做被叫时回落至伪基站，造成被叫失败19 3.13失败原因： 4G网络弱覆盖寻呼无响应造成被叫失败。 (20) 3.14失败原因： 4G网络SINR值差，导致iPhone手机终端无法收到Paing消息造 成被叫失败。 (21) 3.15失败原因：华为MME流程冲突导致的CSFB被叫失败 (23) 4失败类型：CSFB呼叫时延过大........... 错误！未定义书签。 4.1失败原因：用户在主叫回落前和回落后所处的TAC/LAC不一致，导致回落后先 发起位置更新，再进行主被叫流程,造成时延增加两秒左右。 ....... 错误！未定义书签。5失败类型：其他....................... 错误！未定义书签。

寻呼不可及优化经验总结

寻呼不可及优化策略： 第一、针对6个寻呼成功率最差的LAC（22964,2967,24662，24767,24776,24780）进行核心网参数优化，寻呼成功率低于90%且AT=0的将AT调整为1；3、首次寻呼成功率低于80%且INT=300的将INT调整为350。参数优化后这6个LAC的寻呼成功率得到较大提升，都在94%以上。提升都在5个百分点以上。 第二、H YS参数优化。针对泉州TOP500寻呼不可及小区中的LAC边界373个，包括其邻小区进行HYS参数优化。通过 指标统计，优化小区寻呼不可及次数约能改善1%。； 第三、对LAC边界且存在过覆盖小区进行覆盖整治，目前完成对3个小区的过覆盖整治，整治后其寻呼不可及次数下降明 显，约能压降5%以上。 第四、针对高干扰的26个小区的RET参数有原来的4优化为7，通过对比优化前后日均寻呼不可及次数，整体有所下降。 由优化前的平均116次压降为优化后的71次，整体日均约 减少45次。 第五、另外通过优化小区重选参数REO、TEO参数，采取限制小区（较高寻呼不可及）的边缘用户驻留的策略，达到压降 寻呼不可及次数的目的；另外通过优化SD及TCH拥塞小 区，解决由于无线资源原因导致的寻呼不可及问题；再者 就是通过对寻呼容量受限小区（存在寻呼删除小区）进行 扩展CCCH开启，或增加扩展CCCH个数，达到提升寻呼

成功率，压降寻呼不可及次数的目的。 现阶段寻呼不可及优化成功： ◆全网寻呼失败率：全网寻呼失败率由8月份的0.3%，压降到9 月份（目前）的0.22%，整体压降幅度为-28.6%； ◆TOP1000寻呼失败率：TOP1000寻呼失败率由8月份的1.22%， 压降到9月份（目前）的1.08%，整体压降幅度为-11.4%；

寻呼成功率指导书

1. 寻呼成功率的背景及定义 2. CN侧影响因素分析及提高手段 3. B侧相关因素分析及提高手段 4. 案例分析应用 寻呼成功率指导书

第一章寻呼成功率的背景及定义 背景 无线寻呼成功率取自所有的端局(VMSC)，移动用户做被叫或接收短消息过程中端局(VMSC)向所属用户发起寻呼情况的统计，即寻呼成功之和与寻呼尝试之和的百分比。 寻呼成功率考核各地无线覆盖情况、网络运行维护优化的质量等。这项指标的高低反映网络的覆盖规模，网络覆盖本质上是无线的问题，应归于基站的密度、发射接收功率的设置等。 通常，每期工程的顺利完成寻呼成功率就会有所提高，而且这个提高幅度同工程的规模成正比。网络优化的目的是尽可能使得寻呼成功率达到工程设计应该达到的水平。那么这项反映网络覆盖的指标如何优化呢？BSS当然是这项指标的理想跟踪对象，可以将大的系统指标分解到各个小区来定点分析，通过对各个小区或基站的障碍清除、参数调整、高度调整及俯仰角变换等等手段来达到无线的最佳覆盖，从而优化寻呼成功率。其次在NSS一边也有一些优化手段可以提高这项指标。本文主要讲述NSS侧的一些优化手段。 寻呼流程

定义 系统寻呼成功率=寻呼响应次数/寻呼请求次数*100% 寻呼响应次数 指本地区所有MSC收到的PAGING RES消息的响应总和。包括重复寻呼的响应。统计点为MSC。 寻呼请求次数

定义:指本地区所有MSC发出的首次PAGING消息（不包括重复寻呼）的总和，统计点为MSC。 语音寻呼成功率=语音寻呼响应次数/语音寻呼请求次数 话统指标 目前版本的实现，对于寻呼方面的统计有四个测量指标： MSC基本表测量 寻呼过程测量 MTC呼通率测量 位置区话务测量 话统公式：系统寻呼成功率以MSC基本表测量的寻呼响应次数和寻呼次数的比率为准。 <备注> B侧的寻呼成功率指标是以BSC为单元进行测量，而N侧的寻呼成功率指标分为两种：一是以MSC为单元进行测量；二是以位置区为单元进行测量。

低寻呼成功率的LAC的分析

长春本周最差LAC统计、分析 4天最差LAC统计过滤出7个寻呼成功率低LAC，通过对低寻呼LAC下的BSC、小区及相应参数进行统计分析，无法从无线侧发现LAC 寻呼成功率低的原因。建议交换侧配合分析具体Paging失败的原因。 1. 对《长春本周最差LAC统计.rar》进行统计分析，附件中只有7个低寻呼成功率低的LAC。详见下表： 从上表可以看出，低寻呼成功率的LAC并不是每个时段都出现，也不是每个时段寻呼成功率都低于90%。其中17181出现时段最多为64次，但其寻呼成功率平均值都在91.96之上。 2．在《长春本周最差LAC统计》中LAC17181最差时段出现在13日2时和15日18时，寻呼成功率都为89.77%；另一个LAC17165在14日3时和15日2时寻呼成功率为87.03%和89.66%。低于90%的也只有这两LAC，共计出现4个时段。 对LAC17181和LAC17165中的BSC的指标进行查看，其出现低寻呼的时段BSC各项指标均正常，同时对其他各个LAC最差时段BSC 进行统计，指标正常。详见下表：

3. 对11月1日到14日网络指标进行统计、分析，干扰、切换成功率、掉话、拥塞、上行干扰比例、无线利用率等指标均正常，见下表：

从上表可以看出，网络各项指标对比历史没有明显波动及变化。其具体指标详见附件参考附件《每日网络指标汇总》。 4. 没有对bs_ag_blks_res、bs_pa_mfrms、T3212和CRH等参数没有进行参数调整。 综上所述，各个LAC下BSC及小区指标均正常，与历史指标对比后没有发现明显变化，同时各项参数也没有进行调整，无法从无线侧发现LAC寻呼成功率低的原因。建议交换侧配合分析具体Paging失败的原因，对于无线类的，网优中心进行进一步分析。

CSFB失败原因与信令分析指导书

CSFB失败原因与信令特征对应表 版本号：V1.0 中国移动通信集团公司网络部监控处 2014年6月

目录 1概述 (4) 1.1前言 (4) 2失败类型：CSFB主叫失败 (4) 2.1失败原因：终端回落到了弱覆盖的2G小区,终端在2G的接续过程中掉话 (4) A接口： (6) 3失败类型：CSFB被叫失败 (7) 3.1失败原因：用户处在2个TA重叠的覆盖范围, 经常在两个TA之间来回重选， 做被叫时正在重选过程中导致的CSFB被叫时失败 (7) 3.2失败原因：未部署MTRF功能情况下 UE跨MSC Pool回落，导致的CSFB被叫失 败7 3.3失败原因：诺西ENodeB的CSFB功能未打开，导致的CSFB被叫失败 (8) 3.4失败原因：阿朗ENodeB的CSFB LICENSE功能未打开，导致的CSFB被叫失败。 9 3.5失败原因：诺西MME软件缺陷，当用户正在进行X2切换时，MME并没有等待该 切换完成后重新下发Paging消息，最终导致寻呼未正常下发.诺西计划在14年6月的NS31中解决。 (11) 3.6失败原因：手机终端设置黑名单或来电防火墙引起CSFB被叫失败 (12) 3.7失败原因：回落2G后发生LAC改变,改变后的LAC所属BSC(华为）的GSM小区 未开启CSFB功能，导致主叫失败 (13) 3.8失败原因：阿朗ENODEB采用BitMap方式下发GSM回落频点导致CSFB接通失败 15 3.9失败原因： .回落邻区漏配、少配或者优先级不当引起回落失败 (16) 3.10失败原因：诺西MME的BUG造成7108D等单卡双待手机存在联合附着. 引起 双待手机被叫失败 (17) 3.11失败原因： ENODEB将ESR(TAU)错误分发至另外一个SGSN，引起被叫无法接 续（大唐、中兴ENDOBE) (17) 3.12失败原因：伪基站干扰，CSFB手机做被叫时回落至伪基站，造成被叫失败 19 3.13失败原因： 4G网络弱覆盖寻呼无响应造成被叫失败。 (20) 3.14失败原因： 4G网络SINR值差，导致iPhone手机终端无法收到Paing消息造 成被叫失败。 (21) 3.15失败原因：华为MME流程冲突导致的CSFB被叫失败 (23) 4失败类型：CSFB呼叫时延过大 (24) 4.1失败原因：用户在主叫回落前和回落后所处的TAC/LAC不一致，导致回落后先 发起位置更新，再进行主被叫流程,造成时延增加两秒左右。 (24) 5失败类型：其他 (26)