切换失败通常是指切换的信令流程交互失败，关注点在信令的交互，只有在信令交互出现丢失或信令处理结果失败才会失败。其中，信令丢失是指信令在传输过程中出错或不能到达对端，信令处理结果失败是指终端或网络侧在处理信令时出现异常导致流程不能正常进行（如切换时资源不足）。信令传输失败根据信令传输媒介的不同可分为无线传输失败和有线传输失败，其中X2、S1接口的传输通常为有线传输，UU口为无线传输。其中，有线传输失败的概率较小，无线传输失败的概率较大，特别是信号质量较差的切换区。
1.UU接口信令异常
对于切换流程，在UU接口只有3条信令：测量报告（MEASUREMENT REPORT）、切换命令（RRC CONN RECFG）、切换完成（RRC RECFG CMP）。但有时在定位切换后立即掉话或重建问题时，也关注切换后的第一次重配置信令（RRC CONN RECFG）交互。严格来说，切换后的重配置消息已经与切换流程没有关系，且此消息不可预期，如图9-45所示。
图9-45 切换信令流程中UU口消息交互
UU接口信令异常的常见原因如下。
（1）测量报告丢失
1）UE内部层间丢失，如L3把测量报告发送给L2时，L2处理失败。
2）UE上发测量报告的UL GRANT没有收到，下行PDCCH受限。
3）UE上发的测量报告，eNB没有收到（或收到但CRC错），上行PUSCH受限。
（2）切换命令丢失
1）eNB切换内部流程处理（如邻区漏配、资源不够等）出错，没有下发切换命令。
2）UE下行PDCCH解析失败，下行PDCCH受限。
3）UE下行PDSCH解析失败，下行PDSCH受限。
（3）切换完成信令丢失
1）UE在目标小区的PREAMBLE，eNB没有收到，上行PRACH受限。
2）UE下行接收RAR失败，下行PDSCH受限。
3）UE上发切换完成，eNB没有收到，上行PUSCH受限。
UU口的传输为无线传输，其信道质量可以分为上、下行来分析。如果终端侧能够捕获RSRP、SINR、IBLER、DL/UL_Grant等信息，并配合网络侧的信令跟踪，则大多情况都可以判断上、下行的问题。信道质量的观察量通常有以下几个。
RSRP：下行导频接收功率。导频与数据域的信道质量有一定差异，通过导频RSRP、SINR可以大致了解数据信道状况。一般RSRP＞-85dBm，用户位于近点；RSRP=-95dBm，用户位于中点；RSRP＜-105dBm，用户位于远点。判断用户位于近点、中点、远点并不能完全判断用户的信道质量，尤其在加载场景下，有可能中点、近点用户的信道质量仍然不理想（当邻区RSRP与服务小区RSRP较接近时，干扰较大），需要依据其他指标来判断信道质量。
SINR：下行导频SINR。通过导频SINR可以大致了解数据信道状况。如果SINR＜0dB，则说明下行信道质量较差。当SINR＜-3dB时，说明下行信道质量恶劣，处于解调门限附近，容易造成切换信令丢失，导致切换失败。上行SINR可以通过LMT用户性能跟踪获得。
IBLER：正常情况下，IBLER应该收敛到目标值（目标值为10%，当信道质量很好时，IBLER接近或等于0）。如果IBLER偏高，则说明信道质量较差，数据误码较多，很容易造成掉话、切换失败，或者切换时延。
在判断上、下行信道质量时，有时不能完全依靠L3上下行信令是否丢失来判断。例如，下行信道质量差不仅会影响下行信令的解调，下行PDCCH解调错误，还会影响上行调度，造成上行信令丢失。信道质量问题通常是由于弱覆盖或干扰引起的。
对于空口问题定位，需要把问题定位到覆盖（弱覆盖、越区覆盖等）、干扰、邻区漏配、切换不及时等几类，再采用相应的措施解决问题。
2.X2接口信令异常
对于切换流程，只有经过X2的站间切换在X2口有切换流程的信令。在X2接口通常情况下有以下4条信令：切换请求（HANDOVER REQUEST）、切换响应（HANDOVER RE-QUEST ACK）、SN状态转发（SN STATUS TRANSFER）、UE上下文释放（UE CONTEST RE-LEASE），如图9-46所示。
图9-46 切换信令流程中X2口消息交互(www.xing528.com)
X2接口信令异常的常见原因如下。
1）切换请求丢失，可能的原因主要为eNB内部处理测量报告异常，如邻区漏配、内部模块处理失败。
2）X2口传输异常，如传输丢包。
3）切换响应丢失，可能的原因主要为源小区内部异常，源小区在目标小区回切换响应之前，向目标小区在X2口发HANDOVER CANCEL信令。
4）目标小区切换准备异常，这时通常会在X2口出现HANDOVER PREPARATION FAILURE信令。
5）X2口传输异常，如传输丢包。
6）SN状态前转信令丢失，可能的原因主要为X2口传输异常，如传输丢包、源小区内部错误。
7）UE上下文释放信令丢失，可能的原因主要为X2口传输异常，如传输丢包，目标小区收到切换完成后内部处理错误，导致没有进行S1 PATH切换，或S1 PATH切换失败。
8）对于X2口消息交互出现异常，通常是传输失败或基站内部处理出错，而基站内部处理出错的概率较小，传输失败的可能性较大，但比较难以定位，需要在传输的两端抓包确认。
3.S1接口信令异常
对于切换流程，只要是跨eNB切换，不管是经S1切换还是经X2切换，在S1口均有信令交互。在经X2接口切换时，S1接口仅有两条信令：S1AP PATH SWITCH REQ、S1AP PATH SWITCH REQ ACK；在经S1接口切换时，S1接口信令会在源eNB和目标eNB有较多的交互，如图9-47和图9-48所示。
跨X2切换的S1AP PATH SWITCH REQ丢失，可能的原因主要为目标eNB内部处理切换完成信令失败，S1口传输异常，如传输丢包。
图9-47 切换信令流程中X2口消息交互
图9-48 切换信令流程中S1口消息交互
跨X2切换的S1AP PATH SWITCH REQ ACK丢失，可能的原因主要为核心网收到S1AP PATH SWITCH REQ消息后，内部处理失败。
跨S1切换的S1AP HANDOVER REQUIRTED信令丢失，可能的原因主要为源小区因为在切换内部流程处理出错（如邻区漏配、资源不够等），没有发切换请求消息S1AP HAN-DOVER REQUIRTED，S1口传输异常，传输过程中丢失。
跨S1切换的S1AP HANDOVER REQUEST信令丢失，可能的原因主要为核心网收到S1AP HANDOVER REQUIRTED后，内部处理出错，S1口传输异常，传输过程中丢失。
跨S1切换的S1AP HANDOVER REQUEST ACK信令丢失，可能的原因主要为目标小区收到S1AP HANDOVER REQUEST后，内部处理出错（如资源不足等），S1口传输异常，传输过程中丢失。
跨S1切换的S1 HANDOVER CMD信令丢失，可能的原因主要为核心网收到S1AP HAN-DOVER REQUEST ACK后，内部处理出错，S1口传输异常，传输过程中丢失。
跨S1切换的S1AP ENB STATUS TRANSFER信令丢失，可能的原因主要为源小区处理收到S1 HANDOVER CMD后，内部处理出错，S1口传输异常，传输过程中丢失。
跨S1切换的S1AP MME STATUS TRANSFER信令丢失，可能的原因主要为核心网收到S1AP ENB STATUS TRANSFER后，内部处理出错，S1口传输异常，传输过程中丢失。
跨S1切换的S1AP HANDOVER NOTIFY信令丢失，可能的原因主要为目标小区收到切换完成消息后，内部处理出错，S1口传输异常，传输过程中丢失。
跨S1切换的S1AP UE CONTEST REL CMD信令丢失，可能的原因主要为核心网收到S1AP HANDOVER NOTIFY后，内部处理出错，S1口传输异常，传输过程中丢失。
跨S1切换的S1AP UE CONTEST REL CMP信令丢失，可能的原因主要为源小区收到S1AP UE CONTEST REL CMD后，内部处理出错，S1口传输异常，传输过程中丢失。
对于S1口消息交互出现异常，通常是传输失败或网络设备内部处理出错，设备内部处理出错的概率较小，传输失败的可能性较大，但比较难以定位，需要在传输的两端抓包确认。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
