名称：切换异常的几种原因分析及排查提交人：张鑫提交日期：2011-12-24软件版本：硬件版本：1.1 RNC内切换过程中的异常1.1.1 总体描述RNC内切换相关的异常主要有如下几种典型场景：物理信道重配失败：网络侧在下发physicalChannelReconfiguration消息后，终端回physicalChannelReconfigurationFailure消息，导致切换过程失败，此类异常影响RNC内切换成功率，但不会导致掉话；物理信道重配超时：网络侧在下发physicalChannelReconfiguration消息后，终端没有响应，网络侧等待一段时间后，终端仍然未上报cellUpdate，超时后释放，此类异常会同时影响切换成功率；小区更新后物理信道重配超时：网络侧在下发physicalChannelReconfiguration消息后，终端没有响应，网络侧等待一段时间后，终端上报cellUpdate，网络侧下发cellUpdateConfirm消息，终端响应超时后释放，此类异常会同时影响切换成功率；网络侧收到测量报告但未发起切换：网络侧收到终端上报的1G或2A测量报告，但未在目标小区发起无线链路建立过程，也未向终端下发physicalChannelReconfiguration，此类异常不会对KPI指标造成直接影响；1.1.2 典型信令过程1.1.2.1 物理信道重配失败1. 信令截图：第 1 页2. 信令分析：第 3 页原因分析及排查手段：查看PhysicalChannelReconfigurationFailure 中携带的失败原因，比如最常见的Failure cause 为physical channel failure ，表示UE 无法在建立新的物理信道，即UE 无法在新的信道配置上完成L1同步（UE 在T312时间内，收到N312个同步指示，即认为新的信道建立成功）。
造成这种现象的原因可能为物理信道所在的时隙干扰较大，或目标小区存在UP 干扰。
排查方法：查看各时隙干扰情况，如果发现时隙干扰很大，查看NODEB 载扇是否正常，同时查看邻小区是否有大量同频邻区，若在话务量小的情况下，ISCP 仍然很高，则干扰可能来自异系统，如：GSM ，PHS 等；查看目标小区UP 干扰，若较大，则进行UP 位置偏移；时隙干扰经常性偏大时，可以尝试调低UE 的上、下行开环功率；无效配置、配置不支持等配置错误：换个手机测试，若各厂家手机测试都有问题，将本小区的重配消息和正常小区的重配消息进行对比，查看配置是否正确； 注：物理信道/RB 重配失败后测量控制下发说明：切换失败后，RNC 会重新下发测量控制消息，测量控制消息中携带邻区列表但不包含频点扰码等具体信息，如图所示，因为之前的测量控制消息中已经携带了邻区的扰码、频点等信息，UE 侧已经保存了相关邻区的详细信息，因此网络侧不需要重新携带邻区的详细信息，只需要指示邻区序号。
1.1.2.2物理信道重配超时原因分析及排查手段：UE收到了RECONFIGURATION消息，并发送了COMPLETE消息，但RNC未收到（上行功率不足或存在干扰等原因）；UE收到了RECONFIGURATION消息，但没发送COMPLETE消息（消息错误或UE 内部错误等原因）；排查方法：若UE未收到重配消息：调整后台下行最小发送功率，增加UE接收到重配消息的几率，或者调整周围网络的覆盖、频点、功率等，尽量降低下行方向上的干扰；若网络侧没有收到重配完成消息：则调整后台DPCH的期望接收功率，同时利用网规网优手段，降低上行方向上的干扰；1.1.2.3 小区更新后物理信道重配超时第 5 页原因分析及排查手段：可能原因为：UE未收到CONFIRM消息（下行功率不足或存在干扰等原因）；UE收到了CONFIRM消息，并发送了COMPLETE消息，但RNC未收到（上行功率不足或存在干扰等原因）；UE收到了CONFIRM消息，但没发送COMPLETE消息（消息错误或UE内部错误等原因）；排查方法：若UE未收到CONFIRM消息：调整后台下行最小发送功率，增加UE接收到CONFIRM消息的几率，或者调整周围网络的覆盖、频点、功率等，尽量降低下行方向上的干扰；若网络侧没有收到重配完成消息：则调整后台DPCH的期望接收功率，同时利用网规网优手段，降低上行方向上的干扰；1.1.2.4 网络侧收到测量报告但未发起切换1. 信令截图：2. 信令分析：3. 原因分析及排查手段：一般为RNC资源申请失败导致，如码道资源不足，软资源（功率、干扰）接纳失败等（此时信令跟踪工具上没有IUB口和空口消息）；可查看目标小区剩余的码道资源数看是否有足够的剩余资源，并查看公共测量值和配置的接纳门限，是否为功率干扰等软资源受限。
1.1.2.5 网络侧在RAB指派过程中收到测量报告1. 信令截图：2. 原因分析及排查手段：RNC在收到CN RAB指派后，UE上报一个测量报告，但此时RNC在处理CN RAB 指派，无法同时处理测量报告，RNC缓存此条测量报告，等RAB指派完成后，在发起切换过程，由于此案例中测量报告中的目标小区来自邻RNC，因此发起了重定位流程。
第 7 页1.2 RNC间切换过程中的异常1.2.1 总体描述RNC内切换相关的异常主要有如下几种典型场景，CN侧响应RelocationPrepareFailure：CN响应超时；CN响应IuReleaseCommand；终端RB重配失败；终端RB重配失败；下面分别详细描述各类异常发生的场景及原因，并给出对应排查手段。
1.2.2 典型信令过程及异常分析1.2.2.1 CN侧响应RelocationPrepareFailure异常描述当S-RNC向CN发送Relocation Required消息后，CN向D-RNC发送Relocation Request，D-RNC侧发起类似于业务接入的流程，分配信令、业务所需的物理资源，并建立无线链路及相应承载，其中任何一个步骤发生异常，则会向CN响应Relocation Failure消息，携带D侧失败的错误码，CN通过Relocation Preparation Failure消息透传该错误码到S-RNC，由于是重定位准备阶段流程发生异常，不会记入跨RNC切换失败，因此不会影响任何KPI指标，但此类异常会导致终端脱离源小区覆盖而又无法切换，最终因覆盖问题导致掉话。
信令过程由于比较难于搜集同一次跨RNC切换异常过程中S侧和D侧的信令，因此本部分未以截图的形式给出行令流程。
S侧信令：D侧信令：原因分析及排查根据S侧Relocation Preparation Failure消息或Relocation Failure消息中的错误码，参考非标准原因错误码对应表中说明，进行排查；第 9 页1.2.2.2 CN响应超时异常描述当CN Iu口负荷过高或CN存在某种异常时，会不处理S侧发送的Relocation Required消息，D侧表现为看不到任何信令，S侧在发送Relocation Required 后会设置等待定时器，定时器时长内CN未响应任何消息，则S侧认为对方状态不可知，则发起Iu连接释放过程，记作一次掉话，此类异常影响业务掉话率指标。
信令过程S侧信令：D侧信令：D侧未收到任何CN下发的信令消息。
原因分析及排查需要确认和CN的Iu口链路是否存在问题，如故障、拥塞等，重点在CN侧排查问题。
1.2.2.3 CN响应IuReleaseCommand异常描述当CN存在某种异常时，收到S侧发送的Relocation Required消息，立即下发IuReleaseCommand，D侧表现为看不到任何信令，此种异常不会导致任何KPI 指标异常，但会影响用户感受。
信令过程S侧信令：D侧信令：D侧未收到任何CN下发的信令消息。
原因分析及排查需要确认和CN是否存在问题，如故障、拥塞等，重点在CN侧排查问题。
1.2.2.4 终端RB重配失败异常描述当S-RNC向CN发送Relocation Required消息后，D侧完成资源分配及建立过程，S侧下发RB重配消息，由于终端在目标侧同步失败，终端上报RB重配失败消息，记作一次跨RNC切换失败，此类异常影响系统RNC间切换成功率，此外该异常会导致终端脱离源小区覆盖而又无法完成切换，最终因覆盖问题导致掉话。
信令过程S侧信令：第 11 页D侧信令：第 13 页原因分析及排查排查方法参考物理信道重配失败。
1.2.2.5终端RB 重配超时异常描述当S-RNC 向CN 发送Relocation Required 消息后，D 侧完成资源分配及建立过程，S 侧下发RB 重配消息，由于终端在目标侧同步失败，终端上报RB 重配失败消息，记作一次跨RNC 切换失败，此类异常影响系统RNC 间切换成功率，此外该异常会导致终端脱离源小区覆盖而又无法完成切换，最终因覆盖问题导致掉话。
信令过程 S 侧信令：D侧信令：原因分析及排查排查方法参考物理信道重配超时。
1.3 CS系统间切换过程中的异常1.3.1 总体描述1.3.2 典型信令过程及异常分析1.3.2.1 重定位失败信令过程原因分析及排查TRANAP_relocation_failure_in_target_CN_RNC_or_target_system：在2G 网络侧重定位失败，原因不明，可能是GSM侧资源分配问题；TRANAP_unknown_target_rnc：可能原因如下：23G CN对接参数配置错误：外场初期进行23G测试时都是这个原因，正确配置后问题即可解决；在Not_BSICVerficationRequired配置，有时UE会上报非要求测量的频点测量事件结果，也会出现此现象；TRANAP_unspecified_failure：原因不明；1.3.2.2 UE返回handoverFromUTRANFailure信令过程原因分析及排查切换失败的原因都为configurationUnacceptable时，目前认为和UE能力有关，协议上规定，UE返回原因为configurationUnacceptable切换失败的可能为：UTRAN要求UE在不支持的情况下进行切换；或UTRAN要求UE使用其不支持的配置；或HANDOVER FROM UTRAN COMMAND消息中包含了信元“RAB information第 15 页List”，并且这个信元不包含任何一个其信元“CN domain Identity”被设置为“CS domain”的信元“RAB info”。
目前版本中HANDOVER FROM UTRAN COMMAND消息是不携带“RAB information List”信元的，因此应该是和UE能力相关。