A-高掉线Top小区分析

合集下载

Volte炎强ASR无线掉话TOPN小区分析优化总结-V3

Volte炎强ASR无线掉话TOPN小区分析优化总结-V3

Volte炎强系统ASR无线掉话TOPN小区分析优化总结目录1、现状 (2)2、创新方案 (3)2.1无线原因排查流程 (3)2.2 LTE网络切换流程 (5)2.3 Mml_Xml解析工具Plus工具介绍 (6)3、S1上下文释放炎强端到端定位优化 (8)3.1[128] interrat-redirection掉话炎强端到端定位优化 (8)3.2[121]radio-connection-with -ue-lost掉话原因定位及优化 (10)3.3[101]tx2relocoverall-expiry掉话原因定位及优化 (16)4、TOPN推广效果 (23)4.1[128]interrat-redirectionTOPN优化效果推广验证 (23)4.2[121]radio-connection-with-ue-lostTOPN优化效果推广验证 (26)4.3[101]tx2relocoverall-expiry TOPN优化效果推广验证 (27)5、Esrvcc切换参数设置异常(一) (28)5.1 概述 (29)5.2 未发起eSRVCC切换原因分析 (30)5.3 参数调整方案 (31)5.4 优化效果 (32)5.5 优化总结 (34)6、Esrvcc切换参数设置异常(二) (34)6.1 问题小区描述 (34)6.2 原因分析 (35)6.3 优化调整方案 (37)6.4 效果评估 (37)6.5 总结 (40)1、现状由于现在炎强系统端到端VOLTE呼叫流程中采集了S1AP接口(除了部分由于信令丢失之外),所以可以结合端到端异常“S1错误码话单”中S1错误码进行针对性的定位分析。

结合炎强系统天粒度“指标报表下载”模板统计最近7天东莞全网ASR掉话话单,相关S1错误码分布情况:东莞全网S1上下文释放导致ASR掉话原因分布图从S1错误码分布情况来看,东莞ASR掉话记录的错误码主要以[300] normal-release、[121]radio-connection-with-ue-lost、[128]interrat-redirection为主,占比达10%以上:东莞全网S1上下文释放导致ASR掉话S1错误码占比情况2、创新方案通过近几个月对炎强ASR掉话TOPN小区优化情况进行总结,结合炎强端到端VOLTE掉话小区无线原因排查流程、切换流程,通过运用Mml_Xml解析工具Plus工具及优化切换参数(“切换RAR功率抬升”和“切换信令优化(UL)”),开展部分S1上下文释放原因的炎强系统端到端定位优化,并进行了推广验证,各项指标改善明显。

高掉线Top小区分析-大理

高掉线Top小区分析-大理
对触发重建的原因或重建被拒进行分析 对光模块或传输质量进行检查
不予处理
不予处理 不予处理 不予处理 不予处理 不予处理
4
高掉线小区处理流程
5
Context释 放,ENB重 建立失败导
致释放次数
(次)
Context释 放,ENB由 于S1链路故 障导致释放
次数(次)
Context释 放,ENB检 测到UE被异 常拔掉(次)
10
0
0
3
1
0
1
掉线率分析-- E-RAB掉线
指标名称
600版本指标公式
600版本对应Counter
无线掉线率(集团)
RRCConnectionReestablishmentRequest消息后,经过
接纳等流程,处理失败,给UE发送
RRCConnectionReestablishmentReject消息,同时触发
发S1口UE实例释放。本计数器统计这种情况发起的E-
RAB的释放个数。
归为异常释放原因
当eNodeB由于检测到S1链路故障,给MME发送UE
弥渡县城新区-ZLH(571897)
3 3.24%
1
0
2014-6-24 0:00 大理(10) 59548
大理海东大黑山-ZLH(59548)
1 3.12%
2
0
0
546
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
26
0
0
0
0
0

诺基亚LTE top小区处理意见

诺基亚LTE top小区处理意见

top小区处理意见低流量以及流量异常小区处理低流量小区是重要的KPI指标之一,指标反映了网络的移动性,指标直接影响到用户感知。

处理步骤:1. 首先核查是否为目标基站故障导致流量异常,查看当时站点的状态正常(基站是否存在故障)2. 现网核查参数等相关,发现参数设置无异常3. 与前台沟通后现场查看,无线环境正常,主覆盖区域为公路,上站检查无异常,更换光纤、光模块后观察流量依旧较低,后更换FBBA板,观察,流量恢复正常;总结:低流量以及流量异常小区优化首先排除外部干扰,基站故障等情况以外,还要针对基站相关参数、无线环境等进行进行核查,排除参数以及无线环境问题,之后利用前台实测数据分析,逐一排查问题根源,再进行处理。

零流量小区针对现场一个月的零流量小区统计情况分析,干扰、用户少、基站故障、人为调测、工程问题等都是导致零流量小区的原因:故障问题:电源:设备掉电端站,BBU掉电硬件告警:X2接口故障,系统时钟不可用,驻波等传输:传输光纤接口异常,BBU接口异常,射频R口接口异常覆盖、干扰问题:室外站点覆盖景区,景区冬季人少室外站点覆盖农村空旷公路室外站点不合理,如周围有村庄,密集人群活动区域,但天线覆盖方向不合理的.用户行为问题:活动场所:偶尔有活动,但周期比较长的。

随着季节变化,室外用户变少的.确实是用户过少的.工程原因:新建站处理故障期间,流量比较低小区未激活,导致零流量无线接通率低处理意见接入失败通常有三大类原因:无线侧参数配置问题、信道环境影响以及核心网侧配置问题。

因此遇到无法接入的情况,可以大致按以下步骤进行排查。

1.通过话统分析是否出现接入成功率低的问题,当前RRCeRAB接通率指标一般为98%,也可根据局点对接入成功率指标的特殊要求启动问题定位。

2.确认是否全网指标恶化,如果是全网指标恶化,需要检查操作,告警,是否存在网络变动和升级行为。

3.如果是部分站点指标恶化,拖累全网指标,需要寻找TOP站点。

VoLTE高掉话小区处理流程

VoLTE高掉话小区处理流程

VOLTE高掉话处理流程1. 基站告警-主要指小区存在明显的站点告警,主要影响业务告警,包含硬件、停电、断站,射频单元驻波,IPPATH,S1故障等告警;2. 隐形故障-主要指对问题点进行后台排查后,未发现明显故障,需上站检查相关硬件,计为隐性故障;3. 传输故障-主要指小区存在传输链路断链,误码率过高,传输数据配置异常等问题;4. 参数问题-主要指小区存在参数设置不合理、设置错误,参数漏配等;5. 覆盖问题-主要指小区存在弱覆盖、覆盖过远或覆盖不合理等因素;6. 内部干扰-主要指小区存在时隙配比不一致(要求同频点站点时隙配比一致)、GPS失锁、模三干扰、超远干扰;7. 外部干扰-主要指小区存在阻塞干扰、杂散干扰、互调干扰、及其他外部干扰;8. 邻区问题-新开站点邻区关系不全,不合理或未加任何邻区,影响UE小区选择或重选至不合理小区,从而影响掉线率。

