MSCBSC 移动通信论坛
搜索
登录注册
网络优化工程师招聘专栏 4G/LTE通信工程师最新职位列表 通信实习生/应届生招聘职位

  • 阅读:2625
  • 回复:2
经典网络AMR异常掉话问题定位案例
yuanjie_rf
初级会员



 发短消息    关注Ta 

积分 75
帖子 15
威望 422 个
礼品券 0 个
专家指数 0
注册 2013-6-18
专业方向  网络优化
回答问题数 0
回答被采纳数 0
回答采纳率 0%
 
发表于 2013-06-29 12:49:56  只看楼主 
某网络AMR异常掉话问题定位案例
某项目搬迁割接后,客户反映AMR语音掉话率不论是RNC级话统,还是Cluster话统都要比搬迁前NT网络高,RNC语音掉话率在1%左右。尤其在小区半径改大以后,掉话率呈现进一步上升的趋势。
²
现场分析话统发现超过70%的语音掉话原因是上行RL Failure,检查上行同失步参数觉得失步比较容易触发,因此修改了上行同失步参数。然而参数修改并没有取得预想的效果,掉话率没有任何改善
²
分析语音掉话相关的配置参数,发现语音的RL MAX Power配置为-3dB,而NT公司设置是+1dB,相差4dB,我司的缺省设置偏低。将语音下行最大发射功率修改为+1dB,掉话率有所下降,为0.8%左右,基本与NT公司持平。以下是我司和NT公司掉话率变化走势图

MOD Cell Radius


MOD AMR Max RL PWR


MOD In/Out Sync Para



²
通过修改语音下行最大发射功率,掉话率有所下降,然而这个改善并不显著,客户仍然觉得我司的网络掉话率比NT公司的要差,并做了一份对比报告,认为我司网络的AMR掉话率平均比NT高出一倍,对我司网络的性能指标不满
²
从初步的CHR分析来看,有相当多的异常掉话在信号很好的时候,而且掉话的原因仍然是以IUB RL Failure为主。通常都是呼叫刚刚建立18秒左右掉话,异常现象非常典型

1定位问题的基本手段
首先根据所有可能原因,从以下几个方面分别进行定位分析:
1)
Top N
小区的路测
2)
Top 5
用户的CDT跟踪
3)
Top 5
小区的IOS 跟踪
4)
网络参数对比
5)
Node B
的日志分析
6)
设备告警与掉话小区相关性检查
2.初步的排查
1)
路测:首先在对掉话率比较高的几个小区进行路测后,没有发现掉话。路测无法重现这类掉话,因此基本排除了依靠路测定位此问题的可能;
2)
参数设置检查:包括了与NT公司参数的对比,以及和其它商用网络的对比,列出与掉话相关的几个不同参数。分析后发现主要可以修改的是软切换参数(1A的延迟触发时间改为100ms,滤波系数改为2),这能够解决一些切换不及时造成的掉话,而事实上该网络的无线传播环境并不复杂,切换不及时发生的概率较低,而NT公司以前是根据0.5秒周期报告来做软切换的,比我司目前320ms的配置更慢。因此,修改该参数能带来的增益并不大。
3)
Node B
问题:该网络普遍采用我司RRU,以前没有普遍商用过,一度怀疑RRU可能有问题。为此还对比其它商用局RRU的话统,并对CHR进行分析;对Node B的日志分析也没有什么结果。
4)
设备告警:检查IUB传输告警、小区VSWRRTWP告警以及拥塞等告警,发现这些告警与当天的TOP 5小区相关性不大。
5)
通过以上分析,定位问题的手段主要都落在CDTIOS跟踪上。对前一天CHR统计的AMR掉话Top5用户进行CDT跟踪,结果好几个用户没有开机(或者在NT网络),跟到的两个也没有什么异常发生。分析的重点只能放在IOS跟踪数据上面。
3.锁定异常掉话发生过程——RB Setup后的RL Failure
根据对掉话TOP5小区的IOS跟踪数据进行分析,重点只分析RL Failure造成的AMR掉话。在这些RL Failure原因的掉话中,刨除掉一些确实是信号问题(Ec/IoRSCP较差)造成的掉话,有相当大一部分RL Failure的掉话确实是在信号非常好的地方发生(前几秒的Ec/IoRSCP一般达到-8dB/-80dBm以上),而且掉话的过程非常一致——都是在RB Setup完成后10秒左右收到RL Failure(这时候一般还没有发生软切换,激活集只有一个小区)5秒钟后没有RL Restore掉话。因此把问题锁定在这种典型过程的掉话上面,典型的掉话点信令流程如下

