57.寻呼拥塞分析优化案例

合集下载

寻呼原理概述及寻呼优化

寻呼原理概述及寻呼优化目录一、背景 (1)二、寻呼原理 (2)2.1、CS寻呼流程及寻呼策略 (2)2.1.1、CS寻呼流程 (2)2.1.2、CS寻呼策略 (3)2.2、PS寻呼流程及寻呼策略 (4)2.2.1、PS寻呼流程 (4)2.2.2、PS寻呼策略 (5)2.3、寻呼信道及寻呼容量 (5)2.3.1、寻呼信道介绍 (5)2.3.2、寻呼容量 (6)三、小区级寻呼拥塞及解决思路 (7)3.1、小区寻呼拥塞 (7)3.2、寻呼拥塞的解决方法探讨 (8)四、全网语音寻呼成功率优化探讨 (9)五、小结 (10)附件1：寻呼组计算方法 (10)附件2：文中COUNTER意义： (11)附件3：文中涉及参数的意义 (11)一、背景随着GPRS业务的迅速增长，数据业务占用消耗载波资接近语音业务消耗的载波资源，同时空口寻呼容量瓶颈现象也日趋严重，现网中小区级寻呼拥塞现象严重，甚至制约着网络语音寻呼成功率的提高。

由于寻呼优化需涉及到MSC、SGSN、BSC及PCU等网元，作者知识经验有限，本文结合广州项目做高拥塞工作的经验及参考了韩杰斌《GPRS网络优化原理》，对寻呼做了简单的介绍，希望大家对网络中出现的新问题有个系统的感性认识。

二、寻呼原理GPRS没有专用的控制信道，因此BTS的CCCH信道承载了CS业务与PS 业务的寻呼指配，其中CS寻呼消息由MSC发出，PS寻呼消息由SGSN发出。

2.1、CS寻呼流程及寻呼策略2.1.1、CS寻呼流程当被叫MSC收到GMSC发来的IAI消息后，将向其VLR发送一条入局呼叫消息,VLR在收到该消息后，来分析被叫的号码（在VLR中有各种号码分类的信息，它会检查看是否有指向该号码的能力）和网络本身的资源能力等等来核对是否能接纳这种需求，若某些项目不能通过将通知主叫端呼叫建立失败。

在正常的情况下VLR将向MSC发送寻呼（PAGING）的MAP消息，该消息中含有该移动台所在的位置区（LAI）以及被寻呼用户的IMSI或TMSI的号码，来通知MSC开始执行寻呼该移动台的过程。

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规划问题。

交通信号配时优化的实践案例分析与总结

交通信号配时优化的实践案例分析与总结在现代城市的交通管理中，交通信号配时优化是一项至关重要的工作。

通过合理调整信号灯的时长和相位，能够有效提高道路的通行能力，减少交通拥堵，提升出行的安全性和效率。

本文将通过几个具体的实践案例，深入分析交通信号配时优化的方法和效果，并总结其中的经验和教训。

一、案例一：市中心繁忙路口（一）路口现状该路口位于市中心的商业区域，周边有多个大型购物中心和写字楼，日常交通流量巨大。

在优化前，信号灯配时不合理，导致高峰时段车辆排队长度过长，交通拥堵严重，平均延误时间高达 30 分钟以上。

（二）优化措施1、进行交通流量调查，收集不同时段、不同方向的车流量数据。

2、根据流量数据，重新划分相位，增加了左转专用相位，减少了冲突点。

3、采用自适应信号控制技术，根据实时交通流量自动调整信号灯时长。

（三）优化效果经过优化后，高峰时段车辆排队长度明显缩短，平均延误时间降低至 15 分钟左右，道路通行能力提高了约 30%，交通拥堵得到了显著缓解。

二、案例二：学校周边路口（一）路口现状这个路口紧邻一所学校，上下学时段学生和家长的出行集中，导致交通混乱。

之前的信号配时没有充分考虑到学校的特殊需求，行人过街时间不足，存在安全隐患。

（二）优化措施1、调整信号灯周期，在上下学时段增加绿灯时长，保障学生和家长有足够的时间通过路口。

2、设立行人专用相位，确保行人过街的安全。

3、与学校沟通，实行错峰放学制度，分散交通流量。

（三）优化效果优化后，上下学时段的交通秩序明显改善，行人过街更加安全，车辆通行也更加顺畅，得到了学校和周边居民的一致好评。

三、案例三：工业园区路口（一）路口现状该路口位于工业园区内，大型货车流量较大。

由于原信号配时未充分考虑货车的启动和制动特性，导致路口通行效率低下，频繁出现车辆熄火和追尾事故。

（二）优化措施1、延长货车通行方向的绿灯时长，以适应其较长的启动和制动时间。

2、调整相位顺序，优先放行货车流量较大的方向。

利用多寻呼及接入信道方案解决CDMA拥塞研究

大陆桥视野·２０１６年第２２期 41利用多寻呼及接入信道方案解决ＣＤＭＡ拥塞研究丁秀锋　／　南京信息职业技术学院　通信学院【摘要】本文通过分析网络寻呼信道及接入信道产生拥塞的原因，分析了进行拥塞分析的常用方法，同时通过对某市寻呼信道及接入信道的具体问题分析情况，提出通过利用多寻呼及接入信道的方法，解决某市网络的寻呼及接入信道拥塞问题。

