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

资源描述

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

《LTE劣化小区优化指导手册华为设备Word下载.docx》由会员分享，可在线阅读，更多相关《LTE劣化小区优化指导手册华为设备Word下载.docx（25页珍藏版）》请在冰豆网上搜索。

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

掉话问题范围、KPI趋势分析、话统原因分解

1、掉话率变化趋势和转折点确认。

2、识别出是Top小区冋题还是整网冋题。

3、根据话统分析掉话的主耍原因值。

参数检查

分析参数一致性。

操作日志+设备故障+告警+外部事件排查

1、确认转折点是否有修改参数，软件升级，更改license操作。

2、确认转折点是否有影响掉话的故障和告警。

版本差异和已知问题排查

分析是否由版本已知问题导致，

TOP小区问题确认版本、补丁与规划一致性。

网络规划优化

排查覆盖，切换，邻区，负载容量问题

射频通道和干扰排查

1、排查射频通道是否存在异常

2、分析是否存在上行干扰

TOP用户排查/TOP终端类型

1、排查是否存在掉话TOP用户

2、排查掉话是否由某款特殊终端导致。

核心网异常排查

排查异常释放是否由核心网兼容性问题造成

传输排查

排查是否传输问题导致掉话

10:

投诉及问题复现

利用复现加快问题定位，保证客户感受

1.3掉线问题接入初步分析

1.3.1KPI趋势分析

掉话率长期趋势分析，确认是逐渐恶化还是突然恶化。

如果是突然恶化，那么在转折点附近寻找异常；

如果是逐渐恶化则需要分析负载、容量、当地话务模型。

掉话率趋势线与切换成功率、RB利用率、用户数、CPU负载趋势线密切相关。

可以通过这些

趋势线推导掉话率恶化原因。

|Call!

（掉话率趋势图）

1.4参数核查

参数核查需要进行全参数核查，掉话强相关的参数需要优先确认。

类别

参数ID

参数名称

注意事项及说明

eNodeB连接状态

定时器配置

S1MessageWaitingTimer

等待MMEJ1接口响应消息定时器

与X2超时定时器保持一致性，并且小于空口等待定时器

X2MessageWaitingTimer

等待对端ENBX2接口响应消息定时器

与S1超时定时器保持一致性，并且小于空口等待定时器

eNodeB连接状态定时器配置

UuMessageWaitingTimer

ENB等待UE返回空口响应消息定时器

应大于S1/X2接口的等待定时器

UE控制定时器配置

UelnactiveTimer

UE不活动定时器

改小对掉话率有增益，增加信令风暴，改大对掉话负增益，减少信令风暴

RLCPDC参数组

无线类

UeMaxRetxThreshold

AMPDU最大重传次数

重传次数变大，对掉话率有改善，用户感受变差

ENodeBMaxRetxThreshold

eNodeBAM模式RLC

ARQ最大重传次数

UE定时器常量信息

T310

定时器310

改小对掉话率有冲击，改大影响用户感受

T311

定时器311

N311

常量N311

N310

常量N310

PDCCH算法参数

InitPdcchSymNum

PDCCH初始OFDM符号

设置初始符号为1符号，边缘

数

用户解调有困难

PdcchSymNumSwitch

PDCC占用OFDM符号数

动态调整开关

初始符号为1符号，必须打开

小区重选参数

CELLRESE异频）:

SNonlntraSearchCfglnd=CFG,SNonlntraSearch,SNonlntraSearchQ;

异频和异系统的小区重选参数

MOC场景下，对不同运营商由于覆盖引起的掉话率差别会带来一定影响

UTRANNFREQ（异系统）：

SNonlntraSearchCfglnd=CFG,SNonIntraSearch，ThrshServLow，ThreshXHigh,ThreshXLow

核心网参数

核心网类

PBR

专有承载参数

设置无限大会导致异常释放

1.5操作日志、设备故障、告警/外部事件排查

对于与掉话不相关或影响不大的告警，可以暂缓处理；

但对于影响掉话和网络性能的告警，需要首先处理完成。

名称

影响

可能原因

射频＞

元接收通道

RTWP/RSS过低告警

射频类

