未接通事件处理专题.docx
《未接通事件处理专题.docx》由会员分享，可在线阅读，更多相关《未接通事件处理专题.docx（39页珍藏版）》请在冰豆网上搜索。
未接通事件处理专题
泉州分公司针对未接通事件专项整治的报告
一、概述：
在省公司下发最近几次的第三方话音业务DT测试结果中，我司的接通率指标出现了较为明显的波动，同时在我司自行安排的摸底DT路测中也出现了多次遇到未接通事件，接通率指标比较不理想，如何解决未接通问题成为摆在我司网优人员的一个重要难题。
因此为了有效改善接通率指标，同时提升用户满意度，我司高度重视，专门组织人员针对未接通事件进行了详细分析及优化，并针对每次的未接通案例进行研究，总结了未接通的原因和相应的解决方法。
现将这阶段针对未接通事件专项整治工作总结如下：
二、未接通事件的分析：
认真分析了10月和11月路测过程中出现的27个未接通（包括呼叫失败）事件的原始路测文件，得出了导致每个事件的原因。
这些路测主要集中在泉州市区、晋江以及机场路。
如下表所示：
原因
次数
所占比例
1
被叫位置更新
10
37.0%
2
质量差/过覆盖/覆盖弱
5
18.5%
3
TCH拥塞
5
18.5%
4
硬件故障
2
7.4%
5
PagingDelete（10月16日LAC22981）
2
7.4%
6
被叫频繁的小区重选
1
3.7%
7
呼叫重建不成功
1
3.7%
8
上行干扰
1
3.7%
合计
27
100%
以下为每一类型事件的原因以及解决它们的方法：
1、被叫位置更新：
路测中由于被叫做位置更新导致未接通是一个主要问题。
从上表统计中看，所遇到的27个事件中有10个是由于被叫做位置更新引起的，占所有事件中的37%。
事件描述如下：
当主叫发起呼叫时，被叫正跨LAC边界并进行位置更新。
在此期间寻呼将会失败，因为被叫尚未完成位置更新，对被叫的寻呼消息会被发往原来的LAC，二次寻呼也仍然不会成功，因为此时的二次寻呼还是在原来的LAC里发送。
从下面的层三信令看，可以看出MS1完成信令到“CallProceeding”，但是在BTS成功地发送寻呼信息给MS2之前，MS2进行了位置更新。
二次寻呼以及后续的寻呼都将会失败，因为MS2现在处于一个新的LAC。
解决方法1:
FEAT93858
使用NOKIANSS的FEAT93858功能，这会解决MSC内的LAC边界由于被叫位置更新导致未接通的问题。
这个功能是一种寻呼机制，可以提高二次寻呼手机时的成功率。
当主叫呼叫被叫，而被叫恰好在做位置更新，第一次寻呼将会失败，因为此时网络不知道被叫位置更新到哪里。
位置更新处理需要2S时间，在2S之后，被叫位置更新已完成。
MSC在第一次寻呼失败后，间隔3S后做第二次寻呼。
在开启FEAT93858功能的情况下，第一寻呼失败后，MSC将在二次寻呼前从VLR中寻找目前手机的当前位置信息，然后在新LAC下寻呼被叫并取得成功，而未开启FEAT93858功能时的二次寻呼仍然在原来的LAC下进行将导致未接通。
此功能可以有效改善同一MSC下LAC边界由于被叫位置更新导致未接通的问题，但对于在不同MSC下LAC边界，这个功能对改进呼叫成功率没有任何帮助。
为了验证这个功能，我们进行了模拟测试，测试方法如下：
1）将MS和路测设备处于Intra-MSC边界小区的覆盖范围内（比如说在LAC-A）。
2）使用MS2锁频于相邻LAC（比如说LAC-B）下某一小区的BCCH频点。
3）改变所锁频点，让MS2处于LAC-A下的一个小区。
4）立即用MS1拨打MS2。
5）观察信令看呼叫是否成功
6）在Inter-MSC边界使用上述同样的方法。
Intra-MSC测试结果:
MS1正在呼叫MS2，但MS2正在做LAU和RAU，没有时间监听进来的寻呼，只能监听使用IMSI的二次寻呼，并且能够响应寻呼应答此次呼叫。
事件过程：
呼叫开始时MS1主服务小区
位置更新之前MS2的主服务小区
位置更新之后MS2的主服务小区
事件发生时三层信令
上面就是在MS2做完LAU和RAU之后，使用IMSI的二次寻呼成功。
注:
上面的案例是在MS1呼叫MS2，MS2做完LAU和RAU之后二次IMSI寻呼成功。
Inter-MSC测试结果:
MS1正呼叫MS2，MS2从一个MSC下的LAC变化到另一个MSC下的LAC而进行LAU和RAU,14S之后,MS1仍然未能接通MS2而听得提示“对不起,您拨打的电话暂时无法接通,请稍后再拨”。
MS1在16:
37:
34.16发起呼叫,实际上MS2在16:
37:
37.20已经做完LAU和RAU，但是MS2仍然不能监听到来自网络对于MS1的呼叫的寻呼信息，即使使用IMSI的二次寻呼也仍然没有成功,在16:
37:
48.22,MS1听得MSC关于此次呼叫不能接通的广播。
从这看出,呼叫建立失败;MS2未能监听到第一次寻呼请求以及后续的寻呼请求。
事件过程
结论:
以上测试证明了FEAT93858功能能够像期望的那样。
使用这个功能,在intra-MSC边界的由于被叫位置更新导致未接通完全能够避免。
解决方法2:
减少乒乓位置更新
乒乓的位置更新对一个网络影响很大，不仅会影响路测时的接通率，而且还会增加不必要的信令流量。
在泉州，我们已经进行了一些调整，减少乒乓位置更新的影响。
例1:
天线倾角调整
在LAC边界的小区过覆盖到相邻LAC，这将会引起乒乓位置更新。
此类问题的最好的解决办法就是调整天线控制小区的覆盖范围。
例2:
HYS参数调整
调整LAC边界附近小区的BTS参数HYS避免空闲模式下乒乓位置更新。
通过增大参数HYS,比如,从6dB增加到8dB,不同LAC下的小区之间的小区重选将会更慢一些,只有当目标小区信号强到满足adjacent_C2>serving_C2+HYS时才会小区重选。
路测时,若增加了HYS的值,会推迟手机在LAC边界作位置更新的时间,但手机迟早都要位置更新,当目标小区的信号强于源小区加上HYS的值时,手机就要做位置更新,如果这时主叫呼叫被叫,同样会因为被叫在做位置更新而失败。
因而，对于泉州现网，仅仅选择了那些LAC边界信号强调不稳定的小区，调整其HYS参数从6dB到8dB
调整记录:
共调整了11个LAC边界小区的HYS从6dB到8dB。
解决方法3:
减少呼叫时间
修改LAC边界附近小区的BTS参数MFR（NumberofMultiFrames）,当前的MFR被设为5。
参数MFR（2…9）表明手机多长时间监听一次寻呼信息,它对手机电池的使用寿命有直接影响,参数MFR的值越小,手机需要更频繁的监听自己的寻呼组,这就会使得手机更耗电,而且,呼叫建立时间也更快了.当MFR设为5时,手机需要5*235ms=1.175s的时间响应寻呼,可以让MFR更小一点,当设为2时手机需要2*235ms=0.47s的时间响应寻呼.这样,在路测时,被叫将会更加频繁的监听寻呼信息.提高了呼叫成功率,因为被叫手机在位置更新前去监听寻呼请求的次数提高了。
如果被叫先做位置更新，调整MFR参数根本没有任何作用。
调整记录:
共调整了22个LAC边界小区的MFR从5到2。
2、质量差/过覆盖/弱覆盖
27个事件中，其中有5个是由于质量差/过覆盖/覆盖弱所引起的，占所有未接通中的18.5%。
通过优化，可以通过优化有效减少这种原因的未接通问题。
事件描述如下：
在呼叫建立阶段，不管是主叫还是被叫，质量差和信号弱都会引起信令丢失和未接通，从“CMServiceRequest”到“Connect”阶段的信令丢失，都将会被认为未接通。
下面的例子是一个典型的由于质量差和过覆盖所致的未接通。
MS1小区重选到过覆盖的小区13532，13532的信号不稳定。
MS1发送“ChannelRequest”信令来发起呼叫，因为13532的信号场强和质量很不稳定,第一条“ChannelRequest”信令失败。
之后MS1又发送了2次（RET=2）“ChannelRequest”信令，第三次才成功获得了BTS的响应信息“ImmediateAssignment”。
之后MS1继续发送“CMServiceRequest”信令，但是由于质量差，没有得到BTS得响应直到T200计时器超时。
解决方法:
对于上面这个例子，质量差是由于小区13532过覆盖，而江滨路没有明显的主服务小区所致。
通过调整13532得下顷角和降功率，很好地控制住其覆盖，之后还勘察调整了小区13401,13403和11072以保证江滨路的覆盖。
另外，还有一些是通过修改频点解决的。
3、TCH拥塞
27个事件中，其中有5个是由于TCH拥塞引起的，占所有事件中的18.5%。
通过扩容和使用半速率，能避免由于此中原因导致的未接通。
事件描述如下：
被叫和主叫的TCH拥塞都能造成未接通，根据三方测试规范，有“ChannelRequest”或者“CMServiceRequest”信令但是没有“Connect”或者“ConnectAcknowledge”信令都是未接通。
下面的例子是一个典型的被叫拥塞.
例子:
MS2因为TCH拥塞而未接通。
MS2已经应答了寻呼并正常的呼叫建立，因为没有可用的TCH信道，网络下发TCHassignmentfailed信令。
从三层信令上可看出，MTC信令完成到“CallConfirm”但是没有可用的TCH信道分配。
服务小区CI13963,RX_LEV-60dBm,quality1,呼叫由网络下发DISCONNECT信息断开。
解决方法:
解决此种问题最好就是增加TCH信道,这可以通过TRX扩容或者增加半速率。
4、硬件故障
在27个事件中，其中有2个是由于硬件故障造成的，这两个未接通都是发生在小区8082。
事件描述如下：
从三层信令上看,MS1发送“CMServiceRequest”之后,BTS没有响应，最后T200计时器超时导致未接通。
从测量报告可以看出信号强度和质量都非常好（RxLev=-55dBm,RxQual=0）。
这应该是一个SD掉话。
查看故障小区列表,小区8082有7949告警（DIFFERENCEINRXLEVELSOFMAINANDDIVERSITYANTENNA/TRX），
KPI指标显示此小区SDCCH掉话率非常高（47%）,800掉话率3.2%，TCHAssignmentBlockingRate是15%.
解决方法:
小区8082是CommonBCCH小区，主BTS是Talk-Family站，EGSMBTS是Ultra-Site站型。
在将所有的BTS都换成Ultra-site站型后,小区的各项KPI指标都返回到正常水平。
下图硬件替换后KPI指标：
SDCCH掉话率从47%降低到3.8%,800掉话率从3.0%降到1.5%,TCHASSblockrate从18%降到0%，小区内切换失败率从76%降到1.7%.
在这个小区CQT测试也表明问题已解决。
5、PagingDelete
在27个事件中，其中有2个是由于pagingdelete命令造成的。
事件描述如下：
LAC22981在原来调整割接前每天17：
00的时候有较多的pagingdelete情况，当有pagingdelete命令发送时,从BTS到MTC的寻呼会被删除，这将会导致路测时的未接通。
泉州的寻呼模型很不一样，寻呼量高峰期并不在话务最忙时，而NetworkDoctor222报告只反映了话务忙时的寻呼负载情况，不能反映寻呼高峰时的情况，为了找出问题，直接使用SQL脚本直接从OMC上取得数据。
下表显示出LAC22981每小时寻呼状况，寻呼高峰是在在17：
00，MTC和MOC呼叫也最多（注:
17：
00的寻呼信息与其它时间最大不同是重呼的次多，因为pagingdeletes发生）
LAC
22981
Time
MOC
MTC
TotalCall（MTC+MOC）
PagingMSG
DeletedPagingMSG
Traffic
10.16.0612:
00AM
61901
23685
85586
55426
0
1617.89
10.16.061:
00AM
42532
11430
53962
24874
0
800.23
10.16.062:
00AM
32148
6362
38510
12902
0
392.85
10.16.063:
00AM
27279
3847
31126
7206
0
213.95
10.16.064:
00AM
24330
2684
27014
4629
0
138.11
10.16.065:
00AM
25898
2869
28767
4742
0
125.58
10.16.066:
00AM
32296
7432
39728
11169
0
230.51
10.16.067:
00AM
48800
20288
69088
29312
0
577.23
10.16.068:
00AM
78700
50731
129431
66791
0
1394.23
10.16.069:
00AM
102501
74850
177351
103562
0
2132.46
10.16.0610:
00AM
112076
80854
192930
112313
6
2408.31
10.16.0611:
00AM
115943
81120
197063
110425
0
2411.94
10.16.0612:
00PM
111885
65163
177048
99375
0
2475.47
10.16.061:
00PM
80327
43182
123509
68755
0
1606.71
10.16.062:
00PM
93871
60540
154411
91780
0
1882.16
10.16.063:
00PM
110500
77774
188274
111065
0
2303.08
10.16.064:
00PM
124831
87101
211932
114642
0
2535.35
10.16.065:
00PM
127058
98797
225855
208812
30624
2841.81
10.16.066:
00PM
124965
97002
221967
138664
5
2983.81
10.16.067:
00PM
112128
82092
194220
128463
23
2993.25
10.16.068:
00PM
98784
71233
170017
116993
4
2802.83
10.16.069:
00PM
101866
71401
173267
119576
0
3127.50
10.16.0610:
00PM
91463
59905
151368
121912
2
3159.27
10.16.0611:
00PM
70157
40557
110714
96674
0
2608.11
10.17.0612:
00AM
43403
22844
66247
52649
0
1593.48
由于pagingdelete命令导致的2个未接通恰好是在10月26日的LAC22981,一个在17：
05，另外一个在17：
31。
从三层信令上分析,主叫发起呼叫后,根本就没有被叫的寻呼响应。
看主叫和被叫所占用的小区，他们都在同一个小区（在下例中是小区11043）。
从主叫的测量报告,可以可看出信号强度很好（-78dBm），质量也很好（RxQual=0）。
因而可以判断出被叫的信号场强和质量也很好。
后来查看统计报告,发现LAC22981在17：
00到18：
00这段时间里有非常多的pagingdelete命令。
下表显示了pagingdelete命令的数量（30624次删除）.
LAC
22981
Date
PagingMSG
DeletedPagingMSG
10.11.065:
00PM
201878
33126
10.12.065:
00PM
170159
18186
10.13.065:
00PM
213826
32819
10.14.065:
00PM
156329
9982
10.15.065:
00PM
174527
20522
10.16.065:
00PM
208812
30624
10.17.065:
00PM
187050
25168
检查小区11043的KPI指标正常，没有上行干扰，sd掉话率和tch掉话率都在正常水平。
从这断定未接通是由于PagingDelete命令造成的。
解决方法:
作了一些调整减少了pagingdelete命令，大多数BTS的参数AG（NumberOfBlocksForAccessGrant）设为4，这种设置使得多数资源被AG信道占用，以往的经验，AG参数设为2或者1就已经够用。
对于Non-CombinedControlChannel,
NumberofPagingGroup=（9-AG）xMFR
对于CombinedControlChannel,
NumberofPagingGroup=（3-AG）xMFR
PagingBufferSize=freebuffers（max8）xNumberofPagingGroup.
将参数AG的值调的低一些，更多的寻呼信道被分配，寻呼容量也就更大，在11月27日还将一些基站从LAC22981和LAC22869调整到LAC22984。
经过这些调整之后,11月27日LAC22981在17：
00的paging信息减少到130,000左右，而pagingdelete也减少到300左右。
AGCH缓冲也没有溢出情况。
LAC
22981
Date
PagingMSG
DeletedPagingMSG
10.11.200617:
00
201878
33126
10.12.200617:
00
170159
18186
10.13.065:
00PM
213826
32819
10.14.065:
00PM
156329
9982
10.15.065:
00PM
174527
20522
10.16.065:
00PM
208812
30624
10.17.065:
00PM
187050
25168
11.24.065:
00PM
138184
773
11.25.065:
00PM
140768
AG调整
2430
11.26.065:
00PM
134439
96
11.27.065:
00PM
131982
312
11.28.065:
00PM
68195
BTS割接
0
11.29.065:
00PM
66755
0
11.30.065:
00PM
70564
0
在11月28日寻呼高峰时段（例如17：
00到18：
00）进行了路测，没有因为pagingdelete命令导致未接通，呼叫304,失败了2次，是由于被叫位置更新和TCH拥塞造成的。
6、被叫频繁的小区重选
27个事件中有1个是由于被叫频繁的小区重选导致。
事件描述如下：
当MS1拨打MS2，MS2先占用小区13543，然后又重选到小区8641，MS1在13541上发起呼叫之后切换到小区8641。
此次未接通，因为在MS1拨打MS2时，MS2正在小区重选并解读邻小区BCCH和BSIC码，因而不会监听网络的寻呼。
在MS1呼叫MS2时，信令上看没有寻呼请求信息，呼叫失败MS1听到网络的提示信息“对不起,您拨打的电话暂时无法接通,请稍后再拨”，频繁的小区重选可能是由于在解读和同步主服务小区的BCCH时质量太差所致。
事件过程：
1）MS1拨打MS2
2）MS2没有监听网络的寻呼信息
3）MS1呼叫建立失败（MS1会听得来自MSC提示“对不起,您拨打的电话暂时无法接通”）
4）在MS1拨打MS2时，MS2正在小区重选。
5）未接通MS1不能连接MS2
详细的三层信令分析：
结论:
经过分析,频繁的小区重选是因为在那片区域没有主控小区，调整了小区13543和8641的天线加强了这一路段主控。
7、呼叫重建失败
27个事件中，有1个是由于呼叫重建失败。
事件描述如下：
MOC信号强度弱或者质量差造成无线链路超时而掉话，因为打开了RE（CallRe-establishment）,MOC试图重新建立呼叫，发送“ChannelRequest”之后再发送“CMRe-establishmentRequest”。
根据三方测试规范的定义,这被认为是一个呼叫尝试，实际上“ChannelRequest”之后再发送“CMServiceRequest”的才是一个呼叫尝试，因而，呼叫重建失败很容易和正常的呼叫尝试混淆。
如果重建失败，BTS发送“CMServiceReject”信息给MS，就像下图所示那样：
解决方法:
在这个案例中呼叫失败和掉话的主要原因是弱覆盖和无主控小区，在SITE1107增开了一个扇区后，此路段的场强和质量得到很大改善。
下图是调整之后得情况：
8、上行干扰
27个事件中，有1个是由于呼叫上行干扰所致。
事件描述如下：
MOC发送了3条“ChannelRequest”（RACH）信息给BTS，但是BTS没有任何响应。
这意味着MOC没有“CMServiceRequest”信息，根据三方测试规范，这个不被认为是未接通，因为缺乏“CMServiceRequest”信令。
但是，这个问题也是需要解决，因为如果发生在MTC而不是在MOC，那就算是一个未接通。
MOC在小区18092上起呼，MOC发送的第一条“ChannelRequest”信息没有得到B
升级会员 