LTE学习—掉话类KPI基本方法答题.docx

掉话类KPI 1.通过LST ALMAF查询站点实时告警,参考历史告警； 2.通过DSP BRD 查询单板运行情况； 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.如果确认问题后，需第三方配合解决，转发相关人员处理，做好跟踪工作，直至问题闭环。 关于掉话的定义 话统掉话的定义c 当ENodeB收到来自MME的ERAB ReleaseCommand（UE Context Release Command）消息或eNodeB向MME发送E-RAB RELEASE INDICATION（ UE CONTEXT RELEASE REQUEST ）消息，且释放原因不为“Normal Release”，“User Inactivity”，“Partial Handover”，“Handover triggered”，“successful-handover”，“cs-fallback-triggered”时统计该指标。如果E-RAB RELEASE COMMAND消息中要求同时释放多个E-RAB，则相应指标按各个业务的QCI分别进行累加。 掉话基本排查步骤 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小区资源核查基带板与主控板见小区资源核查不一致导致的用户释放