八一宾馆LTE-2、3小区切换成功率低分析案例

合集下载

【案例】切换到错误小区导致切换失败

【案例】切换到错误小区导致切换失败

切换到错误小区导致切换失败1问题描述统计某局点LTE FDD网络忙时指标S1切换切换成功率异常,如下图忙时KPI:图1:KPI统计2处理过程2.1统计忙时S1切换成功率低于100%的小区统计全网发现S1切换成功率低于100%的小区是S-莱城-行健堂-行健堂-2-L-H-O-N-39E6732。

2.2确定S1切换失败的目标小区名称基于两两切换报表统计出S-莱城-行健堂-行健堂-2-L-H-O-N-39E6732切换失败的目标基小区为S-莱城-东方红(上联机关印刷厂)-东方红-2-L-H-O-N-39E0632。

2.3查找切换目标基站告警切换失败目标基站东方红在8-20号已断站,且至今未恢复。

2.4原因分析1)切换目标基站东方红在8月20号网元就已断裂告警,且至今未恢复正常发,因此可能由于切换到错误的小区导致切换失败。

如下图所示,小区B和C与小区A距离相近,但是邻区B被加入A的邻区列表中了,但是邻区C没有被加入邻区列表,同时小区B和C的PCI相同;驻留在小区A的终端检测到小区C时,上报C小区PCI和RSRP;由于小区B和C的PCI相同,基站A误认为终端上报的是邻区B的RSRP,就会发起向邻小区B的切换。

而邻区B断链,就会导致切换失败;在这种情况下即使邻区B正常,也很可能切换失败。

2)检查与切换目标小区PCI相同的邻区小区,并将该小区加入源基站;观察一段时间,发现指标恢复正常。

3总结PCI相同的两个小区都加入源小区的邻区列表中,会带来PCI混淆告警,但从另外一个角度会提升切换成功率。

原因是终端上报了一个PCI,基站遍历邻区列表发现邻区中有两个PCI 相同的邻区,为了避免切换到错误的小区,基站就会要求终端上报ECGI,这样就会避免终端切换到错误的小区,从而提升切换成功率。

LTE切换为题处理案例及切换参数总结

LTE切换为题处理案例及切换参数总结

切换问题处理及切换参数总结目录:简述: (1)一、案例分析: (1)1.1. 问题描述: (1)1.2. 优化: (3)二:切换参数总结: (3)1.1.UE测量配置基本信道参数表 (4)1.2.A3事件上报参数表 (4)1.3.切换算法参数表 (5)1.4.UE定时器及常量分析 (6)1.5.ENB协议定时器分析 (8)1.6.ENB实现定时器分析 (9)A1~A5,B1~B2事件总结: (10)简述:地铁部分FDD线路分布问题导致覆盖盲区场景下,FDD切TDD。

由FDD 站点覆盖快速衰落情景下,终端开启A2测量,信令窗口中频繁上报MR,无响应,切换失败导致重建。

经由本次问题处理,对切换参数进行总结。

一、案例分析:1.1.问题描述:由芍药居至太阳宫段,FDD切TDD终端占用1350(PCI=467) ENB=502165,地铁行驶过程中,信号快速衰落,终端开启A2测量,信令窗口频繁上报MR,无响应,切换失败导致RRC重建至1350(PCI=496)502163,经由此站切换至TDD38950(PCI=87)ENB=82354-42海淀十号线海淀黄庄站FDDNLS1.测试结果:1.2.优化:●参数查询:A1:-92,A2 :-100,A5 :-90,-95 CIO:0db TTT: 640ms●调整:由于FDD衰落迅速,几次测试均有-92左右迅速衰落至-120,导致重建,所以建议将A2门限提高,同时为满足快衰场景下能够顺利切换,将CIO调为10,使其提前切换,TTT切换切换时间由640ms改为160ms调整后参数:A1:-90,A2 :-92,A5 :-90,-95 CIO:10db TTT: 120ms●调整后测试二:切换参数总结:当UE处于连接状态,网络通过切换过程实现对UE的移动性管理。

切换过程包含移动性测量、控制面流程和用户面流程。

为了辅助网络作切换判决,原eNodeB为UE配置测量,使UE在切换之前上报服务小区和邻小区的信道质量,便于网络侧合理地判决切换。

关于光衰导致LTE eNodeB内切换成功率低优化案例

关于光衰导致LTE eNodeB内切换成功率低优化案例

