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度。
LTE端到端分析思路及案例分析
LTE端到端分析思路及案例分析LTE(Long Term Evolution)是第四代移动通信技术,具有高速率、低延迟、高能效和大容量等特点。
在进行LTE端到端分析时,可以按照以下思路展开分析,并结合案例进行具体分析。
思路一:网络架构分析首先,对LTE网络架构进行分析,包括核心网和无线接入网的组成和功能。
核心网包括Evolved Packet Core(EPC)和多媒体子系统(IMS),无线接入网包括eNodeB(eNB)和用户设备(UE)。
分析网络架构时,可以关注各个网络节点之间的接口、协议以及功能模块的组成,了解数据在网络中的流动路径和处理过程。
案例分析:可以选择一个LTE网络部署的实例,如地区的LTE网络。
通过查阅网络文档或通过网络工具获取网络架构图,分析网络中各个节点的功能和接口之间的关系。
思路二:无线接入过程分析其次,分析无线接入过程,包括eNB和UE之间的初始接入、随机接入、RRC连接过程等。
在初始接入过程中,UE需要与eNB进行物理层和随机接入过程,获取系统信息、分配RNTI等。
在随机接入过程中,UE发送随机接入信令来请求建立RRC连接。
RRC连接建立后,UE可以与eNB进行数据传输。
案例分析:选择一个UE在初始接入过程中的日志数据,通过分析日志数据中的消息序列和信令流程,了解UE与eNB之间的握手过程和数据传输过程。
思路三:移动性管理分析移动性管理是LTE网络中的重要功能,包括切换和重定向两个方面。
切换是指UE在移动过程中从一个eNB切换至另一个eNB,以保持用户的连接稳定。
重定向是指UE在移动过程中从一个小区切换至另一个小区,以改善信号质量。
移动性管理需要考虑UE的上下文切换、控制面和用户面的切换以及数据平面的持续传输等问题。
案例分析:选择一个UE在移动过程中的日志数据,分析日志中的切换消息和事件,了解UE在移动过程中发生的切换和重定向行为以及对网络性能的影响。
思路四:QoS管理分析QoS(Quality of Service)管理是为了保证不同业务的服务质量而采取的一系列策略和措施。
LTE端到端分析思路及案例分析
LTE端到端分析思路及案例分析LTE(Long Term Evolution)是第四代移动通信技术,广泛应用于现代的移动网络通信中。
LTE端到端分析是对LTE系统中从用户设备到目标服务器的数据传输进行全面、深入的分析和诊断。
下面将介绍LTE端到端分析的思路以及一个实际案例的分析。
一、LTE端到端分析思路:1.确定测试目标:确定需要分析的LTE网络中的哪一部分,比如用户设备、基站、核心网等。
2.收集数据:使用抓包工具,收集LTE系统中的网络流量数据,包括用户设备与基站之间的无线通信数据、基站与核心网之间的协议数据等。
3. 数据解析:对收集到的数据进行解析,将其转换为可读的数据格式,如Wireshark等流行的抓包工具可以对LTE协议进行解析。
4.数据分析:对解析后的数据进行分析,统计关键指标,如网络延迟、数据丢包率、带宽利用率等,以评估网络性能。
5.问题定位:根据分析结果,定位网络问题的具体位置,确定是用户设备、基站还是核心网的问题。
6.问题解决:根据问题定位结果,采取相应的措施解决网络问题,如调整用户设备的配置、优化基站的信号覆盖、调整核心网的负载等。
7.监控与优化:持续监控LTE网络的性能,不断优化网络配置,以提升用户的通信体验。
二、LTE端到端分析案例分析:假设一个LTE网络中存在用户设备连接问题,用户设备在连接到基站时出现频繁掉线的情况。
以下是一个LTE端到端分析案例的分析步骤:1.收集数据:使用抓包工具对用户设备与基站之间的无线通信数据进行抓包,收集通信过程中的数据包。
2. 数据解析:使用Wireshark对抓包数据进行解析,查看LTE协议中的消息内容,了解设备与基站之间的通信过程。
3.数据分析:通过统计解析后的数据包,计算用户设备连接成功率和掉线率等关键指标,以判断问题的严重程度。
4.问题定位:通过分析抓包数据中的消息内容,查看设备与基站之间的握手过程、认证过程等,确定问题出现在哪个环节。
中国移动集团LTE案例资料
集团LTE案例库总结目录1.LTE下载速率低原因及相关案例 (4)1.1无线环境 (4)1.1.1案例1:系统外干扰(DCS1800)导致LTE宏站单小区下载速率低 (5)1.1.2案例2:服务小区与邻小区PCI存在mod3 干扰造成下载速率过低 (7)1.1.3案例3:由GPS失锁引起的F频段LTE基站上行干扰 (9)1.2 容量 (9)1.3无线参数配置 (10)1.3.1案例4:爱立信小区上下行时隙配比错误导致上行高BLER速率低 (10)1.3.2案例5:LTE的功率PA、PB参数设置不合理导致下载速率低的处理 (10)1.3.3案例6:爱立信LTE小区DLTARGETBLER参数配置有误导致下行速率低111.3.4案例7:华为eNodeB升级8.0版本默认开启MR功能后导致速率低 (12)1.3.5案例8:由于PDCCH信道误码率较高导致下载速率波动 (13)1.3.6案例9:TA同步功能未打开导致LTE下载速率抖降问题案例 (13)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下载速率低 (16)1.5.3案例13:由交换机端口配置不正确导致LTE TDD下载速率波动问题 (16)1.6核心网参数 (17)1.6.1案例14:QCI设置错误导致演示厅LTE下行速率低问题 (17)1.7基站存在故障或告警 (18)1.7.1案例15:室分场景多RRU合并后某一RRU驻波导致速率低 (18)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传输模式配置不一致导致切换失败 (33)3.5.2案例9:大唐与诺西Local Cell Resource ID配置不一致导致切换失败的案例 (34)3.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.掉话问题 436.1.1案例1:TD-LTE SRS带宽重配置导致掉话率高案例 (43)1.LTE下载速率低原因及相关案例现阶段排查LTE下载速率低影响的主要因素包括:(1)无线环境(2)容量(3)无线参数配置(4)传输问题(5)传输相关参数配置(6)故障(7)传输相关参数配置1.1无线环境无线环境是影响下载速率低的一个重要原因。
LTE室分设计及案例分析
LTE室分设计及案例分析一、内容描述首先我们先来了解一下LTE室分设计是什么。
简单来说LTE室分设计就是针对室内环境的移动通信网络设计。
因为室内环境和室外环境有很大的不同,信号会受到建筑物、墙体、家具等各种因素的影响,所以需要有专门的设计来保证我们在室内也能享受到稳定的网络服务。
接下来我们会详细介绍LTE室分设计的过程。
从选址、布局到安装,每一步都很关键。
我们还会分享一些常见的案例分析,看看在实际应用中,如何解决问题,让网络覆盖更广泛、更稳定。
你可能会想,这些设计听起来好像很复杂。
但其实背后的原理并不复杂,我们会用通俗易懂的语言,让你轻松理解。
同时通过案例分析,你会看到设计师们是如何根据实际情况,一步步解决问题的。
1. 介绍LTE技术的背景和发展趋势大家现在上网是不是越来越离不开手机和网络了呢?那么有没有想过我们手中的手机是如何实现与世界的连接的呢?这就不得不提我们今天要介绍的LTE技术了。
LTE,也就是“长期演进技术”,它是现代移动通信的核心技术之一,让我们的手机与网络之间的连接更加快速和稳定。
LTE技术并非凭空出现,它是从过去的2G、3G技术逐步演变而来的。
随着人们对网络速度和数据量的需求越来越大,LTE技术应运而生,并迅速发展。
从最初的版本到如今的高级版本,LTE技术在不断地更新和升级,每一次升级都带来了更快的速度和更好的体验。
近年来我们可以看到LTE技术的发展趋势非常明显。
不仅仅是手机,越来越多的设备都开始支持LTE,包括平板电脑、智能手表等等。
而且随着物联网、云计算等新技术的发展,LTE技术的应用领域也在不断扩大。
可以说LTE技术正在改变我们的生活,让我们与世界的连接更加紧密。
那么为什么LTE技术这么重要呢?除了速度快、稳定性好之外,它还能帮助我们实现更多的功能,比如在线视频、高清语音等等。
而且随着技术的不断进步,LTE的未来发展潜力巨大,我们有理由相信,未来的LTE会给我们带来更多的惊喜和便利。
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案例总结
LTE案例集锦案例一:分布问题导致下行呑吐率不达标问题【故障类别】:分布系统【现象描述】:宽窄巷子星巴克咖啡室分基站开通后,我们用B593S终端进行现场测试发现在RSRP和SINR极好的情况下下行吞吐率无法达到测试标准,查看基站配置为双流模式基站,下行呑吐率标准为50M以上,现场测试最高速率只能达到47M,具体情况如下:下行呑吐率数据【原因分析】:1、通过测试数据分析发现该基站为双通道配置,两个通道口0和1在输出功率最大时相差32dBm,怀疑为双通道输出功率不一致导致下行速率无法达标,如下图所示:可以看到两个通道的输出功率相差较大【处理过程】:1、而后后台配合我们将两个通道分别单开,测试其下行速率,如图:通道口0从上图可以看出通道口0由于输出功率低导致RSRP<-100,下载速率平均只有36M;通道口1从上图可以看出通道口1输出功率正常,下载速率稳定在46M以上,以此确定该站的通道0输出功率问题导致下行呑吐率无法达标.【建议与总结】:该问题后经协商后由双通路改为单通路,并将通道0关闭处理,复测结果如下:下图可以看出改为单流后下行呑吐率达到测试要求,下载速率稳定在46M以上.案例二:基站热点区域异频优化案例【故障类别】:参数类【现象描述】:高升桥室分站点热点区域优化,在对覆盖进行步测中发现,6F主要为2小区覆盖但受到3小区干扰下载速率不稳定;4\5F主要为3小区覆盖但受到1小区干扰下载速率不稳定;为此,将3小区频点由39050调整为39250(同1小区、2小区异频),调整后发现在原有的1、3小区切换点位置无法正常进行切换。
高升桥基站覆盖分布图:5F同频切换点如图(中间电梯间仍然为1小区覆盖):【原因分析】:通过分析,3小区调整为异频频点后同1小区发生的为异频切换,切换类型应为基于A4的切换,然在邻区列表中都一直无法检测异频邻区(后台已做异频邻区切换参数数据配置),进一步确定可能原因出现在终端未上报异频邻区测量,并观察信令及事件窗口,无A2事件相关消息。
LTE网络优化经典案例
LTE网络优化经典案例城市A运营商在LTE网络部署后,发现用户投诉率较高,网络质量不稳定。
经过一段时间的调查和分析,发现存在以下问题:1.弱覆盖区域:在城市一些地区,用户经常遇到信号弱或无信号的情况,导致通话中断或数据传输中断。
2.高拥塞区域:在城市中心商业区域,用户在高峰时段经常遇到网络拥塞问题,导致数据传输速率慢或无法连接上网。
3.外部干扰:在一些区域,存在大量的外部干扰源,如电视台、电台等,对LTE网络信号产生干扰。
针对以上问题,LTE网络优化团队制定了以下优化方案:1.新增基站:通过在弱覆盖区域增加基站,提高信号覆盖范围,解决信号弱或无信号的问题。
通过网络规划工具,确定基站的具体布局和参数设置,减少基站之间的干扰。
2.安装小区间干扰消除设备:在高拥塞区域安装小区间干扰消除设备,通过信号调度算法对小区之间的资源进行优化调配,减少小区之间的干扰,提高网络容量和覆盖率。
3.频谱管理与优化:通过频谱监测仪对外部干扰源进行监测和定位,对LTE网络频段进行调整和优化,减少外部干扰对网络信号的影响。
此外,LTE网络优化团队还进行了以下工作:1.反向传播方案:通过在城市中心地区建立反向传播系统,及时收集用户投诉和问题,以便优化团队及时跟进并解决问题。
2.数据分析和优化:通过网络性能监测系统,对网络数据进行实时监测和分析,了解网络负荷、覆盖范围等关键指标,及时调整网络参数和配置,提高网络性能和稳定性。
3.用户体验改善措施:针对用户投诉和需求,进行一些用户体验改善措施,如新增热门区域Wi-Fi覆盖、提供优质宽带服务等,提高用户满意度。
通过以上的优化方案和工作措施,该运营商在一段时间内逐步改善了LTE网络质量和用户体验。
用户投诉率显著降低,信号覆盖范围扩大,网络拥塞问题减少。
LTE网络优化团队也持续跟踪和监测网络性能,及时调整和改善网络参数,以保持网络的稳定性和良好的用户体验。
TD-lte优化案例分析(测试类)2稿
目录1 TD-LTE优化案例分析 (3)1.1 覆盖优化案例 (3)1.1.1 弱覆盖 (3)案例1(无主服务小区) (3)案例2(无主覆盖) (4)案例3(有遮挡) (6)1.1.2 越区覆盖 (7)1.1.3 重叠覆盖 (8)案例1(无主覆盖,各小区RSRP值相近) (8)案例2(天线权值调整重叠覆盖) (9)1.2 切换优化案例 (11)1.2.1 邻区漏配 (11)案例1 (11)案例2 (12)1.2.2 乒乓切换 (16)案例1 (16)案例2 (18)1.2.3 切换不及时 (19)1.2.4 UE未启动同频测量 (21)1.2.5 切换失败在源侧发起重建立 (22)1.2.6 中兴爱立信边界不能切换问题处理 (24)1.2.7 PCI规划不合理导致无法切换 (28)1.2.8 邻区中频点配置过多导致未能测量目标小区 (29)1.2.9 由于归属核心网未割接导致切换问题掉线 (30)1.3 干扰优化 (31)1.3.1 PCI干扰 (31)案例1(调整PCI解决MOD3干扰) (31)案例2(调整RF解决MOD3干扰) (32)案例3(MOD3导致切换失败掉话) (33)案例4(MOD3冲突导致SINR差) (35)1.3.2 重叠覆盖干扰 (39)1.3.3子帧配比相互干扰 (40)1.3.5天线接反导致邻区漏配造成掉线 (44)1.4 参数优化 (45)1.4.1 DSR上报周期 (45)1.4.2 小区驻留困难 (47)1.4.3 同频小区重选失败 (47)案例1(与SIB3中参数有关) (47)案例2(删除同频小区黑名单列表) (48)1.4.4 重选参数设置不合理 (50)1.4.5 高重选优先级的室分信号泄漏 (52)1.4.6 切换后TAU导致掉话 (55)1.4.7 切换参数设置不合理导致掉线 (56)1.4.8 LTE下载速率低(DSR参数设置) (57)1.4.9 LTE参数设置不合理导致下载速率低的处理 (59)1.4.10 上行信道功率不足导致上行速率异常问题 (61)1.4.11 子帧配比问题 (63)1.5 接入类优化 (68)1.5.1 LTE接入失败问题分析 (68)1.5.2 基站不能接入问题处理案例 (70)1.5.3 某外场部分站点UE无法接入和小区无法建立问题分析 (76)1.5.4 UE触发重建被拒 (77)1.7有线类优化 (78)1.7.1 厂家PTN配置问题导致下载速率低 (78)1.7.2 eNodeB路由配置错误导致UE无法附着问题 (81)1.8 测试终端问题 (83)1.8.1 detach之后出现重建信令 (83)1.8.2 收到MIB后解不出SIB (85)1.7.3 SIM卡速率限制 (87)2 常见优化问题总结 (89)2.1 覆盖优化类 (89)2.1.1影响覆盖的主要因素有以下几个方面: (89)2.1.2覆盖问题可以归纳为以下几类: (89)2.1.3 对于以上5种覆盖问题的优化,遵循以下原则。
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,该路段属于东都花园和龙中站点主覆盖区,需要调整东都花园和龙中站的天馈方向角和下倾角加强覆盖。
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)。
中国移动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,导致会话未接通,定位为终端问题解决措施需要终端确认或者更换终端测试再查看结果测试验证。
LTERF优化簇优化网格优化经典案例分析
LTERF优化簇优化网格优化经典案例分析LTE(Long Term Evolution)是现代移动通信领域的一种无线通信技术,而RF优化(Radio Frequency Optimization)在LTE网络中扮演着至关重要的角色。
通过RF优化,可以提高网络的覆盖范围、容量和质量,从而提高用户的通信体验。
簇优化和网格优化是RF优化的两个重要方面,下面将分析LTE RF优化、簇优化和网格优化的经典案例。
一、LTERF优化案例分析1.问题描述:在地区的LTE网络中,用户投诉增加,主要原因是网络的覆盖范围不够广、信号强度低、丢包率高等。
解决方案:通过RF优化来解决这些问题。
首先,针对信号强度低的问题,可以调整天线的角度、高度等因素,以改善信号传播。
其次,通过增加基站数量和改善基站之间的传输链路,来拓展网络的覆盖范围。
最后,采用功率控制、干扰抑制和资源调度等技术手段,优化网络的质量和容量,减少丢包率。
2.问题描述:在一些高密度城市区域的LTE网络中,拥塞严重,用户无法正常上网和通话。
解决方案:通过RF优化来解决这个问题。
首先,可以对繁忙的基站进行扩容,增加其吞吐量和容量。
其次,可以利用频谱资源进行重分配,减少基站之间的干扰,提高网络的负载均衡。
另外,可以使用新的调度算法来优化资源分配,确保资源的有效利用。
二、LTE簇优化案例分析1.问题描述:在一些城市的LTE网络中,用户投诉集中在一些区域,且用户体验差,包括呼叫掉话、数据传输延迟等问题。
解决方案:通过簇优化来解决这个问题。
首先,可以对该区域的基站进行重新规划和优化,包括基站的选址、天线的安装以及参数的调整等。
其次,可以利用各种技术手段来降低干扰,包括功率控制、资源分配和干扰消除等。
最后,可以通过加强网络监控和维护,及时发现和解决问题,提高用户的体验。
2.问题描述:在一些乡村地区的LTE网络中,由于地理环境和用户分布的特点,用户体验较差,主要表现为信号弱、呼叫掉话等问题。
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、环城西路和县前路交叉口附近弱覆盖问题分析:测试车辆在县前街自西向东行驶到环城西路附近时,UE占用到0.28公里的永嘉上塘大会堂_3小区信号PCI 152 RSRP=-109dBm,SINR=2.0dB,下载速率在2296kb/s左右,RSRP 持续低于-105dBm,存在弱覆盖区域,该问题区域同时收到永嘉上塘大会堂_1(PCI 150)和永嘉上塘档案局_3(PCI 119),RSRP低于-105dBm,无主导频。
通过查看道路的PCI覆盖情况可以看出问题区域距离永嘉上塘大会堂_3最近且是该扇区主瓣覆盖方向且覆盖较差。
解决方案:【解决方案】:永嘉上塘大会堂_3电子下倾角由5度调整为2度。
【整改进度】:【复测】:复测正常【复测分析】测试车辆在县前街行驶到环城西路附近时,UE占用到永嘉永建路_2小区信号PCI 7 RSRP=-104dBm,RSRP持续高于-105dBm,弱覆盖区域明显减少。
2、环城西路码道西街交叉口附近弱覆盖问题分析:测试车辆在环城西路上自南向北方向行驶接近码道西路附近时,UE占用到0.44公里之外的永嘉上塘嘉盛街_1小区信号PCI 201 RSRP=-119dBm,SINR= -7dB,下载速率在7407kb/s左右,RSRP持续较差,存在弱覆盖区域,该问题区域同时收到永嘉上塘嘉盛街_3(PCI 203)和永嘉上塘大会堂_2(PCI 151) RSRP均在-105dBm左右,缺乏主导频覆盖,查看PCI覆盖情况可以看出问题区域主要是由永嘉上塘嘉盛街_1以及永嘉上塘大会堂_2(PCI 151)覆盖且部分路段覆盖较差。
解决方案:【解决方案】:建议新增站点(120.688918,28.150286)解决弱覆盖区域。
【整改进度】:永嘉上塘气象局站点已经建好【复测】:复测正常小结:弱覆盖日常调整方式为调整覆盖及新建资源为有效手段。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
簇优化一、簇优化流程1、簇优化准备工作:1)划分基站簇每簇包含15—30个站点根据地形地貌、区域环境特征等信息划分簇2)选择可优化的簇站点开通率大于80%。
3)配置站点邻区等参数4)获取相关文档及电子地图站点设计图纸、勘察及单站验证报告、站点工参信息、无线参数配置数据、电子地图;5)确认基站簇状态站点地理位置、站点是否开通、站点是否正常运行没有告警、工参及无线参数核查、站点目标覆盖区域;6)规划测试路线7)测试工具准备及检查测试终端、扫频仪、笔记本电脑、车载逆变器、测试车辆图10-47 测试工具检查1、RF优化1)覆盖问题:覆盖空洞、弱覆盖、无主覆盖、越区覆盖覆盖优化:方位角、下倾角、功率2)干扰问题:同频干扰、网外干扰排查干扰优化:PCI、干扰排查3)切换优化:邻区关系、切换参数、异频组网技术切换优化;邻区、切换序列、异频技术4)业务类优化:连接建立成功率、掉线率、切换成功率业务类优化:覆盖性能、干扰性能、邻区缺失、切换混乱、硬件告警排查RF优化各部分工作量占比:覆盖60%、干扰30%、其他10%3、簇优化指标验收指标验收撰写总结报告簇优化周期为20到30天左右。
对于有限基站下的覆盖需求,尽量进行覆盖调整,开启DL Rs Boost,实在处理不了才催开站、加站或者提基站改造。
参数调整:1、基站功率调整小区下行功率计算公式:RS EPRE = pMax – dlCellPwrRed – 20lg(4024/txPWRScaling) + dlRsBoost目前簇优化通过调整tx PowerScaling 与dlRsBoost实现小区功率降低或提升。
2、PCI调整LTE系统提供504个物理层小区(即PCI),和TD-SCDMA系统的128个扰码概念类似。
配置原则:1)相邻小区的PCI不能相同2)相邻小区的PCI避免MOD3(MOD6)相同3)相邻小区的PCI避免MOD(2*DL_PRBs_NUM)相同对于双天线端口模式,强干扰邻区一定要避免PCI 模3相同,一般规划时能够实现相邻小区PCI不相同,PCI模(2*DL_PRBs_NUM)不相同,但很难实现强干扰邻区PCI模3不相同。
目前LTE簇优化中PCI优化主要是进行PCI模3调整。
调整原则:同站内PCI对调,避免由于疏忽导致站内小区间PCI模3相同。
图10-48 MOD3修改2、邻区添加LNBTS右键添加New LNADJ,输入邻站IP和ENBID建立X2接口连接图10-49 添加X2接口eNB根据UE上报的MR自动添加邻区图10-50 自动添加邻区Handover allowed 可根据需求设置为allowed、forbidden、onlyS13、切换参数优化A3事件:Mn + Ofn + Ocn – Hys > Ms + Ofs + Ocs + OffA5事件:Ms + Hys < Thresh1; Mn + Ofn + Ocn – Hys > Thresh24、异频参数优化D/F频段交界区域的站点需添加异频切换参数异频切换参数除异频测量开启和关闭外,A3/A5等参数与同频切换完全相同由于异频测量带来25%的小区吞吐量损失,那么优化异频参数就至关重要协议考虑尽量减小终端复杂度,UE实现异频测量需要GAP,在GAP测量周期内,停止所有业务和服务小区的测量GAP模式分为40ms周期和80ms周期,GAP测量长度都为6ms,目前华为终端由于实现问题,GAP测量长度为10ms。
那么如果是40ms的GAP周期,容量损失大约是1/4。
簇优化指标验收市公司指标要求图10-51 市公司指标要求集团公司指标要求覆盖目标:RSRP> -100dBm且RS-SINR》-3dB的概率大于95%业务目标:连接建立成功率》95%;无线掉线率《4%切换成功率》95%二、现阶段LTE簇优化难点网络规划设计不合理、美化天线无法调整、天线安装位置不合理、信号绕射能力差、天线电气特性差。
1、网络规划设计不合理1)现网基站分布VS 理想蜂窝布局有限的基站分布不合理,部分站点分布过密图10-52 基站分布过密部分站点存在明显遮挡图10-53 覆盖受遮挡2)整体布局VS 天线过高从控制覆盖角度出发,相邻基站天线挂高基本相同有利于覆盖控制,保证网络指标性能,伞状效应不利于同频组网干扰控制受限于自身楼面遮挡和天线电气特性,站点过高引起塔下黑现象。
2、美化天线无法调整同频组网干扰控制VS 美化天线下倾角调整空间有限根据簇优化经验,密集城区下倾角平均为8度,一般城区为3度图10-54 美化天线无法调整3、天线安装位置不合理1)天线安装位置位于大楼玻璃幕墙内,受窗框及玻璃影响,信号衰减较大;且天线倒立安装,影响天线辐射特性。
图10-55 天线安装位置不合理2)天线隔离度要求:水平隔离度> 2m垂直隔离度> 0.5m图10-56 覆盖受楼面阻挡天线安装位置不合理,导致信号覆盖方向受自身楼面阻挡。
4、信号绕射能力差D频段无线电波衰减快,绕射能力差,市区部分路段覆盖无法达到集团公司和福建省公司指标要求。
需建设大量路灯杆站点补充覆盖图10-57 信号绕射能力差5、天线电气特性差由于居民环保意识增强,市政美化需求等原因,市区大量采用加罩美化天线,相比于常规天线,加罩美化天线方向图发生畸变,前后比变差,导致小区间重叠覆盖区域变大,不利于干扰控制市区大量使用雷克微天线,此天线垂直半功率角大于17度,信号收敛特性差,不利于市区覆盖控制图10-58 天线电气特性差簇优化中发现,目前市区使用的京信1.4m大天线背向信号较强,不利于小区间干扰控制,尤其对小区覆盖边缘影响较大。
以距离基站150米处为例,非美化天线实测正向信号-70dBm左右。
根据京信天线说明书所示,该型号天线前后比大于33,那么背向信号应小于-103dBm,考虑到同站不同小区位置差异,理论背向信号强度应该更低。
但实测天线背向信号在150米处为-90—-95dBm,与预期严重不符实测数据:对晋安天宇电气旧厂-2小区进行背向拉远,距离与RSRP关系如下:150m为-90dBm300m为-95dBm500m为-97dBm1000m为-105dBm图10-59 天线前后向对比三、簇优化案例优化案例1:弱覆盖问题描述:玄南路弱覆盖问题分析:西园康山由于谈点问题暂未开通,导致玄南路部分路段弱覆盖,计划调整晋安福州艺术师范院校-2和晋安双安中学-3方位角、下倾角和功率参数改善RSRP,且弱覆盖路段位于小土坡上,信号衰落快,通过调整参数加快切换图10-60 弱覆盖调整方案:图10-61 弱覆盖调整后复测优化效果:玄南路RSRP覆盖有明显改善。
优化案例2:无主覆盖/SINR差问题描述:秀峰路高架桥下无主覆盖,RS-SINR较差。
图10-62 导频污染问题分析:由于桥面遮挡,秀峰高架桥下信号波动较大,且周围站点规划不合理,导致该区域无主覆盖,分析UE log发现,晋安中铁快运-2、晋安天宇电气旧厂-3、晋安福州七中-1在此路段信号强度相差不大,小区间干扰严重。
调整方案:该区域计划由晋安福州七中-1主覆盖,增强此小区功率并调整周围站点天线和功率,以达到控制干扰的目的。
优化结果:问题路段无主覆盖现象消失,RS-SINR有明显改善图10-63 导频污染调整后复测优化案例3:PCI模3冲突/SINR差问题描述:晋安福州艺术师范学校与晋安新罗汉北交界区域SINR差。
图10-64 模3干扰问题分析:晋安福州艺术师范学校-2(PCI=126)与晋安新罗汉山北-1(PCI=462)PCI 模3冲突。
调整方案:优化结果:SINR有明显改善。
优化案例4:切换掉话问题描述:山前路掉话问题分析:测试车辆进入山前路,UE由晋安金榜食府-1切换至晋安居住主题公园水塔-3后,持续上报MR。
切换目标小区为晋安新店溪里,基站无响应,SINR恶化掉话。
通过网管查看邻区关系发现,晋安居住主题公园水塔和晋安新店溪里两站由于距离较远,未添加邻区关系。
图10-65 切换掉话优化方案-1:山前路应由晋安金榜食府和晋安新店溪里主覆盖,晋安居住主题公园水塔为越区覆盖,调整此3站的方位角和下倾角控制覆盖。
优化效果-1:山前路RSRP有所改善,但晋安居住主题公园水塔-3仍会覆盖至山前路,掉话问题仍未解决。
现象分析:山前路游泳道路狭窄且两侧民房较密,晋安金榜食府天线挂高低,无法有效覆盖山前路。
晋安居住主题公园水塔建于山顶,3扇区由于美化罩空间限制,无法按预期调整下倾角。
优化方案-2:晋安居住主题公园水塔与晋安新店溪里添加双向邻区。
优化效果-2:晋安居住主题公园水塔-3可切换至晋安新店溪里-2,但由于晋安居住主题公园水塔-3信号不稳定,快衰落导致切换不及时,有掉话隐患。
图10-66 调整覆盖后复测优化方案-3:将晋安金榜-1向晋安居住主题公园水塔-3切换关系设置为禁止,删除晋安居住主题公园水塔与晋安新店溪里双向邻区。
优化效果-3:山前路切换正常,掉线现象消失。
图10-67 增加邻区关系后复测优化方案分析:晋安金榜食府-1与晋安居住主题公园水塔-3切换点处,晋安居住主题公园水塔-3与晋安新店溪里-2信号强度相当,此方案并不会因SINR恶化导致掉话。
切换掉话问题解决思路:1)调整周围站点天线方位角和下倾角,避免弱覆盖、越区覆盖;2)检查邻区关系,避免由于邻区缺失导致掉话;3)优化切换参数和切换序列,减少不合理切换,提升整体SINR。
优化案例5:天线口功率不平衡问题分析:簇8空扰拉网时发现,五一北路、蒙古营巷、沙帽井巷路段RS0SINR在10 —20dB之间,但下载速率较低,此区域由邮电公寓-2小区覆盖。
问题分析-1:经网管工程师核查,邮电公寓-2小区无硬件告警且数据配置正确。
在邮电公寓-2下进行定点测试,发现极好点处下载速率只有20Mbps左右,若先排除站间干扰影响,将邮电公寓频点由37900改为38100,在SINR=30处下载速率不超过35Mbps,PRB每秒占用不超过400次,初步怀疑为传输问题。
问题分析-2:但在邮电公寓-3下进行定点测试时发现,下载峰值可达60Mbps,排除站点传输问题,关闭邮电公寓-1/3小区,邮电公寓-2下载速率仍不达标,深入分析UElog 时发现,邮电公寓-2小区天线口-0与天线端口-1功率差异较大,影响TM3双流性能。
图10-68 双天线口功率差异过大解决方案:基站工程师排查RRU、跳线、天线故障复测验证:经工程更换天线后,邮电公寓-2小区双天线口功率不平衡问题消失,下行峰值速率达到57Mbps以上,下载速率恢复正常。
图10-69 更换天线后复测经验小结:单站吞吐量异常解决方案单站吞吐量异常排查方法:传输受限:若核心网下行UDP灌包无法达到峰值,查看UDP流量节流位置,若eNB 侧入口流量不足,则判断为传输问题。