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

2011-03-15 07:45
电子世界 2011年8期
关键词:彩信信令物业

(中国移动通信集团设计院有限公司陕西分公司,陕西 西安 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秒,并在以后的测试中分析信令,发现该问题不再体现,确保了测试顺利进行。

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

猜你喜欢
彩信信令物业
SLS字段在七号信令中的运用
物业服务
地铁车辆段及上盖物业开发一体化探讨
移动信令在交通大数据分析中的应用探索
彩信的巅峰与陨落
基于信令分析的TD-LTE无线网络应用研究
LTE网络信令采集数据的分析及探讨
加强细部处理,提升物业品质
一种基于IP的彩信收发模块设计
山东省气象彩信平台本地化设计与实现