9. 拥塞问题-主要指小区存在明显的资源不足,用户过多导致。

10. 核心网问题-主要指核心网数据定义不全、定义错误或网元合理化调整、功能验证等,导致指标恶化,计为核心网问题;11. 终端问题-主要指对问题点通过后台排查和现场测试,排除为所有可能无线侧因素,结合相关信令,确认为个别用户终端问题;12. 突发异常-主要指某项指标在1-2个时段突然出现恶化,然后自行恢复正常,再排查完各种可能性原因后,未发现任何异常,计为突发异常。

2、E-RAB 掉线率(QCI=1/2)-高掉话TOP 小区分析流程2、E-RAB掉线率(QCI=1/2)-高掉话TOP小区分析流程1.查询掉线类定时器设置是否正确;(T310、N311、N310、T311、T301)2.如掉线率突增,查询操作日志,确认是否有修改,导致小区异常;1. 检查小区时隙配比是否设置准确(DE:SA2\SSP7;F:SA2\SSP5);2.如每PRB 上干扰噪声平均值>-110dBm,确认小区存在上行干扰,同时可通过后台跟踪,确认干扰类型1.通过观察小区上下行丢包率是否正常,如丢包率偏高,基本断定小区存在质差;2. 通过后台QCI=1/2误码率跟踪,如BLER>1%,确定小区存在高误码;1.检查传输模式,是否为TM3,如长时间为TM2,确认设置正确的情况下,基本确定小区存在弱覆盖;2.对比64QAM 和QPSK 占比,如后者比例远大于前者,可确定小区覆盖异常;1.安排前场人员现场测试,同时后台通过信令跟踪,配合查找问题原因;2.如果确认问题后,转发相关人员处理,做好跟踪工作,直至问题闭环;1.确定目标小区运行情况,是否基站故障或异常告警;2. 检查邻区间参数设置是否正确;3.通过Mapinfo 检查小区邻区配置是否合理,进行邻区合理性优化;4.检查基站是否周边站点缺少,如为孤站,可视为正常;1.通过LST ALMAF 查询站点实时告警,参考历史告警;2.通过DSP BRD 查询单板运行情况;是否存在弱覆盖E-RAB 掉线率(QCI=1/2)高掉话TOP 小区服务小区是否存在异常告警或传输闪断,周边300米站点是否存在断站及告警SRB 达到最大重传次数导致的激活的语音业务E-RAB 异常释放次数切换流程失败导致的激活的语音业务E-RAB 异常释放eNodeB 发起的原因为无线层问题的UE Context 释放次数上行弱覆盖导致的激活的语音业务E-RAB 异常释放通过提取两两小区切换,确定目标小区参数是否设置合理是否存在高干扰是否存在高质差现场测试及后台跟踪UE Reply 超时导致的激活的语音业务E-RAB 异常释放。

LTE指标优化及TOP小区分析指导(图文详解)

LTE指标优化及TOP小区分析指导(图文详解)

1 掉线率1.1 指标定义无线掉线率=(eNodeB发起的S1 RESET导致的UE Context释放次数+UE Context异常释放次数)/UE Context建立成功总次数*100%1.2 指标分析及统计点介绍UE Context异常释放次数测量点:如图1中A点所示,当eNodeB向MME发送UE CONTEXT RELEASE REQUEST消息,会释放UE的所有E-RAB。

当释放原因不为“Normal Release”,“Detach”,“User Inactivity”,“CS Fallback triggered”,“UE Not Available for PS Service”,“Inter-RAT Redirection”,“Time Critical Handover”,“Handover Cancelled”时,测量指标L.UECNTX.AbnormRel加1。

eNodeB发起的S1 RESET导致的UE Context释放次数测量点:如图2中A点所示,当eNodeB向MME发送S1 RESET消息时,根据包含的上下文个数,指标L.UECNTX.Rel.S1Reset.eNodeB进行累加。

UE Context建立成功总次数测量点:如图3中B点所示,当eNodeB向MME发送INITIAL CONTEXT SETUP RESPONSE消息时统计该指标。

消息中如果包括多个E-RAB,该指标也只统计一次。

1.3 TOP小区分析流程TOP小区分析可通过OMC 920提取异常释放原因:□ eNodeB发起的原因为UE LOST的UE Context释放次数□ eNodeB发起的原因为切换失败的UE Context释放次数□ eNodeB发起的原因为无线层问题的UE Context释放次数□ eNodeB发起的S1 RESET导致的UE Context释放次数❶是否存在异常告警或传输闪断1)通过LST ALMAF查询站点实时告警,参考历史告警;2)通过DSP BRD 查询单板运行情况;❷通过提取两两小区切换,确定目标小区1)确定目标小区运行情况,是否基站故障或异常告警;2)检查邻区间参数设置是否正确;3)通过Mapinfo检查小区邻区配置是否合理,进行邻区合理性优化;4)检查基站是否周边站点缺少,如为孤站,可视为正常;❸检查S1链路是否配置正确现统计中eNodeB发起的S1 RESET导致的UE Context释放次数均为0,如统计出现释放次数,需进行针对排查;❹参数是否设置合理1)查询掉线类定时器设置是否正确;(T310、N311、N310、T311、T301)2)如掉线率突增,查询操作日志,确认是否有修改,导致小区异常;❺是否存在高干扰1)通过Mapinfo查看小区PCI复用是否合理,是否存在模三冲突;2)检查小区时隙配比是否设置准确(DE:SA2\SSP7;F:SA2\SSP5);3)如每PRB上干扰噪声平均值>-110dBm,确认小区存在上行干扰,同时可通过后台跟踪,确认干扰类型;小提示:判断干扰类型时,可跟踪后台干扰检测,如果RB0-RB99呈下坡图,则为杂散干扰,如果为陡升陡降则为互调干扰,如果为上坡图,则为阻塞干扰,如果干扰仅在RB40-RB80,则为广电干扰,请大家知悉。

TOP小区处理思路概述

TOP小区处理思路概述

TOP小区处理思路概述引言TOP小区是指在移动通信网络中,负载最高的小区。

由于用户数量众多,TOP小区往往会遇到网络拥塞、用户体验下降等问题。

因此,如何高效地处理TOP小区成为了运营商和网络优化工程师们的重要任务。

本文将概述处理TOP小区的思路和方法。

TOP小区的定义和影响移动通信网络中,小区是网络的基本单元,负责覆盖特定的区域,并提供无线信号覆盖。

TOP小区是指在特定时间段内,用户数占比最高的小区。

TOP小区通常具备以下特征:1.用户数众多。

