常见告警故障处理及案例分析

1、 常见告警故障处理及案例分析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）

2、 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可能会消失TDMTime Division Multiplexing时分复用：该总线用于把来自BTS的呼叫与信令数据

3、传送到MSC，反之亦然。可分为两个独立的部分：交换机公共通路&出局公共通路。交换机公共通路：处理路由到交换机的数据，数据来自外部信源 (通过E1/T1接口)或由GPROC内部产生。出局公共通路：这是一个被交换的数据，现在被路由出BSC/RXCDR (通过E1/T1接口)或通向内部GPROC。 4. DRI 81：Transmitter Synthesizer Failure收发单元故障此告警为收发单元TCU故障，故障原因有可能为：-接收Calibration频点丢失-信道盘的CEB故障-射频电缆连接失败处理方法：远程ins或reset TCU,告警消失并监测；若告警未消失，更换TCU5

4、. DRI 86 ：Transmitter Failure输出功率失败，引起DRI退出服务。状态：D-U此告警是信道盘的功率放大器失败。应更换信道盘。6 DRI 91 ：Power Amplifier Power Low But Functioning信道盘的功率放大器输出功率低于门限，状态B-U。此告警有可能由于高温等原因引发，有些站经常性出现DRI91的盘则需要更换，以免因小区功率不平造成掉话。有时侯在现场看不见此告警，须从OMC的事件窗口检查。7 DRI 92 ：Power Amplifier Temperature High But Funncioning信道盘的功率放大器高温告警，但

5、可以工作。信道盘的功率放大器的高温多数是因机房高温，或机箱内的风扇故障造成的。在出现此告警后，信道盘的性能会下降。如温度过高，信道盘会自动闭塞。因此常出现此告警的信道盘应于以更换。8 DRI 112 （114） Receiver Synthesizer Failure接收单元合成器故障 此告警为收发单元内部故障，其主要原因大概有： -收发信单元内部直流供电故障-收发信单元内部硬件故障处理方法：远程ins或reset TCU,告警消失并监测；若告警未消失，更换TCU9 DRI 150: Receive Matrix Branch 1 control Link Failure接收矩阵支路控制失败，

6、状态: B-U 此告警M-CELL和Horizon中均有出现，伴随切换掉话，切换成功率低，呼叫建立成功率低导致的话务量减少。有时也会导致信道盘的path_balance值偏高。 其主要原因有： -有故障的接收矩阵即SURF -收发信单元与接收矩阵之间的同轴电缆断路 -收发信单元与接收矩阵之间的同轴电缆短路 -信道盘中的均衡器板控制电路出现故障 -SURF内部前-后端接口短路 -SURF内部前-后端接口断路根据现场判断具体情况更换硬件。10 DRI 152: Control Processor to Power Amplifier Communication Failure 处理器与功率放大器的

7、通信失败此告警是信道盘中的CEB及对PA的控制失败。首先对信道盘进行INS或RESET处理，不行再更换信道盘。 11 DRI 209 : Timeslot Configuration Failure信道分配失败 D-U小区资源管理器CRM为MS分配无线信道时在射频硬件上分配时隙失败。产生的原因有： -收发信单元TCU故障 -DRI软件故障 处理方法：远程ins或reset TCU,告警消失并监测；若告警未消失，更换TCU12 DRI 218 ：Timeslot Configuration Failure不健全的信道接收校验数值 此告警的出现时用指令：disp_cal_data <loca

8、tion> <device_name> <dev_id> <dev_id> <dev_id> 可看到基站接收数据校准值中出现80（错误的校准数据）， 还找到根本的原因，远程对硬件reset或ins均无作用，现场人员有时需更换新硬件设备而有时只需对信道盘开关电即可恢复，初步判断为硬件TCU(Horizon目前还未发现)接收单元问题。 13 DRI 234 ：Active Link Connection Failure主用链路与BTP的链接失败。状态：D-U此告警主要发生在M-CELL上，是主用BTP到DRI/TCU900的链接失败。其原因主要

9、分为： * 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之间的连接

10、和使用的光纤类型的问题。 *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