【关键词】多寻呼；接入信道；拥塞１．　前言拥塞是所有具备承载业务功能的无线网络系统中常见的问题，是引起网络质量和用户感知下降的重要原因之一。

而寻呼信道及接入信道拥塞，又是常见的网络拥塞问题，它对用户感知的影响，主要体现在：呼入呼出困难、多次拨打才可接通、有信号但是无法起呼等方面。

当前正处在用户快速增长的时期，网络负荷不断增加，如果不注意进行网络的负荷及拥塞分析，容易发生拥塞，影响用户感知。

因此，必须采取措施进行拥塞的预防与控制。

本文可以作寻呼信道及接入信道拥塞问题处理的参照，预防及解决网络寻呼信道及接入信道的拥塞问题，改善网络质量，提升用户感知。

２．　寻呼及接入拥塞的原因２．１　寻呼信道资源不足寻呼信道用于用户寻呼、公共消息广播等。

当寻呼信道负荷过高时，会引起寻呼信道的拥塞。

一般认为当寻呼信道负荷超过７０％时，会引起寻呼信道拥塞。

在ＭＳＣ侧可以设置短信使用业务信道传输的触发门限，字节数小于该门限的短信会在寻呼信道下发，当该类短信较多的时候，会引起寻呼信道的拥塞；ＬＡＣ规划不合理，如ＬＡＣ规划过大，导致寻呼量较大；或ＬＡＣ区边界位于高话务区域或人流量较大的交通要道，ＬＡＣ区嵌套等，导致位置更新频繁，同样也会引起寻呼信道的拥塞；寻呼机制配置不合理，也会引起寻呼信道的拥塞。

２．２　接入信道资源不足接入信道用于用户接入或登记时的信令交互，过多用户同时接入或登记，会引起接入信道的拥塞。

一般认为当接入信道负荷超过６０％时，会引起接入信道拥塞。

接入参数设置不合理，会引起接入信道的拥塞。

VOLTE寻呼拥塞分析优化案例

VOLTE寻呼拥塞分析优化案例一、案例背景VOLTE（Voice over LTE）是指通过LTE网络进行语音通信的技术，它提供了高质量的语音通话和丰富的通话功能。

然而，在实际网络运营中，由于网络拥塞等原因，VOLTE寻呼过程中可能浮现延迟或者失败的情况，影响用户的通话体验。

因此，我们需要进行VOLTE寻呼拥塞分析优化，以提高寻呼成功率和通话质量。

二、问题分析1. 寻呼拥塞原因分析：我们需要对VOLTE寻呼拥塞问题进行深入分析，找出导致寻呼失败或者延迟的具体原因。

可能的原因包括网络拥塞、信号覆盖不足、信道干扰等。

2. 寻呼成功率分析：对于寻呼成功的情况，我们需要分析成功率，并根据不同地区、时间段等因素进行对照分析，找出成功率较低的地区或者时间段，并进一步分析原因。

3. 通话质量分析：除了寻呼成功率外，我们还需要分析VOLTE通话质量，包括音质、时延、丢包率等指标。

通过对通话质量的分析，我们可以找出影响通话质量的因素，并进行优化。

三、数据采集与分析1. 数据采集：我们需要采集VOLTE寻呼过程中的相关数据，包括寻呼请求次数、寻呼成功次数、寻呼失败次数、寻呼延迟时间、通话质量指标等。

这些数据可以通过网络监测设备、基站设备、用户设备等进行采集。

2. 数据分析：采集到的数据需要进行详细的分析，包括寻呼成功率的计算、寻呼延迟时间的统计、通话质量指标的计算等。

通过对数据的分析，我们可以找出问题所在，并制定相应的优化方案。

四、优化方案1. 网络优化：针对网络拥塞问题，我们可以通过增加基站、优化网络参数、调整信道分配等手段来提高网络容量和覆盖范围，从而减少寻呼拥塞情况的发生。

2. 信号优化：对于信号覆盖不足的问题，我们可以通过增加基站或者调整天线方向来改善信号覆盖情况，提高寻呼成功率。

3. 干扰处理：针对信道干扰问题，我们可以通过频谱分析、干扰源定位等手段来找出干扰源，并采取相应的干扰消除措施，提高寻呼成功率和通话质量。

WK35--寻呼拥塞案例--彭艳娟

寻呼拥塞率高一.故障现象2017年8月29日F_N_R_岳阳市岳阳楼区八字门电信食堂的209,210,211三个小区寻呼拥塞率高。

而且都是1.4M小区。

这三个小区是NB的host小区，近期新开的.二．问题分析1)核查全网告警经核查未发现影响站点的故障和告警。

2)近期操作记录没有相关操作记录。

3)核查同一TAC同一TAC内其他小区没有寻呼拥塞4)指标分析选取寻呼拥塞问题点，对这些小区对应时间段的重要指标进行统计，统计结果发现RRC丢弃次数较高，指标如下：M8008C2计数器统计指标为RRC寻呼丢弃次数，M8008C1计数器统计指标为RRC寻呼请求次数. 1.4M的寻呼容量小，所以出现了拥塞。

