LTE切换问题分析报告.docx
《LTE切换问题分析报告.docx》由会员分享，可在线阅读，更多相关《LTE切换问题分析报告.docx（33页珍藏版）》请在冰点文库上搜索。
LTE切换问题分析报告
1相关Counter介绍
1.1切换相关KPI公式
具体KPI指标
指标定义
eNB内切换出成功率
〔小区eNodeB内同频切换出成功次数+小区eNodeB内异频切换出成功次数-小区通过重建回源小区的eNodeB内同频切换出执行成功次数-小区通过重建回源小区的eNodeB内异频切换出执行成功次数〕/〔eNodeB内同频切换出尝试次数+eNodeB内异频切换出尝试次数〕*100%
eNB间切换出成功率
〔小区eNodeB间同频切换出成功次数+小区eNodeB间异频切换出成功次数-小区通过重建回源小区的eNodeB间同频切换出执行成功次数-小区通过重建回源小区的eNodeB间异频切换出执行成功次数〕/〔eNodeB间同频切换出尝试次数+eNodeB间异频切换出尝试次数〕*100%
同频切换出成功率
〔小区eNodeB间同频切换出成功次数+小区eNodeB内同频切换出成功次数-小区通过重建回源小区的eNodeB间同频切换出执行成功次数-小区通过重建回源小区的eNodeB内同频切换出执行成功次数〕/（eNodeB间同频切换出尝试次数+eNodeB内同频切换出尝试次数）*100%
异频切换出成功率
〔小区eNodeB间异频切换出成功次数+小区eNodeB内异频切换出成功次数-小区通过重建回源小区的eNodeB间异频切换出执行成功次数-小区通过重建回源小区的eNodeB内异频切换出执行成功次数〕/（eNodeB间异频切换出尝试次数+eNodeB内异频切换出尝试次数）*100%
切换成功率
（eNodeB间同频切换出成功次数+eNodeB间异频切换出成功次数+eNodeB内同频切换出成功次数+eNodeB内异频切换出成功次数-通过重建回源小区的eNodeB间同频切换出执行成功次数-通过重建回源小区的eNodeB间异频切换出执行成功次数-通过重建回源小区的eNodeB内同频切换出执行成功次数-通过重建回源小区的eNodeB内异频切换出执行成功次数）/（eNodeB间同频切换出尝试次数+eNodeB间异频切换出尝试次数+eNodeB内同频切换出尝试次数+eNodeB内异频切换出尝试次数）*100%
✧eNB内切换出成功率
L.HHO.IntraeNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntraeNB.InterFreq.Succ.ReEst2Src）/
（L.HHO.IntraeNB.IntraFreq.PrepAttOut+L.HHO.IntraeNB.InterFreq.PrepAttOut）*100%
✧eNB间切换出成功率
L.HHO.IntereNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntereNB.InterFreq.Succ.ReEst2Src）/
（L.HHO.IntereNB.IntraFreq.PrepAttOut+L.HHO.IntereNB.InterFreq.PrepAttOut）*100%
✧同频切换出成功率
L.HHO.IntereNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntraeNB.IntraFreq.Succ.ReEst2Src）/
（L.HHO.IntereNB.IntraFreq.PrepAttOut+L.HHO.IntraeNB.IntraFreq.PrepAttOut）*100%
✧异频切换出成功率
L.HHO.IntereNB.InterFreq.Succ.ReEst2Src-L.HHO.IntraeNB.InterFreq.Succ.ReEst2Src）/
（L.HHO.IntereNB.InterFreq.PrepAttOut+L.HHO.IntraeNB.InterFreq.PrepAttOut）*100%
✧切换出成功率
〔L.HHO.IntereNB.IntraFreq.ExecSuccOut+L.HHO.IntereNB.InterFreq.ExecSuccOut+
L.HHO.IntraeNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntraeNB.InterFreq.Succ.ReEst2Src）/
（L.HHO.IntereNB.IntraFreq.PrepAttOut+L.HHO.IntereNB.InterFreq.PrepAttOut+
L.HHO.IntraeNB.IntraFreq.PrepAttOut+L.HHO.IntraeNB.InterFreq.PrepAttOut）*100%
1.2Counter解释
Counter解释：
✧切换成功率Counter
CounterName
指标中文名称
小区eNodeB间同频切换出成功次数
小区eNodeB间异频切换出成功次数
小区eNodeB内同频切换出成功次数
小区eNodeB内异频切换出成功次数
小区通过重建回源小区的eNodeB间同频切换出执行成功次数
小区通过重建回源小区的eNodeB间异频切换出执行成功次数
小区通过重建回源小区的eNodeB内同频切换出执行成功次数
小区通过重建回源小区的eNodeB内异频切换出执行成功次数
eNodeB间同频切换出尝试次数
eNodeB间异频切换出尝试次数
eNodeB内同频切换出尝试次数
eNodeB内异频切换出尝试次数
✧切换失败counter原因：
CounterName
指标中文名称
核心网原因导致模式内切换出准备失败次数
目标小区无响应导致模式内切换出准备失败次数
目标小区回复切换准备失败消息导致模式内切换出准备失败次数
源小区发送切换取消导致模式内切换出准备失败次数
eNodeB间模式内切换出取消次数
对端回复切换响应消息合法性检查失败导致切换出准备失败次数
无对应的邻区关系导致无法发起同频切换过程的次数
无对应的邻区关系导致无法发起异频切换过程的次数
1.3Counter计数位置与说明
图〔2〕
1.3.2X2切换
图〔3〕
2.3.3S1切换
图〔4〕
注明：
尝试切换Counter都计数在A点位置，准备切换Counter都计数在B点位置，切换成功Counter都计数在C点位置
1.3.4切换失败Counter说明
图〔5〕
a）.在S1接口切换与X2接口切换过程中的切换准备阶段，源小区收到来自MME的UECONTEXTRELEASEMAND消息时，如果切换过程中源小区和目标小区为同频或异频，指标加1。
图〔6〕
b）.在S1接口切换与X2接口切换过程中的切换准备阶段完毕时，源小区未收到来自目标eNodeB的任何消息，包括如下场景：
在S1接口切换时，未收到MME发出的HANDOVERMAND消息与HANDOVERPREPARATIONFAILURE消息；在X2接口切换时，未收到对端eNodeB发出的HANDOVERREQUESTACKNOWLEDEG消息与HANDOVERPREPARATIONFAILURE消息。
如果切换过程中源小区和目标小区为同频或异频，指标加1。
图〔7〕
c）.在S1接口切换过程中的切换准备阶段，当源小区收到来自MME的HANDOVERPREPARATIONFAILURE消息时，或在X2接口切换过程中的切换准备阶段，当源小区收到来自目标小区的HANDOVERPREPARATIONFAILURE消息时，如果切换过程中源小区和目标小区为同频或异频，指标加1。
图〔8〕
d）.在S1接口切换与X2接口切换过程中，切换准备阶段未完毕，源小区判决取消本次切换，并发送HANDOVERCANCEL消息时，如果切换过程中源小区和目标小区为同频或异频，指标加1
在S1接口切换与X2接口切换过程中，源小区发送HANDOVERCANCEL消息时，如果切换过程中源小区和目标小区为同频或异频，指标l加1。
图〔9〕
e）.在S1接口切换过程中的切换准备阶段，当源小区收到来自MME的HANDOVERMAND消息时，或在X2接口切换过程中的切换准备阶段，当源小区收到来自目标小区的HANDOVERREQUESTACKNOWLEDGE消息时，由于合法性检测失败，源小区判决取消本次切换，如果切换过程中源小区和目标小区为同频或异频，指标加1。
2指标分析
切换成功率指标分析流程
说明：
网管测统计到切换失败原因
✧核心网原因导致切换出准备失败次数
✧目标小区无响应导致切换出准备失败次数
✧目标小区回复切换准备失败消息导致切换出准备失败次数
✧源小区发送切换取消导致切换出准备失败次数
✧eNodeB间切换出取消次数
2.2TOP小区掉话原因处理
小区切换失败Counter
CounterName
指标中文名称
核心网原因导致模式内切换出准备失败次数
目标小区无响应导致模式内切换出准备失败次数
目标小区回复切换准备失败消息导致模式内切换出准备失败次数
源小区发送切换取消导致模式内切换出准备失败次数
eNodeB间模式内切换出取消次数
对端回复切换响应消息合法性检查失败导致切换出准备失败次数
无对应的邻区关系导致无法发起同频切换过程的次数
无对应的邻区关系导致无法发起异频切换过程的次数
✧鉴别切换失败原因（,,，,,L.HHO.Prep.FailOut.TargetIllegal,,）。
✧查看基站有无告警，小区状态是否正常：
〔通过LSTALMAF查询站点实时告警，LSTALMLOG参考历史告警；存在告警如此降低功率切换用户，严重的临时去激活小区，通知维护人员处理。
✧查询有无外部干扰〔PRB上行干扰噪声平均值>-110dBm,如此存在外部干扰〕；统计话务看是突发的还是持续的，可应急通过MODPDSCH降低功率处理。
✧提取两两小区切换，确定切换出目标小区，核查外部小区参数〔PCI、TAC、频点、小区标识、切换参数〕配置有无错误；假如错误如此对外部定义的小区进展修改，另外关注两两小区切换切换过早和切换过晚或者乒乓切换统计〔、、〕，进展相应的CIO调整。
以上问题都解决不了需安排外场人员测试，同时后台进展信令跟踪，找出问题原因。
3案例
3.1TD-LTE基站未与时割接到新MME导致切换失败案例分析
【问题描述】：
某某西乡塘某某师X明秀校区_HLH、某某西乡塘区如家快捷酒店_HLH、某某西乡塘区中医学院_HLH、某某西乡塘区某某区民族医院_HLH、某某西乡塘区金棉楼_HLH、某某西乡塘区北湖集贸市场2_HLH、某某西乡塘区北湖生活区19栋_HLH和某某西乡塘区北湖生活区19栋_HLH等站点在14：
00后切换指标严重恶化，对全网切换成功率指标造成影响；如如下图所示：
以某某西乡塘某某师X明秀校区_HLH为例
【问题分析】：
切换成功率低通常有以下几种原因，需逐步排查：
1、基站故障告警；
2、邻区以与切换参数等不合理，如：
外部小区、切换参数等配置错误会直接导致切换失败；
3、弱覆盖；
4、强干扰；
5、拥塞；
6、异常用户终端；
7、传输、核心网等问题；
【问题排除过程】：
经核查发现切换异常的站点很集中，都位于明秀路某某师X学院附近，且切换异常都是在14：
00之后，因此可以判断导致切换异常为同一原因，于是抽取某某西乡塘某某师X明秀校区_HLH进展重点分析。
1、对某某西乡塘某某师X明秀校区_HLH的故障告警进展核查，核查发现此时段并无故障告警；
2、对于目前LTE基站版本在配置邻区数据时可能会出现小区名称与PCI，eNodeBID等数据不一致的情况。
对某某西乡塘某某师X明秀校区_HLH进展外部小区等数据进展核查，核查结果未发现异常；
3、对于干扰对切换的影响一般情况下是导致空口质量恶化导致信令交互失败，但是一般不会出现切换全部失败，但是对某某西乡塘某某师X明秀校区_HLH_1的TDL数据进展分析时发现与某一基站切换全部失败，不像是由干扰导致
为了验证判断我们对该小区的干扰数据进展了核查，核查结果显示并无干扰；
4、弱覆盖对切换的影响类似与干扰对切换的影响，主要表现在空口质量，一般情况下也不会出现切换全部失败的现象。
某某西乡塘某某师X明秀校区_HLH位于明秀路处于市中心位置，因此排除了弱覆盖的因素；
5、特定的异常用户终端一般情况下只会对单个特定服务小区造成影响，但是这次切换异常为整个区域同时涉与多个站点，因此可以排除异常用户终端的因素；
6、拥塞会直接影响切换等KPI指标，但是目前的LTE网络负载还很轻，除开重大节日等情况不会出现拥塞等情况，因此可以排除拥塞的因素；
7、为了核查是否是传输、核心侧等问题，我们在U2000上对eNodeBID为492084〔〕的站点进展了信令跟踪。
在对某某西乡塘区如家快捷酒店_HLH的X2接口信令跟踪是发现该站的X2切换全部失败！
从上图可以看出失败原因值为unknown-MME-code，推测某某西乡塘区如家快捷酒店_HLH与MME的链路配置存在问题导致MME不可达。
同时对某某西乡塘区如家快捷酒店_HLH站点状态进展了跟踪，据知该站之前由于故障一直处于断链状态在10月30日才重新开启，操作日志显示该站工程人员在14：
19进展处理后开启，其时间跟切换异常时段吻合！
同时了解到某某移动现网MME之前进展过一次割接，全点都已经割接到新的MME下。
考虑到某某西乡塘区如家快捷酒店_HLH之前一致是断连状态很有可能因为断链而导致还继续下挂在老的MME下，为了验证推断我们对某某西乡塘区如家快捷酒店_HLH的SCTP对端对象配置信息进展了核查，核查结果显示某某西乡塘区如家快捷酒店_HLH还下挂在旧的MME下没有割接到新的MME〔旧的MMEIP最后一位为1或2〕，
到这里根本可以确定切换异常是因为某某西乡塘区如家快捷酒店_HLH没有与时更新为新的MMEIP而导致MME不可达而切换失败。
【解决方法】：
已经确定为MME的IP问题，联系客户并推动工程方处理，在割接到新的MME后切换指标恢复正常。
3.2同频同PCI导致无法切换
【问题描述】：
测试工程师在对铜鼓岭应急通信车测试过程中发现：
周围站点无法切入应急通信车
【问题分析】：
关于切换问题总体处理思路如下：
1、首先对测试数据进展分析
车辆由凤岭2站向铜鼓岭应急车方向行驶，在距离应急车不足200M的地方，凤岭2站-2小区的RSRP值为-97dbm，UE从凤岭2站-2小区向应急通信车-1发送多条测量报告，但UE始终没有收到切换命令。
2、项目组对铜鼓岭应急通信车告警信息进展查询核实，并未发现存在告警故障。
3、对铜鼓岭应急通信车的干扰进展排查分析，后台提取干扰检测图如下：
铜鼓岭应急通信车干扰检测图：
从干扰检测图可以看出铜鼓岭应急通信车并未存在干扰，排除由于干扰导致无法切换。
4、对该站点的邻区关系以与外部数据进展核查，经核实外部数据以与邻区关系准确
详细的邻区关系如下：
进一步核实发现下面邻区对：
本地小区名称
enodeid
频点
PCI
邻区小区名称
enodeid
频点
PCI
某某青秀区铜鼓岭应急车_HLH_1
41123
38350
258
某某青秀区青环路铜鼓岭_HLH_2
491767
38350
260
某某青秀区铜鼓岭应急车_HLH_2
41123
38350
260
某某青秀区青环路铜鼓岭_HLH_1
491767
38350
258
应急通信车与青环路铜鼓岭同频同PCI，显然PCI设置不准确，经核实青环铜鼓岭站点已被删除，应急车在青环路铜鼓岭站点附近，客户无规划新的PCI数据而是直接用该站点PCI数据，从规划角度来看这样操作本身没有问题，但把该站点的小区添加为邻区关系并且青环路铜鼓岭和应急通信车与周围站点都存在邻区关系〔删除青环路铜鼓岭站点时未删除相应的邻区关系〕显然是错误，由于应急通信车和青环路铜鼓岭同频同PCI,UE在满足切换条件向应急通信车切换时，enb不知道那个为目标小区，一直发测量报告而不发生切换。
【问题处理】：
删除周围站点与青环路铜鼓岭站点存在的邻区关系
【问题解决】：
处理后应急通信车能够与青秀区凤岭2站正常切换。
【总结】：
现网删除站点后一定把冗余数据删除。
PCI规划时一定满足confusion-free原如此，一个小区的两个相邻小区具有一样的PCI，这种情况下如果UE请求切换到ID为A的小区，eNB不知道哪个为目标小区。
称这种情况为confusion，如如下图所示：
Confusion-free原如此除了要求同PCI小区有足够的复用距离外，为了保证可靠切换，要求每个小区的邻区列表中小区PCI不能一样，同时规划后的PCI也需要满足在二层邻区列表中的唯一性。
3.3故障导致切换失败
【现象描述】
某某横县宝华东路_HLH_1小区进展KPI统计时，发现某某横县宝华东路_HLH_1小区在6月5日〔11：
00-12：
00〕时间段内切换成功率偏低，该小区KPI指标情况如下：
无线掉线率：
无线接通率：
切换成功率：
切换成功率主要通过话务统计获得，根据区公司推荐的公式为：
切换成功率=[（eNodeB间同频切换出成功次数+eNodeB间异频切换出成功次数+eNodeB内同频切换出成功次数+eNodeB内异频切换出成功次数-通过重建回源小区的eNodeB间同频切换出执行成功次数-通过重建回源小区的eNodeB间异频切换出执行成功次数-通过重建回源小区的eNodeB内同频切换出执行成功次数-通过重建回源小区的eNodeB内异频切换出执行成功次数）/（eNodeB间同频切换出尝试次数+eNodeB间异频切换出尝试次数+eNodeB内同频切换出尝试次数+eNodeB内异频切换出尝试次数）*100%。
切换差TOP小区可通过OMC920提取切换失败原因：
1）核心网原因导致切换出准备失败次数
2）源小区发送切换取消导致切换出准备失败次数
3）目标小区回复切换准备失败消息导致切换出准备失败次数
4）目标小区无响应导致切换出准备失败次数
5）eNodeB发起的原因为切换失败的UEContext释放次数
从以上KPI指标统计结果来看，该小区无线接通率为100%，无线掉线率为0.97%，同频切换成功率较差，切换失败主要是目标小区回复切换准备失败消息导致切换出准备失败次数
较高引起。
【问题分析分析】
1、从后台提取切换失败相关测量报告发现该小区切换目标小区回复切换准备失败消息导致切换出准备失败次数较高，可以通过查询在此时间段内目标小区状态来进展问题分析。
2、从后台提取该时间段内该小区切换失败较高指标如下：
3、从以上查询结果可以看出，某某横县宝华东路_HLH_1小区切换指标异常主要是与某某横县环城东路_HLH_2小区切换失败次数较高引起，怀疑某某横县环城东路_HLH站点在此时间段内有异常情况。
【处理过程】
从后台查询历史告警，查看某某横县环城东路_HLH在6月5日〔11：
00-12：
00〕时间段内告警如下：
从以上告警统计结果可以看出，在此时间段内某某横县环城东路_HLH连续出现小区不可用、基站控制面传输中断、以太网链路故障、X2接口配置更新失败等告警，从而严重影响某某横县宝华东路_HLH_1与某某横县环城东路_HLH_2切换成功率。
【分析结果】
根据以上切换测量、告警统计结果来看，该小区切换成功率偏低主要是因为某某青秀区荣和大地3站_HLH站点故障引起，需推动基站维护人员上站处理。
3.3跨厂家边界模三干扰导致切换失败
【问题描述】：
某市局方领导投诉在某重点道路途径时信号比拟好，但SINR非常低，下载速率只有KB级。
接到投诉后我方马上安排了复测，希望能复现该问题。
测试车在该重点道路往返反复测试屡次，发现在某路段确实能复现该投诉问题，RSRP在-95dBm以上，但SINR却在5dB以下，下载速率低于5Mbps。
该路段周围站点密集，覆盖良好，道路宽阔，双向8车道道路，且有宽阔绿化带，道路双向总宽近百米。
【问题分析】：
某市TD-LTE网络站点比拟密集，全网平均站间距在300至400米之间，超近站也较多，所以MOD3干扰成了该网络优化中最主要、最重要的工作之一。
如如下图所示两个相邻基站的小区相对距离较近，切A站是我方设备，B站为其他厂家设备。
通过跟踪信令分析，A小区上报了MR，220和服务小区358的MOD3相等，所以干扰是比拟大的。
由信令分析，网络侧下发了切换命令后UE并没有收到，由UE侧可看到此时SINR很差为1.8;。
【问题处理】：
通过以上分析可知，发生SINR低、下载速率低的根本原因，而MOD3干扰是是由2同模PCI引起，同时MOD3干扰引起的切换失败更加剧了下载速率降低，下载任务失败。
为了快速解决此问题，将该重点道路附近A站1小区的PCI由220调整为219，0小区的PCI由219调整为220，并将0小区和1小区方位角各顺时针调整10度。
干扰得到躲避，投诉问题得到解决。
3.4邻区关系配置引起切换失败问题
【问题描述】：
某移动在进展TOPN分析时发现邮政局LTE基站B小区切换成功率较低影响全网KPI指标。
窗体顶端
查询粒度窗体底端
ENBFunction名称
切换成功率LTETS
1周
[TDD]QHFUN6432邮政局-ZLHF（935213）
62.79%窗体底端
切换成功的采样点从消息HORequest始，终止于消息RRCConnectionReconfigurationplete。
目标小区等待消息RRCConnectionReconfigurationplete超时或未收到消息如此认为切换失败。
切换失败可能的原因如下：
1）目标小区上行干扰导致的随机接入失败
2）目标小区硬件故障或异常告警导致的接入失败
3）目标小区接入参数配置错误导致接入失败
4）存在一样PCI的外部小区和邻区
1.提取基站干扰指标，三个小区低噪正常无明显干扰，初步排除干扰导致切换失败。
2.提取基站近期告警，基站无异常告警，初步排除硬件故障导致切换失败。
3.提取小区点对点切换指标发现邻区关系中异常存在25433-0小区，邮政局B小区至该小区所有的切换全部失败。
指标如如下图所示：
查询粒度
小区名称
邻区关系
[TDD]系统内小区间异频切换出请求次数
[TDD]系统内小区间异频切换出成功次数
[TDD]系统内小区间异频切换出失败次数
1天
[TDD]QHFUN5213邮政局-ZLHF-2
（2）
0:
460:
00:
205433:
0
176
0
176窗体底端
核查邮政局B小区邻接关系参数发现邻区参数配置中，EnodeBid25433配置了两个小区0和1，查询网管数据，25433是迎宾路营业厅室分，只有一个小区，小区编号是1，0小区为冗余的错误数据。
现场抓取信令，在源小区下发的RRCconnec
升级会员 