标题 | 电信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网络维护工作的经验还在逐步的积累中,处理各种故障还需要根据现网的组网实际情况,接入设备,模式等具体情况来综合判断确定故障点,希望本文能对维护工作者们能起到交流、借鉴作用。 |
随便看 |
|
科学优质学术资源、百科知识分享平台,免费提供知识科普、生活经验分享、中外学术论文、各类范文、学术文献、教学资料、学术期刊、会议、报纸、杂志、工具书等各类资源检索、在线阅读和软件app下载服务。