CS掉话TOPN小区分析

2020-03-02 18:43:13 来源：范文大全收藏下载本文

CS掉话TOP N小区分析

8月20日CS掉话率TOP N小区：

可以看到，掉话次数&掉话率最高的几个小区均为RNC11下面的，且比较集中，从Google Earth上可以看到这些小区全部分布在华强北一带：

KPI设计文档，RNC电路域掉话率的公式：

本指标用于了解该RNC内UE进行电路域业务的时候掉话的概率, 无线掉话率部分反映了该RNC范围内用户进行电路域业务的感受度.RNC内的掉话是指由于异常原因被RNC主动发起RAB释放的情况; 这种RNC主动发起的释放原因很多，但是针对\"RAB re-empted\", \"Release due to Overload Control\",\"Release due to UE \"User Inactivity\"这些原因，是不算作RNC的异常掉话的, 掉话率的公式中是不把这些原因统计进去的.

(C301050120+C301050121+ C301050123+C301050157+ C301050159+C301050160+ C301050161+C301050164+ C301050165)/

C301050205+C301050206+ C301050207) generated signalling connection release\",\"O&M ntervention\", (C301050203+C301050204+ C301050120 RNC请求释放的电路域RAB数目,UTRAN产生的 0 C301050121 RNC请求释放的电路域RAB数目,IuUP失败 0 C301050123 RNC请求释放的电路域RAB数目,不确定失败

C301050157 RNC请求释放电路域Iu连接对应的RAB数目,重复的完整性检查失败 0 C301050159 RNC请求释放电路域Iu连接对应的RAB数目,失去与UE的无线连接 C301050160 RNC请求释放电路域Iu连接对应的RAB数目,重定位完成定时器超时 0 C301050161 RNC请求释放电路域Iu连接对应的RAB数目,无线接口流程失败 C301050164 RNC请求释放电路域Iu连接对应的RAB数目,不确定失败

C301050165 RNC请求释放电路域Iu连接对应的RAB数目,UTRAN发起 0

------------------------- C301050203 C301050204 C301050205 C301050206 C301050207 RNC总共释放的电路域AMR RAB数目 RNC总共释放的电路域C 64/64RAB数目 RNC总共释放的电路域数据业务RAB数目 RNC总共释放的电路域C类其他业务RAB数目 RNC总共释放的电路域C 32/32RAB数目

其中掉话率公式分子项里面，标红色0的是导出计数器中没有该类型的掉话。整体上看掉话原因集中在下面四种：

RNC请求释放的电路域RAB数目,不确定失败

RNC请求释放电路域Iu连接对应的RAB数目,失去与UE的无线连接 RNC请求释放电路域Iu连接对应的RAB数目,无线接口流程失败 RNC请求释放电路域Iu连接对应的RAB数目,不确定失败根据KPI定义，导出8.21~24相关计数器：

可以看到，RNC11和RNC13的话务量是所有RNC中最高的两个，两个RNC相比，差别最大的就是“RNC请求释放电路域Iu连接对应的RAB数目,失去与UE的无线连接”这个计数器的值，RNC11是RNC13的5倍之多，其他几个掉话计数器，两个RNC差别不大；最终导致“电路域异常释放的话音RAB数目”RNC11是RNC的两倍，掉话率也基本是两倍关系：

导出三天来CS掉话超过10次/天的小区：

这三天的掉话TOP小区(所有掉话次数>10次/天的小区)，可以看见，8月20号掉话TOP小区均在榜上(高亮的小区)：新上榜的小区分析如下，丽斯/深业大厦8-20号开始传输告警，已经反馈给告警团队：

其他罗湖边检，皇岗公路，联通大厦之所以上榜是因为业务量比较大，所以掉话次数大于10次被筛选出来，看他们的掉话率都还可以接受。

导出这些TOP小区起呼原因相关计数器：

8月21日~8月24日三天华强北这一带位于上面TOP小区列表中的十多个小区造成的CS语音掉话有：865次，RNC11三天的总掉话次数为1700次；比例为865/1700=50.88% 全网15个RNC三天来的CS语音掉话次数共有4293次，RNC11占了将近一半，而这十个小区则占了全网掉话次数的1/5还多：865/4293=20.15% 从上面橙色高亮一列可以看到掉话TOP小区，紧急呼叫占很大语音业务比例，统计如下： 11690(sum (emergency call))/14932(sum (AMR call)) =78.29% 为了验证这个结果，今天又导出了8月24号的掉话次数>10次/天的小区，基本一致：

综上分析，一个大致的结论

通过跟踪TOP N小区的信令跟踪，发现其中大部分CS业务都是未插SIM卡的紧急呼叫业务，这个结果可以证明和解释以下几个问题：

1.KPI中的统计结果，紧急呼叫占很大比例，接近80%；

2.为什么以前NodeB同事到这些地区路测，总复现不出来掉话；

3.为什么我们根据TOP小区ID(掉话五六十次的小区)在关联日志中查询掉话，但是每每只能查到两三次CS业务掉话；

4.为什么联通2G现网，也是这个地区掉话率最高；

根据上面分析，怀疑这些是华强北地区很多W手机商场里面产生的呼叫。考虑到卖手机的经常不用电池，拨打紧急呼叫，直接插拔充电器来为顾客试机的行为模式，他们很可能造成较多“失去与UE的无线连接”原因的掉话。

为了验证这个结论，我们在实验室模拟了CS通话中突然掉电的场景。信令中可以看到手机通话中突然掉电会造成NodeB上报rl failure indication：

.RadioLinkFailureIndicationMsg.reporting_Object_RL_FailureInd.u.rL_Set.rL_Set_InformationList_RL_FailureInd.elem[0].cause.u.radioNetwork = TNBAP_synchronisation_failure Iu释放的原因也是失去与UE的无线连接：

.Iu_ReleaseRequestMsg.cause.u.radioNetwork = TRANAP_radio_connection_with_UE_Lost