LTE日常维护案例介绍
LTE运维情况及当前问题和解决思路
杭州总流量(GB) 5110.95
网页浏览流量（GB） 1844.91
视频流量（GB） 1983.79
杭州LTE用户数 133597
网页浏览KQI：与3G比，页面响应时长改善1倍以上，下载速率提升2倍以上 （ 500KB-2M文件平均下载速率为915kbps，大于2M的文件平均下载速率为2355kbps）。
省 中 心
省干OTN
机房A 核心层L2/L3 PTN 机房B 核心层L2/L3 PTN
地 市
eNB
核心/骨干/汇聚层
地市核心PTN设备完 核心/骨干/汇聚层 成L2与L3的转换
接入层L2 PTN
eNB
eNB
接入层L2 PTN
eNB
杭州 宁波 温州 台州 绍兴 金华 嘉兴 湖州 丽水 衢州 舟山 合计
2013年1月 2013年5月
2013年9月 2014年1月
完成全球首个基于RIM的CSFB电话。 基于终端侧fast retun
首个VOLTE高清语音电话，11月13日实现中韩VOLTE高清互通 9各地市LTE商用， 用户剧增；3月全省11各地市全面商用
2013年3月完成核心网的交维工作，2013年4月全面启动接入网设备 的交维工作，坚持“建设一片，优化一片，交维商用”。
eNB
6
LTE网络运行情况
（1）网络性能指标 浙江3月份无线接通率为99.51%，掉线率为0.52%，整体指标和2/3G网络相当； 同时，路测平均下行速率为30.84Mbps，上行7.28Mbps； 全省CSFB用户主叫接通率为88.76% ，时延9.339S；被叫接通率92.66%，时延 5.799S。
EPC EPC
各地市上连带宽（G）
LTE网络掉线问题优化处理案例
LTE网络掉线问题优化案例摘要：高掉线严重影响用户业务连续性感知，日常优化中遇到的高掉线问题主要是由于：邻区缺失、干扰、弱覆盖、导频污染等问题引起的。
通过合理的RF优化调整、PCI规划、功率调整等手段可有效解决掉线问题。
关键字：掉线率、Mod3干扰、天馈接反、超远切换、邻区漏配、旁瓣覆盖。
掉线率指标主要影响用户业务连续性指标，高掉线小区的特征主要表现在以下几个方面：小区的连续性覆盖、小区的邻区配置合理性、小区覆盖距离、小区干扰水平、小区的参数规划配置等。
日常优化中，需要把握小区掉线特性，有针对性处掉线问题。
本案例从天馈、干扰、邻区等几个方面进行举例。
1.天馈接反导致掉线1.1问题描述通过网优平台对全区LTE掉线率指标统计分析中，发现锡西新城医院_51扇区持续掉线率较高，其他类指标正常。
1.2问题分析1、通过对周围站点分布分析，发现TOP掉话小区：锡西新城医院_51扇区，与胡埭电信支局54扇区存在Mod3干扰，Mod3余值2。
2、通过对胡埭区域的前台测试分析，了解两个扇区覆盖情况。
通过测试数据分析，两扇区主覆盖范围无交叉覆盖区域，两站点间的主要道路由胡埭电信支局_53扇区覆盖。
两个扇区主覆盖方向两扇区之间道路的主覆盖扇区3、在对周围道路分析过程中发现，滨湖_胡埭老桥50与51扇区天馈接反，且两扇区存在交叉覆盖区域。
从PCI分布上分析，两个扇区均为Mod3余2，存在干扰。
路段扇区覆盖图扇区PCI分布1.3问题解决1.3.1 解决方案问题定位后，对滨湖_胡埭老桥50与51扇区天馈进行整改。
1.3.2 测试结果1、整改后现场测试情况对WXL2HTC滨湖_胡埭老桥_51扇区进行整改，整改前后覆盖情况对比如下：整改前整改后2、整改后KPI指标对比2.超远切换导致掉线2.1问题描述日常TOP小区优化中发现5月4日“WXL2HMB新区_旺庄立交_51“E-RAB掉线异常恶化，由之前的0.15%抬升至7.24%，掉线次数达到240次，同时LTE系统内切换成功率从99%下降至83%：2.2问题分析E-RAB高掉线主要通过硬件故障排查->干扰排查->切换问题分析，一步步分析可能存在的异常，直至定位最终问题点，解决问题：2.3问题解决2.3.1 解决方案1、硬件排查；通过华为U2000网管平台查询小区5月4日的告警信息，未发现异常：2、干扰排查；上行干扰查询，通过网优平台查询小区上行RB干扰平均值，近一周上行平均干扰为-119dbm，未发现异常：下行干扰查询，通过MAPinfo查询PCI规划，是否存在MOD3对打现象，与周边小区未发现MOD3干扰：3、E-RAB异常释放COUNTER定位；通过网优平台查询E-RAB异常释放具体counter。
TD-LTE故障处理手册及典型案例
4
4
DSP BRD，看是否有RRU故障（基站侧可直接查看RRU是否掉电）
9
5
5
DSP SFP查询不可用RRU对应的光路是否OK（基站侧可看指示灯是否正常）
9
6
6
DSP CLKSRC查看当前使用的时钟,如是GPS ,DSP GPS查看当前收星情况（基站侧直接查看GPS是否开路或登录基站查看）
9
7
7
查看是否有系统无License运行告警、
原因分析
通常小区服务能力下降告警都是由于站点硬件故障导致的，例如RRU驻波告警、RRU到BBU之间收发光异常、光模块速率过低等，但是查询该站点并不存在上述情况，怀疑跟数据配置有关。
处理过程
1 查询RRU驻波、收发光功率、光模块速率都正常，也不存在其它异常告警，初步排除硬件故障原因；
2 怀疑跟数据配置有关，查询RRU和扇区配置发现该站点为8T8R的宏站配置，而且RRU的8个PATH也都正确关联进去，如下所示（详见附件）——
4
4
3
联系代维到BBU近端，重新插拔故障IR端口上的光模块和光纤接头并用酒精擦拭以清洁光纤接头，看是否恢复
5
4
4
通知代维人员上站更换光模块
5
5
结束
查询RRU收发光：
6)【26260：系统时钟不可用告警】
●告警解释
当基站使用本地晶振的时间超过其可保持的时限时，产生此告警。
●对系统影响
基站业务处理会出现各种异常，如切换失败、掉话等，严重时基站不能提供业务。
现象描述
多个双模站点LTE侧上报小区服务能力下降告警，无其它相关告警，需要排查产生该告警的原因。
ENODEB版本：DBS3900V100R005C00SPC372
最新(完美版)06_LT_OC2010_C1_1_TD-LTE_eNodeB日常维护 (1)
TD-LTE eNodeB日常维护课程目标：●了解日常维护内容●掌握日常维护方法目录第1章维护概述 (3)1.1 维护的分类 (3)1.2 常用维护方法 (3)1.3 维护注意事项 (5)第2章维护信息收集 (7)2.1 基本维护信息收集表 (7)2.2 版本信息收集表 (9)第3章例行维护 (10)3.1 例行维护定义 (10)3.2 例行维护项目 (11)3.3 例行维护周期 (11)3.4 日维护项目 (11)3.5 月维护项目 (13)3.6 季度维护项目 (15)3.7 半年维护项目 (17)3.8 年维护项目 (19)第4章维护信息收集 (23)4.1 日维护记录表 (23)4.2 月维护记录表 (25)4.3 季度维护记录表 (26)4.4 半年维护记录表 (27)4.5 年维护记录表 (27)4.6 突发故障处理记录表 (29)4.7 模块更换数据记录表 (30)4.8 线缆更换数据记录表 (30)第5章模块更换 (32)5.1 CC的更换 (32)5.2 BPL的更换 (33)5.3 PM的更换 (35)5.4 SA的更换 (36)5.5 FA的更换 (37)第6章线缆更换 (38)6.1 BBU线缆更换 (38)6.1.1 更换环境监控RS232/RS485通信线缆 (38)6.1.2 更换环境监控干接点线缆 (41)6.1.3 更换S1/X2接口千兆以太网通信光纤 (43)6.1.4 更换S1/X2接口电以太网通信线缆 (44)6.1.5 更换GPS接收天线线缆 (45)6.1.6 更换基带-远程射频单元光纤 (46)6.2 RRU线缆更换 (47)6.2.1 更换直流电源线缆 (47)6.2.2 更换保护地线缆 (48)6.2.3 更换光纤 (49)6.2.4 更换天馈跳线 (50)6.2.5 更换干接点/RS485/AISG接口线缆 (50)第1章维护概述知识点●维护的分类●常用维护方法●维护注意事项1.1 维护的分类按照日常维护内容可以分为例行维护、通知信息处理、告警信息处理和常见问题处理等4类。
LTE组网介绍及日常维护(华为) ppt课件
12
LTE基站近端维护接入
Step1: UMPT面板只提供USB口，需要USB转接线才能与便携的网口相连（ USB转接 线华为随基站发货）。
UMPT
USB转接 线
Step2: 设置便携电脑与CMPT/UMPT在同一网段（ 如：192.168.0.50），且便携电 脑和单板之间网络通信正常。 UMPT缺省的IP地址为：192.168.0.49，缺省的掩码为：255.255.255.0。密 码为******（密码提供给无线中心维护接口人，有需求申请即可） 连接完成后在浏览器输入http://192.168.0.49，就可以登陆webLMT了。
11
LTE日常维护接入方式
LTE网络相比2G/3G网络更加扁平化，对无线来说最大的变化就是取消了 BSC（RNC）,在LTE网络无线侧来说，网管和eNodeB的功能进一步强化。目 前华为LTE网络无线设备主要提供2种维护接入方式： A. 远端OMC维护，亦即网管操作 （目前主要采用的方式） B. 近端Telnet维护，亦即近端操作（故障处理辅助方式）
6
Page 6
广东电信LTE IPRAN组网结构
7
目录
一、LTE组网概述 二、LTE基站主设备介绍 三、LTE日常维护接入方式 四、LTE日常维护小知识 五、LTE日常维护案例
8
产品介绍－LTE主设备
华为可以提供系列化、平台化的基站设备，满足电信各种场景的应用需求。
9
部件介绍－LTE基站BBU单板配置原则
电源环境监控模块。槽位优先级：Slot19>Slot18 单星卡的USCU槽位配置优先级：Slot5>Slot4>Slot1>Slot0 双星卡的USCU槽位配置优先级：Slot5(同时占据Slot4)>Slot1(同时占据Slot0)
LTE优化案例整理
青岛LTE网络316公交线路测试优化报告1. 优化案例导频污染及重叠覆盖香港中路裕能宾馆附近问题描述：香港中路裕能宾馆以西路段测试情况如下，该路段存在严重弱覆盖问题，部分位置RSRP在-110dBm左右，由于严重弱覆盖造成信号质量及速率差。
问题分析：问题路段测试情况如下，测试分析发现裕能宾馆LDE3覆盖范围较小，扇区方向200左右RSRP下降至-100dBm以下，造成信号质量及速率较差，二疗附近由于覆盖极差发生数据业务掉线。
通过现场勘查发现裕能宾馆3小区天线位置不合理，存在楼面遮挡造成信号阴影衰落严重，小区覆盖方向信号覆盖差，下图为天线位置情况，天线位置为建筑楼面靠东的位置，小区覆盖裕能宾馆以西路段时由于存在40米左右楼面遮挡，信号覆盖差。
优化方案：对裕能宾馆3小区天线位置进行整改，由原位置迁移至建筑东南角区域，并将裕能宾馆LDE3天线由180度调整至200度，直接覆盖香港中路，避免楼面遮挡造成的信号衰落，改善信号覆盖。
优化效果：天线整改后信号覆盖改善明显，由于弱覆盖问题得到改善，该路段信号质量提升，数据业务速率得到很大改善，平均下行速率由14M左右提升至30M以上，掉线问题解决。
二疗覆盖仍存在小范围弱覆盖通过基站“二疗”开通可以得到进一步改善。
调整前RSRP：调整后RSRP：调整前SINR：调整后SINR：调整前Throughput：调整后Throughput：香港中路金丽华附近问题描述：下图为香港中路金丽华附近基站分布情况，平均基站间距150米左右，其中金丽华与疗供基站间距仅90米，且金丽华站高32米、疗供站高24米，基站分布密集且站高较高造成香港中路附近重叠覆盖严重，信号质量及速率差。
问题分析：香港中路附近现场测试情况如下，从信号覆盖情况来看，金丽华附近信号覆盖良好，同一位置可以收到多个强度相近的小区信号，重叠覆盖严重，造成SINR及下行速率差。
前期已针对金丽华、疗供、碧波酒店进行天线调整，控制小区覆盖范围，减小重叠覆盖，由于基站间距过小无法进一步调整改善。
LTE案例维护集
LTE维护案例集目录：1.1华为：某局NASTAR应用过程中无采集数据问题处理 (1)1.2某局OMC调试过程中无法登陆问题处理 (3)1.3PTN带宽受限导致站点下行吞吐速率不达标分析 (6)1.4带电拔掉磁阵存储与硬盘框连接线导致磁阵存储故障告警 (8)1.5爱立信：CalibrationFailure告警处理 (12)1.6爱立信：部分手机无法注册到TD-LTE网络 (12)1.7卡特：双路接收电平不平衡 (13)1.8卡特：天面安装不合理导致下载速率低问题 (14)1.9诺西：LTE初期基站维护常见问题171.1 华为：某局NASTAR应用过程中无采集数据问题处理现象描述：A省某局在进行NASTAR设备调试时，发现其基础数据应用部分不正常，在数据维护中查询，无任何数据，但是同时在数据订阅中发现数据采集状态正常。
具体如截图：数据采集状态：数据维护管理中数据状态：告警信息：无任何告警原因分析：出现此种情况，主要原因可能如下：1、数据未订阅，或者订阅不成功导致数据无法入库。
2、LTESAU与TS服务器连接不正常，数据无法有效传输。
3、路由问题，组网存在端口限制导致数据传输不可实现。
处理过程：针对如上三个原因，进行了详细排查，首先通过区分站点分别定制不同任务数据，待状态正常后两小时，在数据维护窗口下观察是否有数据生成，结果始终无任何数据生成。
后续，通过登陆LTESAU进行TS服务器远程登陆，发现路由正常；最后，分别进入TS服务器/export/home/sysm/internalftp/var/SauService/filter/Nastar库下查询，是否存在后缀名为SIG的采集文件，发现存在该文件，且在实时更新。
该现象说明，数据订阅任务通过NASTAR系统已经顺利下发给网元，且TS接收正常。
介于此，初步分析问题原因点可能存在在LTESAU对于SIG采集文件的预处理入库上。
随后，针对LTESAU上预处理后的入库目录/opt/ransau/data/common/datafile/bak/RanSau.Calculator0下文件进行检查，发现该LTESAU上根本不存在RanSau.Calculator0目录。
LTE eNodeB-FDD基站S1断链告警故障分析和处理案例
LTE eNodeB-FDD基站S1断链告警故障分析和处理案例问题描述（故障现象）某局LTE网管上新出现十几个基站有S1断链的告警，查看告警信息时发现，基站配置的两个MME地址中有一个地址是不通的，基站能正常建链，但都出现到同一MME地址不通而告S1断链。
问题原因分析查看告警附加信息，发现基站配置的两个MME地址中有一个地址是不通的，只有一个地址通，基站能正常建链，但由于绝大部分其他基站到2个MME的地址都是通的，排除MME故障原因导致，检查告警基站的配置数据也没有发现问题，于是怀疑烽火IPRAN数据是否做了修改。
问题解决方案1、通过告警信息初步判断故障原因可能是基站配置数据有过修改、其中一套MME故障、IPRAN传输数据有改动。
2、通过查看全网基站告警排除MME故障原因导致，检查基站配置数据都正常。
3、基本定位为IPRAN传输数据修改导致，沟通烽火IPRAN人员了解到，他们在对应的B设备上把网关做了修改，让做数据的人员检查发现网关修改错误导致到一套MME的地址不通，从而导致我们基站上告S 1链路断的告警，烽火把对应网关修改后告警恢复。
总结及注意事项利用告警信息进行故障的初步定位，应用排除法逐一排查最终定位故障原因，沟通协调传输厂家完成故障处理。
LTE eNodeB-某地FDD基站搜星故障的分析处理问题描述（故障现象）某局FDD基站近期频繁出现“GNSS接收机搜星故障”告警，维护组立即进行深入分析。
时钟同步是为了让基站和网络中的其他设备的时钟频率或者时间差异保持在允许的范围内，避免传输系统中收发信号定时的不准确导致传输性能的恶化。
FDD基站同步是为了后续引起诸如eMBMS、eICIC、M BSFN等降低干扰的关键技术。
问题原因分析①由于开站后就出现故障，初步判断硬件问题，更换蘑菇头、跳线等，故障依旧。
②勘察现场，基站所处位置地理条件糟糕，位于两座山之间的山谷内。
③经一段时间观察，发现由于地理条件影响，该基站受环境影响格外明显，一旦出现大雾天气或者云雨遮挡，便会搜星失败。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
一致则把从消息中获取到的，路由及全部失效，重新启动 流程
传输引起的开站失败案例
问题现象
eNB
某局点，在进行开站时，发现从U2000上
看，每次开站时都是进行到99%时，失
败。
排查步骤
1、首先进行现象确认，从U2000开站界 面上可以看到基站已完成了版本下载 、配置下载，在进行激活配置后等待 站点重新启动完成时超时。
传输类故障
传输故障处理思路
总体思路：分层/逐段排查定位 分层法：根据协议层，逐层定位，定位出实际故障点； 逐段法：完成故障隔离，对数据流进行分段，逐段环回，逐
段定位； 具体排查项： 物理层故障排查 层故障排查 异常处理 异常处理 问题定界指导：
传输类故障
传输故障逐层排查方法简介
处理过程
1、首先进行现象确认，过程正常，而通道建立失败，可能是由于过程中下发的配置有误或者是传输侧配 置有误。
2、其次进行配置核查，结合现象核查下发的配置，下发的主要配置如图所示：核查后发现配置参考与规 划相同。
3、再次进行传输侧相关参数核查，主要是与通道相关的配置，如，网关，核查后发现配置与规划不一致， 修改表中基站的，重新导入中，重新导出开站数据和开站列表。开站正常。
射频类故障处理
3
外部干扰
互调
1
电调天线故障
驻波 2
接口
射频类故障
故障处理
空载下的计算方法如下： -174+10*,其中为带宽，单位为，为射频 模块的噪声系数，通常为2-2.5左右，举例： 2.6G 2T2R，5小区带 宽 ，那么空载下的参考值大小 174+10*(5*10^6)+2.5104.5。
2、其次进行配置核查，版本能够下载成 功，说明无误，、和路由没有问题， 复位后建立失败，可能原因是版本和 配置文件激活失败，或激活成功后通
基站复位重启
传输类案例
路由器）
下载软件 下载配置 激活配置 激活软件
M2000
复位后，U2000以新配置登陆站点 此处失败
目录
设备类故障处理 传输类 设备类故障处理 射频类 设备类故障处理 硬件更换类 业务类故障处理
带宽
20M -98 15M -99 10M -101 5M -104 3M -106 1.4M -110
-97 -98 -100 -103 -105 -109
理论值 过低
过低告警门限为-114
自学习失败故障处理
维护通道类故障
自学习： 在U2000上创建调测任务后，U2000周期性向基站发送通道建立请求。该报文的源地址 为U2000 地址，目的地址为基站的 地址。此数据包会被发送至基站侧的L3路由器上， 如果L3路由器上无对应此报文目的地址及 的表项，L3设备就会广播报文，此时基站则 会接收到此报文，并从报文中取出正确的信息同时进行保存。 案重例点根：因基：站学习到的是 L2上配置的
排查方法
应用场景
通断检测检测
传输路径排查、探测
环回 检测S12链路质量
路由排查
排查方法
应用场景
表项查询
与优先级映射
抓包
协议层
常见问题现象
L5 信令终端/吞吐量异常
L4 上层应用链路不通（、、）
L3 冲突、路由错误等导致业务异常
L2 错误、异常导致链路不通
光纤/光模块故障,物理端口连接 L1 不良,光电模式协商不正确等导致
【实现原理】 1、为了避免广播包冲击U2000，引入 路由器进行 ，转化为单播报文。 2、过程目的是实现的的建立。即获取、 路由等。 2、上电后，4步完成过程。常见问题 需分析具体消息中的取值
自发现失败故障处理
问题描述
维护通道类故障
某局点，在站点安装完成并加电后，使用U2000进行自开站，发现某站点在发送报文后， 在配置管理中一直未出现上报的报文。 问题原因
日常维护案例介绍
目录
设备类故障处理 传输类 设备类故障处理 射频类 设备类故障处理 硬件更换类 业务类故障处理
传输类故障处理
类别
常见问题现象
信令终端/吞吐量异常
上层应用链路不通（、、） 传输类 典型问 冲突、路由错误等导致业务异常
题 错误、异常导致链路不通
光纤/光模块故障,物理端口连接不良,光电模式协商不正 确等导致物理链路不通
在U2000抓包看，已收到上报报文，但在上报的中未携带54字段，因此导致该站的报文 被U2000抛弃。 同时，在基站侧镜像抓包后证明基站发送的报文已携带54字段。
结论：
修改了报文，丢弃了54字段。
问自题描学述习失败故障处理
维护通道类故障
W市T运营商工程在开站过程中四个报文都是正常的,从U2000上可以看到已经下发消息 到基站,且基站也收到U2000发送的消息,但是消息之后又重复四个报文,导致基站操作 维护链路一直不能建立
物理链路不通
传输类故障
维包 1.2、组织配置数据
维护通道类故障
网站
1.4、打开开站工具、
1.3、导出开站列表
上传数据、启动开站
Config Config
Config
上 报
U2000
典型故障 自发现失败
站点
1、安装上电
2、自动发现
eNodeB
3、自动配置
4、调测下发
限制和约束：在开站之前，必须：硬件安装完毕，U2000调测完毕，与U2000之间的传输正常；的软件版本必须从网站上取得，并且 已经上传到U2000 。
自发现失败故障处理
流程： 该流程分四步： 1） 基站在检测到可用的链路后，广播 报 文，以查找可用的U2000; 2） U2000进行匹配，如果匹配成功，U2000 会发送 报文给L3交换机，并携带分配的地 址等信息，以响应 ; 3） 收到 后，判断是否正确，如果正确， 则停止探测过程。并发送 广播报文，向 U2000服务器发起确认信息; 4） U2000同样需要进行匹配判断。确认信 息正确后发送 报文给,基站收到 报文，进 行匹配，匹配成功后，分配的地址等信息生 效，并生成 和相关路由信息。
1、 四个报文中从基站上报的和报文中的都是从 L2上学习 到的，所以基站所发的这两个报文能正常到达U2000，而 U2000也可以把和报文发送到基站； 2、U2000给基站下发消息后，基站会把从U2000上配置的操 作维护、和路由在基站侧生效；
在建立操作维护之前基站会使用U2000 消息中的和 L2上