浅析传输误码引起接通率低问题.docx

浅析传输误码引起接通率低问题【摘要】有几条专线做主叫时经常拨打电话不成功拨打完成号码后电话经常会自动挂断引起网络的接通率低。分析过程小交换机在采用逐号发送时有时发送过来的号码是11位被叫号码齐全但主叫号码会变成乱码。对于逐号发送的模式会引起收号不全或者主叫号码乱码最终导致呼叫失败那么就对小交换机的发号模式进行修改修改成整体发送。由以上信令可以看出此次呼叫成功在SETUP消息里面可以看到小交机发送过来的主叫号码是5788328被叫号码是13692796308。修改小交机发送号码的模式后主叫号码没有变成乱码小交换送过来的号码也是11位号码收全所以呼叫正常。3、初步定位是由于发号模式的问题引起呼叫失败而逐号发送号码的模式怎么就会引起被叫号码收号不全及主叫号码变成乱码的呢？而且此交换机一直都是运用逐号发送的模式怎么现在才引起呼叫失败呢？鉴于这些问题就要对此呼叫失败的原因再进一步的进行分析。4、对此专线的Q921消息进行跟踪发现此专线的信令链有些异常。正常的信令是只发送RR的测试消息的但这条专线的信令是在发送一段时间RR消息后对端会回复一条INVALIDFRAME信令然后又是发送RR信令。传输整改后信令链的信令消息正常。由以上分析的过程可以看出此次呼叫失败的原因是由于传输误码引起CRC校验不成功当小交换机采用逐号发送的模式时会使对端发送过来的部分号码丢失引起呼叫失败。处理过程传输对此专线的线路进行整改整改后专线的信令链消息正常。而且再把专线更改回来逐号发送的模式也不会出现呼叫失败的现象。总结对以上专线呼叫失败的处理最后定位出专线呼叫失败的原因是传输有误码而不是专线的逐号发送模式引起。对于一般专线呼叫失败时首先要核查是移动网络还是铁通网络引起的呼叫失败在中创中查询呼叫记录查看是由哪端网元发起拆线消息此次呼叫失败在中创中根本查不到相关的呼叫记录那么说明此次呼叫时没有经过铁通的网络排除了铁通引起呼叫失败的可能性。其次是核查在移动的哪个网元引起呼叫失败因为此次呼叫未经过铁通那么此次呼叫也是未经过核心网的两个关口局排除了核心网关口局引起呼叫失败的可能性。再次就是核查剩下的几个移动网元由于HZAGW是在B表中定义数据而B表是整个号段定义数据如果此数据定义错误的话就完全打不通电话不可能有呼叫成功的可能性所以又排除了HZAGW引起呼叫失败的可能性。最后剩下NGN及对端小交换机及NGN和小交换机所连接的传输可能会引起呼叫失败。在UGC中跟踪信令发现呼叫不成功的时候是因为对端小交换机送过来的号码不全或者主叫变成乱码而引起呼叫失败而且在跟踪Q921消息的时候发现对端有发送INVALIDFRAME无效帧消息。可能NGN在收对端发送号码的时候同时收到一个INVALIDFRAME无效帧引起收号不齐或者主叫号码变成乱码。但对端小交换机跟踪信令的时候发现号码已全部发送出去及发送的主叫号码也是正常的。是什么原因引起发送的信令与收到的信令是不一致的？可能是Q921中有INVALIDFRAME无效帧引起但又是什么原因让信令链中有INVALIDFRAME消息呢？NGN和对端小交换机都没有发送这些消息那么可能就是由连接两端的中间传输引起此问题。对传输的误码进行测试发现传输的误码较高尝试对传输进行整改整改后信令链没有再出现INVALIDFRAME消息而且也未出现呼叫失败的情况。经过此次故障的处理总结出处理故障时要从根本上解决问题而不要让故障的表面现象所迷惑。如果此专线呼叫失败的问题定位成是由于小交换机的逐号发送模式引起收号不全最终导致呼叫失败就会对小交换机的发号模式进行更改成整号发送更改后会大大的减少呼叫失败的次数让我们觉得更改后就不会出现呼叫失败了偶而出现一次呼叫失败则可能定位成网络临时问题这样的话最终还是没有解决根本的问题。而传输状态是正常的信令链的状态也是正常的而且也没有相应的告警但传输有误码还是会引起呼叫失败影响网络的接通率。所以在解决问题时要找出引起问题的最终原因才能真正的解决网络问题。