摩托罗拉BSS系统安全监控手册（motorola）

摩托罗拉BSS系统平安监控手册摩托罗拉浙江分公司协维组内容提要本局部内容综述GSMBSC级系统网络的硬件告警处理及一些日常监控方法，提供维护过程中分析问题的一般思路，对常见告警的处理，实际故障解析等。对一些工具的使用，还有常见故障的案例和日常维护工作的考前须知。通过本局部的学习读者将具有GSMBSC级网络维护的一般知识，掌握BSS系统根本维护技能，能够承当日常的网络维护工作。目录序论 4维护工作的要旨--防患未燃 4分析问题的一般思路 5第一章 日常监控数据收集 6一、ECT 6二、EVENTLOG： 7第二章 BSS系统平安监控 8一、告警定义 8二、监控列表及描述 8 GPROC告警 9 GCLK告警 10 KSW告警 11 LAN告警 13 BSP告警 14 MSI告警 15 MTL告警 15 XBL告警 17 数据总线告警 17 BSS告警 19第三章 故障处理分析 20一、常见故障分析处理 20 GPROC的故障处理 20 GCLK的故障处理 21 KSW的故障处理 22 KSWX/DSWX板的故障： 22 LANX的故障处理 23 MSI的故障处理 24 MTL的故障处理 24 BSP的故障处理 25 数据总线的故障处理 26 单通故障的处理 29二、日常维护的考前须知 29三、典型问题汇总 30序论维护工作的要旨--防患未然系统建设完成经过验收后，就转入系统维护工作。由于此时系统已经给终端用户提供效劳，网络的任何故障均可能对终端用户产生影响，从而对运营商的形象产生影响。所以维护工作的要旨是防患于未燃，将系统隐患尽早排除，不要使其成为系统故障而影响系统的性能。预防性维护是我们的最正确选择，定期对任何一个BSS网元的巡检和对基站的安装调测都进行严格的检测调整，保证系统及其附属外围设备工作在正常状态，通过集中性预防维护，可以及时发现系统隐患并加以排除，最大限度地提高现行系统设备的利用率，增强系统设备的可靠性，从而减轻平时日常维护的压力。由于各个方面的原因，诸如传输、不同厂家设备配合、各个厂家硬件的稳定性、软件、气候、环境等，使得系统会出现一些不可预知的问题。如何解决此类问题，尽快恢复系统工作。分析问题的一般思路遇到问题时，保持清醒的头脑，认真仔细的分析问题，做好必要的检查，收集相关数据，最大限度的掌握材料对于我们迅速准确的判断问题是有很大的帮助。首先我们要分清是局部问题，还是系统问题，是单个基站的问题，还是整个BSC的问题，是一个BSC的问题还是MSC下所有的BSC问题。通过初步的故障定位，进行初步的处理与测试，缩小故障范围，直到找到最终的故障原因。其次我们要通过各种方法，寻找问题可能有的规律，如特定的时间，具有周期性等等。寻找出规律，就能加快故障定位，在日常的维护中出现的最多是硬件故障，而系统的硬件又是整个网络运行的最根本保障，有些硬件故障是我们可以解决的，而有些硬件故障是需要CNRC来协助解决，所以就需要收集一些SWFM、LOG等数据。每次出现的故障及处理好后都要做记录，以便为以后出现故障提供参考。日常监控数据收集机房维护人员经常碰到告警，有些告警是操作维护过程中自然产生的，有些告警是瞬时性的，不会影响系统正常运行，但频繁的出现也会加大系统的负荷，因此对于我们维护人员来说，怎么发现告警，怎么来定义告警，有些告警是需要通过历史事件来发现跟踪，还有一些告警故障是需要CNRC来协助我们解决，在CNRC处理的过程中当然会需要一些数据分析说明，所以需要我们来收集一些告警事件，SWFM、MMILOG、EVENTLOG等数据，因此我们有必要知道日常维护中的一些命令和工具的使用。一、ECTEventcounttool是COP的工具之一，该Tool只统计ALARM告警，可以统计出整个OMC的告警次数，也可以具体统计出某个设备产生告警的次数，所以我们可以通过ECT了解现网的告警趋势，对于一些EVENT如传输、信令的闪断，和硬件板主备用的倒换这样告警事件是无法统计的，而ECT保存的数据一般是一星期，所以我们在日常的维护中如何应用该工具、如何从ECT里发现告警、如何分析告警，具体操作可参考附件：目前，如果杭州EMS系统没有故障的话，也可以使用EMS报表来统计各类告警。二、EVENTLOG：Eventlog是网元产生的所有告警信息，存放了所有的告警历史件，存放的时间一般一星期，因此当网元出现故障时，我们一般要去收集几天的Eventlog数据来进行分析，从Eventlog里可以发现具体的告警信息时间及出现的次数来找出故障的原因，对于现网中EVENT数据的收集，我们可以采用CEL命令和OMC-R上的EventLogs的窗口来收集，具体方法参考附件。三、SR数据收集由于目前浙江没有签署NSP合同，因此只能通过以下两个途径才能开SR。1.内部途径：需要上报领导批准；2.外部途径：浙江移动客户上报省公司网络部批准。SR开通后，通常需要现场协助收集故障网元的一些SWFM、MMILOG、EVENTLOG，如还需要其他数据，CNRC会给出详细的操作说明，具体操作说明详见附件。BSS系统平安监控日常的网络维护中，发现有些告警对系统影响不大，如EAS外部告警、IAS内部告警；而有些告警出现次数很少，往往出现会给系统带来严重后果，严重会导致系统重起，如GPROC、BSP、KSW等一些的告警，因此日常对这些严重的告警(BSC级以上网元)要实时监控，对于这些监控的告警内容要熟悉掌握，这样才能在发现告警后做出准确的判断处理，对这些告警尽早发现、分析、定位、解决，让网络保持良好的运行。一、告警定义在维护中一些实时告警是需要我们时时关注的，这些告警我们定义在OMC-R上EventMgt窗口上，如何在OMC-R上EventMgt窗口定义告警、如何在该窗口查看告警，请参考附件：二、监控列表及描述日常的平安监控应该从软件、硬件及信令负荷来分析处理，我们现在监控的主要是BSC级的告警，因为网络正常运行最根本的条件是硬件正常工作，如果网元都不能正常运行，所有的性能指标也毫无意义，所以在日常的网络维护中，掌握一定的告警分析和处理技能，显得非常重要，这里就对我们监控的告警进行说明解释。GPROC告警GPROC:GenericProcessorboard完成BSC站和RXCDR站的基站控制功能，如故障管理、交换控制等，支持第3层呼叫处理能力，支持信令链路，包括支持MTL、RSL、OML、XBL、CBL等信令链路处理器自检失败，处理板存在软件或硬件故障，应该去检查软件版本或硬件的相关连接，GPROC的CUP也有一定的工作极限，当BSP的CPU使用率到达100%，出现BSP[239]告警，BSC就会自动reset。晶振震荡器的故障引起GPROC退服，检查SYNC硬件及更换。主用GPROC和某个GPROC的LAN连接失败，可能导致该GPROC重起，因为GPROC下挂的信令或BTS，所以GPROC的重起会引起其它设备的重起，因此在监控中要重点去分析处理，出现该告警要去检查LAN连接及LANX、GPROC硬件。GPROC管理系统的故障引起GPROC退服，如果该GPROC是BSP会导致BSC重起，检查处理板的连接、复位该硬件板无效、进行更换。此告警说明GPROC出现一个fatalSWFM，检查该系统的软件版本。GCLK告警GCLK：GenericClockboard产生时钟信号，向上一级时钟锁相，对于BSS来说GCLK要与MSC的时钟同步，因此出现了该告警我们逐步往上查如提供时钟的MMS、GCLK硬件板等相关硬件。此告警说明GCLK晶振电路模块故障，将导致GCLKOOS。需要更换GCLK板。此告警说明GCLK无法从传输端口提取时钟，需要检查传输或传输参数。此告警说明GCLK存在不可恢复的硬件故障，需要更换。此告警GCLK锁相电路无法锁相，RXCDR或BSC出现该告警，会导致下面的所有的BTS时钟丧失，结果会引起切换失败，掉话等一些现象，所以在日常的监控中我们要重点关注。此告警说明GCLK板125μs参考时钟延时超过125μs，GCLK将自动切换到备用侧。如果7秒钟内出现2次，这块GCLK将OOS。可能是GCLK硬件故障。此告警说明GCLK板60μs参考时钟延时超过60μs，GCLK将自动切换到备用侧。如果7秒钟内出现2次，这块GCLK将OOS。可能是GCLK硬件故障。此告警说明GCLK板6.12s参考时钟延时超过6.12s，GCLK将自动切换到备用侧。如果7秒钟内出现2次，这块GCLK将OOS。可能是GCLK硬件故障。此告警说明GCLK板发生了复位。此告警说明GCLK板锁时钟失败，可能是传输故障或GCLK硬件故障。此告警说明SYNC处理器在MCU板上的Watchdog计数器超时，检查SYNC硬件及MCU板。在系统里GCLK的同步硬件没有产生16.384MHz时钟信号，导致时钟输出失败，检查SYNC硬件及MCU板。该告警说明GCLK同步严重失败，检查GCLK状态、SYNC硬件及MCU板。MCU与GCLK的同步功能失败，无法操作，检查GCLK板及SYNC硬件。此告警说明GCLK不能在即定的时间内完成预热，检查SYNC处理器及硬件。此告警说明MCU的FM进程检测到GCLK完成初始化和预热后进入的操作模式不正确GCLK板与MUAP总线通信失败，检查GCLK板和相关的MCAP总线。此告警说明GCLK的同步时钟超出的范围会影响系统性能，或时钟源需要校准。KSW告警KSW：KiloportSWitchboard千端交换板，执行TDMHIGHWAY上1024个64Kb/s时隙的交换，还可以执行32kb/s或16kb/s的交换，KSW在BSC站中完成16kb/s的动态交换功能，在RXCDR中完成静态交换功能。当BSC超过一个CAGE时就需要KSWX板来扩展KSW板的1024个Ts到另外的CAGE，KSWX板它支持TDMhighway的扩展和扩容，接受扩展时钟。KSWXError时，有可能是KSWX板子的硬件问题，也有可能是连接KSWX板的光纤故时，应该先确认故障的原因。当KSWOOS时，KSWX的故障也将不能被监控。KSWX的问题一样会导致BSC自动reset，因为它负责了TDMhighway的扩展和扩容，当它出现问题时，扩展的CAGE有可能就是失去时钟源，或者是没有了时隙分配，当然就不能正常工作了，所以系统为了尽可能恢复工作，会自动进行reset。对于KSW告警的出现我们在日常监控中也进行了分析处理并及时的派发了工单。主时钟信号丧失，说明一个KSW的CLOCKA失败，可能引起BSS的重起，检查KSWX的相关连接及GCLK板，一般该告警都是GCLK板的故障引起。该告警是相对与上面的4号告警，处理方法同4号告警，对于这两个告警任何一个告警出现我们都要综合分析处理。此告警此告警说明KSW意外地重新初始化或reset。引起告警是KSW板的硬件故障或软件版本，处理器及MMS的连接板都可能导致KSW的Reset.此告警说明KSW硬件reset了,是KSW的硬件故障及软件版本引起。KSW和FaultManagement通信失败，检查KSWX连接及硬件、MCAP底板的数据连接线、MCAP主处理器的GPROC板。本地KSWTDM循环测试失败，检查KSW硬件及TDM数据线。KSW平安自检AUDIT失败，检查KSW软硬件、MCAP数据线。此告警说明KSW无法通过MCAP总线与某个GPROC通信，处理器数据线通信失败，该告警是由KSW或GPROC板不在机架上引起的或KSW/GPROC板连接的MCAP数据线的故障引起的。KSW的Watchdog计数器超时，检查KSW硬件、处理器及外围设备板。KSW硬件失败主KSWFAIL导致KSW重起，会引起BSS重起，是KSW硬件设备引起，检查KSW硬件板及进行更换。LAN告警LAN网是BSC站/RXCDR站中各GPROC/GPROC2处理器板之间通信的局域网，几个CAGE的GPROC是否工作在同一LAN上是区分这几个CAGE是否是一个站的标志，LAN网上GPROC和LANX串联在一起，由LANX控制本CAGE的LAN自成环网还是与其它CAGE的LAN组成一个网，BSSC机柜中有一主一备两个LAN网。此告警说明LAN的检测进程无法将activeLANSWAP到另一个LAN，主备LANOOS，检查主备LAN板及光纤连接。LAN设备故障OOS，GPROC的重起及硬件故障、LAN板、LANX板及相连接的光纤都可能引起该告警。BSP告警BSP：BaseStationProcessor,被定义在GPROC上是BSSC总处理器，分主备用，出现问题时，整个BSSC都要受到严重影响，BSPRESET后，整个BSSC都会RESET,因此在日常维护中对该处理器的监控及处理是非常重要的。BSP上的Lapd控制器出现严重错误。BSP监察到TDMClockAFailure引起BSCOOS,检查KSWXA板、CLOCKA在GPROC上的接受电路、光纤及相关连接。BSP监察到TDMClockBFailure引起BSCOOS，检查KSWXB板、CLOCKB在GPROC上的接受电路、光纤及相关连接。分配时隙的记数器溢出引起TDM接口失败，检查分配时隙的记数器、MCAP接口及MCAP的地址数据总线。TDM奇偶校验错误，检查和GPROC、KSW/KSWX相连接的TDM数据线。主用的GPROC和备用的BSP通信失败，不在同一LAN上，检查GPROC硬件、LANX连接及硬件。处理器的软件故障，检查处理器的软件版本、GPROC硬件。BSP在TBUS时隙指定配置出现程序错误，该告警是软件或GPROC硬件板引起。处理板的软硬件故障引起处理器自检失败，检查处理器的连接及GPROC硬件板。该告警说明BSPFailure，检查GPROC硬件及相关连接。MSI告警MSI板实现E1信号与TDMHIGHWAY上信号的相互转换。1块MSI板终端2个E1，提取2M时钟参考信号。对于RXCDR站8#、10#槽位是主用槽位，对于BSC站14#、16#槽位是主用槽位，主用槽位上定义了起站时用来从OMC下载软件和数据库的缺省OML链路。此告警说明MSI〔XCDR，GDP〕的DSPauditfail。此告警说明MSI(XCDR,GDP)无法通过MCAP总线与GPROC通信。MTL告警MTL链路是MSC与BSC的信令链路，其在整个系统中起着MSC与MS、BSS连接的作用。MTL出现问题会导致其下属所有的BSS瘫痪。MTL最多的告警一般为0号告警，出现此告警时MTL为D-U。此告警表示MTL链路与MSC已经失去联系。这是由于MTP第二层出现问题，而退出效劳。但系统会不断尝试恢复此链路。另外当一条MTL链路退出效劳时，其负荷会分配到其它MTL上，加重其它MTL的负担，因此MTL链路负担过重，会使得GPROC退出效劳，从而导致更多的链路退出效劳，在杭州的现网中建议MTL的利用率不要超过40%〔40%的MTL利用率是指TX或RX中的任意一条都建议工作在不大于此门限之下〕。MTL0号告警表示一条MTL退出效劳，而一个BSS可能有多条MTL链路，一条MTL退出效劳不会导致系统重起，如出现频繁就要去检查数据库内关于MTL链路定义有无问题，然后检查有关的MMS口、MSI板是否退出效劳，再查与MSC的信令点码是否正确，在日常的监控中发现很少是数据库，MMS口、MSI板的问题，大局部是MSC传来的MTP第二层LSSU信息引起的。是MSC处理器远端的MTP第二层LSSU链路故障导致MTL被BLOCK掉，该告警几乎很少出现，在监控中也没有发现该问题。MTL信令负荷超过门限，系统拥塞，会影响GSM的效劳，建议去增加MTL链路，MTL扩容。一个BSS可能有好多条MTL链路，BSS0告警表示此BSS系统的最后一条链路也退出效劳，此时BSS完全瘫痪。此时我们要去检查数据库内关于MTL链路定义有无问题，然后检查有关的MMS口、MSI板是否退出效劳，再查与MSC的信令点码是否正确，在确认上述方面无问题后检查GPROC是否有硬件问题，必要时复位该GPROC。XBL告警XBL:TranscodertoBSSLink.是通过MMSE1/T1链路连接，BSC和RXCDR是通过几条XBL信令链路通信的，如果其中某条中断会增加其它信令的负荷，如果负荷超过极限会导致BSSC系统重起，在现网摩托罗拉建议此项指标的预警门限设定在50%。XBL中断，BSC与RXCDR失去通信，检查XBL所在的传输及协议。XBL链路的业务量太大而使的链路中断，建议对该链路进行扩容。该告警是在一分钟内LAPDlayer二层协议出错超出30次，检查传输及相关的协议。数据总线告警BSS在软件上存在着PBUS、SBUS、TBUS和CBUS四种总线，这四种总线我们可以在BSC的MMI—RAM状态下通过state命令来查看它们的工作状态。TBUS它由KSW控制，有1024个Ts，分配给GPROC、MSI、XCDR、KSW，可扩展扩容。此告警说明在扩展cage内的50%GPROC和remoteKSW间的TDM自环测试fail。本地KSWX/DSWX的TDM错误，一般是KSWX/DSWX的光纤连接或硬件板的故障引起。该告警是和3号告警相对的，远端KSWX/DSWX的TDM错误。CBUS即ClockDistributionBus，通过此总线将GXLK时钟传到CAGE背板。给GPROC、KSW、MSI、XCDR等提供时钟，这些BUS都是每个CAGE一主一备的。此告警说明一个cage中有超过50%GPROC和全尺寸板无法使用CBUS总线。此告警说明因为GCLK被取走使得CBUS无法工作。此时CBUS为OOS。此告警说明连到lclKSWX的CBUS光纤出现问题或DSWX板的硬件问题。PBUS即ProcessorBus，它是MCAP总线在软件上的一种表示，它负责GPROC与其他全尺寸板〔XCDR、GCLK、KSW、DRI〕之间的通信。此告警说明activePBUSfailBSS告警从MSC侧得不到电路BLOCK确实认应答从MSC侧得不到电路UNBLOCK确实认应答从MSC侧得不到RESET电路确实认应答增加该CIC或BSC删除该CIC增加该CIC或MSC删除该CICRCI的TRAU同步丧失MSC与BSC侧的告警PCI的TRAU同步丧失故障处理分析在日常的维护中，会遇到各种各样的故障，为了对现场处理故障有更多的了解，我们选择一些平时处理故障的的案例，分析一些故障产生的原因，并对一些故障的分析思路、最总解决手段进行分析说明。一、常见故障分析处理GPROC的故障处理根据日常的维护发现，GPROC出现的告警最多是“[35]LANConnectionFailure〞GPROC是BSC机柜中数字处理板，它支持与MSC的信令链路〔MTL〕、与BTS的信令链路〔RSL〕、CBC接口的CBL链路以及与RXCDR接口的XBL链路，支持以上这些链路的协议，支持第三层呼叫处理功能，以及BSC的许多如故障管理、开关控制等的控制功能。GPROC可被定义成BSP、CSFP和普通的GPROC，当主用的GPROC板也就是BSP，出现问题时，整个BSC的工作就受到严重影响，将主用GPROCreset后，就有可能使整个BSC都reset，而[35]告警说明该GPROC不工作在整个BSC的LAN上了。该故障的可能原因是：GPROC板通过软件操作或硬件操作被Reset；GPROC板的故障；LANX硬件的故障或光纤物理损坏。如果是BSS上的某个GPROC出现[35]号告警，应该可以判断是该GPROC的故障，建议更换。GCLK的故障处理GCLK产生时钟，向上一级的时钟锁相，GCLK最多的告警是PhaseLockLost。GLCK的功能是使得系统与更准确的时钟同步，对于BSS来说，GCLK要与MSC的时钟同步。GCLK要与上一级时钟同步必须要有上一级时钟的参考信号，时钟参考信号是根据数据库的定义从指定的MMS口上提取的。在database中需要定义不同MMS口的时钟提取优先等级。该故障的可能原因是：因传输问题引起MMS退服MSI板或MMS口硬件故障数据库定义不合理GCLK本身的问题，需要校正或更换当出现GCLK无法锁相的告警时首先要搞清楚参考时钟是从哪里来的。检查一下数据库中有关GCLK的参数设置是否合理，如锁相应向上锁，即RXCDR向MSC锁、BSC向RXCDR锁、BTS向BSC或上一级的BTS〔只有菊花链的情况〕锁，如果数据库设置没有明显不合理之处，应注意一下与时钟提取有关的MMS口和MSI板的状态，MMS口退服可能是传输问题引起的，也可能是MSI板或MMS口硬件故障引起的，如果MSI板工作正常那么应着重检查传输质量。在排除了数据库、MSI硬件和传输原因之后，应校正或更换GCLK板，而日常的时钟失锁根本上都是传输问题引起，虽然GCLK失锁不会给系统带来致命后果，但也会给网络的指标带来负面影响。由于4月23日HZBSC163发生了GCLK问题导致BSC退服事件，因此现在开始，需要对GCLKPhaseLockLost或GCLKPhaseLockFailure的BSC/XCDR重点监控，发现GCLKPhaseLockFailed的，应该及时派发工单给杭分处理。KSW的故障处理KSW执行TDMHIGHWAY上1024个64Kb/s时隙的交换。也能进行32Kb/s或16Kb/s的交换，RXCDR站中完成静态交换功能〔钉连〕，BSC站中完成16Kb/s动态交换功能。KSW出现最多的告警是ClockA/BSignalLoss该故障的可能原因：GCLK/KSWXA/B可能损坏；接受电路引起KSWFAIL；MCAP或那么TDM处理总线接口。当KSW出现这些告警时，我们要收集近几天的eventlog数据来发现问题，因为该告警的出现也许不仅仅是KSW板的问题，根据日常出现的故障发现，如果同时出现时钟失锁，应该首先定位在GCLK上，如果时钟没有失锁，而出现了TDM的闪断，这时候我们应该关注半尺寸板KSWX，所以在这些告警出现时，要综合的去考虑分析，定位出故障。KSWX/DSWX板的故障：当BSC超过一个CAGE时就需要KSWX板来扩展KSW板的1024个Ts到另外的CAGE，KSWX板它支持TDMhighway的扩展和扩容，接受扩展时钟。KSWXError时，有可能是KSWX板子的硬件问题，也有可能是连接KSWX板的光纤故障，也有可能是与它通信的另一CAGE的KSWX板有问题。所以当我们发现有KSWX的Alarm时，应该先确认故障的原因。当KSWOOS时，KSWX的故障也将不能被监控。KSWX的问题一样会导致BSC自动reset，因为它负责了TDMhighway的扩展和扩容，当它出现问题时，扩展的CAGE有可能就是失去时钟源，或者是没有了时隙分配，当然就不能正常工作了，所以系统为了尽可能恢复工作，会自动进行reset。如[24]KSWX/DSWXinSlot9DetectedExpanded；[25]KSWX/DSWXinSlot21DetectedExpanded；[26]KSWX/DSWXinSlot22DetectedExpandedKSWMatrixFailure，出现这些告警，首先考虑CAGE0上的CLKX与相对应的CAGE的KSWX/DSWX板的光纤、光纤连接及半尺寸的硬件板，通过日常的故障处理，这些告警根本都是半尺寸的问题引起，而这些硬件板的故障率也较大。LANX的故障处理LANX板是每个BSU/RXUCAGE里所必须要有的板子，它由两条串行总线连接与GPROC板之间的通信，以及不同CAGE之间的通信。当LANX出现问题变为D--U时，GPROC之间的通信就不能进行，整个BSC的就不能正常工作，在这种情况下，BSC有可能会试图修复故障，重新建立LAN，它就会自动reset。如果确实为板子硬件问题，当然reset也好不了，这时候我们就必须更换LANX才能解决问题了。一般每个CAGE配两块LANX，为一主一备，这样工作就比拟保险，不至于一个LANX一坏就整个BSCOOS。如：LANFailure告警。该故障的可能原因：某GPROC的故障也会引起LANOOSLAN或LANX硬件板的故障LANX的光纤故障在某时段LAN的信息超过负荷MSI的故障处理MSI出现的最多告警就是MSI-GDP的DSPChannel(0–29)AuditFailure，，GDP是完成话音的压缩编码和速率适配，支持增强型语音编码和话音控制，虽然该告警不会导致BSS系统Reset，但是出现DSPChannelAuditFailure会引起单通，在日常的监控中，如发现该故障建议更换硬件板MTL的故障处理MTL链路是MSC与BSC的信令链路，其在整个系统中起着MSC与MS、BSS连接的作用。MTL直接与BSC与MSC相连，或者是经过RemoteXCDR与MSC相连。它使用C7协议，MTL提供了MSC与BSC、MSC与MS之间的控制信息。MTL是MTP的Layer2链路，当MTLOOS时，LocalMTPLayer2与RemoteMTPLayer2之间的通信也就Fail了。该故障的可能原因：连接MTL的MSI板FailMSC的处理器ＦailBSC端GPROC的FailMSC传来的MTP第二层LSSU信息出现错误。在出现告警时首先要判断是传输、MSI的问题还是MSC的问题。disp_eq0MTL**查看MTL所在的MMS，用state0mms**查看MMS的状态，如果MMS出现过闪断应该是传输问题引起，如果没有出现闪断，应该是MSC传来的MTP第二层LSSU信息出现错误，在日常的监控中大局部是MSC传来的MTP第二层LSSU信息出现错误引起的。BSP的故障处理BSP是BSC/RXCDR的处理器，都是配置一主一备，如果BSP出现reset，整个网元也就reset了，因此在日常维护中对该处理器的监控及处理是非常重要的。根据日常出现过的故障发现，有时候BSP硬件故障会突然导致BSS复位，BSP的故障发生率是很低，如：RXCDR自动重启，CNRC的分析说明：故障分析：经过分析，发现在故障发生时，主用011bh报告了以下fatal和nonfatalSWFM"process_user_interrupts"，这说明RXCDR的重启是由主用BSP的硬件故障引起的。SWFMLogEntry2182FATALSWFMERROR:SOFTRESETRoutine:process_user_interrupts182Area:0x00000001Error:0x00000000PC:0xd00261aePID:0x00(Null)18224-Apr-200605:01:50.865Subsystem:0x01CPU:0x011bBoard:GPROC3RAM182T7130resetforrecoverytimeout.RecoveryType:29SWFMLogEntry121179NonfatalSWFMErrorRoutine:process_user_interrupts179Area:0x00000001Error:0x0000001dPC:0xd002656ePID:0x00(Null)17924-Apr-200605:01:45.865Subsystem:0x01CPU:0x011bBoard:GPROC3RAM179Channel:5179HDLC:T7130ALARM29179ChannelState:8179ReadAddress:15179WriteAddress:9ea2a179InternalStack:179422d19271ff9393027a3179通过进一步对swfmlog的分析，我们发现在RXCDR重启之前系统的主用BSP有如下swfm：12117924-Apr-200605:01:45.865d002656e00Nullprocess_user_interrupts

