寻呼成功率指导书

1、1. 寻呼成功率的背景及定义2. CN侧影响因素分析及提高手段3. B侧相关因素分析及提高手段4. 案例分析应用寻呼成功率指导书第一章寻呼成功率的背景及定义背景无线寻呼成功率取自所有的端局(VMSC,移动用户做被叫或接收短消息过程中端局(VMSC向所属用户发起寻呼情况的统计,即寻呼成功之和与寻呼尝试之和的百分比。寻呼成功率考核各地无线覆盖情况、网络运行维护优化的质量等。这项指标的高低反映网络的覆盖规模,网络覆盖本质上是无线的问题,应归于基站的密度、发射接收功率的设置等。通常,每期工程的顺利完成寻呼成功率就会有所提高,而且这个提高幅度同工程的规模成正比。网络优化的目的是尽可能使得寻呼成功率达到工

2、程设计应该达到的水平。那么这项反映网络覆盖的指标如何优化呢?BSS当然是这项指标的理想跟踪对象,可以将大的系统指标分解到各个小区来定点分析,通过对各个小区或基站的障碍清除、参数调整、高度调整及俯仰角变换等等手段来达到无线的最佳覆盖,从而优化寻呼成功率。其次在NSS一边也有一些优化手段可以提高这项指标。本文主要讲述NSS侧的一些优化手段。寻呼流程 定义系统寻呼成功率=寻呼响应次数/寻呼请求次数*100%寻呼响应次数指本地区所有MSC收到的PAGING RES消息的响应总和。包括重复寻呼的响应。统计点为MSC。寻呼请求次数定义:指本地区所有MSC发出的首次PAGING消息(不包括重复寻呼的总和,统

3、计点为MSC。语音寻呼成功率=语音寻呼响应次数/语音寻呼请求次数话统指标目前版本的实现,对于寻呼方面的统计有四个测量指标:MSC基本表测量寻呼过程测量MTC呼通率测量位置区话务测量话统公式:系统寻呼成功率以MSC基本表测量的寻呼响应次数和寻呼次数的比率为准。<备注>B侧的寻呼成功率指标是以BSC为单元进行测量,而N侧的寻呼成功率指标分为两种:一是以MSC为单元进行测量;二是以位置区为单元进行测量。第二章 CN侧影响因素分析及提高手段第一节寻呼策略影响分析当发现寻呼成功率下降时,首先查看无线环境是否有调整过?无线信号覆盖状况如何?(基站覆盖区域是否有比较多的掉话?较多则说明无线覆盖差

4、。BSC是否有PCH过载告警(考虑是否有大量群组短信、全网寻呼、大量立即指配。一般情况下,在MSC 可以通过以下调整寻呼策略来优化寻呼成功率。1寻呼次数和寻呼间隔;对位置区容量较大的位置区,建议寻呼重发次数不能太大,且寻呼重发间隔不能太短。原因是这样做容易造成基站过载和BSC CPU 过载,导致大量的寻呼消息被丢弃,从而造成寻呼成功率急剧下降。另外,如果寻呼重发间隔设置太短,则在所指定的寻呼次数内还没有收到寻呼响应,MSC就认为预寻呼失败并清除寻呼信息。之后,即使寻呼响应又上来,但由于寻呼信息已清除,则MSC会通过CLEAR_COMMAND拆除被叫侧无线信道。寻呼间隔设置时间太长将导致主叫用户

5、听不到PGTO(PagingTimeOut录音通知(由被叫端局向主叫用户播放用户不在服务区的录音通知,时间太短将不能收到手机终端的寻呼响应。寻呼时间间隔必须和BSS侧的寻呼响应时间配合合理,才能提高寻呼成功率。例如MSC寻呼的时间间隔为4s,但是BSS侧的寻呼响应时间大部分为4.4s,这样肯定会导致寻呼成功率较低。通过在现场观察比较设置为7秒效果最佳,目前系统均设置一般为5秒。如果无线侧资源较充足,寻呼次数建议设置3次。分析:寻呼次数和寻呼间隔的调整是对寻呼成功率的影响最大,在调整时要考虑B侧下述因素:1 PCH资源的数量;2忙时一定时间内同时被寻呼的用户数量,数量越大存在接入碰撞的几率也越大

6、;3 BTS有无重发功能;4 BTS的寻呼论选算法(决定寻呼重发次数;关于第一次的寻呼间隔:寻呼响应时间分布.jpg这个图是一个局点的现网数据统计出来的,可以看出99%的寻呼响应都是在4秒之内回的。当然B侧的无线环境太差或者BTS的寻呼队列太长也会导致寻呼响应时间超过5秒。这个值的设定与BTS的寻呼队列机制有关,不同厂商可能差异较大。附:我司的MSC/BSC/BTS寻呼过程配合分析图 以上流程中:基站寻呼队列生命周期为5000ms;计算后寻呼响应最长时间约为6840ms,再加上核心网的处理时延,会更长一些,据此建议核心网寻呼等待时间设为7000ms。2 以TMSI进行寻呼还是以IMSI进行寻呼

7、;分析:以TMSI寻呼可提高安全性,还可以增大无线信道上的寻呼合并比(提高PCH的利用率,对于这种情况一般是先用TMSI 进行寻呼,最后一次使用IMSI进行寻呼。另外以IMSI寻呼还可解决个别用户TMSI临时出错的情况。寻呼必须有IMSI,利用TMSI 寻呼也必须携带IMSI,TMSI寻呼并不是减少寻呼数量,而是节约资源。一个PCH只能同时对两个IMSI进行寻呼,但是一个PCH 可以同时对4个TMSI进行寻呼,相当于PCH扩容。MSC下发的寻呼报文只会携带一个用户的信息,一般既有TMSI和IMSI,或者只有IMSI,此时BSC会做一个判断,如果有TMSI,这时BSC就给BTS下发携带该TMSI

8、的寻呼报文,如果没有TMSI,BSC就给BTS下发携带该IMSI的寻呼报文。寻呼报文到达基站后,为了有效利用无线资源,BTS会进行寻呼合并,即Um接口下去的一个寻呼报文会携带4个TMSI,不够就用填充位填充;或者2个IMSI,不过一般IMSI合并比较困难,复用比只有1: 1.2左右。综上所述:IMSI只用于给BSC,用于进行寻呼编码,并不是用于真正下发寻呼处理。一个手机只监视在PCH的一个地方,BTS下发寻呼时,必须根据IMSI进行编码,但BSC会做一个判断:如果有TMSI,就使用TMSI进行寻呼,如果只有IMSI,则使用IMSI寻呼。因为有时系统下发的TMSI,手机并不认识,因此应该设置至少

9、存在一次使用IMSI寻呼。<案例>用户在MSOFTX3000中第一次寻呼后,如果从SGSN发过来一个位置更新的消息,更新了TMSI后,MSOFTX3000依旧以原有TMSI进行寻呼分析:在现有的设计处理下,如果在寻呼时进行了位置更新,本次呼叫寻呼携带的TMSI不改变,这是正常情况。解决方法:以上情况发生的机率很小,对业务也不是很大影响如要修改(即第一次寻呼后发生位置更新,修改成以新TMSI进行寻呼,实际意义不大,而我们要做的改动大。规避方法:用户担心在信号较弱的地区因为寻呼过程长,而此过程中发生了位置更新导致寻呼失败,我们可以用下面的方法来规避:MOD PGCTRL配置最后一次寻呼

10、使用IMSI,而不是TMSI说明:对于没有分配TMSI的情况,系统自动用IMSI进行寻呼。建议:如果无线侧寻呼信道较为充足,建议每次寻呼都IMSI,否则最后一次使用IMSI(前面几次使用TMSI。3 按照按照位置区进行寻呼还是进行全网寻呼(MSC覆盖范围;分析:现网一般都是按照位置区进行寻呼的;现网存在这种可能:用户刚漫游到新的位置区,未及时发起位置更新,发起全网寻呼可提高寻呼成功率;注:这种事件的概率一般不大。但发起全网寻呼,会极大增加B侧的寻呼话务量,导致PCH拥塞。建议:对位置区容量较大的位置区,建议不启动全网寻呼。因为这样做容易造成基站过载和BSC CPU过载,导致大量的寻呼消息被丢弃

11、,从而造成寻呼成功率急剧下降。但对于位置区容量较小的位置区,可通过启动全网寻呼来提高寻呼成功率。4 是否启动预寻呼;分析:预寻呼是提高接通率的一个手段(如果寻呼不到,则取漫游号码失败,可提高被叫局的接通率,并且可减少资源的浪费。但启动预寻呼有下述负面影响:1预寻呼失败返回的原因值会影响主叫局的放音;2预寻呼如果间隔较长,超过HLR取漫游号码定时器时长,会影响接通率;5 是否启动PSI寻呼;分析:某些智能业务,对用户的位置信息要求精度比较高,需要发起PSI寻呼;但启动PSI寻呼会有下述影响:1根据以往的经验,某些款式手机在收到一次寻呼消息后,如果在很短时间内容又收到另一次寻呼,则寻呼成功率比较低

12、;如果同时打开了PSI寻呼和预寻呼,则两者间的时间间隔很近。2启动PSI寻呼,会使得一次呼叫有两个寻呼响应,对CSSR指标有较大影响。3寻呼间隔如果较长,超过HLR对应定时器,则可能对呼叫流程产生影响,目前已知通过签约方式触发的彩铃业务会有影响;如果没有特殊需要,建议不要打开PSI寻呼。<备注> PSI寻呼和预寻呼的启动与否不直接影响B侧的寻呼成功率指标,但由于影响B侧的CSSR指标,因此需按照具体情况取舍。6 联合寻呼分析:联合寻呼是在网络同时提供语音业务和分组业务情况下出现的,适用于即签约了GPRS业务,也签约了语音业务的用户(下面称为联合寻呼用户,且手机要支持GPRS业务。对

13、于联合寻呼用户做语音被叫的寻呼,寻呼路由一般从Gb口下发,如果Gs口故障,则从A接口下发寻呼。当用户状态异常时才可能从两个接口联合下发(此时会统计为两次寻呼。(仅使用华为公司产品从Gb口下寻呼,寻呼范围为路由区;从A口下寻呼,寻呼路由为位置区;路由区一般小于位置区(多个路由区覆盖一个位置区;因此从Gs口下寻呼,寻呼话务量要小于从A接口下寻呼。因此在现网关闭Gs口时要注意对B侧寻呼话务量的影响。7 寻呼范围寻呼范围通常设置为LAC。因此要详细检查VMSC的LAC定义,如果没填将不发寻呼消息,如果做多将发出大量没用的寻呼消息,会干扰系统处理浪费资源,因此要求NSS/BSS基站数据保持一致。寻呼策略

14、设置建议关于寻呼次数和寻呼间隔:MSC侧的寻呼次数、寻呼时间间隔应设置合理。对于MSC侧寻呼成功率的提高主要是调整寻呼方式、寻呼次数和寻呼时间间隔。寻呼次数越多,寻呼成功率也越高;寻呼时间间隔必须和BSS侧的寻呼响应时间配合合理,才能提高寻呼成功率。例如MSC寻呼的时间间隔为4s,但是BSS 侧的寻呼响应时间大部分为4.4s,这样肯定会导致寻呼成功率较低。按照现网相同地区的寻呼策略进行设置,然后由网优人员进行调试。关于用TMSI寻呼还是IMSI寻呼:一般来说,如果N侧支持TMSI寻呼,前几次寻呼都应该采用TMSI寻呼,但最后一次寻呼重发应该采用IMSI寻呼。关于是否采用全网寻呼:在覆盖地区较差

15、,且B侧寻呼负荷不高的情况下,可考虑最后一次寻呼采用全网寻呼。一般来说,寻呼方式为全网寻呼,肯定能够提高寻呼成功率。注意:并不一定是全网寻呼并寻呼次数越多,就会提高寻呼成功率,这需要考虑BSS侧的负荷,响应寻呼信道的利用率等,如果负荷本身就比较高,改为全网寻呼后,BSS侧的负荷过载,同样会导致寻呼成功率较低。PSI寻呼和预寻呼按照具体需要进行启动,但要注意相关影响。联合寻呼如果支持联合寻呼,在条件允许的情况下,建议从开启联合寻呼功能。<小结>1对于局点替换,要和原先局点寻呼策略保持一致,包括寻呼次数、寻呼间隔、对PSI寻呼和预寻呼的功能开启;不建议用全网寻呼(使用全网寻呼需考虑流控

16、方案;2对与新开局点,参照当地已有网络的寻呼策略进行设置,然后根据统计结果,再进行调整;3对于寻呼不理想的情况下,要求采取逐步调整的措施,避免一次变化太大。第二节隐含关机定时器检查MSC上的隐含关机定时器设置:终端设备(用户手机是通过周期性位置更新来保持同系统的联系,为了不占用太多CPU负荷,周期性位置更新不可能做到实时,于是在BTS上定义了周期性位置更新时长这个参数,此参数通过BCCH信道发送到BTS所覆盖的手机终端上,在正常情况下(指没有主叫、被叫、通话、切换、正常LAC越区更新位置、开机、关机等行为手机按照这个参数向系统汇报自己的状态信息。由于网络做不到无缝隙覆盖,手机自然会有脱网的情况

17、发生,或者由于网络覆盖、系统故障等问题造成手机正常关机消息不能送到VLR,这些实际情况会导致VLR不能及时将用户状态反映出来,克服这个问题方法是缩短系统诊断开机变关机的时间隐含关机定时器。隐含关机定时器超时没有收到用户的周期性位置更新请求,MSC会将用户的状态置为关机。根据网优经验,如果MSC上的隐含关机定时器的时长大于2小时,则减少MSC上的隐含关机定时器的时长对提高提高寻呼成功率的作用很明显,因为减少此定时器的时长,就使网络对处于脱网状态的手机有更快的了解。由于对隐含关机的手机不发寻呼,减少了寻呼不到机会。但是问题是它在提高寻呼成功率的同时,也会提高“用户已关机”这种问题的次数。建议MSC

18、隐含关机定时器时长设置为BSC周期性位置更新最长时间的1.1倍到2倍。如果对寻呼成功率要求很高,可以考虑缩短IMSI隐式分离时间为比周期性位置更新长510分钟。第三章 B侧相关因素分析及提高手段B侧相关影响因素寻呼成功率是一个系统级的问题,影响寻呼成功率的B侧因素主要有:1、基站覆盖情况;2、信令信道是否拥塞;3、位置区划分的合理性、上下行平衡情况;4、寻呼相关参数设置。如:上下行接入门限参数、周期位置时间(T3212等;5、手机质量问题。B侧提高手段1 开启BTS寻呼重发功能为了提高寻呼成功率和寻呼效率,基站侧增加了寻呼重发功能,这样可以解决一些由于偶尔的无线链路传输质量差而造成的移动台暂时

19、无法正确接收寻呼命令问题,而对于持续的无线链路传输质量差而造成的移动台暂时无法正确接收寻呼命令问题继续依赖于MSC侧的寻呼重发来解决。另外,由于基站侧实现了寻呼重发,减少了MSC侧寻呼重发量,一定程度上降低了整个网络侧的信令负载。修改参数“寻呼次数”(小区属性表开启BTS寻呼重发功能(建议设置为4次。参数“寻呼次数”含义:在BTS2X基站中本参数用于BTS决定寻呼重发,它与MSC内配置的寻呼次数共同控制寻呼的重发次数,总共的寻呼次数近似为两者相乘值。华为BSC没有重发机制,收到一条寻呼消息处理一条寻呼消息。华为BTS支持寻呼重发机制。2 合理设置MSC周期位置更新时间适当减小MSC周期位置更新

20、时间,且设置BSC的周期位置更新定时器T3212稍小于MSC周期位置更新时间(MSC(VLR的位置更新周期要求是BSC的位置更新周期的23倍有利于寻呼成功率的提高。当MSC 附着分离定时器(Detach Timer超时后,VLR 将把处于覆盖盲区或关机的手机设置为隐性关机,此时MSC也不会下发寻呼。在保证不发生信令过载的条件下,适当减小BSC、MSC周期位置更新时间。注意:同一位置区下不同BSC的周期位置更新时间设置为一致,并且BSC的周期位置更新时间小于MSC的周期位置更新时间。建议B侧位置更新周期不小于1小时,MSC侧时间应大于B侧时间【案例】位置更新周期设置过小引起移动台掉网现象描述某G

21、SM局有4个BTS2.0基站,网络运行一直正常。从某天开始,出现用户突然掉网。处理过程(1从硬件进行检查,从OMC的BTS远端维护台上查看各个基站HPA、TRX状态正常,各TCH、SDCCH上都有用户占用。(2再检查BSC的硬件,各GMPU、GLAP、BIE以及CK3的单板指示灯都正常。根据以上情况,可以排除肯定基站侧硬件部分出问题的可能性。(3近期该局的数据没有修改,唯一的区别就是用户数量大幅度增加。VLR中本地用户4000多,漫游用户5000多。由此推断,问题可能是由于用户突然增加。(4用户增加给网络带来的压力主要反映在两方面:TCH(话音信道拥塞率增高,当局部地区TCH被占用满以后,会引

22、起其余用户无法发起主叫,也无法接听电话。SDCCH(信令信道拥塞率增高,当局部地区SDCCH被全部占用以后,移动台不能进行正常的信令交互。移动台除了不能作主叫和被叫以外,也不能成功的进行位置更新,而位置更新失败的直接后果就是移动台掉网。(5检查BSC的系统消息数据表,发现周期位置更新时限值设置为2(单位:6分钟,即周期性位置更新时间设为12分钟。MSC对应的时间设为30分钟。这种设置使所有已经激活的移动台每12分钟就会通过SDCCH发起一次周期性位置更新,当用户数量增加到一定时,SDCCH全部被占满。此时如果移动台再发起周期位置更新,由于没有空闲的SDCCH可用,周期位置更新失败,移动台就会掉

23、网。(6将BSC的周期位置更新时限值更改为10,即60分钟,将MSC对应的时间改为180分钟。通过两天的观察,没有用户投诉,问题解决。建议与总结MSC(VLR的位置更新周期要求是BSC的位置更新周期的23倍。BSC的位置更新周期时间越短,网络的总体服务性能越好。但网络的信令流量增大,无线资源的利用率降低。此外,MS的功耗增大,使系统中MS的平均待机时间大大缩短。在设定本参数值时, MSC、BSC的处理能力,A接口、Abis接口、Um接口以及HLR、VLR的流量等都要全面考虑。一般市区设置较大,郊区和农村设置较小。3 适当降低“RACH最小接入电平”参数“RACH最小接入电平”(小区属性表设置越

24、小,对提高寻呼成功率越有利。参数“RACH最小接入电平”最小可以设置为0 (表示对上行接入电平不限制。由于影响寻呼成功率和掉话率的网优参数是互相制约的,通过降低“RACH 最小接入电平”可以提高寻呼成功率,但会造成掉话率增加。4 适当降低“MS最小接收信号等级”参数“MS最小接收信号等级”表示MS接入系统所需要的最小接收信号电平,缺省值为8。为了提高寻呼成功率,可以适当降低该参数。该参数设置过低同样会导致掉话增加,需要采取优化掉话的措施。5 适当增大“MS最大重发次数”参数“MS最大重发次数”(系统消息数据表表示MS在同一次立即指配进程中允许发送Channel Request消息次数的上限。参

25、数设置值越大,试呼的成功率越高,接通率越高,但同时RACH信道的负荷也越大。参数“MS最大重发次数”缺省值为4次,为了提高“寻呼成功率”,可以设置该参数为7次,但要密切关注RACH信道的负荷。<注> MS最大重发次数表示允许手机在收到立即指配消息前重新发送的信道请求消息的个数,即手机可以发送的信道请求个数为M+1。它是2比特编码,范围0-3对应的最大重发次数为1、2、4、7次。增大该参数即允许手机收到寻呼后多次进行信道请求次数来响应寻呼,适用于无线环境较差的情况下使用。6 减小信令信道的拥塞信令信道拥塞可能造成寻呼消息丢失,直接影响寻呼成功率。A口信令链路拥塞、PCH拥塞、SDCC

26、H拥塞都会导致寻呼成功率下降。信令信道是否拥塞可以从话统中的PCH过载率、SDCCH拥塞率、立即指配成功率(是否存在AGCH拥塞等指标查看。7合理划分位置区位置区划分不合理,也会影响寻呼成功率。位置区划分建议:1、LAC的范围必须在一个MSC下,不允许跨越MSC;2、LAC大小划分合理,不要出现寻呼过载;3、兼顾寻呼量和位置更新次数之间的平衡问题;4、避免沿主要干道和铁路划分LAC,否则会造成手机的频繁位置更新;5、一个BSC尽量不要归属于多个LAC;6、尽量做到每个LAC的PAGING量比较平均。7、LAC边界的划分要结合切换次数、话务量、BSC归属等来确定。8上下行平衡等对寻呼成功率的影响

27、如果上下行不平衡较严重,可能出现上行或下行信号很差,导致MS无法寻呼到。可以查看上下行不平衡话统,某些小区是否存在严重的上下行不平衡问题。<案例> 广西北海寻呼成功率问题北海华为区共分为3个lac区,18737、27025、27026,其中BSC2含有18737和27026两个lac区,其中18737下主要基站为合浦县城和合浦郊区的基站,27025主要为北海市区基站,27026主要为铁山港区的基站。在调整完无线和交换侧参数后,BSC2下挂lac区18737的寻呼成功率提升较为明显,提升了大约3个点左右,在90%左右,lac区27026的寻呼成功率改善不明显,而且该lac区的寻呼成功

28、率是所有3个lac中最低的,只有81%左右。由于本期替换工程中为考虑覆盖因素,增加了一部分通过PUB将发射功率达到80W的载频,按照工程规范来说应该安装塔放以解决上下行平衡问题,目前由于工程上原因所有塔放均未安装。该lac区下面有14个小区使用的是80W的载频,占整个lac区下面114个小区的12%,这样会存在上下不平衡问题,无论是对无线侧还是交换侧都有一定的影响。局方已经预计在下周开始进行塔放的安装工程。分析:下行采用80W+PBU,合路器EDU,而上行未安装塔放。确实会存在一定程度的上下行不平衡问题。上行弱,导致部分手机的PAGING RESPONSE消息报不上来,会对寻呼成功率造成一定影

29、响。9其它MSC和BSC对于CGI数据配置是否正确等会影响到寻呼成功率。接入允许保留块数、相同寻呼间帧数编码等参数,也会影响寻呼成功率,请按照数据配置规范合理设置。附:手机进入新的位置区的动作分析:1 手机一直开机情况下的进入(无线环境比较好:这个时候,是手机自己完成对选更好小区(重选或是BSC控制的(切换,这样的情况下,手机会立刻发起位置区更新的,MSC可以知道这个情况。2 手机一直开机情况下的进入(无线环境比较差:这个时候,是手机自己完成对选更好小区(重选或者BSC控制的(切换,这样的情况下,手机会立刻发起位置区更新的,如果位置更新尝试计数器小于4,MS将启动T3211定时器进行位置更新请

30、求,如果连续4次失败(即位置更新尝试计数器大于4,MS则启动T3212定时器,等待下一次周期性位置更新。这样,如果期间MSC的周期位置更新时间到了,就会把MS的状态设置为关机(即使MS已经进入好的无线环境。3 手机关机再开情况下的进入:这个时候,这个时候手机首先按HPLMN,再VPLMN进行频点搜索。如果在HPLMN里有有效频点,手机会优先选其存储的BA频点,这个期间MSC发起的寻呼MS是不会响应的,但入网后手机一定会进行位置区更新。4 手机进入盲区再进入:有些手机15秒内没服务区信号就会按手机里存储的BA表进行搜索,如果还是搜索不到有效频点就会进行全频段的搜索。(这个是一个耗时比较长的动作,

31、可能需要好几分钟到10几分钟不等这个期间MSC发起的寻呼MS是不会响应的。但有些手机就会一直优先搜索手机里存储的BA表数据。手机再次入网后,只要T3212没有超时,而且是同一位置区,手机不会发位置更新;否则会进行位置更新。第四章案例分析应用1 因交换的位置区配置有问题导致BSC整体寻呼成功率很低-0410201现象描述:新建BSC割接后,发现用户被叫寻呼成功率低大约是20-40%左右,但是主叫一切正常。在此BSC下的用户被叫时,经常听到用户不在服务区。2 告警信息:无3 原因分析:分析可能的原因:1.手机质量问题2.MSC用户状态管理不一致3.无线链路上下行不平衡4.SDCCH拥塞5.PCH过

32、载6.覆盖不全面或小区重选频繁导致7.数据配置类问题(包括BSC,MSC4 处理过程:分析出现问题的前后操作:原来有一个BSC因达到7个模块(OPT:B1,因此新建了一个BSC(多模下的1个模块,OPT:B2,把原来BSC上的5个基站倒到新的BSC下,这样MSC33下挂2个BSC。在MSC侧是用户维护工程师自己通过800指导添加的数据。仔细询问用户发现5个基站下都存在相同问题:主叫正常,被叫经常是10个电话打通2-4个左右,而且在忙时10:00-11:00打通的几率更小。1.原来5个基站在老BSC下没有问题,可以排除:手机质量问题,无线链路上下行不平衡,覆盖不全面或小区重选。2.查看告警和话统

33、分析后没有发现BSC有异常告警,基站传输也正常而且时钟也都是锁定的,SDCCH,PCH也没有过载现象。3.如果MSC对用户状态管理有异常应该在老BSC下也有类似问题,不可能只有在新BSC出现问题,于是可以排除MSC用户状态管理不一致问题4.话统里A接口下发的寻呼次数也比较少,但没有和正常值的对比关系,不能太确定这是否正常,通过A接口信令分析发现对一个用户打电话,A口没有下发寻呼。再次检查新BSC数据没有发现任何问题。检查MSC33位置区小区表,发现新BSC的位置区LAC号是和老BSC的LAC号相同的,但是在位置区小区表下这个LAC号只归属于B1,实际应该是把B2也加上。这样就可以说明,以前20

34、%左右的成功率应该是由位置区寻呼后的全网寻呼才寻呼到的。5.设定位置区小区表后,拨测发现5个基站业务恢复正常了。5 建议与总结:1、对所有可能的原因进行排除,可以对定位问题起到一个立竿见影的效果,对交换的数据配置规范我们BSS人员也该有所了解。2、还是要强调,扩容割接一定要拨测,确认设备没有问题。2 MSC寻呼策略问题导致BSC寻呼过载CPU负荷过载1现象描述:某局网络拓扑如下:华为MSC(G9,下挂一爱立信BSC,两个华为BSC A、B。该局下出现用户投诉拨打开机附着网络状态的手机经常出现系统提示:“暂时无法接通”。2 告警信息:1、MSC收到BSC发来的CCCH和CPU过载信息;2、BSC

35、流量控制告警信息。3 原因分析:由于华为A BSC 话务量较大,一个位置区话务量为2400ERL左右,CPU一直处于较高的占用率。但是发现个别时段CPU的占用率达到了96%左右,由于导致CPU占用率高的原因很多,包括话务情况,以及各种切换的数量和寻呼数量。起初怀疑为A BSC话务量过高导致的如此高的CPU占用率。但是该局下另一华为BSC B的CPU占用率也发现有较高的CPU占用率,事实上该BSC的话务量并不高,和CPU占用率根本不成正比。进一步分析话统发现虽然BSC B的话务量较小,但是一天中很多时段出现寻呼过载,由此想到MSC的寻呼策略问题,如果只是BSC B的寻呼消息不可能导致寻呼信道的过

36、载。查看BSC话统发现从MSC收到的寻呼消息达到40W条以上/小时,明显异常。寻呼过载也正是用户投诉的主要原因。4 处理过程:联系NSS工程师,了解寻呼策略,查看N侧的寻呼相关话统,由于MSC使用了3次寻呼,第一次在LAC,第二次在LAC,第三次的时候对局下的所有小区进行寻呼,而该地区的覆盖也不是很好,因此由于第一第二次的寻呼不成功,导致第三次寻呼的重发次数是惊人的,给该局下的各个BSC都带来了很大的负担,建议关闭MSC的全局寻呼功能。关闭全局寻呼后华为两个BSC均没有寻呼过载,而且两个BSC的CPU占用率分别从96%降至67%以及70降至30%。可见,导致CPU过载的主要原因是由于大量的寻呼

37、消息发至BSC所致。修改寻呼策略后发现MSC的寻呼成功率并没有降低。5 建议与总结:1、MSC的寻呼策略是非常重要的一个参数,需要根据网络的具体情况进行分析,在开启全局寻呼的适合要慎重,必须要综合考虑局下各个BSC的具体容量和负载能力,以防网络出现过负载的情况。另外,要注意分析MSC的寻呼话统,查看究竟重发的寻呼信息对于寻呼成功率有多大的影响,一般情况下如果第一次第二次寻呼不成功,第三次寻呼成功率已经很低,此时不建议打开全局寻呼。对于局下覆盖不好的地方也建议关闭全局寻呼。2、BSC CPU占用率高只是一个表面现象,导致CPU占用率高的原因很多,分析的适合要综合考虑寻呼,话务量,以及切换等各个信

38、令流程,本例导致CPU占用率异常的原因就是大量的寻呼消息导致。3 打开基站寻呼重下发功能在一定程度上提高寻呼成功率-0412301现象描述:某局用户反映网上设备寻呼成功率,拨打用户经常联系不上,寻呼成功率低造成一定的用户流失,统计交换侧寻呼成功率,早忙时一般在75%左右,低于一般的水平。2 告警信息:无3 原因分析:寻呼成功率=寻呼响应总次数/寻呼总次数,寻呼响应总次数:指本地区MSC收到的PAGING RES消息的响应总和。包括二次寻呼响应。寻呼总次数:指本地区MSC发出的PAGING消息的总和,不包括二次寻呼的消息。寻呼成功率与交换侧和基站侧都密切相关,与无线环境也密不可分,交换侧设置合理

39、的录呼策略和机制,包括MSC和BSC的位置更新时间,以及BSC的网优参数都可以影响寻呼成功率。4 处理过程:1、检查MSC的寻呼机制,保留二次寻呼下发功能。2、设置MSC和BSC的位置更新时间,根据信令负荷情况,适当减少位置更新时间。3、设置BSC的网优参数,包括RACH最小接入门限,提高用户手机的接入性能,减少部分因为覆盖信号弱造成的无法接通现象。通过以上的调整,在一定程度上提高了寻呼成功率。4、打开基站的寻呼重下发功能,将基站的寻呼下发次数由1次改为2次。这样可以解决一些由于偶尔的无线链路传输质量差而造成的移动台暂时无法正确接收寻呼命令问题,另外,由于基站侧实现了寻呼重发,减少了MSC侧寻

40、呼重发量,一定程度上降低了整个网络侧的信令负载。通过以上的调整,再统计MSC侧的寻呼成功率已经达到了87%左右,提高了10多个百分点。XXXX 指导书 5 建议与总结： 提高寻呼成功率可以有多种方式， 通过打开基站重下发功能可以在一定程度上提高系统的寻呼成功率， 这样 可以解决一些由于偶尔的无线链路传输质量差而造成的移动台暂时无法正确接收寻呼命令问题， 另外， 由于 基站侧实现了寻呼重发，减少了 MSC 侧寻呼重发量，一定程度上降低了整个网络侧的信令负载。 4 通过修改网优参数提高寻呼成功率的方法 1 现象描述： 某局 BSS 设备下挂在 S 厂家 MSC 下，从交换机侧统计寻呼成功率在 84%85%左右，而考核指标是 90%，故需对寻呼成功率这个指标进行优化。 BSS 设备上无任何告警。 寻呼成功率是一个系统级的问题，涉及 MSC、BSC、BTS、MS。其中任何一环节发生异常，都可能会影响 到寻呼