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

1、常见告警故障处理及案例分析MOTORO基站的告警按故障设备可分为三类：设备告警、内部告警、外部口警。一、设备常见告警设备告警是硬件告警最常见也是最重要的告警，告警设备一般为基站的主 要器件，它的告警类型就是它的设备类型。1. DRI 29： Front End Processor Failure - Watchdog Timer Expired 前端处理器故障DRI硬件故障，出现此告警时DRI可能会反复自启，可能会退服，应先 reset or ins DRI应进行INS或RESETS理，若告警未消失，更换 TCU2. DRI 40-47 : Channel Coder Timeslot 0（-

2、7） Failure 0-7 时隙信 道编码器失败。M-CELL基站经常出现此类告警，应进行INS或RESE处理，不行再更换 TCU900此告警在GSR4寸出现，升级到GSR旳能会消失。3. DRI 51 : Baseband Hopping TDMLink Error基带跳频 TDM链路错误。 此告警有几种可能性：TDM-HighwayBUS或KSWT能有问题。DRIM的 FEP CCDS可能有问题。此告警须在现场具体测试分析。测试后判定故障点。此告警在GSR4寸出现，升级到GSR旳能会消失TDM Time Divisio nMultiplex ing 时分复用：该总线用于把来自 BTS的呼

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

4、RI 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 Bran ch 1 con trol Li nk Fa

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

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

8、cation 可看到基站接收数据校准值中出现 80 （错误的校准数据）还找到根本的原因， 远程对硬件reset或ins均无作用，现场人员有时需更换新硬件设备而有时只 需对信道盘开关电即可恢复，初步判断为硬件 TCU（Horizon目前还未发现）接收 单元问题。13. DRI 234 : Active Link ConnectionFailure主用链路与 BTP的链接失败。状态：D-U此告警主要发生在 M-CELL上，是主用BTP到DRI/TCU90O勺链接失败。 其原因主要分为：* FOX/FMUX/BT之间的连接和使用的光纤类型的问题。*TCU900/FOX/FMUX/BT本身的问题。*还

9、有则是由于某种原因，使处理机运行过程出现问题，使其与TCU90C失去联系。这类情况可用LOCK-UNLO（恢复。14. DRI 235 : Standby Link Connection Failure备用链路与 BTP的链接 失败，对网络不造成影响。但如果出现整个机柜告警应当引起重视。以免基站 主用出现故障倒换到备边时，出现整个机柜不能工作。此告警只出现在M-CELL是备用BTP到 DRI/TCU900的链接失败。其原因主要分为：* FOX/FMUX/BT之间的连接和使用的光纤类型的问题。*TCU900/FOX/FMUX/BT本 身的问题。*有时侯如有大部分DRI出现此告警，有可能是没将 B

10、TP做成冗余形式。DRI 239 : Process Safe Test Audit Failure有可能是因为机房内高温造成，若不及时进行处理，会继续出现92#告警15. DRI 243 : Unlocked Device Not In Service信道盘退服D-U此告警出现在没有主告警的情况下信道盘退服可能的原因是：系统错误导致的信道盘退服处理方法：发现告警后,RESET THE DRI观察，如果告警仍然存在这更换信 道盘。16. GCLK2 : Clock Referenee Failure时钟参考失败此告警为基站MSI板的时钟提取丢失其主要原因有：-E1/T1链路故障-没有MSI/N

11、IU的时钟信号-没有XCDR勺时钟信号 -GCLK时钟提取电路失败 处理方法：更换MCU或NIU,若仍然出现告警则需通过传输处理17. GCLK4 : Phase Lock Lost时钟参考信号锁相丢失此告警有时会引起切换掉话或切换成功率低，有时没有影响，大多数是因 为传输大网与移动网对时钟要求相距较大引起。其主要原因有：-大多数情况是在E1/T1链路上偏移或不稳定的时钟超过所允许的极限而 引起的时钟失锁。-不正确的时钟源或-GCLK硬件故障-GCLK晶体振荡器由于老化不能长时间对信号源进行锁相 处理方法：一般情况下先进行时钟重新校准或 SWAPBTP到备边,若无作用 则请传输中心处理。18.

