E2 5.docx
《E2 5.docx》由会员分享，可在线阅读，更多相关《E2 5.docx（58页珍藏版）》请在冰豆网上搜索。
E25
详细描述
整个BSC下的大部分基站反映通话质量差
解决步骤
1.通话质量为单方不好，即一方听到对方通话质量差，而对方听到声音很好。
2.一方占用Cage2上的CIC电路时，对方占用Cage1上的电路时，占用Cage2上电路的一方会听到明显噪音，而对方听不到噪音。
3.BSC无Active的告警。
而步骤2发生的现象在通话双方分别占用Cage1和Cage2上的大部分CIC电路时都有发生。
故障定位为硬件故障。
4.查看Ev_logs发现Cage2有KSWXinSlot22DetectedExpandedKSWMatrixFailure的告警。
5.更换Cage1的22槽位KSWX，故障消失。
备注
KSWX为Cage之间的电路交换提供通道，由于KSWX故障造成通话质量变差
讨论区
2005-6-916:
19:
15
吴国建
kswx的螺丝也要拧紧，没有螺丝的kswx有可能导致cage重启。
2005-5-3017:
33:
45
丁廷立
这种告警不仅要看告警机柜的KSW、KSWX和光纤，还要看与之相连的机柜内的相应板件，一条通道上任何部件都有可能导致该告警。
2005-5-1610:
09:
13
李自伟
在新建BSC进行拨打测试时遇到过，通过拔插KSW、KSWX、光纤等清除KSW告警后，OK.
彭华
我在云南也遇到过，该故障引起了大量单通。
黄冰
福建地区升级到GSR7后有个BSC出现如下告警，因为该CAGE下未挂基站不知是否对话音质量有影响？
KSW21018FMICUntagged01-28-2005FailureofExpandedInbound
（DSW）16:
01:
33TDMHighwayfromKSWpair0
KSW21019FMICUntagged01-28-2005FailureofExpandedInbound
（DSW）16:
01:
34TDMHighwayfromKSWpair1
现场排故时我们更换了涉及的DSW21,但告警未消除，反复swap0tdm也未果！
备用边的kswx也换过仍然不行，但重起该BSC后告警消失了！
这种来无影去无综的告警另人有些担心随时可能复发啊：
（
薛绍辉
多谢指教，看来需要不时的看看EVENTLOG发现一些隐形的故障
罗刚
我在宜宾遇到过相同case，只是当时情况更为严重，该BSC下1/3基站有单通现象
详细描述
BSC插上NVM后，导致重启.DISABLE主BSP,BSC起来后，CAGE1找不到。
解决步骤
1.更换BSP。
RLOGIN0119H后，DISABLE主BSP,BSC起来后，CAGE1找不到。
该机柜为PGASE7新机柜。
在重启过程中，CAGE1的SLOT19GPROC红绿灯闪过两次，并有以下提示：
GPROC2_RAM:
emon_0119%
0NonfatalSWFMErrorRoutine:
check_bus_results.c
0Area:
0x00000300Error:
0x0000001fPC:
0xc0040d4_
备注
系统版本信息:
1.6.2.7.0
讨论区
2006-2-1013:
27:
45
魏和旸
请问cage1有问题为什么在插入NVM板以后，故障才凸显出来呢？
liubin
我在山西碰到过,更换NVM后,BSC恢复正常.两个问题:
1.CAGE1的SLOT19提示符是否应该是GPROC2_RAM:
emon_0219,是否这个板子有问题;
2.更换过NVM吗?
龚德强
cage1的slot18是否插有GPROC板？
每个cage都有一个主GPROC,从18开始。
如果找不到主GPROC,cage不能被确认。
你的情况可能是19的GPROC有问题。
张雷
emon_0219提示符的0219为16进制：
02=01+1表示cage01。
19h＝24+1表示slot24。
cage1的slot19的GPROC，processorid应为0214。
即GPROC2_RAM:
emon_0214提示符。
李玉刚
我以前遇到的一个问题几乎与此一样，也是插入NVM板BSC重启，CAGE1找不到，或者有时CAGE1找到，但上面有的GPROC找不到，最后故障原因是cage1有问题，更换后良好。
陈智炜
NVM，全称“NonVolatileMemory”,它是一块全尺寸板，置于BSC时必须位于第26槽位，置于RXCDR时必须位于第24槽位，板上有1和2二个PCMCIA卡的插槽，目前实际只使用第1插槽，其最大的好处在于此板会时时对比PCMCIA卡与BSP板的数据，始终保持数据同步，从而使得BSC或RXCDR断电重启后可直接从PCMCIA卡获取数据而不必从OMCR上下载，使设备能在短时间内恢复正常。
详细描述
据说目前CINDY6调测软件可以调测HII基站，但国内没人用CINDY6调测过HII基站，不知如何使用。
鉴于现在订货新站都是HII基站，为了调测需要，我根据GSR6上的《68P02902W96-ServicemanualHorizonIImacro》这本手册中摘录成简短的调测流程。
用这个调测流程调HII基站比较方便。
解决步骤
HorizonIIBTS调测流程（在对CTU2调测时，Rx/Tx都可以同时调测两个DRI，可节省一半时间）
【I】*******载频测试模式准备阶段,相当于做载频“prepare”*************************************
1）使用双载频的时候，lock小区中的其他载频，并ins载频CTU2中的第一个DRI，每个CTU2都必须ins一个dri后才能调测
2）连接到载频的TTY测试端口
3）chglev（passwordis“pizza”）
4）cal_test_modeon
5）fmtest_modeon
6）fm_testblocknonenone0xff
【II】*******接收RX校准（BayLevelcalibration：
calibration值为4位16进制,不通为8000H）********
7）tsarx_br_sel2
8）set_carriercara
9）tsalltxp0xff
10）set_carriercarb
11）tsalltxp0xff
12）set_carriercara
13）cal_configrx_cab_antenna0a0b（或1a1b、2a2b，根据调测载频天线扇区选择来定）
14）cal_cabinetrx_cab
15）输入信号发生器频点（从880.8052Mhz开始），按提示逐步调测（容许一次误操作，否则重新cal_cabinetrx_cab），调测完RXa路后，继续调测RXb路。
【III】*******以下为发射TX和驻波比VSWR校准***************************************************
16）Cal_configtx_cab_modedouble
17）Cal_cabinettx_cab
18）使用键盘u和d调整功率，每步进值为0.2dBm，最后用“q”退出
【IV】*******调测结束后，保存调测值到载频EEPROM，再退出测试模式*******************************
19）cal_store_1
20）fmtest_modeoff
21）cal_test_modeoff
22）locksite_nodri（此时CTU2状态为：
E-U,calibrationinprogress）
23）inssite_nodri
应注意的是双载频时如不调整发射值，在diap_cal_data中的Txoffset为12
（hex-）=18（dec-），这是双载频模式的最大值，说明比单载频时小18×0.2＝
3.6（dBm），但由于CTU2内部合路还有附加衰耗，实际衰减为5dBm。
在以上调测流程中，第【I】和【IV】步一定要做，中间的【II】、【III】可视实际调测情况调整顺序。
例如，可先做RX调测，再做TX/VSWR调测；或者将顺序反过来；当然，也可以只做其中的一个。
讨论区
2006-10-2618:
29:
45
吴南川
现在用户和基站工程师用mermer6.03调测基站的比较多。
原因就是集成程度高，傻瓜式操作。
但BUG也多
2005-5-3017:
36:
42
丁廷立
HorizonIIMini的PB不会比HorizonIIMacro的PB稍微偏高吧？
confused
薛绍辉
没有例如BACK之类的调测软件能调测H2吗？
详细描述
BSC在例行安全检查进行重启后,所有SITE硬件等正常，但所有CELL都为Barred状态，
解决步骤
1、所有MTL状态正常，SITE的硬件工作也正常，首先怀疑是BSCRESET过程出现了问题，但是重新将BSC多次RESET仍无法恢复正常。
2、对基站进行远程RESET或现场断电RESTET故障依旧。
3、将所有MTL分别在BSC和MSC两侧都进行复位，后再RESET基站也无效。
4、在MSC把所有MTL都LOCK后，把BSCRESET一次，BSC起来后，把所有基站都LOCK后，然后在MSC侧把所有MTL依次UN-LOCK，最后把基站UN-LOCK，CELL状态恢复正常。
备注
系统版本信息:
GSR5
讨论区
2006-8-299:
34:
48
魏雄辉
今年四月在湖南张家界也出现过类事问题，当时只重启了BSC，CELL就恢复了正常（是华为交换机）。
2006-3-18:
37:
24
龚勋
太神奇了：
“最后看见移动维护人员和交换班的人在moto的OMCR上和西门子的终端上喊一、二、三，同时激活信令，居然OK了”
2005-5-3017:
39:
21
丁廷立
这个问题是不是MTL‘假活’呀？
！
本人在河南时（Nokia交换机）就遇到过该现象
龚德强
用disp_cell_s看小区状态为barred,看看resetinprog是否是"no",如果是“yes”，就是reset造成的A口两边不同步。
和MSC厂家有关，象阿尔卡特，爱立信MSC和我们配合这种问题较多。
锁信令是个不错的方法。
应学理
和NOKIA的交换机配合时也有这种问题，不过重启NOKIA的信令路由单元就OK了
关涛
有没有开SR查找到问题的原因啊?
小区的cellbaraccess参数都是正确的吗?
孙强国
和北电MSC配合时，曾出现类似情况。
当时是在MSC方面激活控制MTL的信令模块，问题得到解决。
秦雪峰
应该是BSSAP未通.可以询问CNRC,好象有类似的现象.
薛绍辉
以前遇到过，不用锁什么MTL，就直接重启一次BSC，马上搞定
陈锋
和阿标一样的问题几年前在山东也碰到过。
是烟台的DCS1800系统。
在BSS升级后当时也是所有的小区都Barred。
当时以往时软件版本问题。
后天请教了徐宏起大虾，才发现山东的很多系统经常要这样。
肖毅
上次一个BSC有几个MTL是"E-U",交换和BSC处反复激活都不见效，最后看见移动维护人员和交换班的人在moto的OMCR上和西门子的终端上喊一、二、三，同时激活信令，居然OK了，有点象两个人开密码门的感觉！
焦志冬
我们同NOKIA配合时碰到过同样的问题,是通过重起BSC解决的!
刘明涛
同Nokia交换机（M10版本）配合时也出现过类似问题，我同意应学理的观点，当Moto的BSC重启后与Nokia交换机之间MTL信令连路的B-U状态是一种假活状态，我们曾架表测试发现在MTL链路上我BSSAP层消息，使得无线应用部分不工作，导致小区状态不能复位，感觉就像交换机侧没有添加小区数据一样，检查交换机，小区数据正确。
这时想到重启信令，当在BSC，MSC侧重启MTL无效，重启交换侧信令单元（SCU）系统立时工作正常。
怀疑在交换或无线某一侧对信令激活有问题，或两侧信令参数不匹配造成。
吴国建
bsc不用重启，就是和msc配合的问题，像阿尔卡特的这种情况我遇到过
详细描述
以下讨论是关于某市X694无法登陆问题和处理方法。
RXCDR是网络中的二级网元。
该网元无法正常监控将无法得知具体该网员的工作状态。
我将此次排障的过程总结，给大家一个参考，同时大家可以通过该例子总结经验和不足。
涉及的硬件：
XCDR
软件版本：
1760.21-t6
解决步骤
问题描述：
第一阶段：
2006年7月12日1：
00接到局方告知，X694出现无法登陆的故障，请求MOTO配合解决。
赶往现场取检查网员状态，取出LOG文件。
检查网员发现OML为B-U.
[12/07/0613:
46:
32]MMI-RAM011b->state0oml**
DEVICESTATUSINFORMATIONFORLOCATION0:
OPERSTATES:
D:
DisabledE:
EnabledB:
Busy
ADMINSTATES:
L:
LockedU:
UnlockedE:
EquippedS:
Shutdown
LastTransitionRelated
DeviceStateReasondd/mmhh:
mm:
ssFunction
-----------------------------------------------------------------------
OML000E-UNOREASON19/0603:
25:
50None
OML100B-UNOREASON12/0713:
24:
56None
[12/07/0613:
49:
53]MMI-RAM011b->state0oml**
DEVICESTATUSINFORMATIONFORLOCATION0:
OPERSTATES:
D:
DisabledE:
EnabledB:
Busy
ADMINSTATES:
L:
LockedU:
UnlockedE:
EquippedS:
Shutdown
LastTransitionRelated
DeviceStateReasondd/mmhh:
mm:
ssFunction
-----------------------------------------------------------------------
OML000B-UNOREASON12/0713:
49:
38None
OML100E-UNOREASON12/0713:
49:
52None
ENDOFSTATUSREPORT
通过倒换OML，复位OML等操作都无法远程登陆该网员。
最奇怪的是OML为B-U而无法登陆。
初步认为是软件出现问题。
检查SWFM发现有如下信息：
SWFMLogEntry17
51NonfatalSWFMErrorRoutine:
data_request_c3
51Area:
0x0000030bError:
0x0000000dPC:
0xc0006232PID:
0x72（Agent）
51BSSRelease:
1.7.6.f0.71ObjVersion:
1.7.6.0.21ExecVersion:
1.7.6.21.3
5112-Jul-200612:
06:
13.990Subsystem:
0x01CPU:
0x011bBoard:
GPROC2RAM
51MaxTxcreditretrycountreached;disconnectingVC
SWFMLogEntry18
52NonfatalSWFMErrorRoutine:
parse_x25_msg.c
52Area:
0x0000030bError:
0x00000002PC:
0xc00036f2PID:
0x72（Agent）
52BSSRelease:
1.7.6.f0.71ObjVersion:
1.7.6.0.21ExecVersion:
1.7.6.21.3
5212-Jul-200612:
12:
13.995Subsystem:
0x01CPU:
0x011bBoard:
GPROC2RAM
52NetconC04038A0formsg1F11notfoundintables
检查EV_LOG中发现有如下信息：
#0-NOTAPPL-*NONE*.
linkFailureEvent-RXCDR-CSRXCDR694（CSRXCDR694:
SITE-0:
）:
0SITE-12/07/200612:
05:
54.
[30003]x25CircuitDown-FMIC-Critical
确定OML中断时间为12:
05:
54。
同时现场工程师发现该故障和2005年出现的X403（SR2056836）故障有许多相似之处。
开启SR2112728，和CNRC工程师取得联系，按照给的DCP取得响应的数据。
发送数据。
和CNRC沟通，初步确定为软件出现问题。
由以往的经验认为BSC某个进程出现问题导致该BSC出现无法登陆的故障。
本地工程师根据以往的经验，制定于晚上对X694重启，排除该故障。
同时要求CNRC根据取得的LOG文件，给出该问题根本原因的解释。
第二阶段：
2006年7月16日凌晨对X694进行重启。
现场工程师对网员进行登陆操作，可以正常进行。
同时在7月16日2：
28成功进行了UPLOAD操作。
#0-NOTAPPL-*NONE*.
uploadStartedEvent-RXCDR-CSRXCDR694-16/07/200602:
28:
09.
2-dbase-87257
#0-NOTAPPL-*NONE*.
uploadCompletedEvent-RXCDR-CSRXCDR694-16/07/200602:
28:
51.
2-dbase-87257
Swfm中有如下信息。
CM:
cmtommi_upload.c-databaseisuploadingtoOMC.
CM:
check_msgs.c-uploadisdone.
2006年17日局方又通报X694无法登陆。
现场工程师到达现场取得数据。
下午现场工程师再次赶往某市老八局X694机房。
检查X694状态。
将LOG文件发送CNRC确定原因。
检查XCDR694状态发现。
[17/07/0615:
06:
56]MMI-RAM011a->state0oml**
DEVICESTATUSINFORMATIONFORLOCATION0:
OPERSTATES:
D:
DisabledE:
EnabledB:
Busy
ADMINSTATES:
L:
LockedU:
UnlockedE:
EquippedS:
Shutdown
LastTransitionRelated
DeviceStateReasondd/mmhh:
mm:
ssFunction
-----------------------------------------------------------------------
OML000D-UGPROChasReset17/0701:
57:
23None
OML100D-UGPROChasReset17/0701:
57:
43None
ENDOFSTATUSREPORT
[17/07/0615:
06:
59]MMI-RAM011a->disp_p0
PROCESSORSTATUSINFORMATIONFORLOCATION0:
OPERSTATES:
D:
DisabledE:
EnabledB:
Busy
ADMINSTATES:
L:
LockedU:
UnlockedE:
EquippedNE:
NotEquipped
NC:
NotConnected
RelatedRelated
CPU#ProcessorNameStateReasonDeviceFunction
---------------------------------------------------------------------------
011aBSP00B-UNOREASONABSS450N/A
011bGPROC00E-UNOREASONN/AN/A
021aBSP10E-UNOREASONN/AN/A
021bN/ANEN/AN/AN/A
ENDOFSTATUSREPORT
检查BSP板SWFM发现有7130问题。
由上述状态确定无法登陆X694的原因为OMF板无法承载OML导致该故障发生。
于是进行复位OML操作后，使OML恢复B-U状态。
X694可以进行正常的登陆操作。
然而一旦进行UPLOAD操作OML马上中断又恢复到GPROChasReset状态。
在BSP板上发现有如下SWFM信息。
[17/07/0615:
06:
56]MMI-RAM011a->state0oml**
DEVICESTATUSINFORMATIONFORLOCATION0:
OPERSTATES:
D:
DisabledE:
EnabledB:
Busy
ADMINSTATES:
L:
LockedU:
UnlockedE:
EquippedS:
Shutdown
LastTransitionRelated
DeviceStateReasondd/mmhh:
mm:
ssFunction
-----------------------
升级会员 