下载文档原格式
BTS常见故障分析—传输类故障分析冯智能网上故障统计表明，基站的传输故障占到BSS系统所有故障的数量的60%~80%，故障现象：1.告警台：有“LAPD链接告警”、“BIE失步”“LAPD_OML故障告警”、“13M失锁”等告警。
2.话统台：故障时间内，小区切换成功率、掉话率指标异常。
3.用户投诉：打不通电话（BTS 传输断）、话音质量差或掉话（误码）。
告警R-LOS接收侧光信号丢失、危急告警。
原因：1.光纤故障（断）2.SDH板发送故障3.SDH板接收模块故障。
检测方法：自环法、光功率测试法。
T-ALOS告警：2M支路输入模拟信号丢失。
方法：逐级环回法：1.E1接口板相应通道内环回2.DDF架环回3.检查DDF架到交换机的线缆。
TU-AIS告警：与配置有关，时隙配置，业务方向配置。
基站常见告警交换端报1.AIS 接入一个不正常的信号，远端告警（1）基站断（2）配置有问题2.2M 信号丢失 DDF架有问题链接线路断3.远端告警 REMOTE 没有 1. 2. 告警 4.误码 TU指针调整 2M接头接地虚焊支路上产生误码线路上也产生误码。
处理方法：逐段环回判断故障点。
故障定位的常用方法：1.分析2.环回3.换板。
传输电路中断：基站和BSC之间传输环节越多，传输中断可能性越大。
E1接头接触不良：工程质量问题，会造成传输时有时无，语音质量差，严重时会造成基站传输中断。
传输闪断：传输误码率高，多见于使用微波、HOSL，或传输环节多的基站，阴雨天气更频繁。
传输接地不好：传输线浮地，将造成E1信号电平异常，可能导致LAPD链路中断。
常见故障一：E1不通、OML断链。
故障分析：该问题原因可能为E1线缆问题，或者传输设备问题，或者坏版问题处理步骤如下：1.使用自环线对基站侧自环，观察E1接口板指示灯是否熄灭。
如接口指示灯不灭，则可能为基站接口板问题，更换接口板、2.使用自环线对BSC侧自环，观察BIE接口板只是灯是否熄灭。
BTS常见故障及问题处理BTS常见故障及问题处理：软故障：通过复位、断电解决。
故障定位：熟悉通路（发射通路、接收通路、传输通路、控制通路）交叉法：如载频交叉、光纤交叉、接收线交叉等，由此判定故障所在。
同步丢失：（系统时间）一般出此现象，看设备是否有电，然后从基站往上做环回。
如果正常，则一般为基站本身的问题，如：2M线头子不好、T43板、NIU板、MCU、uBCU机框问题。
也可以用PCMCIA卡起站，对基站做自环回检查。
bit误码高：可能原因有：传输接地不好、没有与基站共地、2M线头子不好、传输本身不好（可以挂表做2M测试远端告警：在BSC侧看到MMS远端告警，表示BTS没收到BSC的信号，由BTS发给BSC远端告警。
可以先做从基站往上做环回，观察BSC端MMS状态。
可能原因同上。
传输好，基站起不来此种现象一般为MMS为B-U状态，但RSL为E-U或D-U状态，即信令起不来。
可以先将2M拔断，看BSC 端MMS状态是否依旧B-U（传输在基站前就有环回，传输也可以做软环回）。
可能原因同上。
复合故障处理流程检查传输接地、传输与基站是否通过一个铜牌接地、重做2M头子—> 排除基站自身的可能问题(更换T43板、NIU板、MCU、uBCU机框) —> 挂表做2M测试—> 通知网管。
根据具体情况，可以做适当调整，问题一旦超时，请寻求电话和现场支持。
调测80或接收补偿值异常对Mcell基站，可能原因有：信号发生器设置有误、硬件连接有误、天线选择号错误、AB通路错误、载频硬件故障、载频软故障、双工器故障、DLNB故障、IADU故障、射频线故障、载频接收线故障、载频接收线未连接好、IADU拨位开关设置有误。
对Horizon基站，可能原因有：信号发生器设置有误、硬件连接有误、天线选择号错误、AB通路错接收矩阵告警DLNB或IADU（Mcell6）;SURF（horizon）、载频软硬故障、接收线未连接好整个柜子载频OOS可能原因有：MCU故障、FMUX故障（out口应有光，但要注意不要正对眼睛，防止损伤）、光纤接反、光纤损坏、软故障。
华为典型故障处理1 告警介绍：1.1告警分类：由于上报告警的网元不同，为告警规划的ID也不同，具体可分为：BSC控制器告警：20***~22***3900基站告警：25***、26***、28***自定义告警：65033~65040（门禁、烟感、水浸、交流断电、稳压器防盗等）从告警需要关注的程度不同可以分为故障、事件、工程告警：故障告警又分为：紧急告警、重要告警、次要告警、提示告警告警与事件的区别：事件是指被管对象发生的任何情况的通称。
例如对象的增加、删除、修改、状态改变等。
考虑到和原有系统的兼容，故障子系统中的事件专指：系统正常运行状态下产生且需要提示用户的通知。
工程告警：对设备在特定状态下上报的告警进行特殊处理，以达到降低告警数量、减轻维护人员工作量的目的。
设置方法：M2000菜单栏依次点击：“监控”、“告警设置”、“工程告警过滤”、“设置”从网管分类不同可以分为：电源系统、硬件系统、环境系统、通信系统、运行系统、业务质量、信令系统、中继系统2 告警查看方法2.1 查看当前未恢复告警未恢复告警就是设备当前存在的告警，需要重点关注和处理，监控未恢复告警是发现故障最直接最快速的手段。
2.1.1M2000操作方法（OMC级别）1、点击菜单栏监控/浏览告警列表2、在出现的过滤菜单栏中将状态为已清除的选项去掉，点击右下角的确认，就会弹出当前未恢复告警的列表。
2.1.2WEBLMT 操作方法（BSC 级别）在WEBLMT 界面依次点击“告警”、“浏览活动告警”、“故障”即可查询当前BSC 以及下挂基站的所有活动告警。
2.2 查询告警日志（历史告警）的方法查看告警日志是故障定位的常用方法，操作与查看未恢复告警类似，M2000对历史告警进行了优化，对同一网元同一告警多次上报进行了归一化处理，在告警信息中多了频次首次发生时间、最近发生时间等字段，如果需要逐条列出历史告警，请到WEBLMT 中进行查询。
2.2.1 M2000操作方法（3 a E H 浏览告警列表回 ilanager12000移动网元管理系^(10.228.192.10)-［主拓扑］监控①维护勉拓扑◎性能（E ）安全㈢配置©软件®报表®窗口迴）帮助®系统㈤ 昭卩區册I 邂理A 蟲工作¥查询爭件日志㈢ 当前观團 性能监控日监控國值管理（H ）…I 室内分布万冰蒔谷II.--2bJ■11JU ：-1■:IaJ^：：查询告警日志Q2.2.2WEBLMT操作方法在WEBLMT页面点击告警/查询告警日志，就可以进入到查询历史告警的界面：1、可以对查询的告警类型、告警时间、告警级别等进行设置；2、可以通过基站过滤进行单站点告警过滤；3、返回数目最大可以设置为4000，请修改为4000，防止出现因告警条数超过设置值导致部分告警无法显示的问题；3 性能结果统计统计的三要素：测量对象、指标名称、测量周期测量对象：指测量的网元实体，比如BSC、基站、小区、载频等；指标名称：测量统计的具体名称，比如：“DPUCPU占用率平均值”测量周期：BSC6900目前支持：5分钟、15分钟、60分钟、24小时测量3.1 性能结果统计开启方法BSC6900默认全指标登记，并上传至M2000数据库，但是M2000并不对没有开启的指标进行解析，如果要查询某些指标的结果，进行就必须先在策略设置中开启，具体操作如下：1、点击菜单栏性能/测量管理/测量设置國值管理⑤ 自定艮指标管理側 性能对象集管理回2、弹出的菜单中选择网元、功能级、功能子集、测量周期、测量对象后，单击右下角的“应用”，测量任务就开启了，M2000会对网元下一周期上传的统计结果进行解析，到时就可以查询到对应的统计结果。
BTS故障案例分析案例1：TRX单板反复加载1．现象描述某地基站进行预调，先后有3个基站出现上电后TRX单板反复加载现象，现象具体表现：∙基站上电后TMU板启动、运行正常,全部TRX单板由初始状态(4个灯全亮)进入数据加载阶段(RCP/RDP灯0.25秒闪)∙接着TRX单板进入启动阶段(RCP/RDP灯快闪,FAIL灯间断闪)∙然后又回到初始状态,如此循环。
∙操作维护终端可看到TRX单板软件加载进度指示条反复出现，TRX无法正常工作。
2．告警信息:∙TRX主时钟告警∙TRX单板通信告警∙TRX时钟严重告警∙TRX处理器运行告警3．处理方法：（1）检查基站背面数据总线连线:∙从TMU的背板CMB板与数据总线连接插座处查起,直到TRX的背板TRB板与数据总线连接插座处∙接下来检查TRB板上的trx-ID拨码开关设置正常并且没有虚焊∙无数据及控制方面的告警,数据加载正常,可排除数据总线硬件方面的原因。
（2）检查基站时钟系统：∙检查时钟源，基站近端维护查看TMU板状态，重点看时钟模式：♦正常情况下，鉴相器读数与晶振DA值都应为1500左右♦无特殊情况下：设定工作模式和当前工作模式都为外时钟♦有条件测量TMU板的T13M输出的频率是否在正常范围内？∙检查背面时钟总线连线：♦检查TMU的背板CMB板与时钟总线连接插座及与TDU的连接♦检查TDU板工作状态：若TDU板上的绿色和红色指示灯同时亮，至少说明TDU加电正常♦查看TDU的拨码开关♦检查TDU板至各载频之间的时钟总线♦检查机柜时钟总线两端的时钟总线匹配头。
4．三基站处理过程：∙基站1：♦查看TMU单板信息：♣鉴相器读数：0♣晶振DA值：2048♣时钟模式：内时钟。
♦重新设置时钟工作模式：♣时钟模式：外时钟♣晶振DA值：1500♣鉴相器读数始终为0♦复位TMU♣故障不变♦判断TMU板时钟锁相环出了问题♣更换TMU板，故障排除∙基站2：♦判断TMU板无问题♦机柜顶部的时钟分配板TDU板上的两个指示灯都不亮♣ TDU板电源线插头松动♣重新连接后,故障排除。
第1章常见故障定位及处理IP传输所出现的问题主要集中在传输链路不通，信令链路无法建立，载频不开工或基站反复重启等问题上。
本章主要介绍E1/T1方式下Abis接口IP传输所经常遇到的问题和相应的处理方法。
1.1 OM链路不通的定位处理1．首先查询物理链路的连接是否正常，可以采用DSP E1T1STAT的命令来查询链路所在的E1/T1状态。
如果返回链路不可用的或存在链路告警等情况，需要对链路进行逐段环回测试，查找出链路上存在故障的节点。
2．检查接口单板的拨码开关是否设置正确。
查询命令为DSP CBTSDIPSTAT，须根据实际情况确定拨码开关和跳线的拨码位，拨码开关的具体意义请见第三章。
3．DSP PPPLNKINFO/MLPPPLNKINFO来查看PPP链路是否被激活。
4．如果有条件的话可以在近端用DSP CBTSBRDSPCESTAT命令查看BCIM单板是否已经通过协商获取了单板端口的IP地址。
如果未获取可以查看LOAD进程中有没有BOOTP请求上报。
5．查看基站的版本信息。
支持IP传输的BCIM板为QC54BCIM，且最小版本为V200R002C02B022，如果不满足以上要求请更换单板或升级基站。
6．查看BSC侧的数据配置，用LST BSCBTSINF和LST BTS查看两边的配置的基站操作维护IP是否一致，基站的BOOTP标识是否一致。
7．如果所查询的信息都正常，请复位基站，并ping 基站的操作维护IP地址。
如果ping通请立即下配置，原因很可能是基站原先存在的链路类型与BSC侧现在的配置不一致。
如果不及时下配置，则可能导致基站重新加载原来的配置文件，导致链路类型再次一致而OM链路中断的问题。
8．Abis IP化下，如果上述数据都正确，复位基站后还是无法ping通，那么需要检查1）基站CI板是否为QC54CI板；2）近端登陆检查CI板程序是否为V2R2C02B022以上版本（该版本为支持Abis IP化的最低版本）；9．Abis IP化FE方式下，近端登陆BTS，检查BTS上是否正确手动配置下面四个信息：1）ADD CBTSFEPORT配置BTS侧FE链路地址，要求与BSC侧配置一致；2）SET CBTSBCIMIP设置BTS CI单板地址，要求与BSC侧配置一致；3）SET CBTSOAMIP设置OMIP，其中需要输入BSC侧FG1Ba/FG2Ba单板IP，要求与BSC侧配置一致；4）ADDCBTSIPROUTE设置BTS侧路由信息，要求目的IP为BSC侧FG1Ba/FG2Ba单板IP，网关为BSCFE链路IP，要求与BSC侧配置一致。
某通信公司BTS维护操作手册1. BTS设备基本信息在进行BTS维护前，首先需要了解BTS设备的基本信息，包括型号、序列号、软件版本等。
这些信息通常可以在BTS设备的标识牌或管理界面中找到。
确保在维护过程中使用正确的设备信息。
2. 维护前准备在进行BTS维护前，需要做好一些准备工作。
首先，确认BTS设备的供电和环境是否正常。
其次，准备好相应的维护工具和备件，以便在需要时进行更换和修理。
3. 维护操作流程BTS维护操作包括巡检、清洁、检修、调试等内容。
在进行这些操作时，需要严格按照规定的操作流程进行，避免操作失误导致设备故障。
4. 故障排除在BTS设备出现故障时，维护人员需要快速响应并进行故障排除。
首先，根据设备报警信息和现场情况进行初步判断，并按照相应的故障排除流程进行操作。
如果无法解决，及时向相关部门报告并寻求支持。
5. 安全注意事项BTS维护过程中需要注意安全，保证自己和设备的安全。
在进行高空作业时需要使用安全带，避免发生意外。
同时，操作人员需穿戴好防静电服，并遵守相关的安全操作规定。
6. 维护记录和报告在完成BTS维护工作后，及时记录维护情况和维护所用时间，以及对设备性能进行测试的相关数据。
并将维护报告提交给相关部门进行审核和存档。
以上内容为BTS维护操作手册的主要内容，希望每位维护人员都能严格按照手册规定进行操作，确保通信网络的正常运行和设备的长久稳定性。
BTS维护操作手册7. 常规巡检定期进行BTS设备的常规巡检是保障通信网络正常运行的重要一环。
在巡检过程中，需要检查设备的外部和内部连接线是否松动或损坏，检查设备的风扇是否正常运转，确保设备的散热正常，还需检查设备的指示灯是否正常，以及设备面板是否有异常情况。
对于无线天线和天线馈线，也需要进行定期的巡检，确保其连接稳固，未受到外部干扰。
8. 清洁维护定期对BTS设备进行清洁维护也是非常重要的。
设备在长期运行过程中可能会积累一定的灰尘和污垢，会影响设备的散热和正常运行。
BTS3012和BTS3900故障处理一、标题：3012基站射频连线松动和数据配置不一致导致双不通现象描述：某局基站割接后用户投诉有大量双不通现象。
告警分析：大量的双不通可能由MSC数据配置问题、BSC数据配置问题、A接口鸳鸯线、Ater接口鸳鸯线、Abis接口等多方面原因造成。
处理过程：对可能的原因逐一排查：1、检查MSC、BSC数据配置没有异常，排除数据配置问题。
2、对A接口逐CIC拨测，没有发现双不通，排除A接口原因。
3、对Ater口每条E1线用7号信令MTP3是否通，判断Ater口物理传输是否正常，Ater口传输正常，排除Ater口原因。
4、倒换EIUB板，故障未消除，排除EIUB单板问题。
对双不通现象进行外部语音环回，发现故障出在BTS侧，现场拨测后发现，双不通现象只存在于XX基站的1、3小区，该站型是S9/8/7，1、3小区为并柜配置并公用一个载波和一对传输，分析后可能的原因有：1、共用载波故障故障导致双不通。
2、怀疑连线和数据配置不一致。
3、DTMU故障导致双不通。
4、1、3小区传输故障导致双不通。
和代维现场定位：1、将怀疑有故障的载波闭塞，拨测后发现故障未消失，排除载波原因。
2、检查连线发现所有的连线接头都没有拧紧，并且连线和数据配置不一致，一、三小区的DFCU上行和下行通道的配置和实际射频电缆连线不一致，把接头拧紧，修改数据配置后，拨测700余次未发现双不通现象，故障排除。
二、标题：BTS3012的DBUS总线损坏导致LAPD告警产生问题处理现象描述：某局BSC6000下挂的BTS3012，该基站使用并柜方式配置。
在站点开通后半小时，主机柜内1号DTRU、3号DTRU出现DBUS告警，同时伴随载频板的LAPD告警。
告警描述：告警台出现编号为4158的DBUS告警，4102的LAPD告警。
BTS3012的基站面板显示两开红色的故障载频，查看载频的信道状态为故障。
告警分析：1、传输问题；2、DTRU问题；3、DBUS总线问题；4、DCSU、DTMU问题。
目录第一章基站说明 (1)第二章传输类故障处理 (3)2.1故障现象 (3)2.2传输类通知和告警 (3)2.3传输故障的一般处理方法 (5)2.3.1测试误码 (5)2.3.2检查TS分配 (7)2.4典型传输故障的处理方法 (8)2.4.1传输断 (8)2.4.2传输通但存在异常 (9)2.5传输故障案例分析 (11)2.5.1 BTS站点操作维护断 (11)2.5.2 BTS站点的某些载频的LAPD断 (13)2.5.3基站载频LAPD 大面积瞬断 (15)第三章天馈类故障处理 (17)3.1故障现象 (17)3.2天馈系统相关告警 (17)3.3天馈故障的一般处理方法 (19)3.3.1置换法 (19)3.3.2步步为营法 (19)3.4典型天馈故障案例分析 (21)3.4.1驻波比告警 (21)3.4.2上行信号不好问题 (23)3.4.3下行信号不好 (24)3.4.4 PA电压驻波比告警 (26)3.4.5增加塔放后的驻波比异常 (27)3.4.6塔放告警（TTA） (28)3.4.7低噪声放大器告警 (30)第四章语音类故障处理 (31)4.1故障现象 (31)4.2语音类通知和告警 (31)4.3语音故障原因分析 (31)4.4语音故障的一般处理方法 (33)4.5典型语音故障的处理方法 (35)4.5.1手机单向通话 (35)4.5.2明显的串话 (37)4.5.3双向无声 (38)4.5.4通话质量差 (39)4.6语音故障案例分析 (42)4.6.1阿坝火地坝基站通话质量差 (42)4.6.2阿坝长途出局电话经常出现杂音 (43)第五章时钟类故障处理 (45)5.1故障现象 (45)5.2时钟类故障通知和告警 (45)5.3时钟故障原因分析 (56)5.4时钟故障的一般处理方法 (57)5.4.1时钟模块的复位重新启动 (57)5.4.2基站频率的校准 (57)iii5.4.3载频时钟问题的处理 (57)5.5时钟故障案例分析 (58)5.5.1基站时钟频偏大导致切换掉话 (58)5.5.2基站时钟采用自由振荡导致切换失败率偏高 (59)5.5.3手机不能上网 (60)5.5.4通话过程中出现金属敲击声 (61)第六章业务类故障处理 (63)6.1故障现象 (63)6.2业务类通知和告警 (63)6.3业务故障原因分析 (64)6.4业务故障的一般处理方法 (65)6.4.1基站呼叫测试法 (65)6.4.2性能统计分析法 (67)6.4.3信令流程分析法 (68)6.5业务故障案例分析 (69)6.5.1载频状态正常，在后台动态管理中表现为不能长时间占用 (69)6.5.2基站状态正常但无信号或手机无法上网 (70)6.5.3小区载频无占用 (71)6.5.4 SDCCH 长时间占用 (73)6.5.5基站状态正常但切换不正常 (74)6.5.6小区掉话率突然升高 (75)6.5.7基站从信令跟踪看有过载消息 (76)第七章单板类故障处理 (77)7.1故障现象 (77)7.2单板类通知和告警 (77)7.3单板故障的一般处理方法 (77)7.4典型单板故障的处理方法 (86)7.4.1 BTS（V1A）的TRU的FU、CU通讯链路断，且PA通讯链路断 (86)7.4.2主、备CMM出现时钟严重告警 (88)7.4.3 CMM和FUC的通讯链路断 (89)7.4.4 PA驻波比告警 (90)7.4.5 HW长时间断链 (91)7.4.6层3软件无响应 (92)7.4.7 CMM复位、站点重启、CMM主备倒换出现相关告警说明 (93)v第一章基站说明ZXG10-BTS主要有宏基站（如ZXG10-BTS（V1），ZXG10-BTS（V1A）和ZXG10-BTS（V2））、和一体化基站（如ZXG10 EMB，ZXG10 BS21和ZXG10 BS30）。
BTS常见故障处理步骤一、载频单板驻波告警定位方法问题原因：1、从载频到射频前端的射频线缆连接不牢固。
2、载频到射频前端的射频线缆质量存在问题。
3、载频单板本身故障导致载频驻波告警。
4、射频前端单板（如CDU、DDPU等）本身故障导致。
5、天馈线可能存在问题。
处理步骤：1、检查载频单板到射频前端的连接线缆连接是否牢固，拧紧射频线缆和射频前端连接，拧紧射频线缆和载频单板的连接。
2、检查载频到射频前端的射频连接线缆是否存在质量问题，是否有损坏现象，更换载频到射频前端的射频连接线缆。
3、检查是否载频单板本身存在故障，更换载频单板观察载频驻波告警是否消除。
4、检查是否射频前端单板（如CDU、DDPU等）本身故障导致，更换射频前端单板观察告警是否消除。
5、检查是否天馈存在问题，测试天馈驻波比是否过大。
二、无线链路提示告警定位方法问题原因：无线链路告警有四种原因值，需要根据不同的告警原因值进行处理。
1、无线链路提示告警支路号0，表示信道激活异常，原因是SCP与BSC的信道类型或信道状态不一致，产生此告警。
2、无线链路提示告警支路号1，表示信道释放异常，包含SDCCH异常释放和TCH异常释放。
产生信道异常释放的原因值有设备问题（如TRX单板故障）引起告警，干扰引起告警，数据配置不当SDCCH异常释放引起无线链路告警，数据配置不当TCH异常释放引起无线链路告警。
3、无线链路提示告警支路号2，表示主BCCH无话务，主BCCH载频在连续的检测时间内没有话务，产生此告警。
4、无线链路提示告警支路号3，表示上下行不平衡，导致上下行不平衡的原因有载频或天溃上行和下行通道问题，数据配置不当等。
处理步骤：1、信道激活异常的告警：（1）对于信道激活异常的告警，查看数据配置，是否有BTS与BSC信道状态和信道类型不一致，如果有修改信道状态一致。
（2）是否进行过信道、频点、跳频数据等修改，有可能配置未下发到基站并生效，导致不一致，对于该种情况，重新配置数据并下发基站生效。
基站可换设备故障处理1 载频常见故障说明下文中提到的故障都是客户返修中最常见的，也是返修中最有可能发生“No-Fault-Found”情况的。
通过了解造成这些故障的可能原因，用户就能在故障发生时确定故障背后的真正原因。
这将减少网络故障时间并提高系统可靠性。
1.1 “DRI Not Detected” 和“Waiting for Connection”这两种故障都是由于 MCU/MCUF 不能与载频通信。
术语 DRI 是所有类型载频的软件总称。
在“DRI Not Detected”的情况下，从载频到 MCU/MCUF 的上行链路中断；而“Waiting for Connection”的情况则是从 MCU/MCUF 到载频的下行链路中断。
这些链路可能受多种因素影响，列举如下：• 数据库错误－－MCU/MCUF 试图寻找物理上不存在的载频。
• 载频未加电或光纤的收发弄反。
• TCU上的光纤损坏或弄脏。
• CTU的背板接头或前面板有物理损坏。
• 系统处于过渡状态，会在几分钟内自行恢复。
• TCU-B在”tcu_clock 0”后没有硬件”reset”，在载频上按”reset”后会恢复。
• 载频硬件故障,更换载频能正常。
• MCU/MCUF硬件故障,更换MCU/MCUF能够恢复正常。
• FMUX故障引起,更换FMUX后能够恢复。
1.2 “Inhibited”该故障说明载频产生了一个严重告警。
当处理一个“Inhibited”的载频时，应当记录下当前的告警。
• 载频重启。
•更换载频。
•其它原因。
1.3 “Code Load Fail” 和“CEB Configuration Fail”这两种故障说明在软件下载期间载频的固件和数字硬件间发生通信错误。
这可能由各种原因造成。
很多情况下该故障可通过重新下载软件清除，载频也可正常工作。
1.4 “No HDLC reset pending”该故障通常是由于MCU/MCUF间的通信中断造成，而载频则可能处于软件下载过程中或正常工作状态。
该故障通常会在几分钟内自行清除，也可通过“INS”载频清除。
1.5 “Code Load”这不是故障，只是表明软件下载仍在进行中。
一次完整的软件下载可能需要15-20 分钟，但对于载频的过程只要1分钟左右。
重要的是尽管可能发生错误，下载过程并没有被中断。
在下载过程结束前不要在该器件上进行任何操作，否则会使载频坏掉。
1.6 “Invalid Calibration Data”该故障是由于bay level校准未完成或校准数据在校准完成后未能正确保存，因此需要对接收进行重调。
进行 bay level校准最可靠的方法是使用一个简单的终端程序并手工键入命令。
校准软件工具常被用来最大限度地减少所需时间。
最常用的校准软件工具是“Cindy”和“Back”。
不幸的是这些工具可能无法正确保存校准数据，从而引起该告警。
最好在校准完成后手工保存并验证数据。
1.7 “High call/se t-up failure rate”射频干扰或接收调测引起。
这通常是由数据库中射频接口或未优化的切换参数设置引起，也有可能是接收调测不正确引起。
在这些情况下最好试用其它频率/信道一段时间并比较统计结果。
完整的bay level校准也可能会提高基站的性能。
如果网络中正在发生这类问题，就应进行一次彻底的频率检查以最大限度地减少射频干扰。
1.8 DRI 150 或“Receive Matrix Branch 1 Control Link Failure”该告警通常出现在Horizon Macro以及Mcell Macro类型的站上。
DRI 150告警表明IADU板子或SURF模块已经与载频失去联络或这些模块上有内部故障。
在发生内部故障的情况下，模块会在任意一条射频路径上出现过流状态的时候产生该告警，指示一个或多个LNA的故障。
该告警还可能是由于到模块或载频的连接松动，SURF模块未加电，或机柜中的SURF/IADU板子故障引起。
2 MCU/MCUF 常见故障说明2.1 无LED指示这通常表明MCU/MCUF未加电。
这可能是由于电路保险被触发或板卡未正确插入插槽；也可能是由于引导程序(boot code)损坏。
为消除引导程序(boot code)损坏的可能性，应确保当设备正在进行引导程序(boot code)更新时不要切断电源。
当引导程序(boot code)更新，或写入非易失性内存，可以看到红色和绿色的LED快速交替闪烁。
2.2 不能进行TTY接入这通常是由于MCU/MCUF与PC或终端的连接接口故障引起。
这种情况也可能是由于引导程序(boot code)损坏。
为消除引导程序(boot code)损坏的可能性，应确保当设备正在进行引导程序(boot code)更新时不要切断电源。
当引导程序(bootcode)更新，或写入非易失性内存，可看到红色和绿色的LED快速交替闪烁。
2.3 “Waiting for sync to initialize”出现在TTY这一问题可能由于MCU/MCUF安装不牢固或遭损坏的引导程序 (boot code) 所致。
为防止软件被损坏，当MCU/MCUF软件正在更新，或者正在写入NV-RAM时必须确保不要让MCU/MCUF掉电。
这一过程可通过面板上LED灯红绿快速变换识别。
2.4 MCU/MCUF 连续不断的重新启动遭损坏的引导程序 (boot code)或BTS和BSC之间的传输中断都会导致这一问题。
为防止引导程序 (boot code) 遭损坏，当MCU/MCUF软件正在更新，或者正在写入NV-RAM时必须确保不要让MCU/MCUF掉电。
这一过程可通过面板上LED灯红绿快速变换识别。
如果是BTS不能与BSC联系，MCU/MCUF将每30分钟自启动一次。
这是正常情况。
2.5 “FMUX Loopback Failure”这个告警指示FMUX卡认为光纤连接不能正常工作。
这可能由于以下情况造成：FMUX卡没插好、FMUX卡硬件故障、FMUX掉电、光纤安装有问题或折断等。
2.6 “No Redundant Link”主备MCU/MCUF不能正常通信将引发这一告警。
如果备边MCU/MCUF刚刚加上电，需要等待30分钟去预热这块板。
这是由于板内的高精度的晶体振荡器需要一个稳定的温度才能工作。
当然这一告警也可因备用边的MCU/MCUF故障所导致。
2.7 “PCMCIA Failure”PCMCIA卡插入不当或不匹配的卡将造成这一告警。
正确插入时，PCMCIA卡将与MCU/MCUF面板平齐，并且只有摩托罗拉认可的卡能在这里被使用。
3 现场工程师处理CTU和TCU-B的步骤下面将概要地介绍判断问题的方法，包括一些必要的步骤。
这些步骤是作为其他一些方法的补充，而不是取代它们。
如果经过这些步骤判断，问题依然存在则该设备需要返修。
3.1 现场工程师执行的一般性检查3.1.1 验证所有机柜内的设备都加上电，也要检查TCU的插头极性。
3.1.2 验证TCU收发线缆的正确连接，包括线缆和连接的情况，例如是否清洁和可靠。
3.1.3 验证TCU-B光纤的正确连接，连接是否紧密，并且没有碎屑。
这可以通过以下步骤做到：拔出光纤然后用吹气球向MCU/MCUF和TCU的光纤连接口吹风，并用软布擦拭光纤的端头，然后牢固插入。
3.1.4 验证数据库和实际硬件安装相一致。
disp_equip X full (在MCU的MMI提示符符下键入，这里的X是站号) 3.1.5 验证MMI提示符出现在载频的RSS端口，如果不是，请验证这个载频的电源开关是否打开。
3.1.6 验证LED的状态，如果不是亮的，请验证这个载频的电源开关是否打开。
3.1.7 验证这个载频没有被锁住。
State X dri * * （从MCU上的MMI提示符下键入，这里X是站号，Y是DRI号）Unlock X dri Y Y(从MCU上的MMI提示符下键入，这里X是站号，Y是DRI号) 这将解锁这个DRI。
3.1.8 检查基站的告警。
disp_act_al X ( 从OMC上的MMI提示符下键入，这里X是站号)3.2 “DRI NOT DETECTED” 和“Waiting for Connection”3.2.1 执行在6。
1段中的一般性检查，保证系统运行。
3.2.2 如果发生“ W aiting for Connection”错误，等待5-10分钟去观察这个故障是否自动消除。
3.2.3 INS 这个硬件ins X dri Y Y（从MCU上的MMI提示符下键入，这里X是站号，Y是DRI号）3.2.4 硬件reset这个载频3.2.5 对于TCU-B的检查，清洁所有光纤连接口。
对于CTU，检查背板或面板的物理损伤。
如果面板弯曲或安装不到位，那么背板不可能正确连接。
3.2.6 如果上述步骤不能清除这故障，请试着和同一基站中的载频调换，然后判断是槽位的问题还是载频问题。
3.2.7 判断数据库是否最近被修改，如果是，确保数据库和实际硬件安装一致。
3.3 “Inhibited”3.3.1 执行在6。
1段中的一般性检查，保证系统运行，特别注意所有的告警。
3.3.2 打开MCU/MCUF的告警模式，INS这个设备，并且在基站正常工作后，记录所有告警。
Mode_alarm X on 或 en_al X（在MCU上的MMI提示符下键入，这里的X是站号）Ins X dri Y Y（从MMI提示符下键入，这里X是站号，Y是DRI号）3.4 “Code Load Fail” 和“CEB Configuration Fail”3.4.1 执行在6。
1段中的一般性检查，保证系统运行。
3.4.2 INS 这块载频。
Ins X dri Y Y（从MMI提示符下键入，这里X是站号，Y是DRI号）3.4.3 等待10-15分钟的软件下载。
3.4.4 如果这个故障再次出现，重启载频。
Reset_dev X dri Y Y（从MMI提示符下键入，这里X是站号，Y是DRI号）3.5 “No HDLC reset pending”3.5.1 执行在6。
1段中的一般性检查，保证系统运行。
3.5.2 INS 这个载频ins X dri Y Y（从MMI提示符下键入，这里X是站号，Y是DRI号）3.5.3 等待10-15分钟的软件下载。
3.6 “Code Load”3.6.1 不进行任何操作，等待软件下载的完成。
如果载频在软件下载过程中被重启或者掉电，可能造成永久性的软件损坏。
正常的软件下载过程需要花费15-20分钟完成，具体依赖于这一基站所需的软件大小。
3.6.2 仅当载频处于下载状态（ code load)超过20分钟后，INS 这一载频。