12、 GCLK8:主备时钟频差过大。此告警是由BTS的本振时钟主备频率偏差过大，应及时对时钟进行校准M-CELL: 8000H Z.19. GCLK14 : Phase Lock Failure时钟参考信号锁相失败 此告警有大多数时间会引起切换掉话或切换成功率低 其主要原因有：-GCLK硬件故障-有问题的前时钟源-规范问题20. GCLK18: Not Operati on al主时钟不工作此告警是由于基站主控板MCI不能建立正常的同步时钟初始化。 出现的原因：可能是由于固件故障，或是硬件老化。出现此问题时应reset MCU若告警未消失则需更换MCU若告警消失，则 不需在作进一步的观察。GCLK

13、24 Bad Clock Source or OCXOfoscillator):不精准的时钟源或有故障的时钟振荡器。出现此告警时先reset site或主控倒到备边，若还存在告警则需传输帮助解决21. GCLK26: GCLKCalibrationRequest GCL!校准失败此告警有大多数时间会引起切换掉话或切换成功率低 其主要原因有：-GCLK校准超出要求范围（即不能进行校准）-有问题的GCLK寸钟源或时钟源超出传输要求规范-在MCI第一次加电时不能进行校准，因此不能计算 LTA值 -GCLK长时间不能进行锁相，超出允许时间-GCLK硬件故障处理方法：更换MCU另：LTALong Ter

14、m Average.长期平均值。BTS的GCLI频率寄存器为 产生一个16.384MHz的时钟所需的值。22. BTP39: 软件故障此告警出现时会引起 BTP D-U Code Load Failure 或反复code load 其主要原因有：-下载的软件故障-主控GPRO故障处理方法：1.进emon reset site,并观察2. 更换 MC（或 SWAFBTP、内部告警内部告警的告警设备一般为基站的辅助设备如风扇、保险、开关、电源模1. IAS 86#cabinet fan failure:基站风扇故障2. IAS 81: PSU供电单元输出失败。通过计算机检测电源模块，判定故障及时更

15、换。3. IAS 95:低噪音放大器保险坏。M-CELL对于GSM90的选件中没有采用低噪音放大器。所以此告警对 DCS180基站有影响。解决措施为：更换对应的保险。对于内部告警，除一般的高温和风扇告警，其他一些内部告警一般为假告 警，不与处理。告警网元告警号及描述BTSBTSBTSBTSDRI 29： Front End Processor Failure-Watchdog Timer ExpiredDRI 40-47 : Channel Coder Timeslot0 (-7) FailureDRI 81: TransmitterSynthesizerFailureDRI 86： Tran

16、smitter Failure处理建议应先reset or ins DRI应进行INS或RESET处理,若告警未消失，更换 TCUINS或RESET处理，不行再更换 TCUins或reset TCU告警消失并监测；若告警未消失，更换TCU更换TCUBTSBTSBTSBTSBTSBTSBTSBTSBTSBTSBTSBTSBTSBTSBTSBTSDRI 91: Power Amplifier Power LowBut FunctioningDRI 92： Power Amplifier TemperatureHigh But FunncioningDRI 112:(114) ReceiverSyn

17、 thesizerFailureDRI 150: Receive Matrix Bran ch 1controlLink FailureDRI 152: Control Processor to PowerAmplifier Commu ni cati on FailureDRI 209: Timeslot Con figurationFailureDRI 218 : InvalidTransceiverCalibrati onDataDRI 234: ActiveLink ConnectionFailureDRI 235 : Sta ndby Li nk Conn ectionFailure