4.锁定异常掉话发生手机类型——V980
根据跟踪的IOS信令,网络发了NAS层消息Idendity Request,而UE回的Idendity Response中上带了手机的IMEI,因此根据IMEI的前6为数字可以确定手机的型号

如上图的IMEI:3549090098161989,在Google上查询“IMEI:354909”发现这是MOTO V980手机。这款手机存在较多问题,其中在其它商用网上发现该款手机存在内环功控的问题。将RL Failure掉话的IMEI全部检查,并一一在网上搜索其对应的手机型号,发现V980手机占的比例相当大,见下图

上图查到的V980对应的2IMEI42%,后来查到354757也是V980,所以V980手机实际比例为56%,这与V980在网络中占有的较小比例显然不符,因此怀疑V980手机引起异常掉话。
为了进一步证实我们的怀疑,把2CHR统计的掉话TOP 10IMSI逐个进行跟踪,并查看Identity Response消息。一共抓到8个用户的消息,其IMEI和对应的手机型号如下表

Top AMR Drop IMSI
IMEI Prefix
UE Type
214014001028124
354757
MOTO V980
214019800996086
357390
MOTO V3x
214018400245450
354757
MOTO V980
214015502901764
354909
MOTO V980
214019802036798
355603
MOTO V980
214019800794715
354757
MOTO V980
214019800805920
354757
MOTO V980
214016002234223
354757
MOTO V980

这样问题逐渐明显,肯定是与V980手机有关的。
在我司的某个商用局,V980手机的问题是不做内环功控,而是固定以满功率发射,因此导致很多站的RTWP抬升导致其它用户掉话。从现网问题小区的RTWP跟踪来看,确实也有类似RTWP尖峰

于是一度把问题瞄准了RTWP问题,但后来的IOS分析否定了这种推测
5RTWP问题排除
为了证实异常掉话时是否有RTWP抬升,我们打开了IOS跟踪的NBAP公共测量报告,查看RL Failure前后的测量报告,见下图所示,RTWP=(61-1)/10-112 =-106dBm,因此RTWP非常正常

而且RL Failure之前也没有看到UE的发射功率攀升,见下图所示,UE Tx power 上报值为51,由此计算UE发射功率Tx Power=51-71=-20dBm

分析了IOS中很多的这类异常,发现都是这种情况:RTWPUE发射功率都很正常的情况下发生的RL Failure。因此基本可以排除上行问题导致,而信号这么好的情况下下行怎么会有问题呢?这种错误的假设也导致我们在问题定位的前期一直没有注意查看下行质量
6.锁定RL Failure的原因——下行BLER 100%
于是打开了IOS中的UE质量上报(下行BLER)和下行码发射功率的测量。
发现RL Failure前的下行BLER达到100%,而此时的导频Ec/Io非常好

