华为RNC与爱立信MGW光纤倒换失败案例研究.docVIP

华为RNC与爱立信MGW光纤倒换失败案例 引言 深圳前期进行了2、3G共核心网改造，因此跨厂家设备互连的情况大大增加。目前深圳的共核心网跨厂家设备互连情况包括中兴RNC及华为RNC与爱立信MGW的互连。 在共核心网联调过程中发现了华为RNC与爱立信MGW光纤倒换的失败案例。通过多组设备的测试发现此失败案例是一个共性的问题，且此问题的原因与华为RNC和爱立信MGW的光纤倒换机制的设计特性有关。 1 物理连接及数据配置 案例涉及的RNC为深圳RNC25，硬件版本为RNC820，软件版本为V004R000C01SPC100；MGW为深圳GM28，硬件版本为GMPV3_MGW_CNP_R4.2.4.0，软件版本为 CXP9012221/2_R2G02。 图1 爱立信GM28与华为RNC25间物理连接 爱立信GM28的保护组配置如图2所示： 图2 爱立信GM28保护组配置 华为RNC25的配置脚本如下，其中MODE2为1+1单端备份SET MSP: SRN=0, SN=24, PN=0, MODE=MODE2; SET MSP: SRN=0, SN=24, PN=1, MODE=MODE2; 2 故障现象 系统初始时RNC侧24槽UOI板口25槽UOI板口24槽UOI板口25槽UOI板口华为RNC25拔出24槽UOI板口的收光纤时，RNC侧出现“AAL2 PATH被对端闭塞告警”，此时24槽UOI板口状态由“主用正常”变为“故障”，25槽UOI板口由“备用正常”变为“主用正常”。爱立信GM28一侧的MSPG状态没有变化，选收端口仍为2-21-1，但出现MS Remote Defect Indication告警（Os155SpiTtp=2211）和VC4 Remote Defect Indication告警（Os155SpiTtp=2211,Vc4Ttp=1），并且Aal2PathVccTp、Aal5TpVccTp状态由ENABLED变为DISABLED，即该对主备物理链路上配置的所有AAL2和AAL5链路中断。 类似上述操作，单独拔出RNC的2槽UOI板口的收光纤时也会出现同类的告警，即另一对主备物理链路上配置的所有AAL2和AAL5链路中断。 当RNC侧24槽UOI板口及2槽UOI板口的收光纤都拔出时，所有AAL2和AAL5链路中断。此时，该RNC信令、话务全阻。爱立信MGW光口直连保护机制为单端非恢复式。 非恢复式：一旦倒换发生，即使故障解除也不倒回，除非条件再次触发。 单端倒换：当主信道故障时，切换选收备用信道，即仅收端切换。 爱立信MGW采用双发单收机制，双发即发端在主备两个信道上发同样的信息，单收即通过对信号质量的检测和APS(Automatic Protection Switch)倒换协议，对两路信号进行选择性的接收，收端在正常情况下收主信道上的业务。 倒换触发条件：LOS；LOF；MS-AIS；B2-EXC (BER≥10-3)；B2-DEG(10-5~10-9)。 倒换时间：保护倒换的时间控制在50ms以内。 图3爱立信GM13与华为RNC26间物理连接 在RNC侧分别设置光口保护方式为恢复式与非恢复式分别进行测试。 恢复模式：拔掉RNC侧收端后，远端发起闭塞，RNC侧端口发生倒换，业务中断；恢复后，RNC侧端口再次进行倒换，业务恢复正常。在此过程中爱立信MGW的光口均未发生倒换。???? 非恢复模式：拔掉RNC侧收端后，远端发起闭塞，RNC侧端口发生倒换，业务中断；恢复后，RNC侧端口不再倒换，业务恢复正常。在此过程中爱立信MGW的光口均未发生倒换。???? 由此证明RNC侧恢复模式不是造成业务中断的原因。同时，由于RNC与MGW间采用ODF直连，因此也排除了传输设备对倒换过程的影响。 通过上述测试，确定故障原因为爱立信MGW与华为RNC倒换机制配合问题。结合倒换过程中产生的告警进行理论分析，华为RNC当收光口发生中断时，会在故障端口上发送一个HP-RDI告警给MGW（爱立信MGW侧对应告警为VC4-RDI），同时在RNC侧触发MSP倒换，并给MGW发送一个MS-RDI告警。爱立信MGW在收到HP-RDI、MS-RDI这两个告警后，会判定为底层物理链路状态异常，从而主动把AAL2 PATH置为不可用。对比华为RNC与华为MGW（UMG8900）对接的情况，当RNC侧发生收光口中断时，华为MGW会忽略收到的HP-RDI、MS-RDI这两个告警，所以不会影响AAL2 PATH的状态。 为解决此问题，华为已计划在RNC的4.1C02SPC600版本4.1C02SPC600补丁解决此问题。） 目前，为避免此类故障引起RNC所带业务全阻，建议在华为RNC与爱立信MGW对接时采用2对光纤电路互连，