18、DRI 243: Unlocked Device Not InServiceGCLK2: Clock Referenee FailureGCLK4: Phase Lock LostGCLK18: Not OperationalGCLK24 Bad Clock Source or OCXO(oscillator)GCLK26: GCLK Calibration RequestBTP 39:软件故障常见问题分析如果是大量经常岀现的就应该更换TCU如果是大量经常岀现的就应该更换TCUins或reset TCU,告警消失并监测；若告警未消失，更换TCU根据现场判断具体情况更换硬件（包括surf,Dri

19、,cable）首先对TCU进行INS或RESET处理，不行再更换TCUins或reset TCU，告警消失并监测；若告警未消失，更换TCU安排工程师到现场调测ins或reset TCU，告警消失并监测；若告警未消失，安排工程师到现场检查TCU900/FOX/FMUX/BTP或者是 FOX/FMUX/BTF之间的连接和使用的光纤类型的问题如果是大量经常岀现的就安排工程师到现场检查TCU900/FOX/FMUX/BTP或者是 FOX/FMUX/BTF之间的连接和使用的光纤类型的问题RESETTHE DRI观察，如果告警仍然存在这更换TCU更换MCU或 NIU，若仍然岀现告警则需通过传输处理一般情况

20、下先用命令 reattepmt_pl 来让MCU进行时钟重锁，若仍然无法锁相，则检查时钟无法锁 相的基站是否在同一个传输环上，若无法锁相的 基站在同一个传输环上则请传输中心处理，若无 法锁相的基站之间没有什么共性，则先对基站传 输挂表测试，确定传输没有问题后，对主背用的MCU（ MCUF进行更换，对 NIU也同时更换岀现此问题时应reset MCU若告警未消失则需更换MCU岀现此告警时先 reset site 或主控MCU倒到备 边，若还存在告警则更换MCU或者安排传输帮助解决更换MCUreset MCU若没有好转则更换 MCU关于SD掉话的问题SDCC是Stand-alone Dedicat

21、ed Control Channel的缩写,其意思是独立专用控制信道。其作用是 A GSM controlchannel where the majority of call setup occurs .Usedfor MS to BTS communications before MS assigned to TCH 是指建立呼叫时主要使用 的GSM控制信道。用于在 MS分配给TCH之前MS与BTS的通信。SD掉话问题可能产生的原因：1突发事件（突然增高的话务量、相临基站断站等）2、 基站硬件问题可能会造成基站SD产生掉话。（载频、发射通路、合路器、时钟问题等）3、 基站天馈性能不好可能会造

22、成基站SD掉话。4、 基站天馈接错可能会造成基站SD掉话。5、 基站数据设置错误可能会造成基站掉话。（CCB类型、CCB cavity号定义错误等）6、 频率问题可能会造成基站掉话。（同频、邻频干扰或基站上行干扰等）7、 基站相邻小区定义错误可能造成基站掉话。（产生SD切换掉话）关于TCH话的问题基站掉话问题是 GSM网络运行过程中一个比较常见的问题，由于产生掉话问题的原因较多，因此很难对掉话问题按其产生的原因进行一个较为准确的分类。在现网的统计中，将掉话问题按其归属分成了四类：单载频掉话（Rf_losses_tch ）； BTS内小区间切换掉话（Intra_cell_ho_lost ）; B

23、SC内小区间切换掉话（Out_intra_bss_ho_lost）； BSC间小区间切换掉话（Out_inter_bss_ho_clear）。第一部分：掉话问题可能产生的原因由于掉话问题较为复杂很难准确定位，因此此处我们仅列出在现网中较为常见的几种引起掉话的原因：一. 基站硬件问题可能会造成基站产生掉话。（载频、发射通路、接收通路、时钟问题等）二. 基站天馈性能不好可能会造成基站掉话。三. 基站天馈接错可能会造成基站掉话。四. 基站数据数据设置错误可能会造成基站掉话。（CCB类型、CCB cavity号定义错误 等）五. 频率问题可能会造成基站掉话。（同频、邻频干扰或基站上行干扰等）六. 基站

