智能网业务故障分析

智能网业务故障分析
孙璐
中国电信江苏公司南京分公司南京 210008
1 维护实例1：F150制式的主叫号码打不通异地手机
省内某地维护人员反映，当地一用户打不通2个外地手机号码。

根据业务特性，判断该用户使用的是异地手机受端入网业务。

该业务当时全部由省内各TS/SSP触发013X智能业务，将被叫手机号码送至省智能网SCP进行H码翻译，接着由SCP 将翻译后的被叫区号及手机号码送回发端局，再完成后续接续通话。

根据业务特点，维护人员首先在省智能平台上查询这2个手机号码的翻译区号，然后分别进行了手机号码直拨及在手机号码前加插区号的拨打测试，均不通。

接着，为了校验集团下发的H码翻译汇总文件是否有误，维护人员直接用手机拨打被叫手机，询问对方手机入网的城市区号，结果与智能平台数据一致，为0432。

一般情况下，如果异地手机直拨不通，可能是H码翻译不正确或者未翻译；如果区号翻译正确，直拨或者加拨区号都不通，则可能为落地局未做入省或地市的H码翻译数据。

根据这个处理结果，维护人员联系了长春局的维护人员，请他们拨测并检查数据。

结果出乎我们的意料：数据正确，且拨测成功。

带着疑问，我们再次进行了全面的测试，同时利用信令仪表进行呼叫跟踪，偶然发现：当主叫用户通过F150制式的交换机发起呼叫时就打不通这2个手机，而主叫用户用S1240等其他制式的时候都可以打通。

通过仔细比对2种不同制式的呼叫跟踪结果，维护人员发现大部分的消息内容是一致的，只是F150制式主叫用户送出的IAM比S1240制式主叫用户送出的IAM多出一段“00011101 1d：用户业务信息”的内容，因此，初步判断是对方TS或者对方移动局不识别此段多出的消息内容。

于是，维护人员再次联系长春局维护人员，描述了我们的测试结果及疑问，并请他们进行测试跟踪。

不久，经过长春局维护人员的分析处理并与移动公司联系后，确认故障原因是由于吉林市移动公司更换设备，不能识别F150制式交换机发出的那部分消息。

最后，经过长春局联系吉林移动公司对其设备进行了相应数据修改后，故障排除。

2 维护实例2：同一商务灵通网内的PHS A打固定号码B的小号时无法同振B的PHS
用户投诉：小灵通8211aaaa拨打网内固定电话8550bbbb的小号bbbb时，同振不了被叫的小灵通8211bbbb。

其实这个故障中包含了2个业务。

一个是商务灵通网（广域虚拟网/WAC）业务，这是在南京本地WAC智能平台上实现跨端局且在同一网内小号的互拨功能。

不管是IGW还是PSTN 端局，只要判断所拨被叫小号为出局时，均在被叫小号前加插业务触发字冠84259后送上SCP，再由SCP根据其所拨小号在组内查找PSTN号码，下发回发端最终接续到被叫用户并触发被叫用户的签约业务。

另一个为同振业务（TCP），当被叫用户（固定电话）在SHLR（综合智能归属位置寄存器）上签约被叫同振业务后，在省智能平台上可设置一同振小灵通号码。

当固定电话作被叫时，则2个终端同时振铃，用户可以选择任一终端接听电话。

根据这2个业务触发原则，首先在WAC平台上检查数据是否正确，即8211aaaa和8550bbbb是否存在大小号对应关系且在同一个虚拟网组内。

数据显示小灵通号码8211aaaa 的WAC小号为aaaa，固定电话8550bbbb的WAC小号为bbbb，它们在同一个虚拟网组内。

因此，只要IGW送上SCP的数据正确，则拨打小号bbbb时，WAC平台肯定会下发其大号8550bbbb。

接着，维护人员又检查了8550bbbb在SHLR上有没有签约被叫同振业务及在省智能平台上有无设置同振号码，发现数据均正确。

