论文部分内容阅读
【摘要】本文主要针对当前软交换网络下出现单通现象的排查方式进行了一个简单的概述，主要是通过追踪单通通话，找出设备占用的共性，我们通过对MSC-S、MGW、BSC进行一系列的实时追踪，发现单通通话都集中在爱立信MGW的某一块MSB板上，而后我们对MGW进行一系列的深度检查，包括ET板、MSB板、SCB＼SXB板＼ISL连线进行程序检查，发现某一块MSB板出现问题，而这一块MSB板出现问题并未通过告警来呈现，因此，我们最后给出了爱立信MGW隐性故障导致单通后续的解决方案。
【关键词】单通MGW定位MSB
一、概述
近日陆续接到投诉反映在南海桂城通话有单通的情况出现。单通跟掉话、电话无法呼入呼出等又有所不同，单通的发生对网络指标如接通率无任何影响，从信令上看无任何异常，并且当前复杂的网络架构又给本次故障定位带来了一定的干扰。当出现单通投诉时，我们只能追踪单通通话，找出共性，首先我们要定位用户所在的小区，看是否集中在小区，排除无线方面的原因。其次需定位是否集中在核心网的某个交换机中。
二、处理方法
2.1MSC-S、MGW上监听用户A口设备
由于有部份投诉号码位于FSM21B2（双连至FSM06及FSM21）下，于是在FSM21B2下挂微蜂窝拨测，经过统计发现38次拨测中有5次出现单通复现，分别对这5次通话进行跟踪，统计其所占用的MSC-S的A口信息、MGW上的MSB板等信息。
MGW上：CALL PATH TRACEING EMAS->Troubleshooting->Call path trace弹出的对话框中输入MSC上CTRAI得到的Context ID（需留意后面选择的是DEC），得出本次通话所占用的MSB板。
经过对相应的单通通话进行监听，对其所占用的TRA、ABIS口、小区、A口、MGW、MSB板进行统计，发现只有一个共性，即所有的单通通话都占用了FSM21中的1-17这块MSB单板。
2.2可疑故障网元FSM21深度检查
ET板或MSB板的故障引起。对于这种类型的单通故障，故障诊断方法是在MSC-S和MGW上做call path trace，如果单通总出现在某块ET板或MSB板上，可把故障点定位到该ET板或MSB板。如果单通故障是由MSB板故障引起，通常会伴随着NB init fault，可lhsh到定位的MSB板用指令gra_info_stat查看。如果出现数量较多的NBinitfault，证明该MSB板有故障。如果单通故障出现在某块ET板，可通过MSP1+1转换把话务转换到备用板。如果通过call path trace显示单通分散在多块ET板或MSB板，则有可能是switch plane出现故障。如果通过call path trace发现单通集中在某个机框的多块ET板或多块 MSB板，则可能是由该框的SCB板或与该SCB板连接的主机框SXB板故障引起的，SCB/SXB板故障有可能伴随大量的gcp error（error code 500或510），这些gcp error在各块负责mesc功能的GPB板均有出现，可通过指令mesc_counters_gcp查看。
三、故障原因分析
根据“先抢通后抢修”的故障处理原则，我们对FSM21进行了冷启操作，但从拨测结果及信令数据上来看，并不是整个网元出现问题。
根据FSM21当时的日志，发现在单通故障期间FSM21 MSB板3307出现大量的“SAI Egress Discard. Cells”事件。对比之前的拨测结果发现每次单通通话都占用到了FSM21的2-7这块MSB板。Pool内其他MGW无类似故障，而此次单通故障的很大程度是MSB4 3307出现问题是造成。
四、改善计划
对于MSB板故障，部分监控方法与MRW R5相比有所变化，而为了更好地解决MGW的单通问题，全网对MGW进行了升级，在R6.2.2版本中，新增了UPS功能，可以对相应的单板所占用的通话时长进行监控，将疑似单通的板通过告警的形式呈现出来。
UPS的将两种类型的板-ETIPG/MFG、MSB按物理上的框定义成相应的资源组，每个资源组里各个板逻辑上赋予了三种颜色：黑灰白，通过对各个板占用时常的监测，各个板的颜色会有一定的变化，黑色情况时发生单通的概率较高，各个板状态正常时为白色，状态异常时会由白变成灰，灰变成黑，三种颜色的变化只能是以下四种情况：
可以通过以下三条CLI指令查看相应的资源组及各个板的状态：
（1）ups_get_peergroups
查看各种类型单板分组情况
（2）ups_get_safs查看各板当前的颜色（黑、白灰）
（3）ups_get_saf_details查看各板状态的统计值
由于UPS功能正在调测阶段，有时受到骚扰电话的影响，单板的状态也可能会发生变化，导致有些告警信息不正确，后续将进行不断的完善。
【关键词】单通MGW定位MSB
一、概述
近日陆续接到投诉反映在南海桂城通话有单通的情况出现。单通跟掉话、电话无法呼入呼出等又有所不同，单通的发生对网络指标如接通率无任何影响，从信令上看无任何异常，并且当前复杂的网络架构又给本次故障定位带来了一定的干扰。当出现单通投诉时，我们只能追踪单通通话，找出共性，首先我们要定位用户所在的小区，看是否集中在小区，排除无线方面的原因。其次需定位是否集中在核心网的某个交换机中。
二、处理方法
2.1MSC-S、MGW上监听用户A口设备
由于有部份投诉号码位于FSM21B2（双连至FSM06及FSM21）下，于是在FSM21B2下挂微蜂窝拨测，经过统计发现38次拨测中有5次出现单通复现，分别对这5次通话进行跟踪，统计其所占用的MSC-S的A口信息、MGW上的MSB板等信息。
MGW上：CALL PATH TRACEING EMAS->Troubleshooting->Call path trace弹出的对话框中输入MSC上CTRAI得到的Context ID（需留意后面选择的是DEC），得出本次通话所占用的MSB板。
经过对相应的单通通话进行监听，对其所占用的TRA、ABIS口、小区、A口、MGW、MSB板进行统计，发现只有一个共性，即所有的单通通话都占用了FSM21中的1-17这块MSB单板。
2.2可疑故障网元FSM21深度检查
ET板或MSB板的故障引起。对于这种类型的单通故障，故障诊断方法是在MSC-S和MGW上做call path trace，如果单通总出现在某块ET板或MSB板上，可把故障点定位到该ET板或MSB板。如果单通故障是由MSB板故障引起，通常会伴随着NB init fault，可lhsh到定位的MSB板用指令gra_info_stat查看。如果出现数量较多的NBinitfault，证明该MSB板有故障。如果单通故障出现在某块ET板，可通过MSP1+1转换把话务转换到备用板。如果通过call path trace显示单通分散在多块ET板或MSB板，则有可能是switch plane出现故障。如果通过call path trace发现单通集中在某个机框的多块ET板或多块 MSB板，则可能是由该框的SCB板或与该SCB板连接的主机框SXB板故障引起的，SCB/SXB板故障有可能伴随大量的gcp error（error code 500或510），这些gcp error在各块负责mesc功能的GPB板均有出现，可通过指令mesc_counters_gcp查看。
三、故障原因分析
根据“先抢通后抢修”的故障处理原则，我们对FSM21进行了冷启操作，但从拨测结果及信令数据上来看，并不是整个网元出现问题。
根据FSM21当时的日志，发现在单通故障期间FSM21 MSB板3307出现大量的“SAI Egress Discard. Cells”事件。对比之前的拨测结果发现每次单通通话都占用到了FSM21的2-7这块MSB板。Pool内其他MGW无类似故障，而此次单通故障的很大程度是MSB4 3307出现问题是造成。
四、改善计划
对于MSB板故障，部分监控方法与MRW R5相比有所变化，而为了更好地解决MGW的单通问题，全网对MGW进行了升级，在R6.2.2版本中，新增了UPS功能，可以对相应的单板所占用的通话时长进行监控，将疑似单通的板通过告警的形式呈现出来。
UPS的将两种类型的板-ETIPG/MFG、MSB按物理上的框定义成相应的资源组，每个资源组里各个板逻辑上赋予了三种颜色：黑灰白，通过对各个板占用时常的监测，各个板的颜色会有一定的变化，黑色情况时发生单通的概率较高，各个板状态正常时为白色，状态异常时会由白变成灰，灰变成黑，三种颜色的变化只能是以下四种情况：
可以通过以下三条CLI指令查看相应的资源组及各个板的状态：
（1）ups_get_peergroups
查看各种类型单板分组情况
（2）ups_get_safs查看各板当前的颜色（黑、白灰）
（3）ups_get_saf_details查看各板状态的统计值
由于UPS功能正在调测阶段，有时受到骚扰电话的影响，单板的状态也可能会发生变化，导致有些告警信息不正确，后续将进行不断的完善。