LTE学习总结—掉话类KPI基本分析方法

掉话类KPI1.通过LSTALMAF查询站点实时告警,参考历史告警；2.通过DSPBRD查询单板运行情况；3.提取两两小区切换，确定目标小区：A.确定目标小区运行情况，是否基站故障或异常告警；B.检查邻区间参数设置是否正确；C.通过Mapinfo检查小区邻区配置是否合理，进行邻区合理性优化；D.检查基站是否周边站点缺少，如为孤站，可视为正常；4.检查参数设置是否合理：A.查询掉线类定时器设置是否正确；（T310、N311、N310、T311、T301）.如掉线率突增，B.查询操作日志，确认是否有修改，导致小区异常；5.检查是否存在干扰：A.通过Mapinfo查看小区PCI复用是否合理，是否存在模三冲突；B.检查小区时隙配比是否设置准确（室分:SA2\SSP7;宏站:SA2\SSP5）；C.如每PRB上干扰噪声平均值-110dBm,确认小区存在上行干扰，同时可通过后台跟踪，确认干扰类型；6.是否存在高质差：A.通过观察小区上下行丢包率是否正常，如丢包率偏高，基本断定小区存在质差；B.通过后台误码率跟踪，如BLER10%，确定小区存在高误码；7.是否存在弱覆盖：A.检查传输模式，是否为TM3，如长时间为TM2，确认设置正确的情况下，基本确定小区存在弱覆盖；B.对比64QAM和QPSK占比，如后者比例远大于前者,可确定小区覆盖异常；8.现场测试及后台跟踪：A.安排前场人员现场测试，同时后台通过信令跟踪，配合查找问题原因；B.如果确认问题后，需第三方配合解决，转发相关人员处理，做好跟踪工作，直至问题闭环。1、关于掉话的定义话统掉话的定义c当ENodeB收到来自MME的ERABReleaseCommand（UEContextReleaseCommand）消息或eNodeB向MME发送E-RABRELEASEINDICATION（UECONTEXTRELEASEREQUEST）消息，且释放原因不为“NormalRelease”，“UserInactivity”，“PartialHandover”，“Handovertriggered”，“successful-handover”，“cs-fallback-triggered”时统计该指标。如果E-RABRELEASECOMMAND消息中要求同时释放多个E-RAB，则相应指标按各个业务的QCI分别进行累加。2、掉话基本排查步骤2.1、基本排查首先需要在话统侧获取全网的掉话率指标以及趋势，掉话率趋势分析至少1到2周的数据，如果掉话率指标突然偏高，一般执行步骤：是否全网问题对全网MME及eNodeB侧进行告警核查（传输，设备等告警），观察期间是否实施版本升级是否存在Top小区：小区级的掉话率指标和掉话绝对次数按从高到低的顺序进行排序，优先分析掉话绝对次数多而且掉话率高的Top小区对Top小区进行参数核查、告警检查等对引起掉话的Top原因进行定位分析若是共性问题，将优化结果复制到全网参数对比随机抽取部分站点的脚本与基线参数进行核对，对不一致的参数进行分析；告警核查是否存在传输告警：观察S1传输是否出现问题；是否存在设备告警：观察eNB侧是否存在告警；检查系统是否升级、打补丁等动作；小区筛查将小区级的掉话率指标和掉话绝对次数按从高到低的顺序进行排序，优先分析掉话绝对次数多且掉话率高的Top小区；通常取每天掉话率高于平均指标的Top5小区进行分析，确定掉话的主要原因；2.2、掉话问题分析规定动作获取小区级话统掉话率指标及趋势，掉话率趋势至少分析1到2周数据如果小区的掉话率指标突然偏高，需要核查ENB侧是否存在该小区的相关告警信息，检测该小区所属ENodeB的相关告警，确认该小区是否存在故障分析CHR数据，获取导致掉话的各种原因的比例，按照比例从高到低的顺序分别针对不同的问题原因进行定位，并针对各TOP原因进行分析处理判断是否存在OM操作导致的站点复位，重启等导致的掉话，检测是否有TOP用户存在，如果有，需要对TOP用户的数据进行针对分析如果无法通过CHR数据定位解决问题，通过抓取该小区ENodeB侧IFTS跟踪如果无法进行深一步分析在需要使用测试终端进行复现，并抓取UE侧LOG和内部打印信息进行进一步定位2.3、CHR原因统计取每天的Top5站点通过InsightSharp对CHR数据进行分析，找到影响每个Top小区掉话率的主要原因：CHR常见释放原因编号CHR打点内部RelCause中文解释含义1UEM_UECNT_REL_AUDIT_CELLM_RELEASE小区资源核查基带板与主控板见小区资源核查不一致导致的用户释放2UEM_UECNT_REL_HO_OUT_X2_REL_BACK_FAILX2切换目标侧失败X2切换过程中，源小区侧没有收到正常释放UE_CONTEXT_REL消息，原因可能是：1、PATHSWITCH处理失败（包括以下几种情况：pathswitch消息没有发送出去，或者收到pathswitchfailure或者处理pathswitch过程失败）2、在SNSTATUS尚未处理完毕的情况下，收到重建请求3、没有收到切换完成也没有收到重建请求4、收到重建请求，但是重建过程失败(除了2以外的情况)3UEM_UECNT_REL_RB_RECFG_FAILRB重配置失败1、核心网下发erabmod流程涉及的空口重配置失败2、算法流程涉及的空口重配置失败（包括MIMO，CQI，DRX，PUCCH资源以及其他）3、小区内切换涉及的空口重配置失败（TTIbudding触发，ROHC，MME下发的安全模式修改）4UEM_UECNT_REL_RRC_REEST_OTHER_RB_RESTORE_FAILotherRB恢复失败一般重建完成有5条消息（3条Reestablishment及2条重建重配置），在最后两条消息处理过程中发送了重建过程中的SRB/DRB重配置但是没有收到重配置完成。5UEM_UECNT_REL_RRC_REEST_SRB1_FAIL重建失败重建SRB1失败，一般可以细化为以下几个场景1、连续多次收到重建请求2、安全校验失败3、多场景交叉情况下，如果当前场景不支持重建，也是重建拒绝6UEM_UECNT_REL_SAE_BEARER_REL_NUM_MAX释放承载个数达到最大请求释放的SAEBearer数目和已建立的SAEBearer数目相同1、传输链路异常原因2、重传达到最大次数，并且等待长时间之后UE不重建3、其他（一般不会出现）7UEM_UECNT_REL_SCTP_ABORT传输IPPATH异常IPPATH由于资源不足或者是过载出现异常时8UEM_UECNT_REL_UE_RESYNC_TIMEROUT_REL_CAUSEUE重同步定时器超时L2上报重同步定时器超时导致的用户释放9UEM_UECNT_REL_WAIT_RRC_CONN_RECFG_RSP_TIMEOUT测量控制重配置失败测量控制重配置失败10UEM_UECNT_REL_S1_UESR_ABORTS1接口用户面异常S1链路锻链或者是IPPATH异常导致的用户释放11UEM_UECNT_REL_UE_RLC_UNRESTORE_INDL2上报RLC重传次数达到最大值时的无法恢复指示消息SRB达到最大重传次数12UEM_UECNT_REL_AUDIT_S1ITF_RELEASES1接口核查释放与S1接口核查结果不一致的场景下释放用户2.4、TOP用户排查2.4.1、Top用户的确定Top用户的判断主要是依据终端接入时上报的TMSI进行判定，华为核心网TMSI分配的机制是对于同一个IMSI用户，TMSI的右起第5位进行随机赋值，即某用户的TMSI中只有*指示的8bits位置发生变化，就是同一个用户，C06*0005；TMSI可以通过CHR数据分析获取：2.4.2、Top用户log分析Step1：分析是否存在同频邻小区漏配或者错配导致的掉话；Step2：分析是否存在弱覆盖导致的掉话；Step3：分析是否由于切换来不及导致的掉话；Step4：分析是否导频污染引起的掉话：Step5：分析是否存在上行干扰导致的掉话：如果掉话原因不是步骤1~5所述的原因，则很有可能是非RF原因导致的掉话，需要结合IFTS信息进一步定位；如果是异常导致的掉话，则需要结合一键式日志、TTI跟踪等信息进行异常定位。2.4.3、Top用户隔离定位输入数据eNBIFTS跟踪UETTI跟踪UE侧路测logeNB表口log一键式日志CHR日志2.4.5、Top用户掉话分析四步曲Step1：标口流程分析谁主动发起释放eNB主动发起释放eNB主动向核心网发起释放请求，收到核心网下发的释放命令后释放用户RRCConnRel、并向核心网反馈释放完成核心网主动发起释放eNB收到核心网下发的释放命令，释放用户RRCConnRel、并向核心网反馈释放完成Step2：通过S1释放请求/命令中的释放原因值隔离掉话原因无线侧原因触发释放传输原因触发释放NAS原因触发释放协议原因触发释放其他混合原因触发释放Step3：CHR分析详细释放原因Step4：复现问题抓取IFTS跟踪、UE侧Log，深度定位掉话根因