LTE劣化小区优化指导手册-华为设备

1、LTE劣化小区优化指导手册目 录1掉线类问题31.1影响掉话问题的常见因素31.2整体分析思路41.3掉线问题接入初步分析51.3.1KPI趋势分析51.4参数核查51.5操作日志、设备故障、告警/外部事件排查61.6版本差异和已知问题排查81.7网络规划优化81.7.1弱覆盖排查81.7.2切换异常和邻区分析81.7.3负载和容量分析81.8射频通道和干扰排查81.9Top用户/Top终端类型排查91.9.1TOP用户识别91.9.2TOP终端类型识别91.10核心网异常排查91.11传输排查92高S1切换占比问题112.1X2接口信令异常113高RRC重建问题133.1重建机制介绍：133

2、.2与主要网管指标关联分析143.3与MR指标相关分析143.4打开关闭DRX特性重建比率验证143.5相关参数优化143.6与终端关联分析143.7结论154高PDCP层时延164.1用户面（数据面）时延介绍164.2用户面时延问题定位174.2.1Ping时延分段定位174.3本地UE PC获取时延184.4Wireshark工具精确时延获取184.5Ping时延eNodeB侧L2处理时延获取195总结21LTE劣化小区优化指导手册概述本文介绍了高掉话问题、高S1切换问题，高RRC重建问题，高PDCP层时延问题的排查方法。1 掉线类问题1.1 影响掉话问题的常见因素1.2 整体分析思路规定

3、动作名称分析目的1：掉话问题范围、KPI趋势分析、话统原因分解 1、掉话率变化趋势和转折点确认。2、识别出是Top小区问题还是整网问题。3、根据话统分析掉话的主要原因值。2：参数检查分析参数一致性。3：操作日志+设备故障+告警+外部事件排查1、确认转折点是否有修改参数，软件升级，更改license操作。2、确认转折点是否有影响掉话的故障和告警。4：版本差异和已知问题排查 分析是否由版本已知问题导致，TOP小区问题确认版本、补丁与规划一致性。5：网络规划优化排查覆盖，切换，邻区，负载容量问题6：射频通道和干扰排查 1、排查射频通道是否存在异常 2、分析是否存在上行干扰7：TOP用户排查/TOP终

4、端类型1、排查是否存在掉话TOP用户2、排查掉话是否由某款特殊终端导致。8：核心网异常排查排查异常释放是否由核心网兼容性问题造成9：传输排查排查是否传输问题导致掉话10：投诉及问题复现利用复现加快问题定位，保证客户感受1.3 掉线问题接入初步分析1.3.1 KPI趋势分析掉话率长期趋势分析，确认是逐渐恶化还是突然恶化。如果是突然恶化，那么在转折点附近寻找异常；如果是逐渐恶化则需要分析负载、容量、当地话务模型。掉话率趋势线与切换成功率、RB利用率、用户数、CPU负载趋势线密切相关。可以通过这些趋势线推导掉话率恶化原因。（掉话率趋势图）1.4 参数核查参数核查需要进行全参数核查，掉话强相关的参数需

5、要优先确认。MO类别参数 ID参数名称注意事项及说明eNodeB连接状态定时器配置无线类S1MessageWaitingTimer等待MME S1接口响应消息定时器与X2超时定时器保持一致性，并且小于空口等待定时器eNodeB连接状态定时器配置X2MessageWaitingTimer等待对端ENB X2接口响应消息定时器与S1超时定时器保持一致性，并且小于空口等待定时器eNodeB连接状态定时器配置UuMessageWaitingTimerENB等待UE返回空口响应消息定时器应大于S1/X2接口的等待定时器UE控制定时器配置UeInactiveTimerUE不活动定时器改小对掉话率有增益，增

6、加信令风暴，改大对掉话负增益，减少信令风暴RLCPDCP参数组UeMaxRetxThresholdAM PDU最大重传次数重传次数变大，对掉话率有改善，用户感受变差RLCPDCP参数组ENodeBMaxRetxThresholdeNodeB AM模式RLC ARQ最大重传次数重传次数变大，对掉话率有改善，用户感受变差UE定时器常量信息T310定时器 310改小对掉话率有冲击，改大影响用户感受UE定时器常量信息T311定时器 311改小对掉话率有冲击，改大影响用户感受UE定时器常量信息N311常量 N311改小对掉话率有冲击，改大影响用户感受UE定时器常量信息N310常量 N310改小对掉话率有