与此相关的主要参数有defaultPagingCycle，pagingNb与maxCrPgDl 。

5)原理分析：1.eNB上寻呼相关的两个参数：defaultPagingCycle即T，决定DRX周期即寻呼周期，单位为rf（无限帧，10ms），取值范围是32、64、128和256。

值越大，RRC_IDLE状态下UE的电力消耗越少，但是相应的，寻呼消息的平均延迟越大，接通的时延也越大。

nB表征寻呼密度，取值范围是4T、2T、T、T/2、T/4、T/8、T/16、T/32，图中T/4表示每4个无线帧有1个子帧用于寻呼，如果设置为T/8则表示每8个无线帧有1个子帧用于寻呼，该值决定了LTE系统的寻呼容量。

nB的取值表征寻呼组的数量，如T取值128，nB取值T，则相当于将所有的用户分为128个寻呼组（一个无线帧一个寻呼组），如果T取值64，nB取值T/4，则分为16个寻呼组，寻呼组越多，每个组中用户数量越少。

LTE寻呼在物理信道PDSCH信道传输，每个寻呼信道最多可以寻呼16个用户，根据nB的取值，可以计算出小区的寻呼容量：由于移动通信寻呼的突发性，一般要求网络的寻呼负荷不超过50%的寻呼容量，因此，在进行网络规划、参数规划的时候，需要考虑综合TAC、用户分布等因素，规划寻呼参数：一般情况下，LTE小区寻呼参数建议设置：–T=64或者128，nB=T此时，寻呼周期640/1280ms，寻呼容量：1600次/秒特殊场景（如大型活动、比赛现场），需要对某些小区的寻呼参数进行优化调整，可以采用的方案如下：–nB：增大nB，提高小区寻呼容量，减少寻呼拥塞，如nB→2T/4T–T：T值越大，寻呼时延越长，寻呼组增加，每个寻呼信道中的用户越少，反之寻呼时延缩短，每个寻呼信道用户增加，可能导致某个时刻一个寻呼组寻呼的用户超过16个，反而增加的寻呼时延，因此，可以根据实际用户的数量，调整T值。

话务量低高拥塞优化案例

小区话务量很低的情况下出现较高拥塞优化案例现象描述；为了提高语音质量，关闭话务量较小的小区C2_CQ北羊坊HG-2的半速率,将参数【TCH速率调整允许】从“是”改为“否”,但发现关闭半速率后TCH拥塞率大幅度上升,但根据容量规划的爱尔兰B表计算,这些小区的话务量采用全速率完全可以承载，不应有大幅度的拥塞出现。

原因分析；分析话统发现指标：CH302A:CELL_INTRACELL_HO_FAIL_CONG[BSC内小区内切换失败次数（无可用信道)]与K3011B:CELL_KPI_TCH_HO_CONGEST_TRAF[TCH切换占用遇全忙次数（业务信道)]的值相同，即这些小区的小区内切换失败均由拥塞导致。

同时查看指标;K3011A:CELL_KPI_TCH_ASS_CONG_TRAF[TCH呼叫占用遇全忙次数（业务信道）]均为0，这说明指配完全没有拥塞。

结合以上三个指标分析，可以断定这些小区的高拥塞率是假拥塞，可能原因是小区内全-半切换失败导致拥塞率异常。

判定是假拥塞后，检查参数配置，【小区内切换允许】设置为否,但检查【小区内全-半切换允许】设置为是。

查阅相关文档，对于AMR全－半速率切换，R3版本受【小区内切换允许】和【小区内全-半切换允许】两个开关控制，而R8版本只受【小区内全-半切换允许】控制，但现场版本为BSC6000V900R008C12，排除参数【小区内切换允许】和【小区内全-半切换允许】设置不一致导致切换失败的可能。

进一步检查AMR全半速率话统，发现依然有切换请求。

指标：H3005A: CELL_INTRACELL_HO_REQ_AMR_TCHF_TCHH[指标反映了BSC放弃的AMR 呼叫全速率向半速率切换尝试次数]，该指标不为0，说明全速率信道向半速率信道发起切换请求；指标H3015A:CELL_INTRACELL_HO_CMD_AMR_TCHF_TCHH，该指标全部为0，这说明全速率信道向半速率信道发起切换请求全部被拒绝。

网络优化典型案例分析

网络优化案例案例1：关于邻小区列表设置的问题【现象描述】手机在通话过程中可以成功的从A小区切换到B小区,但无法从B小区切换到A小区；手机距离某小区C很近,但在手机的导频激活集中看不到C小区的PN码。

这样随着手机向目标小区移近,手机导频激活集中的EC/IO将逐渐降低、FER逐渐增大,继而引起掉话。

【原因分析】一般情况下,CDMA手机有四个寄存器,分别存放6个激活导频集、5个候选导频集和20个相邻导频集。

