诺西G82和G85下2个小区TBF建立异常分析.docx
《诺西G82和G85下2个小区TBF建立异常分析.docx》由会员分享，可在线阅读，更多相关《诺西G82和G85下2个小区TBF建立异常分析.docx（9页珍藏版）》请在冰豆网上搜索。
诺西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网络优化额外的重要。
升级会员 