LTE劣化小区优化指导手册
目录
1掉线类问题 (3)
1.1影响掉话问题的常见因素 (3)
1.2整体分析思路 (4)
1.3掉线问题接入初步分析 (5)
1.3.1KPI趋势分析 (5)
1.4参数核查 (5)
1.5操作日志、设备故障、告警/外部事件排查 (6)
1.6版本差异和已知问题排查 (8)
1.7网络规划优化 (8)
1.7.1弱覆盖排查 (8)
1.7.2切换异常和邻区分析 (8)
1.7.3负载和容量分析 (8)
1.8射频通道和干扰排查 (8)
1.9Top用户/Top终端类型排查 (9)
1.9.1TOP用户识别 (9)
1.9.2TOP终端类型识别 (9)
1.10核心网异常排查 (9)
1.11传输排查 (9)
2高S1切换占比问题 (11)
2.1X2接口信令异常 (11)
3高RRC重建问题 (13)
3.1重建机制介绍： (13)
3.2与主要网管指标关联分析 (14)
3.3与MR指标相关分析 (14)
3.4打开关闭DRX特性重建比率验证 (14)
3.5相关参数优化 (14)
3.6与终端关联分析 (14)
3.7结论 (15)
4高PDCP层时延 (16)
4.1用户面（数据面）时延介绍 (16)
4.2用户面时延问题定位 (17)
4.2.1Ping时延分段定位 (17)
4.3本地UE PC获取时延 (18)
4.4Wireshark工具精确时延获取 (18)
4.5Ping时延eNodeB侧L2处理时延获取 (19)
5总结 (21)
LTE劣化小区优化指导手册
概述
本文介绍了高掉话问题、高S1切换问题，高RRC重建问题，高PDCP层时延问题的排查方法。
1 掉线类问题
1.1 影响掉话问题的常见因素
1.2 整体分析思路
1.3 掉线问题接入初步分析
1.3.1 KPI趋势分析
掉话率长期趋势分析，确认是逐渐恶化还是突然恶化。如果是突然恶化，那么在转折点附近寻找异常；如果是逐渐恶化则需要分析负载、容量、当地话务模型。
掉话率趋势线与切换成功率、RB利用率、用户数、CPU负载趋势线密切相关。可以通过这些趋势线推导掉话率恶化原因。
（掉话率趋势图）
1.4 参数核查
参数核查需要进行全参数核查，掉话强相关的参数需要优先确认。
1.5 操作日志、设备故障、告警/外部事件排查
对于与掉话不相关或影响不大的告警，可以暂缓处理；但对于影响掉话和网络性能的告警，需要首先处理完成。
1.6 版本差异和已知问题排查
检查指标异常站点软件版本是否特殊；若全网问题，通过产品配套文档检查是否存在影响接入的已知问题、预警、网元版本匹配问题，首先进行处理。
1.7 网络规划优化
1.7.1 弱覆盖排查
TOP小区问题，并且掉话原因主要为Radio类，需要对TOP小区进行弱覆盖排查。
新建、扩容等涉及到基站设备调整的动作发生后产生的掉话问题，要求首先对整网覆盖异常情况进行了解。
根据MR弱覆盖比例高小区、LTE手机占G网数据流量高比例小区、LTE手机占T网数据流量比例高小区、异系统重定向比例高小区等数据以及现场DT、CQT数据综合分析定位。
1.7.2 切换异常和邻区分析
分析切换成功率趋势图，是否与掉话率趋势图对应以判断掉话率恶化是否与切换相关。
邻区漏配：在ANR功能关闭的场景下，基站对终端上报的MR不处理时，检查基站配置来查看是否漏配邻区。
PCI规划不合理：确认切换目标小区为与本小区PCI模3相等，或者PCI复用距离过小等场景。
1.7.3 负载和容量分析
负载分为空口负载，传输负载，单板负载。对掉话率有影响的主要为空口和单板负载。
分析上下行RB利用率与掉话率的关联。
单板CPU使用率VS.Board.CPUload.Max分析，VS.Board.CPUload.Max>90%，则单板负载过高。
L.RRC.SetupFail.ResFail和L.E-RAB.FailEst.NoRadioRes是否出现增长。
分析掉话率随上下行RB利用率的变化趋势，单板CPU使用率的变化趋势，RRC接入拒绝和ERAB建立失败的变化趋势。
1.8 射频通道和干扰排查
TOP小区问题，并且掉话原因主要为Radio类，需要对TOP小区进行射频通道和干扰排查。
新建、搬迁等涉及到基站设备调整的动作发生后产生的掉话问题，要求重点确认射频告警情况。
1.9 Top用户/Top终端类型排查
1.9.1 TOP用户识别
eNB侧无法获取到IMSI，通过TMSI进行判断
1、CHR中会记录用户的TMSI，但在TAU更新中核心网一般会更新用户的TMSI，华为核心网对同一个用户一般只更新TMSI的左起第三、四位，比如0x C06E49A4、0x C06749A4为同一个用户，在统计时可以将这些TMSI统计成一个用户。其它核心网的TMSI一般TAU更新周期为2小时左右，具体要看核心网配置。
2、Top用户占总体异常的比例,Top1用户异常超过70％时界定为Top用户问题。
1.9.2 TOP终端类型识别
提取一定站点数量的日志，并对CHR中记录UE能力进行统计，将各种UE能力的比例统计出来，筛选出TOP1终端类型。
1.10 核心网异常排查
在以L.E-RAB.AbnormRel.MME为掉话原因的TOP小区中启动UU/S1信令跟踪，同时USN信令跟踪。
S1口跟踪到的UE CONTEXT RELEASE消息中携带的cause若为radioNetwork：ho-failure-in-target-EPC-ENB-or-target-system，且组网非跨MME的场景下，若L.UL.Interference.Avg超标，优先执行干扰排查。
若结合UU口信令跟踪，确认为切换执行阶段的unspecified原因，而在这种场景下若问题发生在核心网，则联系核心网人员分析；如果问题发生在基站侧，L.UL.Interference.Avg超标优先执行干扰排查。
其他场景，若涉及以下错误，联系核心网人员处理：
1.协议错误，多是ENB和核心网存在参数不兼容，需要根据原因提示解决
2.APN或DNS错误：核心网配置错误
3.未指定错误：依赖核心网人员定位
1.11 传输排查
非同一传输节点下的TOP小区问题，需要对TOP小区逐个定位；同一传输节点下的局部小区问题，定位传输节点问题；整网问题：统管全网的传输节点问题或UGW异常。
查看是否有传输类告警：ALM-25888 SCTP链路故障告警，ALM-26223 传输光接口性能恶化告警，ALM-29214 网元端口发送丢包率过高告警，ALM-29207 基站控制面传输中断告警，ALM-25880 以太网链路故障告警
检查VLAN，DSCP，IPRT，IPPATH，SCTP等传输参数配置与规划是否一致。
2 高S1切换占比问题
高S1切换占比小区，如果是跨MME引起的高S1切换属于正常情况，另一个就是X2切换准备失败在X2后交换中：
跨MME的站间切换排查，如果两个站点时跨MME的切换必然走S1，这部分无法避免 对于其他走S1切换的多位X2口信令异常问题，主要排查X2口上问题即可
2.1 X2接口信令异常
对于切换流程，只有经过X2的站间切换在X2口有切换流程的信令：在X2接口通常情况下有如下4条信令：切换请求（HANDOVER REQUEST）、切换响应(HANDOVER REQUEST ACK)、SN 状态转发(SN STATUS TRANSFER)、UE上下文释放（UE CONTEST RELEASE），如下图中红色信令：
X2接口信令异常的常见原因有：
1) 切换请求丢失，可能的原因主要有
eNB内部处理测量报告异常，如邻区漏配、内部模块处理失败
X2口传输异常，如传输丢包
2) 切换响应丢失，可能的原因主要有
源小区内部异常，源小区在目标小区回切换响应之前，向目标小区在X2口发HANDOVER CANCEL信令
目标小区切换准备异常，这时通常会在X2口出现 HANDOVER PREPARATION FAILURE信令
X2口传输异常，如传输丢包
3) SN状态前转信令丢失，可能的原因主要有
X2口传输异常，如传输丢包
源小区内部错
4) UE上下文释放信令丢失，可能的原因主要有
X2口传输异常，如传输丢包
目标小区收到切换完成后内部处理错，导致没有进行S1 PATH切换
S1 PATH切换失败
对于X2口消息交互出现异常，通常是传输失败或基站内部处理出错，而基站内部处理出错的概率较小，传输失败的可能性较大，但比较难以定位，需要在传输的两端抓包确认。
3 高RRC重建问题
指标定义：
RRC重建比例=RRC重建请求次数/（RRC连接请求次数（不包括重发）+RRC重建请求次数）*100% 3.1 重建机制介绍：
UE在RRC 连接态如果遇到失步无线链路失败（T310超时）、切换失败（t304超时）、RLC重传次数超限、重配置失败、完整性保护失败等情况时，会触发RRC重建流程。
RRC连接重建立成功流程如下：
RRC连接重建请求：UE通过UL_CCCH在SRB0上发送，携带UE的AS层初始标识信息及重建立原因，该消息对应随机接入过程的Msg3
RRC连接重建：eNB通过DL_CCCH在SRB0上回复，携带SRB1的完整配置信息，该消息对应随机接入过程的Msg4
RRC连接重建立完成：UE通过UL-DCCH在SRB1上发送，不携带任何实际信息，只起到RRC层确认的功能
RRC连接重建立拒绝流程：
第二步中，如果eNB中没有UE的上下文信息，则拒绝为UE重建RRC连接，则通过DL_CCCH 在SRB0上回复一条RRC连接重建立拒绝消息
3.2 与主要网管指标关联分析
首先对重建比例与无线掉线率、ERAB掉线率、切换成功率的相关性进行分析。
结论：重建比例高与这些指标没有相关性，重建劣化小区，无线掉线率、ERAB掉线率、切换成功率未见明显恶化。
3.3 与MR指标相关分析
与MR相关分析，重建比例与低SINR<0(干扰)、RSRP<-110(覆盖)以及RIP>-105(底噪)进行分析.
结论：虽然个别小区SINR<0占比偏大，但与重建比例大相关性不明显。
3.4 打开关闭DRX特性重建比率验证
为进一步排查验证是否是DRX开关引起的重建，选取现网RRC重建比次数Top小区执行关闭DRX特性开关操作。
跟踪小区用户数为始终为1-2个，执行关闭DRX开关后重建次数从操作前的平均4,500降到了0，效果明显。同时在操作前后跟踪uu口信令结果也明显看到了RRC RESTAB信令明显消失。
结论：重建比率过高和打开DRX特性有较大关系。
3.5 相关参数优化
定时器：
多长时间失步则进入重建的定时器：T310（1000ms）省控
失步后在特定时间内寻找合适小区的定时器：T311(1000ms)省控
找到合适小区发起重建，在该时间超时前需完成重建：T301(600ms)省控
相关随机接入参数：
prachConfIndex、prachCS、prachFreqOff、prachFreqOff等PRACH相关参数按规范设置。
3.6 与终端关联分析
在S1信令中找到RRC重建次数较多的CALLID对应的TMSI；
提供TMSI信息给MME侧工程师，查询该终端使用的IMEI信息，该IMEI对应的终端型号；
使用该型号手机在问题小区下做拨打测试，验证该款终端的RRC重建比例是否较高。
3.7 结论
从目前分析结果来看，重建比率过高和打开DRX特性有关系，主流终端在IOT测试未发现此问题，非主流终端未在实验室进行测试过，需要外场问题复现后推动终端厂商来定位问题
4 高PDCP层时延
4.1 用户面（数据面）时延介绍
用户面时延也指反应端到端的用户面时延，涉及到用户面的所有网元，对于验证网络性能是一个重要的指标。
PING时延测试主要分为两大类，第一类是按字节大小分，通常会测试PING 32 bytes，以及1000/1460/1500字节；另外也分调度方式：动态调度和预调度。
影响ping时延的关键因素：
（1）信道质量：如果测试时UE所处环境的信道质量不好，则会对解调性能造成一定的影响，这样有可能造成错包或者丢包，进而影响时延结果。
（2）HARQ重传：如果数据包在传输过程中出现了错误或者丢失（触发原因可能因为瞬时信号质量变化使得较高的MCS无法解调正确），那么会触发HARQ重传，直到数据包接收正确为止。
因此，信道质量越差，重传次数越多，时延也就越大。
（3）调度方式：由于不同调度方式的流程间存在区别，则调度采用预调度还是非预调度会对时延造成影响；
预调度：调度器始终为其分配资源，不需要调度请求（Scheduling Request）。详见下图（a）
非预调度：在首包到达之后调度器再为其分配资源。UE要通过调度请求来初始化这一流程。详见下图（b）
（4）Ping包大小与调度资源分配（MCS和PRB）：MCS和PRB个数不同，则可以承载的数据量不同，如果调度使用MCS10阶，RB数5个，根据36.213协议查表
（Table7.1.7.2.1-1），那么这次调度可以发送的数据量为776bit。如果使用MCS28阶，RB数41个，那么这次调度可以发送的数据量为0576bit。
4.2 用户面时延问题定位
定位思路：分段隔离分析，通过信令跟踪统计，分段抓包等方法，尽可能的找出出现问题的最小网元或者模块。
4.2.1 Ping时延分段定位
当Ping时延数据结果和预期结果有较大差距的时候，就需要经过分段测试、定位的方法，特别是因为S1口到核心网UGW/服务器侧的波动带来的PING时延的不稳定问题，下面说明PING时延分段定位方法。
（Ping时延分段分析示意图）
1、Wireshark用在本地PC端，可以计算出端到端的精确时延。同时在UE的ping界面，也可以
看到个精确度在ms级的时延。（Wireshark抓包使用前，需要获得相应许可）
2、在M2000 可以利用用户面消息跟踪打印出ENB侧L2每一层的时间戳信息，同时也可以使用IFTS个跟踪，获取L1日志，可以帮助推断空口时延
另外，还可以在核心网服务器侧，利用Wireshark计算出服务器侧的处理时延。
4.3 本地UE PC获取时延
电脑，开始---运行CMD
Ping服务器地址: ping xx.xx.xx.xx （默认32byte）
Ping大包ping xx.xx.xx.xx -l 1460 –n 30
-l 后加要ping包的大小，单位byte
-n 后加要ping包的次数
得到ping包的平均值后与基线对比，寻求定位。
4.4 Wireshark工具精确时延获取
在Ping之前，打开Wireshark工具，点击Capture捕获窗口，选择正确的interface在过滤栏指定ICMP消息。
Ping的精确时延：在Protocol—Icmp: Echo (ping) reply的seq=894里的Arrival time —Echo (ping) request的seq=894里的Arrival time
在Inter Control Message Protocol里：Sequencen number:确定该Ping包的序列号，Date里确定Ping包的大小。
4.5 Ping时延eNodeB侧L2处理时延获取
webLMT是eNodeB维测工具，是在eNB侧经常使用的工具，，下面针对PING包时延分段eNB 侧的使用作描述。
首先获取TMSI，可以在UU口的RRC_CONN_REQ看到：
打开用户面跟踪，跟踪模块中勾选上PDCP，RLC基本项
在PING过程中，记录用户面跟踪数据，测试完毕后，保存为tmf文件，以便后面计算和分析。