虽然在目前的系统中,部分厂家的数据库最多可提供多达45个相邻小区,但系统通过Neighbor List Updat消息经空中接口向手机传送的只有20个,而这20个邻区是系统按一定的算法从当前的服务小区的多个邻小区数据库列表中选出来的,在选择过程中系统一般不依赖于这些小区的信号强度和质量,而仅仅根据数据库的静态定义按照预先设定的算法进行选择。

这样如果某个目标小区在系统邻小区中未定义或定义了但由于优先级低而未能通过空中接口消息告之手机,手机的邻小区寄存器中未存放该目标小区的信息,就会导致上述问题现象的发生。

【解决方案】通过路测设备或其它呼叫跟踪设备采集空中接口消息,采集掉话前后的信息,确定掉话后同步的PN码,然后查找该同步消息上面最近的Neighbor List Updat消息,看是否由该PN码,并结合邻小区列表数据库中判断是否为未定义或虽然定义了但优先级太低。

案例2：关于导频检测参数设置的问题【现象描述】手机在通话过程中由于无线环境变化,导致信号急剧变化,此时会出现手机虽然已搜索到目标小区信号,但由于未达到切换门限而无法切换或切换区域不足,导致误帧率上升引起掉话。

下面是一组现场测试数据,可以看出由于无线环境的变化,PN75的信号急剧减弱,但PN396由于切换门限T-ADD为-12db,未能进入有效集,导致PN27虽然已达到门限值,但由于高误帧而无法完成切换,导致掉话。

【原因分析】分析该问题,我们需要对导频检测参数的定义和设置意义要有些了解。

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

影响GSM网络系统寻呼成功率因素分析及优化措施【摘要】随着用户对网络通信质量的要求也不断提高，运营商纷纷加强对自身服务的改善，其中就包括如何提高寻呼成功率。

本文结合笔者多年工作经验，重点就影响GSM网络系统寻呼成功率的因素进行分析，并提出一些有效的优化措施，以期指导实践。

【关键词】GSM网络；寻呼成功率；PCH控制；解决措施随着移动通信事业的快速发展，我国移动电话普及率的不断提高，网络容量日益增加，运营商对无线网络性能指标的稳定性的要求也有所提高，特别是涉及到用户体验方面的指标，这就迫使运营商要不断优化无线网络以提高网络质量和稳定性。

移动通信的网络优化工作十分复杂，它包括无线网络、用户分布、测试评估和频率资源等方面的内容。

寻呼成功率作为GSM网络系统中的一项重要质量指标，对来电接通率和无线系统接通率等网络质量指标具有重要的影响，若该项指标偏低，则表示网络系统的接通能力和寻呼能力低下，这也是引起用户投诉的主要原因之一。

本文重点就影响GSM网络寻呼成功率的几个重要因素进行分析。

1.影响网络寻呼成功率的因素分析1.1 网络覆盖效果覆盖盲区和弱覆盖区是影响网络系统寻呼成功率的一项重要负面因素。

一方面，我们可以通过路测或话务统计中测量报告（MR）来发现问题覆盖区域，对于这类区域一般建议规划基站、调整基站天线挂高及俯仰角来增强覆盖。

另一方面，网络中可能存在一些参数设置不合理造成的人为问题覆盖区域。

可以检查小区主B（主频）的发射功率、小区最小接入电平（ACCMIN）、随机接入错误门限（Rach）等参数，并依据实际情况控制每个基站的覆盖区域，以达到较好的覆盖效果。

1.2 位置区的划分网络中位置区的划分不易过大和过小。

位置区过小，手机频繁移动发生的位置更新次数较多，增加了系统的信令流量；反之，位置区过大，一个用户的寻呼消息会在许多的小区中发送，给PCH信道带来了较大的负荷同时增加了Abis口的信令流量。

在进行位置区大小划分时，要充分估算位置区的容量，并考虑节假日、重大活动的冗余量。

寻呼成功率专题分析(通过A接口信令数据定位寻呼差小区理论模型)

寻呼专题分析在此次优化工作中，我们针对寻呼成功率指标做了专项分析，由于寻呼成功率低会影响网络接通率指标，同时也会使用户的感知度受到影响，我们参考无线侧数据及交换侧数据在寻呼成功率方面进行了一些优化工作，从寻呼时长，寻呼较差小区，以及寻呼涉及的一些参数进行了分析，具体过程如下：我们按下面的模型统计了寻呼较差的小区，并针对这些小区进行了一定的优化调整。

理论模型：当某用户在某LAC下的一个小区下成功被寻呼到后，此时假定小区为用户的驻留小区，并记成功寻呼一次；当对该用户做寻呼而且在该LAC下其他小区无响应时，则在该小区下寻呼失败一次。

同样若寻呼响应小区和原小区不同，则将驻留小区变更为当前小区，不记为原小区失败；当用户离开该LAC区，自然也不会产生寻呼消息。

按照上述统计原则做长期的统计就可以计算出寻呼较差的小区。

这样的结果虽然是一种估算，但可以反映寻呼的整体情况，对统计并提高寻呼成功率有重要的意义。

详细结果如下：针对一、二次寻呼时长，我们做了一下分析，以MSC2为例：一次寻呼为起始时间，得到第一次寻呼相应的时间分布图如下：一次寻呼的响应时间平均为1秒，主要部分集中在0.45秒---2秒这个间隔。