2.数据业务和语音业务的同时存在。

3.用户活动密度高。

4.网络资源紧张。

TOP小区的存在会导致以下问题:1.网络拥塞和传输延迟增加。

2.用户体验下降,例如呼叫失败率增加、数据传输速度变慢等。

3.网络资源被过度消耗,导致其他小区的服务质量下降。

因此,处理TOP小区的问题对于提高网络性能和用户体验至关重要。

处理TOP小区的思路处理TOP小区的思路主要包括以下几个方面:1. 增加小区容量增加小区容量是处理TOP小区问题的关键措施之一。

通过提升小区的容量,可以增加用户并发能力,减少拥塞情况的发生。

具体的措施包括:•增加小区的载频数,扩大小区的覆盖范围。

•增加小区的天线数目,提高小区的信号覆盖强度。

•利用载波聚合技术,将多个载频进行组合,提高小区的带宽。

2. 优化小区参数配置优化小区参数配置是降低TOP小区负载压力的重要手段。

通过调整小区的参数配置,可以合理分配网络资源,提高网络效率。

具体的措施包括:•调整小区覆盖半径,优化小区边界覆盖,避免频繁的小区切换。

•调整小区的功率设置,减少干扰,提升信号质量。

•优化小区的调度策略,确保资源合理分配,提高用户传输速率。

3. 部署新的网络设备部署新的网络设备是处理TOP小区问题的另一个重要手段。

通过引入新的设备和技术,可以提升网络性能和用户体验。

具体的措施包括:•引入更先进的基站设备,提高网络容量和覆盖范围。

•部署小区干扰消除技术,减少干扰对网络性能的影响。

VOLTE高丢包TOP小区优化实践案例

VOLTE高丢包TOP小区优化实践案例

VOLTE高丢包TOP小区优化实践案例【摘要】上/下行语音丢包率是表征VOLTE语音业务的一个重要KPI,与时延、抖动作为影响VOLTE语音质量的三要素之一;监控、优化、提升上/下行语音丢包率可辅助提升VOLTE用户感知。

【关键字】VOLTE语音丢包率干扰【业务类别】VoLTE、指标、参数优化等其他一、问题描述问随着VOLTE业务全面开通,VOLTE用户数量逐渐增长,根据VoLTE语音质量定界法,无线问题是影响用户感知的最常见因素。

在定界为空口问题后,如何进一步定位具体的无线问题。

我们结合OMC统计三种支撑手段为基础,分析丢包、弃包、抖动、时延大四种影响感知的无线问题,最终定位出具体的无线原因的方法和优化流程广东省各地市指标情况:二、分析过程本文是爱立信在韶关电信无线网进行的VoLTE丢包试验和分析,重点介绍无线侧原因导致的丢包分析思路和优化策略。

影响小区高丢包的可能原因类型有如下七大类:•基站故障问题;•覆盖问题;•干扰问题;•切换参数&邻区问题;•容量问题;•重建导致;•终端问题;VoLTE语音丢包分析的思路从无线方面考虑也主要从以上的七大类方面出发,首先,需要登站查看基站是否存在故障告警之类,影响VoLTE性能相关的告警先要处理基站告警,其次是关注小区的覆盖率情况,可从MR覆盖率,现场测试验证,CTR分析覆盖等多方面来评估是否是弱覆盖引起的丢包问题,再次之就是从小区底噪排除干扰问题、切换参数、邻区配置、小区容量、传输等方面来一一排查。

2.1:相关参数介绍tReorderingDl ;This timer is used by the receiving end of Acknowledged Mode (AM) orUnacknowledged Mode (UM) Radio Link Control (RLC) entity in UE, to detect loss of downlink RLC protocol data units at lower layers.Dependencies: Not applicable for RLC TM. Only relevant when rlcMode is UM or AMChange takes effect: New connectionRange: 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 75, 80, 85, 90, 85, 100, 110, 120, 130, 140, 150, 160, 170, 180, 190, 200, Default=35tReorderingUl :This timer is used by the receiving end of the Acknowledged Mode (AM) or Unacknowledged Mode (UM) Radio Link Control (RLC) entity in eNB, to detect loss of uplink RLC protocol data units at lower layers.Dependencies: Not applicable for RLC TM. Only relevant when rlcMode is UM or AMChange takes effect: Cell lock/unlockUnit: msRange: 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 75, 80, 85, 90, 85, 100, 110, 120, 130, 140, 150, 160, 170, 180, 190, 200, Default=35三、解决措施通过丢包率TOP小区列表,发现韶关浈江莱斯大酒店_EPO_2小区丢包率较高,平均丢包率为24.76%,影响韶关丢包率;从引起丢包的原因分析,1、基站故障问题;小区无故障告警2、覆盖问题,小区MR覆盖为97.84%,不存在覆盖问题3、干扰问题;查看站点干扰情况,小区存在轻微干扰;4、切换参数&邻区问题;经参数核查站点不存在参数设置异常情况;5、容量问题;查看一周小区峰值下行PRB利用率为12.19%,不存在高负荷情况;6、重建导致;查看小区重建类指标正常;由于站点存在轻微干扰,无线环境不算非常好。

华为TOP小区处理阶段流程经验总结

华为TOP小区处理阶段流程经验总结

TOP小区处理流程总结1TOP小区处理流程及整体处理情况1.1 TOP小区分解TD-SCDMA网络系统重要的话统KPI包括CS/PS无线接通率、CS/PS无线掉线率、接力切换成功率、RNC间硬切换成功率、3G/2G互操作成功率等,针对这些KPI指标,可以通过分析、处理和解决影响这些指标的问题小区,提升和改善KPI指标。

1. 2 问题处理流程TOP小区问题处理流程中,原因分析是流程中的关键点和重点。

2无线接通率TOP小区分析处理无线接通率=RRC建立成功率*RAB建立成功率,接通率需要从RRC建立成功率和RAB 建立成功率两块进行分析。

RRC建立成功率与业务类型没有关系,RAB建立成功率则与业务类相关,需要分PS业务/CS业务进行分析。

每次RRC和RAB建立失败,话统都会输出一个失败原因统计。

2.1RRC建立失败处理2.1.1RRC建立失败原因RRC建立失败的原因可以通过RRC原因统计的细化Counter进行确定。

表3是RRC 建立失败的对应原因打点。

表4为RRC失败对应的原因分析。

