经典网络AMR异掉话问题定位案例.docVIP

某网络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 MOD Cell Radius MOD AMR Max RL PWR MOD In/Out Sync Para 通过修改语音下行最大发射功率，掉话率有所下降，然而这个改善并不显著，客户仍然觉得我司的网络掉话率比NT公司的要差，并做了一份对比报告，认为我司网络的AMR掉话率平均比NT高出一倍，对我司网络的性能指标不满； 从初步的CHR分析来看，有相当多的异常掉话在信号很好的时候，而且掉话的原因仍然是以IUB RL Failure为主。通常都是呼叫刚刚建立18秒左右掉话，异常现象非常典型。 无 1．定位问题的基本手段 首先根据所有可能原因，从以下几个方面分别进行定位分析： Top N小区的路测 Top 5用户的CDT跟踪 Top 5小区的IOS 跟踪 网络参数对比 Node B的日志分析 设备告警与掉话小区相关性检查 2．初步的排查 路测：首先在对掉话率比较高的几个小区进行路测后，没有发现掉话。路测无法重现这类掉话，因此基本排除了依靠路测定位此问题的可能； 参数设置检查：包括了与NT公司参数的对比，以及和其它商用网络的对比，列出与掉话相关的几个不同参数。分析后发现主要可以修改的是软切换参数（1A的延迟触发时间改为100ms，滤波系数改为2），这能够解决一些切换不及时造成的掉话，而事实上该网络的无线传播环境并不复杂，切换不及时发生的概率较低，而NT公司以前是根据0.5秒周期报告来做软切换的，比我司目前320ms的配置更慢。因此，修改该参数能带来的增益并不大。 Node B问题：该网络普遍采用我司RRU，以前没有普遍商用过，一度怀疑RRU可能有问题。为此还对比其它商用局RRU的话统，并对CHR进行分析；对Node B的日志分析也没有什么结果。 设备告警：检查IUB传输告警、小区VSWR、RTWP告警以及拥塞等告警，发现这些告警与当天的TOP 5小区相关性不大。 通过以上分析，定位问题的手段主要都落在CDT和IOS跟踪上。对前一天CHR统计的AMR掉话Top5用户进行CDT跟踪，结果好几个用户没有开机（或者在NT网络），跟到的两个也没有什么异常发生。分析的重点只能放在IOS跟踪数据上面。 3．锁定异常掉话发生过程——RB Setup后的RL Failure 根据对掉话TOP5小区的IOS跟踪数据进行分析，重点只分析RL Failure造成的AMR掉话。在这些RL Failure原因的掉话中，刨除掉一些确实是信号问题（Ec/Io或RSCP较差）造成的掉话，有相当大一部分RL Failure的掉话确实是在信号非常好的地方发生（前几秒的Ec/Io和RSCP一般达到-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对应的2个IMEI占42％，后来查到354757也是V980，所以V980手机实际比例为56%，这与V980在网络中占有的较小比例显然不符，因此怀疑V980手机引起异常掉