以一次寻呼为起始时间，得到第二次寻呼相应的时间分布图如下：二次寻呼响应平均时长为6.2秒,主要部分集中在5.5秒---8秒这个间隔。

而JNMSC2的一次寻呼时长设置为5s,并且只有当一次寻呼时长计时器超时才会发起二次寻呼，二次寻呼时长设置为6s，此设置能够保证用户有足够的时间被寻呼到。

下面是一次成功的寻呼流程：从上面的流程中，我们对无线侧影响寻呼的相关因素进行汇总，并参考小区掉话情况对部分相关参数进行优化调整：无线侧影响寻呼成功率的因素/参数主要涉及以下几个方面：●覆盖问题●过多的位置更新●网络随机接入性能差●SDCCH 拥塞●无线参数设置●BTS 硬件问题或者拥塞●MSC 和 BSC 之间的信令链路不稳定其中无线参数部分主要涉及ATT：MS是否允许IMSI ATTACH/DETACH。

寻呼问题常见案例

寻呼问题常见案例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 消息的话，也就不会触发后续的寻呼过程。

优化案例分析

优化案例案例1：问题现象：为充分利用无线信道资源，减少切换，开通了900/1800 COMMON BCCH功能。

但通过掉话投诉分析，发现部分掉话集中在开通COMMON BCCH的小区上，通过NBL参数调整，解决了此问题。

兰州优化人员结合用户投诉和测试情况分析，发现高掉话小区多为COMMON BCCH小区。

首先更换了基站的同步线和主控板，但问题没有解决。

后经过测试数据回放，分析发现这些小区都存在指配失败过多的问题，判断为NBL参数设置问题。

NBL参数作用是，当用户要占用COMMON BCCH小区1800M载波时，由于1800M 载波比900M载波的电平值要低，所以系统会对其电平进行补偿，NBL值就是这个补偿值。

当NBL值设置不合适时会造成用户占用不到1800M的小区，进而导致指配失败，造成掉话。

检查NBL值发现这些小区NBL值设置都为-10，通过分析测试数据得出应该设置为10。

重新优化更改了这些小区的NBL值后高掉话现象得到了明显改善。

案例2：问题现象：用户投诉GPRS上网速度慢？定西优化人员在处理GPRS用户投诉上网速度慢的过程中，结合用户投诉和测试情况，初步判断为静态信道配置不足问题。

重新核查每个基站的静态信道配置情况，发现配置资源富富有余，进一步测试分析发现手机上网网速满的情况集中在部分基站，同时这些基站分布随机，从而怀疑为每个EBRP组下配置的信道数过多造成DSP处理能力不足。

根据此判断，重新核查每个EBRP组下的每个DSP上配置的信道数，发现EBR组3下的DSP 2上配置的信道数达到了60多条，远远超过了配置要求的40条，并且配置在该DSP上的基站全是一些乡镇站型配置较大的重要基站。

从数据核查的结果可以得出结论，是由于DSP资源配置不合理，造成用户使用GPRS业务时感觉网速比较慢。

重新优化配置了每个DSP下的信道数后，测试上网速度正常，回访用户反映也恢复正常。

案例3：问题现象：当基站缺少扩容板件同时又存在话务溢出时，怎样利用参数调整减少话务拥塞？1）、开启半速率：减少话务拥塞是提高无线系统接通率的有效办法。

WCDMA网络寻呼信道拥塞解决方案

WCDMA网络寻呼信道拥塞解决方案通过分析寻呼信道（PCH）承载能力以及寻呼消息中所占用字节数量，提出了一种评估WCDMA网络负荷的方法。

针对现网中PCH负荷较高的问题，论证了几种优化解决方案的可行性，并最终采取RAC分裂解决，通过效果评估，PCH 负荷的优化，在降低网络寻呼负荷、提升寻呼成功率和接通率等方面有良好效果。

标签：RAC分裂；PCH；寻呼类型；寻呼信道；寻呼负荷；寻呼信道拥塞引言寻呼是网络联系UE的重要途径，和其他流程相比较，寻呼流程在无线网络中表现出频率高、流量大、突发性强等特点，寻呼性能关系到整个无线网络的性能。

所以研究寻呼问题对无线网络性能具有很强的现实意义。

1 寻呼过程及原因1.1 寻呼发起CN发起的寻呼：CN发起寻呼过程的目的是使CN能够请求UTRAN联系UE。

寻呼过程在IU接口使用无连接的信令过程。

CN通过发送寻呼消息触发寻呼过程，UTRAN则将CN寻呼消息通过UU接口上的寻呼过程发送给UE，使得被寻呼的UE发起与CN的信令连接建立过程。

UTRAN发起的寻呼：当系统消息发生改变时，UTRAN为了通知处在空闲模式、CELL_PCH和URA_PCH状态下的UE进行系统消息更新，会触发寻呼过程，以使UE读取更新后的系统信息。

为了触发处于CELL_PCH，URA_PCH状态下的UE进行状态迁移，UTRAN 会进行一次寻呼流程，作为对该寻呼的一种应答形式，UE会相应的发起一次小区更新或URA更新。