表3:RRC失败原因打点表4:RRC失败对应的原因分析2.1.2RRC建立失败处理1)拥塞在RRC建立出现拥塞时,可以进行下面的操作:✓将主要业务的RRC建立在公共信道上,修改命令行为:✧主叫流媒类体RRC建立在FACH上SET RRCESTCAUSE: RRCCAUSE=ORIGSTREAMCALLEST, SIGCHTYPE=FACH;✧主叫交互类RRC建立在FACH上SET RRCESTCAUSE: RRCCAUSE=ORIGINTERCALLEST, SIGCHTYPE=FACH;✧主叫背景类RRC建立在FACH上SET RRCESTCAUSE: RRCCAUSE=ORIGBKGCALLEST, SIGCHTYPE=FACH;✧终止流媒体类RRC建立在FACH上SET RRCESTCAUSE: RRCCAUSE=TERMSTREAMCALLEST, SIGCHTYPE=FACH;✧终止交互类RRC建立在FACH上SET RRCESTCAUSE: RRCCAUSE=TERMINTERCALLEST, SIGCHTYPE=FACH;✧终止流媒体类RRC建立在FACH上RCESTCAUSE: RRCCAUSE=TERMBKGCALLEST, SIGCHTYPE=FACH;✧去附着信令承载建立在FACH上SET RRCESTCAUSE: RRCCAUSE=DETACHEST, SIGCHTYPE=FACH;✧注册登记承载在FACH上SET RRCESTCAUSE: RRCCAUSE=REGISTEST, SIGCHTYPE=FACH;✓提高拥塞小区的最小接入电平,限制部分低电平用户的接入:修改命令:MOD CELLSELRESEL: QRXLEVMIN=-96;✓打开LDC开关;✓对于业务量持续较大的小区,可以考虑建议扩容。

LTE指标优化及TOP小区分析指导图文详解

LTE指标优化及TOP小区分析指导图文详解

1 掉线率1.1 指标定义无线掉线率=(eNodeB发起的S1 RESET导致的UE Context释放次数+UE Context异常释放次数)/UE Context建立成功总次数*100%1.2 指标分析及统计点介绍UE Context异常释放次数测量点:如图1中A点所示,当eNodeB向MME发送UE CONTEXT RELEASE REQUEST消息,会释放UE的所有E-RAB。

当释放原因不为“Normal Release”,“Detach”,“User Inactivity”,“CS Fallback triggered”,“UE Not Available for PS Service”,“Inter-RAT Redirection”,“Time Critical Handover”,“Handover Cancelled”时,测量指标L.UECNTX.AbnormRel加1。

eNodeB发起的S1 RESET导致的UE Context释放次数测量点:如图2中A点所示,当eNodeB向MME发送S1 RESET消息时,根据包含的上下文个数,指标L.UECNTX.Rel.S1Reset.eNodeB进行累加。

UE Context建立成功总次数测量点:如图3中B点所示,当eNodeB向MME发送INITIAL CONTEXT SETUP RESPONSE消息时统计该指标。

消息中如果包括多个E-RAB,该指标也只统计一次。

1.3 TOP小区分析流程TOP小区分析可通过OMC 920提取异常释放原因:□ eNodeB发起的原因为UE LOST的UE Context释放次数□ eNodeB发起的原因为切换失败的UE Context释放次数□ eNodeB发起的原因为无线层问题的UE Context释放次数□ eNodeB发起的S1 RESET导致的UE Context释放次数❶是否存在异常告警或传输闪断1)通过LST ALMAF查询站点实时告警,参考历史告警;2)通过DSP BRD 查询单板运行情况;❷通过提取两两小区切换,确定目标小区1)确定目标小区运行情况,是否基站故障或异常告警;2)检查邻区间参数设置是否正确;3)通过Mapinfo检查小区邻区配置是否合理,进行邻区合理性优化;4)检查基站是否周边站点缺少,如为孤站,可视为正常;❸检查S1链路是否配置正确现统计中eNodeB发起的S1 RESET导致的UE Context释放次数均为0,如统计出现释放次数,需进行针对排查;❹参数是否设置合理1)查询掉线类定时器设置是否正确;(T310、N311、N310、T311、T301)2)如掉线率突增,查询操作日志,确认是否有修改,导致小区异常;❺是否存在高干扰1)通过Mapinfo查看小区PCI复用是否合理,是否存在模三冲突;2)检查小区时隙配比是否设置准确(DE:SA2\SSP7;F:SA2\SSP5);3)如每PRB上干扰噪声平均值>-110dBm,确认小区存在上行干扰,同时可通过后台跟踪,确认干扰类型;小提示:判断干扰类型时,可跟踪后台干扰检测,如果RB0-RB99呈下坡图,则为杂散干扰,如果为陡升陡降则为互调干扰,如果为上坡图,则为阻塞干扰,如果干扰仅在RB40-RB80,则为广电干扰,请大家知悉。

华为TOP小区处理阶段流程经验总结

华为TOP小区处理阶段流程经验总结

TOP小区处理流程总结1TOP小区处理流程及整体处理情况1.1 TOP小区分解TD-SCDMA网络系统重要的话统KPI包括CS/PS无线接通率、CS/PS无线掉线率、接力切换成功率、RNC间硬切换成功率、3G/2G互操作成功率等,针对这些KPI指标,可以通过分析、处理和解决影响这些指标的问题小区,提升和改善KPI指标。

1. 2 问题处理流程TOP小区问题处理流程中,原因分析是流程中的关键点和重点。

2无线接通率TOP小区分析处理无线接通率=RRC建立成功率*RAB建立成功率,接通率需要从RRC建立成功率和RAB建立成功率两块进行分析。

RRC建立成功率与业务类型没有关系,RAB建立成功率则与业务类相关,需要分PS业务/CS业务进行分析。

每次RRC和RAB建立失败,话统都会输出一个失败原因统计。

2.1RRC建立失败处理2.1.1RRC建立失败原因RRC建立失败的原因可以通过RRC原因统计的细化Counter进行确定。

表3是RRC建立失败的对应原因打点。

表4为RRC失败对应的原因分析。

表3:RRC失败原因打点表4:RRC失败对应的原因分析2.1.2RRC建立失败处理1)拥塞在RRC建立出现拥塞时,可以进行下面的操作:✓将主要业务的RRC建立在公共信道上,修改命令行为:✧主叫流媒类体RRC建立在FACH上SET RRCESTCAUSE: RRCCAUSE=ORIGSTREAMCALLEST, SIGCHTYPE=FACH;✧主叫交互类RRC建立在FACH上SET RRCESTCAUSE: RRCCAUSE=ORIGINTERCALLEST, SIGCHTYPE=FACH;✧主叫背景类RRC建立在FACH上SET RRCESTCAUSE: RRCCAUSE=ORIGBKGCALLEST, SIGCHTYPE=FACH;✧终止流媒体类RRC建立在FACH上SET RRCESTCAUSE: RRCCAUSE=TERMSTREAMCALLEST, SIGCHTYPE=FACH;✧终止交互类RRC建立在FACH上SET RRCESTCAUSE: RRCCAUSE=TERMINTERCALLEST, SIGCHTYPE=FACH;✧终止流媒体类RRC建立在FACH上RCESTCAUSE: RRCCAUSE=TERMBKGCALLEST, SIGCHTYPE=FACH;✧去附着信令承载建立在FACH上SET RRCESTCAUSE: RRCCAUSE=DETACHEST, SIGCHTYPE=FACH;✧注册登记承载在FACH上SET RRCESTCAUSE: RRCCAUSE=REGISTEST, SIGCHTYPE=FACH;✓提高拥塞小区的最小接入电平,限制部分低电平用户的接入:修改命令:MOD CELLSELRESEL: QRXLEVMIN=-96;✓打开LDC开关;✓对于业务量持续较大的小区,可以考虑建议扩容。

