《未接通事件处理专题》由会员分享,可在线阅读,更多相关《未接通事件处理专题(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