1.2 寻呼类型当用户处于空闲状态、Cell_PCH和URA_PCH状态时，UTRAN通过在寻呼控制信道（PCCH）上发送寻呼消息类型1来启动寻呼，用于被叫业务建立或更新系统消息。

而当用户处于Cell_FACH和Cell_DCH时，UTRAN通过在专用控制信道（DCCH）上发送寻呼消息类型2启动寻呼，用于通知用户接收下行数据或被叫业务建立，也可用于系统消息更新。

（图1）在日常寻呼负荷指标优化中可以有效参考RNC寻呼负荷指标。

华为三次寻呼优化案例

佛山短信寻呼成功率分析报告1问题分析广东华为区域短信寻呼成功率一直比较低，严重影响无线系统接通率考核指标，无线网络优化中心开展大量分析优化工作。

经过研究发现，华为设备短信的寻呼机制和语音寻呼机制是不同的，华为的短信第一次寻呼区域为本LAC，第二次寻呼区域是相邻LAC，不包含本LAC，因此导致短信寻呼成功率低，建议短信寻呼修改3次寻呼。

另一方面，短信第一次寻呼等待时长设置为5秒，是明显偏短的，在5秒内只能监听到1－2次寻呼信道，目前SLOT CYCLE INDEX＝1，每2.56秒监听一次寻呼信道，建议最小设置为2.56*2=5.12秒，考虑到接入多探针的时延，第一次寻呼等待时间应该设置得更大，由于短信的特点，建议三次寻呼的时长修改为8，5，8秒。

2话统分析佛山MSC7于4月3日17：37修改了短消息寻呼间隔时长，从（5，5，5）修改为（8，5，8），从后台查询到结果显示，数据修改已经成功：LST PAGEINTVL:;广州马场MSCe7+++ MSCe7 2009-04-07 11:59:46+08:00O&M #192914%%/*4184165*/LST PAGEINTVL:;%%RETCODE = 0 操作成功寻呼间隔信息------------寻呼间隔名称 = Default寻呼间隔T1（秒） = 7寻呼间隔T2（秒） = 8寻呼间隔T3（秒） = 5其余寻呼间隔（秒） = 5短消息寻呼间隔T1（秒） = 8短消息寻呼间隔T2（秒） = 5短消息寻呼间隔T3（秒） = 8其余短消息寻呼间隔（秒） = 5ADDS_PAGE消息间隔T1（秒） = 9ADDS_PAGE消息间隔T2（秒） = 9ADDS_PAGE消息间隔T3（秒） = 9其余ADDS_PAGE消息间隔（秒） = 9寻呼间隔索引 = 0分析4月1日至4月6日的早忙时话统数据，短信寻呼成功率提升了6％左右，达到87％；序号位置区短消息定位寻呼1次响应次数短消息定位寻呼2次响应次数短消息定位寻呼3次以上响应次数短消息定位寻呼首发次数短消息定位寻呼无响应次数短信寻呼成功率1 01/04/200910:00:0031877 1297 164 41303 7965 80.72% 2 02/04/200910:00:0029066 913 111 36804 6642 81.76% 3 03/04/200910:00:0027554 968 90 37461 8825 76.38% 4 04/04/200910:00:0011870 375 53 14945 2612 82.29% 5 05/04/2009 14838 359 58 17329 2079 88.03%10:00:0018296 489 68 21427 25976 06/04/200987.99%10:00:003分析结论：将短消息寻呼间隔定时器从（5，5，5）修改为（8，5，8），对短信寻呼成功率提升效果显著，建议全省华为区域的短消息寻呼间隔定时器都修改为（8，5，8）。

拥塞问题解析

寻呼是移动网络重要组成部分，用于寻找并呼叫那些分布在不同位置区中自由移动的注册用户终端，终端在各种状态下响应并完成网络发起的信令或业务过程，直接影响用户实际使用网络的体验。

所以寻呼对TD-SCDMA系统来说至关重要。

寻呼优化流程网络运行一段时间后就可以收集相关网络数据，通过分析网络数据发现问题，并对网络进行优化处理。

寻呼优化流程如图1所示。

对于TD网络，可能出现的寻呼问题主要是以下几点：（2）由于功率或干扰，UE没有接收到寻呼消息；（3）UE频繁发生小区重选或位置更新，无法接收到寻呼消息；（4）CN原因没有下发寻呼给RNC。

常规的寻呼问题如2、3、4条一般都是无线和核心网侧的问题，这里不再赘述。

而资源不足是TD系统联调方面的情况，比如由于短信群发导致寻呼拥塞，该问题是TD网络在奥运期间出现的，下面我们重点讨论寻呼拥塞的相应优化措施。

寻呼拥塞案例在奥运期间，部分TD外场出现过由于群发短信业务导致网络侧寻呼拥塞的情况，中兴通讯优化团队对其进行了分析并提出优化方法。

根据统计，奥运期间外场寻呼拥塞率统计如表1。

从表1可以看到有两个城市的寻呼拥塞率都在10％左右，这意味着拨打10次电话或者发送短消息只有9次寻呼成功。

该问题直接影响到用户使用网络的实际体验。