高掉线TOP小区分析

高掉线TOP小区分析

高掉线TOP小区分析一、概述提取最近一周粒度时间,无线掉线率高于2%的为高掉线小区,经过筛选总共219个为TOP高掉线小区。

TOP小区主要以农村乡下的小区分布居多,部分为城区小区和室分小区。

场景分布示意图:二、掉线分析对于TD-LTE的掉线,是在UE完成“RRCConnectionReconfigurationComplete”处于连接态,之后由于干扰、弱场、其他原因导致的UE上下行失步,触发重建未果或者被拒过程。

只要不是终端主动发起的释放,都应算为掉线。

目前掉线在信令中表现如下3种情况。

●连接态下触发RRC重建无果●连接状态下触发RRC重建被拒●连接状态下异常收到RRC释放消息常规检查:●服务小区SINR过低;●邻区列表电平相差不大,无主覆盖小区;●后台硬件告警排查,如GPS干扰、MTS中各个通道是否正常;●PCI冲突干扰;●邻区漏配;●邻区信息错误;●系统间邻区关系异常(后期检查);●问题点尝试更换不同终端检查●问题点尝试服务小区闭塞解闭塞●设备告警检查:三、掉线定位原因219个高掉线小区经过初步分析,将导致原因划分归类,后期可参考从以下方向进行排查并解决掉线。

掉线原因大类划分:解决方案:●高干扰:现场扫频确定干扰源●空口定时器超时:空口质量差导致,或定时器设置核查。

●ENB的无线链路失败:①农村乡下站点广度覆盖,信号未能连续覆盖,需进一步完善邻区关系,调整加大覆盖,或建议加站②室分站点,小区覆盖深度不足,需要增加天线补弱点,同时保证邻区关系完善③城区站点:现场调整重叠覆盖区域,降低干扰●切换成功率低:同频及异频切换成功率低,需完善邻区关系,核查PCI冲突,防止模三干扰及近距离同PCI现象。

PS:附件为萍乡详细219个高掉线小区,及分析原因。

掉线TOP小区分析.xlsx。

LTE指标优化及TOP小区分析指导(图文详解)

LTE指标优化及TOP小区分析指导(图文详解)

1 掉线率1.1 指标定义无线掉线率=(eNodeB发起的S1 RESET导致的UE Context释放次数+UE Context异常释放次数)/UE Context建立成功总次数*100%1.2 指标分析及统计点介绍UE Context异常释放次数测量点:如图1中A点所示,当eNodeB向MME发送UE CONTEXT RELEASE REQUEST消息,会释放UE的所有E-RAB。

当释放原因不为“Normal Release”,“Detach”,“User Inactivity”,“CS Fallback triggered”,“UE Not Available for PS Service”,“Inter-RAT Redirection”,“Time Critical Handover”,“Handover Cancelled”时,测量指标L.UECNTX.AbnormRel加1。

eNodeB发起的S1 RESET导致的UE Context释放次数测量点:如图2中A点所示,当eNodeB向MME发送S1 RESET消息时,根据包含的上下文个数,指标L.UECNTX.Rel.S1Reset.eNodeB进行累加。

UE Context建立成功总次数测量点:如图3中B点所示,当eNodeB向MME发送INITIAL CONTEXT SETUP RESPONSE消息时统计该指标。

消息中如果包括多个E-RAB,该指标也只统计一次。

1.3 TOP小区分析流程TOP小区分析可通过OMC 920提取异常释放原因:□ eNodeB发起的原因为UE LOST的UE Context释放次数□ eNodeB发起的原因为切换失败的UE Context释放次数□ eNodeB发起的原因为无线层问题的UE Context释放次数□ eNodeB发起的S1 RESET导致的UE Context释放次数❶是否存在异常告警或传输闪断1)通过LST ALMAF查询站点实时告警,参考历史告警;2)通过DSP BRD 查询单板运行情况;❷通过提取两两小区切换,确定目标小区1)确定目标小区运行情况,是否基站故障或异常告警;2)检查邻区间参数设置是否正确;3)通过Mapinfo检查小区邻区配置是否合理,进行邻区合理性优化;4)检查基站是否周边站点缺少,如为孤站,可视为正常;❸检查S1链路是否配置正确现统计中eNodeB发起的S1 RESET导致的UE Context释放次数均为0,如统计出现释放次数,需进行针对排查;❹参数是否设置合理1)查询掉线类定时器设置是否正确;(T310、N311、N310、T311、T301)2)如掉线率突增,查询操作日志,确认是否有修改,导致小区异常;❺是否存在高干扰1)通过Mapinfo查看小区PCI复用是否合理,是否存在模三冲突;2)检查小区时隙配比是否设置准确(DE:SA2\SSP7;F:SA2\SSP5);3)如每PRB上干扰噪声平均值>-110dBm,确认小区存在上行干扰,同时可通过后台跟踪,确认干扰类型;小提示:判断干扰类型时,可跟踪后台干扰检测,如果RB0-RB99呈下坡图,则为杂散干扰,如果为陡升陡降则为互调干扰,如果为上坡图,则为阻塞干扰,如果干扰仅在RB40-RB80,则为广电干扰,请大家知悉。

TOP小区处理

TOP小区处理

案例分析
问题分析: 1、站点故障,查看此小区无告警,无干扰。 2、23G切换参数配置问题。按集团公司要求,因GT分流,23G切换参 数基本固定在某个范围,可改动的范围较小。查看该小区后台参数配置 符合集团公司要求,排除了人为改动造成指标较差的原因。 3、目标GSM小区存在告警、干扰或者拥塞。GSM目标小区的性能也 会影响到23G切换成功率,如干扰导致终端无法解析GSM系统消息; 提取此小区切换counter,此小区向周围GSM邻区切换均失败较多,排 除单个GSM邻区故障原因导致。
案例分析
原因查找及分析:统计RAB释放counter,RAB建立失败的原因值主要为
IU.NbrRabPsRelIuConnPerCell.14(Failure in the Radio Interface Procedure),即无线接口协议失败。
对发生掉线的载波进行统计
案例分析
发生掉线的情况主要集中在该小区的F频点(9476、9482、9492),针对 上述情况,后台通过LMT_R对这两个小区的载波上行干扰情况进行跟踪
案例分析
【问题总结】 通过以上测试分析,发现在目前情况下,TD所使用的F频段与小灵通系统 使用的频段比较接近,导致小灵通系统对TD产生一定程度的干扰。所以在 后期扩容中,必须考虑小灵通系统的影响,优先使用A频段,同时推进小 灵通退网。
案例分析
案例二:TOP用户造成PS 32G切换较差
问题描述:11月19日,沙门西南5PS3G-2G切换失败次数较多, 成为TOP小区,影响了全网指标情况。可以看出沙门西南5小区18 日失败次数为217次,对指标冲击较大。

