LTE劣化小区优化指导手册华为设备Word下载.docx

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

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

3、行全参数核查，掉话强相关的参数需要优先确认。MO类 别参数ID参数名称注意事项及说明eNodeB连接状态定时器配置S1MessageWaitingTimer等待MMEJ1接口响应消 息定时器与X2超时定时器保持一致性， 并且小于空口等待定时器X2MessageWaitingTimer等待对端ENBX2接口响 应消息定时器与S1超时定时器保持一致性， 并且小于空口等待定时器eNodeB连接状态 定时器配置UuMessageWaitingTimerENB等待UE返回空口响 应消息定时器应大于S1/X2接口的等待定时 器UE控制定时器配 置UelnactiveTimerUE不活动定时器改小对掉话率有

4、增益，增加信 令风暴，改大对掉话负增益， 减少信令风暴RLCPDC参 数组无 线 类UeMaxRetxThresholdAM PDU最大重传次数重传次数变大，对掉话率有改 善，用户感受变差ENodeBMaxRetxThresholdeNodeB AM 模式 RLCARQ最大重传次数UE定时器常量信 息T310定时器310改小对掉话率有冲击，改大影 响用户感受T311定时器311N311常量N311N310常量N310PDCCH算法参数InitPdcchSymNumPDCCH初始 OFDM 符号设置初始符号为1符号，边缘数用户解调有困难PdcchSymNumSwitchPDCC占用OFDM符号数

5、动态调整开关初始符号为1符号，必须打开小区重选参数CELLRESE异频）: SNonlntraSearchCfglnd=CFG, SNonlntraSearch, SNonlntraSearchQ;异频和异系统的小区重 选参数MOC场景下，对不同运营商由 于覆盖引起的掉话率差别会带 来一定影响UTRANNFREQ（异系统）：SNonlntraSearchCfglnd=CFG, SNonIntraSearch ， ThrshServLow， ThreshXHigh, ThreshXLow核心网参数核 心 网 类PBR专有承载参数设置无限大会导致异常释放1.5操作日志、设备故障、告警/外部事件排查

6、对于与掉话不相关或影响不大的告警，可以暂缓处理；但对于影响掉话和网络性能的告警，需 要首先处理完成。名称影响可能原因射频元接收通道RTWP/RSS过低告警射 频 类射频单元的灵敏度下降，小区解调性能变差，上 行覆盖变小射频单元接收通道故障ALM-26522射频单 元接收通道RTWP/RSSI不 平衡告警射频单元的主集或分集接收通道故 障或干扰ALM-26506射频单 元光接口性能恶化 告警射频单元该端口链路承载的业务质量严重下降光模块老化或安装不合理ALM-26529射频单 元驻波告警射频单元自动关闭发射通道开关， 该发射通道承载的业务中断天馈安装问题，设备故障ALM-26532射频单 元硬件

7、故障告警射频单元可能无法正常工作射频单元内部的硬件故障。ALM-26758塔放运 行数据异常告警接收通道的接收灵敏度过大或过小，导致该扇区 的覆盖异常塔放运行异常ALM-26520射频单 元发射通道增益异 常告警造成越区干扰或覆盖空洞射频单元硬件故障ALM-29201 S1 接口故障告警传 输 类主动去激活所有与异常的 S1接口相关的小区SCTP链路异常ALM-29211传输网 络丢包率过高告警影响掉话，语音质量劣化，数据业务重传变多本地传输线路连接有问题，传输故 障ALM-29240小区不 可用告警小区不能提供业务，影响邻区切换，造成邻区掉 话单板异常，小区异常ALM-29245小区闭 塞告