12217a24-Apr-200605:01:45.870c0000de213LAPDLSPdl_data_req

12317b24-Apr-200605:01:45.875c000149613LAPDLSPdl_flowcontrol_req

12417c24-Apr-200605:01:46.080c000149613LAPDLSPdl_flowcontrol_req

12517d24-Apr-200605:01:46.125c00004ae45Validateperform_hdlc_config.c

12617e24-Apr-200605:01:46.290c000149613LAPDLSPdl_flowcontrol_req

12717f24-Apr-200605:01:46.335c00004ae45Validateperform_hdlc_config.c

018024-Apr-200605:01:46.335c0044a6442CAgproc_hdlc_recover.c

118124-Apr-200605:01:46.500c000149613LAPDLSPdl_flowcontrol_reqSWFMLogEntry127

17fNonfatalSWFMError

Routine:perform_hdlc_config.c

17fArea:0x00000309Error:0x00000003PC:0xc00004aePID:0x45(Validate)

17fBSSRelease:1.7.6.f0.36ObjVersion:.bExecVersion:7.1

17f24-Apr-200605:01:46.335Subsystem:0x01CPU:0x011bBoard:GPROC3RAM

17fReturncodefromhdlc_init=253#defineT7130_CODE_LOAD_FAIL253从以上log文件，我们看到在T7130重启恢复的过程中，SWFM指明failedtocodeloadT7130chip，所以GPROC板最终因T7130恢复失败而重启。因此我们可以得出这是T7130硬件问题导致的主用BSP重启，从而造成系统重启。数据总线的故障处理BSC在软件上存在着PBUS、SBUS、TBUS和CBUS四种总线，这四种总线我们可以在BSC的MMI—RAM状态下通过state命令来查看它们的工作状态。?PBUS?即ProcessorBus，它是MCAP总线在软件上的一种表示，它负责GPROC与其他全尺寸板〔XCDR、GCLK、KSW、DRI〕之间的通信。当PBUSDeviceFailure时，BSC就会Reboot，在这个初始化过程中，BSCOOS。PBUSDeviceFailure的原因可能是：①LANX板Faulty；②可能是FTP〔故障传输局部〕和FCP〔故障收集局部〕之间的错误引起的。?SBUS?即SerialBus,它上面的通信由GPROC控制，主要负责GPROC与半尺寸板〔如LANX、KSWX、GLKX、DRIX〕之间的通信。每个CAGE也是一主一备的SBUS，但它们被分配不同的任务，Standby不享有ActiveSBUS的功能。当SBUSfail后，BSC就会自动reset。reset结束后，如果SBUS仍然是OOS，那么就必须去检查具体原因了。SBUS有故障时，你必须考虑所有被主GPROC控制的SBUS上的通信。SBUSFailure的原因可能如下：①LANX板子没有插好，与背板的连接不正确。②LANX板子Fail.③GPROC板Fail，使SBUS上的通信不正常。④BTC板不能给背板供电。⑤半尺寸板在背板得不到电源。当我们发现SBUSOOS时，可以从以上几方面来考虑检查故障，不让BSC不停地REBOOT。?TBUS?即TDMBUS。它由KSW控制，有1024个Ts，分配给GPROC、MSI、XCDR、KSW，可扩展扩容。在TDM高速总线故障的情况下，系统的TBUS就会D—U，TBUSD—U后，就会要求TDMhighway做SWAP，这个SWAP将会使CAGE里的所有的TBUS一样做SWAP，如果此CAGE不能SWAPTBUS，那么此CAGE也就变为Disable,这样就会引起BSC的reset。如在现网中出现的这些告警[2]RemoteKSWXTDMError；[4]RemoteKSW/DSWXTDMError；[0]RemoteKSWTDMloopbackTestFailure，根本是KSWX/DSWX的故障引起。引起TBUSFail的原因可能如下：①连接Local与Remote的KSWX的光纤有问题，或者断了②KSWX板子Failure。?CBUS?即Clock