定时器原因导致的S1口切出成功率低问题处理-浙江.docx

定时器原因导致的S1口切出成功率低问题处理-浙江.docx

ID:60901908

大小:1.55 MB

页数:4页

时间:2020-12-30

定时器原因导致的S1口切出成功率低问题处理-浙江.docx_第1页
定时器原因导致的S1口切出成功率低问题处理-浙江.docx_第2页
定时器原因导致的S1口切出成功率低问题处理-浙江.docx_第3页
定时器原因导致的S1口切出成功率低问题处理-浙江.docx_第4页
资源描述:

《定时器原因导致的S1口切出成功率低问题处理-浙江.docx》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库

1、定时器原因导致的S1口切出成功率低问题1问题描述在处理切换成功率低的TOPN小区时,发现某小区切出成功率偏低,在90%左右。而导致切换失败的原因基本上都为“eNb间S1口小区间同频切出执行失败,其他原因”。2问题分析排查查看问题站点假山新村的小区对切换统计,看到S1口的切出失败都发生在与银海苑站点之间,而银海苑站点是半个月前新开站点。那么问题极可能就出在银海苑站点上。再查看到银海苑站点的所有小区对切换统计(一个月),同频切出成功率低的小区都存在相同的现象。进行后台网管的统一信令跟踪,提取切换源侧的后台信令,看到了如下切换失

2、败:从信令上可以看到,eNodeB下发切换命令后很快就收到了MME的上下文释放命令Uecontextreleasecommand,原因为release_due_to_eutran_generated_reason。从内部模块间的信令也看不出有价值的信息。由于切出成功率在90%,那么10%的失败可不可能是由于接入失败导致的呢?所以做了调整Prach接入起始RB位置调整的测试,发现修改为手动配置并且起始RB从高位开始后,S1口切换失败返回源侧的次数增加了,而other原因的次数并没有减少,说明可能不是接入导致的切换失败。(事后

3、想想,没必要做此操作。下发切换命令后很快就收到MME的消息,说明在目标侧的接入应该是没问题的。)同时在后台跟踪源侧小区和目标侧小区的信令,通过handoverrequired和handoverrequest消息中的Source_Identity串联起完整的切换信令,半个小时内看到两次如下场景的切换,在目标侧的信令是这样的:eNodeB在给MME发送切换成功handovernotify消息的同时,还发送了UeContextReleaseRequest消息,携带原因为User_Inactivity。看来问题可能就出在User_

4、Iactivity的定时器上啦,可到底是怎么回事呢?查看目标侧银海苑站点及周边站点的UE常量和定时器中的控制面的User_Iactivity定时器和基于移动性的UE未激活定时器配置。银海苑站点配置的时长为默认值10s和5s,而其他周边站点配置的时长为20s/20s。那么是由于周边站点配置的两个定时器时长相同导致的,还是由于目标侧银海苑站点配置的定时器时长相比周边站点太短导致的呢?我们修改参数进行验证:(1)修改效实中学站点的两个定时器时长从20s/20s为20s/15s(黄色为修改后),发现似乎有改善,但是切换成功率提升不

5、多,且导致切出失败的主要原因还是other。(2)修改目标侧银海苑站点控制面的User_Iactivity定时器时长为不同值再进行测试,证明确实是由于目标侧站点的控制面的User_Iactivity定时器比周边源侧站点的时长小导致的。1问题原因总结在Handoverrequired/Handoverrequest消息中,通过rrm_Config这个IE来告知目标侧用户在源侧的User_Inactivity时长。rrm_ConfigPresent=1,即表示携带了;否则即没有携带。ue_InactiveTime=6:RRM_

6、Config_ue_InactiveTime_Root_s15,即当前定时器已经过了15s。这个里面携带的值只能是网管上可以配置的值,如果当前过了18s,那么也只能指示为15s。如果用户在切换时,依然有数据传输,没有进入不活动状态,即User_Inactivity定时器未启动,那么在Handoverrequired/Handoverrequest消息中也是不携带rrm_Config这个IE的。我们在全局业务开关中有User_Inactivity使能开关,但此开关是总开关,切不可随便关闭,否则可能导致UE无数据传输时我们也不

7、释放承载,变为空闲态。为什么切换走X2口后,切换成功率就正常了呢?那是因为X2的切换,源侧收到的上下文释放消息后,不检查里面携带的原因值;而且消息里也不携带任何原因值。但S1口切换,是需要判断上下文释放消息中携带的原因为handover_successful时才统计切换成功的。因此此问题不影响用户真实的切换,只影响性能统计结果。协议36.331中有关于rrm_Config的介绍。1问题处理排查全网控制面的User_Iactivity定时器和基于移动性的UE未激活定时器,保证全网关于此两个定时器时长配置相同。同时也修改基于移

8、动性的UE未激活定时器时长小于控制面的User_Iactivity定时器时长。切换尽量走X2,开启全网的X2自建立自删除开关。网管上X2的SCTP链路,使用闭塞功能无效,切换依然可以正常走X2切换;需要使用不使能来使某个X2失效。此问题虽然是eNodeB定时器设置不同导致的问题,但核心网MME对于此种场

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。