CDT软件在掉话分析中的应用

CDT软件在掉话分析中的应用
福州网优中心刘俊敏
摘要：
掉话是日常网优工作中经常碰到的问题，掉话的原因多种多样，对于用户感受的影响较大。

本文介绍了CDT在掉话中的部分应用，通过运用CDT软件进行话务分析，能够比较全面快速的发现网络存在的问题，能够做到在办公室内洞察全局，解决问题。

关键词：
CDT、掉话、RSSI、oneway
正文：
一、现象描述：
CDT软件的全称是CALL DETAIL TRACE，呼叫详细跟踪。

邻区漏配问题、越区覆盖问题、弱覆盖问题、ONE WAY与TWO WAY问题、室分故障问题等都会引发掉话，在日常优化过程中需要通过多次的DT、CQT测试，与后台软件配合分析，响应时间较长，且不易重现掉话，在近期的网优实践中，我们发现通过CDT软件的使用，能够快速地分析、定位上述问题。

CDT软件的主要功能包括TOPN分析（IMSI TopN Analysis）、呼叫记录分析（ALL CALL）、呼叫细节分析（ONE CALL）等，通过这些分析，我们可以窥视整个网络、每个扇区、每个用户、每次通话的过程，了解发生了什么，出了什么问题，帮助我们找到问题的来龙去脉，准确定位问题原因，及时优化网络。

二、问题分析、解决方案及实施效果：
1.邻区漏配掉话问题
9月底，闽侯大目溪二级电站第二扇区出现高掉话现象，查看CDT 中IMSI TopN Analysis ，选取闽侯大目溪二级电站第二扇区，可以看到有很多CALL DROP的IMSI，如下图：
图一CALL DROP图
选取其中的一个IMSI查看IMSI Detail Analysis数据中的ALL CALLS表格，表格告诉我们的信息是：用户于2009年9月20日8点17分29秒占用闽侯大目溪二级电站CI为5805的扇区做被叫，最终掉话，呼叫时长为26秒，呼叫距离大概为2074米。

掉话后，原主叫号码立即重拨，于2009年9月20日8点18分12秒接通，占用闽侯梧桐CI为10334的扇区，呼叫正常，呼叫时长是27秒，呼叫距离大概为1342米。

图二 ALLCALL数据图
进而选取该次掉话呼叫的ONE CALL表格，如下图：
图三第一次呼叫ONECALL数据图
可以看出用户在EC/IO为-6.5的情况下占用该扇区通话，PN为180，于26秒后掉话，掉话原因为SDM_LINK_FAIL_REVTOOMANYBADFRM（反向链路太多坏帧），在接通直至掉话期间未发生切换。

掉话后大约过了17秒，立刻又做了被叫，占用闽侯梧桐基站，ONE CALL表格如下图：
图四第二次呼叫ONECALL数据图
占用的PN为501，通话27秒，正常结束，通过过程中未发生切换。

查看了其他掉话IMSI的数据，也基本为类似现象，据此，我们怀疑大目溪二级电站CI为5805的扇区与闽侯梧桐CI为10334的扇区邻区未配置，导致闽侯梧桐的信号在用户在占用大目溪二级电站
扇区通话时形成强干扰，最终掉话。

查看后台网管NET NUMEN数据，证实了我们的推断，两个扇区邻区没有互配。

两站点在地图上的方位如下图所示。

图五站点地理位置图
解决方案：配置了邻区。

实施效果：闽侯大目溪二级电站掉话率恢复正常。

小结：邻区未配置的问题在大量开通新站点的时候会经常出现，主要关注的是ALL CALLS表格中有掉话的记录，掉话后用户一般会在几十秒内立即发起呼叫，这时占用的扇区很可能与原掉话扇区之间邻区未配置。