于是，维护人员又进行了拨打测试，并且同时在WAC平台、汇接局和小灵通IGW上进行跟踪，结果发现WAC业务触发正常，能正常接续到被叫8550bbbb，可就是同振不了其小灵
通。

仔细研究比对3个跟踪结果，最终维护人员发现故障原因就在小灵通IGW上。

原来，在IGW上“同振业务”与“WAC业务”被定义成了一个业务分析。

在这个业务分析的“被叫分析子”中，以1～8开头的被叫分析字冠直接定义了加插9113025（同振业务前缀码），而在小灵通HLR，当该组内aaaa1拨打短号码bbbb时，HLR会默认为WAC业务，于是又加上了WAC业务前插码84259。

这样整合后，从IGW送给MS（汇接局）的号码为911302584259bbbb。

汇接局将同振业务接入码9113025剥离后暂时寄存，再将84259bbbb送上SHLR去查有没有该号码相关属性。

由于SHLR中无84259bbbb这个号码的任何数据与属性，所以就透传下发回汇接局。

汇接局看到有WAC业务前插码84259，就又送上南京本地WAC业务平台，去查到了该8543小号对应的大号为8550bbbb。

WAC平台将大号8550bbbb下发给汇接局，汇接局又将先前剥离的同振业务接入码9113025加上，送上SHLR再去查还有无8550bbbb相关的签约业务。

SHL R识别到9113025为同振业务接入码，即认为该被叫号码已经触发过同振业务了，于是只将8550bbbb下发回汇接局，由其接续到被叫。

这样，就无法再去同振其小灵通号码8211bbbb了。

为解决这个问题，维护人员在小灵通IGW上做了数据修改：在“被叫分析子”中增加对84259的分析字冠，这样，当aaaa拨打bbbb时，从IGW送出的号码就直接为84259bbbb了。

接下去，各网元就能正常分析数据、触发并接续到其同振小灵通上了。

3 维护实例3：用户使用201卡时总提示“请输入您的卡号”
某晚，大量用户投诉：使用201卡业务时，输入卡号密码后总再次提示“请输入您的卡号”。

201卡业务是省智能平台上主要的卡式业务，是面向学生推广的全省通用卡，可提供语音通话及201窄带上网业务。

该智能平台上的201卡数据库设置为分别由2对主/备SDP服务器来处理账号尾数为奇数和偶数的卡。

维护人员用201测试卡进行了拨打测试，发现问题集中在账号尾数为偶数的卡。

根据经验，初步判断是处理偶数类卡数据库出现问题，不能对用户的卡号和密码进行识别。

登录到智能平台查看系统状态，发现处理偶数类卡业务的SDP服务器已经由A自动切换到原备用机B了，原主用机A已是吊死（非正常宕机与切换）状态。

按照正常的突发故障处理经验，主/备机能自动倒换时是不会影响业务使用的。

可按照目前状况看，设备倒换成功了，业务却依旧无法正常使用。

于是，维护人员进入当前主用机B检查系统各进程运行状态，均为“RUNNING”。

接着，又继续观察201业务各呼叫进程接入情况，发现一个重要疑点：虽然是深夜，呼叫量少，可是每个呼叫进程均无任何接入呼叫，CAPS值全为0。

问题的关键点就在这里。

紧急情况下，维护人员将业务进程及所有应用进程全部重新启动了一遍。

重启后，所有201业务进程开始正常接收呼叫，故障排除。

事后，经过与设备及系统厂商工程师的进一步分析，发现是由于处理201偶数类卡的原主用机A因为某硬件故障发生吊死（非正常宕机与切换），业务进程虽然切换到了备用机B，但是A机状态并未显示为完全宕机，造成B机并没有真正接管业务呼叫，即SCP依然将上发的卡号密码查询发往原主用机A。

当天夜里对B机上所有应用进程进行重启操作，即强制把业务呼叫从A上切换到B上，所以呼叫得以恢复正常。