通过上图UE上报的数据可以计算
¨
服务小区CPICH Ec/Io=(39-1)/2-24=-5dB, RSCP=(29-1)-115=-87dBm;
¨
下行码发射功率TCP=(86-10)/2-10-PO3=28dBm-3dB=25dBm
¨
下行BLER100%(上报值63映射为100%)
通过以上计算,下行业务信道码发射功率为25 dBm,并没有达到最大发射功率。虽然下行的外环功控我们看不到,但是在覆盖这么好的地方,即使SIR Target调到上限(5dB)下行码发射功率不需要太高也能满足SIR的要求。这种情况是合理的
下行BLER100%意味着下行连续误码,这时会触发下行失步,下行失步后UE会在40ms时间内关闭发射机,因此大约8秒后上行RL Failure
为什么在下行信号如此好的地方,会频频出现DL BLER100%的情况呢?
后来得到一些信息:
²
CDT信令分析,也发现了一次这样的掉话,也是下行BLER很差但是TCP很小,而对方(主叫)号码是一个特服号码101,怀疑在接听时刻传送的用户面数据异常
²
在正常呼叫流程中,在UE接听之前,E公司的核心网下发的IUUP是没有数据的,而此时我司RNC配置的传输格式是0×0
由此猜测,在没有数据传输时,V980可能按照1×0的传输格式来解,导致100%BLER。这个猜测比较切合实际,因为前几天看到的掉话确实大部分都是被叫,而且也都是在UE接听之前发生的,此时用户面没有数据。
通过对比我司和NT公司的RB Setup消息,确认我司配置了0×81的传输格式(A子流),而NT公司没有这种配置。而如果此问题就是导致下行BLER 100%的原因,则可以打开下行盲检测开关来规避,使用SET CORRMALGOSWITCH命令,打开DOWNLINK_BLIND_DETECTION_SWITCH (下行盲检测开关)。因为下行盲检测开关打开后不下发0×81TF,而是下发一个1×0TF,如下图所示:

1)下行盲检测开关关闭时2)下行盲检测开关打开时
检查NT公司的消息,发现其盲检测开着的(NT公司没有面向客户的这个开关)

然而我们不敢轻易打开盲检测开关,因为有些老版本的高通芯片有个BUG,如果盲检测开关打开,而网络侧配置了太多的CTFC则可能导致问题,因此目前我司的商用网络全部关闭了这个开关。而对于AMR语音核心网只指配了3种速率,于是检查NT公司的CTFC和我司的对比,发现都是6个,见下图所示
NT

Huawei


如果NT公司不存在上述高通芯片的问题,我司的配置也不会有问题。于是决定打开盲检测开关,现场使用V980手机进行对比测试。
²
下行盲检测开关关闭时,V980做被叫如果不接听则频频掉话,跟踪的消息和我们先前分析的异常掉话原因相同
²
下行盲检测开关打开时,单独对V980的手机进行被叫测试,连续进行上百次的测试,没有一次掉话
打开盲检测开关后话统指标验证
²
打开盲检测开关后18:00一小时的AMR掉话率降到了0.44%,在这个时段是从未有过的新低;而接下来的几个忙时,掉话率也都在0.4%左右保持
²
修改后18:00~21:00各时段AMR掉话率与前两天同期的对比统计图如下

RNCId

RNCName

Time(As hour)

AMR drop call rate

AMR Call Attempts

121

RNC:121

2006-11-15 18:00

0.70%

8337

121

RNC:121

2006-11-15 19:00

0.86%

8561

121

RNC:121

2006-11-15 20:00

1.04%

7895

121

RNC:121

2006-11-15 21:00

0.69%

6533

121

RNC:121

2006-11-16 18:00

0.68%

8082

121

RNC:121

2006-11-16 19:00

0.84%

8383

121

RNC:121

2006-11-16 20:00

0.93%

8180

121

RNC:121

2006-11-16 21:00

0.75%

6617

121

RNC:121

2006-11-17 18:00

0.44%

9211

121

RNC:121

2006-11-17 19:00

0.43%

9212

121

RNC:121

2006-11-17 20:00

0.38%

8829

121

RNC:121

2006-11-17 21:00

0.27%

7313

²

Switch on DOWNLINK BLIND DETECTION


MOD AMR Max RL PWR