光衰导致LTE eNodeB内切换成功率低优化案例一、现象描述:在处理KPI TOP小区时发现L800M新建站崔庄2小区切换成功率突然恶化,并导致全网切换成功率指标恶化严重,该小区切换成功率基本保持在98.9%左右,而在7月18日时指标突然恶化至81,0%左右,且切换失败次数在7月19日时达到切换失败6619次,e NodeB内切换成功率更是低至7%,急需分析排查造成异常的原因。

指标如下:指标趋势图如下:二、分析思路1、排查设备硬件故障、基站告警原因;2、核查切换参数配置是否正确;3、核查是否因PCI冲突或MOD3干扰引起;4、核查邻区配置是否有错;5、光路隐性故障;三、分析过程1、经后台查询,208204_16崔庄2小区无告警,设备工作状态正常,X2告警不影响,因冗余邻区导致,已删除,排除设备原因,如下:2、经后台查询切换参数配置,无明显异常,排除切换参数配置原因;3、经后台指标分析,改站点1、2小区eNodoB切换失败次数较多,怀疑为PCI冲突导致,结合MAPINFO,对此站点位置进行PCI核查,发现无PCI冲突,核查该站点邻区配置是否存在PCI冲突情况,经核查无相同PCI,排除PCI冲突原因,;4、对该站点BBU至RRU端光路进行收发光检测发现,该站点BBU发光正常,但2小区RRU收光较弱,怀疑为BBU端至BUU端光衰大,但未导致小区退服,通知代维对该站点BBU至RRU光路进行排查,代维现场进行收发光检测发现的确存在光衰大问题,督促代维对该站点光路进行排查故障后,该站点2小区切换成功率恢复到正常水平;最终定位为BBU至RRU光路隐性故障导致该小区切换成功率差;现场排查:经现场代维排查发现,该站点光纤安装摆放位置不合理,现场进行整改。

四、优化建议当后台KPI指标波动异常时,排除了基站告警问题、参数配置问题等原因,还需对基站隐性故障及光路隐性故障进行排查,除了排查告警、参数等问题还需对设备隐性故障进行排查,从而加快解决问题,恢复指标。

LTE无线接通率优化提升案例

LTE无线接通率优化提升案例

无线接通率低优化案例一、问题描述西安长庆宾馆-HLH-XAAO133TL-2无线接通率指标7月24号开始严重下滑,根据失败counter主要是由于RRC重建失败较高造成,其中该小区接入失败主要集中在早晚忙时间段。

二、问题分析针对该项指标进行相关的counter指标提取,发现问题主要集中在“小区内因为无上下文导致的RRC重建拒绝的次数(无)”和“UE无应答而导致RRC重建失败次数(无)”这两个counter,结合现场情况需逐步排查分析。

用户接入失败分析过程:基站告警核查当前无告警,历时告警无。

基础参数核查(随机接入、上行功控、重选)◆SRI自适应开关,自适应调整SRI调度周期◆小区级子帧树重配开关,根据小区资源使用情况,动态调整SRS的子帧配置◆PUCCH算法开关,当PUCCH资源不足时可以发起资源配置调整◆将SRS资源配置方式的接入优先◆上行功控参数路径损耗因子、PUSCH标称P0值提升UE发射功率PRB上行干扰核查无干扰,全天均值-118左右。

是否存在弱覆盖核查该站位置,怀疑是由于周边楼宇比较密集有阻挡导致覆盖不足以及深度覆盖不够,需提升调整上行功控参数路径损耗因子以及PUSCH标称P0值提升UE发射功率以及由于资源分配不足导致的RRC失败。

三、解决方案SRS/PUCCH资源分配而导致RRC连接建立失败1.打开SRI自适应开关,自适应调整SRI调度周期MOD GLOBALPROCSWITCH: SRIADAPTIVESWITCH=ON;2.打开小区级子帧树重配开关,根据小区资源使用情况,动态调整SRS的子帧配置MOD CELLALGOSWITCH: SRSALGOSWITCH=SrsSubframeRecfSwitch-1;3.打开PUCCH算法开关,当PUCCH资源不足时可以发起资源配置调整MOD CELLALGOSWITCH: LOCALCELLID=2, PUCCHALGOSWITCH=PucchSwitch-1;4.将SRS资源配置方式修改为接入优先MODSRSCFG:LOCALCELLID=0,SRSCFGIND=BOOLEAN_TRUE,TDDSRSCFGMODE=ACCESS_FIRST;UE无应答导致RRC建立失败调整上行功控参数路径损耗因子、PUSCH标称P0值提升UE发射功率MOD CELLULPCCOMM:LOCALCELLID=2,PASSLOSSCOEFF=0.8,P0NOMINALPUCCH=-105;四、实施效果对比7月27日对该小区进行参数调整,调整后指标明显提升,如下图:五、总结a)在问题分析过程中若发现失败次数集中在某个counter,需考虑整体性的原因,如是否存在故障以及干扰或者某类参数设置不当导致等。