7、冲击，改大影响用户感受PDCCH算法参数InitPdcchSymNumPDCCH初始OFDM符号数设置初始符号为1符号，边缘用户解调有困难PDCCH算法参数PdcchSymNumSwitchPDCCH占用OFDM符号数动态调整开关初始符号为1符号，必须打开小区重选参数CELLRESEL(异频) ：SNonIntraSearchCfgInd=CFG, SNonIntraSearch, SNonIntraSearchQ;异频和异系统的小区重选参数MOCN场景下，对不同运营商由于覆盖引起的掉话率差别会带来一定影响UTRANNFREQ（异系统）：SNonIntraSearchCfgInd=CFG, S

8、NonIntraSearch，ThrshServLow，ThreshXHigh, ThreshXLow核心网参数核心网类PBR专有承载参数设置无限大会导致异常释放1.5 操作日志、设备故障、告警/外部事件排查对于与掉话不相关或影响不大的告警，可以暂缓处理；但对于影响掉话和网络性能的告警，需要首先处理完成。名称类别影响可能原因ALM-26521 射频单元接收通道RTWP/RSSI过低告警射频类射频单元的灵敏度下降，小区解调性能变差，上行覆盖变小射频单元接收通道故障ALM-26522 射频单元接收通道RTWP/RSSI不平衡告警射频单元的灵敏度下降，小区解调性能变差，上行覆盖变小射频单元的主集或分

9、集接收通道故障或干扰ALM-26506 射频单元光接口性能恶化告警射频单元该端口链路承载的业务质量严重下降光模块老化或安装不合理ALM-26529 射频单元驻波告警射频单元自动关闭发射通道开关，该发射通道承载的业务中断天馈安装问题，设备故障ALM-26532 射频单元硬件故障告警射频单元可能无法正常工作射频单元内部的硬件故障。ALM-26758 塔放运行数据异常告警接收通道的接收灵敏度过大或过小，导致该扇区的覆盖异常塔放运行异常ALM-26520 射频单元发射通道增益异常告警造成越区干扰或覆盖空洞射频单元硬件故障ALM-29201 S1接口故障告警传输类主动去激活所有与异常的S1接口相关的小区

10、SCTP链路异常ALM-29211 传输网络丢包率过高告警影响掉话，语音质量劣化，数据业务重传变多本地传输线路连接有问题，传输故障ALM-29240 小区不可用告警无线类小区不能提供业务，影响邻区切换，造成邻区掉话单板异常，小区异常ALM-29245 小区闭塞告警小区不能提供业务，影响邻区切换，造成邻区掉话用户手动执行闭塞小区命令ALM-29246 小区模拟负载启动告警本小区对邻区的下行干扰增大。用户启动小区模拟负载ALM-29247 小区PCI冲突告警可能会导致掉话、影响切换性能。PCI规划配置不合理，越区覆盖ALM-26120 星卡时钟输出异常告警时钟类基站长时间获取不到参考时钟，会导致基

11、站系统时钟不可用，基站业务处理会出现各种异常，如小区切换失败、掉话等，严重时基站不能提供业务1.星卡软件运行异常2.星卡硬件故障ALM-26121 星卡天线故障告警基站不能与GPS时钟同步，如果基站长时间获取不到参考时钟，会导致基站系统时钟不可用，此时基站业务处理会出现各种异常，如小区切换失败、掉话等，严重时基站不能提供业务。1.星卡硬件故障2.2.BBU3900到GPS避雷器的信号线开路或短路3.3.GPS避雷器失效4.馈线开路或短路5.天线故障1.星卡天线故障2.时钟参考源配置错误3.星卡工作模式配置错误ALM-26122 星卡锁星不足告警4.卫星天线周围有干扰、遮挡/星卡硬件故障ALM-

