常见告警故障处理及
案例分析
MOTOROLA基站的告警按故障设备可分为三类：设备告警、内部告警、外部告警。
一、设备常见告警
设备告警是硬件告警最常见也是最重要的告警，告警设备一般为基站的主要器件，它的告警类型就是它的设备类型。
1. DRI 29：[Front End Processor Failure - Watchdog Timer Expired] 前端处理器故障
DRI硬件故障，出现此告警时DRI可能会反复自启，可能会退服，应先reset or ins DRI应进行INS或RESET处理，若告警未消失，更换TCU。
2． DRI 40-47 ：[Channel Coder Timeslot 0（-7） Failure] 0-7时隙信道编码器失败。
M-CELL基站经常出现此类告警，应进行INS或RESET处理，不行再更换TCU900。此告警在GSR4时出现，升级到GSR5可能会消失。
3． DRI 51 ：[Baseband Hopping TDM Link Error]基带跳频TDM链路错误。
此告警有几种可能性：TDM-Highway BUS或KSW可能有问题。
DRIM的FEP，CCDSP可能有问题。
此告警须在现场具体测试分析。测试后判定故障点。
此告警在GSR4时出现，升级到GSR5可能会消失
TDM——Time Division Multiplexing时分复用：该总线用于把来自BTS的呼叫与信令数据传送到MSC，反之亦然。可分为两个独立的部分：交换机公共通路&出局公共通路。
交换机公共通路：处理路由到交换机的数据，数据来自外部信源 (通过E1/T1接口)或由GPROC内部产生。
出局公共通路：这是一个被交换的数据，现在被路由出BSC/RXCDR (通过E1/T1接口)或通向内部GPROC。
4. DRI 81：[Transmitter Synthesizer Failure]收发单元故障
此告警为收发单元TCU故障，故障原因有可能为：
-接收Calibration频点丢失
-信道盘的CEB故障
-射频电缆连接失败
处理方法：远程ins或reset TCU,告警消失并监测；若告警未消失，更换TCU
5. DRI 86 ：[Transmitter Failure]输出功率失败，引起DRI退出服务。状态：D-U
此告警是信道盘的功率放大器失败。应更换信道盘。
6． DRI 91 ：[Power Amplifier Power Low But Functioning]信道盘的功率放大器输出功率低于门限，状态B-U。
此告警有可能由于高温等原因引发，有些站经常性出现DRI[91]的盘则需要更换，以免因小区功率不平造成掉话。有时侯在现场看不见此告警，须从OMC 的事件窗口检查。
7． DRI 92 ：[Power Amplifier Temperature High But Funncioning]信道盘的功率放大器高温告警，但可以工作。
信道盘的功率放大器的高温多数是因机房高温，或机箱内的风扇故障造成的。在出现此告警后，信道盘的性能会下降。如温度过高，信道盘会自动闭塞。因此常出现此告警的信道盘应于以更换。
8． DRI 112 （114）[Receiver Synthesizer Failure]接收单元合成器故障此告警为收发单元内部故障，其主要原因大概有：
-收发信单元内部直流供电故障
-收发信单元内部硬件故障
处理方法：远程ins或reset TCU,告警消失并监测；若告警未消失，更换TCU
9． DRI 150: [ Receive Matrix Branch 1 control Link Failure]接收矩阵支路控制失败，状态: B-U
此告警M-CELL和Horizon中均有出现，伴随切换掉话，切换成功率低，呼叫建立成功率低导致的话务量减少。有时也会导致信道盘的path_balance值偏高。其主要原因有：
-有故障的接收矩阵即SURF
-收发信单元与接收矩阵之间的同轴电缆断路
-收发信单元与接收矩阵之间的同轴电缆短路
-信道盘中的均衡器板控制电路出现故障
-SURF内部前-后端接口短路
-SURF内部前-后端接口断路
根据现场判断具体情况更换硬件。
10． DRI 152: [Control Processor to Power Amplifier Communication Failure] 处理器与功率放大器的通信失败
此告警是信道盘中的CEB及对PA的控制失败。首先对信道盘进行INS或RESET处理，不行再更换信道盘。
11． DRI 209 : [Timeslot Configuration Failure]信道分配失败 D-U 小区资源管理器CRM为MS分配无线信道时在射频硬件上分配时隙失败。
产生的原因有：
-收发信单元TCU故障
-DRI软件故障
处理方法：远程ins或reset TCU,告警消失并监测；若告警未消失，更换TCU
12． DRI 218 ：[Timeslot Configuration Failure]不健全的信道接收校验数
值
此告警的出现时用指令：
disp_cal_data
对信道盘开关电即可恢复，初步判断为硬件TCU(Horizon目前还未发现)接收单
元问题。
13． DRI 234 ：[Active Link Connection Failure]主用链路与BTP的链接失败。状态：D-U
此告警主要发生在M-CELL上，是主用BTP到DRI/TCU900的链接失败。
其原因主要分为：
* FOX/FMUX/BTP之间的连接和使用的光纤类型的问题。
*TCU900/FOX/FMUX/BTP本身的问题。
*还有则是由于某种原因，使处理机运行过程出现问题，使其
与TCU900失去联系。这类情况可用LOCK-UNLOCK恢复。
14． DRI 235 ：[Standby Link Connection Failure]备用链路与BTP的链接
失败，对网络不造成影响。但如果出现整个机柜告警应当引起重视。以免基站主
用出现故障倒换到备边时，出现整个机柜不能工作。
此告警只出现在M-CELL，是备用BTP到DRI/TCU900的链接失败。
其原因主要分为：
* FOX/FMUX/BTP之间的连接和使用的光纤类型的问题。
*TCU900/FOX/FMUX/BTP本身的问题。
*有时侯如有大部分DRI出现此告警，有可能是没将BTP
做成冗余形式。
DRI 239 ：[Process Safe Test Audit Failure]
有可能是因为机房内高温造成，若不及时进行处理，会继续出现92#告警
15． DRI 243 ：[Unlocked Device Not In Service]信道盘退服 D-U 此告警出现在没有主告警的情况下信道盘退服
可能的原因是：系统错误导致的信道盘退服
处理方法：发现告警后,RESET THE DRI观察，如果告警仍然存在这更换信
道盘。
16. GCLK 2 :[Clock Reference Failure]时钟参考失败
此告警为基站MSI板的时钟提取丢失
其主要原因有：
-E1/T1链路故障
-没有MSI/NIU的时钟信号
-没有XCDR的时钟信号
-GCLK 时钟提取电路失败
处理方法：更换MCU或NIU,若仍然出现告警则需通过传输处理
17． GCLK 4 : [ Phase Lock Lost]时钟参考信号锁相丢失
此告警有时会引起切换掉话或切换成功率低，有时没有影响，大多数是因为传输大网与移动网对时钟要求相距较大引起。
其主要原因有：
-大多数情况是在E1/T1链路上偏移或不稳定的时钟超过所允许的极限而引起的时钟失锁。
-不正确的时钟源或
-GCLK硬件故障
-GCLK 晶体振荡器由于老化不能长时间对信号源进行锁相
处理方法：一般情况下先进行时钟重新校准或SWAP BTP到备边,若无作用则请传输中心处理。
18． GCLK [8] ：主备时钟频差过大。
此告警是由BTS的本振时钟主备频率偏差过大，应及时对时钟进行校准。M-CELL: 8000HZ.
19． GCLK 14 : [Phase Lock Failure]时钟参考信号锁相失败
此告警有大多数时间会引起切换掉话或切换成功率低
其主要原因有：
-GCLK硬件故障
-有问题的前时钟源
-规范问题
20． GCLK 18: [Not Operational]主时钟不工作
此告警是由于基站主控板MCU不能建立正常的同步时钟初始化。
出现的原因：可能是由于固件故障，或是硬件老化。
出现此问题时应reset MCU,若告警未消失则需更换MCU；若告警消失，则不需在作进一步的观察。
GCLK 24[Bad Clock Source or OCXO (oscillator) ]:不精准的时钟源或有故障的时钟振荡器。
出现此告警时先reset site 或主控倒到备边，若还存在告警则需传输帮助解决。
21． GCLK 26: [GCLK Calibration Request] GCLK校准失败
此告警有大多数时间会引起切换掉话或切换成功率低
其主要原因有：
-GCLK 校准超出要求范围（即不能进行校准）
-有问题的GCLK时钟源或时钟源超出传输要求规范
-在MCU第一次加电时不能进行校准，因此不能计算LTA值
-GCLK长时间不能进行锁相，超出允许时间
-GCLK 硬件故障
处理方法：更换MCU
另：LTA——Long Term Average.长期平均值。BTS的GCLK频率寄存器为产生一个16.384MHz的时钟所需的值。
22．BTP [39]: 软件故障
此告警出现时会引起BTP D-U Code Load Failure或反复code load .
其主要原因有：
-下载的软件故障
-主控GPROC故障
处理方法：1.进emon reset site,并观察
2.更换MCU（或SWAP BTP）
二、内部告警
内部告警的告警设备一般为基站的辅助设备如风扇、保险、开关、电源模块等。
1． IAS 86#[cabinet fan failure]：基站风扇故障
2． IAS [81] ：PSU供电单元输出失败。
通过计算机检测电源模块，判定故障及时更换。
3． IAS [95] ：低噪音放大器保险坏。
M-CELL对于GSM900的选件中没有采用低噪音放大器。所以此告警对DCS1800基站有影响。解决措施为：更换对应的保险。
对于内部告警，除一般的高温和风扇告警，其他一些内部告警一般为假告警，不与处理。
告警网元告警号及描述处理建议
BTS DRI 29：[Front End Processor Failure -
Watchdog Timer Expired
应先reset or ins DRI应进行INS或RESET处理，
若告警未消失，更换TCU
BTS DRI 40-47：[Channel Coder Timeslot 0
（-7） Failure
INS或RESET处理，不行再更换TCU
BTS DRI 81：[Transmitter Synthesizer
Failure]
ins或reset TCU，告警消失并监测；若告警未消
失，更换TCU
BTS DRI 86：[Transmitter Failure] 更换TCU
BTS DRI 91：[Power Amplifier Power Low But 如果是大量经常出现的就应该更换TCU
Functioning
BTS DRI 92：[Power Amplifier Temperature
High But Funncioning
如果是大量经常出现的就应该更换TCU
BTS DRI 112: （114）[ Receiver Synthesizer
Failure
ins或reset TCU，告警消失并监测；若告警未消
失，更换TCU
BTS DRI 150: [ Receive Matrix Branch 1
control Link Failure
根据现场判断具体情况更换硬件(包括
surf,Dri,cable)
BTS DRI 152: [Control Processor to Power
Amplifier Communication Failure
首先对TCU进行INS或RESET处理，不行再更换
TCU
BTS DRI 209: [Timeslot Configuration
Failure
ins或reset TCU，告警消失并监测；若告警未消
失，更换TCU
BTS DRI 218：[Invalid Transceiver
Calibration Data
安排工程师到现场调测
BTS DRI 234：[Active Link Connection
Failure
ins或reset TCU，告警消失并监测；若告警未消
失，安排工程师到现场检查TCU900/FOX/FMUX/BTP
或者是FOX/FMUX/BTP之间的连接和使用的光纤类
型的问题
BTS DRI 235：[Standby Link Connection
Failure
如果是大量经常出现的就安排工程师到现场检查
TCU900/FOX/FMUX/BTP或者是FOX/FMUX/BTP之间
的连接和使用的光纤类型的问题
BTS DRI 243：[Unlocked Device Not In
Service
RESET THE DRI观察，如果告警仍然存在这更换TCU
BTS GCLK 2: [Clock Reference Failure 更换MCU或NIU，若仍然出现告警则需通过传输处
理
BTS GCLK 4: [Phase Lock Lost 一般情况下先用命令reattepmt_pl来让MCU进行时钟重锁，若仍然无法锁相，则检查时钟无法锁相的基站是否在同一个传输环上，若无法锁相的基站在同一个传输环上则请传输中心处理，若无法锁相的基站之间没有什么共性，则先对基站传输挂表测试，确定传输没有问题后，对主背用的MCU（MCUF）进行更换，对NIU也同时更换
BTS GCLK 18: [Not Operational 出现此问题时应reset MCU，若告警未消失则需更
换MCU；
BTS GCLK 24[Bad Clock Source or OCXO
(oscillator)
出现此告警时先reset site 或主控MCU倒到备
边，若还存在告警则更换MCU,或者安排传输帮助
解决
BTS GCLK 26: [GCLK Calibration Request 更换MCU
BTS BTP [39]: 软件故障reset MCU,若没有好转则更换MCU 三：常见问题分析
关于SD掉话的问题
SDCCH是Stand-alone Dedicated Control Channel 的缩写,其意思是独立专用控制信道。其作用是A GSM control channel where the majority of call setup occurs .Used for MS to BTS communications before MS assigned to TCH。是指建立呼叫时主要使用的GSM 控制信道。用于在MS分配给TCH之前MS与BTS的通信。
SD掉话问题可能产生的原因：
1、突发事件（突然增高的话务量、相临基站断站等）
2、基站硬件问题可能会造成基站SD产生掉话。（载频、发射通路、合路器、时钟问题等）
3、基站天馈性能不好可能会造成基站SD掉话。
4、基站天馈接错可能会造成基站SD掉话。
5、基站数据设置错误可能会造成基站掉话。（CCB类型、CCB cavity号定义错误等）
6、频率问题可能会造成基站掉话。（同频、邻频干扰或基站上行干扰等）
7、基站相邻小区定义错误可能造成基站掉话。（产生SD切换掉话）
关于TCH掉话的问题
基站掉话问题是GSM网络运行过程中一个比较常见的问题，由于产生掉话问题的原因较多，因此很难对掉话问题按其产生的原因进行一个较为准确的分类。在现网的统计中，将掉话问题按其归属分成了四类：单载频掉话（Rf_losses_tch）；BTS内小区间切换掉话（Intra_cell_ho_lost）；BSC内小区间切换掉话（Out_intra_bss_ho_lost）；BSC间小区间切换掉话（Out_inter_bss_ho_clear）。
第一部分：掉话问题可能产生的原因
由于掉话问题较为复杂很难准确定位，因此此处我们仅列出在现网中较为常见的几种引起掉话的原因：
一．基站硬件问题可能会造成基站产生掉话。（载频、发射通路、接收通路、时钟问题等）二．基站天馈性能不好可能会造成基站掉话。
三．基站天馈接错可能会造成基站掉话。
四．基站数据数据设置错误可能会造成基站掉话。（CCB类型、CCB cavity号定义错误等）五．频率问题可能会造成基站掉话。（同频、邻频干扰或基站上行干扰等）
六．基站相邻小区定义错误可能造成基站掉话。
关于载频BER高的问题
载频的BER（Bit Error Rate）含义是载频工作的时候在其上传输的数字信息比特的比特误码率。
载频的BER和在该载频上通话时的通话质量是密切相关的。手机在通话时的话音质量有8个级别，即Quality=0,1,2,3,4,5,6,7 。0是最好，7为最差。而Quality的0到7是和BER分别对应的。对应关系如下：
Rxquality BER 默认BER
0 <0.2% 0.14%
1 0.2—0.4% 0.28%
2 0.4—0.8% 0.57%
3 0.8—1.6% 1.13%
4 1.6—3.2% 2.26%
5 3.2—6.4% 4.53%
6 6.4—12.8% 9.05%
7 >12.8% 18.1%
一般情况下认为Rxquality在不大于4的时的通话话音质量是可以接受的。但当Rxquality大于4时则会出现通话断续、杂音甚至掉话的现象。因此从对应关系可以看出，当载频的BER高于2.26%的时候，即说明该载频的通话质量有问题了，应该尽快进行处理。第一部分：BER高的原因
造成载频BER高的原因主要有以下几种：
一．基站问题引起的BER高
1、信道盘的发射接收补偿参数不合格
2、信道盘内部硬件和架顶发射接收器件故障
二．频率干扰引起的BER高
1、同邻频干扰造成
2、上行干扰
关于载频IOI高的问题
IOI（Interference On Idle）值的含义是：载频时隙在空闲状态时收到的上行干扰信号的强度。理想情况下，载频时隙在空闲状态即没有占用的情况下收到的上行信号功率应该为0,一般情况下IOI值 <1。只要IOI值 <5,那么对信道的影响就不会很严重，但若IOI值接近了10或超过了10 ，则会造成小区的掉话，通话质量下降等严重问题。
第一部分：IOI值高的原因可以分为两方面
一．基站内部的接收设备障碍造成的IOI值高：
1．信道盘的接收补偿值不准或接收功能障碍
2．小区的接收器件DLNB或IADU、双工器故障
3．天馈线故障
二．外来的干扰源造成的上行干扰：
1．GSM网络内部的干扰：即频率规划不当，同邻频过多造成的上行干扰。
2．GSM网络外部的干扰：即外界非法直放站、集团通信系统非法占用GSM上行频段，或由于其它通信系统的设备的不合格，发射信号边带频谱干扰GSM上行频段。
部分故障问题总结表:
四：案例分析详见附录。
案例1：信号不稳定
【问题名称】
信号不稳定
【问题类别】
硬件故障
【相关设备】
天馈线
【问题详细描述】
在距离基站200处的小村庄，在直视基站的情况下，手机接收信号漂移达30dbm,
基站天线高60米。
【技术背景】
1．参考无线原理中上下性平衡进行计算
2．参考天线电气参数
3. 驻波比计算与正常值
【问题解决步骤】
1．检查架顶功率，发现没有问题，按设计要求设置
2．测驻波比，用常规功率检查没发现问题，用SITE MASTER检查发现在50米处驻波达1.6。
降低天线高度至50米，重换馈线后，问题解决。
案例2：载频IOI值高的问题
【问题名称】
8/8/8基站最后一个机柜的载频IOI高且话务量少
【问题类别】
硬件故障
【相关设备】
BTS相关设备
【问题详细描述】
MCELL6_8/8/8基站，采用6/6/6/（2，2，2）方式扩展，其中最后一个机架（也就是扩展机架）的6个扩展载频的IOI都比同扇区的其他非扩展载频高，基本上扩展载频IOI在3～4左右，而非扩展载频IOI都小于1。这种情况造成扩展载频的TCH分配优先级低于同扇区的其他非扩展载频，TCH loading rate大大低于非扩展载频，造成话务分担不平衡。
【技术背景】
BTS相关技术
【问题解决步骤】
（1）检查过该站的数据库，所有RTF的TCH分配优先权设置均为0，DRI数据库也符合实际配置；
（2）该站采用短跳频，并且倒换RTF到其他载频，跟踪统计指标，发现故障只与载频DRI 有关，与RTF无关，所以不会是外部频率干扰的问题；
（3）检查过硬件连接均无问题，载频TX/RX调测时均正常，更换过载频/CEB（接收扩展模块）后，故障仍存在；
（4）DRI调测时，增大DRI 0 6/0 7接收补偿，跟踪观察，故障未解决；
（5）更换扩展机架IADU，各扇区TCH的平均占用略有好转，特别是3扇区改善明显，但IOI 仍比非扩展机柜的载频偏高；
（6）检查机柜IADU的扩展开关DIP SWITCH，一切正常，但有部分RESERVE的IADU开关被置为ON，这些开关是不用的，把它改置为OFF状态再观察是否有影响，结果未解决；
（7）检查该站室外天馈线连接，发现都正常，交叉3扇区的两根天馈线试验，未解决；（8）修改该站RF频率规划，3扇区改善，已正常，1扇区未改善；
（9）将DRI 03/04和DRI 06/07对调，发现IOI高的问题在原载频DRI 06/07（现载频DRI 03/04）上；
案例3：无法作主叫的问题
【问题名称】
无法作主被叫
【问题类别】
硬件故障
【相关设备】
CTU
【问题详细描述】
现场测试时发现手机上接收信号较好，用户就是无法作主被叫。
【技术背景】
参考主被叫呼叫流程
【问题解决步骤】
1.检查统计发现TOTAL_CALL为0 ，有话务量，其他CHAN_REQ_MS_FAIL、
MA_FAIL_FROM_MS，PA TH_BALANCE、IOI均正常。
2.检查参数CELL_BAR设置正确，没有关闭小区接入。
3．检查MSC中定义的小区LAC号与BSC的小区LAC号是否一致，检查后发现设置正确。
4．重启基站BCCH后恢复正常。
案例4：室内分布系统话音单通问题
【问题名称】
室内分布系统话音单通问题
【问题类别】
室内分布系统
【相关设备】
光纤放大器
【问题详细描述】
某重要场所室内覆盖较差，为了保障该地通话质量，移动公司专门安装了整套室内分布系统。分布系统安装之后，就出现在该地的手机下行话音非常清晰但是上行确根本听不清楚的现象。
【技术背景】
3.分布系统的光纤线性放大器。光纤线性放大器是用在分布系统中长距离传输而使用
的信号放大器。它有接收端，光纤传输和放大器三部分组成。线信放大器的线性范围和放大倍率是它的主要技术指标。当接收信号不在放大器的线性范围内，产生的放大信号就不再是线性的。
4.摩托罗拉公司基于接收电平的功率控制算法。简单的说就是落在功率控制接收窗口
之外，需要相应调整功率。
【问题解决步骤】
由于只是这一个基站存在单通问题，所以我们把问题定位在基站和相应的分布系统上。我们发现基站的所有载频都存在该问题，所以与载频硬件无关。检查基站到BSC传输，也不存在传输质量问题。所以，问题更像是无线环境造成。
通过实地使用tems手机测打，发现下行接收电平和话音质量都很好，这与手机听对方来电非常清楚相一致。Tems手机无法检测手机上行的接收电平和质量，所以我们采用在OMCR 上CTP跟踪上行数据。通过对该基站255个呼叫的跟踪，我们发现该基站上行rxlev始终大于－20dbm以上，而上行quality却主要为5～7级，手机发射功率较低。为什么基站上行rxlev 会出现始终大于－20dbm的奇怪现象呢？我们就此问题与分布厂家进行交流，原来问题就是出在分布系统的光纤放大器上。这个厂家的线性放大器技术指标严重不合格，线性范围只有3db，超出此范围都严重变型。所以，导致手机无论如何功率控制，基站接收测的接收电平都在－20dbm以上，而话音质量极差，导致上行根本听不清楚。最后，我们将所有的光线放大器去除，直接用7/8馈线连接，问题就解决了。
案例5：M－M接续时间过长
【问题名称】
湖北省荆门移动M－M接续时间过长
【问题类别】
参数设置
【相关设备】
MSC
【问题详细描述】
M－M拨打时，从发出Channel Request到收到Alerting消息，荆门移动耗时约6.8秒，而武汉为5.3秒。
【技术背景】
【问题解决步骤】
对于同一系统，寻呼响应的快慢在一定程度上影响了接续的快慢，鉴于荆门系统的寻呼响应比武汉平均慢473ms，为此对荆门系统的寻呼分组进行重新设定。寻呼消息的复帧结构时长为235ms，荆门系统的寻呼分组为5，其对手机而言，帧长为1175ms；武汉系统的寻呼分组为2，其对手机而言，帧长为470ms，这样最大可能导致705ms的时延。
在西门子交换机中，即使不采用CIPHERING过程，但无法在流程上消除，每次M－M的接续，导致470ms的时延。
再考虑到目前交换机的二次寻呼设置（TPAG为5s），而A接口中测到的寻呼响应时间约为1.5s，则完全可以将TPAG改为3s。从而可以大幅度地减少二次寻呼时的接续时间。
在Um接口，未采用跳频时，收到ASSIGNMENT COMMAND的延时为230ms；而采用跳频时，收到ASSIGNMENT COMMAND的延时为470ms，两者有240ms的延时，考虑到主、被叫，则有480ms 的延时。
案例6：手机空闲/通话过程突然信号全无
【问题名称】
手机空闲、通话过程中信号全无
【问题类别】
路测问题
【相关设备】
天线覆盖
【问题详细描述】
客户投诉手机在空闲状态下和通话过程中存在手机信号突然全无，出现脱网或掉话现象
【技术背景】
参考路测分析
【问题解决步骤】
现场使用TEMS T28S测试发现确实存在此类现象。1、空闲状态下手机出现了信号全无，信号变化主要集中在小区重选的时刻，原因是：无主覆盖信号，而且室内信号电平在-95dBm 左右，手机在空闲状态下小区重选频繁。由于在室内的信号存在明显起伏变化，导致重选过程中会出现了明显的信号变化；开通室内分布系统，服务小区信号大于-85dBm，复测正常；
2、通话状态下手机出现了信号全无：A、手机没有发生切换时但接收到的信号电平突然降到-108dBm，多次拨测发现此现象仅仅出现在该小区某块载频上，判断为硬件故障，更换载频后问题解决。B、DT测试中手机切换到目标小区后信号电平突然降到-100dBm以下，检查目标基站没有发现相应硬件问题，检查发现该小区还存在与目标小区相同BCCH的相邻小区（BSIC不相同），这两个目标邻区分别覆盖两条垂直交叉的街道，手机的快速运动造成系统误判断，命令手机切换到错误的目标小区，接收到的信号电平非常低。修改其中一个小区的BCCH后问题解决。（本次测试中T28S在-104dBm时表现为信号全无）
案例7：PCMCIA卡故障造成基站不能正常CODE LOAD
【问题名称】
PCMCIA卡故障
【问题类别】
硬件故障
【相关设备】
PCMACIA卡
【问题详细描述】
某个基站开通正常后，拨打测试通话也正常。但是运行一段时间后就会反复loading基站不
能正常服务
【技术背景】
1．CSFP下载过程中的问题
【问题解决步骤】
1．到现场测试发现原来SC0中的PCMCIA卡有故障造成基站在下载数据时由于要检测SC0板及板中的PCMCIA卡，当SC0中有卡时，BSC在下载DA TABAIS会给该卡写数据，由于PCMCIA 卡本身故障造成BSC反反复复不断的检查不停Loading,造成数据正常不能下载SC0板导致基站不能重启到正常状态。取出该PCMCIA卡后20分钟基站进入服务状态，拨打测试正常。
案例8：避雷器故障造成基站IOI高
【问题名称】
避雷器故障造成基站IOI高
【问题类别】
硬件故障
【相关设备】
避雷器
【问题详细描述】
高ma_fail_from_ms，所有载波都比较高，且ioi较高（12-23）；通话质量差，掉话高【技术背景】
1．硬件损坏
【问题解决步骤】
1、调测基站收发，馈线的阻波比正常；
2、更换基站的主要器件，如TCU、SURF等没有效果。
3、DT测试信号强度正常，稍远处话音质量就变差；
4、最终更换避雷器件后，故障消除，指标正常
案例9：硬件连接与数据定义错误造成基站PB值高
【问题名称】
硬件连接与数据定义错误造成基站PB值高
【问题类别】
硬件连接与数据定义错误
【相关设备】
DLNB
【问题详细描述】
对于一批基站的第三扇区，出现掉话率高，PA TH_BALANCE 偏高的现象，该扇区的SDCCH RFLOSS也较高。
【技术背景】
1．硬件连接
2．DA TD BASIE
【问题解决步骤】
1．从统计看，此类基站的第三扇区的所有载频的PA TH_BALANCE都偏低，显示扇区接收较差，而且不是个别载频的硬件问题。
2. 由于该问题在第一、二扇区没有出现，所以非常令人奇怪。
3. 检查该基站的数据库配置，三个扇区完全一样，所以很奇怪。
4. 我们后来发现这些基站都是在2个机柜内配置3各扇区的，这就使我们想到了是否在硬件配置上与普通的3个机柜内分别配置三个扇区的基站有什么区别。最后我们发现原来是DLNB的连接问题。这些基站的第三扇区的接收天线是连接在第三个DLNB而不是常规的第一个。而我们的数据库设置中该扇区每个载频的antenna select number都是1。这样就造成了天馈接收问题。
5. 综上所述，每个载频的antenna select number必须与实际的DLNB连接相一致，否则就会造成严重的掉话问题。