8、警用户手动执行闭塞小区命令ALM-29246小区模 拟负载启动告警本小区对邻区的下行干扰增大。用户启动小区模拟负载ALM-29247 小区 PCI 冲突告警可能会导致掉话、影响切换性能。PCI规划配置不合理，越区覆盖ALM-26120星卡时钟输岀异常告警ALM-26121星卡天线故障告警ALM-26122星卡锁星不足告警ALM-26123星卡维护链路异常告警ALM-26261未配置时钟参考源告警ALM-26266时间同步失败告警ALM-26262时钟参考源异常告警ALM-26263 IP 时钟链路异常告警ALM-26264系统时钟失锁告警ALM-26265基站同步帧号异常告警基站长时间获取不到

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

10、:3.星卡线缆故障如果基站长时间不能与参考时钟源同步， 会导致系统时钟不可用，此时基站业务处理会岀现各种 异常，如小区切换失败、掉话等，严重时基站不 能提供业务.基站未配置外部时钟参考源基站和网管之间时间不同步， 导致基站上报的告 警、日志等信息和实际时间不一致。1.和SNTP/NTP服务器相连的传输 端口故障2.时间参考源的配置错3.SNTP/NTP客户端参数配置错误4.网元到SNTP/NTP服务器的路由未配置或路由不可达5.SNTP/NTP服务器未启动服务6.星卡天线故障7.星卡锁星不足基站不能与参考时钟源同步，如果基站长时间获 取不到参考时钟，会导致基站系统时钟不可用， 此时基站业务处理

11、会岀现各种异常，如小区切换 失败、掉话等，严重时基站不能提供业务。1.如果时钟参考源是 GPS可能是 星卡天线故障或锁星不足2.如果时钟参考源是IP CLK，可能 是IP时钟链路异常或时钟参考源 不可用3.如果是线路时钟，可能是基站与 时钟参考源之间的传输线路故障或 参考源的频率与本地时钟频率偏差 太大4.时钟参考源的配置错误5.UTRP单板、USCU单板或主控板硬 件故障。1.承载IP时钟链路的端口故障2.IPCLK链路配置错误3.网元到CLOCKSERVE的路由未配己 置4.网元到CLOCKSERVE的路由不可 达。系统时钟异常，导致基站业务处理会岀现各种异 常，如接入失败、掉话等，业务中

12、断等。1.时钟参考源异常2.未配置时钟参考源 丁3.主控板硬件故障4.如果是非主控板上报该告警，可 能是单板未插紧5.单板硬件故障 单板承载的业务中断。1.主控板系统时钟锁相环失锁2.单板未插紧3.单板硬件故障时 钟 类1.6版本差异和已知问题排查检查指标异常站点软件版本是否特殊；若全网问题，通过产品配套文档检查是否存在影响接入 的已知问题、预警、网元版本匹配问题，首先进行处理。1.7网络规划优化1.7.1弱覆盖排查TOP小区问题，并且掉话原因主要为 Radio类，需要对TOP小区进行弱覆盖排查。新建、扩容等涉及到基站设备调整的动作发生后产生的掉话问题，要求首先对整网覆盖异常情况进行了解。根据

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

14、 CPU 使用率 VS.Board.CPUIoad.Max 分析， VS.Board.CPUIoad.Max90% ，则单板负载过高。L.RRC.SetupFail.ResFail 和 L.E-RAB.FailEst.NoRadioRes 是否出现增长。分析掉话率随上下行 RB利用率的变化趋势，单板 CPU使用率的变化趋势， RRC接入拒绝和ERAB建立失败的变化趋势。1.8射频通道和干扰排查TOP小区问题，并且掉话原因主要为 Radio类，需要对TOP小区进行射频通道和干扰排查。新建、搬迁等涉及到基站设备调整的动作发生后产生的掉话问题， 要求重点确认射频告警情况。1.9 Top用户/Top终