射频单元的灵敏度下降，小区解调性能变差，上行覆盖变小

射频单元接收通道故障

ALM-26522射频单元接收通道

RTWP/RSSI不平衡告

警

射频单元的主集或分集接收通道故障或干扰

ALM-26506射频单元光接口性能恶化告警

射频单元该端口链路承载的业务质量严重下降

光模块老化或安装不合理

ALM-26529射频单元驻波告警

射频单元自动关闭发射通道开关，该发射通道承

载的业务中断

天馈安装问题，设备故障

ALM-26532射频单元硬件故障告警

射频单元可能无法正常工作

射频单元内部的硬件故障。

ALM-26758塔放运行数据异常告警

接收通道的接收灵敏度过大或过小，导致该扇区的覆盖异常

塔放运行异常

ALM-26520射频单元发射通道增益异常告警

造成越区干扰或覆盖空洞

射频单元硬件故障

ALM-29201S1接口

故障告警

传输类

主动去激活所有与异常的S1接口相关的小区

SCTP链路异常

ALM-29211传输网络丢包率过高告警

影响掉话，语音质量劣化，数据业务重传变多

本地传输线路连接有问题，传输故障

ALM-29240小区不可用告警

小区不能提供业务，影响邻区切换，造成邻区掉话

单板异常，小区异常

ALM-29245小区闭塞告警

用户手动执行闭塞小区命令

ALM-29246小区模拟负载启动告警

本小区对邻区的下行干扰增大。

用户启动小区模拟负载

ALM-29247小区PCI冲突告警

可能会导致掉话、影响切换性能。

PCI规划配置不合理，越区覆盖

ALM-26120星卡时

钟输岀异常告警

ALM-26121星卡天

线故障告警

ALM-26122星卡锁

星不足告警

ALM-26123星卡维

护链路异常告警

ALM-26261未配置

时钟参考源告警

ALM-26266时间同

步失败告警

ALM-26262时钟参

考源异常告警

ALM-26263IP时钟

链路异常告警

ALM-26264系统时

钟失锁告警

ALM-26265基站同

步帧号异常告警

基站长时间获取不到参考时钟，会导致基站系统时钟不可用，基站业务处理会岀现各种异常，如小区切换失败、掉话等，严重时基站不能提供业务

1.星卡软件运行异常

2.星卡硬件故障

基站不能与GPS时钟同步，如果基站长时间获取不到参考时钟，会导致基站系统时钟不可用，此

时基站业务处理会岀现各种异常，如小区切换失败、掉话等，严重时基站不能提供业务。

1.星卡硬件故障

2.2.BBU3900到GPS避雷器的信号

线开路或短路

3.3.GPS避雷器失效

4.馈线开路或短路

5.大线故障

1.星卡大线故障

2.时钟参考源配置错误:

3.星卡工作模式配置错误

4.卫星天线周围有十扰、遮挡/星卡硬件故障

基站不能与星卡通信.

1.星卡软件运行异常:

3.星卡线缆故障

如果基站长时间不能与参考时钟源同步，会导致

系统时钟不可用，此时基站业务处理会岀现各种异常，如小区切换失败、掉话等，严重时基站不能提供业务.

基站未配置外部时钟参考源

基站和网管之间时间不同步，导致基站上报的告警、日志等信息和实际时间不一致。

1.和SNTP/NTP服务器相连的传输端口故障

2.时间参考源的配置错

3.SNTP/NTP客户端参数配置错误

4.网元到SNTP/NTP服务器的路由

未配置或路由不可达

5.SNTP/NTP服务器未启动服务

6.星卡天线故障

7.星卡锁星不足

基站不能与参考时钟源同步，如果基站长时间获取不到参考时钟，会导致基站系统时钟不可用，此时基站业务处理会岀现各种异常，如小区切换失败、掉话等，严重时基站不能提供业务。

1.如果时钟参考源是GPS可能是星卡天线故障或锁星不足

2.如果时钟参考源是IPCLK，可能是IP时钟链路异常或时钟参考源不可用

3.如果是线路时钟，可能是基站与时钟参考源之间的传输线路故障或参考源的频率与本地时钟频率偏差太大

4.时钟参考源的配置错误

