华为TDD-LTE指标监控指导书(经典)Word文件下载.doc
《华为TDD-LTE指标监控指导书(经典)Word文件下载.doc》由会员分享，可在线阅读，更多相关《华为TDD-LTE指标监控指导书(经典)Word文件下载.doc（23页珍藏版）》请在冰点文库上搜索。
2.KPI指标公式定义
请参考附件中OMC920对应指标定义：
二、数据提取方法
1.OMC自定义指标
以eNB间切换成功率为例：
1、查看工具栏，点击自定义指标管理，选择功能子集模块eNODEB,选择测量族和测量组（指标所在的测量族请参考文档《中国移动集团要求上报TDDLTE网络指标V2.1.8》），如图1：
图1
2、右击系统内切换出测量，选择添加后出现下图窗口，输入指标名称（注意单位的选择），填写公式后，点击应用
图2
3、在自定义指标管理界面找到定义的指标，右击，选择测量设置，如图3
图3
4、在弹出的窗口，如图4，勾选新对象自动测量，点击应用，结束。
图4
2.KPI指标提取
1、点击结果查询，选择新查询，选择对象，如需选取部分站点（点击第一个对象后，按住“Shift”键，再点击最后一个站点，可将这些对象全选），如图5
图5
2、选取需要查询的指标和对应的周期类型，如图6，按需要选择日期范围和时间方式，如图7
图6
图7
3、指标查询结果如图8
图8
3.告警提取
常见告警分类表
告警等级
告警号
告警名称
本机网管
紧急
网元连接中断
ENODEB
重要
29243
小区服务能力下降告警
19240
小区不可用告警
26205
BBU单板维护链路异常告警
29207
基站控制面传输中断告警
25621
直流输出异常告警
26276
制式间站点配置冲突告警
26238
RRU组网拓扑类型与配置不一致告警
BBP心跳检测失败告警
26529
射频单元驻波告警
26322
BBU测收发光异常
26503
RRU测收发光异常
26233
BBUIR光接口性能恶化告警
29201
S1接口故障告警
25888
SCTP链路故障告警
26235
射频单元维护链路异常告警
26506
RRU测光口性能恶化
26260
系统时钟不可用告警
主要告警分析和常见的处理手段。
下面以“网元链路中断”为例说明如何查看和处理常见告警，其他告警类可查看附件内容。
（附件：
）
示例：
【网元链接中断】
●告警解释：
网元与OMC网管之间的链接中断，一般来讲，为断电或传输问题
●对系统的影响
对该网元无法控制
●告警处理
序号
处理方法
“是”
“否”
1
检查同一环路下基站是否全部中断（基站侧检查光路和电源是否OK.）
2
3
2
通知传输中心处理
4
3
通知机房巡检处理故障（基站侧更换传输光模块/光纤）
结束
三、坏小区（TOP小区）查找和分析处理
每小时对上一个小时的全网整体指标进行提取，如果指标变化波动较大，需提取小区级别指标进行查看，将小区级的掉话率指标和掉话绝对次数按从高到低的顺序进行排序,确认是全网的整体问题还是TOP小区引起的指标波动，若剔除TOP小区后，指标恢复正常，则是TOP小区问题，优先分析掉话绝对次数多且掉话率高的Top小区；
否则是全网性问题，以下是关于TOP小区筛选的方法和主要KPI处理方法流程：
1.接入性TOP分析处理
1.
1.1指标定义
指标定义
OMC920
RRC连接建立完成次数/RRC连接请求次数（不包括重发）
E-RAB建立成功总次数/E-RAB建立尝试总次数
RRC连接建立成功率*E-RAB建立成功率
1.2指标分析及统计点介绍
lRRC连接建立成功率
图1中【A点】
（1）指标L.RRC.ConnReq.Att加1，不统计重发的次数。
Case1：
eNB下发RRC_Conn_Setup消息后，在T300定时器超时前，收到相同的UeID发起的RRC_Conn_Req（Setup丢失，UEMAC冲突解决定时器超时后重发RRC_Conn_Req，UeID不变），记为一次重发RRC_Conn_Req消息。
Case2：
T300超时后，UE仍未收到RRC_Conn_Setup，UE重新搜网，发起初始接入，UeID是取0~239的随机值或上层下发的TMSI。
eNB侧记为新的一次初始接入，L.RRC.ConnReq.Att加1。
Case3：
发起Attach后会启动T310定时器。
如果UE发出RRC_Conn_Setup_Cmp后，ENB没有收到，UE会在定时器超时后重新发起Attach，ENB侧记为新的一次初始接入；
RRC_Conn_Setup_Cmp丢失不会触发重建，发起重建的前提是安全已经激活。
（2）如果RRCConnectionRequest消息信元EstablishmentCause为“emergency”，指标L.RRC.ConnReq.Att.Emc加1。
（3）如果RRCConnectionRequest消息信元EstablishmentCause为“highPriorityAccess”，指标L.RRC.ConnReq.Att.HighPri加1。
（4）如果RRCConnectionRequest消息信元EstablishmentCause为“mt-Access”，指标L.RRC.ConnReq.Att.Mt加1。
（5）如果RRCConnectionRequest消息信元EstablishmentCause为“mo-Singnalling”，指标L.RRC.ConnReq.Att.MoSig加1。
（6）如果RRCConnectionRequest消息信元EstablishmentCause为“mo-Data”，指标L.RRC.ConnReq.Att.MoData加1。
【B点】
当eNodeB下小区接收到UE发送的RRCConnectionRequest消息并下发RRCConnectionSetup消息给UE时，指标L.RRC.ConnSetup加1。
【C点】
当eNodeB收到UE返回的RRCConnectionSetupComplete消息时统计相应指标，L.RRC.ConnReq.Succ加1。
RRCSetupSuccessRate计算：
RRCSetupSuccessRate=（L.RRC.ConnReq.Succ）/（L.RRC.ConnReq.Att）*100%
lE-RAB建立成功率
如图2、3中【A点】所示，当eNodeB收到来自MME的E-RABSETUPREQUEST或者INITIALCONTEXTSETUPREQUEST消息时统计该指标。
如果E-RABSETUPREQUEST或者INITIALCONTEXTSETUPREQUEST消息中要求同时建立多个E-RAB，则相应指标按各个业务的QCI分别进行累加。
当MME收到来自eNodeB的E-RABSETUPRESPONSE或者INITIALCONTEXTSETUPRESPONSE消息时E-RAB建立成功次数累加。
ERABSetupSuccessRate计算公式：
ErabSetupSuccessRate=（L.E-RAB.SuccEst）/（L.E-RAB.AttEst）*100%
1.3TOP小区分析和处理
Ø
处理流程和方法
通过对TOP小区建立失败的原因进行观察，通过对不同的原因做相应的观察，不同失败原因对于相应指标有不同的变化，应对观察指标和优化策略均不同，下表为指标提取的建立失败的不同原因分类和相应说明：
①小区RRC建立失败次数：
1、□资源分配失败而导致RRC连接建立失败的次数，指标ID：
1526727083；
重点关注top资源是否足够，包括top用户数，传输、PRB等；
2、□UE无应答而导致RRC连接建立失败的次数，指标ID：
1526727084；
关注质差、干扰、无线环境等；
3、□小区发送RRCConnectionReject消息次数，指标ID：
1526728269；
关注传输问题、是否拥塞、干扰；
4、□因为SRS资源分配失败而导致RRC连接建立失败的次数，指标ID：
1526728485；
重点关注SRS带宽、配置指示、配置方式、SRSACK/NACK设置是否合理等；
5、□因为PUCCH资源分配失败而导致RRC连接建立失败的次数，指标ID：
1526728486；
关注PUCCH信道相关参数设置是否合理，CQIRB数配置是否合理等；
d
6、□流控导致的RRCConnectionRequest消息丢弃次数，指标ID：
1526728489；
关注拥塞，业务流控相关参数是否设置正确等；
7、□流控导致的发送RRCConnectionReject消息次数，指标ID：
1526728490；
②对小区E-RAB建立失败次数：
1、□因未收到UE响应而导致E-RAB建立失败的次数，指标ID：
1526726717；
处理建议：
需排查覆盖，干扰，质差，ENODEB参数设置错误，终端及用户行为异常等原因。
2、□核心网问题导致E-RAB建立失败次数，指标ID：
1526728276；
需跟踪信令，排查核心网问题（EPC参数设置,TAC码设置的一致性，对用户开卡限制，硬件故障方面排查）；
3、□传输层问题导致E-RAB建立失败次数，指标ID：
1526728277；
需查询传输是否有故障，高误码，闪断，传输侧参数设置问题。
4、□无线层问题导致E-RAB建立失败次数，指标ID：
1526728278；
5、□无线资源不足导致E-RAB建立失败次数，指标ID：
1526728279；
1、排查TOP小区资源是否足够，是否故障引起，若存在资源不足问题，可考虑参数调整，流量均衡（小区选择，重选和切换类参数）；
2、结合现场调整天馈，流量均衡；
3、热点区域，增补基站等；
6、□安全模式配置失败导致E-RAB建立失败次数，指标ID：
1526728280；
在一般正常情况下建立失败的通常为无线侧问题导致的可以处理，具体常见处理方法和流程如下：
1.检查操作，告警，传输问题，是否存在网络变动和升级行为等（1.通过LSTALMAF查询站点实时告警,用LSTALMLOG参考历史告警；
è
存在告警则降低功率切出用户，严重的临时去激活小区，通知维护人员处理；
2.通过DSPBRD查询单板运行情况；
异常则通知维护人员；
3.传输及EPC侧有网络变动（升级，割接，参数修改等）。
一般为突发，及时同时相关人员；
4.通过Mapinfo查看小区PCI复用是否合理，是否存在模三冲突；
用MODCELL修改PCI
5.检查小区时隙配比是否设置准确（室分:
SA2\SSP7;
宏站:
SA2\SSP5）è
LSTCELL查看，MODCELL修改；
6.如每PRB上干扰噪声平均值>
-110dBm,确认小区存在上行干扰，同时可通过后台跟踪，确认干扰类型；
统计话务统计看是突发的还是持续的，可应急通过MODPDSCH降功率处理；
7.检查传输模式，是否为TM3，如长时间为TM2，确认设置正确的情况下，基本确定小区存在弱覆盖；
8.对比64QAM和QPSK占比，如后者比例远大于前者,可确定小区覆盖异常；
9.邻区告警、故障等导致TOP小区存在弱覆盖；
10.天馈问题,无线环境差；
11.天线权值配置与现场天线参数不一致。
12.核查参考信号功率是否偏低（常规设置92,122，需结合现场设置）；
MODPDSCH进行修改；
2.保持性TOP分析处理
2.
2.1指标定义
（eNodeB发起的S1RESET导致的UEContext释放次数+UEContext异常释放次数）/UEContext建立成功总次数*100%
（eNodeB触发的释放原因为异常的E-RAB释放总次数+切换出E-RAB异常释放总次数）/用户发起E-RAB建立流程且建立成功的总次数*100%
2.2指标分析及统计点介绍
l无线掉线率
如上图：
【图1】中A点所示，当eNodeB向MME发送UECONTEXTRELEASEREQUEST消息，会释放UE的所有E-RAB。
当释放原因不为“NormalRelease”，“Detach”，“UserInactivity”，“CSFallbacktriggered”，“UENotAvailableforPSService”，“Inter-RATRedirection”，“TimeCriticalHandover”，“HandoverCancelled”时，测量指标L.UECNTX.AbnormRel加1。
如【图2】中A点所示，当eNodeB向MME发送S1RESET消息时，根据包含的上下文个数，指标L.UECNTX.Rel.S1Reset.eNodeB进行累加。
如【图3】中A点所示，当MME向eNodeB发送S1RESET消息时，根据包含的上下文个数，指标L.UECNTX.Rel.S1Reset.MME进行累加。
lE-RAB掉线率
E-RAB掉线分2部分，为eNodeB触发的释放原因为异常的E-RAB释放总次数和切换出E-RAB异常释放总次数，分别如下：
切换出E-RAB异常释放信令统计点如下图：
上图中，图1表示eNodeB内切换，图2表示X2接口切换，图3表示S1接口切换，图4表示E-UTRAN系统切换到WCDMA系统、GERAN系统、或者TD-SCDMA系统。
如图1、图2、图3和图4中C点所示，切换执行成功，但目标小区有建立失败的承载，源小区异常释放对应的E-RAB，则在源小区按各个业务的QCI分别统计该指标。
同时，在源小区根据相应E-RAB的个数将总次数累加，即指标L.E-RAB.AbnormRel.HOOut累加。
eNodeB触发的释放原因为异常的E-RAB释放信令统计点如下图：
如图1中A点所示，当eNodeB发出E-RABRELEASEINDICATION消息，且释放原因不为“NormalRelease”，“Detach”，“UserInactivity”，“CSFallbacktriggered”，“UENotAvailableForPSService”，“Inter-RATRedirection”，“SuccessfulHandover”时统计L.E-RAB.AbnormRel.eNBTot指标，当判断相应承载有数传时统计L.E-RAB.AbnormRel指标。
如果E-RABRELEASEINDICATION信令中要求同时释放多个E-RAB，则相应的指标统计多次；
如图2中A点所示，当eNodeB向MME发送UECONTEXTRELEASEREQUEST消息，会释放UE的所有E-RAB。
当释放原因不为“NormalRelease”，“Detach”，“UserInactivity”，“CSFallbacktriggered”，“UENotAvailableForPSService”，“Inter-RATRedirection”，“TimeCriticalHandover”，“HandoverCancelled”时统计L.E-RAB.AbnormRel.eNBTot指标，当判断相应承载有数传时统计L.E-RAB.AbnormRel指标。
如果被释放用户建立了多个E-RAB，则相应的指标统计多次。
并且在MME回复UECONTEXTRELEASECOMMAND消息时，相应指标不会被重复记录。
2.3TOP小区分析流程
TOP小区分析可通过OMC920提取异常释放原因：
无线掉线率释放原因如下：
□eNodeB发起的原因为UELOST的UEContext释放次数
□eNodeB发起的原因为切换失败的UEContext释放次数
□eNodeB发起的原因为无线层问题的UEContext释放次数
□eNodeB发起的S1RESET导致的UEContext释放次数
E-RAB掉线率释放原因如下：
□无线层问题导致的激活的E-RAB异常释放次数
□传输层问题导致的激活的E-RAB异常释放次数
□网络拥塞导致的激活的E-RAB异常释放次数
□切换流程失败导致激活的E-RAB异常释放次数
□核心网问题导致E-RAB异常释放次数
1.通过LSTALMAF查询站点实时告警,参考历史告警LSTALMLOG；
è
若异常，通知维护人员处理；
3.提取两两小区切换，确定目标小区：
A.确定目标小区运行情况，是否基站故障或异常告警；
B.检查邻区间参数设置是否正确；
核查修改邻区外部小区参数是否正确，切换偏置是否合理；
C.通过Mapinfo检查小区邻区配置是否合理，进行邻区合理性优化；
进行邻区的合理删除和添加；
D.检查基站是否周边站点缺少，如为孤站，可视为正常；
暂不做处理，观察；
4.检查参数设置是否合理：
A.查询掉线类定时器设置是否正确；
（T310、N311、N310、T311、T301）.
LSTUETIMERCONST:
;
B.如掉线率突增，查询操作日志，确认是否有修改，导致小区异常；
用LSTOPTLOG查看是否指标异常开始时段有相应修改操作，询问修改人进行相应恢复观察；
5.检查是否存在干扰：
A.通过Mapinfo查看小区PCI复用是否合理，是否存在模三冲突；
修改PCI
B.检查小区时隙配比是否设置准确（E频段室分:
F和D频段宏站:
SA2\SSP5）；
修改时隙配比配比MODCELL;
C.如每PRB上干扰噪声平均值>
6.是否存在高质差：
A.通过观察小区上下行丢包率是否正常，如丢包率偏高，基本断定小区存在质差；
B.通过后台误码率跟踪，如BLER>
10%，确定小区存在高误码；
7.是否存在弱覆盖：
A.检查传输模式，是否为TM3，如长时间为TM2，确认设置正确的情况下，基本确定小区存在弱覆盖；
B.对比64QAM和QPSK占比，如后者比例远大于前者,可确定小区覆盖异常；
8.现场测试及后台跟踪：
A.安排前场人员现场测试，同时后台通过信令跟踪，配合查找问题原因；
B.如果确认问题后，需配合解决，转发相关人员处理，做好跟踪工作，直至问题闭环。
3.移动性TOP分析处理
3.
3.1指标定义
（eNodeB内同频切换出成功次数+eNodeB内异频切换出成功次数-通过重建回源小区的eNodeB内同频切换出执行成功次数-通过重建回源小区的eNodeB内异频切换出执行成功次数）/（eNodeB内同频切换出执行次数+eNodeB内异频切换出执行次数）*100%
（eNodeB间同频切换出成功次数+eNodeB间异频切换出成功次数-通过重建回源小区的eNodeB间同频切换出执行成功次数-通过重建回源小区的eNodeB间异频切换出执行成功次数）/（eNodeB间同频切换出尝试次数+eNodeB间异频切换出尝试次数）*100%
（eNodeB内同频切换出成功次数+eNodeB间同频切换出成功次数-通过重建回源小区的eNodeB间同频切换出执行成功次数-通过重建回源小区的eNodeB内同频切换出执行成功次数）/（eNodeB内同频切换出执行次数+eNodeB间同频切换出尝试次数）*100%
（eNodeB内异频切换出成功次数+eNodeB间异频切换出成功次数-通过重建回源小区的eNodeB间异频切换出执行成功次数-通过重建回源小区的eNodeB内异频切换出执行成功次数）/（eNodeB内异频切换出执行次数+eNodeB间异频切换出尝试次数）*100%
（eNodeB间同频切换出成功次数+eNodeB间异频切换出成功次数+eNodeB内同频切换出成功次数+eNodeB内异频切换出成功次数-通过重建回源小区的eNodeB间同频切换出执行成功次数-通过重建回源小区的eNodeB间异频切换出执行成功次数-通过重建回源小区的eNodeB内同频切换出执行成功次数-通过重建回源小区的eNodeB内异频切换出执行成功次数）/（eNodeB间同频切换出尝试次数+eNodeB间异频切换出尝试次数+eNodeB内同频切换出尝试次数+eNodeB内异频切换出尝试次数）*100%
3.2指标分析及统计点介绍
统计小区范围内不同原因的切换出失败的次数。
切换出失败一般发生在切换准备阶段，包括几种典型场景：
核心网问题，目标小区无响应，目标小区回复切换准备失败以及源小区发送切换取消消息。
切换准备阶段是从切换判决到切换执行之间的切换资源准备阶段。
l如图1和图2中B点所示，在S1接口切换及X2接口切换过程中的切换准备阶段，源小区收到来自MME的UECONTEXTRELEASECOMMAND消息时，指标L.HHO.Prep.FailOut.MME加1。
l如图3和图4中B点所示，在X2接口切换及S1接口切换过程中的切换准备阶段结束时，源小区未收到来自目标eNodeB的任何消息，包括如下场景：
在X2切换时，未收到对端eNodeB发出
升级会员 