24、相邻小区定义错误可能造成基站掉话。关于载频BEF高的问题载频的BER（ Bit Error Rate）含义是载频工作的时候在其上传输的数字信息比特的比特误码率。载频的BER和在该载频上通话时的通话质量是密切相关的。手机在通话时的话音质量有 8 个级别，即卩 Quality=0,1,2,3,4,5,6,7是和BER分别对应的。对应关系如下：RxqualityBER。0是最好，7为最差。而 Quality的0到7默认BER012.8%18.1%般情况下认为Rxquality在不大于4的时的通话话音质量是可以接受的。但当Rxquality大于4时则会出现通话断续、杂音甚至掉话的现象。因此从对应关系可

25、以看出， 当载频的BER高于2.26%的时候，即说明该载频的通话质量有问题了，应该尽快进行处理。第一部分：BER高的原因造成载频BER高的原因主要有以下几种：一. 基站问题引起的 BER高1、信道盘的发射接收补偿参数不合格2、信道盘内部硬件和架顶发射接收器件故障二. 频率干扰引起的BER高1、同邻频干扰造成2、上行干扰关于载频101高的问题I0I (InterfereneeOn Idle )值的含义是：载频时隙在空闲状态时收到的上行干扰信号的强度。理想情况下，载频时隙在空闲状态即没有占用的情况下收到的上行信号功率应 该为0, 一般情况下IOI值1。只要IOI值5,那么对信道的影响就不会很严重，

26、但若IOI值接近了 10或超过了 10，则会造成小区的掉话，通话质量下降等严重问题。第一部分：IOI值高的原因可以分为两方面一基站内部的接收设备障碍造成的IOI值高：1. 信道盘的接收补偿值不准或接收功能障碍2. 小区的接收器件 DLNB或IADU、双工器故障3天馈线故障二外来的干扰源造成的上行干扰：1. GSM网络内部的干扰：即频率规划不当，同邻频过多造成的上行干扰。2. GSM网络外部的干扰：即外界非法直放站、集团通信系统非法占用GSM上行频段，或由于其它通信系统的设备的不合格，发射信号边带频谱干扰GSMh行频段。部分故障问题总结表:序号现象描述故障原因分析处理措施及人机命令处理效果1SD

27、拥塞sdcch_mea n_holdi ng_time is long,相关GPROC负荷大吊死reassign site to other lcfsuccess2三个交换机间切换失败三个交换机间挂表进行信令测试 分析交换机打patchsuccess3SD拥塞sdcch_mea n_holdi ng_timeislong, SD traffic 不大T3101 延长=5000,cha nn el_rec on fig_switch=0, immediate_assig n_ mode=0负荷有所减轻4SD掉话,接通率差PATH_BANLAN（差数据库DRI天线选择号配置有 问题恢复正常5小区不

28、能与周围小区切换该小区GCLK失锁phase_lock_gclk=1 - reattemp gclk - 换 GCLKsuccess6通话时对方听到无此号码随后掉话本地交换机900-1800切换存在 问题，中继不够，话务走备分路由交换机增加900-1800中继，备分路由数据改正（切换号码）success7call_setup_suc_rate彳氐发生于冋一交换机下BSC,告警中有unequipcic.即交换机分配了该CIC,而BSC中未配置交换机锁住相关 CICsuccess8呼叫无法接通大量用户在手机发岀assig nmentcomplete之后，交换机即发回 disc onn ect消息导

29、致呼叫无法接 通交换机打patchsuccess9单通:信号强，分布式系统某些地方单通r分布式系统一节天线问题success10通话话音质量差某交换机下串话，单通,每线爱尔 兰超过0.5导致中继任意分配交换机增加中继success11呼叫无法接通信号差，天馈线接反天馈线接反success12单通某BSS下单通严重，该序列号的 GCLK寄存状态错误，主备用GCLK 均被激活，各CBUS时钟失去同步GCLK重新编制程序success13单通BSS側CIC号码对应交换机的 CIC号码是错误的CIC号码一 一对应success14OM（统计问题统计表中有多余小区，而 CM中没有登录到SYS中，/usr