11、Reference Failure时钟参考失败 此告警为基站MSI板的时钟提取丢失 其主要原因有： -E1/T1链路故障 -没有MSI/NIU的时钟信号 -没有XCDR的时钟信号 -GCLK 时钟提取电路失败 处理方法：更换MCU或NIU,若仍然出现告警则需通过传输处理17 GCLK 4 : Phase Lock Lost时钟参考信号锁相丢失此告警有时会引起切换掉话或切换成功率低，有时没有影响，大多数是因为传输大网与移动网对时钟要求相距较大引起。 其主要原因有： -大多数情况是在E1/T1链路上偏移或不稳定的时钟超过所允许的极限而引起的时钟失锁。 -不正确的时钟源或 -GCLK硬件故障 -GC

12、LK 晶体振荡器由于老化不能长时间对信号源进行锁相处理方法：一般情况下先进行时钟重新校准或SWAP BTP到备边,若无作用则请传输中心处理。18 GCLK 8 ：主备时钟频差过大。此告警是由BTS的本振时钟主备频率偏差过大，应及时对时钟进行校准。M-CELL: 8000HZ.19 GCLK 14 : Phase Lock Failure时钟参考信号锁相失败 此告警有大多数时间会引起切换掉话或切换成功率低 其主要原因有： -GCLK硬件故障 -有问题的前时钟源 -规范问题20 GCLK 18: Not Operational主时钟不工作 此告警是由于基站主控板MCU不能建立正常的同步时钟初始化。

13、出现的原因：可能是由于固件故障，或是硬件老化。 出现此问题时应reset MCU,若告警未消失则需更换MCU；若告警消失，则不需在作进一步的观察。 GCLK 24 Bad Clock Source or OCXO (oscillator) :不精准的时钟源或有故障的时钟振荡器。 出现此告警时先reset site 或主控倒到备边，若还存在告警则需传输帮助解决。 21 GCLK 26: GCLK Calibration Request GCLK校准失败 此告警有大多数时间会引起切换掉话或切换成功率低 其主要原因有：-GCLK 校准超出要求范围（即不能进行校准）-有问题的GCLK时钟源或时钟源超出

14、传输要求规范-在MCU第一次加电时不能进行校准，因此不能计算LTA值-GCLK长时间不能进行锁相，超出允许时间-GCLK 硬件故障处理方法：更换MCU另：LTALong 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）二、内部告警内部告警的告警设备一般为基站的辅助设备如风

15、扇、保险、开关、电源模块等。1 IAS 86#cabinet fan failure：基站风扇故障2 IAS 81 ：PSU供电单元输出失败。通过计算机检测电源模块，判定故障及时更换。 3 IAS 95 ：低噪音放大器保险坏。M-CELL对于GSM900的选件中没有采用低噪音放大器。所以此告警对DCS1800基站有影响。解决措施为：更换对应的保险。 对于内部告警，除一般的高温和风扇告警，其他一些内部告警一般为假告警，不与处理。 告警网元告警号及描述处理建议BTSDRI 29：Front End Processor Failure - Watchdog Timer Expired应先reset

16、or ins DRI应进行INS或RESET处理，若告警未消失，更换TCUBTSDRI 40-47：Channel Coder Timeslot 0（-7） FailureINS或RESET处理，不行再更换TCUBTSDRI 81：Transmitter Synthesizer Failureins或reset TCU，告警消失并监测；若告警未消失，更换TCUBTSDRI 86：Transmitter Failure更换TCUBTSDRI 91：Power Amplifier Power Low But Functioning如果是大量经常出现的就应该更换TCUBTSDRI 92：Power

17、Amplifier Temperature High But Funncioning如果是大量经常出现的就应该更换TCUBTSDRI 112: （114） Receiver Synthesizer Failureins或reset TCU，告警消失并监测；若告警未消失，更换TCUBTSDRI 150: Receive Matrix Branch 1 control Link Failure根据现场判断具体情况更换硬件(包括surf,Dri,cable)BTSDRI 152: Control Processor to Power Amplifier Communication Failure首先