拥塞原因分析我们在后台通过CN侧的CS短信寻呼图与RNC侧寻呼统计图可以看出，短信寻呼下发次数的超高峰（11:30~11:40，20:30~20:40）和高峰（13:35~13:45，22:30~22:40）在CN侧与RNC侧出现的时间点完全吻合，说明拥塞并在RNC侧和CN侧同时存在，可以认为拥塞是整个系统的问题。

对CN侧CS域语音寻呼进行统计，可知CS域语音寻呼（以5分钟为粒度）一天的变化趋势是正常的，说明现网中的寻呼拥塞并没有影响客户对语音业务的主观感受。

对CN侧PS域语音也进行了寻呼统计，可知PS域寻呼（以5分钟为粒度）一天的变化趋势也是正常的，说明现网中的寻呼拥塞，也没有影响PS域业务的客户主观感受。

校园高话务区域寻呼拥塞问题优化报告

校园高话务区域寻呼拥塞问题研究及解决方案探讨一、目前现状及主要问题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万了。

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

VOLTE寻呼拥塞分析优化案例2019年7月目录寻呼拥塞分析优化案例 (3)一、问题描述 (3)二、分析过程 (3)2.1寻呼的定义及作用 (3)2.2寻呼流程分析 (4)2.2.1寻呼流程说明 (4)2.2.2寻呼流程涉及算法 (6)2.2.3寻呼关键参数 (8)2.3寻呼流量分析 (9)2.4寻呼跟踪区分析 (10)2.4.1TA及TAL概念及作用 (10)2.4.2 系统负荷对Paging影响 (11)2.4.3 TA及TAL规划原则 (12)2.5问题定位 (14)三、解决方案及效果 (15)3.1.TAL重规划优化方案 (15)3.2.寻呼参数优化方案 (16)3.3.TAL重规划优化效果 (17)3.4.寻呼参数优化效果 (17)四、经验总结及推广 (18)VOLTE寻呼拥塞分析优化案例【摘要】LTE需要使用寻呼流程，向UE发送寻呼消息，或者向UE传送系统更新消息通知。

寻呼消息由PDSCH（Physical Downlink Shared Channel物理下行共享信道）承载，通过控制关键的寻呼参数，可以大大增加寻呼流量，有效改善寻呼拥塞。

另外，合理地规划TA（Tracking Area跟踪区）列表大小，能在TA更新的信令负荷和寻呼区大小之间寻找到一个平衡点，从而达到降低系统负荷，从而解决寻呼拥塞问题。

【关键字】paging、拥塞、TAL、maxNoOfPagingRecords、nB【业务类别】核心网、参数优化一、问题描述省公司通过寻呼拥塞指标的监控分析，发现东莞的寻呼拥塞情况异常严重，需要对相应的寻呼拥塞进行分析处理，从而避免网络事故出现。

下面是东莞寻呼拥塞情况：东莞电信爱立信区域寻呼拥塞率59.69%，寻呼丢弃数量达到百万级，相应的寻呼信道占用率也达到了77.92%；华为区域寻呼拥塞率11.53%，寻呼丢弃数量为7万多，相应的寻呼信道占用率为14.14%。

也就是说东莞寻呼拥塞问题主要集中在爱立信区域，需要进行针对性的分析优化去解决寻呼严重拥塞问题。

二、分析过程为了找到寻呼拥塞的原因，需要将寻呼相关的内容进行梳理分析，以发现存在的问题。

2.1 寻呼的定义及作用寻呼消息（Paging）是LTE中重要的系统消息，主要用于网络寻找UE，以及UE响应网络下发的呼叫请求。

在LTE中，网络可以向空闲状态和连接状态的UE发送寻呼，寻呼过程可以由核心网（MME）触发，用于通知某个UE接收寻呼请求；或者由基站（eNode）触发，用于通知系统信息更新，以及通知UE接收ETWS（Earthquake and Tsunami Warning System地震海啸告警系统）以及CMAS（Commercial Mobile Alert System商用移动警报业务）等信息。

Paging 消息的作用包括：（1）向处于RRC_IDLE 态的UE 发送呼叫请求；（2）通知处于RRC_IDLE 和RRC_CONNECTED 态的UE，系统信息发生了变化；（3）通知UE 开始接收ETWS primary 通知，和（或）ETWS secondary 通知；（4）通知UE 开始接收CMAS 通知。

2.2 寻呼流程分析2.2.1寻呼流程说明Paging消息的详细流程如下：1） eNodeB通过S1接口接收具有或不具有优先级的S1AP寻呼消息。

如果启用了优先级寻呼功能，则eNodeB会执行寻呼消息的优先级排序。

2）如果paging优先级开启，eNodeB根据优先排序paging消息，下发至UE。

3） Paging消息通过PDSCH（Physical Downlink Shared Channel物理下行共享通道）传送至TA（Tracking Area跟踪区）内所有eNodeB的小区。

在PDCCH上广播P-RNTI（Paging Radio Network Temporary Identity寻呼无线网络临时标识），在PDCCH上可以找到包含RRC寻呼消息的PDSCH数据的调制和编码方案的信息。

4） PDCCH中的信息通过CRC (Cyclic Redundancy Check循环冗余校验)传输，并采用P-RNTI进行加扰。

