论文部分内容阅读
摘要：本文主要介绍了TS子系统各功能模块在mSwitch系统中的作用及其相互间的接口，重点阐述了TS的主要技术，简要说明了TS的主要进程及相关配置文件，并通过案例分析进一步说明如何对TS子系统进行维护。
关键词：mSwitch 、TS （事务处理服务器）
中图分类号：[C94]
1. TS在mSwitch系统中的位置及其作用
1.1 TS在mSwitch系统中的位置及其作用
mSwitch系统是UT斯达康公司开发研制的面向下一代网络（NGN）软交换网络产品，它利用传统的电信网络体系架构，实现了电路交换网向分组交换网的演进，并将二者有效地结合在一起。而作为mSwitch子系统之一的TS（事务处理服务器）子系统采用高性能商用服务器群来实现整个系统的漫游、认证、计费请求、用户信息的维护，实现数据库与TS以及多个TS之间的数据同步等功能。
2.TS各模块的基本功能及其接口
2.1用户位置寄存器（SLR）
2.1 SLR基本功能
SLR中存储了所有的PHS用户信息、IP终端用户信息及IP终端设备信息。其主要功能如下：
（1） 管理Cache DB中的所有用户数据，包括用户公共数据、基本业务数据、补充业务数据
（2） 同步数据库与Cache的数据、漫游域间的用户信息、SLR集群间的数据
（3）管理本域或漫游域用户的VSA和CSA
（4）支持网络管理（状态报告及控制、性能统计、告警）
（5） 为增值业务（VAS）服务器如MCNC和SMSC提供位置查询业务
（6） 当用户被激活且网关准备进行VAS处理时，将通知MCNC和SMSC
（7） 支持运营商选择
2.2 付费业务中心（PSC）
2.2.1 PSC基本功能
PSC负责采集来自iPAS GW和CS-A的所有CDR，并对其进行预处理，如组装及分类等；还可对预付费用户及卡用户进行处理，如计算预付费用户及卡用户的最大允许呼叫时长，对预付费用户及卡用户CDR进行在线批价等，批价结果将保存在数据库中。
支持运营商选择。选择不同运营商的预付费用户和卡用户应采用不同的批价策略。
2.2.2 PSC接口
在mSwitch系統中，PSC主要有下列接口：iPAS GW接口，iCS-A接口，iTS接口，EventHandler接口，OMC-S接口，数据库接口
2.3丢话通知中心（MCNC）
2.3.1 MCNC基本功能
MCNC（Missed Call Notification Center， MCNC）用于存储PHS用户丢失的呼叫记录（MCR），也就是说，当PHS用户关机或者不可达时（例如移动到覆盖区外），系统将记录其他用户对该用户的呼叫。当用户重新可达后，MCNC将通知用户，同时，它还将定期尝试发出丢话通知。
2.3.2 MCNC接口
在mSwitch系统中，MCNC主要有下列接口：iMG接口，SLR接口，SMSC接口，EventHandler接口，OMC-S接口，数据库接口。
3.案例分析
3.1大量用户投诉充值后打不了电话
故障现象：绥化联通大量用户在充值后打不了电话，提示音为“您拔打的电话因欠费而停机”。
故障分析：从我公司该系统的网络结构（包括计费结构）分析应该有两方面的原因：
（1） 97系统没送过来；
（2） mSwitch系统收到了，但没有同步到SLR及网关。
1.首先通过SAM界面检查用户状态，发现投诉用户状态正常，不是欠费停机状态，说明用户数据已经送到mSwitch系统，97系统没有问题。
2.通过NMS界面检查用户资料发现投诉用户还是欠费停机状态，说明数据库的用户数据没有同步到SLR及GW，初步判定是tseh进程有问题。
3.用SQL语句进一步检查表tsevent/handleevent，发现有360000条记录没有被处理，进一步肯定是tseh进程的问题。（select count（*） from tsevent；）
处理过程：
1.检查tseh进程发现此进程仍在运行，属于正常状态。但由于时间紧急，不允许再详细分析具体原因，只能把tseh进程杀掉重启此进程。
2.重启tseh进程后，再观察表tsevent/handleevent，发现表中的记录以每分钟6000条的速度在减少，大约一个小时表中所有记录被处理完。
3.通过分析tseh.log发现是由于人为原因导致tseh与数据库的session中断，所以数据库的数据同步不过来，造成此类障碍现象的发生。
3.2 TS服务器的SLR进程运行不正常
故障现象：我公司一台TS服务器的SLR进程运行不正常，但暂不影响业务。
故障分析及处理：
1.我公司此系统共有两个TS。TS1的IP地址为10.xxx.xxx.110，TS2的IP地址为10.xxx.xxx.120。故障SLR运行在TS2上。
2.用“ps -ef|grep slr”命令检查进程状态，SLR的进程和其监视进程状态均正常。检查SLR.log文件，发现程序停在建Cache的那一步，根据SLR的工作原理，在SLR启动时，其Cache中的数据会从其它SLR的Cache中同步过来。用snoop检查同步端口的状态#snoop port 4772 （4772为SLR通过组播地址同步数据的端口，NMS中设定），结果如下：
10.xxx.xxx.110 -> 239.xxx.xxx.xxx （同步数据的组播地址，NMS中设定）
10.xxx.xxx.110 -> 239.xxx.xxx.xxx
10.xxx.xxx.110 -> 239.xxx.xxx.xxx
可以看到地址为10.xxx.xxx.110的SLR通过组播地址在向地址为10.xxx.xxx.120的SLR同步Cache中的数据。
3.用top检查SLR进程的内存使用情况，可以发现TS1中的SLR使用内存基本不变，而TS2中SLR使用的内存在不断增加，由此可以判断TS2中SLR确实正在建Cache，工作正常。经过约25分钟左右的时间，Cache建完，vip正常加载，SLR工作正常。
4.由此可以总结SLR进程运行不正常是由于Cache建立速度太慢所致，当Cache建完后SLR进程正常工作，建议现场对IP网络的质量进行测试。
参考文献：
1、《TS技术手册》 内部资料
2、《iPAS/mSwitch系统事务处理器培训手册》 内部资料
3、《mSwitch系统操作手册》 内部资料
关键词：mSwitch 、TS （事务处理服务器）
中图分类号：[C94]
1. TS在mSwitch系统中的位置及其作用
1.1 TS在mSwitch系统中的位置及其作用
mSwitch系统是UT斯达康公司开发研制的面向下一代网络（NGN）软交换网络产品，它利用传统的电信网络体系架构，实现了电路交换网向分组交换网的演进，并将二者有效地结合在一起。而作为mSwitch子系统之一的TS（事务处理服务器）子系统采用高性能商用服务器群来实现整个系统的漫游、认证、计费请求、用户信息的维护，实现数据库与TS以及多个TS之间的数据同步等功能。
2.TS各模块的基本功能及其接口
2.1用户位置寄存器（SLR）
2.1 SLR基本功能
SLR中存储了所有的PHS用户信息、IP终端用户信息及IP终端设备信息。其主要功能如下：
（1） 管理Cache DB中的所有用户数据，包括用户公共数据、基本业务数据、补充业务数据
（2） 同步数据库与Cache的数据、漫游域间的用户信息、SLR集群间的数据
（3）管理本域或漫游域用户的VSA和CSA
（4）支持网络管理（状态报告及控制、性能统计、告警）
（5） 为增值业务（VAS）服务器如MCNC和SMSC提供位置查询业务
（6） 当用户被激活且网关准备进行VAS处理时，将通知MCNC和SMSC
（7） 支持运营商选择
2.2 付费业务中心（PSC）
2.2.1 PSC基本功能
PSC负责采集来自iPAS GW和CS-A的所有CDR，并对其进行预处理，如组装及分类等；还可对预付费用户及卡用户进行处理，如计算预付费用户及卡用户的最大允许呼叫时长，对预付费用户及卡用户CDR进行在线批价等，批价结果将保存在数据库中。
支持运营商选择。选择不同运营商的预付费用户和卡用户应采用不同的批价策略。
2.2.2 PSC接口
在mSwitch系統中，PSC主要有下列接口：iPAS GW接口，iCS-A接口，iTS接口，EventHandler接口，OMC-S接口，数据库接口
2.3丢话通知中心（MCNC）
2.3.1 MCNC基本功能
MCNC（Missed Call Notification Center， MCNC）用于存储PHS用户丢失的呼叫记录（MCR），也就是说，当PHS用户关机或者不可达时（例如移动到覆盖区外），系统将记录其他用户对该用户的呼叫。当用户重新可达后，MCNC将通知用户，同时，它还将定期尝试发出丢话通知。
2.3.2 MCNC接口
在mSwitch系统中，MCNC主要有下列接口：iMG接口，SLR接口，SMSC接口，EventHandler接口，OMC-S接口，数据库接口。
3.案例分析
3.1大量用户投诉充值后打不了电话
故障现象：绥化联通大量用户在充值后打不了电话，提示音为“您拔打的电话因欠费而停机”。
故障分析：从我公司该系统的网络结构（包括计费结构）分析应该有两方面的原因：
（1） 97系统没送过来；
（2） mSwitch系统收到了，但没有同步到SLR及网关。
1.首先通过SAM界面检查用户状态，发现投诉用户状态正常，不是欠费停机状态，说明用户数据已经送到mSwitch系统，97系统没有问题。
2.通过NMS界面检查用户资料发现投诉用户还是欠费停机状态，说明数据库的用户数据没有同步到SLR及GW，初步判定是tseh进程有问题。
3.用SQL语句进一步检查表tsevent/handleevent，发现有360000条记录没有被处理，进一步肯定是tseh进程的问题。（select count（*） from tsevent；）
处理过程：
1.检查tseh进程发现此进程仍在运行，属于正常状态。但由于时间紧急，不允许再详细分析具体原因，只能把tseh进程杀掉重启此进程。
2.重启tseh进程后，再观察表tsevent/handleevent，发现表中的记录以每分钟6000条的速度在减少，大约一个小时表中所有记录被处理完。
3.通过分析tseh.log发现是由于人为原因导致tseh与数据库的session中断，所以数据库的数据同步不过来，造成此类障碍现象的发生。
3.2 TS服务器的SLR进程运行不正常
故障现象：我公司一台TS服务器的SLR进程运行不正常，但暂不影响业务。
故障分析及处理：
1.我公司此系统共有两个TS。TS1的IP地址为10.xxx.xxx.110，TS2的IP地址为10.xxx.xxx.120。故障SLR运行在TS2上。
2.用“ps -ef|grep slr”命令检查进程状态，SLR的进程和其监视进程状态均正常。检查SLR.log文件，发现程序停在建Cache的那一步，根据SLR的工作原理，在SLR启动时，其Cache中的数据会从其它SLR的Cache中同步过来。用snoop检查同步端口的状态#snoop port 4772 （4772为SLR通过组播地址同步数据的端口，NMS中设定），结果如下：
10.xxx.xxx.110 -> 239.xxx.xxx.xxx （同步数据的组播地址，NMS中设定）
10.xxx.xxx.110 -> 239.xxx.xxx.xxx
10.xxx.xxx.110 -> 239.xxx.xxx.xxx
可以看到地址为10.xxx.xxx.110的SLR通过组播地址在向地址为10.xxx.xxx.120的SLR同步Cache中的数据。
3.用top检查SLR进程的内存使用情况，可以发现TS1中的SLR使用内存基本不变，而TS2中SLR使用的内存在不断增加，由此可以判断TS2中SLR确实正在建Cache，工作正常。经过约25分钟左右的时间，Cache建完，vip正常加载，SLR工作正常。
4.由此可以总结SLR进程运行不正常是由于Cache建立速度太慢所致，当Cache建完后SLR进程正常工作，建议现场对IP网络的质量进行测试。
参考文献：
1、《TS技术手册》 内部资料
2、《iPAS/mSwitch系统事务处理器培训手册》 内部资料
3、《mSwitch系统操作手册》 内部资料