LTE案例库总结
LTE切换为题处理案例及切换参数总结
LTE切换为题处理案例及切换参数总结切换问题处理及切换参数总结⽬录:简述:地铁部分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在切换之前上报服务⼩区和邻⼩区的信道质量,便于⽹络侧合理地判决切换。
测量配置基本信道参数表●eueMeasCellSMeasureRsrpSmeasure:服务⼩区RSRP门限启动测量的服务⼩区RSRP门限,取值(-141..-44),单位为dBm。
此参数仅对针对信道质量的测量配置有效,对于针对CGI上报的测量配置⽆效。
对于针对信道质量的测量配置,当⽹络侧没有配置此参数,或者配置了此参数,且服务⼩区RSRP低于此参数指⽰的门限值时,UE根据测量配置对邻⼩区进⾏测量和上报。
LTE案例库总结
LTE案例库总结1.LTE下载速率低原因及相关案例 (5)1.1无线环境 (5)1.1.1案例1:系统外干扰(DCS1800)导致LTE宏站单小区下载速率低 (6)1.1.2案例2:服务小区与邻小区PCI存在mod3干扰造成下载速率过低 (8)1.1.3案例3:由GPS失锁引起的F频段LTE基站上行干扰 (9)1.2容量 (10)1.3无线参数配置 (10)1.3.1案例4:爱立信小区上下行时隙配比错误导致上行高BLER 速率低 (10)1.3.2案例5:LTE的功率PA、PB参数设置不合理导致下载速率低的处理 (11)1.3.3案例6:爱立信LTE小区DLTARGETBLER参数配置有误导致下行速率低121.3.4案例7:华为eNodeB升级8.0版本默认开启MR功能后导致速率低 (12)1.3.5案例8:由于PDCCH信道误码率较高导致下载速率波动 (13)1.3.6案例9:TA同步功能未打开导致LTE下载速率抖降问题案例(14)1.4传输问题 (14)1.4.1案例10:LTE传输问题导致小区下载速率低 (14)1.5传输参数问题 (15)1.5.1案例11:PTNQOS参数限制导致LTE下载速度低案例 (15)1.5.2案例12:PTN侧MAC地址学习功能未配置导致LTE基站FTP下载速率低161.5.3案例13:由交换机端口配置不正确导致LTE TDD下载速率波动问题 (17)1.6核心网参数 (17)1.6.1案例14:QCI设置错误导致演示厅LTE下行速率低问题 (17)1.7基站存在故障或告警 (19)1.7.1案例15:室分场景多RRU合并后某一RRU驻波导致速率低(19)1.8其它类别 (19)1.8.1案例16:LTE测试软件配置错误导致下载速率低 (19)1.8.2案例17:由于合路器接法不正确引起的下载速率低的问题(20)1.8.3案例18:LTE室分双路不平衡导致下载速率低 (22)2.LTE基站小区无法建立或建立异常问题及案例 (23)2.1无线参数配置 (23)2.1.1案例1:GPS数据配置错误导致LTE TDD无法正常开通的案例 (23)2.1.2案例2:LTE宏站小区CRS端口配置错误导致小区无法建立(24)2.1.3案例3:LTE小区与RRU关联错误导致覆盖接反 (25)2.1.4案例4:LTE基站eNodeB ID标识不唯一导致基站S1偶联链路频繁规律闪断(26)2.1.5案例5:大唐和华为GTP-U检测功能参数协商不一致导致LTE站点业务频繁中断 (26)2.1.6案例6:由于TDS频点设置问题导致LTE基站无法开启的案例 (27)3.LTE切换问题及案例 (28)3.1覆盖 (28)3.1.1案例1:由于弱覆盖导致成都理工大学LTE小区1与音乐公园LTE小区2切换失败案例 (28)3.2无线参数配置 (29)3.2.1案例2:爱立信LTE小区DCI配置错误导致切换失败 (29)3.2.2案例3:开启防乒乓切换开关导致不切换 (29)3.2.3案例4:由切换门限设置错误导致某LTE站无法进行异频切换 (30)3.2.4案例5:TAU与X2切换冲突导致切换失败并掉线 (31)3.3核心网参数 (32)3.3.1案例6:LTE核心网鉴权关闭导致切换失败 (32)3.4传输参数 (32)3.4.1案例7:LTE基站S1口少配导致切换成功率低处理案例 (32)3.5异厂家参数配置 (33)3.5.1案例8:爱立信与中兴LTE邻小区RLC传输模式配置不一致导致切换失败333.5.2案例9:大唐与诺西Local Cell Resource ID配置不一致导致切换失败的案例343.5.3案例10:由于DRB-ID分配策略华为中兴LTE异厂家切换失败案例 (35)4.LTE终端接入问题 (35)4.1无线参数配置 (35)4.1.1案例1:TD-LTE帧同步参数配置错误导致上行干扰,造成终端有信号无法接入 (35)4.1.2案例2:TDL完整性保护算法设置错误导致部分终端无法上网 (36)4.1.3案例3:爱立信室分小区PrachConfigIndex配置错误导致接入性差 (37)4.2核心网配置 (38)4.2.1案例4:LTE的S1口IP配置错误导致终端无法正常接入 (38)4.2.2案例5:在MME中未绑定IMSI和HSS对应关系导致LTE 新号段无法附着到网络 (39)4.3传输参数配置 (40)4.3.1案例6:未设置用户面路由导致LTE基站无业务速率 (40)5.2/3/4G互操作问题 (40)5.1.1案例1:由于3G/4G的PLMN不同且未配置EHPLMN导致TD-S重选TD-L失败 (40)5.1.2案例2:华为和中兴MME选路策略不同导致CSFB被叫接通率较低 (41)6.掉话问题 (43)6.1.1案例1:TD-LTE SRS带宽重配置导致掉话率高案例 (43)。
LTE典型案例分析
LTE典型案例分析覆盖类1.1 概述覆盖类问题只要涉及弱覆盖、越区覆盖、过覆盖、无主导小区、上下行不平衡及导频污染等。
在TD-LTE中一般认为RSRP<-110dBm,认为是弱覆盖。
越区覆盖:由于基站天线挂高过高或下倾角过小引起的该小区覆盖距离过远,从而越区覆盖到其他站点覆盖的区域,并且在该区域终端接收到的信号电平较好。
过覆盖:指网络中存在过度的覆盖重叠,容易引起干扰和乒乓切换;无主导小区:指某一片区域内服务小区和邻区的接收电平相差不大,不同小区之间的下行信号在小区重选门限附近的区域,并且无主导覆盖的区域接收电平一般或者较差,在这种情况下由于网络频率复用的原因,导致服务小区的SINR不稳定,可能发生空闲态主导小区频繁重选、连接态频繁切换,无主导覆盖也可认为是若覆盖的一种。
导频污染:指在某一点存在过多(一般认为大于等于3个)的强导频,但却没有一个足够强的主导频;1.2弱覆盖1.2.1弱覆盖分析造成弱覆盖的原因有:1、规划的站点由于种种原因如物业等没有开起来;2、天线方位角、下倾角不合理,如下倾角过低;3、在站建起来后,由于新建楼宇的遮挡,导致部分区域RSRP很差;4、站点过高,如四十多米或更高,会造成塔下黑5、下倾角、方位角由于条件所限,无法调整,如:美化邓杆站点不方便调整天线的方位角(3个天线方位要一起转,因为外面有罩子盖住下倾角无法调整,如科技园四、海德三路等;深大校园里站点天线都是放在美化罩子(长方体的箱子)里面,对天线的下倾角和方位角调整范围也有影响(如:深大、深大南校等))。
针对以上原因建议的方案有:1、推动客户将规划站点尽快开起来;2、调整天线方位角、下倾角到合理位置;1.2.2天线方位角不合理导致弱覆盖现象:科技园三的102和104小区由于天线被住宅楼遮挡,导致覆盖区域内部分道路信号较弱,存在弱覆盖,科技园三站点周围的地物如图:图表1科技园三周围地物调整前道路的电平值如下图:图表2优化前科技园三覆盖措施:将104小区的方位角由20度调整为40度;将102的方位角由150度调整到100度;调整后弱覆盖得到改善,如下图:图表3优化后科技园三覆盖1.2.3天线方位角下倾角不合理导致的弱覆盖现象:东都花园附近有小段路RSRP低于-110dBm,该路段属于东都花园和龙中站点主覆盖区,需要调整东都花园和龙中站的天馈方向角和下倾角加强覆盖。
LTE路测案例分析报告
LTE路测案例分析报告LTE (Long Term Evolution)是第四代移动通信技术的标准之一,其提供了更高的数据传输速率和更低的时延,以满足用户对高速移动宽带数据服务的需求。
LTE的引入和部署对移动网络的覆盖和性能产生了重大影响,因此进行LTE路测案例分析是非常重要的。
本文将以一次LTE路测案例为基础,对路测数据进行分析和解读,以评估LTE网络的覆盖范围、速率和性能。
本次LTE路测案例是在一些城市进行的,目的是评估LTE网络在城市中各个区域的覆盖情况和性能表现。
路测使用了专业的测试仪器和软件,收集了大量的数据,包括信号强度、信噪比、RSRP(Reference Signal Received Power)、RSRQ(Reference Signal Received Quality)等。
以下是对数据的分析和解读:首先,我们关注LTE网络的覆盖情况。
通过分析信号强度和RSRP数据,我们可以确定网络覆盖的强弱程度。
我们发现,在城市中心区域,信号强度较高,RSRP值在-60dBm到-80dBm之间;而在城市边缘区域,信号强度较低,RSRP值在-85dBm到-100dBm之间。
这表明LTE网络在城市中心区域的覆盖较好,在城市边缘区域的覆盖相对较弱。
其次,我们需要分析LTE网络的速率和性能。
通过分析信号质量和RSRQ数据,我们可以评估网络的速率和性能。
我们发现,在城市中心区域,信号质量较好,RSRQ值在-6dB到-9dB之间;而在城市边缘区域,信号质量较差,RSRQ值在-12dB到-15dB之间。
这表明LTE网络在城市中心区域的速率和性能较好,在城市边缘区域的速率和性能相对较差。
最后,我们可以基于路测数据,提出一些改进建议。
首先,对于城市中心区域的覆盖,可以进一步优化网络资源分配和功率控制,以提高覆盖范围、速率和性能。
其次,对于城市边缘区域的覆盖,可以考虑增加基站密度,以增强信号强度和质量,提高网络覆盖和速率。
LTE 路测案例分析报告
1覆盖类1.1概述覆盖类问题只要涉及弱覆盖、越区覆盖、过覆盖、无主导小区、上下行不平衡及导频污染等.在TD-LTE中一般认为RSRP<-110dBm,认为是弱覆盖.越区覆盖:由于基站天线挂高过高或下倾角过小引起的该小区覆盖距离过远,从而越区覆盖到其他站点覆盖的区域,并且在该区域终端接收到的信号电平较好.过覆盖:指网络中存在过度的覆盖重叠,容易引起干扰和乒乓切换;无主导小区:指某一片区域内服务小区和邻区的接收电平相差不大,不同小区之间的下行信号在小区重选门限附近的区域,并且无主导覆盖的区域接收电平一般或者较差,在这种情况下由于网络频率复用的原因,导致服务小区的SINR不稳定,可能发生空闲态主导小区频繁重选、连接态频繁切换,无主导覆盖也可认为是若覆盖的一种.导频污染:指在某一点存在过多<一般认为大于等于3个>的强导频,但却没有一个足够强的主导频;1.2弱覆盖1.2.1弱覆盖分析造成弱覆盖的原因有:1、规划的站点由于种种原因如物业等没有开起来;2、天线方位角、下倾角不合理,如下倾角过低;3、在站建起来后,由于新建楼宇的遮挡,导致部分区域RSRP很差;4、站点过高,如四十多米或更高,会造成塔下黑5、下倾角、方位角由于条件所限,无法调整,如:美化邓杆站点不方便调整天线的方位角<3个天线方位要一起转,因为外面有罩子盖住下倾角无法调整,如科技园四、海德三路等;深大校园里站点天线都是放在美化罩子<长方体的箱子>里面,对天线的下倾角和方位角调整范围也有影响<如:深大、深大南校等>>.针对以上原因建议的方案有:1、推动客户将规划站点尽快开起来;2、调整天线方位角、下倾角到合理位置;1.2.2天线方位角不合理导致弱覆盖现象:科技园三的102和104小区由于天线被住宅楼遮挡,导致覆盖区域内部分道路信号较弱,存在弱覆盖,科技园三站点周围的地物如图:图表 1科技园三周围地物调整前道路的电平值如下图:图表 2优化前科技园三覆盖措施:将104小区的方位角由20度调整为40度;将102的方位角由150度调整到100度;调整后弱覆盖得到改善,如下图:图表 3优化后科技园三覆盖1.2.3天线方位角下倾角不合理导致的弱覆盖现象:东都花园附近有小段路RSRP低于-110dBm,该路段属于东都花园和龙中站点主覆盖区,需要调整东都花园和龙中站的天馈方向角和下倾角加强覆盖.调整方案见下表,表格 1东都花园天馈调整方案调整后弱覆盖得到解决,调整前后的图见下:图表 4东都花园调整前覆盖调整后的图见下:图表 5东都花园优化后覆盖1.3越区覆盖1.3.1越区覆盖分析越区覆盖经常因为一些超过周围建筑物的站点,发射信号沿丘陵地形或道路可以传播很远,在其他基站的覆盖区域形成了主导覆盖,产生"岛"的现象,因此,当呼叫接入到远离某基站而仍由该基站服务的"岛"形区域上,并在小区切换参数设置时,"岛"周围的小区没有设置为该小区的邻区,当终端离开该"岛"时,就会立即发生掉话.且即便配置了邻区,由于"岛"的区域过小,也会容易造成切换不及时而掉话.解决建议:1、避免扇区天线的主瓣方向正对道路传播,可调整扇区的天线方位角,使天线主瓣方向与街道方向稍微形成斜角,利用建筑物的遮挡减少电波因街道两边的建筑反射而覆盖过远的情况.2、调整扇区天线的下倾角,如果条件允许优先调整电子下倾角,其次调整机械下倾角;3、降低天线高度4、在不影响小区与业务性能前提下,降低发射功率;1.3.2越区覆盖案例214小区的电子下倾6度,机械下倾5度,由于美化罩缘故,下倾角无法再往下压;但小区在1.26km还有信号且电平为-103dBm,在700多米时信号强度达到-93dBm,故在不影响覆盖的前提下需要适当降功率,将功率降低2dB后,信号消失,如下图图表 6科技北调整前越区覆盖图图表 7科技北调整后覆盖图表 8科技北覆盖路段基站分布注:该路段由于高新公寓站没开起来,有小段弱覆盖,当电平为-103时会切向214小区.2干扰类2.1PCI模3相等干扰科技园E,58小区上报了114的MR,181和服务小区58模3相等,下发了切换命令,UE没收到,由UE侧可看到此时SINR很差为-6.83;图表 9科技园58基站侧LOG图表 10科技园58信道状况图表 11科技园58终端侧LOG措施:将科技园四1小区的PCI由181调整为182,0小区的PCI由180调整为181,2小区的PCI182调整为180,干扰得到规避.注:在调整PCI时也要将配置该小区为外部邻区的基站的外部邻区中的PCI修改过来.2.2GPS失锁干扰现象:高科E站点小区1覆盖区域近点接入困难,拉网在此小区覆盖区域下必然掉话且长时间无法接入.在M2000信令跟踪下的干扰检测中跟踪高科E的1小区.发现每个RB的功率都比正常-110dBm高了30dB左右.RSSI同时也高了20dB左右,如下图:在故障小区覆盖区域,实测,信号强度大于-70dBm的时候才偶尔能接入.Probe和基站侧信令分析看到,eNodeB未发切换命令或者切换重配消息UE没收到,导致每次经过此处必然掉话.后发现M2000中,中兴通讯站点有GPS告警"GPS线路短路故障",在MML中将中兴通讯站点去激活,高科站点的干扰马上消失.由此确定是中兴站点GPS失步,导致周边区域同频干扰严重,更换中兴站点GPS后,故障消失.3切换类3.1基站不下发切换命令该问题的前提是UE上报了切换的MR,基站侧也收到了MR,但没有收到切换命令,可能的原因有邻区漏配或邻区配错、下发重配置没收到重配置完成和同频邻区中有PCI相等的邻区.下面以案例形势一一展开.3.1.1邻区漏配&邻区配错一、邻区漏配从基站跟踪看到基站收到了大量的MR,没有下发切换命令,导致掉话,如下图.从probe 上看信道质量不差没到解调门限以下,因为没有下发切换命令而掉话,可以查看是否为邻区漏配.中兴通讯179向科技园四182发起切换,上报了切换的MR,基站侧也收到了MR,没有下发切换命令,之后读系统消息,发起重建,重新接入到MR中小区,即科技园四182,可以确认为邻区漏配.Probe和基站侧log如下:图表 12邻区漏配UE侧无线环境图表 13邻区漏配UE侧LOG图表 14邻区漏配基站侧log邻区漏配有2种情况: 1、同频邻区和外部小区都没有配置;2、配置了外部邻区,但没配置同频邻区;建议:添加邻区注:也可通过对比SIB4中的邻区信息与MR中的邻区PCI发现是否为邻区漏配,如下图;图表 15SIB4消息内容二、邻区配错下面为外部小区和同频邻区均已配置,且同频邻区也配置正确,但外部小区的PCI添加有错,导致的掉话.如下图,102<科技园三1小区>上报181<科技园四的1小区>的MR,但没下发切换命令,查询同频邻区已配置eNBID为28即科技园四的1小区为邻区,但1小区的PCI被配成了182,且配置了同站的两个PCI相等的外部邻区.图表 16邻区错配终端侧LOG图表 17科技园三1小区的同频邻区图表 18科技园三的外部邻区建议:修正外部小区的PCI,在添加邻区时务必保证外部小区的PCI及同频邻区的eNBID正确,减少优化工作量.3.1.2PCI相等导致不发切换命令现象:基站标识117,67<本地小区1>、68<本地小区0>为同站邻区,68往67切换正常,67往68切则切不过去,表现为上报了MR,不发切换命令,LOG如下:图表 19PCI相等终端侧LOG图表 20PCI相等基站侧LOG经查询67<本地小区标识为1>的外部邻区中有PCI为68和同站邻区的PCI相等,如下,在ANR关闭情况下,会不发切换命令;图表 2167小区的外部邻区图表 2267小区的同频邻区措施:首先核查是外部邻区中的PCI配置错误<即该站不存在,或基站存在但PCI配置有错>;核查都无误时需要调整PCI;建议:1、调整完PCI后或新加站后用M2000上的PCI冲突核查工具进行核查邻区中是否存在PCI相等情况.2、使用excel原型工具进行对比,该工具相对麻烦一点,需要将邻区信息倒出来.如下,在M2000的配置中选择LTE 自优化,在优化菜单中双击PCI优化任务,如下图:图表 23M2000 PCI自优化界面图表 24PCI冲突信息在PCI冲突信息中点击任何一条在旁边会显示与其冲突的邻区的具体信息,如下表:图表 25PCI冲突详细信息点击下面优化任务中的绿色按钮,会弹出如下对话框,图表 26优化任务启动界面点击确认后,会显示如下进度条图表 27优化进度条看见完成后会显示已成功,进度条显示100%,建议的优化值会显示如下:图表 28优化结果3.1.3基站下发的RRC连接重配置没收到RRC连接重配置完成科技园三102切向科技园三104后,基站侧下发了RRC连接重配置,为重配置CQI,UE侧没收到,一直山上报MR,基站侧不处理,掉话;UE侧LOG如下:图表 29OMT侧LOG基站侧LOG如下:图表 30基站侧LOG在切换到104后,104小区的信道质量很差,导致没有解出RRC连接重配置而不下切换命令继而掉话,如下:图表 31Probe侧信道状况措施:测量到邻区中182与服务小区104模3相等,由于此路段为弱覆盖路段,建议调整182的PCI,将182调整为180,180调整为181,181调整为182,但由于高新公寓站开不起来,弱覆盖无法解决.3.2乒乓切换在高科E内114和115间乒乓切换,如下图,将时间迟滞由320ms调整480ms,调整后有所缓解,如下:图表 32调整前114和115乒乓情况图表 33优化后114和115切换情况注:根据实际情况也可调整IntraFreqHoA3Hyst和IntraFreqHoA3Offset,但该参数会影响到所有和该小区进行切换的邻区.4重建类协议规定的重建原因有3类:切换失败、重配置失败和其他,重建成功的前提是小区必须有ue的上下文.下面依案例进行分析.4.1重配置失败引起的重建现象:服务小区为102,102切换到180后,基站下发了RRC连接重配置,但在发送重配置完成时,无线链路失败,从无线环境来看,此时服务小区的180的信号为-106左右,随后信号消失,且邻区中也测不到180信号,之后开始搜小区,搜完小区就报RRC连接重建了,重建原因为重配置失败,重建不成功导致掉话,该点为弱覆盖点,各小区在该点的信号都在-110左右且持续时间较短.图表 34Histudio侧信令无线环境如下:图表 35HiStudio侧无线环境措施:可以调整天线的下倾角和方位角,使其有一个主导小区覆盖,但该段由于高新公寓站没有开起来,属于弱覆盖,214为距离1km左右的信号,182为旁瓣覆盖,除了加站,此处无法优化.改掉话点的位置如下<102小区距离该掉话点610米左右,182距离约780米左右>:。
精品案例_LTE切换优化专题总结
LTE切换优化专题总结目录1.背景介绍 (3)2.LTE切换概念 (3)2.1 LTE切换分类 (4)2.2 LTE切换目的 (4)2.3 LTE切换测量 (5)3.LTE切换优化思路及出现场景 (6)3.1 全网切换策略制定 (7)3.2 定期核查 (7)3.3 算法优化 (8)3.4 上行信道质量差导致切换失败 (9)3.5 同PCI干扰导致切换失败 (9)3.6 模3干扰导致切换失败 (9)3.7 外部干扰导致切换失败 (9)3.8 UE接入失败导致切换失败 (10)3.9 UE下行质量差导致测量报告丢失 (10)3.10 切换执行命令丢失导致切换失败 (11)3.11 未收到RRC重配置完成消息导致切换失败 (11)3.12 X2_IP配置错误导致切换失败 (11)3.13 X2切换准备时间过长导致切换失败 (11)4.总结 (12)LTE切换优化专题总结1. 背景介绍无线网络最大特点在于移动性控制,是进行其他优化的前提,是无线网络的重中之重。
移动性控制对于终端在不同小区间的移动,网络侧需要实时监测UE信号变化并控制在适当时刻命令UE做跨小区的切换,以保持其业务连续性。
在切换的过程中,终端与网络侧相互配合完成切换信令交互,尽快恢复业务,在LTE系统中,此切换过程是硬切换,业务在切换过程中是中断的,为了不影响用户业务,切换过程需要保证切换成功率、切换中断时延、切换吞吐率三个重要指标,其中最重要的是切换成功率,如果切换出现失败,将严重影响用户感知,切换中断时延和切换吞吐率也会不同程度地影响用户感知。
本文主要全场景方案、受控ANR精准识别、多种算法的优化快速闭环问题,从而提升网络质量,改善用户感知,打造电信LTE品牌网络。
2. LTE切换概念移动性管理是蜂窝移动通信系统必备的机制,当用户从一个小区移动至另一个小区时,与其连接的小区将发生变化,执行切换操作。
切换能够辅助LTE系统实现负载均衡、提高用户体验以及系统整体性能。
LTE经典案例分析
优化案例9.1、PUSCH BLER高案例问题现状:最近在上南路高青路做业务测试时发现PUSCH BLER较高,分别对Cell175进行了多次不同状态下的测试,分别为由其他小区切换至Cell175、处于定点状态下占用Cell175、处于移动状态下稳定占用Cell175进行测试,在这三种状态下,Cell175的PUSCH BLEW均很高,同时,在占用Cell175的时候,UE会多次出现重建的情况。
上南路高青路问题路段调整前测试情况:在切换占用上Cell175以后测试情况截图在定点状态下处于移动状态稳定占用Cell175调整措施:对Cell175进行了Lock&Unlock操作。
调整后复测情况说明:在对Cell175进行了相应的调整以后,在原问题路段及进行复测,复测过程中发现:原先切换至Cell175(Cell177切换至Cell175以及Cell174切换至Cell175)均会出现PUSCH BLEW偏高的问题已经得到了解决。
调整后,在切换占用上Cell175的时候,PUSCH BLEW值维持在10以下,原先在Cell175的过程中会频繁重建的问题也得到了解决。
调整后复测情况如下图所示:后续问题:已经抓取了UE侧和eNB侧的相关Trace,准备进一步分析定位问题。
9.2、天馈调整案例问题现状:在上南路永泰路路段附近进行业务测试时,UE在Cell183和Cell181之间切换的过程中会出现SNR突降,同时检测到许多奇怪的Cell ID的情况,导致切换失败事件频发。
怀疑是Cell181和Cell183小区之间的干扰所导致的,准备对Site61的天馈进行了相应的排查和调整。
Site61基站查勘情况1、Site61 Cell183 方位角由325度调整为355度,下倾角由0度调整为6度;Cell183方位角调整情况说明:如上图所示:由于Site61——PD125的实际位置与规划位置存在偏差,故对Cell183的天线方位角由325度调整为355度;同时,Cell183的电子下倾角由于工程的原因未进行下压,故今天将其由0度调整为6度。
移动LTEVOLTE案例分析汇总
移动L T E V O L T E案例分析汇总Pleasure Group Office【T985AB-B866SYT-B182C-BS682T-STT18】广东移动4GTD-LTE详细案例分析案例1:580 Precondition Failure导致的未接通。
【问题描述】在集团测试LOG中,存在Precondition Failure导致的失败事件,表现为呼叫过程中,终端主动上发或收到网络侧下发的580 Precondition Failure消息,随后呼叫中止,出现未接通事件。
Log文件名:MO UE:MT UE:时间:10:16:【问题分析】1、呼叫过程中,被叫发送Ringing 180后,收到网络下发的专载去激活命令,QCI 1被释放,被叫随后上报580 Precondition Failure,主叫同样收到网络侧转发的580消息,呼叫接续中止,导致未接通。
2、从信令中可以看到,被叫回复Ringing 180且主叫也已经收到Ringing 180,被叫随后收到网络侧下发的RRC重配,携带有QCI 1被释放的信息,被叫去激活专有承载。
由于专载已被释放,业务资源已不存在,所以被叫上发580 Precondition Failure失败消息。
主叫收到网络侧下发的580,接续被中止,导致了会话未接通。
3、从MME下发到Node B的E-RAB RELEASE COMMAND,原因上看是Nas层nomal_release,导致专载QCI 1被释放。
4、专载QCI 1被释放,去激活后,被叫发送INVITE 580,主叫收到网络侧转发的INVITE 580,会话流程中断,导致未接通【问题定位】在正常的会话流程中,由于MME下发E-RAB RELEASE COMMAND,使得QCI 1被释放,导致未接通。
【解决措施】需要核心网查看MME在什么情况下会下发E-RAB RELEASE COMMAND。
【测试验证】案例2:Server Internal Error 500导致的未接通【问题描述】在集团测试LOG中,存在Server Internal Error 导致的失败事件,表现为呼叫过程中,终端主动收到网络侧下发的Server Internal Error 500消息,随后呼叫中止,出现未接通事件。
LTE网络优化经典案例
LTE网络优化经典案例城市A运营商在LTE网络部署后,发现用户投诉率较高,网络质量不稳定。
经过一段时间的调查和分析,发现存在以下问题:1.弱覆盖区域:在城市一些地区,用户经常遇到信号弱或无信号的情况,导致通话中断或数据传输中断。
2.高拥塞区域:在城市中心商业区域,用户在高峰时段经常遇到网络拥塞问题,导致数据传输速率慢或无法连接上网。
3.外部干扰:在一些区域,存在大量的外部干扰源,如电视台、电台等,对LTE网络信号产生干扰。
针对以上问题,LTE网络优化团队制定了以下优化方案:1.新增基站:通过在弱覆盖区域增加基站,提高信号覆盖范围,解决信号弱或无信号的问题。
通过网络规划工具,确定基站的具体布局和参数设置,减少基站之间的干扰。
2.安装小区间干扰消除设备:在高拥塞区域安装小区间干扰消除设备,通过信号调度算法对小区之间的资源进行优化调配,减少小区之间的干扰,提高网络容量和覆盖率。
3.频谱管理与优化:通过频谱监测仪对外部干扰源进行监测和定位,对LTE网络频段进行调整和优化,减少外部干扰对网络信号的影响。
此外,LTE网络优化团队还进行了以下工作:1.反向传播方案:通过在城市中心地区建立反向传播系统,及时收集用户投诉和问题,以便优化团队及时跟进并解决问题。
2.数据分析和优化:通过网络性能监测系统,对网络数据进行实时监测和分析,了解网络负荷、覆盖范围等关键指标,及时调整网络参数和配置,提高网络性能和稳定性。
3.用户体验改善措施:针对用户投诉和需求,进行一些用户体验改善措施,如新增热门区域Wi-Fi覆盖、提供优质宽带服务等,提高用户满意度。
通过以上的优化方案和工作措施,该运营商在一段时间内逐步改善了LTE网络质量和用户体验。
用户投诉率显著降低,信号覆盖范围扩大,网络拥塞问题减少。
LTE网络优化团队也持续跟踪和监测网络性能,及时调整和改善网络参数,以保持网络的稳定性和良好的用户体验。
TD-LTE网络优化经验总结——优化案例集
Soc Classification level 14 © Nokia Siemens Networks
案例一:长河水产市场下载速度低 案例二:滨江电力公司上传速率低 案例三:海斯终端无法搜网 案例四:海斯终端ATTCH 失败 案例五:远见智能第1小区下载速率偏低问题 案例六:室分小区随机接入失败 案例七:基站有信号,Attach不成功 案例八:参数配置导致切换失败
Soc Classification level 17 © Nokia Siemens Networks
案例一:长河水产市场下载速度低 案例二:滨江电力公司上传速率低 案例三:海斯终端无法搜网 案例四:海斯终端ATTCH 失败 案例五:远见智能第1小区下载速率偏低问题 案例六:室分小区随机接入失败 案例七:基站有信号,Attach不成功 案例八:参数配置导致切换失败
问题解决: •1.在滨江电力1小区进行参数核查,确定无线参数均正常,尝 试修改相关上行参数进行调整,但上传速度依旧没有改善;
•2.恢复修改的参数,核查干扰源,检查周边邻区的无线参数配 置,经过核查发现滨江电力3小区的TDDframeconf=2,即时 隙配比为3:1,而周边基站均为2:2;
•3.将时隙配比改为2:2后,三个扇区上传速度均达到了 15Mbps以上,确认为3扇区的3:1配置对该站有强干扰导致 上行底噪上升,上传速度低;
【问题分析】 1. 怀疑定时器设置或者切换参数问题,但是核查参数发现336和337 的定时器设置相同,切换参数也相同,故排除定时器设置和切换 参数问题; 2. 怀疑无线环境问题,336小区和337小区做的是同层的2个小区,在 同层测试RSRP/RSRQ/SINR都比较好,排除无线环境问题; 3. 怀疑随机接入参数设置有问题,由于336向337切换都正常而反向 切换337向336会出现失败,因此对比这两个小区的PRACH参数, 发现prachConfigIndex参数不同。将336小区的 prachConfigIndex从51修改到3,多次测试切换成功率和接入成 功率明显提高。 4. 进一步定位发现海思终端在prachConfigIndex=51(preamble format 4)时随机接入的成功率较低。
LTE切换优化总结案例
XX市LTE切换优化总结报告目录一、LTE切换概述 (4)1.1 切换流程图 (4)1.2 切换分类介绍 (6)1.2.1 站内切换 (6)1.2.2 X2口切换 (6)1.2.3 S1口切换 (7)二、LTE切换日常优化 (8)2.1 LTE切换原理 (8)2.2 切换问题优化流程 (9)三、LTE切换自动优化(MRO) (10)3.1 MRO优化场景 (10)3.1.1 切换过早 (11)3.1.2 切换过晚 (12)3.1.3 乒乓切换 (13)3.1.4 切换到错误小区 (14)3.2 MRO优化模式 (15)3.3 MRO优化原理及动作 (15)3.4 网络影响 (16)3.4.1 系统容量影响 (16)3.4.2 网络性能影响 (17)3.5 MRO优化部署建议 (17)3.5.1 部署要求 (17)3.5.2 数据准备 (17)3.5.3 特性激活 (18)3.5.4 开通观测 (19)四、MRO优化试点 (20)4.1 试点区域 (20)4.2 同频MRO优化 (20)4.2.1 试点分析 (20)4.2.2 优化效果 (22)4.3异频MRO优化 (24)4.3.1 试点分析 (24)4.3.2 优化效果 (26)五、日常切换差处理案例 (27)5.1 切换准备失败类优化案例 (27)5.2 模三干扰严重优化案例 (27)5.3 参数配置错误导致切换差优化案例 (28)5.4 T/F切换参数调整提升切换成功率案例 (29)六、总结 (30)一、LTE切换概述1.1 切换流程图切换流程图Measurement Control:测量控制,一般在初始接入或上一次切换命令中的重配消息里携带Measurement Report:测量报告,终端根据当前小区的测量控制信息,将符合切换门限的小区进行上报HO Request:源小区在收到测量报告后向目标小区申请资源及配置信息(站内切换的话为站内交互,站间切换会使用X2口或者S1口,优先使用X2口)HO Request Ack:目标小区将终端的接纳信息以及其它配置信息反馈给源小区RRC Connection Reconfiguration:将目标小区的接纳信息及配置信息发给终端,告知终端目标小区已准备好终端接入,重配消息里包含目标小区的测量控制SN Status Transfer:源小区将终端业务的缓存数据移至目标小区Random Access Preamble:终端收到第5步重配消息(切换命令)后使用重配消息里的接入信息进行接入Random Access Response:目标小区接入响应,收到此命令后可认为接入完成了,然后终端在RRC层上发重配完成消息(第9步)RRC Connect Reconfiguration complete(HO Confirm):上报重配完成消息,切换完成Release Resource:当终端成功接入后,目标小区通知源小区删除终端的上下文信息1.2 切换分类介绍按照我们实际情况,切换可分为eNb站内切换,X2口切换以及S1口切换,下边分别进行介绍(下边介绍的所有切换都是基于已经接入且获取到了测量配置后)。
LTE网络优化经典案例-重要
LTE网络优化经典案例-重要1 LTE优化案例分析1.1 覆盖优化案例1.1.1 弱覆盖问题描述:测试车辆延长安街由东向西行驶,终端发起业务占用京西大厦1小区(PCI =132)进行业务,测试车辆继续向东行驶,行驶至柳林路口RSRP值降至-90dBm以下,出现弱覆盖区域。
问题分析:观察该路段RSRP值分布发现,柳林路口路段RSRP值分布较差,均值在-90dBm 以下,主要由京西大厦1小区(PCI =132)覆盖。
观察京西大厦距离该路段约200米,理论上可以对柳林路口进行有效覆盖。
通过实地观察京西大厦站点天馈系统发现,京西大厦1小区天线方位角为120度,主要覆盖调整结果:西城三里河一区站下仅有该站内小区信号,并且SINR提升到15以上,无线环境有明显提升。
1.1.2 重叠覆盖问题描述:测试车辆延长安街由西向东行驶,终端占用中华人民共和国科技部2小区(PC=211)进行业务,随后切换至海淀京西大厦1(PC=133)小区,业务正常保持。
车辆继续向东行驶,终端又回切至中华人民共和国科技部2小区(PC=211)发生掉话。
问题分析:观察该路段切换过程,终端由中华人民共和国科技部2小区(PC=211)正常切换至海淀京西大厦2小区后又出现回切情况导致掉话。
两小区RSRP值相近,相差3dBm 以内,造成该路段为无主覆盖路段,发生频繁切换最终导致掉话。
调整建议:针对该路段无主覆盖问题,建议调整京西大厦2小区功率由原15降低为5,使其不会对长安街路段实行有效覆盖。
调整结果:调整后,SINR值有明显改善,保持在20左右,多次测试该路段不会出现频繁切换情况,避免掉话等异常事件发生。
1.2 切换优化案例1.2.1 邻区漏配问题描述:测试车辆延长安街由东向西行驶,终端占用中华人民共和国科技部2(PCI=211)小区进行业务,车辆继续向西行驶,终端开始频繁上发测量报告,并没有网络侧下发的切换命令,导致UE掉话,终端掉话后重选至新兴宾馆1小区(PCI=201)。
精品案例_LTE网络负载均衡技术分析及参数优化案例总结
LTE网络负载均衡技术总结及参数优化案例总结目录LTE网络负载均衡技术分析及参数优化案例总结 (3)一、问题描述 (3)1.1双载波负载均衡原理 (3)1.2负载均衡的触发和停止 (5)1.3目标小区选择优化 (5)1.4负载均衡执行优化 (6)1.5现网负载均衡策略 (6)二、分析过程 (8)三、解决措施 (8)3.1宏站双载波不均衡优化 (8)3.2室分同覆盖不均衡优化 (11)四、经验总结 (15)LTE网络负载均衡技术分析及参数优化案例总结【摘要】目前热点区域LTE基站的双载波采用负载均衡的方式,保证用户平均分布,达到负荷分担的目的。
文章从双载波负载均衡原理、负载均衡的触发和停止、负载均衡参数优化、负载均衡实例效果评估四个方面对负载均衡技术进行阐述和探讨。
【关键字】高负荷负载均衡参数优化【业务类别】基础维护、参数优化一、问题描述随着4G业务的快速发展,部分L基站己完成了二载波甚至三载波的小区扩容,以满足大量用户的接入。
部分小区的用户数或PRB利用率已接近容量极限,而二载波和三载波小区的资源使用率却很低。
因此,如何均衡小区间、载波间的负载,提高系统资源利用率就显得尤为重要。
1.1双载波负载均衡原理移动性负载均衡(Mobility Load Balancing,简称为负载均衡MLB)是指eNodeB判断小区的负载状态,当小区处于高负载状态时,将部分UE转移到低负载小区,均衡异频之间的负载。
LTE负载均衡分为三个阶段:触发负载均衡、均衡用户选择、负载均衡执行,这三个阶段循环进行。
在触发负载均衡阶段,系统判断本小区的负载高低并与负载均衡启动门限进行比较,判断本小区是否进入高负载状态并启动负载均衡机制,之后本小区与目标小区进行小区间负载信息交互,以确定负荷均衡实施是否开始;在均衡用户选择阶段,系统按照一定门限选择合适做负荷均衡的用户,进行异频测量;在负载均衡切换执行阶段,系统根据异频测量结果向选定的用户下发选择合适的目标邻区,指示用户从负载较高的小区转移到负载较低的小区。
中国移动LTEVOLTE案例分析汇总
广东移动4GTD-LTE详细案例分析案例1:580 Precondition Failure导致的未接通;问题描述在集团测试LOG中,存在Precondition Failure导致的失败事件,表现为呼叫过程中,终端主动上发或收到网络侧下发的580 Precondition Failure消息,随后呼叫中止,出现未接通事件;Log文件名:MO UE:MT UE:时间:10:16:1、呼叫过程中,被叫发送Ringing 180后,收到网络下发的专载去激活命令,QCI 1被释放,被叫随后上报580 Precondition Failure,主叫同样收到网络侧转发的580消息,呼叫接续中止,导致未接通;2、从信令中可以看到,被叫回复Ringing 180且主叫也已经收到Ringing 180,被叫随后收到网络侧下发的RRC重配,携带有QCI 1被释放的信息,被叫去激活专有承载;由于专载已被释放,业务资源已不存在,所以被叫上发580 Precondition Failure 失败消息;主叫收到网络侧下发的580,接续被中止,导致了会话未接通;3、从MME下发到Node B的E-RAB RELEASE COMMAND,原因上看是Nas层nomal_release,导致专载QCI 1被释放;4、专载QCI 1被释放,去激活后,被叫发送INVITE 580,主叫收到网络侧转发的INVITE580,会话流程中断,导致未接通在正常的会话流程中,由于MME下发E-RAB RELEASE COMMAND,使得QCI 1被释放,导致未接通;解决措施需要核心网查看MME在什么情况下会下发E-RAB RELEASE COMMAND;测试验证案例2:Server Internal Error 500导致的未接通问题描述在集团测试LOG中,存在Server Internal Error 导致的失败事件,表现为呼叫过程中,终端主动收到网络侧下发的Server Internal Error 500消息,随后呼叫中止,出现未接通事件;Log文件名:MO UE:MT UE:时间:10:19:问题分析1、主叫发出UPDATE后,被叫收到UPDATE并回复UPDATE 200,随后被叫发送Ringing 180,主叫同时收到UPDATE 200和Ringing 180;按照正常的信令流程应该是先收到UPDATE 200,再收到Ringing 180;2、然后主叫收到网络侧下发的 INVITE Server Internal Error 500.主叫专载被释放,去激活,导致会话未接通;问题定位主叫收到网络侧下发的INVITE 500,然后网络侧又下发RRC重配,释放掉QCI 1,然后去激活,会话流程终止,导致未接通解决措施需要核心网确认,为什么会下发INVITE 500,什么情况下会导致网络侧下发INVITE 500,随后的专载释放是否由INVITE 500导致的测试验证案例3:软件对失败事件的误判导致统计错误问题描述在集团测试LOG中,存在软件的误判而错误统计的失败事件;如在某个特定时间点上,信令显示主被叫正常通话,软件却统计出掉话或未接通事件;Log文件名:MO UE:MT UE:时间:09:44:问题分析1、主叫从09:42:41主叫开始呼叫到09:45:47挂机成功,在通话过程中信令流程正常,中间出现一次RRC重建被拒,导致RRC释放,事件表现为掉话,软件统计为掉话;2、在09:44:主叫收到网络侧下发的RRC重建被拒,主叫随后发起RRC建立请求,在09:44:15:004,然后因为TAU,在09:44:15:128 RRC Connection Release了,软件统计为掉话;随后主叫又发起RRC连接,且在09:44:重建完成,从RRC重建被拒到RRC连接成功不到1s,且默认承载和专有承载均保持,未被释放,证明会话保持正常;3、到最后结束通话正常挂机都没有出现失败事件问题定位主叫接通后,在没有收到通话结束的情况下,中间出现RRC Connection Release,软件判断为掉线,此次是在会话建立后出现,软件统计为掉话解决措施需要鼎利修改判断事件失败的机制测试验证案例4:软件对失败事件的重复统计问题描述软件对于失败事件存在重复统计的问题,在集团测试问题统计表中,多次出现同一次失败事件,软件却作了多次统计,导致失败事件的增多;Log文件名:MO UE:MT UE:时间:10:04:问题分析1、主叫在10:04:发出INVITE会话请求,被叫在10:04:收到网络侧下发的BYE Request,软件统计为掉话;查看BYE Request中的CALL-ID,发现是上次会话的BYE Request2、被叫在10:04:08:230收到网络侧下发的INVITE Request同时发送Trying 100,又在10:04:收到网络侧下发的INVITE Request同时发送Trying 100,并在同时发送INVITE 486,软件统计为未接通;3、主叫在收到网络侧下发的UPDATE 200后,在10:04:上报Cancel,主叫的整个会话流程到这里被终止,事件上表现为未接通;且承载都存在问题定位通话期间,被叫收到网络下发的BYE Request会被软件统计为掉话;被叫连续两次收到网络下发的INVITE Request,回复INVITE 486 Busy Here,由于第一次INVITE Request未释放,故第二次INVITE Request网络侧才会下发INVITE 486,流程停止,软件统计为未接通;此时主叫在进行正常的会话接续,信令流程正常,事件中未出现失败事件;直到主叫上报Cancel,主叫会话流程停止,事件表现为未接通,之前的两次失败事件统计是重复统计;解决措施需要鼎利确认对失败事件的统计机制;测试验证案例5:LTE到2G eSRVCC切换失败导致的掉话问题描述呼叫会话建立后,由于到达异系统B2门限,终端上报B2事件,网络下发eSRVCC切换配置命令,但在2G侧切入失败,导致掉话;Log文件名:MO UE:MT UE:时间:11:16:42:311问题分析1、被叫上报B2事件,满足切换门限系统下发mobility切换命令,此时4G的流程已完成,接下来切入2G网络,2G网络下发TMSI Reallocation Command,被叫回复TMSI Reallocation Complete,此后流程中断,eSRVCC切换失败;3、信令上看,4G流程正常走完且建立会话,被叫切换到2G,但是网络下发TMSIReallocation Command导致流程终止,eSRVCC切换失败,会话流程结束,怀疑是2G问题;问题定位4G流程正常且已正常建立会话,由于2G网络侧下发TMSI Reallocation Command导致eSRVCC 切换失败,会话流程结束,导致掉话,怀疑是2G的问题;解决措施下周准备复侧,准备定位;测试验证案例6:TAU过程中RRC Connection Release 导致的未接通问题描述在越秀区网格10的测试LOG中,出现如下的未接通事件:主叫起呼发出Invite消息后,在收到网络效应Trying 100之前,先收到了网络下发的RRC Connection Release消息,RRC连接释放后,接续被终止,出现了Blocked Call事件;问题分析1、通过信令详细分析主叫起呼的过程,可以发现,起呼前,主叫刚完成重选过程,从PCI216小区重选至PCI103小区,由于源小区与目标小区处在不同的TAC,主叫发起了TAU请求:2、在主叫上发TAU请求后,未等网络回复ATU Accept,主叫已开始了起呼,上发Invite消息;然而Invite上发后,主叫同时收到了网络下发的ATU Accept和RRC Connection Release 消息因此时主叫处在非业务态,ATU更新会伴随RRC连接的释放,主叫被叫释放,从而导致了Blocked Call事件的发生:3、进一步分析信令可以发现,主叫在该测试路段内连续在3个TAC9437、10315、10014间进行TAU更新,其中从11:42:53至11:43:04就发生了4次,可能在存在TAC规划不合理的问题;问题定位解决措施测试验证案例7:Alerting中eSRVCC失败导致未接通问题描述主叫起呼后,流程正常,达到eSRVCC切换门限后收到eSRVCC切换命令且几乎同时收到Ringing 180,主叫未摘机,由于切换失败导致未接通;Log文件名:MO UE:MT UE:时间:11:25:28:189问题分析1、主叫在11:25:起呼,到11:25:收到网络侧转发的Ringing 180,整个信令流程正常2、在主叫几乎收到网络侧转发的Ringing 180的同时,主叫达到eSRVCC切换门限,网络侧在11:25:下发eSRVCC切换命令,在切换过程中主叫处于振铃中,并未摘话,而切换失败,导致了未接通;问题定位主叫已经收到Ringing 180,处于振铃状态还未摘话,由于在Alerting中发生了eSRVCC 切换失败导致了未接通解决措施需要核心网方面帮忙定位测试验证案例8:CSFB失败导致未接通问题描述主叫起呼后,被叫CSFB失败,主叫直接Cancel导致未接通Log文件名:MO UE:MT UE:时间:15:42:53:063问题分析1、主叫于15:42:22发起invite,被叫未收到网络侧转发的INVITE Request,但是主叫能一直收到网络侧下发的INVITE 183 、PRACK、UPDATE消息,这些消息被叫并没有收到也没有回复;被叫在15:42:24收到网络侧下发的CSFB request,但CSFB到2G后从信令看没有呼叫相关的信令交互过程2、直到15:42:35 CSFB失败,由于收不到被叫的响应,主叫主动于15:42:53发起CANCLE;导致会话未接通;问题定位主叫发起会话后,被叫没有收到会话请求,直接CSFB,CSFB失败,主叫一直未收到被叫的响应,直接Cancel,导致会话未接通;解决措施需要核心网查看为什么被叫没有收到主叫的会话请求,且主叫能收到网络侧下发的INVITE 180、UPDATE、PRACK消息;测试验证案例9:被叫Detach导致会话未接通问题描述主叫发起会话,被叫驻留在2G未返回4G,没有响应主叫的会话请求,主叫收不到被叫相应,直接Cancel导致未接通;Log文件名:MO UE:MT UE:时间:15:43:37:999问题分析1、主叫在15:43:起呼,此时被叫任然驻留在2G,由于上一次会话中CSFB失败,并没有返回4G;2、起呼后,被叫一直无响应,没有与主叫进行信令交互,然而主叫能一直收到网络侧下发的PRACK、UPDATE消息;3、主叫一直收不到被叫的回复,被叫在15:43:被叫上发Detach Request,主叫在15:43:上发Cancel,取消会话,导致未接通问题定位被叫停留在2G未返回4G,然后上发Detach Request,主叫收不到被叫的回复,直接Cancel,导致未接通解决措施需要核心网查看为什么主叫会话信令流程正常,被叫却无法收到主叫的会话请求;同时查看2G无线侧,为什么被叫会上发Detach Request;测试验证案例10:承载未建立导致未接通问题描述主叫收到100 Trying 后未建立承载,使得 RRC直接释放,导致未接通Log文件名:MO UE:MT UE:时间:15:46:36:271问题分析1、主叫在15:46:发起会话,收到网络侧下发的100 Trying后,专有承载一直未建立,10s后RRC释放,主叫在15:46:上发Cancel,导致会话未接通问题定位专有承载未建立,10s后RRC释放,导致未接通解决措施需要核心网查看为什么没有建立专有承载测试验证案例11:承载异常释放导致掉话问题描述被叫重建立成功后,专有承载突然被释放,导致掉话Log文件名:MO UE:MT UE:时间:10:35:41:981问题分析1、主叫在10:28:起呼,流程正常,收到网络侧转发的Ringing 180,UPDATE 200,主被叫会话正常建立;2、被叫在10:35:发送重建立,重建立成功,且流程正常,但是在10:35:承载被释放,导致掉话问题定位会话建立后,被叫重建立完成,但是专有承载被释放,导致掉话解决措施需要核心网确认承载释放的原因测试验证案例12:信令转发失败导致未接通问题描述主叫发起会话请求,网络侧未转发,被叫未收到,主叫Cancel,导致未接通Log文件名:MO UE:MT UE:时间:10:03:48:952问题分析主叫在10:03:发起会话,被叫未收到,直到10:03:主叫Cancel,会话接续无法继续,导致未接通;整个过程无线环境良好,网络侧未转发信令;问题定位网络侧未转发主叫会话请求,使得会话接续无法继续,主叫Cancel,导致未接通;解决措施需要核心网确认会话信令是否成功转发测试验证案例13:终端上报Cancel导致会话未接通问题描述会话流程正常接续,终端上报Cancel,导致会话未接通Log文件名:MO UE:MT UE:时间:14:53:06:510问题分析1、主叫在14:53:起呼,信令流程正常,且被叫上发Ringing 180,主叫收到网络侧转发的Ringing 180,主被叫都已经振铃;但是主叫突然在14:53:上发Cancel,被叫也收到网络侧转发的Cancel,会话接续停止,导致未接通;问题定位主被叫会话流程正常,无线环境良好,信令转发正常;主叫上报Cancel,导致会话未接通,定位为终端问题解决措施需要终端确认或者更换终端测试再查看结果测试验证。
LTE终端问题案例
L TE终端问题案例知识库目录前言 (3)1. 苹果系手机 (3)2. 三星系手机 (19)2.1 NOTE 3(三星N9008V) (19)2.2 NOTE 2(三星N7108D) (25)2.3 三星 I9308D (32)2.4 三星 S5(G9008v) (33)3. 其他厂家手机 (34)3.1 华为手机 (34)3.2 酷派手机 (40)3.3 中兴手机 (48)3.4 LG手机 (54)3.5 索尼手机 (55)3.6 HTC手机 (57)3.7 联想手机 (60)3.8 海信手机 (63)3.9 天语手机 (63)3.10 多款手机共性问题 (65)前言LTE网络商用至今,LTE在网用户数和在网终端数直线上升,随之产生的LTE终端问题以及终端和网络互操作的问题也呈几何态势增长,影响用户感知的问题主要集中在互操作与选网、语音业务问题、数据业务问题等,下面将常见热门机型的集团范围内发现的问题进行整理汇总,具体情况如下:1.苹果系手机问题1 使用数据业务时无法从3G返回4G且上网速率不稳定【问题现象】用户在使用数据业务时,有50%概率无法从3G返回4G 【涉及终端型号】Iphone5S/5C、三星NOTE 2【问题定位】Iphone 5S/5C、三星Note 2等部分高通芯片手机不支持“3G到4G基于测量的数据业务连接态重定向”(只支持盲重定向)。
造成手机从3G返回4G的成功率不高于50%,而且仅支持盲重定向的终端可能导致异系统间的乒乓切换,从而造成用户上网速率波动较大【问题解决进展】已给相关手机厂家去函,反馈后续通过软件版本升级解决【问题是否已解决】否,需要相应苹果以及三星等公司发布更新软件版本来解决。
【问题备注】重定向:在有数据业务进行时,用户所在网络发生变化所需要进行的一种网络行为(比如用户从无4G网络移动到有4G网络的环境)。
问题2 手机信号栅格标示频闪,无法登入4G网络【问题现象】终端网络制式(手机信号栅格显示部分)标示频繁闪烁,用户无法登入4G网络,无法做被叫及上网【涉及终端型号】Iphone5S/5C LG E985【涉及终端软件版本】IOS 7.1【问题定位】经验证该问题仅在华为无线设备下偶发出现【问题解决进展】已反馈给终端公司,苹果已提供7.1版本,该问题已解决,LG公司尚未更新软件版本【问题是否已解决】是,苹果终端已解决,更新为IOS7.1;LG需要更新软件版本问题3 手机欠费后耗电量增大【问题现象】Iphone 5s/5c欠费后,手机耗电量增大,待机时间明显缩短【涉及终端型号】Iphone5S/5C【涉及终端软件版本】IOS 7.1【问题定位】 IPhone5s/5c欠费后,手机耗电量增大,待机时间明显缩短。
LTE案例分析
一定要像爱护自己的眼睛一样爱护我们的网络
5
案例6:切换类
• 故障现象:邻区漏配 从基站跟踪看到基站收到了大量的MR,没有下发切换命令,导致掉话,如下图 。从probe上看信道质量不差没到解调门限以下,因为没有下发切换命令而掉话 ,可以查看是否为邻区漏配。 基站179向科技园四182发起切换,上报了切换的MR,基站侧也收到了MR, 没有下发切换命令,之后读系统消息,发起重建,重新接入到MR中小区,即科 技园四182,可以确认为邻区漏配。Probe和基站侧log如下:
• 解决方案:
• 让测试人员在页面修改为ctlte建立连接,这样,就和附着时的默认承载一致,单PDN 链接,终端重启后,可以接入LTE上网。定论为测试人员所在的基站(爱立信TDD基 站)不支持多PDN连接导致。
• 后期建议:
• 为了避免用户在网络连接时,输入的APN与终端底层送的、或用户签约的默认APN不 一致,附着成功后,发起第二个PDN连接时无线拒绝,导致无法上网。建议需要进一 步梳理无线基站的多PDN连接功能。
邻区漏配有2种情况: 1、同频邻区和外部小区都没有配置; 2、配置了外部邻区,但没配置同频邻区 ; 建议:添加邻区
一定要像爱护自己的眼睛一样爱护我们的网络
6
图表邻区漏配基站侧log
谢谢!
一定要像爱护自己的眼睛一样爱护我们的网络
7
优化建议:
增大A2事件切换门限,将A2门限设置高于终端在掉话前显示的RSRP值,这样终端在掉话前即可触 发激活态切换
一定要像爱护自己的眼睛一样爱护我们的网络
3
案例4:MOD3干扰类
• 故障现象
✓ 科技园E,58小区上报了114的MR,181和服务小区58模3相等,下发了切换命令,UE没收到,由 UE侧可看到此时SINR很差为-6.83;
移动LTEVOLTE案例分析汇总
移动L T E V O L T E案例分析汇总Coca-cola standardization office【ZZ5AB-ZZSYT-ZZ2C-ZZ682T-ZZT18】广东移动4GTD-LTE详细案例分析案例1:580PreconditionFailure导致的未接通。
【问题描述】在集团测试LOG中,存在PreconditionFailure导致的失败事件,表现为呼叫过程中,终端主动上发或收到网络侧下发的580PreconditionFailure消息,随后呼叫中止,出现未接通事件。
Log文件名:MOUE:MTUE:时间:10:16:【问题分析】1、呼叫过程中,被叫发送Ringing180后,收到网络下发的专载去激活命令,QCI1被释放,被叫随后上报580PreconditionFailure,主叫同样收到网络侧转发的580消息,呼叫接续中止,导致未接通。
2、从信令中可以看到,被叫回复Ringing180且主叫也已经收到Ringing180,被叫随后收到网络侧下发的RRC重配,携带有QCI1被释放的信息,被叫去激活专有承载。
由于专载已被释放,业务资源已不存在,所以被叫上发580PreconditionFailure失败消息。
主叫收到网络侧下发的580,接续被中止,导致了会话未接通。
3、从MME下发到NodeB的E-RABRELEASECOMMAND,原因上看是Nas层nomal_release,导致专载QCI1被释放。
4、专载QCI1被释放,去激活后,被叫发送INVITE580,主叫收到网络侧转发的INVITE580,会话流程中断,导致未接通【问题定位】在正常的会话流程中,由于MME下发E-RABRELEASECOMMAND,使得QCI1被释放,导致未接通。
【解决措施】需要核心网查看MME在什么情况下会下发E-RABRELEASECOMMAND。
【测试验证】案例2:ServerInternalError500导致的未接通【问题描述】在集团测试LOG中,存在ServerInternalError导致的失败事件,表现为呼叫过程中,终端主动收到网络侧下发的ServerInternalError500消息,随后呼叫中止,出现未接通事件。
集团LTE案例库总结材料
集团LTE案例库总结1.LTE下载速率低原因及相关案例现阶段排查LTE下载速率低影响的主要因素包括:(1)无线环境(2)容量(3)无线参数配置(4)传输问题(5)传输相关参数配置(6)故障(7)传输相关参数配置1.1无线环境无线环境是影响下载速率低的一个重要原因。
现网中由于多系统的存在,会对空口传输质量造成影响。
无线系统按照干扰产生的起因可以将干扰分为系统内干扰和系统间干扰。
系统内干扰:系统内干扰通常为同频干扰。
TD-LTE 系统中,系统内干扰常见原因有小区越区覆盖造成的同频干扰和GPS时钟不同步造成的下行信号对上行信号的干扰和模三干扰。
系统间干扰的产生:系统间干扰通常为异频干扰。
主要有:杂散干扰、阻塞干扰、谐波干扰、互调干扰。
通过LTE前期总结系统间干扰的干扰主要如下:排查这种类型干扰,一般是通过系统监控手段对小区干扰进行预判断,然后根据小区的干扰特性进行实地扫频排查。
通过闭站,看干扰是否消失排查。
1.1.1案例1:系统外干扰(DCS1800)导致LTE宏站单小区下载速率低1.现象描述LTE基站1小区在测试过程中,发现下载速率低(1M左右),终端 ping 核心网侧丢包率高达 50% 。
该基站配置为S111,频段是F 频段 1880-1900MHz,带宽20M,参考信号功率12dBm,上下行时隙配比1:3,特殊子帧时隙配置DwPTS:GP:UpPTS=3:9:22.问题分析使用底噪查询工具。
各小区底噪情况如下:将查询出的底噪值与各小区的业务速率对比,很容易看出业务速率低的小区恰好是后台查询底噪高的小区。
由此判断为底噪高是导致空口质量差,引起终端业务速率低、 ping 包丢包率高的原因。
将查询出的底噪值与各小区的业务速率对比,很容易看出业务速率低的小区恰好是后台查询底噪高的小区。
由此判断为底噪高是导致空口质量差,引起终端业务速率低、 ping 包丢包率高的原因。
闭塞周边所有 LTE 小区, 以及 2 、 3 小区全部闭塞,仅保留 1 小区,问题依然存在。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
集团LTE案例库总结1.LTE下载速率低原因及相关案例现阶段排查LTE下载速率低影响的主要因素包括:(1)无线环境(2)容量(3)无线参数配置(4)传输问题(5)传输相关参数配置(6)故障(7)传输相关参数配置1.1无线环境无线环境是影响下载速率低的一个重要原因。
现网中由于多系统的存在,会对空口传输质量造成影响。
无线系统按照干扰产生的起因可以将干扰分为系统内干扰和系统间干扰。
系统内干扰:系统内干扰通常为同频干扰。
TD-LTE 系统中,系统内干扰常见原因有小区越区覆盖造成的同频干扰和GPS时钟不同步造成的下行信号对上行信号的干扰和模三干扰。
系统间干扰的产生:系统间干扰通常为异频干扰。
主要有:杂散干扰、阻塞干扰、谐波干扰、互调干扰。
通过LTE前期总结系统间干扰的干扰主要如下:排查这种类型干扰,一般是通过系统监控手段对小区干扰进行预判断,然后根据小区的干扰特性进行实地扫频排查。
通过闭站,看干扰是否消失排查。
1.1.1案例1:系统外干扰(DCS1800)导致LTE宏站单小区下载速率低1.现象描述LTE基站1小区在测试过程中,发现下载速率低(1M左右),终端 ping 核心网侧丢包率高达 50% 。
该基站配置为S111,频段是F 频段 1880-1900MHz,带宽20M,参考信号功率12dBm,上下行时隙配比1:3,特殊子帧时隙配置DwPTS:GP:UpPTS=3:9:22.问题分析使用底噪查询工具。
各小区底噪情况如下:将查询出的底噪值与各小区的业务速率对比,很容易看出业务速率低的小区恰好是后台查询底噪高的小区。
由此判断为底噪高是导致空口质量差,引起终端业务速率低、 ping 包丢包率高的原因。
闭塞周边所有 LTE 小区, 以及 2 、 3 小区全部闭塞,仅保留 1 小区,问题依然存在。
对 1880-1900MHz 扫频,发现移动 DCS1800 频段天线对该频段有干扰。
由于该LTE基站与37854 昌平都市芳园DCS共址,基本确认干扰来自该基站。
接下来考虑为何2,3方向无明显干扰而1方向干扰明显,观察天线,发现2,3方向LTE天线与DCS天线水平隔离度1米左右,而1方向LTE与DCS天线水平隔离度仅0.4米左右。
3.问题分类:干扰-DCS1800干扰4.解决方案改变1方向LTE天线位置,将其与DCS天线水平隔离度增加到1米。
5.效果评估1小区天线与DCS天线水平隔离度增加到1米后,底噪-109,下载速率50M,故障排查完成。
6.注意事项及建议故障排查流程:1.1.2案例2:服务小区与邻小区PCI存在mod3 干扰造成下载速率过低1.现象描述对某区域LTE网络进行评估测试时发现,当测试终端占用A小区后下载速率过慢,下载速率只有10Mbps左右。
2.问题分析核查A小区PCI发现,该小区PCI与邻区B小区PCI mod3值相等,A小区PCI为15,B小区PCI为36,A、B小区之间存在mod3 干扰。
在LTE中,PCI用来区分每一个小区,类似于WCDMA中的扰码和CDMA2000中的PN。
LTE协议规定,PCI一共有504个,其组成分为两部分:Physical Layer Cell Identity = (3 × NID1) + NID2NID1: 物理层小区标识组,范围从0 到167共168组(决定了辅同步序列)NID2: 组内ID,范围从 0 到 2(决定了主同步序列)然而,PCI也不是504个可以随意分配,它必须避免同一个小区覆盖范围内PCI mod3不相等,其原因是因为不同的PCI决定了小区特定参考信号(CRS)的位置。
CRS用于终端辅助信道估计,其在子帧中的时频位置如下图所示:当小区使用单天线端口传输模式,RS参考信号的位置为PIC mod 6。
当手机天线端口数为2信道Rank=2时,小区使用2天线传输模式,RS参考信号的位置为PIC mod 3。
在小区使用2天线传输模式且2个小区PCI mod3 数值相等,参考信号的位置重叠就会造成相互干扰,SINR 值过低导致下载速率过慢。
3.问题分类:干扰-模3干扰4.解决方案修改A小区PCI为115.效果评估重新测试,A小区下载速率提升到55Mkbps以上。
6.注意事项及建议下行参考信号在天线上发送的位置取决于小区PCI值,如果是单天线发送下行参考信号的位置为PCI mod 6,如果是两天线发送下行参考信号的位置为PCI mod3。
如果PCI规划不当就会造成不同小区间参考信号干扰。
1.1.3案例3:由GPS失锁引起的F频段LTE基站上行干扰1.现象描述某基站通过话统查询上行底噪,发现此基站上行底噪很高,三个小区均在-77dB左右。
测试工程师到现场测试发现该小区无法正常接入,无法进行上下载业务。
2.问题分析经话统确认,此基站周围基站汇彩路、黄村大道、珠吉路底噪也较高,达到-100dBm以上.连片区域基站存在干扰问题原因可能为:GPS失锁或外部干扰。
协调代维人员进入基站机房,发现机房内存在两个BBU。
分别下挂东圃珠村和9860基站,均为TDD F频段基站,9860基站在工参表中未显示,此基站告警灯常闪,后台查询后,发现9860基站存在GPS失锁告警。
3.问题分类:干扰—GPS失锁4.解决方案闭塞9860基站,安排维护人员上站处理该基站的GPS失锁告警问题。
5.效果评估基站底噪下降到-110dBm以下,速率恢复正常。
6.注意事项及建议TDD-LTE上行干扰可能的问题原因:(1)、移动DCS1800M小区频段为:1805-1830M,1850-1872M;所以此频段很容易对TDD-LTE 频段1880-1900M形成阻塞干扰、互调干扰和杂散干扰。
(2)、GSM900M基站对TDD-LTE频段1880-1900M形成谐波干扰。
(3)、小灵通基站对TDD-LTE形成阻塞干扰、互调干扰和杂散干扰。
(4)、周围TDD-LTE基站 GPS失锁形成干扰。
(5)、RRU硬件或天馈系统问题造成干扰。
(6)、外部干扰源干扰。
1.2 容量容量也会影响下载速率,现网由于LTE用户不多,暂不需考虑这方面的问题。
1.3无线参数配置1.3.1案例4:爱立信小区上下行时隙配比错误导致上行高BLER速率低1.现象描述某日在进行簇优化过程中,进行上传业务时发现某站点的3个扇区的上传速率均明显偏低,仅能达到约2~5Mbps,而在前期该站点的单站验证测试中,该站的上传速度正常,三个小区均达到了16Mbps左右;2.问题分析在占用站点第1小区测试过程中,显示第1小区BLER较正常情况偏高,导致MCS较低;检查周边邻区的无线参数配置,经过核查发现该站点第3小区的TDDframeconf=2,即时隙配比为3:1,而周边基站均为2:2;3.问题分类:无线参数配置4.解决方案将第3小区参数TDDframeconf改为1,即时隙配比改2:25.效果评估经测试三个小区SINR在24左右,上传速度均达到了15Mbps以上。
6.注意事项及建议因LTE上行采用SC-FDMA,相对下行抗干扰能力较弱,在LTE建设过程中,需注意邻近小区上下行时隙配比准确一致,否则易对周边小区造成较强的上行干扰。
后期网管搭建完毕后,需定期对小区做参数核查,确保参数配置无误。
1.3.2案例5:LTE的功率PA、PB参数设置不合理导致下载速率低的处理1.现象描述LTE小区在覆盖较好路段(RSRP=-72dB,SINR=32 dB,且传输模式为TM3)下载速率低(基本小于40Mbps)2.问题分析查询该小区功率参数设置,发现PA参数设置为-3,PB参数设置为3,根据功率利用率分配表可知此时功率利用率仅为67%。
3. 问题分类:无线参数配置-功率参数4. 解决方案修改PB 参数为1,使其利用率达到100%。
5. 效果评估将PB 参数修改为1后,对该路段验证测试,该路段PHY DL Throughput 由35Mbps 提升至47Mbps ,达到指标要求。
6. 注意事项及建议LTE 下载速率低也需注意功率参数PA/PB 的设定,其要求Type A ,Type B 两类符号上的功率保持相等,当Atot P 和B tot P 相等且等于最大发射功率时,功率利用率最高。
LTE 参数设置需考虑业务场景,根据不同的需求对参数进行合理化配置,已到达感知最优。
1.3.3案例6:爱立信LTE 小区DLTARGETBLER 参数配置有误导致下行速率低1. 现象描述某站在进行簇优化过程中,进行FTP 下载业务时发现某小区的下载速率均明显偏低,仅能达到约20Mbps 左右,而在前期簇优化的拉网测试中,该站的下载速度正常,三个小区均达到了40Mbps 左右。
2. 问题分析在占用该小区测试过程中,观察发现下行调制方式中16QAM 占比较高;初步怀疑该小区下行速率低为调制方式没有全部采用64QAM 导致。
核查该小区CV 文件发现参DLTARGETBLER (下行目标BLER)配置为1%;当参数DLTARGETBLER(下行目标BLER) 设置为1%时,由于对BLER 要求过高,导致RBS 会调低MCS 以保证BLER 达到目标值。
而对于FTP 、流媒体等并不需要很高的BLER 要求的业务,过高的BLER 要求会导致下行因没有使用64QAM 的高阶调制方式,反而无法得到理想的下行速率,从而影响用户感知。
3. 问题分类:无线参数配置4.解决方案将该小区参数DLTARGETBLER设置为10%5.效果评估修改该参数后,复测FTP下载速率达到40Mbps左右,下行速率正常。
6.注意事项及建议下载速率低时可以查看MCS为64QAM的比例高不高,占用高阶调制比例低并且BLER 较低则可能是DLTARGETBLER设置的过小。
1.3.4案例7:华为eNodeB升级8.0版本默认开启MR功能后导致速率低1.现象描述华为ENodeB升级BTS3900 V100R008C00SPC130后在外场拨打时发现上传及下载速率慢,CAT4测试终端在好点的情况下进行定点CQT测试,下载最高速率仅在45Mbps左右,上传最高速率仅12Mbps左右。
2.问题分析通过后台跟踪UU口信令,发现终端在进行业务过程中会周期性上报Meas_Report。
在无线环境很好的情况下,不应发生异频/异系统测量。
但测试结果表明:终端在不停上报异频测量,并且是周期性上报。
对站点升级前后配置数据进行进一步核查,发现升级站点均默认开启了MR功能,在Nastar服务器上开启了同频/异频/异系统的订阅。
3.问题分类:无线参数配置4.解决方案后台关闭同频/异频/异系统的订阅。
5.效果评估后台关闭订阅后再次进行复测,测试结果恢复正常。
6.注意事项及建议升级版本后需注意核查前后配置数据找原因。