BSC reset的可能原因

（1）BSC硬件故障引起BSC reset
《GPROC》
它是BSC机柜中数字处理板，它支持与MSC的信令链路（MTL）、与BTS的信令链路（RSL）、CBC接口的CBL链路以及与RXCDR接口的XBL链路，支持以上这些链路的协议，支持第三层呼叫处理功能，以及BSC的许多如故障管理、开关控制等的控制功能。

GPROC可被定义成BSP、CSFP和普通的GPROC以及Incell站里的BTP、DHP。

当主用的GPROC板也就是BSP，出现问题时，整个BSC的工作就受到严重影响，将主用GPROC reset 后，就有可能使整个BSC都reset。

这个现象的问题可能是因为以下原因：
①在拔出其中一块BSP时的方法不对，应先disable此GPROC。

②一个局部变量被全局变量所代替，使得CA挂起，产生SWFM错误，而使得BSC reset。

《LANX》
LANX板是每个BSU/RXU CAGE 里所必须要有的板子，它由两条串行总线连接与GPROC 板之间的通信，以及不同CAGE之间的通信。

当LANX出现问题变为D--U时，GPROC之间的通信就不能进行，整个BSC的就不能正常工作，在这种情况下，BSC有可能会试图修复故障，重新建立LAN，它就会自动reset。

如果确实为板子硬件问题，当然reset也好不了，这时候我们就必须更换LANX才能解决问题了。

一般每个CAGE配两块LANX，为一主一备，这样工作就比较保险，不至于一个LANX一坏就整个BSC OOS。

《KSWX》
当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。

（2）LINK的故障引起BSCreset
与BSC连的LINK有MTL、RSL、OML、XBL。

当MTL、RSL D-U时，也有可能导致BSC自动reset。

《MTL》
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 OOS的情况有好多：
①连接MTL的MSI板Fail；
②MSC的处理器Fail；
③BSC端GPROC的Fail；
④BSN和FSN被MSC打断；
⑤MTL的业务量过高；
⑥同步时钟丢失；
⑦A接口物理连接错误、硬件故障；
⑧BSS与MSC软件协议不一致或者它们的软件错误；
⑨MTL链路数量不够处理呼叫量；
以上等等都可以使MTL OOS，但也不是所有的OOS都会导致BSC reset，譬如因为GPROC 控制的MTL的负荷过大，使得MTL时好时坏，当一条MTL断了，造成其超负荷，就会使得MTL退出服务。

这时可检查此MTL的统计数据，或检查GPROC的CPU的使用率，通过扩容增加MTL的链路条数等办法来解决问题。

《RSL》
RSL是BSC与BTS之间的链路，BSC通过RSL来控制BTS，它使用的是LAPD协议，还提供MSC到MS的前向消息。

在BSC这端由GPROC来控制RSL链路，BTS端由MCU来控制。

RSL OOS的情况跟MTL链路差不多，主要也就分为：
①协议错误（链路超时、序列错误、帧拒绝、结构错误、坏帧等）；
②业务量过高；
③断链（物理链路断掉、MMS Fail、T43板等故障）。

当RSL OOS超过10S后，BTS就会OOS，BTS受RSL链路的影响特别大，BTS经常会因为RSL的OOS而必须reset。

BSC当RSL因为话务量过高OOS时，也一样会reset，BSC总会试图修复一些故障，许多暂时性的故障可以通过BSC的自动reset而解决，但一些硬件故障是不可能被修复的。

（3）总线的Fail引起BSC reset
BSC在软件上存在着PBUS、SBUS、TBUS和CBUS四种总线，这四种总线我们可以在BSC 的MMI—RAM状态下通过state命令来查看它们的工作状态。

《PBUS》
PBUS即Processor Bus ，它是MCAP总线在软件上的一种表示，它负责GPROC与其他全尺寸板（XCDR、GCLK、KSW、DRI）之间的通信。

当PBUS Device Failure时，BSC就会Reboot，在这个初始化过程中，BSC OOS。

PBUS Device Failure的原因可能是：
①LANX 板Faulty；
②可能是FTP（故障传输部分）和FCP（故障收集部分）之间的错误引起的。

《SBUS》
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》
TBUS即TDM BUS 。

它由KSW控制，有1024个Ts，分配给GPROC、MSI、XCDR、KSW，可扩展扩容。

在TDM高速总线故障的情况下，系统的TBUS就会D—U，TBUS D—U后，就会要求TDM highway做SWAP，这个SWAP将会使CAGE里的所有的TBUS一样做SWAP，如果此CAGE不能
SWAP TBUS，那么此CAGE 也就变为Disable,这样就会引起BSC的reset。

引起TBUS Fail的原因可能如下：
①连接Local与Remote的KSWX的光纤有问题，或者断了
②KSWX板子Failure 。

《CBUS》
CBUS即Clock Distribution Bus，通过此总线将GXLK时钟传到CAGE背板。

给GPROC、KSW、MSI、XCDR等提供时钟，这些BUS都是每个CAGE一主一备的。

当主用的（B—U）CBUS有故障时，系统会自动SWAP备用的CBUS，当然备用的CBUS 必须是可用的。

当备用的CBUS不用做SWAP 时，就会引起BSC的reset，reset后还不好的话，CAGE 就会OOS，那就必须查找故障的原因所在了
引起CBUS Disable的原因可能如下：
①GCLK板硬件问题
②连接时钟的光纤有问题
③扩展时钟的KSWX板有问题
④背板连接有误
（4）BSC软件故障引起BSC reset
所起软件故障，这是一个很大的范畴，也是一个很复杂又不易解决的问题，有许多软件的问题并不是我们用户所能够解决的，特别是版本原因，我们能做的是判断出故障所在，尽可能的防止人为出错。

《GPROC的内存问题》
我们知道，GPROC在BSC中处于相当重要的位置是因为它担任了控制处理功能，GPROC 的CUP也有一定的工作极限，当BSP的CPU使用率达到100%，出现BSP[239]告警，BSC就会自动reset。

导致此BSC reset的原因是因为BSC的SSM与BTS的CRM间通信量太大，使得产生的SM SWFMs过多所致。

Site的业务量太大，TCH拥塞所致。

通过调整cp_messages.c SWFMs 的量，可以解决此问题。

有时侯内存并没有问题而是当使用内存时GPROC被lock了。

建议在将nvram_access 寄存器改为写之前不可以中断，nvram_access寄存器改为读之后才可以中断，当然对某个具体的寄存器的改写并不是我们做的事情，。

另外有时当CM进程进入内存时，DRAM会出现奇偶错误，使得BSC reset。

这是当进程读内存时出现，此情况不多，但出现就意味着GPROC的内存损坏。

还有一些GPROC中EEPROM 出现错误的问题，也使的GPROC不能正常工作。

这时可有两种方法来处理
①将此损坏的GPROC（BSP）与其它的GPROC交换，即使此GPROC再次reset，也不会使BSC reset。

②换一块好的GPROC。

《改变database及其他》
有时Database做了改动后也需要BSC reset，才能正常工作，特别是一些影响站基本工作的参数，平时不要随意改动。

另外还有可能因为本身新版本软件的缺陷也会偶尔出现问题，需要使BSC reset，发现这种问题应该及时与开发部联系，会有PR来解决。