18、对TCU进行INS或RESET处理，不行再更换TCUBTSDRI 209: Timeslot Configuration Failureins或reset TCU，告警消失并监测；若告警未消失，更换TCUBTSDRI 218：Invalid Transceiver Calibration Data安排工程师到现场调测BTSDRI 234：Active Link Connection Failureins或reset TCU，告警消失并监测；若告警未消失，安排工程师到现场检查TCU900/FOX/FMUX/BTP或者是FOX/FMUX/BTP之间的连接和使用的光纤类型的问题BTSDRI 235：

19、Standby Link Connection Failure如果是大量经常出现的就安排工程师到现场检查TCU900/FOX/FMUX/BTP或者是FOX/FMUX/BTP之间的连接和使用的光纤类型的问题BTSDRI 243：Unlocked Device Not In ServiceRESET THE DRI观察，如果告警仍然存在这更换TCUBTSGCLK 2: Clock Reference Failure更换MCU或NIU，若仍然出现告警则需通过传输处理BTSGCLK 4: Phase Lock Lost一般情况下先用命令reattepmt_pl来让MCU进行时钟重锁，若仍然无法锁相，则

20、检查时钟无法锁相的基站是否在同一个传输环上，若无法锁相的基站在同一个传输环上则请传输中心处理，若无法锁相的基站之间没有什么共性，则先对基站传输挂表测试，确定传输没有问题后，对主背用的MCU（MCUF）进行更换，对NIU也同时更换BTSGCLK 18: Not Operational出现此问题时应reset MCU，若告警未消失则需更换MCU；BTSGCLK 24 Bad Clock Source or OCXO (oscillator) 出现此告警时先reset site 或主控MCU倒到备边，若还存在告警则更换MCU,或者安排传输帮助解决BTSGCLK 26: GCLK Calibratio

21、n Request更换MCUBTSBTP 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

22、掉话问题可能产生的原因：1、突发事件（突然增高的话务量、相临基站断站等）2、基站硬件问题可能会造成基站SD产生掉话。（载频、发射通路、合路器、时钟问题等）3、基站天馈性能不好可能会造成基站SD掉话。4、基站天馈接错可能会造成基站SD掉话。5、基站数据设置错误可能会造成基站掉话。（CCB类型、CCB cavity号定义错误等）6、频率问题可能会造成基站掉话。（同频、邻频干扰或基站上行干扰等）7、基站相邻小区定义错误可能造成基站掉话。（产生SD切换掉话）关于TCH掉话的问题 基站掉话问题是GSM网络运行过程中一个比较常见的问题，由于产生掉话问题的原因较多，因此很难对掉话问题按其产生的原因进行一个较

23、为准确的分类。在现网的统计中，将掉话问题按其归属分成了四类：单载频掉话（Rf_losses_tch）；BTS内小区间切换掉话（Intra_cell_ho_lost）；BSC内小区间切换掉话（Out_intra_bss_ho_lost）；BSC间小区间切换掉话（Out_inter_bss_ho_clear）。第一部分：掉话问题可能产生的原因 由于掉话问题较为复杂很难准确定位，因此此处我们仅列出在现网中较为常见的几种引起掉话的原因：一 基站硬件问题可能会造成基站产生掉话。（载频、发射通路、接收通路、时钟问题等）二 基站天馈性能不好可能会造成基站掉话。三 基站天馈接错可能会造成基站掉话。四 基站数据

24、数据设置错误可能会造成基站掉话。（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.

25、14% 1 0.20.4% 0.28% 2 0.40.8% 0.57% 3 0.81.6% 1.13% 4 1.63.2% 2.26% 5 3.26.4% 4.53% 6 6.412.8% 9.05% 7 >12.8% 18.1%一般情况下认为Rxquality在不大于4的时的通话话音质量是可以接受的。但当Rxquality大于4时则会出现通话断续、杂音甚至掉话的现象。因此从对应关系可以看出，当载频的BER高于2.26%的时候，即说明该载频的通话质量有问题了，应该尽快进行处理。第一部分：BER高的原因造成载频BER高的原因主要有以下几种：一基站问题引起的BER高1、 信道盘的发射接收补偿

