Y省B局点核心网GUTP传输通道配置问题导致无线掉线率升高
- 格式:doc
- 大小:2.74 MB
- 文档页数:15
无线主要问题及改进措施1.无线连接速率下降无线网络设备能够智能调整传输速率,以适应无线信号强度的变化,保证无线网络的畅通。
但是,如果连续一段时间内网络连接速度低于2Mb/s,那就说明网络可能出现了故障,可以进行以下操作,以恢复原有的传输速率:01.查看是否开启了无线网卡的节电模式。
在采用节电模式时,无线网卡的发射功率将大大下降,导致无线信号减弱,从而影响无线网络的传输速率;02.查看是否在无线设备之间有遮挡物。
如果在无线网卡之间,或者无线网卡与无线AP之间有遮挡物,特别是金属遮挡物,将严重影响无线信号的传输。
建议将无线AP置于房间内较高的位置,使之与无线网卡相互可视;03.查看是否有其它干扰设备。
微波炉、无绳电话等与无线网络频率相近的设备,会对无线传输产生较大的干扰,导致通信速率下降。
大多数微波炉使用了2.4GHz频段上14个信道中的7~11个信道,所以对于采用802.11b协议的无线设备,只要将通信信道固定为14(最后一个信道)即可。
2.无线网络不能接收数据如果将无线AP连接至无线路由器时一切正常,可实现无线网络的Internet连接共享,说明无线AP的硬件与设置没有问题。
既然不能接收数据,表明没有能够正确与网络建立连接,导致该故障的原因可能出现在无线AP与交换机的连接上。
如果交换机支持智能端口,可以判断对端所连接的设备,并自动完成端口方式切换。
否则,就应当使用指定的跳线连接无线AP与交换机。
通常情况下,网络设备之间的连接应当使用交叉线。
因此,建议使用交叉线连接无线AP与交换机,测试故障是否解决。
3.无线AP不能连接太多设备虽然从理论上来讲,一个无线AP或者无线路由器能够同时支持256个Wi-Fi连接。
但是,从实践经验来看,一旦有超过10个客户端在使用同一个接入点,其性能将会迅速减弱。
无线AP与无线路由从某种意义上与集线器非常相似,也是由所有接入用户共享带宽。
因此,随着接入用户数量的增加,可用带宽迅速减少,从而导致网络传输速率大幅下降。
无线路由器掉线解决方法3、广播风暴内网的广播风暴导致。
解决思路:产生广播风暴的原因包括:网络中存在着故障网卡、网络环路、不良的线路,如线序标准及线的质量等,或一些产生广播的应用程序及网络协议等。
解决的办法就是检查有线网络的布设情况,进行相应的IP设定。
4、设备过热设备散热不良,刚上网时正常,过一会网速下降,如果用手摸设备很烫。
解决思路:低价无线路由器大多为塑壳,散热性不如铁壳。
只有加强外部散热,不要将设备叠加在一起使用。
AP或路由器缓存过小,带机过多、有电脑一直在进行BT下载也会引起这类问题,可减少带机数和停止P2P下载看看。
5、信道冲突有多个无线设备使用了相同的信道。
解决思路:常用的IEEE 802.11b/g工作在2.4~2.4835GHz频段,这些频段被分为11或13个信道,如果两个以上的无线设备同时使用一个信道进行通讯,便有可能造成带宽拥塞或互相干扰,造成掉线。
IEEE802.11b/g标准其都只支持3个不重叠的传输信道信道,只有信道1、6、11或13是不冲突的,但使用信道3的设备会干扰1和6,使用信道9的设备会干扰6和13……。
解决的办法是在无线路由器设置界面中更改为不常用的无线信道,分别采用1、6、11不同的信道,以减少冲突。
6、信号原因无线信号强度不够,连接距离过远。
解决思路:可在Windows XP或无线网卡配置程序中查看无线信号强度,如果无线信号强度太低,就可断定信号状态不好。
确保无线路由器摆放在周围不能有障碍物或过多障碍物(如墙层太多)的地方,这样的话它与无线网卡之间的通信信号就不会被障碍物阻挡或干扰,而且通信信号还能传输得更远一些;此外,可调整无线路由器或无线网卡的位置及天线角度试试,架设外接增益天线是较好的解决方案;拿开或关闭其他能够干扰无线信号的设备,如手机、微波炉或无线音箱等等。
7、兼容性问题无线设备间或与操作系统间出现兼容问题引其掉线。
解决思路:遇到不明原因的故障除了要考虑上述的部分软件故障以外还要检查硬件部分的接触是否良好,例如可能是灰尘屏蔽了网卡上的金手指造成无线网卡工作不正常,可用橡皮擦清洗一下,或重新换个槽再插以确认一下是不是可以正常使用。
5G NSA 异常掉线率优化提升XX目录5G NSA 异常掉线率优化提升 (3)一、问题描述 (3)二、分析过程 (3)2.1基本原理 (3)2.1.15G 组网方式 (3)2.1.2掉话指标定义 (7)2.2掉话率排查思路 (8)2.2.1指标分析 (9)2.2.2告警排查 (10)2.2.3参数核查 (11)2.2.4误码率高排查 (11)2.2.5覆盖和干扰排查 (12)2.2.6邻区核查 (15)2.2.7日志解析 (16)三、解决措施 (18)3.1基站故障问题处理 (18)3.2参数配置问题优化 (21)3.3异常小区处理 (26)3.3.1邻区配置问题切换失败导致掉线 (26)3.3.2NR 覆盖问题导致的掉线 (29)四、经验总结 (30)5G NSA 异常掉线率优化提升XX【摘要】5G 网络商用临近,站点开通规模增加,打造 5G 体验优的网络过程中,掉线问题的处理尤为重要,掉线率问题在网络中对用户的影响感知较大,感知的明显变化为 5G 信号时有时无,对网络的口碑至关重要.本案例通过 4/5G 邻区核查优化、基站故障处理、参数配置问题优化等手段对掉线问题的多方位分析,提升 5G 用户的使用感知【关键字】NSA 掉线【业务类别】保持类一、问题描述目前XX已全面开展 5G 网络部署工作,主要已 5G NSA 组网模式为主,保障NSA 网络正常运行,提升5G 网络的用户体验感知是当前重要工作;与传统LTE 网络一样,需要从“接入性”、“移动性”、“保持性”以及“小区数据传输能力”几个维度进行性能问题分析定位;接入性:SCG 添加成功率;移动性:SCG 修改成功率、SCG 变更成功率、锚点切换成功率;保持性:SCG 异常释放率;小区数传能力:小区下上下行感知速率;本次主要针对SCG 异常释放率进行优化,根据日常测试、后台指标监控发现网络存在“点、线”的问题,从故障告警、参数配置、邻区优化、覆盖等多方面进行优化提升,保证5G 用户的占用率。
案例:传输问题导致无线系统接通率低一、问题描述对绍兴联通FDD-LTE全网无线接通率进行TOP小区处理及分析,发现诸暨店口五金城、诸暨店口湄池、诸暨店口中伟大厦、诸暨阮市无线接通率一直很低,如下图所示:无线接通率=E-RAB建立成功率*RRC连接建立成功率。
由上图可知,无线接通率较低的小区,E-RAB建立成功率低都是在90%以下,而RRC建立成功率正常。
二、问题分析1) 查询小区告警信息,发现SXFL0523-诸暨店口五金城存在用户面承载链路故障告警;具体如下:用户面承载链路故障告警,通常情况下与X2链路相关,如SXFL2162-绍兴马鞍国庆,就是对端基站故障导致X2接口故障告警,出现用户面承载链路故障告警。
如下图:比较两者之间的告警,发现SXFL0523-诸暨店口五金城告警来至SGW端地址,属于S1接口。
而用户平面的承载是指用于UE和CN之间传送语音、数据及多媒体业务。
因与SGW 对端IP地址存在问题,导致业务不可用。
2) E-RAB建立成功率指标分析:在后台提取指标分析发现SXFL0523-诸暨店口五金城的E-RAB户面承载链路故障告警3)基站侧ping操作排查问题:根据告警定位信息描述发现对端SGW侧IP地址(10.100.33.25等)是存在问题的。
在诸暨店口五金城基站侧执行PING命令(PING 10.100.33.25),即ENODEB端到SGW端,均为超时失败,命令如下:PING:SN=7,SRCIP="10.106.1.210",DSTIP="10.100.33.25",CONTPING=DISABLE,NUM=10,APPTIF=N O;在诸暨店口五金城基站侧执行PING命令(PING 10.100.33.24),即ENODEB端到SGW端,均成功,命令如下:PING:SN=7,SRCIP="10.106.1.210",DSTIP="10.100.33.24",CONTPING=DISABLE,NUM=10,APPTIF=N O;在诸暨店口基站侧执行PING命令(PING 10.100.33.25),即ENODEB端到SGW端,均成功,命令如下:PING:SN=7,SRCIP="10.106.1.150",DSTIP="10.100.33.25",CONTPING=DISABLE,NUM=10,APPTIF=N O;根据上面的排查结果,可以得出以下结果:用户在诸暨店口五金城基站下,SGW侧若分发到10.100.33.25等地址将无法完成正常业务。
最佳实践上报表
图2-2 澄江县悦椿酒店(64T64R)-LHHN告警信息
澄江县悦椿酒店(64T64R)-LHHN基站IP为10.218.138.130,对核心网进行ping测,到MME的地址均能ping通,用户面的SGW均ping不通,具体如下:
图2-3 澄江县悦椿酒店(64T64R)-LHHN基站ping包测试
因此判定澄江县悦椿酒店(64T64R)-LHHN高无线掉线率问题是由于传输侧故障导致E-RAB异常释放导致。
协同核心网、省干传输、本地网传输进行问题排查,经过省干核查后玉溪的地址段路由均已发布,
图2-4玉溪的地址段省干已发布路由
由核心网对基站进行Tracert,发现路由到25.1.253.150不通了,经过传输核查该地市为本地网网L3设备地址,由此断定本地传输网路由存在问题;
图2-5核心网Tracert基站结果
【解决方案】
协调本地网传输侧进行路由核查,发现澄江县悦椿酒店(64T64R)-LHHN基站所在的地址段路由发布有问题,导致的用户面路由不通,重新发布路由后进行ping测正常,基站指标恢复正常。
【优化对比】
传输侧故障排查解决后,澄江县悦椿酒店(64T64R)-LHHN的无线掉线率指标下降到0.09%左右,指标恢复正常。
终端问题导致E-RAB掉线率突增1.问题描述某局点的一个小区从2016.10.11开始,E-RAB异常释放开始突然增加,严重影响整个网络KPI指标,成为Top小区,客户要求定位问题并给出解决方案。
2.处理过程小区从2016.10.11开始,E-RAB异常释放导致的掉线开始突增,严重影响客户网络KPI 指标。
从小时级的KPI趋势图可以看出,无线原因是引起E-RAB异常释放的主要原因。
图1 小时级E-RAB掉线从PRS提取该小区的E-RAB掉线指标,发现小区从2016.09.29 E-RAB异常释放次数开始增加。
图2 E-RAB掉线次数(天级)查看单板操作日志,发现28号前后没有明显的可疑操作,因为所有的修改、删除、设置等操作时间与小区E-RAB掉线恶化时间不一致。
且无重大告警,用Omstar进行参数核查,结果正常。
图3 操作日志使用FMA检查BRD日志,无线失败原因主要是由于SRB达到了最大传输次数32次,导致RLC轮询超时后依然没有收到终端反馈。
图4 FMA核查结果进一步核查KPI差的时间点,发现掉话主要集中在UE终端型号为0x14;7F4FFE9A; 0000000800D7; 00000093;0560上,E-RAB异常释放占比43%以上。
图5 问题终端类型由此可知,此小区E-RAB掉线率突然恶化是由于终端导致的,属于Top终端问题。
3.原因分析由于终端问题导致E-RAB异常释放突增,属于Top终端问题。
4.解决方案根据客户要求解决此小区掉线率恶化问题,由于是终端问题,临时的解决办法是推动核心网让此类型终端不驻留LTE。
最终的解决方案推动终端厂商更新补丁进行升级或者更换终端。
5.建议与总结无。
无线网络为什么经常掉线对于无线网络经常掉线的问题我们现在来进行一下总结。
那么这里就让我们详细看看具体的内容吧。
首先我们看看混合网络中出现掉线的相关问题吧。
希望这些总结对大家能够有所帮助。
无线网络经常掉线1:混合无线网络经常掉线故障现象:使用11G网卡和 11g AP构建无线局域网,它们使用的都是IEEE 802.11g协议,网络中还存在少数802.11b网卡。
当使用11G网卡进行54Mb/s连接时经常掉线。
故障分析:从理论上说,IEEE 802.11g协议是向下兼容802.11b协议的,使用这两种协议的设备可以同时连接至使用IEEE 802.11g协议的AP。
但是,从实际经验来看,只要网络中存在使用IEEE 802.11b协议的网卡,那麽整个网络的连接速度就会降至11Mb/s(IEEE 802.11b协议的传输速度)。
故障解决:在混用IEEE 802.11b和IEEE 802.11g无线设备时,一定要把无线AP设置成混合(MI某ED)模式,使用这种模式,就可以同时兼容IEEE 802.11b和802.11g两种模式。
无线网络经常掉线2:无线客户端接收不到信号故障现象:构建无线局域网之后,发现客户端接收不到无线AP的信号。
无线网络没有信号。
故障分析:导致出现该故障的原因可能有以下几个:(1)无线网卡距离无线AP或者无线路由器的距离太远,超过了无线网络的覆盖范围,在无线信号到达无线网卡时已经非常微弱了,使得无线客户端无法进行正常连接。
(2)无线AP或者无线路由器未加电或者没有正常工作,导致无线客户端根本无法进行连接。
(3)当无线客户端距离无线AP较远时,我们经常使用定向天线技术来增强无线信号的传播,如果定向天线的角度存在问题,也会导致无线客户端无法正常连接。
(4)如果无线客户端没有正确设置网络IP地址,就无法与无线AP进行通信。
(5)出于安全考虑,无线AP或者无线路由器会过滤一些MAC地址,如果网卡的MAC地址被过滤掉了,那麽也会出现无线网络经常掉线。
无线连接成功率波动问题分析1.现象描述8月初监控指标发现,8月1日起全网晚忙时无线连接成功率出现大幅下滑,其他时段基本正常,偶有波动。
3.问题分析通过分析,无线连接成功率波动原因是因为初始E-RAB建立失败,无明显TOP小区。
从抓取到的信令流程来看,失败均是因为Initial context setup failure。
通过E-RAB建立失败统计点图,可以看出“Initial context setup failure”为ERAB建立失败时无线给核心网上报的信令点。
初步判断可能是以下三种原因:1、终端原因;2、无线侧原因,初始上下文建立请求未正常发送至核心网侧;3、核心网侧原因,核心网侧收到初始上下文建立请求,但未给无线侧回应。
3.问题定位3.1 终端原因从抓取到的信令流程来看UU口在下发RRC连接重配置之后一直未收到UE发送的RRC连接重配置完成,ERAB建立失败的原因是eNodeB侧的“等待RRC 连接重配完成的定时器”超时导致,现网设置为8秒。
从Ulinformationtransfer信令中可以看到UE的IMSI信息,118603-16小区中IMSI为“460110032321042”的终端连续多次ERAB失败,为判断是否真是由于终端原因导致全网指标波动,跟踪该用户信令,8月9日上午9点-14点中间,该用户在118603-16扇区下共发起10次Initial context setup request 均成功,未出现问题时段多次请求均失败的现象,可以排除终端问题导致全网指标波动的原因。
3.2 无线侧原因通过对全网扇区指标分析,没有明显TOP小区,对全网扇区进行参数检查,未发现设置不合理的参数。
以问题扇区118603-16扇区为例分析负荷情况:问题时段扇区用户数,基站负荷较小,未出现网络拥塞等情况。
通过上图可以看出,该扇区在问题时段较之前并未出现大幅用户数激增的情况,因此可以判断,无线侧原因导致指标波动的可能性较小。
案例名称异系统异厂家互操作问题导致SA无线掉线率和flow掉线率高分公司专业无线设备类型eNodeB设备厂家华为设备型号BTS3900 5G 软件版本V100R017C00SPC150 编制时间2021.06 作者作者电话入库时间审核人审核人电话厂商审核人联系方式关键字异系统异厂家互操作故障现象5G SA工单通报城二5G东城宝鼎大厦1HM26G-15G SA无线掉线率(天)(5G小区)和5G SA Flow掉线率(天)(5G小区)高复现多次。
SA无线掉线率(天)和SA Flow掉线率(天)达到20%左右。
告警信息无告警原因分析1、该小区平均上下行PRB利用率10%左右,最大用户数较少,排除资源类高负荷原因。
无基站故障告警和干扰较少,基线参数核查无异常。
2、如下所示,主要原因为无线侧原因,为上下文异常施放次数较多,掉线原因为UE lost,排除核心网问题。
3、CELLDT掉线信令流程为基站下发重配置消息给UE,未收到UE反馈的重配置完成,并且重配置消息已达到最大重传次数32次,为上行严重弱覆盖导致掉线。
4、通过RSRP和SINR下行信号确认,下行弱覆盖严重,已到-120以下还未切换到LTE 小区,怀疑存在异系统切换或者深度覆盖不足问题。
5、统计平均TA和PUSCH<-130占比,该小区接入距离不远,上下行信号都较弱,排除有拉远或者严重泄露情况。
处理步骤1、NR至LTE基于覆盖互操作开关核查:NR2LTE切换开关:开;切换和重定向均打开;2、5-4邻区核查,发现该小区存在异系统异厂家分布情况,邻区加全共计12个小区如下表所示3、异系统切换参数修改:标识0,A1由-111改到-100,A2由-115改到-105,盲门限由-120改到-110;标识1,A1由-105改到-100,A2由-110改到-105,盲门限由-120改到-1104、用户饱和功率偏置门限:-23至0。
参数解释:该参数用于控制UE侧入口功率饱和门限的偏置值。
影响无线网络稳定性原因分析
我们在使用无线网络的时候,有时候会发生无线网络不稳的情况,时快时慢,偶尔还会发生掉线,可能你会抱怨连接不稳定和性能差劲,这样便会妨碍应用程序的使用,其实我们应该需要对无线网进行一定的诊断,这样才能找到问题的根本原因,从而解决。
一、无线网络不稳的原因之一就是射频干扰,射频干扰会占用空气这种无线传输媒介,会延迟用户发送和接收数据的时间,并导致冲突,进而导致数据重发。
1、如果噪音强度很大,同时重试率也很高,这一般是由于射频干扰正在影响你的无线网造成的,如果你的网络带宽中噪音强度超过了-85dBm,那幺射频干扰就存在着损害网络性能的可能。
在这种情况下,用户的重试率将超过10%,这时用户会感到网络速度受到了影响。
2、如果你断定问题是由于射频干扰引起的,就得找到这种干扰来自。
文档名称 文档密级 2015-12-30 华为机密,未经许可不得扩散 第1页, 共15页
1
Y省B局点核心网GUTP传输通道配置问题导致无线掉线率升高
1 现象描述 2015年1月份B局点LTE的无线掉线率在0.16%左右,2月初开始无线掉线率开始不断升高,2月4日以后无线掉线率恶化至0.23%以上,较1月份该指标平均值,升高了0.07%,该指标恶化明显,接入类指标及移动性指标无明显变化,详细指标请见下表:
间 时间粒度 LTE基站数 LTE小区数 RRC连接建立成功率(%) E-RAB建立成功率(%) 无线接通率(%) 无线掉线率(%) E-RAB掉线率 切换成功率 CSFB成功率
最大用
户数
01/28/2015 24小时 1236 3433 99.98 99.98 99.96 0.16 0.15 99.58 99.95 48530 01/29/2015 24小时 1238 3441 99.97 99.98 99.96 0.16 0.16 99.54 99.95 48570 01/30/2015 24小时 1241 3448 99.98 99.98 99.95 0.16 0.16 99.55 99.95 49528 01/31/2015 24小时 1242 3450 99.98 99.99 99.97 0.17 0.16 99.56 99.95 47963 02/01/2015 24小时 1242 3451 99.98 99.98 99.96 0.17 0.16 99.55 99.95 50694 02/02/2015 24小时 1248 3462 99.98 99.98 99.96 0.18 0.17 99.57 99.95 52270 文档名称 文档密级 2015-12-30 华为机密,未经许可不得扩散 第2页, 共15页
2
02/03/2015 24小时 1248 3462 99.98 99.98 99.97 0.19 0.18 99.45 99.95 52515 02/04/2015 24小时 1248 3462 99.98 99.98 99.97 0.23 0.22 99.43 99.95 53583 02/05/2015 24小时 1248 3462 99.98 99.98 99.97 0.24 0.23 99.54 99.93 54256 02/06/2015 24小时 1248 3464 99.98 99.98 99.96 0.23 0.23 99.57 99.9 54597 02/07/2015 24小时 1248 3464 99.98 99.98 99.96 0.29 0.28 99.58 99.86 53668 02/08/2015 24小时 1248 3464 99.98 99.98 99.97 0.25 0.24 99.6 99.89 53019 表1:网管KPI指标统计(1月28日-2月8日) 2 告警信息 无 3 原因分析
1. 无线掉线率指标定义 无线掉线率=(eNodeB发起的S1 RESET导致的UE Context释放次数+ MME发起的S1 RESET导致的UE Context释放次数+ UE Context异常释放次数)/ UE Context建立成功总次数*100%
UE上下文异常释放包括eNodeB主动发送UE CONTEXT RELEASE REQUEST消息,原因为异常的释放以及eNodeB、MME发起的S1 RESET导致的UE上下文释放。eNodeB发起的UE上下文释放异常定义:当eNodeB向MME发送UE CONTEXT RELEASE REQUEST消息,会释放UE的所有E-RAB。当释放原因不为“Normal Release”,“Detach”,“User Inactivity”,“CS Fallback triggered”,“UE Not Available for PS 文档名称 文档密级 2015-12-30 华为机密,未经许可不得扩散 第3页, 共15页
3
Service”,“Inter-RAT Redirection”,“Time critical handover”,“Handover Cancelled”时,测量指标L.UECNTX.AbnormRel加1。当eNodeB向MME发送S1 RESET消息时,根据包含的上下文个数,指标L.UECNTX.Rel.S1Reset.eNodeB进行累加。当MME向eNodeB发送S1 RESET消息时,根据包含的上下文个数,指标L.UECNTX.Rel.S1Reset.MME进行累加。eNodeB性能指标中定义的eNodeB发起的UE上下文释放原因只有5种,分别为无线问题、User Inactivity、UE LOST、切换流程失败、上行弱覆盖,指标体系并不完善。另外性能指标中对核心网发起的UE上下文释放原因并没有进一步定义。小区eNodeB发起的UE上下文释放原因各指标名称及描述如下:
指标ID 指标名称 指标描述 所属网元 1526728857 L.UECNTX.Rel.eNodeB.Rnl eNodeB发起的原因为无线层问题的UE Context释放次数 BTS3900, BTS3900 LTE 1526728858 L.UECNTX.Rel.eNodeB.Userinact eNodeB发起的原因为User Inactivity的UE Context释放次数 BTS3900, BTS3900 LTE 1526728859 L.UECNTX.Rel.eNodeB.UeLost eNodeB发起的原因为UE LOST的UE Context释放次数 BTS3900, BTS3900 LTE 1526728860 L.UECNTX.Rel.eNodeB.HOFailure eNodeB发起的原因为切换失败的UE Context释放次数 BTS3900, BTS3900 LTE 1526730863 L.UECNTX.AbnormRel.UlWeak eNodeB发起的原因为上行弱覆盖的UE Context异常释放次数 BTS3900, BTS3900 LTE
2. 性能指标统计分析: 文档名称 文档密级
2015-12-30 华为机密,未经许可不得扩散 第4页, 共15页
4
通过对话统中定义的UE上下文释放测量指标进行统计,得到2月2日-2月11日的数据原表,各指标的UE Context的释放次数如下,可以看到eNodeB发起的UE Context释放次数没有明显的变化,反之MME发起的UE Context释放次数呈现明显的增长;eNodeB发起的原因为无线层问题的释放次数有所浮动,但不是异常释放总数升高的主因,而原因值为其他的MME发起的释放UE Context次有明显上升(MME释放总次数-原因为Normal Release的MME释放次数),因此从整网指标的变化情况上看,UE Context异常释放次数增多与MME发起的释放原因有关:
表3:UE Context释放原因值统计 图1:UE Context释放各原因值比例变化情况 3. TOP问题小区分析 选择2月5日的TOP3(XX固东爱国-HLH-3、XX辛街大官市-HLH-1、XX永昌白塔-HLH-1)问题小区进行针对性分析,提取这三站点2月5日一键式日志,并通过工具进行解析,2月5日这三个站点无异常告警、事件以及网络操作,从内部释放原因表中可以看到三个小区的掉话次数主要原因为UEM_UECNT_REL_RECV_GTPU_RESET_BEAR_REQ,占总掉线次数的80%以上,从TOP用户分析表中看到每一个问题小区下的掉线次数集中在一个TIMSI下,结合 文档名称 文档密级 2015-12-30 华为机密,未经许可不得扩散 第5页, 共15页
5
TOP终端分布可以进一步确认是否由于某类终端异常导致,但是结合三张表可以看到XX固东爱国-HLH-3下TOP终端为Coolpad8720L,但是该类终端在XX辛街大官市-HLH-1下表现正常,并且XX辛街大官市-HLH-1下的TOP终端OPPOFind7 X9077,但该小区下另外一部同类型终端正常,因此判断小区异常掉线升高不是某一款终端异常导致的,而是某些TOP用户导致的:
XX固东爱国-HLH-3
内部释放原因掉话次数比例(%)结果建议UEM_UECNT_REL_RECV_GTPU_RESET_BEAR_REQ2770892.74掉话(L.E-RAB.AbnormRel.TNL)通过查询GTPU Trace确认是否存在错误指示
UEM_UECNT_REL_UE_RLC_UNRESTORE_IND15275.11掉话(L.E-RAB.AbnormRel.Radio)通过 L2RlcReTx事件观察最大重传次数,通过L2_DRB_STRU事件观
UEM_UECNT_REL_MME_CMD4771.59掉话(统计至L.E-RAB.AbnormRel.MME)观察SigInfoList事件中最后1条信令信息,统计核心网发起的释放原
UEM_UECNT_REL_SAE_BEARER_REL_NUM_MAX4840.28掉话获取对应时间的Debug日志,联系L3 RR模块进行处理UEM_UECNT_REL_UE_RESYNC_DATA_IND_REL_CAUSE360.12掉话(L.E-RAB.AbnormRel.Radio)通过L2_XX_USER_TA_FAIL_EVENT事件观察TA
UEM_UECNT_REL_SAE_BEARER_REL_NUM_MAX5240.08掉话获取对应时间的Debug日志,联系L3 RR模块进行处理
UEM_UECNT_REL_RRC_REEST_SRB1_FAIL120.04掉话(L.E-RAB.AbnormRel.Radio)通过L2_USER_INFO事件确认RRC_Conn_Reest信令UEM_UECNT_REL_MME_CMD_BEFORE_SRB2_RRCCONNRECFG_CMP60.02掉话通过L2_USER_INFO事件确认RRC_Conn_RECFG信表5:XX固东爱国-HLH-3掉线内部释放原因统计
TMSI 掉话次数 上行弱覆盖 上行干扰 信号陡降 其它 XX854C27 27819 0 0 6 27813 FFFFFFFF 174 0 0 36 138 XXA55E25 27 18 0 0 9 XX8DBE09 24 24 0 0 0 XX7F1414 18 0 0 0 18 XX354B1F 18 0 0 3 15 XX0FBA13 18 0 0 3 15