LTE切换失败问题分析报告案例

LTE切换失败问题分析报告案例

X2IPPATH配置问题导致切换不成功关键字:X2IPPATH 切换【现象描述】切换测试时,从站点B1的标口信令跟踪发现站点B1连续出现切换准备失败,HANDOVER_REQUEST消息后出现HANDOVER_PREPARATION_FAILURE,进入该消息中可以看到cause为transport-resource-unavailable,切换不成功,如下图所示。

【原因分析】对于切换流程失败而言,如果是切换准备阶段的失败,其原因通常为以下几种:(1)传输资源不够用;(2)没有配置IPPATH;(3)IPPATH中的邻居节点配置错误。

由于切换测试阶段的网络业务负载很小,接入用户数少,通过X2口传输的数据不多,一般来说不会出现传输资源不够用的情况。

所以可以先重点怀疑IPPATH配置的问题,在处理过程中需要对X2口和IPPATH问题排查处理,一步步解决问题。

【处理过程】每次切换到目标小区完成后,UE会读取目标小区的系统消息(RRC_SIB_TYPE1),该消息中可以看到目标小区的CGI,通过CGI中的基站ID确认目标基站B2的ID。

从该次切换的切换命令(RRC_CONN_RECFG)可以找到目标小区CELL2的PCI,在目标基站B2中用MML命令查询确实存在小区CELL2,所以接下来可以针对目标基站B2以及源基站B1来检查IPPATH的配置了。

先查看B2基站对应的IPPATH有没有配置,如果配置则确认X2接口ID与IPPATH的邻接点ID是否一致。

在webLMT上的命令如下:LST SCTPLNK;检查SCTPLNK是否建立并查看目标基站B2以及源基站B1对应的SCTP链路号SCTP Link No。

DSP X2INTERFACE;检查X2INTERFACE是否配置并根据SCTP链路号SCTP Link No,查看对应X2接口的标识X2InterfaceId。

LST IPPATH; 根据X2接口标识X2InterfaceId,查看X2口两端的IP配置是否正确。

经典案例_切换失败典型优化案例

经典案例_切换失败典型优化案例

切换失败典型案例目录一、问题描述 (3)二、分析过程 (3)三、解决措施 (5)四、经验总结 (5)切换失败典型案例【摘要】近期处理top小区时发现,在入网基站开通ANR功能的情况下部分小区仍然会出现切换失败高的现象。

本文以一类切换失败率高的典型案例进行分析,同时总结从信令角度快速定位切换失败的原因,从而准确有效处理切换失败类问题,提升用户感知和降低用户投诉率。

【关键字】ANR切换失败【业务类别】切换信令、参数优化一、问题描述二、分析过程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同频且同PCI 142。

此时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切换成功率低案例

案例-小区割接导致X2切换成功率低案例

小区割接导致X2切换成功率低案例摘要: LTE异常小区优化过程中,发现阜阳锦华第一郡附近小区X2切换成功率告警出现突增现象,影响全网KPI,需处理。

关键字:异常小区 X2告警【问题描述】日常优化处理LTE异常小区过程中,发现市区X2告警出现突增现象,告警小区集中分布于阜阳锦华第一郡附近,严重影响全网指标,需处理。

地理位置:【问题分析】1告警与配置参数排查排查告警小区故障情况,未发现任何异常,基站配置参数正常,且未进行相关参数调整,排除基站侧问题。

2信令跟踪分析查询特定小区间两两切换发现切换失败小区均为438167-50,即XY-FY-市区-锦华第一郡二期-HFTA-438167-50。

U2000网管查询438167-50站点配置情况,未找到相应438167-50小区关系,即网管中不存在438167-50小区,如下:经核查,XY-FY-市区-锦华第一郡二期-HFTA-438167-50于9月5日进行了割接,割接后小区为XY-FY-市区-锦华第一郡二期-HFTA-152162-181,割接后现网中438167-50已经不存在了,割接清单如下:核查X2告警小区的外部小区以及同频邻区,发现与438167-50邻区关系依然存在,详情如下:异常小区X2告警增多的原因为:438167-50小区割接为152162-181之后,周围小区原添加的438167-50邻区关系未及时更新,导致与438167-50邻区进行X2切换时全部失败。