案例分析
【处理措施】:对此用户IMEITAC:35179205的PS3-2G的切换 进行限制。观察指标

诺基亚LTE top小区处理意见

诺基亚LTE top小区处理意见

top小区处理意见低流量以及流量异常小区处理低流量小区是重要的KPI指标之一,指标反映了网络的移动性,指标直接影响到用户感知。

处理步骤:1. 首先核查是否为目标基站故障导致流量异常,查看当时站点的状态正常(基站是否存在故障)2. 现网核查参数等相关,发现参数设置无异常3. 与前台沟通后现场查看,无线环境正常,主覆盖区域为公路,上站检查无异常,更换光纤、光模块后观察流量依旧较低,后更换FBBA板,观察,流量恢复正常;总结:低流量以及流量异常小区优化首先排除外部干扰,基站故障等情况以外,还要针对基站相关参数、无线环境等进行进行核查,排除参数以及无线环境问题,之后利用前台实测数据分析,逐一排查问题根源,再进行处理。

零流量小区针对现场一个月的零流量小区统计情况分析,干扰、用户少、基站故障、人为调测、工程问题等都是导致零流量小区的原因:故障问题:电源:设备掉电端站,BBU掉电硬件告警:X2接口故障,系统时钟不可用,驻波等传输:传输光纤接口异常,BBU接口异常,射频R口接口异常覆盖、干扰问题:室外站点覆盖景区,景区冬季人少室外站点覆盖农村空旷公路室外站点不合理,如周围有村庄,密集人群活动区域,但天线覆盖方向不合理的.用户行为问题:活动场所:偶尔有活动,但周期比较长的。

随着季节变化,室外用户变少的.确实是用户过少的.工程原因:新建站处理故障期间,流量比较低小区未激活,导致零流量无线接通率低处理意见接入失败通常有三大类原因:无线侧参数配置问题、信道环境影响以及核心网侧配置问题。

因此遇到无法接入的情况,可以大致按以下步骤进行排查。

1.通过话统分析是否出现接入成功率低的问题,当前RRCeRAB接通率指标一般为98%,也可根据局点对接入成功率指标的特殊要求启动问题定位。

2.确认是否全网指标恶化,如果是全网指标恶化,需要检查操作,告警,是否存在网络变动和升级行为。

3.如果是部分站点指标恶化,拖累全网指标,需要寻找TOP站点。

VOLTE掉话分析

VOLTE掉话分析

TOP筛选条件◆当日掉话次数大于3次为TOP小区◆一周内出现3次TOP小区为高掉话TOP小区TOP分析方法手段掉话问题掉话原因分析➢按照掉话分子,按原因值提取相关计数器进行分析;➢检查站点是否存在邻区漏配或者配置不合理,导致无法及时切换出而吊死,引发掉线;➢小区存在异频邻区时,需要核查异频切换类相关A2、A3配置门限是否合理;➢检查小区是否存在超远覆盖,导致覆盖孤岛,无法及时切换到周边基站,可通过后台信令跟踪,观察测量报告,补齐漏配的邻区,随后及时对覆盖进行控制;➢对于弱覆盖引起的掉线,若终端处于覆盖边缘,周围无可用LTE小区,可以合理添加异系统邻区,合理配置重定门限,及时重定向到异系统,减少掉线。

➢关注小区无线环境,分析是否NI过高;➢关注影响业务的故障类告警;掉话Context归类如下:●ENB由于S1链路故障发起释放分为三类◆Context释放,Gtpu ErrInd触发释放:主要是核心网参数问题,部分原因是TAC边界不和导致,可以优化TAC边界◆Context释放,Path故障触发释放:传输故障导致,需核查传输◆Context释放,光口故障触发释放:光口、S1链路故障等原因,推维护处理●Context释放,ENB切换失败引发释放:检查切换参数、功率参数、定时器设置;●Context释放,由于小区关断或复位引发释放:检查掉线对应时间段内基站小区故障类告警●Context释放,ENB由于其他原因引发释放:容量等其他问题;●Context释放,ENB重建立失败导致释放:检查小区NI是否过高,RS功率设置是否偏小,检查现场无线环境,开启X2口进行优化(重建立如果在目标基站没有上下文,重建肯定失败);●ENB空口失败引发释放次数分四类◆ERAB释放,空口定时器超时:检查CPU负荷,同时在线用户数是否偏高,如是可增加SR信道配置容量进行优化,排除MR开启时间段内计时器增多,提故障交研发处理;◆ERAB释放,空口质量差触发RLF:检查无线环境是否存在弱覆盖、模三干扰、越区覆盖、底噪偏高、基站存在故障;◆ERAB释放和RLC达到最大重传次数:检查RLC参数设置,排除MR开启时间段内计时器增多,提故障交研发处理;◆ERAB释放,PDCP完整性保护失败:检查加密完保参数设置,排除MR开启时间段内计时器增多,提故障交研发处理;Context整理情况如下:切换问题:切换分为切换准备阶段和切换执行阶段切换准备阶段多由外部邻区参数配置错误(邻区配置正确)或者切换准备目标基站故障引起。

五高一低一弱问题小区整治经验材料

五高一低一弱问题小区整治经验材料

五高一低优化总结—低话务小区
低话务小区现状: 优化前杭州有超低话务小区199个,通过话务均衡等手段有 134个小区已经恢复,现网低话务小区数目为65个: 超低话务小区比例从优化前6.03%下降到1.87%。
•通过调整小区层级、重选、边缘层间切换门限、功 250 200 150 6.03% 7.00% 6.00% 5.00% 4.00% 3.00% 1.87% 2.00% 1.00% 0.00%
责任到人
四结合:
参数优化和
硬件维护相
结合 图纸平台与 后台分析和 现场测试相
三点
闭环管理
实际优化相
结合
依据可实 施性,严 控处理周 期
四结合
网络指标与 规划建设相 结合
结合
五班组
室分组 主管:楼喆午 组长:郭嘉
优化分析组 靳少伟
现场测试组 金小鹏
维护组 蔡海燕
硬件排障组 王科炜
规划组 吴佳
目录
1 2
100
50 0
参数优化
率参数及邻区合理吸收小区覆盖区域的语音话务; •通过调整PS域参数,优化低话务小区数据业务,
优化前
超低话务小区数目
优化后
超低话务小区占比
提升等效数据业务。
• 建立低话务小区故障跟踪处理机制,及
故障排除
时发现和处理由于故障导致低话务的小 区。 • 建立常态化的话务跟踪机制, 对业务波动小区及时进行配置 调整。
27.56% 14.93% 14.67% 14.05% 12.47% 16.32%
有源器件故障 无源器件故障 邻区和参数设置不合 理 弱覆盖 PB值偏高或偏低
通过及时跟踪处理高掉话TOP
小区,室分高掉话小区改善明显, 指标由2011年高掉话专项开始时的 2.0%提升并稳定至当前的0.8%以 下。

