经典案例切换失败典型优化案例.docx
《经典案例切换失败典型优化案例.docx》由会员分享，可在线阅读，更多相关《经典案例切换失败典型优化案例.docx（11页珍藏版）》请在冰豆网上搜索。
经典案例切换失败典型优化案例
切换失败典型案例
一、问题描述3
二、分析过程3
三、解决措施5
四、经验总结5
切换失败典型案例
【摘要】近期处理top小区时发现，在入网基站开通ANR功能的情况下部分小区仍然会出现切换失败高的现象。
本文以一类切换失败率高的典型案例进行分析，同时总结从信令角度快速定位切换失败的原因，从而准确有效处理切换失败类问题，提升用户感知和降低用户投诉率。
【关键字】ANR切换失败
【业务类别】切换信令、参数优化
一、问题描述
TOP小区BB-怀远-怀远工业园-HFTA-440465-51，7月6日和7日，同频切换出成功率突降，需定位问题分析：
二、分析过程
1、查询邻区关系对
查询可见BB-怀远-怀远工业园-HFTA-440465-51同频切换失败主要目标小区是站号为440378的51小区，且切换失败的主要原因为eNB间S1口小区间同频切换出准备失败次数，目标侧准备失败。
2、信令分析
根据切换出失败原因为S1口小区间同频切换出准备失败可知，信令问题出现在下图红色方框区域，第一部分为源小区经过MME向目标小区发起切换请求，申请资源；第二部分为目标小区经过MME向源小区应答请求
3、告警查询
查询相关两个基站告警情况，均不存在告警。
4、查询邻区关系
查询邻区关系发现BB-怀远-怀远工业园-HFTA-440465-51邻小区中BB-怀远-怀远县碧桂园小区北-HFTA-440378-51和BB-禹会区-禹会区杜郢-ZFTA-155959-189同频且同PCI142。
此时UE上报测量到的PCI=142给eNodeB后，eNodeB不能分辨UE测量到的邻区对象是哪个小区（BB-怀远-怀远县碧桂园小区北-HFTA-440378-51和BB-禹会区-禹会区杜郢-ZFTA-155959-189），从而导致BB-怀远-怀远工业园-HFTA-440465-51不发起切换，即图3中信令S1AP_Handover_Required消息不发送，导致切换失败。
三、解决措施
由于开启ANR功能，删除邻区并不一定能解决邻区同PCI问题，所以建议将不合理邻区关系“允许切换”修改为“禁止切换”，参数修改后BB-怀远-怀远工业园-HFTA-440465-51切换成功率回复正常水平：
四、经验总结
切换失败通常是指切换的信令流程交互失败，关注点在信令的交互，只有在信令交互出现丢失或信令处理结果失败才会失败。
其中信令丢失是指信令在传输过程中出错或不能到达对端，信令处理结果失败是指终端或网络侧在处理信令时出现异常导致流程不能正常进行（例如切换时资源不足）。
信令传输失败又可根据信令传输媒介的不同可分为无线传输失败和有线传输失败，其中X2、S1接口的传输通常为有线传输，UU口为无线传输。
其中有线传输失败的概率较小，无线传输失败的概率较大，特别是信号质量较差的切换区。
对UU口，X2口，S1口不同的切换信令分析，进行切换失败问题定位：
一、UU接口信令异常
对于切换流程，在UU接口只有三条信令：
测量报告（MEASUREMENTREPORT）、切换命令（RRCCONNRECFG）、切换完成（RRCRECFGCMP）。
但有时在定位切换后立即掉话或重建问题时，也关注切换后的第一次重配置信令（RRCCONNRECFG）交互，严格说，切换后的重配置消息已经与切换流程没有关系，且此消息不可预期。
UU接口信令异常的常见原因有：
一、测量报告丢失，可能的原因主要有：
1.UE上发测量报告的ULGRANT没有收到，下行PDCCH受限。
2.UE上发的测量报告，eNB没有收到（或收到但CRC错），上行PUSCH受限。
3、UE内部层间丢失，例如L3把测量报告给L2发送时，L2处理失败。
二、切换命令丢失，可能的原因主要有：
1.eNB因为在切换内部流程处理（如邻区漏配、邻区混淆、资源不够等）出错，没有下发切换命令
2.UE下行PDCCH解析失败，下行PDCCH受限
3.UE下行PDSCH解析失败，下行PDSCH受限
三、切换完成信令丢失，可能的原因主要有：
1.UE在目标小区的PREAMBLE，eNB没有收到，上行PRACH受限
2.UE下行接收RAR失败，下行PDSCH受限
3.UE上发切换完成，eNB没有收到，上行PUSCH受限
4.UU口的传输为无线传输，其信道质量可以分为上、下行来分析。
如果终端侧能够捕获RSRP、SINR、IBLER、DL/UL_Grant等信息，并配合网络侧的信令跟踪，大多情况都可以判断上、下行的问题。
在判断上、下行信道质量时，有时不能完成任L3上下行信令是否丢失来判断。
例如，下行信道质量差不仅会影响下行信令的解调，下行PDCCH解调错误也会影响上行调度，造成上行信令丢失。
信道质量问题通常是因为弱覆盖或干扰引起。
对于空口问题定位，需要把问题定位到覆盖（弱覆盖、越区覆盖等）、干扰、邻区漏配、切换不及时等几类，再采用相应的解决措施解决问题。
二、X2接口信令异常
对于切换流程，只有经过X2的站间切换在X2口有切换流程的信令：
在X2接口通常情况下有如下4条信令：
切换请求（HANDOVERREQUEST）、切换响应（HANDOVERREQUESTACK）、SN状态转发（SNSTATUSTRANSFER）、UE上下文释放（UECONTESTRELEASE），如下图中红色信令：
X2接口信令异常的常见原因有：
一、切换请求丢失，可能的原因主要有：
1.eNB内部处理测量报告异常，如邻区漏配、内部模块处理失败
2.X2口传输异常，如传输丢包
二、切换响应丢失，可能的原因主要有：
1.源小区内部异常，源小区在目标小区回切换响应之前，向目标小区在X2口发HANDOVERCANCEL信令
2.目标小区切换准备异常，这时通常会在X2口出现HANDOVERPREPARATIONFAILURE信令
3.X2口传输异常，如传输丢包
三、SN状态前转信令丢失，可能的原因主要有：
1.X2口传输异常，如传输丢包
2.源小区内部错
四、UE上下文释放信令丢失，可能的原因主要有
1.X2口传输异常，如传输丢包
2．目标小区收到切换完成后内部处理错，导致没有进行S1PATH切换
3.S1PATH切换失败
对于X2口消息交互出现异常，通常是传输失败或基站内部处理出错，而基站内部处理出错的概率较小，传输失败的可能性较大，但比较难以定位，需要在传输的两端抓包确认。
三、S1接口信令异常
对于切换流程，只要是跨eNB切换，不管是经S1切换还是经X2切换，在S1口均有信令交互：
在经X2接口切换时，S1接口仅有两条信令：
S1APPATHSWITCHREQ、S1APPATHSWITCHREQACK；在经S1接口切换时，S1接口信令会在源eNB和目标eNB有较多的交互。
如下图绿色信令所示：
X2接口信令异常的常见原因有：
一、跨X2切换的S1APPATHSWITCHREQ丢失，可能的原因主要有：
1.目标eNB内部处理切换完成信令失败
2.S1口传输异常，如传输丢包
二、跨X2切换的S1APPATHSWITCHREQACK丢失，可能的原因主要有：
1.核心网收到S1APPATHSWITCHREQ消息后，内部处理失败
三、跨S1切换的S1APHANDOVERREQUIRTED信令丢失，可能的原因主要有：
1.源小区因为在切换内部流程处理出错（如邻区漏配、邻区混淆、资源不够等），没有发切换请求消息S1APHANDOVERREQUIRTED
2.S1口传输异常，传输过程中丢失
三、跨S1切换的S1APHANDOVERREQUEST信令丢失，可能的原因主要有：
1.核心网收到S1APHANDOVERREQUIRTED后，内部处理出错
2.S1口传输异常，传输过程中丢失
四、跨S1切换的S1APHANDOVERREQUESTACK信令丢失，可能的原因主要有：
1.目标小区收到S1APHANDOVERREQUEST后，内部处理出错（如资源不足等）
2.S1口传输异常，传输过程中丢失
五、跨S1切换的S1HANDOVERCMD信令丢失，可能的原因主要有：
1核心网收到S1APHANDOVERREQUESTACK后，内部处理出错
2.S1口传输异常，传输过程中丢失
六、跨S1切换的S1APENBSTATUSTRANSFER信令丢失，可能的原因主要有：
源小区处理收到S1HANDOVERCMD后，内部处理出错
S1口传输异常，传输过程中丢失
七、跨S1切换的S1APMMESTATUSTRANSFER信令丢失，可能的原因主要有：
1.核心网收到S1APENBSTATUSTRANSFER后，内部处理出错
2.S1口传输异常，传输过程中丢失
八、跨S1切换的S1APHANDOVERNOTIFY信令丢失，可能的原因主要有：
1.目标小区收到切换完成消息后，内部处理出错
2.S1口传输异常，传输过程中丢失
九、跨S1切换的S1APUECONTESTRELCMD信令丢失，可能的原因主要有：
1.核心网收到S1APHANDOVERNOTIFY后，内部处理出错
2.S1口传输异常，传输过程中丢失
十、跨S1切换的S1APUECONTESTRELCMP信令丢失，可能的原因主要有：
1.源小区收到S1APUECONTESTRELCMD后，内部处理出错
2.S1口传输异常，传输过程中丢失
对于S1口消息交互出现异常，通常是传输失败或网络设备内部处理出错，设备内部处理出错的概率较小，传输失败的可能性较大，但比较难以定位，需要在传输的两端抓包确认。
升级会员 