诺西G82和G85下2个小区TBF建立异常分析.docx
《诺西G82和G85下2个小区TBF建立异常分析.docx》由会员分享,可在线阅读,更多相关《诺西G82和G85下2个小区TBF建立异常分析.docx(9页珍藏版)》请在冰豆网上搜索。
![诺西G82和G85下2个小区TBF建立异常分析.docx](https://file1.bdocx.com/fileroot1/2023-1/8/8af09277-4cd8-4c3d-a4e8-0f70746d3393/8af09277-4cd8-4c3d-a4e8-0f70746d33931.gif)
诺西G82和G85下2个小区TBF建立异常分析
诺西G82和G85下TBF建立异常小区分析
故障现象:
自11月20日起发现数据业务质差小区中,G85C2F3GN-奉明奎_3和G82D131GN-晨光_1存在TBF建立异常现象,上行TBF建立成功率70%以上,下行TBF建立成立0%。
日期
时间
小区
站名
上行PDCH复用度
下行PDCH复用度
上行TBF建立尝试次数
下行TBF建立尝试次数
上行TBF成功建立次数
下行TBF成功建立次数
上行TBF建立成功率
下行TBF建立成功率
20121122
20:
00
G85C2F3
GN-奉明奎_3
1.09
0
11942
0
10715
0
89.73%
0.00%
20121120
20:
00
G82D131
GN-晨光_1
1
0
2507
0
2089
0
83.33%
0.00%
原因分析:
通过观察当天的话务统计,发现GN-奉明奎_3和GN-晨光_1下行TBF尝试和建立次数为均为0,无下行TBF建立;
根据以上问题表征,我们从多个方面进行了定位和分析。
首先检查了GN-奉明奎_3和GN-晨光_1的参数设置,比如若所有载频功率过低、EDGE载频TSC参数与BCC不同,数据业务载频信令和载频不对应,GPRS上行功控参数ALPHA和GAMMA为零,均有可能导致上述问题的发生。
经过仔细认真的核查和比对近10项重要参数后,最终确认参数设置没有异常,均在正常的范围之内。
然后我们调取了GN-奉明奎_3和GN-晨光_1当天的话务统计报告,希望从话统方面入手,发现更多的问题表现特征,以有助于准确定位问题的根本原因。
经各项指标统计分析后发现GN-奉明奎_3和GN-晨光_1的其他KPI指标表现良好。
基于以上情况分析,我们认为有以下几个原因可能造成上述问题:
1、存在7745、7606、7743、7725等告等
7745可能造成信道激活失败,导致TBF无法建立
7725可能造成信道激活时间过短,导致TBF无法建立
7606可能为载频故障,RSSI分集接收异常等,导致TBF建立异常
2、基站软件包不匹配(BSC版本刚升级为S150212PP)
3、是否存在干扰
4、存在硬件故障
5、PCU下DSP吊死等情况
6、传输ABIS数据配置错误
流程图:
原因分析:
1、告警
通过现网MML命令ZEOL&ZEOH核查发现小区不存在任何告警信息。
2、基站软件包不匹配
通过MML命令ZWQO:
CR;查看BSC82-D软件包SF0212PP,基站软件包同时需要升级以配合新的BSC软件包,可能的问题是否由于基站软件包未升级至最新。
GN-晨光_1站型FLEXIMULTI最新软件包应为BTS_EX_4_2_0
通过MML命令ZWQO:
CR;查看BSC85-C软件包SE0910EP,基站软件包是需要BSC软件版本支持的,可能的问题是否由于基站软件包不是BSC版本支持的。
GN-奉明奎_3站型FLEXIEDGE最新软件包应为EX3MP50
经过核查发现基站软件包是BSC版本支持的。
3、干扰排查
根据干扰采样点分布可以发现,干扰噪声全部集中在BAND1中,BAND2-均没有发现干扰。
根据目前上海移动对于干扰带要求的设置,BAND1实际是指干扰小于等于-105dbm,接近底噪。
可以认为BAND1的干扰基本是由底噪引起,对于无线信号的传递基本没有影响;同样对于BAND2(实际是指-105dbm~-100dbm)来说,也不影响信号传递,C/I表现均在15以上。
因此对于室外站(包括街道站和宏站)一般认为BAND3以上才算有真正的干扰,会影响用户的实际通话感受。
基于以上分析,可以说明该小区的问题并非是由于干扰所引起的。
4、硬件故障
经查看现网无载频退服现象
5、PCU下DSP吊死等情况
BSC85-C下GN-奉明奎_3的PCUdsp实时占用情况,发现GN-奉明奎_3的SEGMENT_ID为204,只有上行TBF,无下行TBF,dsp-id为4,然而同一dsp-id4下存在2个小区,另一个小区建立正常,说明并不是因为dsp吊死导致下行TBF无法建立,可以尝试resetdsp:
4:
但是仍然存在无下行建立,因此并不是因为dsp吊死导致。
BSC82-D下GN-晨光_1的PCUdsp实时占用情况,发现GN-晨光_1SEGMENG_ID为152,只有上行TBF,无下行TBF,dsp-id为2,然而同一dsp-id2下存在3个小区,另2个小区建立正常,说明并不是因为dsp吊死导致下行TBF无法建立,可以尝试resetdsp:
2:
但是仍然存在无下行建立,因此并不是因为dsp吊死导致。
6、传输abis数据配置错误
经过以上检查仍无法断定是何问题:
经以下步骤一一核查:
1)、看是否是基站数据吊死,重启BTS后仍存在
2)、是否由于CCCHE和跳频存在故障,将小区BB跳频关闭后问题仍然存在,再将BB跳频开启
3)、倒换数据载频
BSC82-D下GN-晨光_1现网EDGETRX配置情况如下:
TRX3&4绑定EDAP开启GTRX功能。
现将TRX3和TRX2进行倒换,将TRX3的EDAP和GTRX设置为N,将TRX2的EDAP设置为152,GTRX设置为Y
出现BTSSITENOTUPDATED告警,无法正常启站,将所有载频GTRX设置为Y,EDAP设置N,关闭EGENA功能,发现是可以正常启站,说明是由于EDAP存在问题导致基站数据无法更新,而导致基站吊死无法正常启站,可能的原因为基站数据TRX2无法关联EDAP导致,基站ABIS传输数据和BSC测数据不匹配问题。
通过BTSManager连接到基站,发现基站侧数据,未选允许自动从BSC的选项,导致BSC和基站数据存在不一致时,无法匹配,无法调用EDAP,以至于造成TBF建立异常的现象。
BSC85-C下GN-奉明奎_3问题同上,原因一致。
解决措施:
如下将允许自动从BSC匹配数据选项选上,基站恢复正常,倒换GTRX,修改ABIS传输数据也可以正常启站。
经验总结:
对于一般TBF建立异常的问题,一般可以从以下几个方面进行考虑:
1.参数设置异常
错误的参数设置会引起固定的问题表征,规律明显,较易发现。
经过参数比对和核查也比较容易定位和解决此类错误。
2.存在严重告警
主频存在7745告警信道激活失败导致无法分配信道,数据载频存在7725告警,信道在起呼阶段,激活时间过短引起的信道闭锁,7606载频故障引起信令吊死,伴随寻呼删除,SDCCH溢出,导致只有上行TBF建立无法进行下行TBF建立的现象。
3.PCU下DSP吊死问题,此类问题容易发现,一般同一PCU下同一DSP下的小区均存在无业务或者TBF建立异常等现象,可以通过重置DSP来解决。
4.对于基站数据与BSC数据MAPPING这一问题值得我们谨慎关注,在新站入网,站址搬迁,正负扩容,以及BSC侧修改EDAP,倒换GTRX,重建信令等对ABIS传输数据更改时,基站数据无法MAPPINGBSC侧数据,导致两侧数据不匹配,引起TBF建立成功率等KPI异常,并严重影响用户感知,造成大量的用户投诉,此类问题,需要基站工程师在新站入网或者替换割接时对基站EnableAbisSignalMapping选项选上,这样无论基站侧数据更改,还是BSC测数据更改,基站侧会自动去匹配BSC侧数据,以保持一致。
尽量避免此类问题的发生,防患于未然。
5.硬件显性、隐性故障
硬件显性故障的发现十分容易,只需要获取当时的告警进行分析即可。
硬件隐性故障的发现则要难得多,首先隐性故障的在话统方面的表现不一,再受到跳频、AMR、功控、语音业务等各类功能的影响,可以说最终在话统、测试时的表征要复杂的多,几乎没有特定的规律可循;要发现和判定隐性故障点,我们发现的这类问题是通过倒换载频试出来发现基站数据和BSC数据不匹配的问题,这类问题的发现,往往需要靠网优工程师长期的工作经验、对当地网络、对ABIS数据和基站硬件的熟悉程度来解决。
对于网优中碰到的各类问题,我们都应该客观细致地进行分析,尽可能收集较多的信息和数据;只有经过全面系统地分析后,才能准确地定位到问题的根源,从而对症下药彻底解决问题。
对于数据业务优化来说不仅无线网络优化,而且ABIS数据规划优化对EGPRS网络优化额外的重要。