12、26123 星卡维护链路异常告警基站不能与星卡通信.1. 星卡软件运行异常2.星卡硬件故障3.星卡线缆故障ALM-26261 未配置时钟参考源告警如果基站长时间不能与参考时钟源同步，会导致系统时钟不可用，此时基站业务处理会出现各种异常，如小区切换失败、掉话等，严重时基站不能提供业务.基站未配置外部时钟参考源ALM-26266 时间同步失败告警基站和网管之间时间不同步，导致基站上报的告警、日志等信息和实际时间不一致。1.和SNTP/NTP服务器相连的传输端口故障2.时间参考源的配置错3.SNTP/NTP客户端参数配置错误4.网元到SNTP/NTP服务器的路由未配置或路由不可达5.SNTP/NTP

13、服务器未启动服务6.星卡天线故障7.星卡锁星不足ALM-26262 时钟参考源异常告警时钟类基站不能与参考时钟源同步，如果基站长时间获取不到参考时钟，会导致基站系统时钟不可用，此时基站业务处理会出现各种异常，如小区切换失败、掉话等，严重时基站不能提供业务。1.如果时钟参考源是GPS，可能是星卡天线故障或锁星不足2.如果时钟参考源是IP CLK，可能是IP时钟链路异常或时钟参考源不可用3.如果是线路时钟，可能是基站与时钟参考源之间的传输线路故障或参考源的频率与本地时钟频率偏差太大4.时钟参考源的配置错误5.UTRP单板、USCU单板或主控板硬件故障。ALM-26263 IP时钟链路异常告警1.承

14、载IP时钟链路的端口故障2.IPCLK链路配置错误3.网元到CLOCK SERVER的路由未配置4.网元到CLOCK SERVER的路由不可达。ALM-26264 系统时钟失锁告警系统时钟异常，导致基站业务处理会出现各种异常，如接入失败、掉话等，业务中断等。1.时钟参考源异常2.未配置时钟参考源3.主控板硬件故障4.如果是非主控板上报该告警，可能是单板未插紧5.单板硬件故障ALM-26265 基站同步帧号异常告警单板承载的业务中断。1.主控板系统时钟锁相环失锁2.单板未插紧3.单板硬件故障ALM-26267 TOD时钟异常告警基站不能与TOD时钟同步，如果基站长时间获取不到参考时钟，会导致基站

15、系统时钟不可用，此时基站业务处理会出现各种异常，如小区切换失败、掉话等，严重时基站不能提供业务。1.TOD线缆故障2.TOD信号源故障3.USCU单板硬件故障1.6 版本差异和已知问题排查检查指标异常站点软件版本是否特殊；若全网问题，通过产品配套文档检查是否存在影响接入的已知问题、预警、网元版本匹配问题，首先进行处理。1.7 网络规划优化1.7.1 弱覆盖排查TOP小区问题，并且掉话原因主要为Radio类，需要对TOP小区进行弱覆盖排查。新建、扩容等涉及到基站设备调整的动作发生后产生的掉话问题，要求首先对整网覆盖异常情况进行了解。根据MR弱覆盖比例高小区 、LTE手机占G网数据流量高比例小区、

16、LTE手机占T网数据流量比例高小区、异系统重定向比例高小区等数据以及现场DT、CQT数据综合分析定位。1.7.2 切换异常和邻区分析分析切换成功率趋势图，是否与掉话率趋势图对应以判断掉话率恶化是否与切换相关。邻区漏配：在ANR功能关闭的场景下，基站对终端上报的MR不处理时，检查基站配置来查看是否漏配邻区。PCI规划不合理：确认切换目标小区为与本小区PCI模3相等，或者PCI复用距离过小等场景。1.7.3 负载和容量分析负载分为空口负载，传输负载，单板负载。对掉话率有影响的主要为空口和单板负载。分析上下行RB利用率与掉话率的关联。单板CPU使用率VS.Board.CPUload.Max分析， V

17、S.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进

18、行判断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.Abnor

19、mRel.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超标优先执行干扰排查。其他场景，若涉及

20、以下错误，联系核心网人员处理：1.协议错误，多是ENB和核心网存在参数不兼容，需要根据原因提示解决2.APN或DNS错误：核心网配置错误3.未指定错误：依赖核心网人员定位1.11 传输排查非同一传输节点下的TOP小区问题，需要对TOP小区逐个定位；同一传输节点下的局部小区问题，定位传输节点问题；整网问题：统管全网的传输节点问题或UGW异常。查看是否有传输类告警：ALM-25888 SCTP链路故障告警，ALM-26223 传输光接口性能恶化告警，ALM-29214 网元端口发送丢包率过高告警，ALM-29207 基站控制面传输中断告警，ALM-25880 以太网链路故障告警检查VLAN，DSC

