NOKIA短信中心系统架构设计说明.docx
《NOKIA短信中心系统架构设计说明.docx》由会员分享，可在线阅读，更多相关《NOKIA短信中心系统架构设计说明.docx（33页珍藏版）》请在冰豆网上搜索。
NOKIA短信中心系统架构设计说明
1.NOKIASMSC7.0同时支持GSM/GPRS/3G网络
NOKIA的SMSC可以通过MSC（使用SMRSE/TCP链路）或者直接通过SS7网络（使用MAP/SS7链路）或者通过IP网络（使用MAP/SIGTRAN链路）连接到GSM，GPRS或者3G网络。
2.NOKIA的SMSCCLUSTER结构
NOKIA的SMSC可以有2～4台SMSC服务器组成一套CLUSTER，其中一台作为ADMIN管理节点服务器。
NOKIA的SMSC可以很方便的进行扩容升级，单点服务器可以一台接一台的升级，保证最小的升级时间，对于整个CLUSTER来说，不会影响现有业务。
外部短消息实体可以通过PSW功能只连接一个单点，就可以使整个CLUSTER来完成外部应用发送的短信。
3.外部接口
上图中显示了SMSC和外部系统的接口和相应的协议，分别属于三个相对独立的功能单元：
电信接口，消息处理核心（管理接口），应用接口。
3.1应用接口
应用接口主要有CIMD2、SMPP、UCP、VMS、E-MAIL、MCI应用等接口，其中国内使用最多的是SMPP接口。
3.1.1SMPP接口
SMPP接口是为短消息实体在GSM网络中使用短消息点对点（SMPP）协议开发的。
在短信中心，SMPP接口是作为一个实现内部的CIMD2应用，负责SMPP协议和CIMD2协议之间的协议转换，使用的协议是基于TCP/IP的SMPPV3.3和V3.4版本。
3.2管理接口
3.2.1图形化用户接口（GUI）
短信中心用户接口包含GUI图形化用户接口和命令行用户接口。
用户可以通过X-WINDOWS模拟软件（例如使用ReflectionXforWINDOWS，使用XDMCP直接连接方式）使用一般的PC机连接到GUI上。
3.2.2计费系统接口
短信中心的logwriter模块产生CDR计费话单，外部的计费中心（BOSS）可以使用基于TCP/IP的FTP协议把CDR取过去。
3.2.3网管接口
∙NokiaEnhancedSNMPSolutionSuite（NE3S）是基于SNMP并扩展了电信管理需求的网络管理接口；
∙NE3S接口用于告警管理；
∙事先定义好的告警信息会发送到NokiaNetAct；
3.2.4性能管理接口
性能管理的目的是去监控短信中心的运行情况和产生性能的统计数据。
性能管理接口是使用来收集系统性能数据，使用的协议是基于TCP/IP的FTP。
3.3通信接口
3.3.1SMRSE接口
3.3.2MAP/SS7接口
3.3.3MSP/SIGTRAN接口
4.短信中心周边系统
4.1短信内容监测系统4.0的组成
4.1.1系统构成
图7.1是短信中心机房中内容监测系统的结构图
图7.1短信内容监测系统的结构
上图中的结构包括了2个Site的网络部署结构,每个Site是一套独立的相对独立又保持联系的短信内容监测系统。
每套系统均由Solaris服务器组成，其中有负责短信内容的收集的实时服务器（RealTimeServer），报警服务器（AlarmServer）针对每一个用户号码，完成短信内容的累加，历史服务器（HistorySeerver）可以实现对历史数据的查询，如果某个手机用户在固定时间内发送的短信条数超过了一定的门限其告警数据的显示和查询在历史服务器上实现。
本次短信内容监测系统由3.2版本升级到4.0版本，系统将支持跨平台，可支持Solaris、Linux和Windows3种操作系统。
4.1.2NOKIA短信内容监控产品的处理流程：
本文档介绍短信内容简介监控系统4.0，forNokiaShortMessageServiceCenter（SMSC7.0）.
SMContentMonitor4.0由以下模块构成：
1.ycmcolmx
2.FTPmodule
3.consort.bat
4.slide_comp.bat
5.HDsave.batonhistoryserver
6.MonitorEngine.batonhistoryserver
7.WebApplicationForSearchClientonhistoryserver
各模块功能及运行所在机器：
Ycmcolmx
SMSC
采集SM数据
FTP
SMSC
传送SM数据文件
Consort.bat
Realtimeserver
实时处理SM数据文件,并把临时记数文件传送到AlarmServer,把转换好格式的SM数据文件传送到HistoryServer
Slide_comp.bat
Alarmserver
根据配置情况定时产生报警数据，并把报警数据传送到HistoryServer
HDsave.bat
HistoryServer
将处理后SM数据文件送到AlarmServer和HistoryServer
MonitorEngine.bat
HistoryServer
搜索引擎程序，接收Client端的查询请求，进行搜索，可支持多用户查询
WebApplication
HistoryServer
部署在Tomcat服务器下，Web查询界面，可实时显示报警数据，并可对报警数据和SM数据进行查询，支持同一页面对双Site的同时查询。
主要模块间接口关系：
ycmcolmx
从SMSC消息队列中取SM数据，形成数据文件；
FTP
将ycmcolmx产生的SM数据文件FTPPUT到RealtimeServer上的./tmp目录下。
Consort.bat
处理SM数据文件。
对于每个SM数据文件产生两个处理后文件：
一个作为历史文件保存；一个计数文件交给AlarmServer做进一步处理；
HDsave.bat
将HistoryServer临时目录中的历史文件转移到查询目录中，并监测查询目录的空间，在空间不足时按目录清理旧文件
Slide_comp.bat
输入：
slide_comp.bat的./cnt子目录下的中间文件
输出：
./alarm子目录下的报警数据文件
4.1.3两个机房短信中心内容监控系统的组成
由于短信中心在两个机房建设，中间采用广域网连接，因此短信内容监测必须考虑节省广域网的带宽，如果把每个短信的内容传送到一套统一的短信内容监控系统，虽然可以准确地监测到短信中心的内容，但是对广域网的带宽产生了巨大的浪费，为此我们在两个机房分别建设内容监测系统，各内容监测系统分别统计自己所管辖区域内的服务器各用户短信的内容，并设计门限，将在规定时间窗口内、某用户的短信发送数量超过该门限的用户号码以文件方式发送到统计服务器，这时我们并不传递内容，因此可以极大地节省广域网的带宽。
图7-2是这种连接方式的拓扑结构图。
图7-2两个机房内容监控组网
系统允许多人查询，但考虑到性能和速度问题，建议的并发查询数<10.系统可配置只允许1个人做查询还是多个人做查询。
另外值得注意的是：
所有的查询过程都将被系统自动记录，通过HistoryServer上的执行的查询行为将记录用户名、查询时间、查询者IP和查询条件。
系统用户分为普通用户和系统管理员，系统管理员可增、删用户，并可查看所有用户的查询记录，但不能删除。
普通用户只能对报警数据和业务数据进行查询。
在本次部署中，可考虑一共使用4台服务器，在主Site上使用2台SUNV440服务器，
在从Site上使用1台SUNV440服务器和1台PC服务器。
4.1.4NOKIA短信内容监控产品的主要功能
1.支持绿色号码：
对确认的手机号码不检测，不产生告警。
2.可以对MO和AO短信设置检测门限，给出报警。
3.对历史数据进行查询，并记录查询日志
4.系统多用户管理和多用户并发查询
5.系统支持双Site查询
6.自动保存上一个月的数据到磁带机。
7.如果硬盘空间不够，自动删除旧数据。
8.系统支持Solaris、Linux、Windows查询。
9.系统告警门限和时间段可配置。
4.2短信统计系统的组成
NOKIA的性能统计服务器是在对短信服务的完整理解上开发完成的，设备由两部分组成，SUN服务器主要完成从短信中心采集数据并将数据按照一定的格式插入到数据库中，NT服务器主要完成各种报表的产生。
性能统计和短信监控的信息源是短信中心产生，定时由短信中心传送到统计监控服务器，如果统计监控服务器出现故障，短信中心能够把原始记录缓存。
短信中心的性能分析服务器对硬盘容量的要求只与短信中心服务器的数目有关，而于短信中心每秒处理的条数没有关系。
短信统计系统保持现在情况不变，由于短信中心在两个机房建设，中间采用广域网连接，两个机房的统计系统分别统计自己所管辖区域内的服务器各用户短信性能数据，分别生成各自的报表，最后在一台服务器上将各个报表合成，这样在广域网上只传递Excel表，因此数据量不大。
图7-3是这种连接方式的拓扑结构图。
图7-3统计系统的拓扑结构
可以按照现在的配置情况不变，配置商贸路机房的报表生成服务器为主服务器，所有的配置工作在该服务器上完成，北环机房的服务器为从服务器，只能在北环机房的报表生成服务器上查询和显示各种统计信息，但不能进行系统配置工作。
4.3告警系统的组成
短信中心配置有一台工作终端，通过专用接口连接告警盒，为系统提供声光告警。
短信中心升级到SMSC7.0之后，不再支持原来的告警系统工作模式，短信中心不再提供通过PIPO把告警信息写入短信中心EventLog文件的功能，因此告警工作站无法提取告警数据，也就不能给出声光告警。
短信中心升级到SMSC7.0之后，系统统一使用故障管理接口（FMIF）把告警信息通过发送SNMPtraps给NMS或者告警系统，使用SNMPV1或者SNMPV2协议。
因此短信系统升级之后，局方操作人员可以配置需要发送哪些告警信息，然后通过SNMP直接发送的NOKIANetAct。
由于升级之后，短信系统可以通过SNMP提供大量的告警信息，因此完全可以通过NMS系统替代现在的告警系统。
但是考虑到声光告警系统对河南移动维护人员很重要，因此NOKIA公司会修改现在声光告警的接口，以使河南移动现在的声光告警系统可以在SMSC7.0下继续使用。
此外，我们这次还增加了如下功能：
∙告警信息入库，并可以保存指定时间内，在alarm-panel可以做实时查询。
∙告警统计功能，提供对历史告警信息作指定的统计。
∙提供自定义声音报警，不同报警显示颜色定义，配置信息可保存等功能。
4.4集中日志查询系统
4.4.1概述
随着短信业务量日新月异的增长，河南移动现网承载业务的短信设备磁盘空间受到了很大的限制，短信日志只能查询最近3天的记录信息。
而随着短信设备维护管理工作的要求不断提高以及受理用户短信投诉的要求，河南移动希望能够向移动用户提供更长时间和功能更强大的短信日志查询服务。
基于短信日志快速查询的需求，考虑单独建立短信日志管理系统：
1）提高河南移动解决用户使用短信服务过程中出现的问题的能力。
2）提高移动用户使用短信服务的满意度。
3）为短信业务的不断改进提供基础数据和分析依据。
4）可为今后有关文件方面的新功能需求提供很好的可扩展性。
4.4.2短信日志查询系统的建设思路
河南移动拥有庞大的潜在用户群体，具有很好的增值业务发展基础。
经过多年来的业务宣传与市场培养，河南移动的短信业务得到了长足的发展，并一直保持着良好的发展势头。
目前河南的短信中心分布在两个点,分别位于北环路机房和商贸路机房，为了满足对单一用户在指定时间段内的全部短信日志查询，我们建议在北环路机房集中建设短信日志查询系统。
而商贸路机房与北环路机房之间的日志数据传输采用压缩传输的方式，从而可以大大地节省对两机房之间的网络带宽需求。
根据河南移动提供的需求，短信日志查询系统将支持以下功能：
1）短信中心将evlog日志文件上传到短信日志管理系统，短信中心上的evlog日志文件还保留原来循环文件的模式。
2）短信日志管理系统将evlog日志文件进行入库处理。
3）evlog日志文件成功入库后，日志文件保存48小时，48小时后短信日志管理系统将这些日志文件自动删除。
4）短信日志管理系统提供日志文件传送和入库处理情况的记录日志，以便处理问题时参考。
5）支持多用户、不同查询权限用户来进行日志准实时查询。
如：
1860和监控室用户的权限为：
只能对用户的发送和接收记录进行查询，查询条件分为必选查询条件和可选查询条件。
要求显示所查询的记录总数，并且以excel格式文件保存。
4.4.3业务模型及能力估算
业务模型
系统要求将北环路短信中心和商贸路短信中心的日志数据在线保存一个月，客户可以通过界面对日志及CDR进行查询，并发查询的规模在并发10次以下，要求在60秒内返回查询结果。
根据河南移动现网业务的情况，短信日志系统的业务处理需求如下：
∙短信中心的话务量为60,000,000条/天；
∙每条短信对应3条日志；
∙每条短信的日志及CDR平均占用162字节；
存储估算
对河南移动现网业务需求的分析来进行短信日志查询系统的存储空间的估算：
每天的日志存储量为：
60,000,000*3*162=27.2GB
日志在现保存一个月为：
22.6*30=844GB
考虑到在数据库中为每条消息配置的索引，数据库的存储效率等因素，我们设定系统的数据库系数为2.5，则该系统最终的存储空间需求为：
884G*2.5=2.2TB
针对以上的业务需求，我们在本次系统建设中，建议用户配置EMCCX300高速光纤磁盘阵列，并配置13块300G硬盘，一块作为备份，其余做3×（3＋1）RAID备份，完全满足需求。
广域网带宽计算
由于短信日志查询系统建设在北环路机房，因此商贸路机房的日志就要传送到北环路机房。
我们可以考虑商贸路机房的流量占有全部短信量的20％～30％左右，因此商贸路产生的日志量流量大约为：
60000000×30％×3＝54000000条。
日志会先进行压缩然后再传送，可以压缩到原来的20％左右，保证带宽的利用率更高，因此通过广域网传送日志文件需要的广域网带宽为：
54000000/3600/10×162byte×8×20％＝389K
同时考虑到一些TCP/IP的开销、系统突发量、路由备份等，不会超过2M数据链路，因此对现网1G的广域网带宽完全没有影响。
4.4.4系统硬件配置建议
根据以上数据分析，我们建议河南移动短信日志查询系统的总体方案如下：
针对河南移动本期短信日志查询系统的需求，业务逻辑相对比较简单，但是系统操控的数据量特别大，在一个月的历史数据完整的情况下，数据库中的平均记录数在几十亿条以上，因此在查询、统计、报表的过程中对数据库服务器的性能要求是一个很大的挑战。
我们在综合借鉴短信中心、短信网关等大容量设备的处理能力后，建议在本期工程中，采用两台SunV490（4CPU、16GRAM）作为系统的主处理服务器。
两台服务器通过VeritasClusterServer软件实现互备的结构，确保在一台设备出现故障的情况下，日志信息的入库、查询、统计等操作可以正常地进行。
对于每天过亿条的日志和话单入库，对磁盘阵列的IO吞吐速度要求非常的高，我们建议在本期系统中配备一台EMCCX300光纤磁盘阵列作为系统的外部存储设备，负责日志和话单信息的存储。
系统拓扑示意如下：
4.5自动巡检系统
∙管理界面
o用户管理（权限）
o配置数据（数据字典）
▪任务配置灵活
▪相关的巡检任务和站点相接合
o巡检结果查询
o告警通知，短信通知用户
o结果收集模块
∙数据采集
o短信中心日常维护项目的采集
4.6CDR转换工具
∙系统只支持SMSC7.0；
∙做一个带有图形界面的小工具，用户可以使用该工具将指定的CDR文件从Binary格式转换成纯文本方式；
∙该工具需要能够跨平台，可以支持Solaris和Windows；
∙用户能够在GUI中指定需要转换的CDR文件；
∙转换完后的CDR文件内容要能够显示在界面上，并且同时显示每一列的列名；
∙用户可以将转换后的结果保存成以特定分隔符分割的纯文本文件；
∙在GUI上提供类似文本编辑器的“查找”、“查找下一个”等功能；
4.7CDR计费文件存放
参考数据：
序号
内容
1
目前，河南有17台短信server，再扩容8台，共计25台。
2
在每台短信server上，每隔1分钟生成1个计费文件，这个计费文件的最大字节数目前定义为1050616字节。
3
计费带要求保存1个月。
需要的磁盘应该为：
1050616×25×60×24×30＝1.13T，同时再考虑500G空间的富余。
因此建议在上面集中日志查询的系统EMCCX300磁盘阵列中增加8块300G硬盘，做2个3+1备份，完全可以满足上面的需求，不用另外配置服务器，其查询功能集成在统一网管WEB界面中。
4.8集中数据制作
未了满足客户维护的需求，本次提供集中数据制作功能，进行集中配置，解放维护人员的工作，集中数据制作功能如下：
∙对普通配置文件多主机分发并发更新（如xnc_rules_orig_int.cf）；
o支持目的号码、应用的源和目的、CUG
∙对存储在数据库中的配置信息进行配置和更新（如Asesubscriber表）；
o支持ASE数据库自动更新配置
∙支持对不同短信中心含有不同配置项的配置文件进行配置（如ysrmanmx.cf）；
∙在更新前，对系统中原有的配置进行备份。
4.9统一网管界面
∙用户可以通过统一的WEB界面维护管理整个短信网元
o统计报表系统；
o自动巡检系统；
o集中日志查询系统；
∙支持多用户同时接入查询
∙查询速度比现在版本有很大的提升
由于集中数据制作系统是一个应用程序，图形界面不是以WEB方式生成，所以无法与其他系统集成在一起，可以单独运行。
5.
诺基亚短信中心版本SC7.0介绍
诺基亚短信中心今年将升级到新的软件版本SC7.0，新版本除了在容量性能指标有很大的提高以外，还具有以下一些特点：
•向基于IP的短消息服务演进
•提高硬件的使用效率
•灵活地增加新功能
•适合不同的网络类型
•简化网络操作和管理
而且软件结构也作了大的改变：
•三个相对独立的功能单元：
电信接口，消息处理核心，应用接口
•SMSCenter7.0版本将众多的消息处理功能分散到多个较小的进程
•对称的消息处理结构，使应用接口、电信接口共享众多的消息处理功能
•管道化传送带结构，不同的消息处理功能进程通过统一接口通讯
•消息处理功能以插件的方式接入系统
•未被选购的功能不必占用系统资源，提高资源使用效率
•缩短新功能的开发周期
由于新的软件版本提供了更强大的功能，对短信中心硬件处理能力的要求也相应提高。
现有短信中心的HPL2000需要硬件更新，产品线推荐使用HPRP4440。
5.1诺基亚短信中心硬件设备：
HPrp4440
HP9000RP4440服务器系列拥有在企业应用服务器中所期望的全部高可用性特性，而且其出色的服务器设计使安装、升级和维护变得轻而易举。
HPRP4440服务器将强大的PA-8800处理器与创新的HPzx1进行了完善集成。
这降低了内存延迟和增加了内存带宽，从而使这两种系统获得了更高的性能。
HPRP4440采用了HP-UX11i这一安全、强大且极负盛名的企业UNIX操作环境，可以提高生产力、提高灵活性，并为企业增长奠定坚实基础，同时保持长久的价值。
硬件可配置数据列举：
∙处理器:
2to8xPA-8800800MHzor1.0GHzprocessors
∙内存:
Upto64GBDDRmemory
∙磁盘:
Upto2x36GB/73GB/146GBHotPlugUltra320SCSI15krpmdisks
∙12.8GB/smemorybusbandwidth
∙6openPCI-XexpansionI/Oslots,hot-plugcapable
∙共9个IP端口（内置1个，两块网卡各4个）
5.2Nokia短信中心SC7.0主要新功能描述
5.2.1Fast-forwardMT--MT短信快速下发功能
数据库的事务处理能力是影响短信中心处理能力的瓶颈之一，MT短信快速下发功能有效的减少了数据库的读写次数，增加了短信中心的处理能力。
其具体流程如下：
∙第一次短信提交，可以直接发送给接收方，而不再需要存放在SMSC的数据库中；
∙如果第一次短信提交失败，短信就从内存中找出，存放在排队队列数据库中下次重试；
∙所有短信处理功能都保持可用，不需要另外的路由设备；
∙同一台硬件服务器能够提供更高的处理能力；
∙对事件日志和CDR的产生进程透明。
MT短信快速下发功能适用于短信中心所有基于路由、限制、计费和号码转换功能的短信。
然而由于某些特殊短信需要进行数据库数据处理，因此对这些短信该功能要关闭：
有级连短信、PID替换、延迟发送短信和安全鉴测存档短信等。
建议河南移动采用该功能下发短信，提高短信下发的速度，增加硬件利用率。
5.2.2MAP/SIGTRAN接口
SIGTRAN接口是3GPPR4制订的IP骨干网承载MAP信令的标准协议。
NokiaSMSCSIGTRAN方案采用SIGTRAN信令单元（SSU），该单元使用IP局域网卡相连。
NokiaSMSCSIGTRAN方案兼容以下规范：
∙IETF规范:
∙M3UA：
IETFRFC3332
∙SCTP：
IETFRFC2960
∙3GPP规范：
TS29.202
在SC7.0中，NokiaSMSC与GSM/GPRS/3G的连接方式可以有三种：
1.基于TCP/IP的SMRSE方式
2.
基于SS7的MAP方式
3.基于IPLAN的MAP/SIGTRAN方式
其中，基于IPLAN的MAP/SIGTRAN方式是SC7.0新增的一种接口，它使用了专用的SIGTRAN信令处理硬件，使SS7信令栈在隔离的环境运行。
这种纯IP解决方案保证信令处理能力，同时使用了高可靠的硬件连接。
从目前TCP/IP连接的SMRSE接口演进到TCP/IP连接的SIGTRAN，其优势在于：
•无需改变现有的IP（SMRSE&TCP）网络结构
•无需升级整体核心交换网络支持SIGTRAN
•只需要升级和短消息中心直接相连的交换机（M12和M13均已支持SIGTRAN）
•核心交换网络可以分阶段进行升级
•MAP处理从移动交换机转移到短消息中心
•降低移动交换机的处理负荷
•移动交换机进行MTP层信令转换
•短消息中心可以直接与HLR相连
•同时享受SMRSE/TCP和SIGTRAN的优势
•SMRSE/TCPMO方向的负荷分担依然保持，
升级会员 