修改前后几天,RNC话统统计AMR掉话率曲线走势图如下: 从上图可以看出,打开盲检测开关后,掉话率话统指标有了较大的改善,RNC话统的AMR掉话率都稳定在0.4%以下
在定位此类异常掉话的问题时,通过话统分析,找出网络中的异常手机的型号,并针对具体的手机型号进行问题的定位分析,这是网络优化中一种方法。该方法在其它商用网络中定位某款手机内环功控的问题时也有所应用。
扫码关注5G通信官方公众号,免费领取以下5G精品资料
  • 1、回复“LTBPS”免费领取《《中国联通5G终端白皮书》
  • 2、回复“ZGDX”免费领取《中国电信5G NTN技术白皮书
  • 3、回复“TXSB”免费领取《通信设备安装工程施工工艺图解
  • 4、回复“YDSL”免费领取《中国移动算力并网白皮书
  • 5、回复“5GX3”免费领取《 R16 23501-g60 5G的系统架构1
  • 6、回复“iot6”免费领取《【8月30号登载】物联网创新技术与产业应用蓝皮书——物联网感知技术及系统应用
  • 7、回复“6G31”免费领取《基于云网融合的6G关键技术白皮书
  • 8、回复“IM6G”免费领取《6G典型场景和关键能力白皮书
  • 对本帖内容的看法? 我要点评

     
    [充值威望,立即自动到帐] [VIP贵宾权限+威望套餐] 另有大量优惠赠送活动,请光临充值中心
    充值拥有大量的威望和最高的下载权限,下载站内资料无忧
    wwwmscbsccom
    超级版主
    鎵嬫満鍙风爜宸查獙璇


     发短消息    关注Ta 

    公益·慈善勋章   专家·高级勋章   纪念勋章·八周年   纪念勋章·九周年  
    积分 15978
    帖子 1497
    威望 34077 个
    礼品券 1225 个
    专家指数 8493
    注册 2013-4-27
    专业方向  终端、协议测试、软件测试
    回答问题数 0
    回答被采纳数 0
    回答采纳率 0%
     
    发表于 2013-06-30 10:31:22 
    技术问题,回答得专家指数,快速升级
    技术贴不顶啊,不过看不到图片啊。

    对本帖内容的看法? 我要点评





    http://www.mscbsc.com/bbs/space.php?uid=10105337
     
    [立即成为VIP会员,百万通信专业资料立即下载,支付宝、微信付款,简单、快速!]
    OscarDon
    论坛副管
    鎵嬫満鍙风爜宸查獙璇


     发短消息    关注Ta 

    C友·铁杆勋章   管理·勤奋勋章   管理·优秀勋章   公益·慈善勋章   C友·纪念勋章   管理·贡献勋章   C友·贡献勋章   “灌水之王”   纪念勋章·七周年   C友·魅力勋章   管理·标兵勋章   活动·积极勋章   财富勋章·财运连连   财富勋章·大富豪   财富勋章·小财主   专家·终级勋章   纪念勋章·三周年   财富勋章·神秘富豪   C友·幸运勋章   C友·登录达人   C友·活跃勋章   公益·环保勋章   纪念勋章·五周年   纪念勋章·四周年   财富勋章·富可敌国   财富勋章·富甲一方   财富勋章·钻石王老五   活动·第一届通信技术杯   活动·第二届通信技术杯   纪念勋章·六周年   活动·摄影达人   通信正能量   纪念勋章·八周年   纪念勋章·九周年   纪念勋章·十周年   C友·技术大神   纪念勋章·十二周年  
    积分 61012
    帖子 5541
    威望 51577 个
    礼品券 15891 个
    专家指数 25389
    注册 2008-6-30
    专业方向  通信工程
    来自 江苏
    回答问题数 0
    回答被采纳数 0
    回答采纳率 0%
     
    发表于 2013-07-01 19:36:03  QQ
    确实图片看不到

    对本帖内容的看法? 我要点评





    当我轻轻转身,细数身上的伤痕,每一道都是福分。
     
    最新通信职位:广东通信人才网 | 北京通信人才网 | 上海通信人才网 | 南京通信人才网 | 西安通信人才网 | 重庆通信人才网 | 中国通信人才网

    快速回复主题    
    标题
    内容
     上传资料请点左侧【添加附件】

    当前时区 GMT+8, 现在时间是 2024-05-05 11:20:44
    渝ICP备11001752号  Copyright @ 2006-2016 mscbsc.com  本站统一服务邮箱:mscbsc@163.com

    Processed in 0.676652 second(s), 17 queries , Gzip enabled
    TOP
    清除 Cookies - 联系我们 - 移动通信网 - 移动通信论坛 - 通信招聘网 - Archiver