语音CQT测试上行连接失败问题分析

（中国移动通信集团设计院有限公司陕西分公司，陕西 西安 710077）

1.测试分析工具

测试工具：Pilot Walktour软件＋多普达PDA

分析工具：Pilot Navigator

2.测试方法

采用手机相互拨打的方式，手机拨叫、挂机采用手动方式，接听采用自动方式。手机与测试仪表相连；定点CQT测试人员在每个测试点的不同位置做主叫、被叫各10次，每次通话时长45秒（人工控制），呼叫间隔15秒以上；出现未接通情况，应间隔15秒以上进行下一次试呼；如出现掉话，则在掉话发生15秒后进行下一次试呼。

3.问题说明

在用鼎立后台分析软件Navigator对某市物业点进行移动2G语音CQT进行分析时，41个物业点共试呼897次，接通885次。其中有8个物业点的11次未接通出现相同原因：Event Details显示Outgoing Blocked Call，Message显示UL Disconnect，Message Details Browser的cause value显示为Normal call clearing。如图1所示：

图1

该问题特点为：

（1）问题较普遍

物业点占未接通物业点的88.9%；未接通次数占总未接通次数的91.7%。

（2）信令显示特殊

一般Disconnect信令为系统下发信令，此类问题却显示为上发信令。

（3）时间特殊

所有Disconnect问题均发生在Alerting之后的5-10秒内。

4.信令分析

由表1可知：在主叫发起Channel Request（信道请求）和CM Service Request（CM业务请求）后，网络会向主叫移动台指配链路。一旦链路指配成功，网络会指示被叫手机启动告警（Alerting），然后指示连接被接受（Connect）。

而本问题中，在Alerting之后，出现了Disconnect，指示连接失败。就该问题，笔者列举出几种可能原因，并逐一分析。

5.问题分析

5.1 测试软硬件问题

首先，笔者怀疑是测试软硬件出现不稳定，导致测试中断。

对比分析8个物业点的信令发现：Dis-connect之前Pilot Navigator显示信令正常，未出现丢失信令等问题。

据测试人员反映：手机、电脑及其他配件在问题发生时未有死机或电池不足等现象。

由此可排除测试软硬件问题。

图2

表1 移动主叫的正常通话时主要信令流程

5.2 网络问题

很多连接失败是由于弱覆盖、切换不成功导致，本问题出现的是否为连接过程中突然出现弱覆盖，导致主叫无法继续连接，或者突然进入切换区，出现切换失败而引起的呢？

（1）覆盖分析

图2为问题物业点GSM Radio窗口视图。

其中：

RxLevFULL：描述测量数据中的无线场强变化趋势。

RxQualFULL：描述测量数据中的无线信道块误码率变化趋势。

RxLevSUB：描述测量数据在开通（DTX＝1）间歇发射条件下场强变化。

RxQualSUB：描述测量数据在开通（DTX＝1）间歇发射条件下块误码

该物业点RxLevSUB为-65dBm，说明该物业点覆盖较好。

（2）切换分析

图3为Alerting时主叫小区信息窗口视图。

图3

图4为Disconnect前主叫小区信息窗口视图。

图4

对比分析可得：连接失败前主叫当前服务小区BCCH电平值均远大于-90dBm，并且驻留在统一小区中，没有切换发生。分析事件，Alerting到Disconnect期间，也没有Cell reselect或者Handover出现。

另外，测试人员反映测试物业点周围没有强电、强磁、强辐射等干扰因素，属于正常覆盖区。

5.3 被叫问题

首先，被叫与主叫处于同一网络同一无线环境，可排除被叫网络问题。

信令显示Alerting，说明主叫到被叫的链路没有问题，从而也证明了网络侧正常。

我们对被叫可能存在的以下问题进行分析：

（1）被叫人为挂断

若为被叫人为挂断，则应出现Call End事件，而不是Blocked Call事件。

（2）转秘书台或呼叫转移

如果被叫转秘书台或呼叫转移，会不会出现5-10秒振铃后突然中断呢？由于没有被叫信令数据，笔者用手机进行了拨打测试，发现转秘书台振铃时间均在20秒以上，而拨打呼叫转移设置的手机也没有突然中断的现象。

（3）被叫接收短信或彩信

经拨打测试，被叫接收短信或彩信过程中，也没有出现5-10秒内突然中断的现象。

图5

图6

5.4 主叫问题

（1）主叫人为挂断

主叫在振铃5-10秒钟主动挂断，则应出现Call End事件，而不是Blocked Call事件。

（2）主叫接收短信或彩信业务

a.短信业务

我们知道：SDCCH信道是负责短信业务和呼叫建立的。如果在起呼阶段，主叫接收到短信，此时SDCCH被短信业务占用，也会导致连接失败。

图5为MS接收短信时的部分信令流程。

在MSC发送Paging CMD，寻呼MS后，MS请求SDCCH信道。此后，MS占用SDCCH接收短信业务。

图6为主叫话音业务信令流程。

主叫从CM Service Request起，到Assignment Command，一直占用SDCCH信道，随后释放，并在Alerting和Connect时再次占用。

该问题中，主叫Alerting后显示Disconnect，是否与短消息业务发生信道冲突呢？我们注意到：Disconnect也在SDCCH上传送，这就说明，该问题发生时，SDHCCH并没有被占用，所以，不会是与短消息冲突所致。并且，经查阅相关资料发现：主叫在与短消息业务冲突时，由于SDCCH被占用，主叫接收不到下行响应，通话状态会由起呼直接转为空闲模式（IDLE）。

b.彩信业务

图7为彩信业务信令流程。

分析彩信业务信令发现：彩信业务占用的是PACCH，而不是SDCCH，不会引起本问题的发生。

（3）主叫呼叫设置

经过以上各种分析，笔者认为：主叫测试手机的设置可能是本次问题出现的原因。经查看测试手机发现：主叫手机的呼叫连接时长设置为15秒。为确定该分析，笔者做了以下测试：

a.连接时长设置为15秒，被叫不接听

图8为测试结果分析图。

和出现问题时的测试结果一致。

b.连接时长设置为45秒，被叫不接听

图9为测试结果分析图。

和出现问题时的测试结果一致，只是Alerting到Disconnect时间变为38秒。

图7

图8

图9

6.分析结论及解决方案

主叫手机的呼叫连接时长设置为15秒，除去信道请求、分配指令、CM业务请求时间，从Alerting到Disconnect大概为5-10秒（视网络环境而定），这与从Pilot Navigator看到的信令时间相吻合。该问题的原因就是主叫手机的呼叫连接时长设置为15秒，被叫在15秒内未接听，导致主叫主动断开连接，从而出现了Blocked Call。我们在连接时长设置为45秒的信令中验证了这一结论。

问题分析后，笔者及时通知测试人员修改主叫手机连接时长设置为45秒，并在以后的测试中分析信令，发现该问题不再体现，确保了测试顺利进行。

测试工具是网优分析的基础，在测试过程中，保证测试工具按照测试规范良好运行至关重要。同时，专业的知识储备和丰富的分析经验是确保网优分析质量的关键因素。每一个问题都会有一种原因，也会有一套解决方案。我们只有真正掌握这门学问，才能在应对问题时，真正立于不败之地。