15 W网规高培-寻呼问题分析
寻呼成功率优化分析
摘要:寻呼成功率是GSM网络的一项重要质量指标。
本文介绍了寻呼流程并细致地分析了实际工作中提高寻呼成功率的优化方法。
关键词:寻呼成功率 GSM 优化1 引言网络优化是目前移动运营商的一项重要工作，寻呼成功率是GSM网络的重要网络质量指标，它直接影响来话接通率和系统接通率等其它网络指标。
良好的寻呼性能对于所有手机用户是否能够成功作被叫来说十分关键，因此加强寻呼成功率的优化分析是非常必要的。
2 寻呼流程和寻呼成功率2.1 寻呼流程在GSM规范08.08描述了A接口的流程，在GSM规范04.08描述了空中接口的流程。
寻呼流程要涉及到A接口和空中接口的流程。
图1 寻呼在A接口和空中接口的流程当MSC从VLR中获得移动台MS当前所处的位置区（LAC）后，将向这一位置区的所有BSC发出寻呼消息（Paging）。
BSC收到寻呼消息后，向该BSC下属于此位置区的所有小区发出寻呼命令消息（Paging Command）。
当基站收到寻呼命令后，将在无线信道的该IMSI所在寻呼组的寻呼子信道上发出寻呼请求消息（Paging Request），该消息中携带有被寻呼用户的IMSI或者TMSI号码。
MS 在接收到寻呼请求消息后，通过随机接入信道（RACH）请求分配独立控制信道（SDCCH）。
BSC则在确认基站激活了所需的SDCCH信道后，在接入许可信道（AGCH）通过立即指配消息（Immediate Assignment）将该SDCCH信道指配给MS。
MS则使用该SDCCH信道发送寻呼响应消息（Paging Response）。
BSC将寻呼响应消息转发给MSC，完成一次成功的无线寻呼。
2.2 寻呼方式设置现在GSM网络上交换机的寻呼方式一般为二次寻呼，寻呼间隔一般为5秒。
当MSC从VLR中获得MS目前所处的位置区LAC后，第一次向MS所在的LAC下的所有BSC寻呼。
如果MSC在发出寻呼消息后，5秒内没有收到寻呼响应消息，MSC 则会再发送一次寻呼消息。
华为WCDMA高培——寻呼问题分析
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 寻呼问题分析指导书关键词：寻呼、寻呼区域、寻呼重发摘要：本文首先阐述了寻呼问题解决的一般流程，然后针对寻呼过程可能会出现的典型问题进行详细分析并给出其优化措施。
影响移动网络寻呼成功率的因素及对策探讨
【 关键词 】 移动 网络 ； 寻呼成功率 ； 因素 ； 对策 【 中图分类号 】 Ｔ Ｎ ９ ２ ９ ． ５ 【 文献标 识码 】 Ｂ 【 文章编 号 】 １ ０ ０ ６ — ４ ２ ２ ２ （ ２ ０ １ ４ ） ０ ２ — ０ ０ ０ ６ — ０ ２
１ 相 关概念
１ ． １ 寻 呼
（ １ ） 含义： 在 ＭＳ Ｃ尚未分域 ， 短信 息终 呼 、 Ｃ ／ ＲＮＣ发 送 信 息 的 次 数 ． 以 及 成 功 接 收 到
ＵＥ ， ＭＳ信 息 的 次 数
发 送 给 所在 位 置 区 小 区 。 在 收到 寻呼 命 令 之 后 ， 基 站 将 在 寻 呼
向Ｒ Ｎ Ｃ ／ Ｂ Ｓ Ｃ发 送 消 息 ． 以及 收 到 Ｕ Ｅ ／ ＭＳ的 消 息 之 时统 计 到
未知 区的 测 量 项 中
２ ． ２ ． ２ 二 次 寻 呼 的请 求 次 数
道并请求进行 Ｓ Ｄ Ｃ Ｃ Ｈ 的 分 配 。在 确 认 基 站 已 经将 Ｓ Ｄ Ｃ Ｃ Ｈ 信
道 激 活之 后 ， Ｂ Ｓ Ｃ再 行 接入 许 可信 道 ， 并将 Ｓ Ｄ Ｃ Ｃ Ｈ 立 即 支 配给
信息． 而 重新 发送 信 息 的 次数 。
通常情况下 ， 假如 在 Ｍ Ｓ Ｃ发 出 Ｔ ＭＳ Ｉ 信号后 的 ４ — ６ ｓ 之内
并 未收 到 响 应 消 息 ． 那 么 ＭＳ Ｃ便 会 再 一 次发 送 Ｉ ＭＳ Ｉ 信 ， 假 如 再 次 未收 到 响 应 消息 。那 么此 次寻 呼便 可 宣告 失 败 。 与 此 同 时， ＭＳ Ｃ将 告 知 主 叫 用 户此 次通 话 未能 接 通 。
移 动 台 而移 动 台则 通过 Ｓ Ｄ ＣＣ Ｈ 将 寻 呼相 应 消 息发 送 给 ＢＳ Ｃ． 然 后再 由 Ｂ Ｓ Ｃ把 消息 发 送给 ＭＳ Ｃ， 从 而使 无线 寻 呼得 以完 成 。
GSM网络寻呼成功率的分析及处理
GSM网络寻呼成功率的分析及处理GSM网络寻呼成功率是衡量网络性能的重要指标之一、寻呼是指移动设备接收基站发出的呼叫通知，以便及时进行通信。
在GSM网络中，寻呼成功率的高低直接影响到用户通信的质量和体验。
因此，对GSM网络寻呼成功率进行分析和处理是网络优化和改进的重要任务。
1.分析寻呼成功率下降的原因：-基站覆盖不足。
若基站覆盖面积有限，信号弱或遭遇遮挡,可能导致寻呼失败。
-空闲模式间隙配置错误。
空闲模式间隙用于设备在待机状态下的信号接收，配置错误会导致设备未能及时接收到寻呼请求。
-快速寻呼失败。
一些设备响应寻呼请求的时间较长，导致快速寻呼失败率升高。
2.进行寻呼成功率提升的处理方法：-增加基站数量或调整基站位置，提升覆盖范围和信号强度，以确保设备可以及时接收到寻呼请求。
-优化空闲模式间隙配置，减少设备在待机状态下可能发生的寻呼失败情况。
-优化网络参数，根据实际需求调整寻呼超时时间，降低快速寻呼失败率。
-定期进行寻呼成功率的监测和分析，及时发现问题并进行故障排查和修复。
3.寻呼成功率分析的方法：-统计基站的寻呼请求次数和成功次数，计算寻呼成功率。
-对不同地理区域和时段的寻呼成功率进行分布分析，找出存在问题的地区和时间段。
-结合其他关键指标，如载频利用率、话务量等，进行相关性分析，了解寻呼成功率与其他因素的关联程度。
-使用数据挖掘和机器学习算法，对寻呼成功率进行预测和优化。
4.数据分析及处理工具和技术：-使用数据库和数据仓库进行数据存储和管理，以支持大规模数据的分析和查询。
- 数据可视化工具，如Tableau、Power BI等，用于绘制寻呼成功率的趋势图和分布图，方便分析和决策。
- 使用Python、R等编程语言，结合数据分析和机器学习库，进行数据处理和建模。
-使用监测工具和测试设备，对网络信号和寻呼能力进行实时监测和测量。
总之，GSM网络寻呼成功率的分析和处理对于优化网络性能具有重要意义。
通过仔细分析寻呼成功率下降的原因，采取相应的处理方法，结合数据分析和监测工具，可以及时发现和解决网络问题，提升用户通信质量和体验。
寻呼信道高负荷解决方 案及边界规划
市区单载频小区寻呼负荷高解决方案一、概述随着石家庄CDMA业务的蓬勃发展，我网部分基站出现了寻呼信道负荷率较高的问题，经统计分析，这些基站除个别为县城话务量过高造成外，其它站点几乎全部为市区与县区接壤处BSC14、15的单载频小区，此问题的产生，与话务负荷和网络结构有直接的关系。
现在我公司CDMA网络共有两个三星BSC和5个中兴BSC，其中三星两个BSC覆盖西部山区，中兴BSC13、14、15主要覆盖三环以内的市区，BSC11、12覆盖县区，BSC13的所有基站位于市区中心，由于市区话务量较大，BSC13基站的1X载频全部为3载波，BSC14、15大部分基站的1X载频也为3载波，尚有32个基站90个小区仍为单载波（见附表一）。
由于BSC13、14、15属于同一LAC区，寻呼消息在同一LAC区内同时下发，而单载波基站只有一个寻呼信道，从而造成BSC14、15的单载波基站寻呼负荷较高，（详见附表二）。
这种情况下，如果遇到突发事件如大型集会或春节等大型节日，将造成寻呼负荷过高从而导致大量的寻呼失败，用户感知度的下降，所以目前的单载频配置已无法满足日益增长的话务需求，需进行解决。
BSC14-15扩容小区.xlsx 寻呼信道利用率.xlsx表一表二解决寻呼负荷偏高问题一般有两种方式一是重新规划LAC区，二是对单载频基站进行载频扩容。
二、解决方案：1、LAC区重新规划：现网LAC分布如下：其中，黄色区域为BSC13、14、15覆盖的三环以内区载LAC0，绿色区域为BSC11覆盖的LAC770，蓝色区域为BSC12覆盖的LAC771。
重新划分LAC区，一般需保证同一BSC在同一LAC区，这样在不进行大的网络割接前提下，只能将BSC13、14、15中的一个划分为一个单独的LAC区，而BSC13基站处于市区中心，无论将哪个BSC独立做这一个LAC，都会使得LAC边界处在人、车流量很大市区内（如下图2），这样会对接入信道造成极大压力，虽解决了寻呼信道忙，却带来了LAC边界接入信道负荷更为严重的问题，并会造成处于LAC边界的用户无法接通现象明显上升，所以此方案虽然没什么投资，但对网络质量影响较大，不宜采用。
寻呼成功率的分析及优化v4
••••••••••••••••网络寻呼成功率的分析及优化2007.08诺基亚西门子网络温州移动项目组郑竣吉 & 刘燕杰浙江温州移动GSM无线网络优化咨询服务•目录1.概述 __________________________________________________________________________________ 32.寻呼的基本信令流程_____________________________________________________________________ 33.影响寻呼成功率的因素____________________________________________________________________ 4 3.1位置区域规划___________________________________________________________________________ 4 3.2网络寻呼策略___________________________________________________________________________ 5 3.2.1呼叫重传_________________________________________________________________________ 5 3.2.2减少不必要的寻呼_________________________________________________________________ 6 3.2.3现网PER参数设置建议 _____________________________________________________________ 7 3.2.4MS进行位置更新同时作MTC ________________________________________________________ 7 3.3寻呼容量受限___________________________________________________________________________ 8 3.3.1信道配置_________________________________________________________________________ 8 3.3.2寻呼块结构_______________________________________________________________________ 9 3.3.3寻呼组_________________________________________________________________________ 10 3.3.4寻呼的排队及抛弃________________________________________________________________ 11 3.3.5现网寻呼最大容量计算 _____________________________________________________________ 11 3.4SDCCH信道指配失败及拥塞______________________________________________________________ 13 3.5网元负荷导致__________________________________________________________________________ 13 3.6无线覆盖质量导致 ______________________________________________________________________ 143.7移动用户因素__________________________________________________________________________ 144.结束语 _______________________________________________________________________________ 145.附件 _________________________________________________________________________________ 15 5.1MSC寻呼参数设置_____________________________________________________________________ 15 5.2BSC寻呼相关参数统计 __________________________________________________________________ 151. 概述致力于提高网络质量，从而保持用户的忠诚度和争取更高的市场份额是中国移动目前面临的重要课题。
寻呼区边界不合理引起接入超时信令分析及解决方案
寻呼区边界引起接入超时信令分析及解决方案一、问题背景4月8日接到用户反映在电信枢纽大楼附楼使用C网手机是，接续时间太长。
二、主要做法测试分析1、测试网优中心组织测试人员到现场测试，共进行了23次拨打测试，测试情况如下表：2呼叫时长定义为主叫起呼到被叫振铃的时间，经过这几次拨打，我们发现该区域确实存在呼叫建立时间太长的现象（红色背景处），最长的一次呼叫时长为15.468s，这么长的呼叫接续时间，一般用户很难接受，用户感知相当差。
是什么原因造成接续时间超长？与以往的小灵通网优相比，CDMA网络优化有相当多的手段与工具，从何入手是很多同志共同的疑问，我们认为，无线网优最根本的还是空中无线接口，还是信令消息。
主叫信令流程如下：无线侧主叫接入成功的标志是service connection completion message。
我们取第15测试分析，此次为入呼叫时延最长的一次，找到10:46:08.108的主叫信令如下：从主叫信令上看，主叫发起呼叫origination message到服务建立完成service connect completion message ，共用了 1.36s，主叫侧接入正常。
手机占用的扇区为电信枢纽室内分布第2扇区，PN180。
再看看被叫的情况，被叫信令流程如下：除了BSC发起page message，手机接收到寻呼消息后，发起page response message外，其他过程与主叫类似。
现场接收到的信令如下：可见被叫没有发起page response message（寻呼响应消息），既然如此，那么当时被叫因为什么没有响应寻呼呢？现场信令的红色字体消息给出了答案，手机正在做registration——登记！当手机在做登记时，网络是寻呼不到的！于是下一个问题接踵而来，当时测试地点在室内，并没有移动，也没有开关机，为什么手机会发起登记消息？查看registration message消息具体内容，我们发现发起的登记为基于区域登记（zone-based registration）。
GSM网络寻呼成功率的分析及处理
GSM网络寻呼成功率的分析及处理概述GSM（Global System for Mobile Communications）是一种数字移动通信技术，被广泛应用于手机、智能终端等通信设备。
在GSM网络中，寻呼是指基站通过广播方式向移动设备发送寻呼信息，以实现呼叫转接、短信发送等功能。
而寻呼成功率则是指在一次寻呼过程中，移动设备正确响应寻呼信息的概率。
GSM网络寻呼成功率是评价移动通信服务质量的重要指标之一。
在实际应用中，由于移动设备接收能力、网络状态等因素的影响，寻呼成功率有一定的波动性。
因此，对寻呼成功率进行分析和处理，可以帮助网络运营商优化网络结构、提高服务质量。
本文将结合实际数据，介绍GSM网络寻呼成功率的分析方法和处理手段。
数据收集要进行GSM网络寻呼成功率的分析，首先需要收集一定量的数据。
通常，网络运营商会在系统中记录每个基站的寻呼成功率信息。
这些信息可以通过下列步骤获取到：1.登录系统管理平台，找到“基站性能统计”模块；2.选择寻呼成功率指标，设置基站列表和时间范围；3.下载导出数据，保存为Excel表格或CSV格式。
为了更好地理解GSM网络寻呼成功率的趋势和波动，我们需要将数据进行可视化处理。
下面是一些常见的数据可视化工具：•Microsoft Excel： Excel是一个强大的数据分析工具，可以对数据进行图表展示或数据透视表分析。
•PowerBI： PowerBI是微软开发的数据可视化工具，提供了丰富的可视化图表和数据分析功能，支持多种数据源。
•Tableau： Tableau是一款流行的商业智能工具，通过简单拖拽的方式可以轻松创建交互式图表和仪表盘。
数据分析对于GSM网络寻呼成功率，我们可以从多个角度进行分析，例如：1.寻呼成功率的趋势寻呼成功率的趋势是揭示网络性能变化的重要指标。
通过对寻呼成功率历史数据的分析，我们可以了解该网络在时间轴上的变化趋势、周期性波动和长期趋势等信息。
寻呼成功率的分析和优化小结
寻呼成功率的分析和优化小结一、概述 (1)二、寻呼容量 (2)三、TRH的容量 (3)四、SDCCH相关的分析 (4)五、EOS分析 (5)六、MRR分析和TEST SYSTEM追踪 (5)七、无线参数的分析和优化 (7)八、交换参数的分析和优化 (8)九、小结 (10)交根据寻呼的流程(寻呼的流程见最上面的图),主要从寻呼容量、TRH的容量、SDCCH分析、覆盖问题、SDCCH掉话、TCH话务、跟PAGING相关的EOS和参数，包括无线参数和交换参数对寻呼来进行分析。
二、寻呼容量影响小区寻呼容量的参数有BCCHTYPE 、AGBLK、MFRMS、PAGREP1LA和TMSIPAR 等。
其中BCCHTYPE是定义BCCH的组合方式，不同的BCCH组合方式会使得每个复帧中有不同的CCCH组；AGBLK在BCCHTYPE确定的情况下，实际上是分配CCCH 中AGCH和PCH的比例；MFRMS是指以多少复帧数作为寻呼子信道的一个循环，它跟BCCHTYPE和AGBLK共同决定每个小区寻呼子信道的个数；小区的寻呼子信道数增多，寻呼信道的承载能力会加强。
另外，由于可以用TMSI或者IMSI作为寻呼，用TMSI和IMSI作为寻呼时，每个寻呼组可以容纳的寻呼消息是不同的，所以当使用不同的用户号码进行寻呼的时候，交换机的寻呼容量是不同的。
决定用哪个用户号码进行寻呼是由参数PAGREP1LA和TMSIPAR,其中TMSIPAR是设置第一次寻呼是否使用TMSI,PAGREP1LA是设置二次寻呼时用户号码的使用情况。
检查GZZMSC、GZRMSC、GZSMSC和GZCMSC上述参数的设置共设备的控制、对移动台的控制、传送指向移动台的短信息、层二链路维护信息。
TRH负荷过高会对寻呼造成影响，我们可以通过打印TRH的告警，观察是否有“MED PAGE DISC”或者“HIGH PAGE DISC”的告警。
我们可以结合LAPD的统计来分析。
15 W网规高培-寻呼过程分析
O n e ra d io fram e (1 0 m s)
DRX过程
每个PICH帧携带NP个寻呼指示，NP定义了PICH信道上每帧支持的最多寻呼指示数， UE在小区系统消息中获取NP的值。NP的取值为18，36，72，144，相当于将288个 bit分为NP个等份，每等份有288/NP个bits，每等份就是一个寻呼指示（PI）。
WCDMA 寻呼过程分析
前言
寻呼是接入过程中一个主要的行为，也是优化接 入过程性能的一个主要方面。 本文档概要介绍了寻呼的基本过程，在此基础上 对寻呼相关的关键参数、信令、性能等内容进行了分 析 ，帮助使用者熟悉WCDMA的寻呼过程。
课程目标
学习完本课程，您将能够熟悉：
寻呼的主要过程 寻呼过程的消息 寻呼性能分析
DRX过程
l
DRX应用举例
è è
小区建立后，广播的系统信息中，有关寻呼的参数设置为： IE“CN domain specific DRX cycle length coefficient”：6 IE“Number of PI per frame”：36
UE接收到这些信息后，计算出自己的寻呼时间、PI以及p值。 现有一个用户，其IMSI 为“448835805669362”，则该UE的计算结果如下： DRX cycle length = 64 （2的6次方） Cell SFN ＝ “448835805669362” mod 64+ n*64 = 50 + 64*n (n = 0,1,2,...)（假设此处 n 取值为3） PI = (448835805669362 div 8192) mod 36 = 14 q = (14 + [((18*(242 + [242/8] + [242/64] + [242/512])) mod 144) *0.25]) mod 36 = 27 从上面的计算可知，该小区PICH每帧携带36个寻呼指示，每个寻呼指示有288/36 = 8 个bit组成，UE需要监视每个PICH无线帧的bit216（27×8）～bit223，如果这些8个 bit变成了"1"，UE知道自己可能被寻呼了，要在SCCPCH上接收寻呼消息。
W网规高培-掉话问题分析
10. UE发RRC_RB_REL_CMP消息给RNC，业务RB释放完成
11. RNC发RANAP_RAB_ASSIGNMENT_RESP消息给CN，RAB释放完成
第一章 掉话分类定义
第一节 正常释放流程
第二节 空中接口掉话定义
第三节 话统指标掉话定义－CS 第四节 掉话话统指标定义－PS
第一章 掉话分类定义
第一节 正常释放流程
第二节 掉话空中接口定义
第三节 掉话话统指标定义－CS 第四节 掉话话统指标定义－PS
话统指标定义
话统指标定义－CS掉话统计
通过统计RNC触发的 RAB 释放个数，统计 RAB 建立个数，进而得 到掉话率。根据测量对象的不同，掉话率可以分为面向 RNC 和面 向小区的掉话率，分别考察整个 RNC 和单个小区的掉话情况。 面向 RNC 的CS掉话率公式： (RNC_CS_RAB_REL_CONV_TRIG_BY_RNC+RNC_CS_RAB_REL_STR_TRIG_ BY_RNC)/(CS_RAB_SETUP_SUCC_CONV+CS_RAB_SETUP_SUCC_STR)*10 0% 测量点： CS会话类(流类）业务建立成功后，RNC向CN CS发送IU RELEASE REQUEST消息，其后CN发送释放原因"Release due to UTRAN Generated Reason"的IU RELEASE COMMAND。
正常释放流程
一个PS正常释放信令流程
正常释放流程
一个PS正常释放信令流程
1.UE发RRC_UL_DIR_TRANSF消息给RNC，消息中nas message是0a46，表示是session management子层的deactivate PDP context request消息。 2.RNC发RANAP_DIRECT_TRANSFER消息给CN，消息中nas pdu是0a46，表示是session management子层的deactivate PDP context request消息。 3. CN 发 RANAP_DIRECT_TRANSFER 消 息 给 RNC ， 消 息 中 nas pdu 是 8a47 ， 表 示 是 session management子层的deactivate PDP context accept消息。 4. CN发RANAP_RAB_ASSIGNMENT_REQ消息给RNC，消息中给出要释放的RAB list，其 中包含了要释放的RAB ID。 5. RNC发RRC_DL_DIRECT_TRANSF消息给UE，消息中nas message是8a47，表示是
寻呼问题常见案例
寻呼问题常见案例1.1.1 呼叫未接通问题分析1.Outum现象某日测试车辆沿图示方向行驶（测试车辆沿平塘路由南向北行驶至金钟后，右转沿金钟路由西向东继续行进）。
当时，UE1占用北翟2小区（RNCID：396，CellID：18）启呼，RSCP在-97dBm左右，在接续过程中，UE1完成RB建立后，在12：59：41收到网络侧下发的Progress消息，随后在12：59：51收到了网络侧下发的Release消息，由于整个接续过程没有完成，UE1发生了未接通1次。
观察当时被叫UE2的测试情况，根据时间节点来看，在UE1收到网络侧下发的Progress消息和Release消息这段时间期间，UE2始终保持空闲模式（UE2驻留在RNC390下的北新泾3小区上），并监听系统消息，而并没有收到网络侧下发的任何Paging消息。
2.分析定位从上述过程可以看到，被叫UE2应该先监听来自网络侧的Paging消息（寻呼消息），随后发起RRC Connection Request消息，向网络侧申请RRC信令连接，并进行后续的过程，在RB建立完成后，UE2向网路侧发送Alerting消息。
而本案例中，Outum测试软件显示，UE2没有收到网络侧理应在Uu口发送的Paging Type 1消息，故UE2根本没有向网络侧发起RRC Connection Request消息。
为何在Uu 口没有看到UE2收到Paging消息呢？是由于网络侧没有下发Paging消息？还是由于无线环境等原因，导致UE2没有收到网络侧下发的Paging消息呢？要分析网络侧是否下发Paging消息，需要考虑以下两点：第一点，RNC侧在收到主叫UE1上发的Radio Bearer Setup Complete消息后，才会向CN侧发送RAB Assignment Response消息，并由CN侧发起向被叫端UE2的寻呼。
换句话说，如果RNC没有收到UE1上发的Radio Bearer Setup Complete 消息的话，也就不会触发后续的寻呼过程。
寻呼成功率的分析与优化一
寻呼成功率的分析与优化（一）关键词：寻呼、寻呼成功率、寻呼拥塞、上行干扰摘 要：寻呼性能反映了网络的接通能力，是网络的一项重要性能指标，直接影响客户感知。
本文通过对寻呼流程及影响寻呼性能的各项因素的简单阐述，结合日常优化经验总结出寻呼性能分析、优化的基本思路。
一、寻呼原理简介手机做被叫时，MSC使用TMSI或IMSI号码对手机行寻呼，向BSC发送寻呼消息。
BSC收到寻呼消息后下发寻呼指令（Paging command）给手机所登记的位置区内所有小区。
这些小区在CCCH上的PCH中广播寻呼（Paging Request）。
移动台调频到BCCH频点后解码系统信息，计算出自己属于哪个寻呼组，并定期接受所在寻呼组的寻呼广播，判断是否被寻呼。
如果收到本机的寻呼则返回给网络寻呼响应（Paging Response）。
当对某个号码第一次寻呼不成功时，MSC会自动对移动台进行第二次寻呼。
以上便是整个寻呼过程的简要介绍。
二、现网寻呼成功率现状和分析深圳现网每小时BTS理论寻呼容量为450000次，实际忙时平均寻呼数为210000次，为寻呼容量理论值的47％。
寻呼容量配置能够满足现有寻呼需求。
网络寻呼性能整体情况较好，平均成功率为94％。
但各别局的寻呼存在问题：z A局、U局等局寻呼成功率偏低；z在寻呼容量足够的情况下，AH局存在寻呼拥塞情况。
深圳A局寻呼成功率为全网最低，第一次寻呼成功率平均89.9%。
晚忙时平均值仅为88%左右，明显低于全网平均水平。
而从寻呼次数上看，A局寻呼次数与全网平均值相差不大。
最大寻呼次数14.7万还略小于全网平均14.8万次。
图1：A局寻呼性能与全网平均对比下面，我们从影响寻呼的相关参数和无线环境等方面，对A局寻呼成功率低的问题进行深入的分析。
1、 参数优化1.1优化寻呼策略移动台被寻呼时，可以用 TMSI或 IMSI来标记移动台。
由于传送IMSI数据长度为TMSI的2倍，因此使用TMSI作为第一次寻呼号码，能有效的增加小区的寻呼容量，对寻呼数量较大的MSC，使用TMSI作为第一次寻呼号码能显著提高寻呼成功率。
2011年凉山移动网络优化培训之寻呼成功率
影响寻呼的重要参数介绍
寻呼成功率分析
MAXRET：为了提高移动台接入的成功率，网络允许移动台在收到立即指配前一次发送多 个信道请求消息，具体个数由最大重发次数MAXRET确定。一般MAXRET设臵越大，接入网 络的成功率越高，接入率也越高，但同时RACH信道和SDCCH信道的负荷也随之增大，尤 其在业务量大的小区，易引起无线信道的过载和拥塞，从而降低接通率和无线资源利用率, 也影响LAU成功率。如果设臵过小则会影响接入成功率。另外，该参数设臵过大可能会增 加一些不必要的试呼次数，从而增加交换及BSC的寻呼量。可取值1、2、4、7。 AGBLK: 参数AGBLK 定义每复帧有多少寻呼块做为AGCH(立即指派)。爱立信的BTS 支持 AGBLK=0(不保留AGBLK)和AGBLK=1(保留一个AGBLK)。注意，当使用了小区广播时AGBLK 只能设为0。现网均设臵为1。 MFRMS: MFRMS 定义同一寻呼组的寻呼间隔，以一个复帧周期为单位。比如，MFRMS=2 表示移动台属于一个特定的寻呼组，每2 个复帧周期重复一次。那么这个寻呼组的寻 呼周期大致为0.47 秒 (2*235.4ms) 。MFRMS 值越高，小区中寻呼组的数量越多,寻呼时延 越大。寻呼组数量=(9-AGBLK)*MFRMS。现网均设臵为2。 T3212：周期性位臵更新的时间越短，网络的总体服务性能越好，但也有其缺陷。一是网 络的信令流量大大增加，对无线资源的利用率降低；另一方面使移动台的功耗增大，平均 待机时间缩短。定时器（T3212）是用来控制周期性位臵更新的频度，T3212设的设臵从6 分钟到超过25小时，甚至为无穷大。无穷大表示网络不进行周期性位臵更新，这完全由运 营者根据业务量和信令流量来决定。对于业务量较小、信令流量较低的小区，可以设臵 T3212较小；对于业务量超过系统容量的地区，T3212取较大，甚至不进行周期位臵更新 （T3212取无穷大）。T3212要小于MSC侧隐含关机时间BTDM+GTDM。现网T3212城区设 臵为5，郊县设臵为10。 CRH：参与不同位臵区小区的重选计算。增大该值，可以适当减少位臵更新次数，有助于 提高被叫对寻呼的响应，提高接通率，所以LAC边界需要适当调大该参数值。
寻呼问题分析定位思路
c) 对于UE是否收到了RNC下发的Paging消息分析环节，需要结合覆盖、干扰、寻呼功率、Paging消息重发次数等传统分析方法进行分析，定位UE没有收到Paging消息的具体原因。
a) 对于CN是否下发的Paging消息的分析环节，由于没有UE ID可查，故需要对Paging消息的本身特性有所了解，譬如Paging消息IE内容携带了被叫的IMSI，故可以以此为依据，查询被叫侧RNC问题时段收到的Paging消息内容，查询是否有属于被叫IMSI的Paging消息；从而定位是否由于CN没有下发Paging消息导致了问题的发生；当然，一般网优人员对于CN侧的问题定位能力有限，如果存在该问题需要与核心网厂家积极沟通，寻求解决方案；
寻呼问题分析ห้องสมุดไป่ตู้位思路
对于寻呼问题大致可以通过以下几个步骤进行逐步分析定位：
1) 要分析寻呼问题就需要对整个寻呼过程有足够的认识，从而定位问题发生环节，从大的过程来说，大致可以将寻呼过程分为两大过程：其一，从主叫启呼到CN发起向被叫寻呼的过程；其二，从CN发起向被叫的寻呼到被叫接收到寻呼消息的过程。
4) 通过上述一系列分析方法，大致已可以定位导致问题发生的原因，并提出相应的优化方案和措施；
5) 在优化方案实施后，还需要通过复测验证调整效果。
2) 上述提到了两大过程，在这里可以认为是两个分析的环节，针对第一个环节，主要需要分析的内容是主叫侧是否为寻呼被叫做好了准备，即RB配置过程是否已经完成，并且RNC侧是否收到了主叫UE上发的RB Setup Complete消息，并向CN侧发送了RAB Setup Success消息来促使CN发起向被叫的寻呼；如果第一个环节没有问题，则需要进入第二环节的分析过程；
寻呼负荷过高导致语音断续分析
寻呼负荷过高导致语音断续分析一、问题概述5月9号15:40-16:10景德镇用户反映在BSC1下面部分基站出现语音通话断续，查询BSC1下有22个基站出现寻呼负荷过载告警，该BSC下所有基站最大寻呼负荷均达到85以上，寻呼负荷过高导致该BSC指标恶化。
二、问题分析1、PCH负荷高问题5月9号15:30开始，景德镇两个BSC下出现大量短消息寻呼，以BSC1为例，9号4点15分钟内短消息一次寻呼请求次数为223053，较前一天5922条增长26倍，发送时间较集中，BSC无法及时处理造成PCH负荷升高，短消息丢弃，短信寻呼成功率降低。
从15分钟CDR来分析，BSC1 15分钟总计接收短消息100691条，其中10001号占80%，发送81037条短消息给BSC1下33534个不同的用户，1小时内10001号发送短信198653给58621个用户，1小时内每个用户平均收到10001的短消息3.3条，发送量大且时间较集中，在15分钟内平均每秒发送112条，超过BSC的承载能力，造成PCH 负荷升高，大量短信首次寻呼失败，5s后再次寻呼，再次加重PCH负荷，导致部分基站出现PCH负荷过高告警，短消息流控，话统指标恶化。
2、语音断续问题一段时间内一个基站下大量短消息寻呼占用该基站大量Abis链路1X前向信令带宽，在优先保障信令链路的前提下业务带宽不足，导致语音通话断续。
以景德镇电信局BBU为例，ACH、PCH是走信令信道，语音通话走业务信道，该基站1x配置1条2m，信令+业务总带宽为1984 kbps，当1x前向信令占用带宽过大时，会导致业务带宽不足，业务信道上的业务会受到影响，语音失真。
三、问题结论短时间内大量短消息群发造成业务信道Abis分配资源不足，语音断续，同时大量群发短信造成PCH负荷急剧升高，短信流控，大量短消息寻呼失败，5s后再次重发，引起PCH 负荷高告警，接入短信过多造成1x abis业务信道分配带宽不足，语音出现断续。
校园高话务区域寻呼拥塞问题优化报告
校园高话务区域寻呼拥塞问题研究及解决方案探讨一、目前现状及主要问题10月份以来，广州多个局出现不同程度的寻呼成功率下降，尤其在校园高话务区域更为严重，一般来说，寻呼性能主要受容量、质量、覆盖等几个方面的影响，其中容量方面主要看LA寻呼负荷，质量方面可以参考SDCCH建立成功率，覆盖方面可以通过收取MRR 来进行评估。
图1是广州35局的指标变化情况（数据取自9月27日与10月11日的17点）：图1 广州35局指标对比从图中可以看到，该局寻呼成功率从93％下降至87％。
通过前后对比发现SDCCH建立成功率变化不大；寻呼负荷虽然有所提升，但也只在50％左右，远远低于寻呼负荷预警门限；而通过MRR数据对比发现覆盖方面变化也不大。
那么究竟还有什么原因会导致寻呼成功率会这么低呢？由于近期也收到了一些校园区域的相关投诉，主要是投诉电话难打，应该和拥塞有关。
在有些校园高话务小区进行扩容后，虽然TCH拥塞率有所缓解，但用户感知变化不大甚至下降，在一些区域甚至出现投诉增多的趋势。
这种越扩越拥的现象又是什么原因呢？综上，校园高话务区域的问题可归纳为“覆盖、质量、负荷都正常的情况下出现寻呼性能严重下降”和“某些小区越扩容用户感觉越拥塞”这两个。
二、原因分析及验证经仔细分析，发现这些局寻呼拥塞很严重，而且都集中在了个别小区，主要是校园高话务小区。
但为什么寻呼负荷又不高呢？因为我们计算LA寻呼负荷时，默认每个51复帧中的PCH寻呼块有8个（总共有9个CCCH块，其中1个给了AGCH），这样计算的寻呼容量约为20万（假设10％的二次寻呼比例，二次寻呼采用IMSI+Global方式）。
但常常被忽略的一点是：在某些校园高话务小区，立即指配数（语音加数据业务）高达十几万甚至二十万，按理论最大承载能力（约3万）计算都要占去7个CCCH，而立即指配的优先级是高于寻呼的，这样留给PCH使用的CCCH块最多只有2个了，那么这个小区的寻呼容量就只有原来的1/4，约5万了。
寻呼成功率优化方法探讨
寻呼成功率优化方法探讨李慧莲（中国联合网络通信有限公司广东省分公司510627）邹海燕（中国联合网络通信有限公司广州市分公司510627）林宇年（中国联合网络通信有限公司潮州市分公司521000）摘要重点从核心网角度出发，结合实际优化案例经验，对寻呼成功率优化方法进行探讨，就核心网寻呼参数配置优化、寻呼黑洞分析优化、寻呼新功能设置进行了研究和优化应用并取得了很好的效果。
关键词：寻呼成功率优化方法寻呼黑洞寻呼协调1 概述寻呼成功率是一项重要的网络质量指标，它直接反映了被叫接通率和短信接收成功率等性能，寻呼指标的优劣直接影响终端用户使用感知，因此寻呼成功率一直是网络优化的重点，寻呼成功率虽然是一项核心网侧的统计指标，但该指标的提升需要核心网优化和无线优化共同完成，本文重点是从核心网出发，对寻呼成功率优化方法进行探讨，包括核心网寻呼参数配置、寻呼黑洞分析、寻呼新功能设置，当然，提升寻呼成功率的方法很多，文本只重点介绍这三个方面。
2 核心网寻呼参数配置2.1 隐性关机时长隐性关机时长就是当用户在达到或超过这个时长的时间间隔后，用户没有与MSC发生联系，则MSC会置用户为关机状态，之后若用户被叫就不会下发寻呼请求，从而能降低无效寻呼来提升寻呼成功率，这个参数要与无线侧周期性位置更新时长综合考虑，一般来说稍大于周期性位置更新时长的2倍，如现网周期性位置更新时长为30分钟，则核心网侧设置为65分钟。
2.2 寻呼间隔寻呼间隔就是等待寻呼响应超时的时长，一般来说在3～6秒之间，对于无线环境较差的区域，可能寻呼响应的时间较长，如果设置的寻呼时间间隔过短，每次寻呼响应还没有到达MSC，MSC的寻呼就超时了，从而影响寻呼成功率，而寻呼时间间隔过长，呼叫接续时长延长，可能造成用户等待时间太长，也会影响用户感知，寻呼时间间隔的设置也需要综合考虑，同时也需要与无线配合，具体优化时可参照核心网优化平台统计寻呼响应时延分布情况进行合理设定。
寻呼删除分析
太原寻呼删除分析一、现网情况通过网络数据的监控、统计，发现整体网络寻呼成功率较高，但一些小区特别是热点地区忙时存在较多的Paging_Del_Command，所以针对此中寻呼删除现象进行简要的分析。
以下为近期出现寻呼删除的小区数量情况：二、无线寻呼删除对网络质量和客户感知的影响分析在普通话务模型下，GSM的寻呼容量是足够的，但是在特定的高密度话务区域却容易出现寻呼容量不足，伴随大量的寻呼排队拥塞、超时和二次寻呼以及寻呼删除，而造成寻呼删除高的关键原因是主覆盖小区承载业务量过高，尤其是数据业务量巨大导致小区CCCH信道负荷过高、寻呼资源不足导致客户出现投诉现象。
常见情况有呼困难和被叫“手机呼”、短信延迟、上网速度慢等。
寻呼删除严重给客户造成的感知极差，一些热点地区，个别小区寻呼删除严重，需要持续跟踪解决。
三、无线寻呼删除原理分析介绍1、太原现网空口容量分析寻呼是在BCCH(BroadcastControChannel)的0时隙上进行的，其中的PCH用来向移动台传送寻呼请求信息。
BCCH的0时隙在逻辑上被分为复帧结构，每个复帧的发送时间为235.4ms。
由于目前太原网络BCCH信道类型均采用了非组合BCCH/SDCCH，则一秒钟最多可以发送的寻呼块的数量为：AG=2： 7 / 0.2354=29.74 Paging block/second网络第一次寻呼采用TMSI方式，即每个寻呼块可以容纳4个TMSI信息，每小时BTS 能处理的最大寻呼指令数量为：（AG=2）4×3600×29.74＝428207 Paging message / hour但是这些都是不现实的，由于寻呼重传机制，通常IMSI的比率在10％左右，特殊情况下更高，且并非每个CCCH块均填充4个TMSI信息，加上BTS的Paging Group机制，如果MFR设置为5，寻呼负荷超过140K Message / 小时就可能出现大面积寻呼删除；2、寻呼删除定义通过查看NED对“delete paging command”的介绍：This counter indicates if some group-specific paging queue becomes so full that an additional paging command cannot be stored to the buffer. In such a case the paging command is deleted.可知寻呼删除产生的原因是某些paging group相对应的buffer寻呼占用已满，在这种情况下，溢出的paging command将被删除。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
从 UE 接 收 寻 呼 消 息 的 角 度 来 看 ， 寻 呼 消 息 分 为 PAGING TYPE1 和 PAGING
TYPE2，由UTRAN决定发送给UE的寻呼类型。PAGING TYPE1是通过PCCH 逻 辑 信 道 来 寻 呼 处 在 IDLE ， CELL_PCH ， URA_PCH 状 态 的 UE 。 PAGING TYPE2是通过DCCH来寻呼处在CELL_FACH，CELL_DCH状态的UE。
应重点关注是否存在覆盖空洞、系统过载、寻呼丢失、寻呼信道功率配比低等方面的
优化记录。
信息收集
参数配置
和寻呼相关的参数如下，优化前要注意收集：
CN寻呼重发次数、寻呼时间间隔； UTRAN寻呼重发次数、寻呼时间间隔； DRX寻呼周期系数k（DRX寻呼周期 = 2k）；
一个PICH帧包含的寻呼指示数目NP；
的某些处理频率很高的消息进行了流控。当RNC收到CN的寻呼消息后，判断系统 如果处于寻呼流控状态，就会丢弃寻呼消息，并记录下寻呼消息丢失的个数。如 果寻呼丢失比例达到一定的门限，RNC就会向CN发Overload消息，CN就会控制 消息发送流量按照一定的步长减少。如果在一定的时间内没有收到Overload消息， IU的消息流量会逐步增长直至恢复正常。 RNC目前寻呼相关的告警是“流量控制告警”，当RNC处于寻呼流控状态下寻呼消息 会无条件丢失。当系统从流控状态恢复时，会产生流量“控制恢复告警”。
加密模式控制
SETUP CALL CONFIRM
RAB 建立过程
ALERT CONNECT CONNECT ACKNOWLEDGE
课程内容
第一章 寻呼问题的分析流程
第二章 寻呼问题的典型案例
第一章 寻呼问题的分析流程
第一节 分析流程
第二节 信息收集
CN使用的UE标识不合理
详细的分析参见后面的案例。
问题定位
其它原因分析
寻呼类信道功率配比过低 存在覆盖盲区 手机性能问题
可能存在的其它方面的原因有：
详细的分析参见后面的案例。
第一章 寻呼问题的分析流程
第一节 分析流程 第二节 信息收集
第三节 问题定位
第四节 优化验证
问题优化
概述
网络侧会在以下情况下发起寻呼：
UE被叫；
小区系统消息更新； UE状态迁移；
一个典型的由寻呼引起的被叫流程如下图所示。
寻呼过程中可能会存在种种问题导致目标UE不能正确收到寻呼消息，如在网络群
发短消息和全文寻呼时，不合理的寻呼策略会使得寻呼信道拥塞从而造成寻呼 消息大量丢失，严重情形下还会造成系统长期过载，寻呼信道功率配比过低造 成寻呼成功率低。
话统 告警 用户投诉 优化历史记录 参数配置
信息收集
话统
观测；RNC话统对应一个RNC区域，UMSC话统对应一个位置区，SGSN话统对
寻呼相关的话统指标可以根据不同的寻呼区域分别在RNC、UMSC、SGSN话统台上
应一个路由区。
在实际话统分析过程中需要把RNC和CN的话统数据结合起来分析。 RNC 的 话 统 中 ， 需 要 关 注 “ CN_PAGE_IDLE_UE_SUCC_RATE” 和
是否被叫手机类型相同，可能存在手机自身问题；
是否投诉地点集中，可能是因为信号覆盖问题；
找到投诉的规律能加快问题解决的速度。
信息收集
优化历史记录
网络所经历各次扩容的规划报告。
获取网络规划报告，重点关注寻呼区域（位置区、路由区）的划分。规划报告应包括
对于开通后网络，可能在本次优化之前已经经历了优化过程，在本次优化开始之前应 获得各次优化历史记录，了解各次网络调整过程及遗留问题。
寻呼消息下发，UE没有收到或者是收到错误的寻呼消息；按照用户投诉的情况具体区分，
如果只是UE作被叫有问题，可能是PICH和PCH的功率配比过低或手机性能有问题；如果 UE主叫被叫都有问题，可能该区域存在信号覆盖盲区。
UE收到寻呼后回寻呼响应失败；属于接入失败的问题，解决方法参考“接入过程问题分 析”。
信息收集
用户投诉
区”。
如果寻呼消息丢失导致手机不能做被叫，主叫用户会听到系统提示音“用户不在服务
可以客户处了解用户投诉情况或直接联系投诉人了解不在服务区发生情况，要重点关 注手机被叫失败的情况。
整理投诉信息，寻找规律，观察是否存在下属情况：
是否忙时和闲时都发生；如果寻呼失败在话务高峰，重点分析寻呼拥塞的情形，如果不是 在话务高峰，要分析其它因素；
第三节 问题定位
第四节 优化验证
分析流程
ø ç Å ¢ Õ ¯ Í Â Ð Ï Ê ¼
²¨Å ¯ ¿ ê È ¶ Ó » Ä ±
°ô Ê â ¨» Ñ º Î Ì ¶ Î
°ô Ê â Å ¯ Ñ º Î Ì Ó »
Å ¯ é ¤ Ó » Ñ Ö
NO Ç ñ ï ½ Å ¯ ¿ ê ¿ Ê ²´ µ Ó » Ä ±£ YES END
PICH、PCH信道功率配比； CN是否使用全局寻呼； CN寻呼使用的UE ID（是IMSI还是TMSI、PTMSI）；
确定优化目标
确定优化KPI目标：
位置区寻呼成功率 路由区寻呼成功率
“位置区寻呼成功率”和“路由区寻呼成功率”这两个KPI指标要达到优化 要求，如寻呼成功率达到86%以上。
第一章 寻呼问题的分析流程
针对各个专题的寻呼问题优化方法详见第二章节的描述。
优化验证
在对网络实施了优化调整后，需要验证优化的结果：
话统：查看“位置区寻呼成功率”和“路由区寻呼成功率”是否达到预 定的优化目标；
告警：查看CN是否有“RNC过载”告警，RNC是否有流控告警；
用户投诉：在一段时间内是否有用户被叫投诉； 拨测：选择话务高峰期和用户投诉地测试手机被叫成功率，拨测不需要
接通，电话只需要听回铃音或提示音即可。
课程内容
第一章 寻呼问题的分析流程
第二章 寻呼问题的典型案例
第二章 寻呼问题的典型案例
寻呼区域规划过大
CN寻呼参数设置不合理 UTRAN寻呼参数设置不合理
CN使用了全网寻呼
DRX寻呼参数设置不合理 NP值设置不合理
的原因。同时查看CN是否有RNC过载告警、RNC是否有流控告警，如果有这些告
警存在说明寻呼丢失的可能性很大。 如果这两个指标低的事件在时间上近似均匀分布，用户投诉具有地域性，就要检查除 “寻呼丢失”外的原因了，如寻呼信道配比、信号覆盖、手机性能等。
进一步分析寻呼问题需要到现场进行拨测分析，时间选择在话务量高的时间段，地点
CN寻呼使用的UE标识
IMSI ATTACH/DETACH功能 寻呼类信道功率配比过低
存在覆盖盲区
手机性能问题
寻呼区域规划过大
现象与分析
CN通常在一个寻呼区域（位置区或者路由区）对目标UE进行寻呼，这种寻呼又 称作本局寻呼。 对CS域业务来说，CN使用位置区来识别和寻呼UE，位置区被定义为移动终端在 不更新VLR的情况下可以自由移动的区域，一个位置区可以涵盖一个或几个
信息是否正常。
第一章 寻呼问题的分析流程
第一节 分析流程
第二节 信息收集
第三节 问题定位
第四节 优化验证
信息收集
网络信息收集是寻呼问题分析的第一步，优化人员要获取待优化网络中与寻 呼相关的话统、用户投诉、告警、网络规划优化历史记录、无线参数配 置等等信息，为后续进一步的深入分析做准备。 需要收集的信息主要包括以下几个方面：
本文将对这些导致寻呼异常的问题进行深入分析，并给出其解决方法。
概述
UE被叫流程图：
UE NAS
RR_PAING_IND RR_EST_REQ (PAGING RESPONSE)
UE AS
paging
NSS
RANAP
MSC
paging
RANAP
RRC连接建立过程
INITIAL_DIRECT_TRANSFER AUTHENTICATION REQUEST AUTHENTICATION RESPONSE RR_SECURITY_CONTROL_REQ (IK CK) (PAGING RESPONSE)
信息收集
话统
BSC配置，可以统计一个位置区的寻呼成功率、第一次寻呼成功率、非第一次寻
UMSC寻呼相关话统指标都是基于一个位置区的。一般情况下，位置区不会跨RNC、
呼成功率。
位置区的寻呼成功率关注一个位置区的寻呼状况，并不关心寻呼重发次数，而第一次 寻呼成功率、非第一次寻呼成功率关注寻呼重发次数对寻呼成功率的影响。 SGSN寻呼相关话统指标都是基于一个路由区的，可以得到某路由区的寻呼成功率。
分析流程
寻呼问题分析流程如图所示，大体分为以下几个步骤：
网络信息收集：收集网络与寻呼相关话统、告警、用户投诉、网
络规划和优化记录、网络参数配置等信息；
确定优化目标：确定寻呼问题优化的KPI指标；
寻呼问题定位：定位导致寻呼问题的原因；
寻呼问题优化：根据定位结果采用相应的优化调整措施； 优化验证：验证优化后的KPI指标是否达到要求以及其它寻呼相关
WCDMA RNO 寻呼问题分析
前言
寻呼是网络联系UE的重要途径，和其它流程相 比较，寻呼流程在无线网络中表现出频率高、流量大、 突发性强等特点，寻呼性能关系到整个无线网络的性 能。所以研究寻呼问题对无线网络性能具有很强的现 实意义。