林蓓，李春梅，李秉智 重庆邮电学院
摘 要：七号信令网是电信网的重要组成部分，其运行质量直接影响到电信网及其各种业务的运行稳定性和实际效益。为了保证七号信令网的正常高效运行，七号信令集中监测系统已成为七信号进行集中监测和管理的重要工具，文章在分析七号信令集中监测系统框架的基础上，提出了在系统中建立多个数据库和数据仓库相结合的方案进行数据管理，然后对数据管理系统的组成结构、逻辑结构、数据存储与应用做了进一步的研究。
关键词：七号信令；数据仓库；关系型数据库
0 引 言
七号信令网是电信网的三大支撑网之一，是电信网的重要组成部分，是发展综合业务、智能业务以及其他各种新业务的必备条件。到目前为止，我国已经组成了由高级信令转接点（HSTP）、低级信令转接点（LSTP）和大量的信令点（SP）组成的三级七号信令网，使得七号信令网真正成为名副其实的电信网的神经网和支撑网。为了保证七号信令网的正常高效运行，七号信令集中监测系统作为对七号信令进行集中监测和管理的重要工具应运而生。七号信令集中监测系统通过直接采集七号信令的原始数据进行分析处理，提供对七号信令网实时动态监测，以及各种用户信令的各种微观分析［1］。目前，七号信令集中监测系统的功能模块已覆盖了固定电话网和GSM移动通信网的所有信令监测项，并正在向GPRS和CDMA移动通信网的集中监测进行功能扩展。
在七号信令网的监测中会不间断地产生大量的业务数据，为了完成对这些数据的有效管理，建立数据库则必不可少。对于单个信令点监测可采用关系型数据库，因这已是很成熟的技术，故对孤立的单个信令点或信令转接点的监测易实现，但对于涉及全网的监测和复杂查询，就需要使用数据仓库技术对来自各单个监测点的结果进行综合，并由它来对涉及多个点的信令业务进行监测显示。如何应用数据库与数据仓库技术结合来解决多级信令网监测中的数据管理问题将是讨论的重点，在提出自己的实施方案后，将围绕它在数据管理系统的组成结构、逻辑结构、数据存储与应用上分别论述。
1 集中监测系统总体结构
系统总体设计采用自顶向下的综合设计方式，在系统实现上采用自顶向下及自底向上相结合的开发方式，总体采用层次模块化结构。
七号信令集中监测系统通过采集原始信令信息，实现从单个局站到省市级信令网的集中监测。为了完成系统的实时监测和告警显示功能，监测系统划分为信令采集子系统、节点机及其挂接的查询终端子系统、中心站及其挂接查询终端子系统（见图1）。各子系统间的通信连接视其远近可采用局域网或广域网，在广域网中通信两端使用网络通信中间件，以保证各种业务应用在不同系统平台之间稳定可靠，完整地传送、交换数据信息。
采集子系统主要由多个信令监测子架构成，完成数据采集与数据预处理的功能，并将预处理的数据送往节点机服务器中。
节点机及其挂接的查询终端子系统中，节点机服务器通过局域网与多个信令监测子架相连接，对采集的信息进行分析处理后，生成记录，交由数据库管理，同时监控与中心站服务器间的数据传送，而该节点机所挂接的查询终端作为数据显示的前端部件，完成较小信令网范围内的各项系统功能。
中心站服务器通过广域网从各个节点机接受数据，进行综合分析和汇总处理，在数据仓库中保存全网的业务记录，并将记录提供给其挂接的查询终端，生成图形显示，另外中心站还提供与其它管理系统进行信息互通的功能。
2 集中监测系统中的数据库设计
2．1 数据库与数据仓库组成的数据管理系统
七号信令集中监测系统的数据处理采用分层结构。若信令监测子架中完成的数据预处理为第一层；节点机服务器上的数据库就为第二层；中心站服务器上的数据仓库为第三层。除了第一层外，其它两层都用于完成数据管理。在每个节点机中完成数据的初步分析，生成各种关系的记录，并保证一定数量的客户端的实时查询要求，有必要在其上建立一个独立的关系型数据库。而中心站主要对各节点机数据库中的记录进行抽取，合成全局模式下的记录，并满足客户端的联机分析处理要求，这可以通过在中心站中建立数据仓库来实现。
在节点机中要选择合适的数据库产品，目前的关系型数据库产品主要有大中小3种类型。大型关系数据库有oracle和DB2，中型关系数据库有Microsoft的SQLServer，小型的有Access和VisualFoxpro，大型关系数据库在安全性、稳定性及多用户并行处理性能方面比中小型数据库有明显的优势。节点机需要对信令点进行不间断的监测，这要求系统有较高的稳定性；并且数据更新与多客户端显示查询会交织产生，因而需要数据库管理系统有很强的并行处理能力。此外，大型关系数据库产品的开发工具包中还提供了C／C＋＋、Java、sql等应用编程的跨平台通用接口，这无疑增强了系统实现上的多样性与可移植性［2］。中心站连接多个节点机组成星型结构，可将多个节点机中收集来的呼叫信息加以识别与合成，来产生全网监测的呼叫业务消息。并且，这些全网监测信息在产生后就不再更改（除了超过五年的数据要清空外），同时所连接客户端提出的是联机分析处理（OLAP）请求。这就要求将多个节点机中的消息按统一格式存储于中心站上，所以将各节点机作为数据源，在中心站上建立数据仓库是完成本系统监测任务的要求。
由多个大型关系数据库与数据仓库构成的星形结构数据管理系统有以下优点。
（1）层次化的管理结构，节点机上大型关系数据库为第一层，完成对本节点所监测的原始信令信息与分析所得的关系元组的管理；中心站数据仓库为第二层，完成对各节点机的消息的集中式管理；
（2）较强的事务处理能力，用节点机对客户端的单点查询与更新要求作出有效回应，用中心站数据仓库满足客户端对全网联机分析处理（可被视为长事务）的要求。
2．2 数据存储的逻辑结构
2．2．1 节点机数据库上的关系集合与组织
节点机直接监测信令点，故节点机上数据库中的关系集合最复杂，按各种关系的用途与内容可将其分为以下3类。
（1）首先数据库中需记录所监测的信令点、信令链路、信令采集子架和节点机本身的信息，这类型关系元组的正确生成是信令消息成分的提取和客户端的查询的先决条件。
（2）七号信令系统本身是由具有类似OSI层次化模型的多层协议所构成。以GSM系统为例，从实现应用层功能的MAP，CAP，INAP协议，到实现表示层、会话层功能的TCAP协议，一直到实现传输层功能的SCCP协议和实现网络层、数据链路层、物理层功能的MTP协议，每种协议都有其固定的数据包格式，而上层产生的数据包又被下层的数据包所封装。实际采集到的一条完整的信令消息嵌套式地包含了多种协议的数据包包头和终端的用户信息，所以分析一条完整的信令消息可以得到对应不同协议的各个关系的元组。这类的关系集合实用于协议初步分析的结果保存。
（3）第三类关系集合用于对信令消息的进一步分析和记录保存，并且可以分为两类：一类是将多条信令消息按一次呼叫过程或其它某种信令过程相结合所分析得出关系元组，这类关系元组有些是描述了TUP，ISUP的详细呼叫记录，有些则记录了应用层协议（如MAP、CAP、A接口）的详细事务，通常这类关系集合也是中心站数据仓库需要的逻辑模式；另一类关系集合是在单条信令消息分析时，将数据链路和各协议层所出现的错误信息提出，生成多种告警关系。该类关系对实时系统监测是十分重要的。
2．2．2 中心站数据仓库上的存储结构
客户端在对中心站的事务请求中关心的是较长时间段内信令点间的信令消息交互的情况，而不是某时刻单条信令消息的分析结果。故数据仓库中的数据就可以保持较高的密度级，而由各个数据库存放信令消息分析的细节。具体而言，中心站将多个节点机中的分析结果抽取合成为详细呼叫记录，并以此为事实表，将信令点记录、信令业务设置、数据入库时间为维表来构成适合联机分析处理的多维数据存储结构［3］。
2．3 数据的更新策略
数据在各节点机的更新主要有2种情况，一是用户在对数据库查询后，对基本设置类表项的更改，这里须考虑给用户所用帐号赋予更新某些对象的权限，并注意多个用户并行地对相同表项提出更新要求时，选用适当的数据库并发控制机制，以满足应用的实时性与并行性要求［4］。另一种更新是持续的大量的信令消息分析后的表项更新，在这种情况下一个表在一小时内会多加入几十万条全新的记录，并且为了保证数据库只保留3个月的数据，还需对当前系统时间的前3个月的数据进行清除。这些更新要求在一天的0点至8点很少外，在其他16 h内都会保持较多数据量的更新操作。此时采用单条数据删除与插入会造成较大的系统时延，一种改进的办法就是利用此类表都采用了入库时间作为主键，将表内的表项按入库时间每小时分一个区来存储，在系统运行时直接把前3个月某小时的数据区整个清除掉，再在新系统的当前时间分区内插入新的表项。如果再配合上节点机服务器的CPU与冗余磁盘阵列，可以使此类的数据更新有较高的并行性［5，6］。
中心站的数据仓库中数据的更新是在特定时段内完成的，而在较长时段内的数据仓库主要在处理客户端的复杂查询。这就决定了数据仓库中的数据虽也具有一定的实时性，但比节点机数据库中在信令网运行时同步产生的数据就有一定滞后，不过这种滞后尚在系统应用许可的范围内。因此我们就选择在每日的0点至8点（即节点机数据库中很少有新数据入库的时候）对各节点机数据库中的数据进行抽取合成，将产生的综合数据放于数据仓库中，到时也会将超过5年的过时数据清理掉。
2．4 数据仓库的应用实现
系统在用于信令网监测的实施时，对信令网管理用户提出的联机分析处理任务可由客户端、中心站共同来完成。这其中数据仓库的建立，本系统采用了并行关系数据库来作为数据仓库引擎，完成数据管理；用中心站应用层软件完成数据抽取；用中心站所挂接的客户端来实现数据表现［3］。数据仓库的应用实现如下。
（1）应用层软件利用中心站与节点机的通信通道连接各个数据库和数据仓库后，在特定时段内将各数据库中的记录查询结果集中于中心站，然后根据源、目的信令点与信令时序分离于各节点机的分析结果排序、整合，待完成生产记录的完整性、一致性检验后，交由数据仓库引擎入库。
（2）数据仓库引擎根据更新表空间在磁盘阵列上的位置，由散列算法算出新纪录的可放入的空闲空间地址，然后跳过操作系统由磁盘控制器直接在多个磁盘上并行写入新记录，另一方面，当数据仓库引擎接受到查询请求，会根据合理的查询计划，利用磁盘阵列并行地读出符合要求的记录，数据仓库引擎由此完成数据管理的基本任务。
（3）客户端选用适合信令网管理的数理统计方法，将数据仓库中查询的结果进行统计，并算出指点网段的性能监测参数，再以表格或直方图的形式表示出来，以此完成数据仓库的数据表现。
3 数据管理系统特性
通过对七号信令监测系统的组成成分的分析，选择了在节点机和中心站上建立数据库和数据仓库，由此构成了适合系统要求的数据管理系统。对于所设计的数据管理系统，具有以下特性。
（1）系统商业化程度较高。无论是节点机上的大型关系数据库还是中心站上的并行关系数据库都是完善的数据库产品，它们的管理系统由紧密结合在一起的各功能模块组成，包括编译器、执行引擎、并发控制、日志管理、缓冲和磁盘管理器等；除了能够快速执行用户的数据定义和数据管理请求外，还能顺利地完成日志管理、数据库备份和恢复等工作。
（2）较强的查询能力。为了系统的高可用性，可以同时运行数据库服务器的多个实例对一个数据库进行访问。并可将用户的查询细分为全网综合查询与单信令点查询，并在中心站和节点机上分别完成。
（3）数据库的完善安全机制。数据库系统能够严格控制数据与存储资源的分配使用，并对用户进行权限管理，对数据库系统内部活动进行审计。
（4）较好的应用扩展性。由于设计了以中心站数据仓库为中心，结合多个节点机的关系型数据库的数据管理体系，在系统监测对象由GSM变为GPRS或者是CDMA时，只在节点机和中心站更新协议分析模块即可完成监测系统的平滑升级。
参考文献
［1］ VI．0－2000．GSM七号信令集中监测系统技术规范［S］．
［2］ 厄曼（美）．OracleqiPL／SQL程序设计［M］．陈维军译．北京：机械工业出版社，2002．
［3］ 邓苏．数据仓库原理与应用［M］．北京：电子工业出版社，2002．
［4］ 廖朝晖，张鹏珊．并行数据库系统目标、体系结构及研究方向［J］．计算机科学，1994，21（6）： 23－28．
［5］ HECTOR Garcia－Molina．Databse SystemImplementation［M］．U．S．A，Prentice HallPress，2000．
［6］ STEVE Bobrowski．Oracle8 Architecture［M］．U．S．A，Oracle Press，1998．
［7］ 席海峰，蹇洁．中国七号信令网及其集中监测系统［J］．重庆：重庆邮电学院学报（自然科学版），2000，12（2）：51－53．
［8］ 张治中，张云麟，程方．七号信令实测方法［J］．重庆邮电学院学报（自然科学版），2000，12（2）：38－40．
摘自 重庆邮电学院学报
|