21、P，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 REQUES

22、T ACK)、SN状态转发(SN STATUS TRANSFER)、UE上下文释放（UE CONTEST RELEASE），如下图中红色信令：X2接口信令异常的常见原因有：1) 切换请求丢失，可能的原因主要有Ø eNB内部处理测量报告异常，如邻区漏配、内部模块处理失败Ø X2口传输异常，如传输丢包2) 切换响应丢失，可能的原因主要有Ø 源小区内部异常，源小区在目标小区回切换响应之前，向目标小区在X2口发HANDOVER CANCEL信令Ø 目标小区切换准备异常，这时通常会在X2口出现 HANDOVER PREPARATION FAILURE信令

23、Ø X2口传输异常，如传输丢包3) SN状态前转信令丢失，可能的原因主要有Ø X2口传输异常，如传输丢包Ø 源小区内部错4) UE上下文释放信令丢失，可能的原因主要有Ø X2口传输异常，如传输丢包Ø  目标小区收到切换完成后内部处理错，导致没有进行S1 PATH切换Ø S1 PATH切换失败对于X2口消息交互出现异常，通常是传输失败或基站内部处理出错，而基站内部处理出错的概率较小，传输失败的可能性较大，但比较难以定位，需要在传输的两端抓包确认。3 高RRC重建问题指标定义：RRC重建比例=RRC重建请求次数/（RRC连接请求

24、次数（不包括重发）+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-D

25、CCH在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(底噪)进行分析.结论：

26、虽然个别小区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) 省控找

27、到合适小区发起重建，在该时间超时前需完成重建：T301(600ms) 省控相关随机接入参数：prachConfIndex、prachCS、prachFreqOff、prachFreqOff等PRACH相关参数按规范设置。3.6 与终端关联分析Ø 在S1信令中找到RRC重建次数较多的CALLID对应的TMSI；Ø 提供TMSI信息给MME侧工程师，查询该终端使用的IMEI信息，该IMEI对应的终端型号；Ø 使用该型号手机在问题小区下做拨打测试，验证该款终端的RRC重建比例是否较高。3.7 结论从目前分析结果来看，重建比率过高和打开DRX特性有关系，主流终端在IOT测

28、试未发现此问题，非主流终端未在实验室进行测试过，需要外场问题复现后推动终端厂商来定位问题4 高PDCP层时延4.1 用户面（数据面）时延介绍用户面时延也指反应端到端的用户面时延，涉及到用户面的所有网元，对于验证网络性能是一个重要的指标。PING时延测试主要分为两大类，第一类是按字节大小分，通常会测试PING 32 bytes，以及1000/1460/1500字节；另外也分调度方式：动态调度和预调度。影响ping时延的关键因素：（1） 信道质量：如果测试时UE所处环境的信道质量不好，则会对解调性能造成一定的影响，这样有可能造成错包或者丢包，进而影响时延结果。（2） HARQ重传：如果数据包在传输

29、过程中出现了错误或者丢失（触发原因可能因为瞬时信号质量变化使得较高的MCS无法解调正确），那么会触发HARQ重传，直到数据包接收正确为止。因此，信道质量越差，重传次数越多，时延也就越大。（3） 调度方式：由于不同调度方式的流程间存在区别，则调度采用预调度还是非预调度会对时延造成影响；预调度：调度器始终为其分配资源，不需要调度请求（Scheduling Request）。详见下图（a）非预调度：在首包到达之后调度器再为其分配资源。UE要通过调度请求来初始化这一流程。详见下图（b）第21页,共21页Page 21 , Total21（4） Ping包大小与调度资源分配（MCS和PRB）：MCS和PRB个数不同，则可以承载的数据量不同，如果调度使用MCS10阶，RB数5个，根据36.213协议查表（Table.1-1），那么这次调度可以发送的数据量为776bit。如果使用MCS28阶，RB数41个，那么这次调度可以发送的数据量为0576bit。4.2 用户面时延问题定位定位思路：分段隔离分析，通过信令跟踪统计，分段抓包等方法，尽可能的找出出现问题的最小网元或者模块。4.2.1 Ping时延分段定位当Pi