1、智能网业务故障分析孙 璐中国电信江苏公司南京分公司 南京 2100081 维护实例 1：F150 制式的主叫号码打不通异地手机省内某地维护人员反映，当地一用户打不通 2 个外地手机号码。根据业务特性，判断该用户使用的是异地手机受端入网业务。该业务当时全部由省内各 TS/SSP 触发 013X 智能业务，将被叫手机号码送至省智能网 SCP 进行 H 码翻译，接着由SCP 将翻译后的被叫区号及手机号码送回发端局，再完成后续接续通话。根据业务特点，维护人员首先在省智能平台上查询这 2 个手机号码的翻译区号，然后分别进行了手机号码直拨及在手机号码前加插区号的拨打测试，均不通。接着，为了校验集团下发的
2、H 码翻译汇总文件是否有误，维护人员直接用手机拨打被叫手机，询问对方手机入网的城市区号，结果与智能平台数据一致，为 0432。一般情况下，如果异地手机直拨不通，可能是 H 码翻译不正确或者未翻译；如果区号翻译正确，直拨或者加拨区号都不通，则可能为落地局未做入省或地市的 H 码翻译数据。根据这个处理结果，维护人员联系了长春局的维护人员，请他们拨测并检查数据。结果出乎我们的意料：数据正确，且拨测成功。带着疑问，我们再次进行了全面的测试，同时利用信令仪表进行呼叫跟踪，偶然发现：当主叫用户通过 F150 制式的交换机发起呼叫时就打不通这 2 个手机，而主叫用户用 S1240等其他制式的时候都可以打通。
3、通过仔细比对 2 种不同制式的呼叫跟踪结果，维护人员发现大部分的消息内容是一致的，只是 F150 制式主叫用户送出的 IAM 比 S1240 制式主叫用户送出的 IAM 多出一段“00011101 1d：用户业务信息”的内容，因此，初步判断是对方 TS或者对方移动局不识别此段多出的消息内容。于是，维护人员再次联系长春局维护人员，描述了我们的测试结果及疑问，并请他们进行测试跟踪。不久，经过长春局维护人员的分析处理并与移动公司联系后，确认故障原因是由于吉林市移动公司更换设备，不能识别F150 制式交换机发出的那部分消息。最后，经过长春局联系吉林移动公司对其设备进行了相应数据修改后，故障排除。2 维
4、护实例 2：同一商务灵通网内的 PHS A 打固定号码 B 的小号时无法同振 B 的 PHS用户投诉：小灵通 8211aaaa 拨打网内固定电话 8550bbbb 的小号 bbbb 时，同振不了被叫的小灵通 8211bbbb。其实这个故障中包含了 2 个业务。一个是商务灵通网（广域虚拟网/WAC）业务，这是在南京本地 WAC 智能平台上实现跨端局且在同一网内小号的互拨功能。不管是 IGW 还是PSTN 端局，只要判断所拨被叫小号为出局时，均在被叫小号前加插业务触发字冠 84259 后送上 SCP，再由 SCP 根据其所拨小号在组内查找 PSTN 号码，下发回发端最终接续到被叫用户并触发被叫用户
5、的签约业务。另一个为同振业务（TCP），当被叫用户（固定电话）在SHLR（综合智能归属位置寄存器）上签约被叫同振业务后，在省智能平台上可设置一同振小灵通号码。当固定电话作被叫时，则 2 个终端同时振铃，用户可以选择任一终端接听电话。根据这 2 个业务触发原则，首先在 WAC 平台上检查数据是否正确，即 8211aaaa 和8550bbbb 是否存在大小号对应关系且在同一个虚拟网组内。数据显示小灵通号码 8211aaaa的 WAC 小号为 aaaa，固定电话 8550bbbb 的 WAC 小号为 bbbb，它们在同一个虚拟网组内。因此，只要 IGW 送上 SCP 的数据正确，则拨打小号 bbbb
6、 时，WAC 平台肯定会下发其大号8550bbbb。接着，维护人员又检查了 8550bbbb 在 SHLR 上有没有签约被叫同振业务及在省智能平台上有无设置同振号码，发现数据均正确。于是，维护人员又进行了拨打测试，并且同时在 WAC 平台、汇接局和小灵通 IGW 上进行跟踪，结果发现 WAC 业务触发正常，能正常接续到被叫 8550bbbb，可就是同振不了其小灵通。仔细研究比对 3 个跟踪结果，最终维护人员发现故障原因就在小灵通 IGW 上。原来，在 IGW 上“同振业务”与“WAC 业务”被定义成了一个业务分析。在这个业务分析的“被叫分析子”中，以 18 开头的被叫分析字冠直接定义了加插 9
7、113025（同振业务前缀码），而在小灵通 HLR，当该组内 aaaa1 拨打短号码 bbbb 时，HLR 会默认为 WAC 业务，于是又加上了 WAC 业务前插码 84259。这样整合后，从 IGW 送给 MS（汇接局）的号码为911302584259bbbb。汇接局将同振业务接入码 9113025 剥离后暂时寄存，再将 84259bbbb送上 SHLR 去查有没有该号码相关属性。由于 SHLR 中无 84259bbbb 这个号码的任何数据与属性，所以就透传下发回汇接局。汇接局看到有 WAC 业务前插码 84259，就又送上南京本地 WAC 业务平台，去查到了该 8543 小号对应的大号为
8、8550bbbb。WAC 平台将大号 8550bbbb 下发给汇接局，汇接局又将先前剥离的同振业务接入码9113025 加上，送上 SHLR 再去查还有无 8550bbbb 相关的签约业务。SHL R 识别到 9113025为同振业务接入码，即认为该被叫号码已经触发过同振业务了，于是只将 8550bbbb 下发回汇接局，由其接续到被叫。这样，就无法再去同振其小灵通号码 8211bbbb 了。为解决这个问题，维护人员在小灵通 IGW 上做了数据修改：在“被叫分析子”中增加对 84259 的分析字冠，这样，当 aaaa 拨打 bbbb 时，从 IGW 送出的号码就直接为84259bbbb 了。接下
9、去，各网元就能正常分析数据、触发并接续到其同振小灵通上了。3 维护实例 3：用户使用 201 卡时总提示“请输入您的卡号”某晚，大量用户投诉：使用 201 卡业务时，输入卡号密码后总再次提示“请输入您的卡号”。201 卡业务是省智能平台上主要的卡式业务，是面向学生推广的全省通用卡，可提供语音通话及 201 窄带上网业务。该智能平台上的 201 卡数据库设置为分别由 2 对主/备 SDP服务器来处理账号尾数为奇数和偶数的卡。维护人员用 201 测试卡进行了拨打测试，发现问题集中在账号尾数为偶数的卡。根据经验，初步判断是处理偶数类卡数据库出现问题，不能对用户的卡号和密码进行识别。登录到智能平台查看
10、系统状态，发现处理偶数类卡业务的 SDP 服务器已经由 A 自动切换到原备用机 B 了，原主用机 A 已是吊死（非正常宕机与切换）状态。按照正常的突发故障处理经验，主/备机能自动倒换时是不会影响业务使用的。可按照目前状况看，设备倒换成功了，业务却依旧无法正常使用。于是，维护人员进入当前主用机 B 检查系统各进程运行状态，均为“RUNNING”。接着，又继续观察 201 业务各呼叫进程接入情况，发现一个重要疑点：虽然是深夜，呼叫量少，可是每个呼叫进程均无任何接入呼叫，CAPS 值全为 0。问题的关键点就在这里。紧急情况下，维护人员将业务进程及所有应用进程全部重新启动了一遍。重启后，所有 201 业务进程开始正常接收呼叫，故障排除。事后，经过与设备及系统厂商工程师的进一步分析，发现是由于处理 201 偶数类卡的原主用机 A 因为某硬件故障发生吊死（非正常宕机与切换），业务进程虽然切换到了备用机 B，但是 A 机状态并未显示为完全宕机，造成 B 机并没有真正接管业务呼叫，即 SCP 依然将上发的卡号密码查询发往原主用机 A。当天夜里对 B 机上所有应用进程进行重启操作，即强制把业务呼叫从 A 上切换到 B 上，所以呼叫得以恢复正常。