15、端类型排查1.9.1TOP用户识别eNB侧无法获取到IMSI，通过TMSI进行判断1、 CHR中会记录用户的TMSI，但在TAU更新中核心网一般会更新用户的 TMSI，华为核心网 对同一个用户一般只更新 TMSI的左起第三、四位，比如 Ox C06E49A4、Ox C06749A4为同一个用 户，在统计时可以将这些 TMSI统计成一个用户。其它核心网的TMSI 一般TAU更新周期为2小时左右, 具体要看核心网配置。2、 Top用户占总体异常的比例，Top1用户异常超过70 %时界定为Top用户问题。1.9.2TOP终端类型识别提取一定站点数量的日志， 并对CHR中记录UE能力进行统计，将各种U

16、E能力的比例统计出来，筛选出TOP1终端类型。1.10核心网异常排查在以L.E-RAB.AbnormRel.MME 为掉话原因的TOP小区中启动UU/S1信令跟踪，同时USN信令 跟踪。S1 口跟踪 至U 的 UE CONTEXT RELEASE 消息 中携带 的 cause 若为 radioNetwork : ho-failure-in-target-EPC-ENB-or-target-system ,且组网非跨 MME 的场景下，若L.UL.I nterfere nce.Avg 超标，优先执行干扰排查。若结合UU 口信令跟踪，确认为切换执行阶段的 unspecified原因，而在这种场景下

17、若问题发生在核心网，则联系核心网人员分析；如果问题发生在基站侧， L.UL. In terfere nce.Avg 超标优先执行干扰排查。其他场景，若涉及以下错误，联系核心网人员处理：1.协议错误，多是ENB和核心网存在参数不兼容，需要根据原因提示解决2.APN或DNS错误：核心网配置错误3.未指定错误：依赖核心网人员定位1.11传输排查非同一传输节点下的TOP小区问题，需要对TOP小区逐个定位；同一传输节点下的局部小区问 题，定位传输节点问题；整网问题：统管全网的传输节点问题或 UGW异常。查看是否有传输类告警： ALM-25888 SCTP链路故障告警，ALM-26223 传输光接口性能恶

18、化告警，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.1X2接口信令异常对于切换流程，只有经过 X2的站间切换在X2 口有切换

19、流程的信令：在 X2接口通常情况下有如下4条信令：切换请求（HANDOVER REQUEST ）、切换响应（HANDOVER REQUEST ACK） 、SN 状态转发（SN STATUS TRANSFER） 、UE上下文释放（UE CONTEST RELEASE ），如下图中红 色信令:UEHandave stRRC COO RECKSN STATUS TOiSFERX2接口信令异常的常见原因有:3）SN状态前转信令丢失，可能的原因主要有X2 口传输异常，如传输丢包源小区内部错4）UE上下文释放信令丢失，可能的原因主要有目标小区收到切换完成后内部处理错，导致没有进行 S1 PATH切换S1

20、PATH切换失败对于X2 口消息交互出现异常， 通常是传输失败或基站内部处理出错， 而基站内部处理出错的概率较小，传输失败的可能性较大，但比较难以定位，需要在传输的两端抓包确认。3高RRC重建问题指标定义：RRC重建比例=RRC重建请求次数/（ RRC连接请求次数（不包括重发）+RRC重建请求次数）*100%UE在RRC连接态如果遇到失步无线链路失败（ T310超时）、切换失败（t304超时）、RLC重传次数超限、重配置失败、完整性保护失败等情况时，会触发 RRC重建流程。RRC连接重建立成功流程如下：RRC连接重建请求：UE通过UL_CCCH在SRB0上发送，携带UE的AS层初始标识信息及

21、重建立原因，该消息对应随机接入过程的 Msg3RRC连接重建：eNB通过DL_CCCH在SRB0上回复，携带SRB1的完整配置信息，该消息 对应随机接入过程的 Msg4RRC连接重建立完成： UE通过UL-DCCH在SRB1上发送，不携带任何实际信息，只起到RRC层确认的功能UE EUTRANRR CCo rinectioriR eerablis h rnemR eq 茁辄rr ,亠 RR CC，皿必 tonR 辽 k 喘 emw RR CComiectia tzR ees iablis/iRRC连接重建立拒绝流程：第二步中，如果eNB中没有UE的上下文信息，则拒绝为 UE重建RRC连接，则通