26、参数不合格2、 信道盘内部硬件和架顶发射接收器件故障二 频率干扰引起的BER高1、 同邻频干扰造成2、 上行干扰关于载频IOI高的问题 IOI（Interference On Idle）值的含义是：载频时隙在空闲状态时收到的上行干扰信号的强度。理想情况下，载频时隙在空闲状态即没有占用的情况下收到的上行信号功率应该为0,一般情况下IOI值 <1。只要IOI值 <5,那么对信道的影响就不会很严重，但若IOI值接近了10或超过了10 ，则会造成小区的掉话，通话质量下降等严重问题。第一部分：IOI值高的原因可以分为两方面一基站内部的接收设备障碍造成的IOI值高： 1信道盘的接收补偿值不准或

27、接收功能障碍2小区的接收器件DLNB或IADU、双工器故障3天馈线故障二外来的干扰源造成的上行干扰： 1GSM网络内部的干扰：即频率规划不当，同邻频过多造成的上行干扰。 2GSM网络外部的干扰：即外界非法直放站、集团通信系统非法占用GSM上行频段，或由于其它通信系统的设备的不合格，发射信号边带频谱干扰GSM上行频段。部分故障问题总结表:序号现象描述故障原因分析处理措施及人机命令处理效果1SD 拥塞sdcch_mean_holding_time is long, 相关GPROC负荷大吊死reassign site to other lcfsuccess2三个交换机间切换失败三个交换机间挂表进行信

28、令测试分析交换机打patchsuccess3SD 拥塞sdcch_mean_holding_time is long, SD traffic不大T3101延长=5000, channel_reconfig_switch=0, immediate_assign_mode=0负荷有所减轻4SD掉话,接通率差PATH_BANLANCE差数据库DRI天线选择号配置有问题恢复正常5小区不能与周围小区切换该小区GCLK失锁phase_lock_gclk=1 -> reattemp gclk -> 换GCLKsuccess6通话时对方听到无此号码随后掉话本地交换机900->1800切换存在

29、问题, 中继不够,话务走备分路由交换机增加900->1800中继, 备分路由数据改正(切换号码)success7call_setup_suc_rate低发生于同一交换机下BSC,告警中有 unequipcic.即交换机分配了该CIC,而BSC中未配置交换机锁住相关CICsuccess8呼叫无法接通大量用户在手机发出assignment complete之后，交换机即发回disconnect消息导致呼叫无法接通交换机打patchsuccess9单通信号强,分布式系统某些地方单通分布式系统一节天线问题success10通话话音质量差某交换机下串话,单通,每线爱尔兰超过0.5导致中继任意分配交

30、换机增加中继success11呼叫无法接通信号差,天馈线接反天馈线接反success12单通某BSS下单通严重,该序列号的GCLK寄存状态错误,主备用GCLK均被激活,各CBUS时钟失去同步GCLK 重新编制程序success13单通BSS側CIC号码对应交换机的CIC号码是错误的CIC号码一一对应success14OMC统计问题统计表中有多余小区，而CM中没有登录到SYS中，/usr/gsm/current/sbin 命令delete_CELLCM与PM一致15OMC统计问题PM窗口无法打开ps -ef | grep app; 杀死所有非root用户的进程吊死进程全部清除,PM正常16OMC

31、统计问题话务量不高,拥塞严重。话务统计可能不正确。增大busy_tch各bin值门限防止溢出17EFRFR->EFR信道不能转换FR的交换机也需打开EFR开关success18呼叫无法接通1800在手机发出assignment complete之后，交换机即发回disconnect消息导致呼叫无法接通900->1800交换机信令模块重启有所改善19通话话音质量差加载在话音上的尖锐声音可能是电路上的某些硬件问题,如XCDR上的MSI或交换机的中继模块success20呼叫无法接通手机发出assignment complete之后，交换机即发回disconnect消息导致呼叫无法接通A

32、LCATEL 的4版交换机开EFR而BSC未开，出现此现象，交换机升7版，可解决问题。success21呼叫无法接通sdcch_access_failure_rate=70修改bcch或硬件DRI排障success22双频网间不能切换路测发现900->900后5ter消息丢失，HOREQ消息中CLM3编码为00（应为50)相关交换机mapversion重创一下success23双频网间不能切换路测发现900->900后5ter消息丢失，HOREQ消息中CLM3编码为00（应为50)相关交换机版本不支持CLM3，交换机升级success24单通手机用户只能听到自己的回音话音通路的某一