【问题解决】删除438167-50邻区关系,并更新438167-50割接后的邻区关系,周边X2切换恢复正常。

【问题总结】LTE网络中,站点割接后邻区未及时更新的情况时有发生,建议站点割接后,及时核查割接站点及周围站点的邻区关系,确保邻区能够及时被更新,避免漏配错配现象的发生,提升用户的4G网络感知。

切换成功率低处理案例

切换成功率低处理案例

切换成功率低处理案例LTE吉州区人民广场基站S1口少配导致切换成功率低处理案例一、现象描述在LTE网络KPI指标监控过程中发现吉州区人民广场区域的几个站点切换成功率极低,严重影响全网切换类指标,其中吉州区人民广场切换入失败次数每天达到4600多次,吉州区富华宾馆、吉州区红雨宾馆、吉州区附属医院,切换出失败次数和为4500多次。

二、原因分析1.处理流程图2.分析切换成功率低可能原因:对KPI指标及周边环境分,可发现如下问题:1)吉州区人民广场基站的邻区是否存在漏配、错配,外部邻区参数设置是否正确,PCI规划是否合理,切换参数设置是否有问题。

2)吉州区人民广场基站的切换入失败次数的和约等于周边基站切出失败的和,可定位为吉州区人民广场基站的问题导致其切入成功率低及周边基站切出功率低;三、问题排查1、吉州区人民广场及周边站点邻区核查吉州区人民广场及周边站点同频邻区核查根据基站拓扑结构核查吉州区人民广场及周边站点的邻区,确定现网邻区无漏配的问题,确定吉州区人民广场及周边站点的PCI规划合理。

2、吉州区人民广场及周边站点外部邻区定义核查吉州区人民广场及周边站点外部邻区核查核查吉州区人民广场及周边站点外部邻区的定义,主要核对外部邻区PCI及TAC设置,将外部邻区定义的PCI及TAC与现网比对,确定没问题。

3、同频切换参数检查及现场测试吉安LTE网络刚开局,现网所有切换参数均为默认值,核查无问题。

现场测试,吉州区人民广场与吉州区附属医院切换正常,验证了该站的参数设置没问题,可能有其他不常见的问题导致。

4、后台跟踪查询周边站点切换出失败原因全部为目标小区回复切换准备失败消息导致切换出准备失败后台信令跟踪对吉州区人民广场标准X2口进行跟踪,发现切换准备失败,失败原因值:传输不可用。

四、解决过程及方案查询ENODEB X2接口自建链开关状态,结果显示正常查询基站的DEVIP配置信息是否正确,结果显示正常查询基站IPRT是否正确,结果显示正常查询基站VLANID是否正确,结果显示正常查询基站SCTPLNK是否正确,结果显示配置正常查询基站IPPATH,发现S1接口配置为1条,IPPATH资源有限,所以相邻站点切到该站的成功率很低,通过增加到S1接口的IPPATH 到8条(现网标准为8条)后:修改后观察指标,恢复正常,该问题解决。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

八一宾馆LTE-2、3小区切换成功率低分析案例
问题描述:
根据KPI指标监控和省公司通报,3月19号早上八点半到中午十一点八一宾馆LTE-2、3小区的切换成功率有明显的大幅度降低,八一宾馆的指标如下:
问题分析:
通过提取3月19号八一宾馆LTE-2和八一宾馆LTE-3相应时段的CDL信令,通过分析八一宾馆工切换失败1307次,所有八一宾馆的切换失败都是指向同一个小区,该小区PCI=380,eNodeBID=606327。

如下图,切换失败次数及切换信令流程:
同时进行一步分析得出该小区切换失败原因为:
ho-failure-in-target-EPC-eNB—or-target-system。

根据CDL,从上面分析,该小区问题怀疑是邻小区的配置数据存在问题,查看这个小区的配置数据和目标小区的配置数据,源小区的配置数据不存在任何问题,源小区在添加目标小区外部定义时,由于华为基站城关区_定西路_E606327-1(ENB=606327)的PCI=380改为了PCI=378导致配置错误,造成大量的S1切换失败。

解决措施:
对八一宾馆添加城关区_定西路_E606327-1小区的错误外部定义进行删除,重新定义外部定义同时添加邻区,重新修改并添加后指标恢复正常,恢复后指标如下所示:。

相关文档
最新文档