《未接通事件处理专题》由会员分享，可在线阅读，更多相关《未接通事件处理专题（33页珍藏版）》请在金锄头文库上搜索。
1、泉州分公司针对未接通事件专项整治的报告一、 概述：在省公司下发最近几次的第三方话音业务DT测试结果中，我司的接通率指标出现了较为明显的波动，同时在我司自行安排的摸底DT路测中也出现了多次遇到未接通事件，接通率指标比较不理想，如何解决未接通问题成为摆在我司网优人员的一个重要难题。因此为了有效改善接通率指标，同时提升用户满意度，我司高度重视，专门组织人员针对未接通事件进行了详细分析及优化，并针对每次的未接通案例进行研究，总结了未接通的原因和相应的解决方法。现将这阶段针对未接通事件专项整治工作总结如下：二、 未接通事件的分析：认真分析了10月和11月路测过程中出现的27个未接通（包括呼叫失败）事件的
2、原始路测文件，得出了导致每个事件的原因。这些路测主要集中在泉州市区、晋江以及机场路。如下表所示：原因次数所占比例1被叫位置更新1037.0%2质量差/过覆盖 /覆盖弱518.5%3TCH拥塞518.5%4硬件故障27.4%5Paging Delete (10月16日 LAC22981)27.4%6被叫频繁的小区重选13.7%7呼叫重建不成功13.7%8上行干扰13.7%合计27100%以下为每一类型事件的原因以及解决它们的方法：1、被叫位置更新：路测中由于被叫做位置更新导致未接通是一个主要问题。从上表统计中看，所遇到的27个事件中有10个是由于被叫做位置更新引起的，占所有事件中的 37% 。事
3、件描述如下：当主叫发起呼叫时，被叫正跨LAC边界并进行位置更新。在此期间寻呼将会失败，因为被叫尚未完成位置更新，对被叫的寻呼消息会被发往原来的LAC，二次寻呼也仍然不会成功，因为此时的二次寻呼还是在原来的LAC里发送。从下面的层三信令看，可以看出 MS1完成信令到 “Call Proceeding”，但是在BTS成功地发送寻呼信息给 MS2之前， MS2 进行了位置更新。 二次寻呼以及后续的寻呼都将会失败，因为MS2 现在处于一个新的 LAC。解决方法1:FEAT 93858使用 NOKIA NSS的 FEAT 93858 功能，这会解决 MSC内的 LAC边界由于被叫位置更新导致未接通的问题
4、。这个功能是一种寻呼机制，可以提高二次寻呼手机时的成功率。当主叫呼叫被叫，而被叫恰好在做位置更新，第一次寻呼将会失败，因为此时网络不知道被叫位置更新到哪里。位置更新处理需要2S时间，在2S之后，被叫位置更新已完成。MSC在第一次寻呼失败后，间隔3S后做第二次寻呼。在开启FEAT93858功能的情况下，第一寻呼失败后，MSC将在二次寻呼前从VLR中寻找目前手机的当前位置信息，然后在新LAC下寻呼被叫并取得成功，而未开启FEAT93858功能时的二次寻呼仍然在原来的LAC下进行将导致未接通。此功能可以有效改善同一MSC下LAC边界由于被叫位置更新导致未接通的问题，但对于在不同MSC下LAC边界，这
5、个功能对改进呼叫成功率没有任何帮助。为了验证这个功能，我们进行了模拟测试，测试方法如下：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的二次寻呼，并且能够响应寻呼应答此次
6、呼叫。事件过程：MS1 正在呼叫MS2MS2 做 LAU和 RAU能在LAU和RAU之后响应二次寻呼（用IMSI）呼叫开始时MS1主服务小区呼叫时MS1主服务小区位置更新之前MS2的主服务小区位置更新之前MS2的主服务小区位置更新之后MS2的主服务小区位置更新之后MS2的主服务小区事件发生时三层信令MS2位置更新MS1 呼叫建立信令”Call proceeding”阶段, 开始寻呼MS2MS2没有监听对自己的寻呼消息，而是仍然在做 RAU.MS1 开始呼叫 MS2当MS2做 RAU时, 不会监听进来的寻呼消息, MS1仍在等待呼叫的连接MS2响应寻呼, 时间是MS1“call proceedi
7、ng”信令后的6SMS2做完 RAU后，开始监听寻呼信息，这个寻呼是用IMSI寻呼的二次寻呼IMSI寻呼MS2响应IMSI 寻呼上面就是在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
8、 已经做完LAU和RAU，但是MS2仍然不能监听到来自网络对于MS1的呼叫的寻呼信息，即使使用IMSI的二次寻呼也仍然没有成功,在16:37:48.22, MS1听得MSC关于此次呼叫不能接通的广播。 从这看出,呼叫建立失败; MS2 未能监听到第一次寻呼请求以及后续的寻呼请求。 事件过程在 MS2不能接通后手动断开连接MS1呼叫时MS2 正在做LAU 和 RAU MS1 拨打MS2结论:以上测试证明了FEAT 93858功能能够像期望的那样。使用这个功能, 在intra-MSC边界的由于被叫位置更新导致未接通完全能够避免。解决方法2:减少乒乓位置更新乒乓的位置更新对一个网络影响很大，不仅会影
9、响路测时的接通率，而且还会增加不必要的信令流量。在泉州，我们已经进行了一些调整，减少乒乓位置更新的影响。 例 1: 天线倾角调整在LAC边界的小区过覆盖到相邻LAC，这将会引起乒乓位置更新。此类问题的最好的解决办法就是调整天线控制小区的覆盖范围。 例 2: HYS 参数调整调整LAC边界附近小区的 BTS参数 HYS避免空闲模式下乒乓位置更新。通过增大参数HYS,比如,从6dB增加到8dB,不同LAC下的小区之间的小区重选将会更慢一些,只有当目标小区信号强到满足adjacent_C2 serving_C2 + HYS时才会小区重选。路测时, 若增加了HYS的值,会推迟手机在LAC边界作位置更新
10、的时间,但手机迟早都要位置更新,当目标小区的信号强于源小区加上HYS的值时,手机就要做位置更新,如果这时主叫呼叫被叫,同样会因为被叫在做位置更新而失败。因而，对于泉州现网，仅仅选择了那些LAC边界信号强调不稳定的小区，调整其HYS参数从6dB到 8dB 调整记录: 共调整了11个LAC边界小区的HYS从6dB到 8dB。解决方法3:减少呼叫时间修改LAC边界附近小区的BTS参数MFR (Number of MultiFrames),当前的MFR被设为5。参数MFR(29)表明手机多长时间监听一次寻呼信息,它对手机电池的使用寿命有直接影响, 参数MFR的值越小,手机需要更频繁的监听自己的寻呼组,
11、这就会使得手机更耗电,而且,呼叫建立时间也更快了.当MFR设为5时,手机需要5*235ms = 1.175s的时间响应寻呼,可以让MFR更小一点,当设为2时手机需要2*235ms = 0.47s的时间响应寻呼.这样,在路测时,被叫将会更加频繁的监听寻呼信息.提高了呼叫成功率,因为被叫手机在位置更新前去监听寻呼请求的次数提高了。如果被叫先做位置更新，调整MFR参数根本没有任何作用。 调整记录: 共调整了22个LAC边界小区的MFR从 5 到2 。2、质量差 / 过覆盖/ 弱覆盖 27个事件中，其中有5个是由于质量差/过覆盖 /覆盖弱所引起的，占所有未接通中的18.5%。通过优化，可以通过优化有效
12、减少这种原因的未接通问题。事件描述如下：在呼叫建立阶段，不管是主叫还是被叫，质量差和信号弱都会引起信令丢失和未接通，从“CM Service Request”到“Connect”阶段的信令丢失，都将会被认为未接通。下面的例子是一个典型的由于质量差和过覆盖所致的未接通。MS1小区重选到过覆盖的小区13532，13532的信号不稳定。MS1发送“Channel Request”信令来发起呼叫，因为13532的信号场强和质量很不稳定, 第一条 “Channel Request”信令失败。 之后 MS1 又发送了2次(RET=2) “Channel Request” 信令 ，第三次才成功获得了BTS的
13、响应信息 “Immediate Assignment”。之后MS1继续发送“CM Service Request”信令，但是由于质量差，没有得到BTS得响应直到T200 计时器超时。 Cell 13532RxQual = 7RxLev = 82dBmMS 发送“ CM service request”之后没有分配到TCH信道, T200 超时解决方法: 对于上面这个例子，质量差是由于小区13532过覆盖，而江滨路没有明显的主服务小区所致。通过调整13532得下顷角和降功率，很好地控制住其覆盖 ，之后还勘察调整了小区13401, 13403和 11072 以保证江滨路的覆盖。另外，还有一些是通过
14、修改频点解决的。 3、TCH拥塞27个事件中，其中有5个是由于TCH拥塞引起的，占所有事件中的18.5% 。通过扩容和使用半速率，能避免由于此中原因导致的未接通。事件描述如下：被叫和主叫的TCH拥塞都能造成未接通，根据三方测试规范，有 “Channel Request”或者“CM Service Request”信令但是没有 “Connect” 或者 “Connect Acknowledge”信令都是未接通。 下面的例子是一个典型的被叫拥塞.例子:MS2 因为TCH拥塞而未接通。 MS2 已经应答了寻呼并正常的呼叫建立，因为没有可用的TCH信道，网络下发TCH assignment faile
15、d 信令。从三层信令上可看出， MTC 信令完成到 “Call Confirm” 但是没有可用的TCH信道分配。服务小区 CI 13963, RX_LEV -60dBm, quality 1, 呼叫由网络下发 DISCONNECT 信息断开。无信道可用解决方法:解决此种问题最好就是增加TCH信道,这可以通过 TRX 扩容或者增加半速率。 4、硬件故障在27个事件中，其中有2个是由于硬件故障造成的，这两个未接通都是发生在小区8082。事件描述如下：从三层信令上看, MS1 发送 “CM Service Request”之后, BTS没有响应，最后 T200 计时器超时导致未接通。从 测量报告可以看出信号强度和质量都非常好 (RxLev= -55dBm, RxQual =0)。 这应该是一个 SD掉话。 查看故障小区列表, 小区 8082 有 7949告警 (D