30、/gsm/curre nt/sbin命令delete_CELLCM与 PM一致15OM（统计问题PM窗口无法打开ps -ef | grep app;杀死所有非root用户的进程吊死进程 全部清除，PM正常16OM（统计问题话务量不咼，拥塞严重。话务统计 可能不正确。增大busy_tch 各 bin值门限防止溢岀17EFRFR-EFR信道不能转换FR的交换机也需打开 EFR开 关success18呼叫无法接通1800在手机发岀assignment complete之后，交换机即发回 disc onn ect消息导致呼叫无法接 通900-1800交换机信令模块重启有所改善19通话话音质量差加载在话

31、音上的尖锐声音可能是电路上的某些硬件问题，如XCDF上的MSI或交换机的中继模块success20呼叫无法接通手机发岀 assignment complete 之后，交换机即发回 disco nn ect 消息导致呼叫无法接通ALCATEL的4版交换机开EFR 而BSC未开，岀现此现象，交 换机升7版，可解决问题。success21呼叫无法接通sdcch access failure rate=70修改bcch或硬件DRI排障success22双频网间不能切换路测发现900-900后5ter消息丢失，HORE消息中CLM3编码为00 （应为50）相关交换机 mapvers ion重创一下suc

32、cess23双频网间不能切换路测发现900-900后5ter消息丢失，HORE消息中CLM3编码为00 （应为50）相关交换机版本不支持CLM3交换机升级success24单通手机用户只能听到自己的回音话音通路的某一设备岀现故障 ， 硬件排障success25通话话音质量差MS-MS话音断续该地区无线覆盖差，调整覆盖success26通话话音质量差手机用户只能听到尖锐的金属声，MS的话音编码方式与 BSC不一致（EFR）交换机间关于 EFR的信令有问 题success27统计中看到相同的LAC下岀现不同page_req_from_msc检查BSC告警，发现存在如下告 警：BSS ALARM26

33、 : ReceivedPage for In validCell fromMSC仔细检查此LAC所对应交换机 下所有的小区号，发现存在错 误小区号。删除这些cellid。success28用disp_cells_s 命令看到的sdcch数量和该小区 sdcch_prefer 不一致。可能是因为SDCCH载过大引起 软件问题。检查该小区的每个 RTF上的SDCCH荷后发现达到 0.9erl 以上。增加SDCCF数量后问题 解决。有所改善29从统计看，小区有话务量 但是 total_call=0。这是由于在数据库中access_cell_bar =1, en_in come_ho=1 导致。检查数

34、据库，将access_cell_bar 设为 0success30从统计上看，某小区的CHAN_REQ_PAGE_RE 值P要远远大于PAGE_RESPON值&经分析发现该小区存在严重的 SDCCH拥塞现象，导致寻呼相应消 息不能发送上来。检查 SDCCHLoading，增加 SDCCHE 置。恢复正常31从统计上看，某小区MA_CMD_TO_MS_BLKD但0 是TCH拥塞率却非常高， 即 ALLOC_TCH_FAIL艮高。分析此原因，发现该小区并没有 任何拥塞现象存在。经过检查发现，数据库参数 bssmap_t11设置大于assig n_successful，这是一个错误的设置，因为ass

35、ign_successful 是 tch 分 配过程的超时保护器，BSSMAP_T1 必须小于它。重 新设置。恢复正常四：案例分析详见附录。案例1信号不稳定【问题名称】信号不稳定【问题类别】硬件故障【相关设备】天馈线【问题详细描述】在距离基站200处的小村庄，在直视基站的情况下，手机接收信号漂移达30dbm,基站天线高60米。【技术背景】1参考无线原理中上下性平衡进行计算2 参考天线电气参数3. 驻波比计算与正常值【问题解决步骤】1检查架顶功率，发现没有问题，按设计要求设置2. 测驻波比，用常规功率检查没发现问题，用SITE MASTER检查发现在50米处驻波达1.6。降低天线高度至50米，重

