摩托罗拉BSS系统安全监控手册(motorola).doc

摩托罗拉BSS系统安全监控手册摩托罗拉浙江分公司协维组内容提要本部分内容综述GSM BSC级系统网络的硬件告警处理及一些日常监控方法，提供维护过程中分析问题的一般思路，对常见告警的处理，实际故障解析等。对一些工具的使用，还有常见故障的案例和日常维护工作的注意事项。通过本部分的学习读者将具有GSM BSC级网络维护的一般知识，掌握BSS系统基本维护技能，能够承担日常的网络维护工作。目录序论4维护工作的要旨-防患未燃4分析问题的一般思路5第一章日常监控数据收集6一、ECT6二、EVENT LOG ：7第二章BSS系统安全监控8一、告警定义8二、监控列表及描述8GPROC告警9GCLK告警10KSW告警11LAN告警13BSP告警14MSI告警15MTL告警15XBL告警17数据总线告警17BSS告警19第三章故障处理分析20一、常见故障分析处理20GPROC的故障处理20GCLK的故障处理21KSW的故障处理22KSWX/DSWX板的故障：22LANX的故障处理23MSI的故障处理24MTL的故障处理24BSP的故障处理25数据总线的故障处理26单通故障的处理29二、日常维护的注意事项29三、典型问题汇总30序论维护工作的要旨-防患未然系统建设完成经过验收后，就转入系统维护工作。由于此时系统已经给终端用户提供服务，网络的任何故障均可能对终端用户产生影响，从而对运营商的形象产生影响。所以维护工作的要旨是防患于未燃，将系统隐患尽早排除，不要使其成为系统故障而影响系统的性能。预防性维护是我们的最佳选择，定期对任何一个BSS网元的巡检和对基站的安装调测都进行严格的检测调整，保证系统及其附属外围设备工作在正常状态，通过集中性预防维护，可以及时发现系统隐患并加以排除，最大限度地提高现行系统设备的利用率，增强系统设备的可靠性，从而减轻平时日常维护的压力。由于各个方面的原因，诸如传输、不同厂家设备配合、各个厂家硬件的稳定性、软件、气候、环境等，使得系统会出现一些不可预知的问题。如何解决此类问题，尽快恢复系统工作。 分析问题的一般思路遇到问题时，保持清醒的头脑，认真仔细的分析问题，做好必要的检查，收集相关数据，最大限度的掌握材料对于我们迅速准确的判断问题是有很大的帮助。首先我们要分清是局部问题，还是系统问题，是单个基站的问题，还是整个BSC的问题，是一个BSC的问题还是MSC下所有的BSC问题。通过初步的故障定位，进行初步的处理与测试，缩小故障范围，直到找到最终的故障原因。其次我们要通过各种方法，寻找问题可能有的规律，如特定的时间，具有周期性等等。寻找出规律，就能加快故障定位，在日常的维护中出现的最多是硬件故障，而系统的硬件又是整个网络运行的最基本保障，有些硬件故障是我们可以解决的，而有些硬件故障是需要CNRC来协助解决，所以就需要收集一些SWFM、LOG等数据。每次出现的故障及处理好后都要做记录，以便为以后出现故障提供参考。 第一章 日常监控数据收集机房维护人员经常碰到告警，有些告警是操作维护过程中自然产生的，有些告警是瞬时性的，不会影响系统正常运行，但频繁的出现也会加大系统的负荷，因此对于我们维护人员来说，怎么发现告警，怎么来定义告警，有些告警是需要通过历史事件来发现跟踪，还有一些告警故障是需要CNRC来协助我们解决，在CNRC处理的过程中当然会需要一些数据分析说明，所以需要我们来收集一些告警事件，SWFM、MMI LOG、EVENT LOG等数据，因此我们有必要知道日常维护中的一些命令和工具的使用。一、ECTEvent count tool 是COP的工具之一，该Tool只统计ALARM 告警，可以统计出整个OMC的告警次数，也可以具体统计出某个设备产生告警的次数，所以我们可以通过ECT了解现网的告警趋势，对于一些EVENT如传输、信令的闪断，和硬件板主备用的倒换这样告警事件是无法统计的，而ECT保留的数据一般是一星期，所以我们在日常的维护中如何应用该工具、如何从ECT里发现告警、如何分析告警，具体操作可参考附件： 目前，如果杭州EMS系统没有故障的话，也可以使用EMS报表来统计各类告警。二、EVENT LOG ：Event log是网元产生的所有告警信息，存放了所有的告警历史件，存放的时间一般一星期，因此当网元出现故障时，我们一般要去收集几天的Event log 数据来进行分析，从Event log里可以发现具体的告警信息时间及出现的次数来找出故障的原因，对于现网中EVENT数据的收集，我们可以采用CEL命令和OMC-R上的Event Logs的窗口来收集，具体方法参考附件。 三、SR数据收集由于目前浙江没有签署NSP合同，因此只能通过以下两个途径才能开SR。1.内部途径：需要上报领导批准；2.外部途径：浙江移动客户上报省公司网络部批准。SR开通后，通常需要现场协助收集故障网元的一些SWFM、MMI LOG、EVENT LOG，如还需要其他数据，CNRC会给出详细的操作说明，具体操作说明详见附件。 第二章 BSS系统安全监控日常的网络维护中，发现有些告警对系统影响不大， 如EAS外部告警、IAS内部告警；而有些告警出现次数很少，往往出现会给系统带来严重后果，严重会导致系统重起，如 GPROC、BSP、KSW等一些的告警，因此日常对这些严重的告警(BSC级以上网元)要实时监控，对于这些监控的告警内容要熟悉掌握，这样才能在发现告警后做出准确的判断处理，对这些告警尽早发现、分析、定位、解决，让网络保持良好的运行。一、告警定义在维护中一些实时告警是需要我们时时关注的，这些告警我们定义在OMC-R上Event Mgt窗口上，如何在OMC-R上Event Mgt窗口定义告警、如何在该窗口查看告警，请参考附件：二、监控列表及描述日常的安全监控应该从软件、硬件及信令负荷来分析处理，我们现在监控的主要是BSC级的告警，因为网络正常运行最基本的条件是硬件正常工作，如果网元都不能正常运行，所有的性能指标也毫无意义，所以在日常的网络维护中，掌握一定的告警分析和处理技能，显得非常重要，这里就对我们监控的告警进行说明解释。 GPROC告警GPROC:Generic Processor board 完成BSC站和RXCDR站的基站控制功能，如故障管理、交换控制等，支持第3层呼叫处理能力，支持信令链路，包括支持MTL、RSL、OML、XBL、CBL等信令链路 239号告警：“ Process Safe test Audit Failure”处理器自检失败，处理板存在软件或硬件故障，应该去检查软件版本或硬件的相关连接，GPROC的CUP也有一定的工作极限，当BSP的CPU使用率达到100%，出现BSP239告警，BSC就会自动reset。 24号告警：“ Bad Clock Source or SYNC OCXO(oscillator) Replacement Required”晶振震荡器的故障引起GPROC退服，检查SYNC硬件及更换。 35号告警:“ LAN Connection Failure”主用GPROC和某个GPROC的LAN连接失败，可能导致该GPROC重起，因为GPROC下挂的信令或BTS，所以GPROC的重起会引起其它设备的重起，因此在监控中要重点去分析处理，出现该告警要去检查LAN连接及LANX、GPROC硬件。 254号告警:“ Device Failure”GPROC管理系统的故障引起GPROC退服，如果该GPROC是BSP会导致BSC重起，检查处理板的连接、复位该硬件板无效、进行更换。 39号告警：“Software Failure” 此告警表明GPROC出现一个fatal SWFM，检查该系统的软件版本。 GCLK告警GCLK：Generic Clock board产生时钟信号，向上一级时钟锁相，对于BSS来说GCLK要与MSC的时钟同步，因此出现了该告警我们逐步往上查如提供时钟的MMS、GCLK硬件板等相关硬件。 0号告警：“Reference distribution module failure”此告警说明GCLK晶振电路模块故障，将导致GCLK OOS。需要更换GCLK板。 2号告警：“Clock reference failure”此告警说明GCLK无法从传输端口提取时钟，需要检查传输或传输参数。 3号告警：“Hardware Fault Detected”此告警说明GCLK存在不可恢复的硬件故障，需要更换。 4号告警：“Phase lock lost ”此告警GCLK锁相电路无法锁相，RXCDR或BSC出现该告警，会导致下面的所有的BTS时钟丢失，结果会引起切换失败，掉话等一些现象，所以在日常的监控中我们要重点关注。 5号告警:“125 s reference count overow”此告警说明GCLK板125s参考时钟延时超过125s，GCLK将自动切换到备用侧。如果7秒钟内出现2次，这块GCLK将 OOS。可能是GCLK硬件故障。 6号告警:“60 ms reference count overow”此告警说明GCLK板60s参考时钟延时超过60s，GCLK将自动切换到备用侧。如果7秒钟内出现2次，这块GCLK将 OOS。可能是GCLK硬件故障。 7号告警:“6.12 seconds reference count overow”此告警说明GCLK板6.12 s参考时钟延时超过6.12 s，GCLK将自动切换到备用侧。如果7秒钟内出现2次，这块GCLK将 OOS。可能是GCLK硬件故障。 9号告警:“Hard reset”此告警说明GCLK板发生了复位。 14号告警:“Phase lock failure”此告警说明GCLK板锁时钟失败，可能是传输故障或GCLK硬件故障。 15号告警:“ Watchdog Timer Expired ”此告警说明SYNC处理器在MCU板上的Watchdog计数器超时，检查SYNC硬件及MCU板。 16号告警:“ Clock Output Failure”在系统里GCLK的同步硬件没有产生16.384MHz时钟信号，导致时钟输出失败，检查SYNC硬件及MCU板。 17号告警:“ SYNC Shutdown Request”该告警表明GCLK同步严重失败，检查GCLK状态、SYNC硬件及MCU板。 18号告警:“ Not Operational”MCU与GCLK的同步功能失败，无法操作，检查GCLK板及SYNC硬件。 19号告警:“ Warmup Failure”此告警表明GCLK不能在即定的时间内完成预热，检查SYNC处理器及硬件。 20号告警:“ Invalid Mode”此告警表明MCU的FM进程检测到GCLK完成初始化和预热后进入的操作模式不正确 232号告警:“ Processor Bus Communication Failure”GCLK板与MUAP总线通信失败，检查GCLK板和相关的MCAP总线。 24号告警: “Bad clock source此告警表明GCLK的同步时钟超出的范围会影响系统性能，或时钟源需要校准。 KSW告警KSW ：Kiloport SWitch board 千端交换板，执行TDM HIGHWAY 上1024 个64Kb/s时隙的交换，还可以执行32kb/s 或16kb/s的交换，KSW在BSC站中完成16kb/s的动态交换功能，在RXCDR中完成静态交换功能。当BSC超过一个CAGE时就需要KSWX板来扩展KSW板的1024个Ts到另外的CAGE ，KSWX板它支持TDM highway的扩展和扩容，接受扩展时钟。KSWX Error时，有可能是KSWX板子的硬件问题，也有可能是连接KSWX板的光纤故时，应该先确认故障的原因。当KSW OOS时，KSWX的故障也将不能被监控。KSWX的问题一样会导致BSC自动reset，因为它负责了TDM highway的扩展和扩容，当它出现问题时，扩展的CAGE有可能就是失去时钟源，或者是没有了时隙分配，当然就不能正常工作了，所以系统为了尽可能恢复工作，会自动进行reset。对于KSW告警的出现我们在日常监控中也进行了分析处理并及时的派发了工单。 4号告警:“ Clock A Signal Loss”主时钟信号丢失，表明一个KSW的CLOCK A 失败，可能引起BSS的重起，检查KSWX的相关连接及GCLK板，一般该告警都是GCLK板的故障引起。 5号告警:“ Clock B Signal Loss”该告警是相对与上面的4号告警，处理方法同4号告警，对于这两个告警任何一个告警出现我们都要综合分析处理。 7号告警:“ Re-Initialized Unexpectedly”此告警此告警表明KSW意外地重新初始化或reset。引起告警是KSW板的硬件故障或软件版本，处理器及MMS的连接板都可能导致KSW的Reset. 8号告警:“ Hard Reset”此告警表明KSW硬件reset了,是KSW的硬件故障及软件版本引起。 10号告警:“ Lost Communication with KSW”KSW和Fault Management通信失败，检查KSWX连接及硬件、MCAP底板的数据连接线、MCAP主处理器的GPROC板。 11号告警:“ Local Cage KSW TDM Loopback Test Failure” 本地KSW TDM循环测试失败，检查KSW硬件及TDM数据线。 224号告警:“ Safe Test Audit Failure”KSW安全自检AUDIT失败，检查KSW软硬件、MCAP数据线。 232号告警:“ Processor Bus Communication Failure”此告警表明KSW无法通过MCAP总线与某个GPROC通信，处理器数据线通信失败，该告警是由KSW或GPROC板不在机架上引起的或KSW/GPROC板连接的MCAP数据线的故障引起的。 9号告警:“Watchdog timer Expired” KSW的Watchdog计数器超时，检查KSW硬件、处理器及外围设备板。 254号告警:“ Device Failure”KSW硬件失败主KSW FAIL 导致KSW重起，会引起BSS重起，是KSW硬件设备引起，检查KSW硬件板及进行更换。 LAN告警LAN 网是BSC 站/RXCDR 站中各GPROC/GPROC2 处理器板之间通信的局域网，几个CAGE的GPROC是否工作在同一LAN上是区分这几个CAGE是否是一个站的标志，LAN网上GPROC和LANX 串联在一起，由LANX 控制本CAGE 的LAN 自成环网还是与其它CAGE 的LAN 组成一个网，BSSC 机柜中有一主一备两个LAN 网。 0号告警:“ Active & Standby LAN Failure”此告警表明LAN的检测进程无法将active LAN SWAP到另一个LAN，主备LAN OOS，检查主备LAN板及光纤连接。 1号告警:“ LAN Failure” LAN设备故障OOS，GPROC的重起及硬件故障、LAN板、LANX板及相连接的光纤都可能引起该告警。 X25 告警：“X25CircuitDown” BSP告警BSP：Base Station Processor ,被定义在GPROC上是BSSC总处理器，分主备用，出现问题时，整个BSSC都要受到严重影响，BSP RESET 后，整个BSSC都会RESET,因此在日常维护中对该处理器的监控及处理是非常重要的。 20号告警：“Lapd Controller Failure ” BSP上的Lapd控制器出现严重错误。 30号告警:“ Clock A Signal Loss”BSP监察到TDM Clock A Failure 引起BSC OOS,检查KSWXA板、CLOCK A在GPROC上的接受电路、光纤及相关连接。 31号告警:“ Clock B Signal Loss”BSP监察到TDM Clock B Failure 引起BSC OOS，检查KSWXB板、CLOCK B在GPROC上的接受电路、光纤及相关连接。 32号告警:“ TDM Interface Failure”分配时隙的记数器溢出引起TDM接口失败，检查分配时隙的记数器、MCAP接口及MCAP的地址数据总线。 34号告警:“ TDM Interface Failure TDM Parity Error”TDM奇偶校验错误，检查和GPROC、KSW/KSWX 相连接的TDM 数据线。 35号告警:“ LAN Connection Failure”主用的GPROC和备用的BSP通信失败，不在同一LAN上，检查GPROC硬件、LANX连接及硬件。 39号告警:“ Software Failure”处理器的软件故障，检查处理器的软件版本、GPROC硬件。 231号告警:“ TDM Interface Configuration Failure”BSP在TBUS时隙指定配置出现程序错误，该告警是软件或GPROC硬件板引起。 239号告警:“ Process Safe Test Audit Failure”处理板的软硬件故障引起处理器自检失败，检查处理器的连接及GPROC硬件板。 254号告警:“ Device Failure”该告警表明BSP Failure，检查GPROC硬件及相关连接。 MSI告警MSI板实现E1 信号与TDM HIGHWAY 上信号的相互转换。1 块MSI 板终端2 个E1，提取2M 时钟参考信号。对于RXCDR 站8#、10#槽位是主用槽位，对于BSC 站14#、16#槽位是主用槽位，主用槽位上定义了起站时用来从OMC 下载软件和数据库的缺省OML 链路。 MSI 11- MSI 40 “DSP Channel (029) Audit Failure”此告警表明MSI（XCDR，GDP）的DSP audit fail。 MSI 232“ Processor Bus Communication Failure”此告警表明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中的任意一条都建议工作在不大于此门限之下）。 0号告警：“Signalling link failure”； MTL 0号告警表示一条MTL退出服务，而一个BSS可能有多条MTL链路，一条MTL退出服务不会导致系统重起，如出现频繁就要去检查数据库内关于MTL链路定义有无问题，然后检查有关的MMS口、MSI板是否退出服务，再查与MSC的信令点码是否正确，在日常的监控中发现很少是数据库，MMS口、MSI板的问题，大部分是MSC传来的MTP第二层LSSU信息引起的。 1号告警：“ MSC Processor Outage”； 是MSC处理器远端的MTP第二层LSSU链路故障导致MTL被BLOCK掉，该告警几乎很少出现，在监控中也没有发现该问题。 3号告警：“ LinkTraffic Too High”；MTL信令负荷超过门限，系统拥塞，会影响GSM的服务，建议去增加MTL链路，MTL扩容。 BSS0 告警：Last MTL link Failure Signalling Point Inaccessible一个BSS可能有好多条MTL链路，BSS0告警表示此BSS系统的最后一条链路也退出服务，此时BSS完全瘫痪。此时我们要去检查数据库内关于MTL链路定义有无问题，然后检查有关的MMS口、MSI板是否退出服务，再查与MSC的信令点码是否正确，在确认上述方面无问题后检查GPROC是否有硬件问题，必要时复位该GPROC。 XBL告警XBL: Transcoder to BSS Link.是通过MMS E1/T1链路连接，BSC和RXCDR 是通过几条XBL信令链路通信的，如果其中某条中断会增加其它信令的负荷，如果负荷超过极限会导致BSSC系统重起，在现网摩托罗拉建议此项指标的预警门限设定在50%。 10号告警:“ Link Disconnected ”XBL中断，BSC与RXCDR失去通信，检查XBL所在的传输及协议。 12号告警:“ Link Traffic Too High” XBL链路的业务量太大而使的链路中断，建议对该链路进行扩容。 13号告警:“ LAPD Protocol Error Threshold Exceeded”该告警是在一分钟内LAPD layer二层协议出错超出30次，检查传输及相关的协议。 数据总线告警BSS在软件上存在着PBUS、SBUS、TBUS和CBUS四种总线，这四种总线我们可以在BSC的MMIRAM状态下通过state命令来查看它们的工作状态。TBUS它由KSW控制，有1024个Ts，分配给GPROC、MSI、XCDR、KSW，可扩展扩容。 0号告警：TBUS: Remote KSW Loopback Test Failure此告警表明在扩展cage内的50%GPROC和remote KSW间的TDM自环测试fail。 3号告警：Local KSWX/DSWX TDM Error 本地KSWX/DSWX的TDM错误，一般是KSWX/DSWX的光纤连接或硬件板的故障引起。 4号告警：Remote KSWX/DSWX TDM Error该告警是和3号告警相对的，远端KSWX/DSWX的TDM错误。CBUS即Clock Distribution Bus，通过此总线将GXLK时钟传到CAGE背板。给GPROC、KSW、MSI、XCDR等提供时钟，这些BUS都是每个CAGE一主一备的。 0号告警 ：Over 50% Of Boards Detected Clock Failure ”此告警表明一个cage中有超过50%GPROC和全尺寸板无法使用CBUS总线。 2号告警：“Master CBUS Signal Provided By Slave GCLK ” 此告警表明因为GCLK被取走使得CBUS无法工作。此时CBUS为OOS。 4号告警：“ Local KSWX/DSWX Clock Fibre Failure”此告警表明连到lclKSWX的CBUS光纤出现问题或DSWX板的硬件问题。PBUS即Processor Bus ，它是MCAP总线在软件上的一种表示，它负责GPROC与其他全尺寸板（XCDR、GCLK、KSW、DRI）之间的通信。 254号告警：PBUS: Device Failure 此告警表明active PBUS fail BSS告警 BSS5 号告警：“No MSC Acknowledgement for Circuit Block” 从MSC侧得不到电路BLOCK的确认应答 BSS6 号告警：“No MSC Acknowledgement for Circuit Unblock”从MSC侧得不到电路UNBLOCK的确认应答 BSS7 号告警：“No MSC Acknowledgement for Reset Circuit”从MSC侧得不到RESET电路的确认应答 BSS8 号告警：“Unequipped Circuit at the MSC MSC”增加该CIC或BSC删除该CIC BSS12 号告警：“Unequipped Circuit at the BSS BSC”增加该CIC或MSC删除该CIC BSS39 号告警：“Circuit Fault Detected on Radio Channel” RCI的TRAU同步丢失 BSS43 号告警：“Circuit Fault Detected on PCM Circuit” MSC与BSC侧的告警 BSS47 号告警“Circuit Fault Detected on PATH Channel” PCI的TRAU同步丢失第三章 故障处理分析 在日常的维护中，会遇到各种各样的故障，为了对现场处理故障有更多的了解，我们选择一些平时处理故障的的案例，分析一些故障产生的原因，并对一些故障的分析思路、最总解决手段进行分析说明。一、常见故障分析处理 GPROC的故障处理 根据日常的维护发现，GPROC出现的告警最多是“35 LAN Connection Failure”GPROC是BSC机柜中数字处理板，它支持与MSC的信令链路（MTL）、与BTS的信令链路（RSL）、CBC接口的CBL链路以及与RXCDR接口的XBL链路，支持以上这些链路的协议，支持第三层呼叫处理功能，以及BSC的许多如故障管理、开关控制等的控制功能。 GPROC可被定义成BSP、CSFP和普通的GPROC，当主用的GPROC板也就是BSP，出现问题时，整个BSC的工作就受到严重影响，将主用GPROC reset后，就有可能使整个BSC都reset，而35告警说明该GPROC不工作在整个BSC的LAN上了。该故障的可能原因是：GPROC板通过软件操作或硬件操作被Reset；GPROC板的故障；LANX硬件的故障或光纤物理损坏。 如果是BSS上的某个GPROC出现35号告警，应该可以判断是该GPROC的故障，建议更换。 GCLK的故障处理 GCLK产生时钟，向上一级的时钟锁相，GCLK最多的告警是Phase Lock Lost。 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退服事件，因此现在开始，需要对GCLK Phase Lock Lost或GCLK Phase Lock Failure的BSC/XCDR重点监控，发现GCLK Phase Lock Failed的，应该及时派发工单给杭分处理。 KSW的故障处理KSW Kiloport SWitch board.执行TDM HIGHWAY 上1024 个64Kb/s 时隙的交换。也能进行32Kb/s 或16Kb/s 的交换，RXCDR 站中完成静态交换功能（钉连），BSC 站中完成16Kb/s 动态交换功能。KSW出现最多的告警是Clock A / B Signal Loss该故障的可能原因：GCLK/KSWXA/B 可能损坏；接受电路引起KSW FAIL；MCAP或则TDM处理总线接口。当KSW出现这些告警时，我们要收集近几天的eventlog数据来发现问题，因为该告警的出现也许不仅仅是KSW板的问题，根据日常出现的故障发现，如果同时出现时钟失锁，应该首先定位在GCLK上，如果时钟没有失锁，而出现了TDM的闪断，这时候我们应该关注半尺寸板KSWX，所以在这些告警出现时，要综合的去考虑分析，定位出故障。 KSWX/DSWX板的故障：当BSC超过一个CAGE时就需要KSWX板来扩展KSW板的1024个Ts到另外的CAGE ，KSWX板它支持TDM highway的扩展和扩容，接受扩展时钟。KSWX Error时，有可能是KSWX板子的硬件问题，也有可能是连接KSWX板的光纤故障，也有可能是与它通信的另一CAGE的KSWX板有问题。所以当我们发现有KSWX的Alarm时，应该先确认故障的原因。当KSW OOS时，KSWX的故障也将不能被监控。 KSWX的问题一样会导致BSC自动reset，因为它负责了TDM highway的扩展和扩容，当它出现问题时，扩展的CAGE有可能就是失去时钟源，或者是没有了时隙分配，当然就不能正常工作了，所以系统为了尽可能恢复工作，会自动进行reset。如 24 KSWX/DSWX in Slot 9 Detected Expanded ；25 KSWX/DSWX in Slot 21 Detected Expanded；26 KSWX/DSWX in Slot 22 Detected Expanded KSW Matrix Failure，出现这些告警，首先考虑CAGE 0 上的CLKX与相对应的CAGE的KSWX/DSWX板的光纤、光纤连接及半尺寸的硬件板，通过日常的故障处理，这些告警基本都是半尺寸的问题引起，而这些硬件板的故障率也较大。 LANX的故障处理LANX板是每个BSU/RXU CAGE 里所必须要有的板子，它由两条串行总线连接与GPROC板之间的通信，以及不同CAGE之间的通信。当LANX出现问题变为D-U时，GPROC之间的通信就不能进行，整个BSC的就不能正常工作，在这种情况下，BSC有可能会试图修复故障，重新建立LAN，它就会自动reset。如果确实为板子硬件问题，当然reset也好不了，这时候我们就必须更换LANX才能解决问题了。一般每个CAGE配两块LANX，为一主一备，这样工作就比较保险，不至于一个LANX一坏就整个BSC OOS。如：LAN Failure告警。 该故障的可能原因：某GPROC的故障也会引起LAN OOSLAN或LANX硬件板的故障LANX的光纤故障在某时段LAN的信息超过负荷 MSI的故障处理MSI出现的最多告警就是MSI-GDP的DSP Channel (029) Audit Failure，GDP是完成话音的压缩编码和速率适配，支持增强型语音编码和话音控制，虽然该告警不会导致BSS系统Reset，但是出现DSP Channel Audit Failure 会引起单通，在日常的监控中，如发现该故障建议更换硬件板 MTL的故障处理MTL链路是MSC与BSC的信令链路，其在整个系统中起着MSC与MS、BSS连接的作用。MTL直接与BSC与MSC相连，或者是经过Remote XCDR与MSC相连。它使用C7协议，MTL提供了MSC与BSC、MSC与MS之间的控制信息。MTL是MTP的Layer 2链路，当MTL OOS 时，Local MTP Layer 2与Remote MTP Layer 2之间的通信也就Fail了。该故障的可能原因： 连接MTL的MSI板FailMSC的处理器ailBSC端GPROC的FailMSC 传来的MTP 第二层LSSU 信息出现错误。在出现告警时首先要判断是传输、MSI的问题还是MSC的问题。disp_eq 0 MTL * * 查看 MTL所在的MMS，用state 0 mms * *查看MMS的状态，如果MMS出现过闪断应该是传输问题引起，如果没有出现闪断，应该是MSC传来的MTP第二层LSSU信息出现错误，在日常的监控中大部分是MSC传来的MTP第二层LSSU信息出现错误引起的。 BSP的故障处理 BSP是BSC/RXCDR的处理器，都是配置一主一备，如果BSP 出现reset，整个网元也就reset了，因此在日常维护中对该处理器的监控及处理是非常重要的。根据日常出现过的故障发现，有时候BSP硬件故障会突然导致BSS复位，BSP的故障发生率是很低，如：RXCDR自动重启，CNRC的分析说明：故障分析：经过分析，发现在故障发生时，主用011bh报告了下列fatal 和 nonfatal SWFM process_user_interrupts，这说明RXCDR的重启是由主用BSP的硬件故障引起的。SWFM Log Entry 2 182 FATAL SWFM ERROR: SOFT RESET Routine: process_user_interrupts 182 Area: 0x00000001 Error: 0x00000000 PC: 0xd00261ae PID: 0x00 (Null) 182 BSS Release: 1.7.6.f0.36 Obj Version: 1.7.6.0.7 Exec Version: 1.7.6.17.1 182 24-Apr-2006 05:01:50.865 Subsystem: 0x01 CPU: 0x011b Board: GPROC3 RAM 182 T7130 reset for recovery timeout. Recovery Type:29SWFM Log Entry 121 179 Nonfatal SWFM Error Routine: process_user_interrupts 179 Area: 0x00000001 Error: 0x0000001d PC: 0xd002656e PID: 0x00 (Null) 179 BSS Release: 1.7.6.f0.36 Obj Version: 1.7.6.0.7 Exec Version: 1.7.6.17.1 179 24-Apr-2006 05:01:45.865 Subsystem: 0x01 CPU: 0x011b Board: GPROC3 RAM179 Channel: 5 179 HDLC: T7130 ALARM 29 179 Channel State: 8 179 Read Address: 15 179 Write Address: 9ea2a 179 Internal Stack: 179 422d 1927 1ff9 3930 27a3 179 通过进一步对swfm log的分析，我们发现在RXCDR重启之前系统的主用BSP有如下swfm：121 179 24-Apr-2006 05:01:45.865 d002656e 00 Null process_user_interrupts122 17a 24-Apr-2006 05:01:45.870 c0000de2 13 LAP DLSP dl_data_req123 17b 24-Apr-2006 05:01:45.875 c0001496 13 LAP DLSP dl_flowcontrol_req124 17c 24-Apr-2006 05:01:46.080 c0001496 13 LAP DLSP dl_flowcontrol_req125 17d 24-Apr-2006 05:01:46.125 c00004ae 45 Validate perform_hdlc_config.c126 17e 24-Apr-2006 05:01:46.290 c0001496 13 LAP DLSP dl_flowcontrol_req 127 17f 24-Apr-2006 05:01:46.335 c00004ae 45 Validate perform_hdlc_config.c 0 180 24-Apr-2006 05:01:46.335 c0044a64 42 CA gproc_hdlc_recover.c 1 181 24-Apr-2006 05:01:46.500 c0001496 13 LAP DLSP dl_flowcontrol_reqSWFM Log Entry 12717f Nonfatal SWFM Error Routine: perform_hdlc_config.c17f Area: 0x00000309 Error: 0x00000003 PC: 0xc00004ae PID: 0x45 (Validate)17f BSS Release: 1.7.6.f0.36 Obj Version: 1.7.6.0.b Exec Version: 1.7.6.17.117f 24-Apr-2006 05:01:46.335 Subsystem: 0x01 CPU: 0x011b Board: GPROC3 RAM17f Return code from hdlc_init = 253 #define T7130_CODE_LOAD_FAIL 253从以上log文件，我们看到在T7130重启恢复的过程中，SWFM指明failed to code load T7130 chip，所以GPROC板最终因T7130恢复失败而重启。因此我们可以得出这是T7130硬件问题导致的主用BSP重启，从而造成系统重启。 数据总线的故障处理BSC在软件上存在着PBUS、SBUS、TBUS和CBUS四种总线，这四种总线我们可以在BSC的MMIRAM状态下通过state命令来查看它们的工作状态。PBUS即Processor Bus ，它是MCAP总线在软件上的一种表示，它负责GPROC与其他全尺寸板（XCDR、GCLK、KSW、DRI）之间的通信。 当PBUS Device Failure时，BSC就会Reboot，在这个初始化过程中，BSC OOS。PBUS Device Failure的原因可能是：LANX 板Faulty；可能是FTP（故障传输部分）和FCP（故障收集部分）之间的错误引起的。SBUS即Serial Bus ,它上面的通信由GPROC控制，主要负责GPROC与半尺寸板（如LANX、KSWX、GLKX、DRIX）之间的通信。每个CAGE也是一主一备的SBUS，但它们被分配不同的任务，Standby 不享有Active SBUS的功能。 当SBUS fail后，BSC就会自动reset。reset结束后，如果SBUS仍然是OOS，那么就必须去检查具体原因了。SBUS有故障时，你必须考虑所有被主GPROC控制的SBUS上的通信。SBUS Failure的原因可能如下：LANX板子没有插好，与背板的连接不正确。LANX板子Fail.GPROC板Fail，使SBUS上的通信不正常。BTC板不能给背板供电。半尺寸板在背板得不到电源。当我们发现SBUS OOS时，可以从以上几方面来考虑检查故障，不让BSC不停地REBOOT。TBUS即TDM BUS 。它由KSW控制，有1024个Ts，分配给GPROC、MSI、XCDR、KSW，可扩展扩容。 在TDM高速总线故障的情况下，系统的TBUS就会DU，TBUS DU后，就会要求TDM highway做SWAP，这个SWAP将会使CAGE里的所有的TBUS一样做SWAP，如果此CAGE不能SWAP TBUS，那么此CAGE 也就变为Disable,这样就会引起BSC的reset。如在现网中出现的这些告警 2 Remote KSWX TDM Error； 4 Remote KSW/DSWX TDM Error；0 Remote KSW TDM loopback Test Failure，基本是KSWX/DSWX的故障引起。 引起TBUS Fail的原因可能如下：连接Local与Remote的KSWX的光纤有问题，或者断了KSWX板子Failure 。CBUS即Clock Distribution Bus，通过此总线将GXLK时钟传到CAGE背板。给GPROC、KSW、MSI、XCDR等提供时钟，这些BUS都是每个CAGE一主一备的。当主用的（BU）CBUS有故障时，系统会自动SWAP备用的CBUS，当然备用的CBUS必须是可用的。 当备用的CBUS不能做SWAP 时，就会引起BSC的reset，reset后还不好的话，CAGE就会OOS，那就必须查找故障的原因所在了，在日常的监控发现CBUS出现 2. CBUS: Master CBUS Signal Provided By Slave GCLK；4 CBUS: Local KSWX/DSWX Clock Fibre Failure告警，出现该类告警需要逐步的去检查定位，检查CAGE 0的GLKX板、光纤、与扩展CAGE的KSWX/DSWX的光纤连接、硬件板。 引起CBUS Disable的原因可能如下：GCLK板硬件问题连接时钟的光纤有问题扩展时钟的KSWX板有问题背板连接有误 单通故障的处理 在日常的监控中出现的单通告警是，BSS47/ Circuit_Fault_Detected_On_PATH_Channel，39/ Circuit_Fault_Detected _on_Radio_Channel。这两个告警成对出现分别表示了RCI和PCI TRAU帧同步丢失，可能会导致单通。BSS/43/ Circuit Fault Detected on PCM Circuit表示了交换和BSC侧的CIC电路告警，5号告警和8号告警、12号告警表明了是交换侧的CIC被BLOCK和交换侧没有配该电路。 如果BSC出现大量的43/ Circuit Fault Detected on PCM Circuit告警，该告警的出现有可能导致单通，首先我们确定这些CIC 告警集中出现在那些CIC电路，这些CIC对应的MMS、MSI端口，应该建议更换BSC对应的MSI板，如果告警还频繁出现，应该进一步去调查BSC对应的RXCDR上出现告警CIC的传输范围，如果发现BSC出现大量的39/47告警，首先检查触发该告警的参数，cic_error_gen_thresh；rci_error_gen_thresh，该两参数的默认值为6，如果这两个参数的值是6，就应该去检查对应的MMS、MSI、和BTS的2M，逐步去检查定位。 二、日常维护的注意事项 鉴于BSC Reset的影响严重，我们应该尽量防止它自动Reset，尽可能避免人为的Reset，为此，在日常维护中，要注意操作规范。更换MSI板时，应该先用state命令查看MSI板的工作状态，如果是unlock状态，则应该先将MSI lock，替换后再Unlock，不要在unlock状态下直接把板子拔出来。安装扳子要到位，要确保板子与背板能连接正确，这样板子才能正常工作，也不会影响与其他板子之间的通信。要注意光纤的清洁，特别是与半尺寸板连接的光纤，如果光纤不干净也会导致板子的Disable，影响站的正常工作。当然机柜也应该定时清洗，要严格按照规范来清洗。要注意日常的告警信息，经常用disp_act_alarm命令查看系统，发现有告警应该及时进行处理。要及时收集故障记录数据，因为系统的存储有一定的限度，到一定的时间或者一定的数量它就会被覆盖掉。对一些实时监控的告警不要遗漏，同时每天要收集SITE 0级别的Event 数据来查看一些告警信息，每周收集ECT数据，观察告警趋势并分析，在每月的月报里也要分析该月的告警趋势。三、典型问题汇总在日常的维护中，对于出现的告警我们都进行分析并已工单形式派发给客户，关于日常的工单我们也进行了汇总并不断更新，同时也可以作为日后的故障处理及分析参考。