2.越区覆盖掉话问题
9月初，仓山太平洋城第一扇区出现高掉话现象，同样，找到某掉话次数多的IMSI，查看IMSI Detail Analysis数据的ALL CALLS表格如下，
图六 ALLCALL数据图
表格说明了，用户在占用太平洋城CI为11953的扇区通话是掉话，掉话后立即又做主
叫，占用南国大厦CI为12834的扇区，通话正常。

查看这两次通话ONE CALL数据如下两图：
图七第一次呼叫ONECALL数据图
图八第二次呼叫ONECALL数据图
根据以上表格，我们认定该次掉话为仓山太平洋城CI为11953的扇区未配置南国大厦CI为12834的扇区。

又查看多个掉话IMSI数据，掉话也为邻区配置问题，仓山太平洋城不仅与南国大厦的扇区邻区未配置，且与五一工行、光明桥等站点的扇区邻区未配置。

查看后台网管NET NUMEN数据，确实如此，但仓山太平洋城的邻区已经配满，无法再增加新的邻区。

这些站点的位置在哪里呢？如下图所示：
图九扇区地理位置图
太平洋城到南国大厦的直线距离在2Km左右，且中间越过了多个站点，我们判断太平洋城为越区覆盖站点，到现场勘察，太平洋城站点高度在50米左右，第一扇区正对江面，天线下倾角太小。

解决方案：增加太平洋城第一扇区下倾角。

实施效果：掉话得到一定程度的改善。

小结：越区覆盖导致的掉话在DT路测时较难发现，一般都不会出现掉话，因为越区的信号影响的往往是建筑物的中高层，因此在路面上一般是测试不到的，通过CDT来分析此类掉话是一种十分便捷的手段。

越区覆盖在CDT上所看到的与邻区未配置较为相似，需要结合地图与现场勘察的情况做综合分析，才能得出正确结论。

3.弱覆盖掉话问题
以闽侯建平为例，闽侯建平的全天掉话统计如下
图十闽侯建平掉话指标
查看CDT数据，
图十一扇区IMSI TOPN图表
存在许多掉话的IMSI，选取掉话最多的IMSI查看IMSI detail analysis数据，如下：
图十二 ALLCALL数据图
选取该IMSI第27次在闽侯建平0扇区掉话的ONE CALL记录查看，如下表
图十三第27次呼叫ONECALL数据图
表中数据说明的情况是，用户占用闽侯建平第一扇区PN78发起呼叫，接入时EC/IO为-11，接通15s后掉话，整个过程未发生切换，掉话原因为SDM_LINK_FAIL_REVTOOMANYBADFRM，即反向链路太多坏帧。

初步判断可能是由于闽侯建平覆盖范围内，存在某些弱覆盖的区域。

观察第28次、29次、30次通话ONE CALL 记录，都得出相同结论，即闽侯建平覆盖范围内有某些弱覆盖的区域。

又观察其他掉话IMSI 的记录数据，也是同样问题。

到现场查勘，发现在闽侯建平第一扇区覆盖范围内存在居民住
宅小区—闽都大庄园（下图红圈处），为弱覆盖区域，时常有用户投诉信号不好如下图
闽都大庄园
图十四站点地理位置图
解决方案：在闽都大庄园内建设新的站点。

小结：弱覆盖导致的掉话在目前福州掉话问题中仍占有较大比例，一般在室内较封闭的房间出现，一般的DT路测也无法真实反映出此类问题，检查后台参数配置等也大都无法定位问题，CDT也是分析此类问题的一个有效手段。

4.ONE WAY 与TWO WAY 现象掉话问题
现象描述，闽侯大目埕掉话徒增，每天在50次左右，称为福州全区掉话最多的基站之一，掉话情况如下表：
图十五闽侯大目埕掉话指标图
查看CDT数据，发现一部分掉话是因为弱覆盖导致。

还有一部分掉话的原因就比较奇怪，具体表现为，许多用户在EC/IO较好的情况下占用闽侯大目埕通话，通话过程中手机发起PSMM消息，要求将PN18的信号加入激活集，然后立即掉话。

如下图所示：
图十六掉话呼叫ONECALL数据图
为什么会产生这种现象，问题似乎出现在PN18的导频上。