5.UTRP单板、USCU单板或主控板硬件故障。

1.承载IP时钟链路的端口故障

2.IPCLK链路配置错误

3.网元到CLOCKSERVE的路由未配己置

4.网元到CLOCKSERVE的路由不可达。

系统时钟异常，导致基站业务处理会岀现各种异常，如接入失败、掉话等，业务中断等。

1.时钟参考源异常

2.未配置时钟参考源丁

3.主控板硬件故障

4.如果是非主控板上报该告警，可能是单板未插紧

5.单板硬件故障「

单板承载的业务中断。

1.主控板系统时钟锁相环失锁

2.单板未插紧

3.单板硬件故障

时钟类

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.CPUIoad.Max分析，VS.Board.CPUIoad.Max>

90%，则单板负载

过高。

L.RRC.SetupFail.ResFail和L.E-RAB.FailEst.NoRadioRes是否出现增长。

分析掉话率随上下行RB利用率的变化趋势，单板CPU使用率的变化趋势，RRC接入拒绝和

ERAB建立失败的变化趋势。

1.8射频通道和干扰排查

TOP小区问题，并且掉话原因主要为Radio类，需要对TOP小区进行射频通道和干扰排查。

新建、搬迁等涉及到基站设备调整的动作发生后产生的掉话问题，要求重点确认射频告警情况。

1.9Top用户/Top终端类型排查

1.9.1TOP用户识别

eNB侧无法获取到IMSI，通过TMSI进行判断

1、CHR中会记录用户的TMSI，但在TAU更新中核心网一般会更新用户的TMSI，华为核心网对同一个用户一般只更新TMSI的左起第三、四位，比如OxC06E49A4、OxC06749A4为同一个用户，在统计时可以将这些TMSI统计成一个用户。

其它核心网的TMSI一般TAU更新周期为2小时左右,具体要看核心网配置。

2、Top用户占总体异常的比例，Top1用户异常超过70%时界定为Top用户问题。

1.9.2TOP终端类型识别

提取一定站点数量的日志，并对CHR中记录UE能力进行统计，将各种UE能力的比例统计出来，

筛选出TOP1终端类型。

1.10核心网异常排查

在以L.E-RAB.AbnormRel.MME为掉话原因的TOP小区中启动UU/S1信令跟踪，同时USN信令跟踪。

S1口跟踪至U的UECONTEXTRELEASE消息中携带的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-25888SCTP链路故障告警，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.1X2接口信令异常

对于切换流程，只有经过X2的站间切换在X2口有切换流程的信令：

在X2接口通常情况下有如

下4条信令：

切换请求（HANDOVERREQUEST）、切换响应（HANDOVERREQUESTACK）、SN状态转发（SNSTATUSTRANSFER）、UE上下文释放（UECONTESTRELEASE），如下图中红色信令:

Handavest

RRCCOORECK

SNSTATUSTOiSFER

X2接口信令异常的常见原因有:

3）SN状态前转信令丢失，可能的原因主要有

X2口传输异常，如传输丢包

源小区内部错

4）UE上下文释放信令丢失，可能的原因主要有

目标小区收到切换完成后内部处理错，导致没有进行S1PATH切换

S1PATH切换失败

对于X2口消息交互出现异常，通常是传输失败或基站内部处理出错，而基站内部处理出错的概

率较小，传输失败的可能性较大，但比较难以定位，需要在传输的两端抓包确认。

3高RRC重建问题

指标定义：

RRC重建比例=RRC重建请求次数/（RRC连接请求次数（不包括重发）+RRC重建请求次数）*100%

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层确认的功能

UEEUTRAN

RRCCorinectioriRee^rablishrnemReq茁辄rr,

亠RRCC，皿必tonR辽k喘em

RRCComiectiatzReesiablis/i

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口信令结果也明显看到了RRCRESTAB信令明显消失。

重建比率过高和打开DRX特性有较大关系。

3.5相关参数优化

定时器：

多长时间失步则进入重建的定时器：

T310（1000ms）省控

失步后在特定时间内寻找合适小区的定时器：

T311（1000ms）省控

找到合适小区发起重建，在该时间超时前需完成重建：

T301（600ms）省控