关于华为软交换端局局间呼叫掉话故障的排查报告
- 格式：doc
- 大小：53.50 KB
- 文档页数：6
关于华为软交换端局局间呼叫掉话故障的排查报告
作者：汕尾公司余跃虹
一、隐患基本描述
2010年5月1日，接到用户投拆，汕尾SWGM02局内呼叫正常，但局间呼叫接通后出现掉话现象，概率为10%~20%左右。
检查交换机设备正常，无异常告警；现网SWGM02 A口为TDM承载，局间为VOIP承载，而局内呼叫正常，可以排除A口侧设备故障；局间呼叫接通后出现掉话现象，此时通话由于需要完成TDM到IP的语音编解码转换，需要占用到语音处理单元MTCB板的TC资源，怀疑与TC资源相关的设备单板有隐性故障。
二、隐患排查分析
1、首先介绍华为MGW的设备业务功能。
华为UMG8900设备提供与业务呼叫无关的业务承载功能，在MGC 的控制下实现业务承载转换和业务流格式处理。
对于UMG8900设备来说，不同业务的接续与交互过程，体现为IP、TDM、ATM和语音编解码等承载和业务资源的调用。
针对不同业务，MGW会分配不同的资源，通常一个呼叫分配的资源包含TDM资源、TC资源、EC资源,CC资源。
针对IP呼叫，还需要分配IP端点、UDP端口等。
要定位业务类的故障，必须知道该业务呼叫占用的系统资源和位置。
2、华为UMG8900设备与呼叫业务相关的TC资源、EC资源、CC 资源介绍。
UMG8900中，TC和EC是两种扣板，换句话说是两种资源。
TC扣在VPU的0号槽位和1号槽位，EC扣在VPU的2号槽位或扣在ECU 上。
TC可以提供编解码转换和放音收号功能。
当用于通信的两个终端之间没有可以共同支持的语音编解码格式时，需要通过TC资源来实现语音编解码的转换。
例如当发生类似于TDM-IP的呼叫需要进行编解码转换，此时需要添加TC。
EC：提供回波抵消功能。
在语音呼叫时有可能会添加EC。
EC可以插在ECU单板上，也可以插在VPB、VPD、TCB和TCD的2号槽位上。
CC：混音资源，就是常说的多方会议的MPTY资源。
它是由TC扣板提供，一块TC扣板插在0或1扣板槽位时可以提供1024个CC资源，插在2号扣板槽位时可以提供2048个CC资源。
3、本故障原因分析与处理
对于多框承载业务MGW中，一次TDM到IP承载也就是案例中的局间呼叫，需要占用到TC资源，其业务流为：
ME32（TDM业务接口板）－TCLU（ TDM汇聚级连单元，为ME32同框）—MTNU（ TDM核心交换单元）—TCLU（ TDM汇聚级连单元，为MVPU同框）－MVPU（语音处理单元）－MNET（分组业务交换单元）－MHRU（高速路由转发板）－MG1O（后插IP分组接从上图可以看出，对局间呼叫，MGW将会涉及到上图中各种单元和资源的调用。
其转发流程为：
（1）、 UMG8900 设备通过后插E32 等TDM 接口单板接入TDM
承载业务流，通过内部TDM（TCLU/MTNU）交换到指定的VPU 单板上。
（2）、 VPU 单板接收到转发过来的TDM 承载业务流后，进行
编解码格式转换，转化为业务互通所需要的编解码格式，并封装为内
部通信数据包，然后通过内部分组业务总线转发给指定的HRB 单板。
（3）、 HRB 单板接收到转发过来的分组业务数据包后，去掉
内部通信的数据包头，然后对数据包进行分片、并完成RTP/UDP/IP 等
适配协议的处理，通过后插IP 分组接口单板转发出去。
再来看一下此次案例，局内呼叫正常，局间呼叫在接通后才出现
掉话，而根据以上所述，局间通话涉及TDM与IP承载的语音编解码
转换，怀颖是在VPU单板上的编解码转换不成功，也就是说TC资源
占用失败。
第一步是怀疑TC资源或对应语音处理单元MTCB（VPU）板有异常。
但是通过查询现网TC资源并没有异常状态。
%%DSP MEDIARES: QM=BTBN, BT=VPU;%%
RETCODE = 0 执行成功
资源查询信息
------------
框号槽位号板类型板组号资源块号资源块类型资源类型资源数空闲呼叫占用其他占用故障
1 0 VPU 0
2 VDB TC 512 467 45
0 0
1 1 VPU 1 0 VDB TC 51
2 462 50
0 0
1 2 VPU 8 0 VDB TC 512 447 65
0 0
1 2 VPU 8 1 VDB TC 512 453 59
0 0
0 0
2 0 VPU 2 0 VDB TC 512 462 50 0 0
2 1 VPU
3 0 VDB TC 512 460 52 0 0
2 2 VPU 9 0 VDB TC 512 455 57 0 0
2 2 VPU 9 1 VDB TC 512 44
3 69 0 0
2 2 VPU 9 2 VDB TC 512 45
3 59 0 0
2 3 VPU 10 0 VDB TC 512 436 76 0 0
2 3 VPU 10 1 VDB TC 512 469 43 0 0
2 3 VPU 10 2 VDB TC 512 468 44 0 0
3 0 VPU
4 0 VDB TC 384 34
5 39 0 0
3 0 VPU
4 0 VDB CC 256 244 12 0 0
3 1 VPU 5 2 VDB TC 448 39
4 54 0 0
3 1 VPU 5 2 VDB CC 256 252
4 0 0
3 2 VPU 6 0 VDB TC 512 461 51 0 0
3 2 VPU 6 1 VDB TC 512 447 65 0 0
3 2 VPU 6 2 VDB TC 512 459 53 0 0
3 3 VPU 7 0 VDB TC 512 461 51 0 0
3 3 VPU 7 1 VDB TC 512 45
4 58 0 0
3 3 VPU 7 2 VDB TC 512 461 51 0 0
4 0 VPU 11 0 VDB TC 512 446 66 0 0
4 0 VPU 11 1 VDB TC 512 46
5 47 0 0
4 0 VPU 11 2 VDB TC 512 454 58 0 0
0 0
4 1 VPU 12 1 VDB TC 512 459 53
0 0
4 1 VPU 12 2 VDB TC 512 458 54
0 0
(结果个数 = 29)
资源统计信息
------------
资源类型资源数空闲呼叫占用其他占用故障
TC 13632 12159 1473 0 0
CC 512 496 16 0 0
--- END
接下来对MTCB板逐板检查，最后发现，将第4框的两个MTCB板
闭塞掉后，故障恢复，局间呼叫正常，那是不是就可以确定这两块MTCB板有故障呢？答案是否定的，当时更换这两块MTCB板，解闭后
再进行拔测，还是出现局间呼叫掉话现象。
第二步怀疑第4框的TCLU板有故障。
通过查看MGW配置，第4
框中并没有配置ME32板或MS2L板，而由现网可以查到，设备上配置
的TC资源管理策略为所有框内轮选资源。
%%LST RESPLCY:;%%
RETCODE = 0 执行成功
资源管理策略配置表
------------------
TC/EC资源本框优选比例 = 0%（当本框优选比例设定为0时，表示当前资源管理策略为在所有框内轮
选资源。
）
IP资源本框优选分配比例 = 0%
公共编解码集优选策略 = 优选G711,再轮选其余编解码集
--- END
这就说明，从其他框ME32上来的业务呼叫，系统有可能会轮选
到4框中的两个MTCB板中的TC资源，此时，从A口上来的业务最终需要流转到4框的TCLU板，才能够占用到该框MTCB板的TC资源。
而当4框的TCLU板出现故障时，业务流就访问不到MTCB板进行编解码转换而导致通话失败，所以该框TCLU板也是可能故障点之一。
由于TCLU板是主备用，当对TCLU板进行主备倒换后，拔测恢复正常，由此，可以确定此次故障的元凶是在4框的主用TCLU板，进行硬件更换后，倒回主用侧测试通过。
三、隐患解决措施
华为UMG8900设备提供与业务呼叫无关的业务承载功能，在MGC 的控制下实现业务承载转换和业务流格式处理。
由于现网华为UMG8900设备的主动告警监测功能不完善，通常故障点并没有产生相应的告警，要定位业务类的故障，必须知道该业务呼叫占用的系统资源和位置，通过对UMG8900业务流的学习分析，在解决故障时需要进行有目的的排查，从最有可能发生故障的点开始，通过业务拔测和设备状态的观察找出故障原因。
四、本地解决情况
对于此次局间呼叫掉话现象，通过对华为MGW处理TDM-IP的业务流的分析，逐步排查，最后确定了故障单板并进行了更换，这次在处理的过程中，维护人员也得到了很好的学习机会，对华为UMG8900设备提供与业务呼叫无关的业务承载功能进行了一次很好的梳理和总结，更加深入的理解了华为UMG8900实现业务承载转换和业务流格式处理的方式。