A-LTE掉线率指标优化指导

A-LTE掉线率指标优化指导

TD-LTE掉线率指标优化指导1.1指标定义无线掉线率=(eNB请求释放上下文数-正常的eNB请求释放上下文数)/初始上下文建立成功次数*100%1.2日常KPI监控流程1.3掉线counter和分析●采样点1:eNodeB发送UE Context ReleaseRequest消息给MME,采样统计。

●采样点2:eNodeB接收到从MME来的UE Context ReleaseCommand消息,采样统计。

●采样点3:eNodeB接收到从MME来的RESET消息,采样统计。

●采样点4:eNodeB接收到从MME来的Error Indication消息,采样统计。

●采样点1:eNodeB接收到从MME来的E-RAB RELEASE COMMAND消息,采样统计。

●采样点2:eNodeB发送E-RAB RELEASE RESPONSE消息给MME,采样统计。

●采样点3:eNodeB发送E-RAB RELEASE INDICATION消息给MME,采样统计。

●采样点4:eNodeB发送UE Context ReleaseRequest消息给MME,采样统计。

●采样点5:eNodeB接收到从MME来的UE Context ReleaseCommand消息,采样统计。

●采样点6:eNodeB接收到从MME来的RESET消息,采样统计。

●采样点7:eNodeB接收到从MME来的Error Indication消息,采样统计1.3.3掉线率处理思路●按照掉线率分子,提取细分原因的计数器,查看由那类计数器引起的失败次数最多,针对性处理。

●正常情况下,某个小区周边都存在邻区,如果无线环境不是很差,都可以通过切换的方式改变服务小区。

当某个站点缺失邻区或者邻区添加不合理,会导致无法切换出而掉死。

因此处理掉线率较高的小区时,需要核查邻区配置是否合理。

●小区存在异频邻区时,需核查异频切换类参数是否配置合理,A2,A3事件配置●核查小区是否存在超远覆盖,导致覆盖孤岛,无法切换到周边邻区。

第十一课:TOP小区分析及案例

第十一课:TOP小区分析及案例
TOP小区的分析筛选
TOP小区常见分类
成都TOP小区的分类 HQI类 掉话类 干扰类 呼叫类 切换类 拥塞类
TOP小区筛选门限
取6忙时指标平均值。 (每线话务量>0.1) BSS呼叫建立成功率 呼叫建立成功率(%)<80%;小区级切换成 呼叫建立成功率 小区级切换成 功率(%)<80%;TCH上行HQI<80; TCH下行HQI<80;TCH拥塞率(含切换)(%)>5%;TCH掉话 功率 率(含切换)(%)>2%;SDCCH拥塞率(%)>3%;SDCCH掉话率>2%andSDCCH掉话次数>500; 出BSC切换成功率<80%and出BSC切换请求次数>200;入BSC切换成功率<80%and入BSC 切换请求次数>200
20
案例分析之一
12月7日话统
小区名称 电力公司-1 电力公司-2 电力公司-3 博乐建行-3 三金粮油-2 三金粮油-3 工业区-2 博乐六中-1 博乐六中-2 博乐六中-3 兴博市场-3 无线切换 切换成功率 成功率 86.58% 93.09% 95.57% 86.84% 88.43% 92.56% 89.47% 93.69% 93.55% 97.40% 91.80% 95.90% 96.88% 96.79% 95.94% 91.51% 94.12% 89.47% 95.59% 93.55% 97.45% 96.89% BSC内入小区切 BSC内入小区 换失败次数 切换失败次 TCH拥塞率 (无可用信道) 数(其他) 47 10 13 10 15 3.4 0 10 0 80 7 18.26 1 21 0.48 0 6 0 0 1 0 1 6 1.44 0 2 0 0 1 0 10 1 7.92
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