是否是产生PN18导频的扇区有问题呢？我们查询闽侯大目埕的邻区列表，发现PN18为闽侯大目溪二级电站第一扇区，如下表所示：
图十七闽侯大目埕邻区配置图
检查后台网管系统，闽侯大目溪二级电站工作正常，所有参数都正常。

说明问题的关键不在闽侯县大目溪二级电站，继续查看CDT数据，我们发现用户在占用闽侯大目埕掉话后，立即发起呼叫，占用的是闽清钟石的站点。

如下表所示：
图十八掉话用户ALLCALL数据图
用户在2009年9月18日17:54:34通话63s后掉话，与17:55:46立即重拨，占用了闽清钟石的基站，CI为14686，会不会是闽清钟石的站点有什么问题呢，我们查看了闽清钟石的基站数据，发现闽清钟石为一个RRU，PN为18。

如下图所示：
图十九掉话用户ONECALL数据图
于是问题的原因找到了，属于用户在通话过程中产生了ONE WAY现象，用户在闽侯大目埕附近收到的是PN18 闽清钟石的信号，但是闽侯大目埕的邻区配置中PN18为闽侯大目溪二级电站，用户只要一发起PN18的加入软切换，就会产生掉话。

闽侯大目溪二级电站、闽侯大目埕、闽清钟石在哪里呢？如下图所示红圈、黄圈、蓝圈处。

在谷歌地图上看，三个站点的距离有相当遥远，闽清钟石与闽侯大目埕直线距离13Km，似乎不大可能发生切换关系。

我们又到现场测试，测试数据证实了在闽侯大目埕站点附近确实收到闽清钟石PN18的信号，用CDT判断的问题是正确的。

图二十站点地理位置图
解决方案：删除闽侯大目埕邻区列表中PN18 闽侯大目溪二级电站，改闽侯大目溪二级电站PN号为66，增加PN18闽清钟石，调整闽清钟石扇区俯仰角，加大俯仰角至10度。

效果评估：经过调整，闽侯大目埕掉话次数明显减少，效果显著。

小结：ONE WAY 与TWO WAY现象其实就是PN规划与邻区配置的问题，在日常优化中通过DT路测基本上可以发现，在没有路测数据的情况下，使用CDT辅助定位问题也不
失为一种有效的手段。

5.室分故障掉话问题
8月9日，华林局第三扇区RRU掉话突然升高。

查询后台数据，华林局第三扇区为西湖大酒店内的RRU。

查看CDT数据，发现当天确实存在高掉话现象，选取掉话最多的一个IMSI查询ONE CALL记录，发现均在信号EC/IO较好的情况下出现SDM_LINK_FAIL_REVTOOMANYBADFRM原因导致的掉话，查询其他高掉话IMSI，也是此类情况。

具体ONE CALL数据如下图：
图二十一掉话用户ONECALL数据图
为什么会在EC/IO较好的情况下出现掉话？由于西湖大酒店为室分系统，我们想到是
否是室内分布存在问题所致。

进而查询RSSI数据如下：
图二十二掉话站点RSSI数据图
发现当天西湖大酒店RSSI一直处于一种非常不稳定的状态，时高时低，晚上22点后恢复正常。

经了解，当天西湖大酒店整改室内分布系统，导致RSSI升高，晚上恢复正常。

观察第二天话务指标，掉话率恢复正常。

小结：在EC/IO较好的情况下掉话，原因有多种多样，但由于是室内分布系统，用户所使用的信号比较单纯，我们才怀疑是RSSI有问题。

因此此例在室外信号的优化上并不一定适用，但在解决室内信号问题上是值得参考的。

〖案例点评〗：
随着天翼网络与用户的发展，各种掉话问题层出不穷，如何定位问题是解决问题的关键，通过CDT数据的分析，能够帮助我们打开问题的黑匣子，了解每一次掉话的原因，是一种将实践与原理结合起来的有效工具。