诺西G82和G85下2个小区TBF建立异常分析.docx

1、诺西G82和G85下2个小区TBF建立异常分析诺西G82和G85下TBF建立异常小区分析故障现象：自11月20日起发现数据业务质差小区中，G85C2F3 GN-奉明奎_3和G82D131 GN-晨光_1 存在TBF建立异常现象，上行TBF建立成功率70%以上，下行TBF建立成立0%。日期时间小区站名上行PDCH复用度下行PDCH复用度上行TBF建立尝试次数下行TBF建立尝试次数上行TBF成功建立次数下行TBF成功建立次数上行TBF建立成功率下行TBF建立成功率2012112220:00G85C2F3GN-奉明奎_31.09011942010715089.73%0.00%2012112020:0

2、0G82D131GN-晨光_110250702089083.33%0.00%原因分析：通过观察当天的话务统计，发现GN-奉明奎_3和GN-晨光_1下行TBF尝试和建立次数为均为0，无下行TBF建立；根据以上问题表征，我们从多个方面进行了定位和分析。首先检查了GN-奉明奎_3和GN-晨光_1的参数设置，比如若所有载频功率过低、EDGE 载频TSC参数与BCC不同，数据业务载频信令和载频不对应，GPRS上行功控参数ALPHA和GAMMA为零，均有可能导致上述问题的发生。经过仔细认真的核查和比对近10项重要参数后，最终确认参数设置没有异常,均在正常的范围之内。然后我们调取了GN-奉明奎_3和GN-晨

3、光_1当天的话务统计报告，希望从话统方面入手，发现更多的问题表现特征，以有助于准确定位问题的根本原因。经各项指标统计分析后发现GN-奉明奎_3和GN-晨光_1 的其他KPI指标表现良好。基于以上情况分析，我们认为有以下几个原因可能造成上述问题：1、存在7745、7606、7743、7725等告等7745可能造成信道激活失败，导致TBF无法建立7725可能造成信道激活时间过短，导致TBF无法建立7606可能为载频故障，RSSI分集接收异常等，导致TBF建立异常2、基站软件包不匹配（BSC版本刚升级为S15 0212PP）3、是否存在干扰4、存在硬件故障5、PCU下DSP吊死等情况6、传输ABIS

4、数据配置错误流程图：原因分析：1、 告警通过现网MML命令ZEOL&ZEOH核查发现小区不存在任何告警信息。2、 基站软件包不匹配通过MML命令ZWQO:CR;查看BSC82-D软件包SF 0212PP，基站软件包同时需要升级以配合新的BSC软件包，可能的问题是否由于基站软件包未升级至最新。GN-晨光_1站型FLEXI MULTI 最新软件包应为BTS_EX_4_2_0通过MML命令ZWQO:CR;查看BSC85-C软件包SE 0910EP，基站软件包是需要BSC软件版本支持的，可能的问题是否由于基站软件包不是BSC版本支持的。GN-奉明奎_3站型FLEXI EDGE 最新软件包应为EX3MP

5、50经过核查发现基站软件包是BSC版本支持的。3、 干扰排查根据干扰采样点分布可以发现，干扰噪声全部集中在BAND1中，BAND2-均没有发现干扰。根据目前上海移动对于干扰带要求的设置，BAND1实际是指干扰小于等于-105dbm，接近底噪。可以认为BAND1的干扰基本是由底噪引起，对于无线信号的传递基本没有影响；同样对于BAND2（实际是指-105dbm-100dbm）来说，也不影响信号传递，C/I表现均在15以上。因此对于室外站（包括街道站和宏站）一般认为BAND3以上才算有真正的干扰，会影响用户的实际通话感受。基于以上分析，可以说明该小区的问题并非是由于干扰所引起的。4、 硬件故障经查看

6、现网无载频退服现象5、 PCU下DSP吊死等情况BSC85-C下GN-奉明奎_3的PCU dsp实时占用情况，发现GN-奉明奎_3 的SEGMENT_ID为204，只有上行TBF，无下行TBF,dsp-id为4，然而同一dsp-id 4下存在2个小区，另一个小区建立正常，说明并不是因为dsp吊死导致下行TBF无法建立，可以尝试reset dsp：4：但是仍然存在无下行建立，因此并不是因为dsp 吊死导致。BSC82-D下GN-晨光_1的PCU dsp实时占用情况，发现GN-晨光_1 SEGMENG_ID为152，只有上行TBF，无下行TBF,dsp-id为2，然而同一dsp-id 2下存在3个