E-RAB掉线原因主要集中在: Enodeb无线链路失败占72.43%, Enodeb重建立失败占21.43%。具 体失败情况如下所示:
E-RAB释 放次数, 由于ENB 其他异常 原因(个) 0 E-RAB释 放次数, 由于ENB 小区拥塞 导致的释 放(个) 0 E-RAB释 放次数, 由于UE 切换失败 ( 个) 0 E-RAB释 E-RAB释 放次数, 放次数, 由于ENB 由于ENB 的无线链 重建立失 路失败(个) 败(个) 10 3 E-RAB释 放次数, ENB由于 S1链路故 障发起释 放(个) 1
E-RAB释放次数,由于ENB其他异常原因(个) E-RAB释放次数,由于ENB小区拥塞导致的释放(个) E-RAB释放次数,由于UE切换失败(个) E-RAB释放次数,由于ENB的无线链路失败(个)
产品和协议都没有明确界定的原因,具体分析 进行负荷均衡优化处理或容量规划 对切换进行分析优化
从无线覆盖、干扰、硬件问题等角度分析
2014பைடு நூலகம்6-24 0:00
2014-6-24 0:00 2014-6-24 0:00
大理(10)
大理(10) 大理(10)
571791
571897 59548
大理江尾河尾-ZLH(571791)
弥渡县城新区-ZLH(571897) 大理海东大黑山-ZLH(59548)
2
3 1
3.38%
3.24% 3.12%
开始时间
子网名称
网元
网元名称
2014-6-24 0:00 2014-6-24 0:00 2014-6-24 0:00 2014-6-24 0:00 2014-6-24 0:00 2014-6-24 0:00 2014-6-24 0:00
大理(10) 大理(10) 大理(10) 大理(10) 大理(10) 大理(10) 大理(10)
从终端侧进行分析
不予处理
不予处理
不予处理 不予处理
3
掉线原因
Cause E-RAB掉线率(集团) 含义及统计点 说明 处理方案 eNodeB除列出的原因外的原因,导致给MME发送ERAB RELEASE INDICATION消息,触发E-RAB释放。 本计数器统计此种情况下释放的E-RAB个数。 归为异常释放原因 当eNodeB由于检测到小区拥塞,给MME发送E-RAB RELEASE INDICATION消息计数器加1。 归为异常释放原因 当eNodeB由于切换失败,触发一个E-RAB释放时,计数 器加1。 归为异常释放原因 当eNodeB由于无线链路失败,给MME发送E-RAB RELEASE INDICATION消息,消息中的IE:E-RAB To Be Released List,每个E-RAB时,计数器加1。 归为异常释放原因 当eNodeB接收到从UE来的 RRCConnectionReestablishmentRequest消息后,经过 接纳等流程,处理失败,给UE发送 RRCConnectionReestablishmentReject消息,同时触发 发S1口UE实例释放。本计数器统计这种情况发起的ERAB的释放个数。 归为异常释放原因 当eNodeB由于检测到S1链路故障,给MME发送UE CONTEXT RELEASE REQUEST消息,每个E-RAB计 数器加1。 归为异常释放原因 当当eNodeB“负荷控制开关”打开时,eNodeB由于检 测到业务过载,给MME发送E-RAB RELEASE INDICATION消息,消息中的IE:E-RAB To Be Released List,每个E-RAB计数器加n。 现归为正常释放原因 在eNodeB的“启用USER INACTIVITY功能”开关打开 前提下,当eNodeB检测到UE的上行和下行承载在配置 的阈值时间内,都没有数据时,会触发UE释放流程。本 计数器统计这种情况发起的E-RAB的释放个数。 现归为正常释放原因 当eNodeB由于小区闭塞或者复位,给MME发送UE CONTEXT RELEASE REQUEST消息,每个E-RAB计 数器加1。 现归为正常释放原因 当eNodeB由于UE重定向,给MME发送UE CONTEXT RELEASE REQUEST消息,释放UE下所有的E-RAB。 本计数器统计此种情况发起的E_RAB释放次数。 现归为正常释放原因 当eNodeB由于CCO过程,给MME发送给MME发送UE CONTEXT RELEASE REQUEST消息,每个E-RAB计 数器加1 现归为正常释放原因 当eNodeB由于检测到UE不在线,给MME发送UE CONTEXT RELEASE REQUEST消息时,本计数器统 计此种情况发起的E-RAB释放次数。 现归为正常释放原因
571513 571885 59651 59558 59496 571750 571513
大理古城南城门停车场-ZLH(571513) 祥云国税局-ZLH(571885) 剑川宝相寺-ZLH(59651) 大理挖色冬瓜箐-ZLH(59558) 大理海东天镜阁二-ZLH(59496) 宾川航凯宾馆-ZLH(571750) 大理古城南城门停车场-ZLH(571513)
([[TDD]eNB请求释放的按业务类型分类的E-RAB数目]-[[TDD]正常的eNB请求 (P311173E-RAB掉线率(集团) 释放的E-RAB数目]+[[TDD]E-RAB切换出失败次数(个)])/([当前ERAB个数 P311438+C373210541)/(C373240828+C373505473+C373505481) (个)]+[初始的E-RAB建立成功次数(个)]+[增加的E-RAB建立成功次数(个)])
E-RAB释放次数,由于ENB重建立失败(个) E-RAB释放次数,ENB由于S1链路故障发起释放(个)
对触发重建的原因或重建被拒进行分析
对光模块或传输质量进行检查
E-RAB释放次数,由于ENB过载控制导致的释放(个)
不予处理
E-RAB释放次数,由于ENB的UserInactive(个) E-RAB释放次数,由于小区关断或复位(个) E-RAB释放次数,由于ENB重定向导致释放(个) E-RAB释放次数,ENB由于CCO原因发起释放(个) E-RAB释放次数,由于UE不在线导致释放(个)
Context释放,ENB空口失败引发释放次数(次)
从无线覆盖、干扰、硬件问题等角度分析
Context释放,ENB切换失败引发释放次数(次)
对切换进行分析优化
Context释放,ENB由于其它原因引发释放次数(次) Context释放,ENB重建立失败导致释放次数(次)
产品和协议都没有明确界定的原因,具体分 析
无线掉线率TOP10分析—中兴Counter
各原因值小区统计 10 0 0 3 1 0 Context释放, Context释放,Context释放, Context释放, Context释放, Context释放, 无线掉线 ENB空口失败 ENB切换失败 ENB由于其它原 ENB重建立失 ENB由于S1链 ENB检测到UE 小区 率(集团) 引发释放次数 引发释放次 因引发释放次 败导致释放次 路故障导致 被异常拔掉 (次) 数(次) 数(次) 数(次) 释放次数(次) ( 次) 3 2 1 2 2 1 1 25.27% 17.65% 9.09% 7.23% 3.97% 3.81% 3.41% 61 3 1 6 4 89 44 0 0 0 0 0 0 0 0 0 0 0 0 0 0 546 0 0 0 1 0 26 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2
掉线原因
Cause 无线掉线率(集团) 含义及统计点 说明 当eNodeB由于RRC重建立或者RRC重配过程中, 等待RRC重建立完成或者RRC重配完成定时器超 时,给MME发送UE CONTEXT RELEASE REQUEST消息时,计数器加1。 归为异常释放原因 当eNodeB的UE在切换执行阶段,由于目标侧发 生RRC连接重建立,或者RRC连接重配完成定时 器超时等等原因,导致UE释放时,本计数器采样 统计。当eNodeB由于切换失败,给MME发送UE CONTEXT RELEASE REQUEST消息时,计数 器加1。 归为异常释放原因 当eNodeB除所列原因外的其它原因(主要指内部 原因),给MME发送UE CONTEXT RELEASE REQUEST消息,触发UE释放。本计数器统计此 原因释放的UE上下文次数。 归为异常释放原因 当eNodeB由于重建立失败,给MME发送UE CONTEXT RELEASE REQUEST消息时,计数 器加1。 归为异常释放原因 当eNodeB检测到S1的光口故障或者GTPU层检测 到Path(eNodeB和SGW业务通路)故障,触发 UE释放。当eNodeB由于检测到S1口故障,给 MME发送UE CONTEXT RELEASE REQUEST消息时,计数器加1。 归为异常释放原因 eNodeB根据MAC层的HARQ反馈情况,判断UE 的状态。如果一个UE的所有HARQ反馈情况不好, 则认为UE不在线或者状态不好,触发发起UE释 放。当eNodeB检测到UE不在线,给MME发送UE CONTEXT RELEASE REQUEST消息时,计数 器加1。 归为异常释放原因 当eNodeB由于UE重定向到别的小区,给MME发 送UE CONTEXT RELEASE REQUEST消息时, 计数器加1。 现归为正常释放原因 当eNodeB接收到小区闭塞命令,或者由于Reset ,给MME发送UE CONTEXT RELEASE REQUEST消息时,计数器加1。 现归为正常释放原因 当eNodeB由于检测到UE没有业务,给MME发送 UE CONTEXT RELEASE REQUEST消息时,计 数器加1。 现归为正常释放原因 当eNodeB由于UE发生CCO,导致在源小区发起 的UE上下文释放时,计数器加1。 现归为正常释放原因 问题处理关注对象
相关文档
最新文档