干扰引起失步导致掉话原因分析.docVIP

序言 引起掉话的原因很多，而无线链路失败是其中比较常见的一种，对于下行无线链路失败和恢复，3GPP协议描述如下： 在正常的业务保持阶段，如果检测到来自L1层的连续N313次“out of sync”指示，则认为下行失步，物理层将向UE的RRC层上报“P_PHY_RRC_OUTOFSYNC_IND”。UE高层在收到L1的失步指示后，启动定时器T313。如果在T313时间内，检测到来自L1层的连续N315次“in sync”则认为下行同步，则停止定时器T313。否则将认为下行无线链路失败，此时UE的RRC层向物理层下发“P_RRC_PHY_RL_Release_REQ”释放了物理信道资源，UE将进行小区搜索过程，在搜到小区后，UE将在目标小区上进行cellupdate，如果小区更新成功，则该次下行无线链路失败得到挽救。 本案例中进一步探讨了下行失步导致掉话的现象和原因分析。 1 问题描述与分析 案例一问题描述：如图所示，车辆在天马路上由西向东行驶过程中，主被叫先后占用在财税大楼-2（10104，109）与常山体育馆-3（10071，88）小区上通话，无线环境较好。继续向前行驶，主叫先发起切换到RSCP值较好的神龙商务酒店-3小区上；5秒后，被叫也切换到神龙商务酒店-3小区上。主叫切换完成后18秒，发生掉话；被叫切换完成10秒，发生掉话。 问题分析：通过分析发现，主被叫在切向神龙商务酒店-3小区之前，两部终端通话均正常，且无线环境也非常好。当主叫先行切向神龙商务酒店-3小区后，PCCPCH_RSCP值与C/I值都很好，但是DPCH_RSCP值为-116，基本等于无功率。5秒后，被叫也切换到神龙商务酒店-3小区上，现象与主叫一样；参照对应的trace信令，发现主被叫都已经成功切换到神龙商务酒店-3小区上，而且RNC在该小区上下发了5条MC消息，但是从UU口信令看，主叫并没有收到该消息，怀疑主被叫在切换到神龙商务酒店-3小区后，下行失步 同时主叫下行失步后试图通过Cell Update来挽救此次通话，但是主叫上发的PHYSICAL CHANNEL RECONFIGURATION COMPLETE消息，RNC侧并没有收到（TRACE信令可以查看到），小区更新没有成功，怀疑上行也已经失步。 主叫TRACE信令： 被叫TRACE信令： 从上述分析看，当主叫和被叫切向神龙商务酒店-3小区后，都发生了下行失步，且主叫上行失步。但在掉话前后，主被叫的PCCPCH_RSCP值与C/I值都很好，排除同频干扰及码字干扰的可能（周边没有与神-3同扰码组的小区）。 与此同时让机房查询该小区的状态，反馈该小区上行干扰平均在-80dbm左右，上行干扰严重。怀疑由外部干扰或RRU故障或基站版本不稳定造成。 事件地点 对应日志 事件名称 事件原因 发生事件小区 天马路靠近神龙商务酒店附近 0303 C1簇拉网_7.log 掉话 下行失步 神龙商务酒店-3 案例二问题描述：车辆在天马路上由东向西行驶，主被叫先后占用在神龙商务酒店-2、神龙商务酒店-3小区上通话。车辆继续向前行驶过程中，财税大楼-2小区的信号的越来越强，主被叫先后发起2A测量报告，被叫切换成功，主叫发生切换，最后主叫在神龙商务酒店-3小区上掉话。掉话时PCCPCH_RSCP值与C/I值都很好。 问题分析：如下图，主叫发起2a测量报告，目标小区是财税大楼-2（10104，109），此时主叫的PCCPCH_RSCP值与C/I值都很好，而且满足切换判决条件，但是主叫UE1一直没有收到RNC下发的PHYSICAL CHANNEL RECONFIGURATION消息。 但从对应的TRACE信令分析，RNC侧在收到主叫上发的MR消息后，马上下发了一条PHYSICAL CHANNEL RECONFIGURATION消息，10秒后，没有收到UE的响应消息，RNC向CN发起IU Release Request，主叫掉话。掉话原因为UE失步。 从上述分析看，主叫在MR消息下发后，一直没收到RNC侧已经下发的物理信道重配置消息，说明主叫在这一段时间内已经下行失步。进一步分析发现，主叫在占用神龙商务酒店-3小区时出现了与第一个掉话一样的现象，DPCH_RSCP值非常低，-116dbm左右。导致RNC侧在神龙商务酒店-3小区下发的PHYSICAL CHANNEL RECONFIGURATION消息，主叫一直没有收到，造成最后失步掉话。 综上2次掉话原因，均是占用在神龙商务酒店-3小区，且机房查询该小区的状态反馈该小区上行干扰平均在-80dbm左右，上行干扰严重。怀疑由外部干扰或RRU故障或基站版本不稳定造成。 进一步核查导致上行干扰产生的原因，在排除外部干扰源、GPS跑偏、基站板卡故障等的基础上发现基本版本为测试69T版