这将通知UEs在同一子帧中是否存在paging消息。

5）当UE在PDCCH上检测到P-RNTI时，它对PDSCH中包含的paging消息进行解调和解码，并通过PCH (Paging Channel)将其转发到MAC (Medium Access Control媒体访问控制)层。

PCH传输块包含被寻呼终端的确切标识。

如果UE在检测到的PCH上没有找到自己的标识，那么它将丢弃PCH数据并根据DRX（Discontinuous Reception非连续接收）周期循环休眠。

（图1）paging消息流程图1（图2）Paging消息流程图2 （图3）寻呼消息信道映射图2.2.2寻呼流程涉及算法根据寻呼流程介绍，系统下发的寻呼消息需要UE定期去监听，其过程如下：在一个DRX周期内，可以只在相应的寻呼无线帧（PF，Paging frame）上的特殊子帧即寻呼时刻（PO，Paging Occasion）先去监听PDCCH上是否携带有P-RNTI，进而判断相应的PDSCH上是否有承载寻呼消息。

→如果有P-RNTI，就按照PDCCH上指示的PDSCH的参数去接收PDSCH上的数据；→如果未解析出P-RNTI，则不需要再去接收PDSCH，而按DRX周期进入休眠。

根据以上机制，在一个DRX周期内，UE可以只在PO出现的时间位置去接收PDCCH，再根据需要接收PDSCH，其他时间可以睡眠，达到省电目的。

而UE监听PDCCH，需要精确知道所监听的PDCCH的具体位置，则要先计算出PDCCH出现的无线帧帧号（PF），然后再计算出PF上的寻呼时刻（PO）。

（图4）PF与PO关系示意图（1）PF相关计算公式如下：SFN mod T = (T/N) * (UE_ID mod N) （公式1）T：DRX参数。

网络会在系统消息SIB2中广播此参数给UE，其取值范围是32，64，128，256，单位是无线帧（10ms）。

nB：网络在SIB2中广播，其取值范围是4T，2T，T，T/2，T/4，T/8，T/16，T/32，单位是无线帧（10ms）。

N = min(T，nB)，取DRX和nB中的最小值，单位是（10ms）。

UE_ID = IMSI mod 1024。

（2）PO相关计算公式如下：i_s =floor (UE_ID/N) mod Ns （公式2）N：min(T，nB)Ns：max(1，nB/T)UE_ID：IMSI mod 1024PO实际是UE需要监听的PDCCH在寻呼无线帧上的子帧号。

因此计算出PF之后，再计算出本UE的PO在PF上的位置i_s，然后根据i_s与PO之间的映射关系，就可以精确获得UE该去监听的PDDCH的精确时间位置。

（表1）i_s与PO之间的映射关系表Ns PO when i_s=0 PO when i_s=1 PO when i_s=2 PO when i_s=31 0 N/A N/A N/A2 0 5 N/A N/A4 0 15 62.2.3 寻呼关键参数在爱立信厂家基站中的相关Paging参数定义中，主要有下列几个：（1）maxNoOfPagingRecords：一个RRC寻呼消息中包括的最大允许寻呼记录数，即每个PO可以寻呼的最大UE。

（表2）各频段maxNoOfPagingRecords最大值（2）defaultPagingCycle：表示paging周期中的无线帧数。

这是eNodeB使用的paging周期，并在SIB2中广播。

如果在来自MME的寻呼消息中提供UE特定的DRX周期，其比defaultPagingCycle值短，则来自MME的值将覆盖eNodeB中的值。

它的作用是可以通过将defaultPagingCycle参数值乘以10 ms来计算用户设备的PO之间的时间。

（3）nB：当nB设置为T，2T或4T时，它影响每个PF的PO数量，并且还确定PF内的PO位置。

当nB设置为1 / 2T，1 / 4T，1 / 8T，1 / 16T或1 / 32T时，它影响寻呼周期期间的PF数量以及将UE分配到具有相同PO的组中。

当nB设置为较小的值时，导致较少的PO，每次都有更多UE被寻呼；当nB设置为较大值时，提供了更多的PO，并且在每种情况下寻呼的UE更少。

（图5）nB设置对寻呼帧数和寻呼时间的影响（4）pagingDiscardTimer：确定在丢弃之前，可以在eNodeB中保留或排队接收的paging消息的最长时间。

该定时器应设置为与MME（T3413）中的寻呼重发定时器相同（或更小的值），以防止eNodeB在从MME接收到重新发送的副本之后保留或发送旧的寻呼消息。

2.3 寻呼流量分析每个Paging Record标识1个UE_ID，一个寻呼消息最多包含的Paging Record数量由上述关键参数maxNoOfPagingRecords决定。

根据3GPP协议maxNoOfPagingRecords最大取值为16（20M带宽小区），即LTE每个寻呼消息最多承载16个UE_ID。

在满足一定的寻呼拥塞率的情况下，单个小区每秒的寻呼流量计算公式如下：I cell=E Paging*(nB/T)*100 （公式3）E Paging：爱尔兰B表中，不同的寻呼拥塞率与对应maxNoOfPagingRecords值的映射关系值，详见（表2）爱尔兰B表。