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

某网络AMR异常掉话问定位案例 某项目搬迁割接后，客户反映AMR语音掉话率不论是RNC级话统，还是Cluster话统都要比搬迁前NT网络高，RNC语音掉话率在1%左右。尤其在小区半径改大以后，掉话率呈现进一步上升的趋势。 ​ 现场分析话统发现超过70%的语音掉话原因是上行RL Failure，检查上行同失步参数觉得失步比较容易触发，因此修改了上行同失步参数。然而参数修改并没有取得预想的效果，掉话率没有任何改善； ​ 分析语音掉话相关的配置参数，发现语音的RL MAX Power配置为-3dB，而NT公司设置是+1dB，相差4dB，我司的缺省设置偏低。将语音下行最大发射功率修改为+1dB，掉话率有所下降，为0.8%左右，基本与NT公司持平。以下是我司和NT公司掉话率变化走势图： ​ 通过修改语音下行最大发射功率，掉话率有所下降，然而这个改善并不显著，客户仍然觉得我司的网络掉话率比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传输告警、小区VSWR、RTWP告警以及拥塞等告警，发现这些告警与当天的TOP 5小区相关性不大。 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手机引起异常掉话。 为了进一步证实我们的怀疑，把2天CHR统计的掉话TOP 10的IMSI逐个进行跟踪，并查看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 这样问题逐渐明显，肯定是与V980手机有关的。 在我司的某个商用局，V980手机的问题是不做内环功控，而是固定以满功率发射，因此导致很多站的RTWP抬升导致其它用户掉话。从现网问题小区的RTWP跟踪来看，确实也有类似RTWP尖峰： 于是一度把问题瞄准了RTWP问题，但后来的IOS分析否定了这种推测。 5．RTWP问题排除 为了证实异常掉话时是否有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中很多的这类异常，发现都是这种情况：RTWP和UE发射功率都很正常的情况下发生的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 ​ 下行BLER＝100％（上报值63映射为100％） 通过以上计算，下行业务信道码发射功率为25 dBm，并没有达到最大发射功率。虽然下行的外环功控我们看不到，但是在覆盖这么好的地方，即使SIR Target调到上限（5dB）下行码发射功率不需要太高也能满足SIR的。这种情况是合理的。 下行BLER为100%意味着下行连续误码，这时会触发下行失步，下行失步后UE会在40ms时间内关闭发射机，因此大约8秒后上行RL Failure。 为什么在下行信号如此好的地方，会频频出现DL BLER为100%的情况呢？ 后来得到一些信息： ​ 从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×81的TF，而是下发一个1×0的TF，如下图所示： （1）下行盲检测开关关闭时 （2）下行盲检测开关打开时 检查NT公司的消息，发现其盲检测开着的（NT公司没有面向客户的这个开关）： 然而我们不敢轻易打开盲检测开关，因为有些老版本的高通芯片有个BUG，如果盲检测开关打开，而网络侧配置了太多的CTFC则可能导致问题，因此目前我司的商用网络全部关闭了这个开关。而对于AMR语音核心网只指配了3种速率，于是检查NT公司的CTFC和我司的对比，发现都是6个，见下图所示： 如果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 ​ 修改前后几天，RNC话统统计AMR掉话率曲线走势图如下： 从上图可以看出，打开盲检测开关后，掉话率话统指标有了较大的改善，RNC话统的AMR掉话率都稳定在0.4%以下。 在定位此类异常掉话的问题时，通过话统分析，找出网络中的异常手机的型号，并针对具体的手机型号进行问题的定位分析，这是网络优化中一种方法。该方法在其它商用网络中定位某款手机内环功控的问题时也有所应用。