7、小区，另2个小区建立正常，说明并不是因为dsp吊死导致下行TBF无法建立，可以尝试reset dsp：2：但是仍然存在无下行建立，因此并不是因为dsp 吊死导致。6、 传输abis数据配置错误经过以上检查仍无法断定是何问题：经以下步骤一一核查：1）、看是否是基站数据吊死，重启BTS后仍存在2)、是否由于CCCHE和跳频存在故障，将小区BB跳频关闭后问题仍然存在，再将BB跳频开启3）、倒换数据载频BSC82-D下GN-晨光_1现网EDGE TRX配置情况如下：TRX3&4绑定EDAP开启GTRX功能。现将TRX3和TRX2进行倒换，将TRX3的EDAP和GTRX设置为N，将TRX2的EDAP设置

8、为152，GTRX设置为Y出现BTS SITE NOT UPDATED告警，无法正常启站，将所有载频GTRX设置为Y，EDAP设置N，关闭EGENA功能，发现是可以正常启站，说明是由于EDAP存在问题导致基站数据无法更新，而导致基站吊死无法正常启站，可能的原因为基站数据TRX2无法关联EDAP导致，基站ABIS传输数据和BSC测数据不匹配问题。通过BTS Manager连接到基站，发现基站侧数据，未选允许自动从BSC的选项，导致BSC和基站数据存在不一致时，无法匹配，无法调用EDAP,以至于造成TBF建立异常的现象。BSC85-C下GN-奉明奎_3问题同上，原因一致。解决措施：如下将允许自动从

9、BSC匹配数据选项选上，基站恢复正常，倒换GTRX，修改ABIS传输数据也可以正常启站。经验总结：对于一般TBF建立异常的问题，一般可以从以下几个方面进行考虑：1. 参数设置异常错误的参数设置会引起固定的问题表征，规律明显，较易发现。经过参数比对和核查也比较容易定位和解决此类错误。2. 存在严重告警主频存在7745告警信道激活失败导致无法分配信道，数据载频存在7725告警，信道在起呼阶段，激活时间过短引起的信道闭锁，7606载频故障引起信令吊死，伴随寻呼删除，SDCCH溢出，导致只有上行TBF建立无法进行下行TBF建立的现象。3. PCU下DSP吊死问题，此类问题容易发现，一般同一PCU下同一

10、DSP下的小区均存在无业务或者TBF建立异常等现象，可以通过重置DSP来解决。4. 对于基站数据与BSC数据MAPPING这一问题值得我们谨慎关注，在新站入网，站址搬迁，正负扩容，以及BSC侧修改EDAP，倒换GTRX，重建信令等对ABIS传输数据更改时，基站数据无法MAPPING BSC侧数据，导致两侧数据不匹配，引起TBF建立成功率等KPI异常，并严重影响用户感知，造成大量的用户投诉，此类问题，需要基站工程师在新站入网或者替换割接时对基站Enable Abis Signal Mapping选项选上，这样无论基站侧数据更改，还是BSC测数据更改，基站侧会自动去匹配BSC侧数据，以保持一致。尽

11、量避免此类问题的发生，防患于未然。5. 硬件显性、隐性故障硬件显性故障的发现十分容易，只需要获取当时的告警进行分析即可。硬件隐性故障的发现则要难得多，首先隐性故障的在话统方面的表现不一，再受到跳频、AMR、功控、语音业务等各类功能的影响，可以说最终在话统、测试时的表征要复杂的多，几乎没有特定的规律可循；要发现和判定隐性故障点，我们发现的这类问题是通过倒换载频试出来发现基站数据和BSC数据不匹配的问题，这类问题的发现，往往需要靠网优工程师长期的工作经验、对当地网络、对ABIS数据和基站硬件的熟悉程度来解决。对于网优中碰到的各类问题，我们都应该客观细致地进行分析，尽可能收集较多的信息和数据；只有经过全面系统地分析后，才能准确地定位到问题的根源，从而对症下药彻底解决问题。对于数据业务优化来说不仅无线网络优化，而且ABIS数据规划优化对EGPRS网络优化额外的重要。