22、过DL_CCCH在SRB0上回复一条RRC连接重建立拒绝消息3.2与主要网管指标关联分析首先对重建比例与无线掉线率、 ERAB掉线率、切换成功率的相关性进行分析。结论：重建比例高与这些指标没有相关性，重建劣化小区，无线掉线率、 ERAB掉线率、切换成功率未见明显恶化。3.3与MR指标相关分析与MR相关分析，重建比例与低 SINR0（干扰）、RSRP-105（底噪）进行分 析.虽然个别小区 SINR0占比偏大，但与重建比例大相关性不明显。3.4打开关闭DRX特性重建比率验证为进一步排查验证是否是 DRX开关引起的重建，选取现网 RRC重建比次数Top小区执行关闭DRX特性开关操作。跟踪小区用户数

23、为始终为 1-2个，执行关闭DRX开关后重建次数从操作前的平均 4,500降到了 0，效果明显。同时在操作前后跟踪 uu 口信令结果也明显看到了 RRC RESTAB信令明显消失。重建比率过高和打开 DRX特性有较大关系。3.5相关参数优化定时器：多长时间失步则进入重建的定时器： T310（ 1000ms ）省控失步后在特定时间内寻找合适小区的定时器： T311（1000ms）省控找到合适小区发起重建，在该时间超时前需完成重建： T301（600ms）省控相关随机接入参数：prachConflndex、prachCS、prachFreqOff、prachFreqOff 等PRACH 相关参数按

24、规范设置。3.6与终端关联分析在S1信令中找到RRC重建次数较多的CALLID对应的TMSI ；提供TMSI信息给MME侧工程师，查询该终端使用的 IMEI信息，该IMEI对应的终端型号;MP M MCn：QUCRYO PT- EJYGUTI ,G LJT I- MDOOSOOMCMA3F 2 - * iVlfNiAME GVMMf J2BHW*/ JO14-M-K 16:3:344 0:00OftM%*i/45871 MEID=（Wb/O$P M 血 TX：QUER帕可冃顺011 南呵子葩0000 初为 忆RETOODE = 0 功MM擀2 -下H噹牙;枢号=0 笔号-萍:=坯号=1IMSI

25、 - 4*0077611600474MSISDN - M&LS76IltOCJ43ME 标週=A6230l2M35uLTTI - b&jQOSOC 3C3CA3-32HMSI = NULLprwsi.?fii4宙区-nullPTMSJ 墨呂=SUL1使用该型号手机在问题小区下做拨打测试，验证该款终端的 RRC重建比例是否较高。HHr.Pi.W-R0*1-712014.311717 J|jfi -RfiC-CCWMjEESlAE.SEOlSUEi152*2125pqtiTggiiaoflTi? ia4i RRG-En/EE曰*fiprat1204T17 * 斡阳f.gJM.曲 EE 宇s*gjE

26、俪bi-iCM,T7l2flW 劄也垃 迢闻 fifiC_CSW.i_ftEESTAH_REO磋UElEiJil-QQUZmTagiflM KflC_.DOREES：TAB才曲EjIME1Z3?窟競曲 N A 剧犹.EilMJfllEIEVr址工昌畑噩T曲-1L-jMKUi冷巾3羽DUL S 2Z3JI iITO FPC_CCm_REE?TA*tS5*JE15IU id 纭 14 -aM WHD0W4 HLLilAH LfeF1VWfiUE3.7结论从目前分析结果来看，重建比率过高和打开 DRX特性有关系，主流终端在IOT测试未发现此问题，非主流终端未在实验室进行测试过，需要外场问题复现后推动终端厂商来定位问题4高PDCP层时延4.1用户面（数据面）时延介绍用户面时