电信IMS网络信令分析在故障处理的应用初探

沈晖

【摘要】 目前中国电信的传统PSTN，固网软交换，移动交换等多张核心网络并存，运维成本高昂，随着互联网的对电信行业的不断冲击和渗透，新业务的不断驱动，需要逐步整合不同的业务和网络，发挥全业务运营的优势，部署IMS网络也就有其必然性了。随着IMS网络的调测入网和上线运行，各种故障处理随之而来，而信令分析是在故障处理的中一把利器。本文从多个IMS网络维护工作中的故障案例探讨了信令分析方法的灵活运用。

【关键字】 IMS 信令 分析

一、维护案例：

案例一：使用信令分析倒查法

故障现象：CS域用户为主叫IMS用户为被叫时，主被叫可以正常接通，但很快自行拆线。

故障分析：由于IMS用户为SIP用户，接入侧为IAD设备，通过PCSCF做代理，向核心网注册，而主叫方为CS域用户，通过MGCF与IMS域互通。用户正常呼叫接通后，双方可以互相听到对方的声音，可以判断主被叫双方媒体面可以正常通信，因此需要在核心网网元用信令分析的方式确定拆线原因。

故障信令分析：首先在PCSCF和ISBG网元同时进行信令跟踪，发现是ISBG上跟踪的信令中收到AS平台发出了BYE消息，导致了拆线，如下图。

继续对ISBG网元的信令进行分析，可以发现在ISBG上出现多次ISBG给PCSCF转发200 OK消息，但均未得到PCSCF的响应。

再查看PCSCF的信令，发现在PCSCF上收到了ISBG发过来的多次200 OK消息，且PCSCF把200 OK消息均转给了SBC，但没有收到SBC返回的ACK响应。

为什么SBC侧为什么不回ACK响应消息呢？继续查看PCSCF的信令，原来PCSCF之前已收到了SBC回的ACK响应消息，且也向主叫方进行了转发，但通话建立后，IMS用户做为被叫方却又主动发出了一个INVITE消息，且INVTE消息中的主被叫号码与呼叫建立时一样。

因此，可以确定是接入侧设备发异常INVITE消息导致呼叫建立成功后拆线。

故障解决：在接入侧对IAD设备配置参数修改后，问题解决。

案例二：有时需要持续跟踪一段时间，以便进行信令比对

故障现象：某用户采用SIP方式接入IMS出现主、被叫有时通，有时不通的问题；

故障分析：由于该用户时通时不通，需要对两种不同情况下的信令进行比对；

故障信令分析：对该故障用户进行信令跟踪，分析一段时间内的有用户注册信息，信令中发现该号码用户有二次从不同的终端发起的注册，说明一个号码放到了多个终端上，导致了有时拨打不通。 （图4）

故障解决：这个解决起来就很简单了，认正确的注册终端确，在其它异常终端上清除垃圾数据。（图5）

案例三：先排除其他原因，再进行信令分析

故障现象：正常的IMS用户在签约IVPN业务后无法做被叫；

故障分析：因IMS用户已正常注册成功；在SCSCF上ping AGCF的业务地址，测试正常； 检测SCSCF与AGCF之间SIP链路状态，一直正常，未出现断链出现，检查SCSCF上号码分析数据配置无异常，几种常见的故障情况均已排除，因此只能在SCSCF上进行用户呼叫跟踪和信令分析；

故障信令分析：在SCSCF上进行用户呼叫跟踪和信令分析，发现信令中出现了不正常的被叫用户触发IVPN业务的信令；IVPN业务是主叫业务，被叫用户不应该触发IVPN。

故障解决：检查SCSCF SIFC和SPT数据，发现IVPN业务SIFC中调用的3个SPT中的组ID参数配置有问题，设备厂家工程师修改后测试正常。

二、案例总结

在维护IMS网络工作中，需要熟悉网络结构，清楚呼叫流程，才能够有效地分析原因，确认故障点。IMS的呼叫流程和传统的呼叫信令跟踪分析有较大的区别，需要认真分析，小心求证，不断地积累经验。

三、结束语

目前， IMS网络维护工作的经验还在逐步的积累中，处理各种故障还需要根据现网的组网实际情况，接入设备，模式等具体情况来综合判断确定故障点，希望本文能对维护工作者们能起到交流、借鉴作用。