33、设备出现故障,硬件排障success25通话话音质量差MS-MS 话音断续该地区无线覆盖差,调整覆盖success26通话话音质量差手机用户只能听到尖锐的金属声,MS的话音编码方式与BSC不一致(EFR)交换机间关于EFR的信令有问题success27统计中看到相同的LAC下出现不同 'page_req_from_msc' 检查BSC告警，发现存在如下告警：BSS ALARM 26 : Received Page for Invalid Cell from MSC 仔细检查此LAC所对应交换机下所有的小区号，发现存在错误小区号。删除这些cell id。success28用dis

34、p_cells_s命令看到的sdcch数量和该小区sdcch_prefer不一致。可能是因为SDCCH负载过大引起软件问题。检查该小区的每个RTF上的SDCCH负荷后发现达到0.9erl以上。增加SDCCH数量后问题解决。有所改善29从统计看，小区有话务量但是total_call=0。这是由于在数据库中access_cell_bar =1, en_income_ho=1导致。检查数据库，将access_cell_bar设为0success30从统计上看，某小区的CHAN_REQ_PAGE_RESP 值要远远大于 PAGE_RESPONSE值。经分析发现该小区存在严重的SDCCH拥塞现象，导致寻

35、呼相应消息不能发送上来。检查SDCCH Loading，增加SDCCH配置。恢复正常31从统计上看，某小区MA_CMD_TO_MS_BLKD=0 但是 TCH拥塞率却非常高，即ALLOC_TCH_FAIL很高。分析此原因，发现该小区并没有任何拥塞现象存在。经过检查发现，数据库参数bssmap_t11 设置大于assign_successful，这是一个错误的设置，因为assign_successful是tch分配过程的超时保护器，BSSMAP_T11必须小于它。重新设置。恢复正常四：案例分析详见附录。案例1：信号不稳定【问题名称】信号不稳定【问题类别】 硬件故障【相关设备】天馈线【问题详细描述

36、】在距离基站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）方

37、式扩展 ，其中最后一个机架（也就是扩展机架）的6个扩展载频的IOI都比同扇区的其他非扩展载频高，基本上扩展载频IOI在34左右，而非扩展载频IOI都小于1。这种情况造成扩展载频的TCH分配优先级低于同扇区的其他非扩展载频，TCH loading rate大大低于非扩展载频，造成话务分担不平衡。【技术背景】BTS相关技术【问题解决步骤】（1）检查过该站的数据库，所有RTF的TCH分配优先权设置均为0，DRI数据库也符合实际配置；（2）该站采用短跳频，并且倒换RTF到其他载频，跟踪统计指标，发现故障只与载频DRI有关，与RTF无关，所以不会是外部频率干扰的问题；（3）检查过硬件连接均无问题，载频T

38、X/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

39、 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，PATH_BALANCE、IOI均正常。2. 检查参数CELL_BAR设置正确，没有关闭小区接入。 3检查MSC中定义的小区LAC号与BSC的小区LAC

40、号是否一致，检查后发现设置正确。 4重启基站BCCH后恢复正常。案例4：室内分布系统话音单通问题【问题名称】 室内分布系统话音单通问题【问题类别】 室内分布系统【相关设备】 光纤放大器【问题详细描述】 某重要场所室内覆盖较差，为了保障该地通话质量，移动公司专门安装了整套室内分布系统。分布系统安装之后，就出现在该地的手机下行话音非常清晰但是上行确根本听不清楚的现象。【技术背景】3. 分布系统的光纤线性放大器。光纤线性放大器是用在分布系统中长距离传输而使用的信号放大器。它有接收端，光纤传输和放大器三部分组成。线信放大器的线性范围和放大倍率是它的主要技术指标。当接收信号不在放大器的线性范围内，产生的

41、放大信号就不再是线性的。4. 摩托罗拉公司基于接收电平的功率控制算法。简单的说就是落在功率控制接收窗口之外，需要相应调整功率。【问题解决步骤】 由于只是这一个基站存在单通问题，所以我们把问题定位在基站和相应的分布系统上。我们发现基站的所有载频都存在该问题，所以与载频硬件无关。检查基站到BSC传输，也不存在传输质量问题。所以，问题更像是无线环境造成。通过实地使用tems手机测打，发现下行接收电平和话音质量都很好，这与手机听对方来电非常清楚相一致。Tems手机无法检测手机上行的接收电平和质量，所以我们采用在OMCR上CTP跟踪上行数据。通过对该基站255个呼叫的跟踪，我们发现该基站上行rxlev始