36、换馈线后，问题解决。案例2:载频101值高的问题【问题名称】8/8/8基站最后一个机柜的载频 101高且话务量少【问题类别】硬件故障【相关设备】BTS相关设备【问题详细描述】MCELL6_8/8/8基站，采用6/6/6/ (2, 2，2)方式扩展，其中最后一个机架(也就是扩展 机架)的6个扩展载频的101都比同扇区的其他非扩展载频高，基本上扩展载频101在34左右，而非扩展载频101都小于1。这种情况造成扩展载频的 TCH分配优先级低于同 扇区的其他非扩展载频，TCHIoading rate大大低于非扩展载频，造成话务分担不平衡。【技术背景】BTS相关技术【问题解决步骤】(1)检查过该站的数据

37、库，所有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 一切正常，但有

38、部分 RESERV的 IADU开关 被置为ON这些开关是不用的，把它改置为OFF状态再观察是否有影响，结果未解决；(7) 检查该站室外天馈线连接，发现都正常，交叉3扇区的两根天馈线试验，未解决；(8) 修改该站RF频率规划，3扇区改善，已正常，1扇区未改善；(9) 将DRI 03/04和DRI 06/07对调，发现101高的问题在原载频 DRI 06/07 (现载频 DRI 03/04)上;案例3：无法作主叫的问题【问题名称】无法作主被叫【问题类别】硬件故障【相关设备】CTU【问题详细描述】现场测试时发现手机上接收信号较好，用户就是无法作主被叫。【技术背景】参考主被叫呼叫流程【问题解决步骤】1

39、. 检查统计发现 TOTAL_CALL 为0，有话务量，其他 CHAN_REQ_MS_FAIL、 MA_FAIL_FROM_MS ，PATH_BALANCE、IOI 均正常。2. 检查参数CELL_BAR设置正确，没有关闭小区接入。3 .检查MSC中定义的小区LAC号与BSC的小区LAC号是否一致，检查后发现设置正确。4 .重启基站BCCH后恢复正常。案例4:室内分布系统话音单通问题【问题名称】室内分布系统话音单通问题【问题类别】室内分布系统【相关设备】光纤放大器【问题详细描述】某重要场所室内覆盖较差，为了保障该地通话质量，移动公司专门安装了整套室内分布系 统。分布系统安装之后，就出现在该地的

40、手机下行话音非常清晰但是上行确根本听不清楚 的现象。【技术背景】3. 分布系统的光纤线性放大器。光纤线性放大器是用在分布系统中长距离传输而使用 的信号放大器。它有接收端，光纤传输和放大器三部分组成。线信放大器的线性范 围和放大倍率是它的主要技术指标。当接收信号不在放大器的线性范围内，产生的 放大信号就不再是线性的。4. 摩托罗拉公司基于接收电平的功率控制算法。简单的说就是落在功率控制接收窗口 之外，需要相应调整功率。【问题解决步骤】由于只是这一个基站存在单通问题，所以我们把问题定位在基站和相应的分布系统上。我们发现基站的所有载频都存在该问题，所以与载频硬件无关。检查基站到BSC传输，也不存在传

41、输质量问题。所以，问题更像是无线环境造成。通过实地使用tems手机测打，发现下行接收电平和话音质量都很好，这与手机听对方来电 非常清楚相一致。Tems手机无法检测手机上行的接收电平和质量，所以我们采用在OMCR上CTP跟踪上行数据。通过对该基站 255个呼叫的跟踪，我们发现该基站上行 rxlev始终大于20dbm以上，而上行quality却主要为57级，手机发射功率较低。为什 么基站上行rxlev会出现始终大于-20dbm的奇怪现象呢？我们就此问题与分布厂家进行交流，原来问题就是出在分布系统的光纤放大器上。这个厂家的线性放大器技术指标严重 不合格，线性范围只有 3db,超出此范围都严重变型。所