42、终大于20dbm以上，而上行quality却主要为57级，手机发射功率较低。为什么基站上行rxlev会出现始终大于20dbm的奇怪现象呢？我们就此问题与分布厂家进行交流，原来问题就是出在分布系统的光纤放大器上。这个厂家的线性放大器技术指标严重不合格，线性范围只有3db，超出此范围都严重变型。所以，导致手机无论如何功率控制，基站接收测的接收电平都在20dbm以上，而话音质量极差，导致上行根本听不清楚。最后，我们将所有的光线放大器去除，直接用7/8馈线连接，问题就解决了。案例5：MM接续时间过长【问题名称】 湖北省荆门移动MM接续时间过长【问题类别】 参数设置【相关设备】 MSC【问题详细描述】M

43、M拨打时，从发出Channel Request到收到Alerting消息，荆门移动耗时约6.8秒，而武汉为5.3秒。【技术背景】【问题解决步骤】对于同一系统，寻呼响应的快慢在一定程度上影响了接续的快慢，鉴于荆门系统的寻呼响应比武汉平均慢473ms，为此对荆门系统的寻呼分组进行重新设定。寻呼消息的复帧结构时长为235ms，荆门系统的寻呼分组为5，其对手机而言，帧长为1175ms；武汉系统的寻呼分组为2，其对手机而言，帧长为470ms，这样最大可能导致705ms的时延。在西门子交换机中，即使不采用CIPHERING过程，但无法在流程上消除，每次MM的接续，导致470ms的时延。再考虑到目前交换机的

44、二次寻呼设置（TPAG为5s），而A接口中测到的寻呼响应时间约为1.5s，则完全可以将TPAG改为3s。从而可以大幅度地减少二次寻呼时的接续时间。在Um接口，未采用跳频时，收到ASSIGNMENT COMMAND的延时为230ms；而采用跳频时，收到ASSIGNMENT COMMAND的延时为470ms，两者有240ms的延时，考虑到主、被叫，则有480ms的延时。案例6：手机空闲/通话过程突然信号全无【问题名称】手机空闲、通话过程中信号全无【问题类别】 路测问题【相关设备】天线覆盖【问题详细描述】客户投诉手机在空闲状态下和通话过程中存在手机信号突然全无，出现脱网或掉话现象【技术背景】参考路测

45、分析【问题解决步骤】现场使用TEMS T28S测试发现确实存在此类现象。1、空闲状态下手机出现了信号全无，信号变化主要集中在小区重选的时刻，原因是：无主覆盖信号，而且室内信号电平在-95dBm左右，手机在空闲状态下小区重选频繁。由于在室内的信号存在明显起伏变化，导致重选过程中会出现了明显的信号变化；开通室内分布系统，服务小区信号大于-85dBm，复测正常；2、通话状态下手机出现了信号全无：A、手机没有发生切换时但接收到的信号电平突然降到-108dBm，多次拨测发现此现象仅仅出现在该小区某块载频上，判断为硬件故障，更换载频后问题解决。B、DT测试中手机切换到目标小区后信号电平突然降到-100dB

46、m以下，检查目标基站没有发现相应硬件问题，检查发现该小区还存在与目标小区相同BCCH的相邻小区（BSIC不相同），这两个目标邻区分别覆盖两条垂直交叉的街道，手机的快速运动造成系统误判断，命令手机切换到错误的目标小区，接收到的信号电平非常低。修改其中一个小区的BCCH后问题解决。（本次测试中T28S在-104dBm时表现为信号全无）案例7：PCMCIA卡故障造成基站不能正常CODE LOAD【问题名称】PCMCIA卡故障【问题类别】 硬件故障【相关设备】PCMACIA卡【问题详细描述】某个基站开通正常后，拨打测试通话也正常。但是运行一段时间后就会反复loading基站不能正常服务【技术背景】1C