42、以，导致手机无论如何功率控制， 基站接收测的接收电平都在- 20dbm以上，而话音质量极差，导致上行根本听不清楚。最 后，我们将所有的光线放大器去除，直接用7/8馈线连接，问题就解决了。案例5： M - M接续时间过长【问题名称】湖北省荆门移动 M M接续时间过长【问题类别】参数设置【相关设备】MSC【问题详细描述】M - M拨打时，从发出 Channel Request到收到Alerting消息，荆门移动耗时约 6.8秒，而 武汉为5.3秒。【技术背景】【问题解决步骤】对于同一系统，寻呼响应的快慢在一定程度上影响了接续的快慢，鉴于荆门系统的寻呼响应比武汉平均慢473ms,为此对荆门系统的寻呼

43、分组进行重新设定。寻呼消息的复帧结构时长为235ms,荆门系统的寻呼分组为 5,其对手机而言，帧长为 1175ms；武汉系统的寻 呼分组为2,其对手机而言，帧长为 470ms，这样最大可能导致 705ms的时延。在西门子交换机中，即使不采用CIPHERING过程，但无法在流程上消除，每次 M M的接续，导致470ms的时延。再考虑到目前交换机的二次寻呼设置（TPAG为5s）,而A接口中测到的寻呼响应时间约为1.5s，则完全可以将TPAG改为3s。从而可以大幅度地减少二次寻呼时的接续时间。在Um接口，未采用跳频时，收到 ASSIGNMENT COMMAN的延时为230ms；而采用跳频时， 收到A

44、SSIGNMENCOMMAN的延时为470ms,两者有240ms的延时，考虑到主、被叫，则有 480ms的延时。案例6:手机空闲/通话过程突然信号全无【问题名称】手机空闲、通话过程中信号全无【问题类别】路测问题【相关设备】天线覆盖【问题详细描述】客户投诉手机在空闲状态下和通话过程中存在手机信号突然全无，出现脱网或掉话现象【技术背景】参考路测分析【问题解决步骤】现场使用TEMS T28S测试发现确实存在此类现象。1空闲状态下手机出现了信号全无，信号变化主要集中在小区重选的时刻，原因是：无主覆盖信号，而且室内信号电平在95dBm左右，手机在空闲状态下小区重选频繁 。由于在室内的信号存在明显起伏变化

45、，导 致重选过程中会出现了明显的信号变化；开通室内分布系统，服务小区信号大于-85dBm，复测正常；2、通话状态下手机出现了信号全无：A、手机没有发生切换时但接收到的信号电平突然降到-108dBm，多次拨测发现此现象仅仅出现在该小区某块载频上，判断为硬件 故障，更换载频后问题解决。B、DT测试中手机切换到目标小区后信号电平突然降到-100dBm以下，检查目标基站没有发现相应硬件问题，检查发现该小区还存在与目标小区 相同BCCH的相邻小区（BSIC不相同），这两个目标邻区分别覆盖两条垂直交叉的街道， 手机的快速运动造成系统误判断，命令手机切换到错误的目标小区，接收到的信号电平非 常低。修改其中一

46、个小区的 BCCH后问题解决。（本次测试中T28S在-104dBm时表现为信 号全无）案例7: PCMCIA卡故障造成基站不能正常CODE LOAD【问题名称】PCMCIA卡故障【问题类别】硬件故障【相关设备】PCMACIA 卡【问题详细描述】某个基站开通正常后，拨打测试通话也正常。但是运行一段时间后就会反复loading基站不能正常服务【技术背景】1. CSFP下载过程中的问题【问题解决步骤】1. 到现场测试发现原来 SC0中的PCMCIA卡有故障造成基站在下载数据时由于要检测SC0板及板中的PCMCIA卡，当SC0中有卡时，BSC在下载DATABAIS会给该卡写数据，由于PCMCIA卡本身