47、SFP下载过程中的问题【问题解决步骤】1到现场测试发现原来SC0中的PCMCIA卡有故障造成基站在下载数据时由于要检测SC0板及板中的PCMCIA卡，当SC0中有卡时，BSC在下载DATABAIS会给该卡写数据，由于PCMCIA卡本身故障造成BSC反反复复不断的检查不停Loading,造成数据正常不能下载SC0板导致基站不能重启到正常状态。取出该PCMCIA卡后20分钟基站进入服务状态，拨打测试正常。案例8：避雷器故障造成基站IOI高【问题名称】避雷器故障造成基站IOI高【问题类别】 硬件故障【相关设备】避雷器【问题详细描述】高ma_fail_from_ms，所有载波都比较高，且ioi较高（1

48、2-23）；通话质量差，掉话高【技术背景】1硬件损坏【问题解决步骤】1、调测基站收发，馈线的阻波比正常；2、更换基站的主要器件，如TCU、SURF等没有效果。3、DT测试信号强度正常，稍远处话音质量就变差； 4、最终更换避雷器件后，故障消除，指标正常 案例9：硬件连接与数据定义错误造成基站PB值高【问题名称】硬件连接与数据定义错误造成基站PB值高【问题类别】 硬件连接与数据定义错误【相关设备】DLNB【问题详细描述】对于一批基站的第三扇区，出现掉话率高，PATH_BALANCE 偏高的现象，该扇区的SDCCH RFLOSS也较高。【技术背景】1 硬件连接2 DATD BASIE【问题解决步骤】

49、1从统计看，此类基站的第三扇区的所有载频的PATH_BALANCE都偏低，显示扇区接收较差，而且不是个别载频的硬件问题。2. 由于该问题在第一、二扇区没有出现，所以非常令人奇怪。3. 检查该基站的数据库配置，三个扇区完全一样，所以很奇怪。4. 我们后来发现这些基站都是在2个机柜内配置3各扇区的，这就使我们想到了是否在硬件配置上与普通的3个机柜内分别配置三个扇区的基站有什么区别。最后我们发现原来是DLNB的连接问题。这些基站的第三扇区的接收天线是连接在第三个DLNB而不是常规的第一个。而我们的数据库设置中该扇区每个载频的antenna select number都是1。这样就造成了天馈接收问题。

50、5. 综上所述，每个载频的antenna select number必须与实际的DLNB连接相一致，否则就会造成严重的掉话问题。案例10：外部干扰【问题名称】外部干扰引起断噪【问题类别】外部干扰 【相关设备】外部干扰源【问题详细描述】重阳宾馆的205房呼叫体育宾馆的三楼过道,主叫小区为:51223,问题现象为:断噪.【技术背景】外部干扰引起断噪【问题解决步骤】1. 信号电平在75dbm,初步判断非覆盖弱造成 2.锁住载频，逐个拨打，均出现此问题 3.通过扫频，发现整个频段信号强度很均匀 4.定位为外部干扰，经过扫频仪测量后，定位了干扰源。案例11：分布系统引起起呼、被叫成功率低【问题名称】分布

51、系统引起起呼被叫成功率低【问题类别】分布系统 【相关设备】分布系统【问题详细描述】在测试中发现问题主要在局部发生，问题电话信令都为起呼/被叫在Channel Request后无SD分配命令。现场测试发现，占同一载频上通话，在问题区域手机接收电平不稳定，手机功率控制迟缓，而其以外区域手机接收正常电平稳定，手机功率控制灵敏【技术背景】分布系统问题【问题解决步骤】1. 检查分布系统的这条天线通路发现存在故障，处理后正常。案例12：分布系统天线设计不合理造成的问题【问题名称】分布系统引起起呼被叫成功率低【问题类别】室内系统/定点测试 【相关设备】室内分布系统【问题详细描述】某微蜂窝采用室内分布天线系统，从OMCR统计来看，在其忙时(19:0020:00)，由于主要话务量集中在2楼饭厅，接通率及切换成功率较高，分别在95和93以上，话务量在3.3爱尔兰左右，但在其他时段，平均话务量不超过0.8爱尔兰，接通率及切换成功率分别在89和 90左右【技术背景】分布系