47、故障造成BSC反反复复不断的检查不停 Loading,造成数据正常不能下载 SC0板 导致基站不能重启到正常状态。取出该PCMCIA卡后20分钟基站进入服务状态，拨打测试正常。案例8避雷器故障造成基站101高【问题名称】避雷器故障造成基站101高【问题类别】硬件故障【相关设备】避雷器【问题详细描述】高ma_fail_from_ms，所有载波都比较高，且 ioi较高（12-23）；通话质量差，掉话高【技术背景】1. 硬件损坏【问题解决步骤】1、调测基站收发，馈线的阻波比正常；2、更换基站的主要器件，如 TCU、SURF等没有效果。3、DT测试信号强度正常，稍远处话音质量就变差；4、最终更换避雷器

48、件后，故障消除，指标正常案例9：硬件连接与数据定义错误造成基站 PB值高【问题名称】硬件连接与数据定义错误造成基站 PB值高【问题类别】硬件连接与数据定义错误【相关设备】DLNB【问题详细描述】对于一批基站的第三扇区，出现掉话率高，PATH_BALANCE偏高的现象，该扇区的SDCCH RFLOSS 也较高。【技术背景】1. 硬件连接2. DATD BASIE【问题解决步骤】1. 从统计看，此类基站的第三扇区的所有载频的PATH_BALANCE都偏低，显示扇区接 收较差，而且不是个别载频的硬件问题。2. 由于该问题在第一、二扇区没有出现，所以非常令人奇怪。3. 检查该基站的数据库配置，三个扇区

49、完全一样，所以很奇怪。4. 我们后来发现这些基站都是在 2个机柜内配置3各扇区的，这就使我们想到了是否在硬件配置上与普通的3个机柜内分别配置三个扇区的基站有什么区别。最后我们发现原来是 DLNB的连接问题。这些基站的第三扇区的接收天线是连接在第三个DLNB而不是常规的第一个。而我们的数据库设置中该扇区每个载频的antenna select number都是1。这样就造成了天馈接收问题。5. 综上所述，每个载频的 antenna select number必须与实际的 DLNB连接相一致，否则就 会造成严重的掉话问题。案例10：外部干扰【问题名称】外部干扰引起断噪【问题类别】外部干扰【相关设备】

50、外部干扰源【问题详细描述】重阳宾馆的205房呼叫体育宾馆的三楼过道，主叫小区为：51223,问题现象为：断噪.【技术背景】外部干扰引起断噪【问题解决步骤】1信号电平在-75dbm,初步判断非覆盖弱造成2锁住载频，逐个拨打，均出现此问题3通过扫频，发现整个频段信号强度很均匀4定位为外部干扰，经过扫频仪测量后，定位了干扰源。案例11:分布系统引起起呼、被叫成功率低【问题名称】分布系统引起起呼被叫成功率低【问题类别】分布系统【相关设备】分布系统【问题详细描述】在测试中发现问题主要在局部发生，问题电话信令都为起呼/被叫在Channel Request后无SD分配命令。现场测试发现，占同一载频上通话，在

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

52、分别在89%和90%左右【技术背景】分布系统问题【问题解决步骤】通过实地测打发现此分布系统在各楼层的天线安装位置不理想，信号覆盖范围较小，各楼层的办公室基本占用周围宏蜂窝的信号，且与此微蜂窝之间的切换大多为quality切换，成功率相对较低。故重新设计了各楼层的天线位置，以保证整个大厦内稳定占用此微蜂窝信 号案例13：基站天馈故障造成覆盖问题【问题名称】基站天馈故障造成覆盖问题【问题类别】天馈硬件系统【相关设备】天馈线【问题详细描述】用户反映该基站的覆盖不好在铁路国道DT测试时该路段覆盖率经常变化 ，即每月的例行 测试结果中该路段覆盖情况不稳定 【技术背景】天馈线系统覆盖问题【问题解决步骤】1. 根据对用户反映及 DT中的问题分析，结合了 OMCR统计，检查发现该站的PATH_BALANCE 统计不正常。 RTFOO和RTF01的PB统计值比 RTF02和RTF0