移动综合网管范文

移动综合网管范文（精选7篇）

移动综合网管 第1篇

1 数据整理及数据库构建

爱立信和中兴设备配置数据、性能数据格式存在差异, Counter定义不尽相同, 必须对数据格式进行整理, 完成Counter级数据整理, 形成统一指标数据集。

根据集团公司配置参数及性能指标规范, 需对各厂家约2000个Counter级数据进行梳理, 根据规范编制指标公式, 形成指标级数据, 最后形成爱立信指标145个, 中兴指标178个, 在此不做详述。

2 网络性能评估与自动化体系构建

2.1 网络性能评估体系构建

根据整合完成的指标集, 进行报表级数据据整理, 构建性能评估体系, 将网络性能评估分为四大类:

1) 网络接入性能评估:评估用户接入无线网络的难易呈度, 从寻呼性能、语音和数据的接入性能等角度进行评估。

2) 网络保持性能评估:评估用户接入网络后持续通话或使用数据业务的稳定性, 从语音掉话和数据掉线两个角度进行评估。

3) 网络移动性能评估:评估用户接入网络后连续移动过程中保持通信的能力, 从网络切换性能进行评估。

4) 网络资源性能评估:评估网络资源忙闲、质量情况, 从网络话务量、数据流量、网络负荷、干扰状况等角度进行评估。

2.2 自动化体系构建

2.2.1 参数自动核查

根据预先设定规划, 对网络小区参数进行核查分析, 解决手工检查效率低下的问题, 发现网络参数设置问题, 名括:1)

1) 频率核查

在网络频率规划应严格禁止同邻频在本小区和本站或邻区的使用, 但往往会由于规划失误或优化失误造成问题, 由于数据量庞大, 依靠手工识别非常困难。根据采集的网络配置信息, 可交由系统自动对小区内邻频问题;同站同频、邻频问题;邻小区同频问题进行检查, 发现一般性错误。

2) 邻区核查

网络中每个小区的邻区一般在15个至20个, 甚至更多可达到32个, 全网的邻区量达15×N (N为全网小区数) , 如出现问题对网移动性和整体性能均会产生重大影响。需要系统自动对切换和重选问题进行检查, 对邻区定义参数错误、单向邻区问题进行检查, 以纠正问题。

3) 参数一致性核查

对全网参数进行分类检查, 识别参数不同取值的使用率, 对使用率低的参数进行提取, 以发现网络中不规范的参数应用, 解决网络参数一致性的问题。

4) 参数变化跟踪

在日常的网络优化工作中, 参数变化频繁, 应可能跟踪参数变化, 以掌握其对现网性能影响。

2.2.2 指标自动监测

通过对性能报表自动提取分析, 对越限小区指标自动产生告警, 并通过短信发送到相关包机人进行处理, 提升处理效率。

2.2.3 网络扩容分析

对小区话务进行分析, 根据扩容门限对小区提出扩容建议并进行跟踪。

3 系统的设计与实现

3.1 系统架构

系统采用B/S结构, 客户端零安装, 方便升级和维护, 便于移动办公。

网管数据处理系统的设计与实现整体上要考虑技术先进性与成熟性相结合的原则, 同时还要兼顾相关行业的发展。网管数据处理系统将采用完全的B/S模式, 基于J2EE技术路线进行设计和开发。

系统应用时, 采用完全的B/S模式, 用户在客户端只需要使用常用的浏览器即可, 不需要安装任何其他软件。

系统中间层遵循J2EE标准, 具有很好的可移植性、可扩展性, 能够跨平台使用。采用多层组件技术。所有的应用软件都是配置实现的, 当用户业务发生变化时, 不需要重新编码, 只需要修改相应配置即可实现。

J2EE技术的基础是Java语言, Java语言的与平台无关性, 保证了基于J2EE平台开发的应用系统和支撑环境可以跨平台运行。依据采用的J2EE技术路线, 网管数据处理系统设计采用客户端基于浏览器、Java技术、开放的三 (多) 层应用体系架构, 包括表现层、业务逻辑层和数据层三大独立的组成部分, 各应用层次之间互相通信, 结构灵活, 且不依赖于底层的硬件环境。

3.2 支持系统设计

3.2.1 ETL技术工具

ET作为BI/DW (Business Intelligence) 的核心和灵魂, 能够按照统一的规则集成并提高数据的价值, 是负责完成数据从数据源向目标数据仓库转化的过程, 是实施数据仓库的重要步骤。

ETL工具有像Ascential公司的Datastage、Informatica公司的Powercenter、NCR Teradata公司的ETL Automation等ETL产品提供了较为全面的解决方案。网管数据处理软件相对数据业务逻辑相对简洁, 主要是将爱立信及中兴等厂商的业务数据转换到Oracle数据库, ETL过程相对较少, 数据之间没有复杂的逻辑偶合如:依赖关系、出错控制以及恢复的流程处理。

因此对网管数据处理系统ETL部分采取本公司基于开源软件基础研发的ETL工具, 能有效的解决目前的源数据处理过程。对数据到数据仓库的转换, 采用Oracle本身提供的存储过程进行数据整理。

作为数据集成ETL, 其在数据处理上主要应该遵从以下几个步骤过程:

1) 异构的多数据源处理

能够尽可能的接受多种数据源, 异构数据源。即除了对三种基本类型的数据库 (本地数据库、外部数据库即较流行的能进行索引顺序访问方法访问的数据库、ODBC数据库即客户-服务器类型) 能全部支持外, 对应用数据、外界的电子商务数据、未知格式文件数据等亦能很好的处理。

2) 通用数据访问数据接口

能够跨平台、跨网络访问数据, 能支持不同类型数据源间的连接, 通过屏蔽各种数据源之间的差异, 为后序提供一个统一的数据视图, 目前已有多种可选的通用数据接口, 如ODBC/OEDB/JDBC等, 其中JDBC支持跨平台、网络访问数据。

3) 数据抽取

数据抽取包括模式数据和实例数据抽取。首先从数据源中抽取模式信息, 用人工或相关的智能算法加以分析, 得到实例数据的抽取策略, 存储在知识库中供装载数据时使用。抽取模式信息的合法性是保证数据质量的关键。此过程还应该尽量使用增量式的抽取算法, 避免对庞大的多源数据集进行昂贵而费时的重复扫描, 以保证数据处理的效率问题。

4) 数据集成

数据抽取后得到的是多个模式和实例数据集, 然而数据仓库需要的是集成的、语义一致、面向对象的数据, 故此必须将多模式与数据集进行统一映射, 转换为单一的结果集。此过程依据数据语义、语法、结构将不同数据元素化, 得到格式统一的数据结构;进而进行数据标准化, 消除不一致性的缩写、简写等;然后进行数据的一致性校验;在内容上修改各种错误, 最后将处理后的数据作为中间结果存储临时区域中, 等待进一步的清洗。

5) 数据规约

经过数据集成后的数据集中还包含许多相似重复记录, 因此必须消除这些严重影响数据仓库的语义一致性的数据。针对数据集进行匹配, 发现重复异常, 根据匹配结果进行处理, 删除部分记录或者将多个记录合并为一个更完整信息的记录。

6) 数据装载

此过程解决模式实现以及数据装载时机等问题, 能够有选择的转载到一个或多个目的数据表中, 并允许人工干预, 以及提供强大的错误报告、系统日志、数据备份与恢复功能。

7) 目的数据存储

提供数据与元数据的存储场所, 是ETL的终点, 一般为数据仓库。同时为了考虑整个数据集成和数据仓库的严密性和整个系统的强大功能的实现, 必须配备强大的辅助管理工具。可以进行工作流管理、作业调度、日志管理、系统运行状态监控、数据备份还原、系统错误处理等辅助于系统的操作。此外为了系统以后的发展或者升级, 应该为程序员提供强大的编程接口, 使数据ETL软件能够与其他的企业软件实现系统级别层次上的集成。为了获得更好的交互性与可扩展性, ETL工具应该提供类SQL的描述性语言, 方便定制高效执行的数据处理流程。

3.2.2 数据库及数据仓库

网管数据日数据量达到1.3G/天, 年生产数据达到474G/年。生产数据量庞大。对这些数据安全的存储和有效的分析能对数据处理和方案制定提供有效决策支持。因此, 采用数据仓库的方案进行构建。

数据仓库的方案建设的目的, 是为前端查询和分析作为基础, 数据仓库建设必须满足高效率 (每时段数据处理时间短) 、高质量 (数据准确性高) 、扩展性 (报表及数据容理可扩展) 的特点。

3.3 系统模块设计

3.3.1 用户登录模块

对登录用户进行安全检查, 允许有权限用户登录系统, 保证数据安全。系统采用公司内部局域网, 安全性较高。

3.3.2 数据分析、报表模块

实现对指标集和报表集数据的处理、分析和查询, 面向用户提升各种分析报表, 其结构图见图3。

3.3.3 告警模块

1) 网络实时监测

此监测系统包括关键指标的设定平台, 根据设定的指标数值, 当网络中这些指标一旦超时马上给与报警或短信提醒。

2) 事件提醒

此系统可设定事件, 平台根据设定的时间与内容提前一段时间给予提示或短信提醒;

3.3.4 网络优化模块

1) 网络扩容自动化:实现对网络的拆闲补忙的自动分析, 提供拆闲和扩容方案;

2) 网参数检查自动化:对网络参数一致进行检查, 对同、邻频问题、邻区问题进行检查, 提供问题小区。

3.3.5 GIS地图展示模块

根据基站的经纬度和小区方位角信息, 把基站显示在地图上, 然后再把小区和其后台数据库中的数据指标数据、配置数据、工程数据进行连接, 然后根据自己的需要把数据库中的内容有选择的显示在地图上, 其实现见图4。

数学知识自适应学习模式不但可以实现个性化学习, 还可以将归纳学习、解释学习、例中学和做中学等有效学习方式有机整合在一起。该系统的成功研制, 对提高数学学习的个性化、智能化和高效性具有重要的理论和实践研究意义。我们将在该数学知识自适应学习系统基础上, 继续研究学习系统的有效性的实证研究。

4 结束语

移动通信网管数据的综合自动化处理是网络优化发展的方向, 该系统的成功研制, 对提高网管数据处理效率, 网管数据的自动化分析和对网络优化工作提供智能支撑具有重要的理论和实践研究意义。我们将在综合网管数据处理平台系统基础上, 继续移动通信网管数据的挖掘研究。

参考文献

[1]啜钢.移动通信原理[M].北京:电子工业出版社, 2011.

[2]郑岩.数据仓库与数据挖掘原理及应用[M].北京:清华大学出版社, 2011.

[3]戈尔法雪利.数据仓库设计:现代原理与方法[M].北京:清华大学出版社, 2010.

[4]秦婧, 刘存勇, 张起栋.ORACAL PL/SQL宝典[M].北京:电子工业出版社, 2011.

移动综合网管 第2篇

项目范围蔓延及变更在以往的项目实施过程中一直是难以控制的事情。在项目实施过程中, 为了防范范围变更的风险, 在项目组织上, 管理制度上, 实施策略及实施方法上制定了有效的项目范围管理方法, 因而取得了良好的效果, 在浙江移动IP网管项目整个实施过程中, 只在项目实施阶段发生了两次变更, 且并未对整个项目的实施进度产生重大影响。

(一) 项目背景。

经过几年的通信系统建设, 浙江移动数据业务种类越来越多, 网络越来越庞大。目前的数据业务包括基于2G网络的数据业务、也包括基于2G/3G/WLAN的数据业务、针对数据专线的管理等。为更好地管理和运营数据业务及其网络, 浙江移动按照集团公司数据网管系统建设规划要求, 对已纳入管理范畴的数据业务, 实现了基础管理功能和业务管理功能, 达到了“集中监控、集中管理和集中维护”的三集中要求。随着3G、LTE、全业务运营竞争的全面开展, IP技术正在以实用化的方式强化其在网络技术中的主导地位, IP数据网网络扩容速度越来越快, 而在其之上开展的各项业务也将进入一个崭新的快速发展阶段。数据网管面临着从面向企业级承载到面向电信级承载、面向业务、面向客户的改造要求。随着数据业务的蓬勃发展和数据网络维护的精细化, 新的数据设备和业务系统不断涌现, 对网络支撑手段的要求越来越高;同时, 数据网络的安全问题有所凸现, 网管系统的安全组网调整势在必行;另外, 随着各类网管支撑系统建设的不断深入, 对于网络支撑系统体系架构的规划和调整也提上了议事日程;正是由于上述情况的出现, 原有的IP网管系统已无法满足需要, 进行IP网管系统二期建设的要求已经日益迫切。

(二) 系统环境。

网管系统中原先包含的主机设备包括2台Sun FIRE V880服务器 (8CPU) 、2台Sun FIRE V480服务器 (2CPU) 、1台PC SERVER、1套磁盘阵列和1套磁带库。二期硬件扩容设备包括:在网管中心增加了2台Sun Fire V890, 配置为8CPU、32G内存, 其中1台作为应用业务服务器, 1台安装资源中间件软件;在DMZ区还需新增1台CISCO 3550交换机, 用做停火区内的数据以及核心生产区主服务器的数据交换;同时需增加5台HP DL380G4作为二期新增私网业务系统的数据采集。另外, 在一期配置的两台880和二期新增的890这三台服务器之间进行软件装载的均衡分担;原先的作流量采集的v480移至DMZ区, 继续用作对netflow数据的采集和分析, 另外一台v480上安装的程序移至主服务器上, 并把该设备移至DMZ区, 用作对公网的配置、性能数据采集之用;原先配置的作拓扑发现用的PC SERVER移至DMZ区, 继续作资源发现用。

(三) 项目效果。

2011年中国移动浙江公司数据网管系统已经实现故障管理、性能管理、拓扑管理、报表管理、业务管理、流量管理、集中操作维护等功能模块, 同时实现了IP承载网质量监测与专家系统、WLAN管理、局数据管理等新增功能模块用于提升维护效果, 有效地支撑了浙江省在2011年对WLAN、BRAS、IP城域网、WAPGW、GPRS、IMS商用平台等网络进行大规模扩容带来的新的管理需求。目前, 数据网管已经成为浙江省数据网集中监控、集中维护、集中管理和智能维护的唯一支撑平台, 它在集中化维护中的重要作用日益彰显。东方通信自从2010年8月开始实施浙江移动IP网管项目以来, 经过浙江移动的大力配合, 到2012年12月为止, IP综合网管系统已经能够满足网管人员的日常工作需要, IP网管系统能够为浙江移动提供:告警、资源和性能数据的集中管理, 提高IP网络运维效率;进行网络性能分析, 实现网络运行质量的量化管理;实现网络资源的汇总和管理, 合理配置网络资源, 提高资源利用率;实现业务质量的分析和保障, 改善网络服务质量, 提高竞争能力。

如此高效的项目实施效率得益于项目组全体成员和客户的努力工作, 但有效的项目范围管理无疑奠定了项目成功的基础。

二、解决方法

(一) 项目启动阶段的范围管理。

1. 分阶段的实施策略。

浙江移动IP综合网管二期建立在网管一期的基础上, 根据浙江移动和集团公司的要求, 增强和完善了IPNet Manager软件架构的基础组件和业务组建, 全面提升IPNet Manager的网管层次, 提供面向业务、面向客户的网络管理系统。浙江移动IP综合网管二期实施方案, 主要的重点是在尽可能保证服务可用性的前提下, 把IP综合网管从一期平滑地升级到二期, 同时使数据尽可能少丢失以及升级以后二期系统功能的可用性。因此采用三个阶段来实施, 第一阶段是二期系统搭建;第二阶段是一期、二期系统并行;第三阶段是一期系统下线、二期系统正式投入生产运行。

2. 由用户参与的项目组织结构。

为了便于项目的成功实施, 项目组成员包括:东信公司的工程实施项目经理、技术支持部经理、软件开发部经理、系统工程师2名、实施工程师2名、浙江移动公司的项目负责人、系统支持室经理等。在项目实施过程中, 浙江移动公司的项目负责人参与关键事项的讨论及决策, 包括项目的进度、范围、测试标准等, 在本项目的验收阶段, 浙江移动项目负责人负责和浙江移动相关部门的协调沟通, 并且负责相关模块的验收。浙江移动公司的项目负责人全职参与本项目的实施过程, 并成为项目中坚力量。组建由用户参加的项目组织结构, 不仅增加了实施人员与用户沟通和交流的机会, 使用户在与项目实施人员一起工作的过程中充分了解项目的范围, 实施进展, 面临的问题及其解决方法。而且在共同工作的过程中对项目的实施形成了共识, 并为同一目标共同努力。避免对项目范围及进展产生理解上的差异, 有利于项目的顺利实施。

3. 充分的需求分析调研。

软件需求分析是准确确定项目范围的基础, 为了保证用户需求分析的全面, 准确。在向用户进行需求分析调研时, 我们首先制定需求分析计划, 明确规定需求调研时间, 用户参加人员, 调研内容, 实施人员;同时要求各个实施人员依据项目背景资料及以前其他项目的实施经验做好需求调研准备, 认真编制需求分析问询表, 详细列出调研问题提纲。以避免在调研过程中遗漏相关内容;在调研过程中实施人员对用户进行启发和诱导, 使用户能有条理, 系统地描述需求, 并在调研中详细记录调研问题的答案。在此基础上编制用户需求说明书。

鉴于需求分析对软件项目的重要性, 本次项目的需求获取采用了多种方式:一是和直接使用的用户进行交流, 获取第一手需求信息;二是与网络规划部门的人员进行交流, 获取系统的发展方向;三是和移动的业务部门进行沟通, 获取项目的范围。

为使项目高效运作, 应仔细根据所有涉众的需求确定优先级, 并对项目规模进行管理。有的开发人员仅仅重视所谓的“复活节彩蛋” (即开发人员感兴趣或觉得有挑战性的特性) , 而不是及早将精力投入降低项目风险或提高应用程序构架稳定性方面, 这已使太多的项目蒙受损失。为确保尽早解决或降低项目中的风险, 应以递增的方式开发系统。要慎重选择需求, 以确保每次增加都能缓解项目中的已知风险。要达到目的, 需要和项目的涉众协商每次迭代的范围。通常, 这要求具备管理项目各个阶段的期望结果的良好技能。除了控制开发过程本身, 还需控制需求的来源, 并控制项目可交付工件的外观。

本次收集的需求相对比较多, 因此需求整理与确认非常重要, 小组成员中专门派一个人负责需求的整理和确认, 为需求评审提供基础。

定义需求时无论怎样谨慎小心, 也总会有可变因素。变更的需求之所以变得难以管理, 不仅是因为一个变更了的需求意味着要花费或多或少的时间来实现某一个新特性, 而且也因为对某个需求的变更很可能影响到其他需求。应确保赋予需求一个有弹性的结构, 使它能适应变更, 并且确保使用可追踪性链接可以表达需求与开发生命周期的其他工件之间的依赖关系。管理变更包括建立基线、确定需要追踪的重要依赖关系、建立相关项之间的可追踪性, 以及变更控制等活动。需求分析包括客户需求分析和评审、方案整体性设计、方案可行性分析、需求最终确认、通过评审及建立需求基线等。客户需求分析、评审建立在需求获取和整理的基础上, 对客户的需求进行评估, 最终确认哪些需求属于本次项目范围之内。根据评审过的客户需求, 进行方案整体性设计, 同时进行可行性分析, 一旦完成方案以后, 进行项目需求的最终评审, 评审结束以后, 建立需求基线, 以后需求的变更以此为基础。提交双方确认过的软件/系统需求规格说明书。

(二) 计划阶段的范围管理。

合理, 精准的范围定义是项目范围管理的基础, 在范围计划阶段, 我们采取了以下措施, 以保证项目范围的精准定义。

1. 制定范围计划。

在对系统进行需求获取和需求分析的基础上, 明确定义系统范围, 这是整个项目管理的脊梁。在实施过程中, 我们首先制定范围说明书。在范围说明书中明确定义项目范围, 各阶段的交付物, 采用的实施方法, 并对相应功能进行细致描述, 避免理解上的二义性。

2. 范围定义。

在范围说明书的基础上, 我们采用由上而下的方法, 按照项目的不同阶段划分WBS。范围细化至每个特定的功能。使得分解后的任务可管理, 可定量检查。使项目实施人员有章可循, 同时便于项目经理在不同阶段有效控制中间成果同时不至于陷入到项目细节中去。

(三) 各个阶段执行过程中的范围管理。

1. 项目例会制度。

为了加强对于项目进度的有效监控, 对重要问题及时作出决策, 对项目的成果和问题及时通报, 建立了浙江移动IP网管二期项目例会制度。通过项目例会制度, 用户与实施人员之间不仅进行了充分的沟通和交流, 而且用户不断对项目范围及已经取得的成果进行确认。避免了在项目实施后期范围变更的巨大风险。具体例会安排如下:每日由项目经理主持的, 项目实施人员参与工作日早会;每周由项目经理主持的, 项目组全职人员参与的周例会, 会议内容为以下几点:一是各小组本周进展通报、问题清单通报、下周主要工作、提交需讨论的问题;二是项目支持组对项目管理问题的通报;三是重要问题讨论。

在项目的每个阶段性开始点, 由项目经理组织, 项目组全职人员及兼职人员参与的项目阶段例会, 内容为:一是上阶段目标、成果回顾;二是下阶段目标、计划的宣贯;三是工作任务的分配。在出现需要决策的关键问题, 对项目进度有重要影响的时候, 由项目经理发起, 浙江移动项目负责人、实施项目经理及相关人员参与的关键为题决策会议, 会议内容如下:一是问题的背景介绍;二是问题方案的分析。在项目阶段结束时, 由项目经理发起, 浙江移动高层领导、业务部门经理、项目管理组、各组组长参与的项目组阶段成果汇报会, 会议内容如下:一是阶段成果汇报;二是对各部门资源配合的需求。

2. 各阶段交付物的确认。

为了在项目各阶段有效控制项目范围, 提供有效表示项目各阶段的成果的交付物, 并由用户确认, 以评估是否正确和满意地完成了各阶段的任务, 在项目过程中不断核实项目范围。在该项目实施过程中, 在项目实施的各阶段我们提供了以上交付物由用户确认, 在上一阶段交付物确认后, 才能开始下一阶段的工作。在项目启动阶段, 由项目经理交付给移动项目负责人方案建议书, 项目功能范围, 项目实施进度计划的相关文档, 并双方共同签字确认。在项目开始实施的阶段, 项目经理需要交付给移动项目负责人系统安装手册。在项目实施后, 项目经理需要交付系统安装调试记录文档, 系统测试手册;在项目验收前, 项目经理需要交付给移动项目负责人系统维护文档, 系统操作手册, 系统技术手册, 系统验收文档。双方负责人对验收文档进行签字确认。

3. 范围变更管理流程。

为了防止项目范围的无效蔓延, 保证项目顺利, 达到并满足用户需求。对浙江移动用户的范围变更请求, 一律通过书面请求报告来提出, 并经浙江移动项目负责人审核, 实施方项目经理审核, 视不同情况, 作出相应的处理。不涉及整个业务流程修改的变更, 一般给以满足。涉及整个业务流程修改的变更, 则视变更大小考虑是否满足用户要求作不同处理。

三、事后总结

软件项目存在很多不确定因素, 比如用户需求变更、技术升级、环境改变等等, 项目的风险相对比较高, 因此我们在进行项目的时候, 需要充分运用项目管理的知识, 在项目的各个阶段进行科学管理。

移动综合网管 第3篇

目前网络管理系统的建设已是移动通信网络发展的必然趋势。其中网管数据管理存在数据量大、多厂商多接口协议、设备繁多且分散等众多问题。如何将此大量数据以数据仓库的方式进行统一采集、存放、清洗、钻取、呈现,一直以来都是各大运营商在构建网管系统过程中首先必须考虑的问题。

只有解决了以上问题,才能对网络运行状况进行监测,保证网络能够有效、平稳、安全地运行;才能给网络管理人员、分析人员提供充足、完整的现网设备运行数据,制定合适的网络扩容、割接、调整计划,使网络存在可持续发展性。

本文所介绍的数据管理系统主要实现对网管性能数据、配置数据、告警数据这三方面数据的采集、汇总和呈现。介绍过程中由浅入深,从需求材料收集、硬件性能分析及设备选型、系统软件设计、关键技术选型、尤其是解决主要难点比如数据补采集问题。其中也简单讲解了硬件选型过程中服务器性能的计算方法和数据采集技术的比较选型。

2、性能数据管理系统研究与设计

2.1、系统需求分析

本系统的目的是为了满足网络规划人员的需求,实现性能数据自动采集、汇总、检查、呈现功能,使得对网络的整体性能、发展瓶颈的掌握成为可能。该系统的需求大致归纳如下:

1. 性能数据实现自动采集:能够周期性的自动采集数据,采集的周期和采集时间可人为设定。

2.性能数据数据补采功能:当由于传输中断或是性能测量数据上传延迟造成数据漏采或数据采集不完整时,数据采集系统应能够启动数据补采机制进行自动或是手动的数据补采集。

3.性能数据检查:可以检查所采集的原始数据的完整性和一致性。

4.性能采集设置:系统应能对所要采集的数据表的范围、采集时间段、采集地区、采集网元和特定的采集数据进行设置。

5.性能数据采集范围:包括GSM、GPRS、BSS、SMSC、智能网AIP系统、传输系统、动力环境监控系统等。

6.数据存储实现原始数据保存三个月、性能归一化数据保存两年、资源数据永久保存。数据库空间利用率应在70%以下。而且数据存储要有容灾功能。

7.忙时系统CPU和IO的占用在75%以下。

8.具备性能超标预警短信派发功能。

2.2、系统硬件方面设计

2.2.1、系统处理能力估算

计算机工业界目前主要采用TPC组织的TPC-C指标来衡量主机系统的性能。

先确定好网管系统中的主要业务种类如配置数据处理、故障数据处理、性能数据处理、前端应用访问(报表查询等)、内部处理(自身监控等)的业务处理量。然后根据TPC公式计算出以上5种业务处理量所需的服务器性能要求。

忽略应用切换时的性能余量和系统开销,服务器的性能(TPC-C)=30203。(计算过程略)

2.2.2、系统存储容量估算

网管系统的存储和采集满足以下要求:

2.2.3、硬件配置

基于以上服务器处理能力和系统存储容量估算,该系统采用SUN V880(4*1.2G CPU/8G内存/73G*2)做为主服务器,Sun Stor Edge T3(9*73GB Disk)磁盘阵列作为数据库存储器。其中主服务器的两块磁盘作镜像热备,T3磁盘阵列采用RAID5技术。SUN由于在TPC-C上的弱势,因此不推荐使用TPC-C,但是有提供计算公式。

其中主机服务器的性能:

=CPU的主频*11*CPU的个数(如果CPU太多的话,再乘以0.8~0.9)

=1200*11*4*0.8=42240>30203(服务器能力估算值)

系统存储容量方面,因为作了RAID5,所以,存储容量为8*73G=584G>392G。

综上所述,针对目前情况,硬件配置是够用的,而且也利于今后的扩容。

2.3、系统软件方面设计

1.1 采集检查程序

数据采集系统通过采集检查程序比较OSS和数据中心的数据库中,同一张数据表在相同时段的记录数,如果OSS中的记录数大于数据中心的记录数,则将该表该时段的采集列入采集任务列表中,最终生成采集任务表。

1.2 数据采集程序

数据采集程序根据采集任务表中动态生成的采集任务,在OMC和数据中心之间执行"旧数据清除、新数据插入"的操作。

1.3 汇总检查程序

经过汇总检查程序的比较,如果采集任务表中包含汇总配置表中事先定义的需要进行数据汇总的内容,则将其列入汇总任务表,最后进入汇总层。

1.4数据汇总程序

数据汇总根据汇总任务表,对网管数据库内的OSS原始备份表执行"旧数据清除、新数据插入"操作。

1.5历史数据删除程序

历史数据删除程序完成调用存储于网管Oracle数据库中的存储过程(即历史数据删除过程)实现对旧数据的删除。

1.6历史数据删除过程

实现判断并删除网管Oracle数据库中过期的网元性能测量数据。

处理程序、核心配置表和数据管理系统之间的数据流为:

Q1:读取静态的采集配置表,获得需要采集的表名、时段等相关信息。

Q2:读取OSS上之前24小时内,某张数据表各个时段的记录数。

Q3:读取数据管理系统上当前24小时,对应的OSS原始备份表各个时段的记录数。

Q4:经过采集检查程序比较Q2和Q3两者记录数是否相同,如果Q2中的记录数大于Q3的记录数,则将该表该时段的采集列入采集任务列表中,最终生成采集任务表。

Q5:根据采集任务表执行数据采集程序。

Q6:更新数据管理系统的数据,在数据管理系统的OSS原始备份表中插入新数据或是补采集的数据。

Q7:参加汇总检查程序,汇总检查程序从采集任务表中取得当前完成的采集任务。

Q8:参加汇总检查程序,汇总检查程序从汇总配置表中取得预先定义的需要进行汇总的内容。

Q9:经过汇总检查程序比较,如果采集任务表中当前完成的采集任务内包含汇总配置表的内容,则列入汇总任务表,并最后有数据汇总程序进入汇总层。

Q10:参加数据汇总程序,数据汇总程序从汇总任务表中取得汇总任务。

Q11:根据汇总任务表执行数据汇总程序。

配置表和日志记录为:

D1:采集配置表

D2:采集任务表

D3:汇总配置表

D4:汇总任务表

D5:采集程序日志

D6:汇总程序日志

2.3.2、数据采集层技术选型

在现有条件下,数据采集层可以通过各厂家提供的各种接口来分别实现对各个厂家设备的数据采集。包括:

1)移动公布的Q3/CORBA标准接口采集数据。中国移动集团公司已经颁布了Q3/CORBA数据接口标准,一旦各个厂家在其所提供的设备上实现了这一统一接口,数据采集层就可以采用一个统一的通用数据接口模块进行数据采集。

2)移动厂商的OMC数据库中采集数据,也就是平时所说的数据库复制方式。

3)移动厂商的OMC文件中采集数据,即FTP文件方式。

4)可以通过其他的一些方式进行采集,如CMIP代理,直接从MSC或网元中获取。

但是目前除少数几大厂商设备有提供Q3/CORBA标准接口,而且是当作一个额外的功能组件卖给运营商。特别是NOKIA公司目前的2G设备(GSM产品)内部网管接口采用基于CLNS(无连接网络服务)协议的VFS(虚拟文件传输协议)根本就不开放,而我公司95%的设备都是NOKIA产品。因此无论从经济上考虑还是从现网技术上考虑,现在马上启用CORBA标准接口都不是很合适。

因此如图3所示,我们以系统高效运行为目标,采用多种采集方式:

1)鉴于95%的设备为NOKIA设备,而NOKIA设备有提供基于Oracle数据库的OSS。我公司的数据管理系统采用的也是Oracle数据库,两者同构,利用Oracle内部的数据库链接技术进行数据采集,高效又稳定。

2)像中兴、华为等厂家设备占3%左右,其采用的数据库是Sybase、Sql Server。利用JAVA语言的易操作性和JDBC的面向对象功能,进行异构数据库采集事半功倍。

3)针对少数几个电源厂家、传输设备厂家,其设备数量较少,只有提供TELNET协议连接方式或者是FTP连接方式,我们就充分利用这些方式将文本文件格式的性能数据FTP采集过来,再用AWK语言入库。

2.3.3、系统关键算法-数据自动补采设计

无论是采用文本接口的设备厂家,还是采用数据库接口的设备厂家,由于网络或其它原因,性能数据没有及时写入文本中,或者没有及时写入数据库,而在故障排除后会重新传送所有未传送的数据文件或者是入库。如此一来数据采集模块采集到的数据就会产生缺漏。这一由网元层故障或升级引起的缺漏就需要有一个数据自动补采机制来解决。

针对文本接口类型,该数据管理系统是采用每小时的采集周期,只要每次采集之前判断网元上是否有新文件生成即可,若有则进行采集。

但是我公司95%的设备是NOKIA设备,是采用Oracle数据库接口的,如何进行数据自动补采是关系到系统运行是否稳定高效的一个关键因素。

对于当前需要采集的某张数据表,采集检查程序从该表的所有数据记录中,取得采集时间字段的最大值,然后以该时间值为基准点,分别推前一段时间(比如一天),取得进行数据补采集判断的一个时间范围。在这个时间范围内,分别计算每小时的时间段内,该系统的记录数和NOKIA OSS上的记录数:如果记录数相等,说明该时段数据完整;反之若是记录数不相等,则说明该时段数据采集不全,需要进行补采集。如此一来,可以在一小时的范围内保证分散在各地的各大厂商网元设备上的数据与数据管理系统中的数据保持一致。

3、小结

综上所述,该数据管理系统是一个以满足网络规划和优化及设计为主的管理系统,系统同时也承担着网络经营分析、资源和性能预警、网络考核指标生成、重大活动话务预测等多项任务,使得维护人员从繁重枯燥的数据采集整理工作中解脱出来。该套系统的成功搭建,为网络人员提供了千里眼、顺风耳的功能。

摘要：本文从电信管理网络(TMN)规范入手,介绍了配置管理、性能管理等网络管理功能在移动通信网管数据管理系统中的作用。并着重介绍该数据管理系统中的关键技术、需求分析、功能设计。

提升移动核心网网管系统的几个方向 第4篇

移动核心网管理的主要目标是实现移动网络运营管理的标准化和自动化, 保证网络的运行质量, 提高网络资源的使用效率, 快速响应市场和客户, 从而促进业务的发展, 并降低网络的运营成本。

1.1 网络管理功能

目前, 核心网尚未演进到全IP (互联网协议) 阶段, 尽管实现了4G数据接入, 但核心网仍处于3G阶段。无论是“中兴域”或“华为”域, 管理对象都是由核心网电路域CS (电路交换) , 核心网分组域PS (分组交换) 以及相关业务网络组成。对于网络管理接口, 侧重点在于网元管理系统和网络管理系统之间的接口。涉及这些管理功能需求有:公共管理功能、配置管理功能、性能管理功能、故障管理功能、安全管理功能等。其中, 公共管理功能是后几类管理功能都要用到的基本管理功能。

公共管理功能包括访问入口点、通知管理、链路监视、日志管理和文件传输功能;配置管理包括基本配置、大数据量配置、配置信息改变的通知和同步, 还包括移动通信网的漫游数据配置、基站信息配置;故障管理功能包括告警上报、告警信息同步、告警处理;性能管理功能包括获取性能数据、性能门限管理、历史数据管理;安全管理功能包括防止接口管理功能的非授权使用。

1.2 网络管理方式

网络管理中, 相互交互的两个实体分别承担着管理者和代理者的角色。管理者发送管理命令并接收代理者发来的通知;代理者直接管理网元对象, 接收管理者发来的命令并返回操作响应, 也可主动向管理者发送通知消息。

在移动核心网网管系统中, 核心网的基本实体域包括公共部分、电路域和分组域。网络管理系统 (NMS) 承担管理者的作用, 而网元设备 (NE) 及其操作维护系统 (OMC) 承担代理者的作用。其中NMS由运营商提供, 能够管理不同厂商的设备, 而OMC由厂商提供, 并向NMS提供北向接口。目前主流网络管理协议有两种, 一是ISO (国际标准化组织) 制定的OSI (开放系统互联) 网管协议, 二是简单网络管理协议 (SNMP) 。

2 移动核心网网管系统现状和不足

在移动核心网演进中, 由于网络结构和技术的发展, 面临着多种类型的核心网并存的情况, 设备种类、协议种类、接口种类也是复杂多样, 因此对移动核心网进行有效的运营管理是运维部门的一个难题。

2.1 管理能力方面

移动互联网时代的显著特征在于丰富的业务。业务网包括数据业务网和移动智能网, 它们是在承载网的基础上增建各种业务引擎来实现的, 基本是以通用计算机平台为主的IT (信息技术) 系统, 支持TCP/IP (传输控制协议/互联网协议) 及SNMP, 便于开发综合网管。业务网元出现故障时, 网管系统应能迅速判断某个高层业务对象的故障是由哪个底层业务对象引起的, 并智能描述出业务故障信息, 把它实时呈现给客服系统。

3G/4G网络和业务比较复杂, 影响用户感知的环节众多, 要实现对服务质量进行监控和管理, 就需要从网络到用户进行端到端的分析, 因而实现起来有难度。如何通过监控反映出业务使用和不同厂家设备的系统运行状态, 为客服系统提供实时易懂的运行信息;如何使网管系统既能满足“集中管理、集中监控、集中维护”的要求, 又能实现对业务管理的有效支撑, 也是一个难点。

目前, 在我们的客服系统或综合调度系统中, 对于用户投诉, 基本上还是人工判断和派单。由于客服人员无法知悉网络动态, 因此经常会出现误派、重复派、不能拦截、超时较多等情况。

2.2 OMC与NMS的功能定位方面

OMC是厂家提供的系统, 应能实现管理网元设备的基本功能。而NMS趋向于省级集中, 应实现对省级范围内网络设备的集中操作维护和故障告警监视, 实现对网络质量的快速反应和省级网络性能分析, 实现对业务的有效技术支撑。因此, 清晰地划分OMC与NMS两者的功能定位有助于避免重复建设。

移动核心网建设时主要依靠厂家的OMC进行网络配置、操作维护和运营管理, OMC在网管中占有重要地位。我们应从运营管理角度考虑, 提出自身的要求和规范, 以对OMC进行约束。

移动核心网的NMS应该具备跨厂家、跨区域、跨网络的综合分析功能, 而该功能是构建在厂家OMC之上的。它应在汇聚各厂家OMC后实现告警的关联和汇聚、统一网管视图、规范化的全网局数据制作, 及全网端到端的性能分析。而要实现这些管理能力, 首先需要在OMC北向接口上统一标准, 再在NMS上统一指标和集中全网性能数据, 这样才能用统一的系统、标准和KPI (关键性能指标) 体系进行网络分析和优化。

目前我们主要使用华为、中兴等主流厂商的OMC, 而缺乏一套综合的NMS。

2.3 管理接口规范方面

在目前业界的OMC北向接口规范中, 对性能管理、故障管理的功能需求、分析和设计定义比较完善, 一般可以满足上层网管通过本接口进行集中故障管理的要求。配置管理部分主要定义了基本配置和大数据量配置接口, 对于上层网管通过本接口向下实现设备配置的规范还在研究中, 安全管理功能的需求和设计还需进一步细化。

由于北向接口规范本身还在不断完善, 在入网测试中, 除了测试接口的可靠性、处理能力、提供数据的准确性等自身性能, 还要保证北向接口稳定性和兼容性符合NMS运行要求。

3 提升网管系统的几个方向

3.1 从Qo S向Qo E转变

Qo S (服务质量) 描述网元在一定级别上满足业务的能力, 而Qo E (用户体验质量) 测量一般用样本统计或应用Qo S参数映射这两种方法。

Qo S实际上是一个技术概念, 对用户而言意义不大。尽管好的Qo S通常会带来好的Qo E, 但对我们运营商来说, Qo E才是网络业务性能的最终衡量标准。Qo E相对而言是个比较新的理念, 它强调的是面向业务、面向前端的网络管理, 更符合“网络运营”的管理思路。对于移动核心网的网络管理系统而言, 也有着更高的要求。

3.2 从TMN向NGOSS转变

长久以来, 电信管理网 (TMN) 一直指导着电信网络管理的建设, 但其功能主要集中在网元层, 对网络层及管理层缺乏支持。TMN是传统的面向网络的管理, 对业务及更高层的运营管理一片空白。电信管理论坛 (TMF) 提出了电信运营图 (TOM) 及增强的电信运营图 (e TOM) , 这就使得建设网管系统的角度从“网络管理”逐步转向“全面运营支撑”的方向。

我们现有的OSS/BSS (运营支撑系统/业务支撑系统) 是在适应业务和市场需求过程中建立起来的运营支撑系统, 能满足特定时期的业务需求。而新一代运营支撑系统 (NGOSS) 将以TMN框架模型为基础, 以TOM/e TOM为需求出发点, 重新确定业务支撑体系结构, 从而形成新的网络管理系统建设框架。NGOSS充分体现了“以客户为中心”的运营原则, 这是我们的转变方向。

3.3 积极应用网管新技术

移动核心网管理的趋势是集中化, 集中网管的功能将日趋丰富, 但仍是分层结构。移动核心网网管系统的发展演进将是一个动态的过程。在此过程中, 新技术在网管领域中的应用, 将是网络管理技术发展的热点和动力。这些新技术包括:基于策略的网络管理、基于SOA (面向服务架构) 的网络管理、基于CORBA (公共对象请求代理架构) 的网络管理、基于Web的网络管理、基于智能移动代理的网络管理等。

4 结束语

移动核心网的网管系统在从“面向网络”转型到“面向前端、面向用户”的过程中, 需要克服设备种类复杂、接口类型众多、管理能力不足等诸多问题, 重视网管新技术的应用和研究, 以提升客户体验为目标, 以实现全面运营支撑为方向, 从而逐步形成保证网络质量的、满足业务需求的、快速响应客户的标准化、自动化网络管理系统。

移动综合网管 第5篇

1 基于ARMA模型的数据挖掘系统

1.1 移动通信网管数据挖掘系统数据挖掘的实现

移动通信网管数据具有时序性、周期性的特点,基于时间序列的数据挖掘方法能够较好的拟合移动通信网络的情况。ARMA模型是时间序列模型的一种,是由美国统计学波克斯(Box)和金肯(Jenkins)在20世纪70年代提出,该模型的数学表达式为:

通过对上述的数学表达式进行统计处理后,可以得到自相关系数为:

由以上公式可以看看出,自相关系数是θ1和φ1的函数,自相关函数从开始,呈指数衰减。若φ1>0,自相关函数的指数衰减是平滑的;若φ1<0,自相关函数的衰减是交变的,在正负值之间振荡,的符号由(φ1-θ1)所决定,它决定指数衰减趋于0的方向。其偏自相关函数的起始值θ11=,以后呈指数衰减。若θ1>0,θkk是平滑指数衰减;若θ1<0,θkk的指数衰减是振荡的。θ11的符号与相同,也由(θ1-)所决定。

以对话务量的预测为研究对象,以预测周期前3个月的相关数据作为训练序列,建立一个合理、计算简单且准确度高的ARMA模型来预测将来一段时间内的话务量,并与实际得到的数据作比较,判断所建的模型是否合理,反复循环修正,直至最优。

1.2 移动通信网管数据挖掘系统数据挖掘的实现

如图1所示。

2 结语

基于电信网络“全程全网”的特点,软交换网络的引入,除电路和信令外同样必须考虑同步时钟、计费、网管和CDS等与MSS和MGW的连接。由于技术的进步,与相关设备的连接方式也发生了变化,如与CDS的连接,用户平面仍然采用TDM方式,但控制流则由IP专网的承载,也实现了控制与承载的分离。从而说明了软技术不仅是核心网本身的进步,也推动了与其相关设备及接口的同步发展。本文提出的设计方法,能够实现软交换设备与现网同步系统和计费、网管、CDS等系统的融合,已经部署在实际的网络环境中。

参考文献

[1]朱建秋,周皓峰,朱扬勇,等.一个基于关联规则的数据采掘工具的设计和实现[J].2001.

[2]Kitty Stokes,Mike Wilkes,Scott Barney:Data Warehousing Using the Metacube Rolap Option.

移动综合网管 第6篇

移动通信网网管系统是一个具有较高复杂性的系统,它的组成结构比较多,主要包括 :集中操作维护、智能巡检、数据集中制作、电子化运维以及高级集中处理这几个部分,它的运行目的,主要是为了实现对系统中的各类数据信息进行收集、监控、分析、处理、维护以及管理等目的,以在最大限度之内,提高移动通信网的运行效率。就它的管理功能而言,也是较为庞大的,比如 :

1)能够对通信网的性能进行系统性的分析,主要有 :业务的分布情况、流量的具体流向、网络维护的考核情况以及话务的分布情况等。

2)对干线网进行管理,比如 :链路调配、网络设置、数据修改、业务设置、增减节点以及路由设置等。

3)对新业务进行科学地分析,确定其对整个网络能够造成的影响程度,以及时采取有效措施,对其进行合理的规避。

2 探析网络入侵告警系统的设计

网络入侵告警可以被划分成为四个部分,即 :

1)用户界面。

我们利用JAVA,对本系统的用户界面进行设计与开发,以达到让用户能够通过该界面,来对整个系统中的数据信息以及各项功能进行有效使用的目的。

2)高级功能。

本系统之所以会应用到大量的数据,主要是为了达到两个目的,即 :1)入侵告警 ;2)对通信网的安全性进行维护与管理。因此,我们特意在本系统当中,设计了一个高级功能子系统,它囊括的功能比较多,主要有 :报表分析、资产管理、接口管理、维护工具以及工单管理等。

3)数据处理。

本系统的核心功能,是通过对数据以及各种事件的有效处理,来实现入侵告警的目的。因此,为了尽可能的提高本系统对数据信息以及事件的处理效率,我们特意为其设计了一个具有较高性能的数据处理子系统,它的作用主要是 :对各类数据信息进行分析、过滤、处理以及关联,并将其及时的存入到系统的数据库当中。

4)数据采集。

数据在本系统当中,起着至关重要的作用,且它的类型也是比较多的,主要包括 :安全策略、日志、安全时间以及风险评估结果等。因此,我们就应当强化本系统的数据采集功能,以为系统其它功能的实现提供数据支持。

3 探究系统的总体设计

3.1 总体设计

借助J2EE,对本系统的整体架构进行设计,而模的设计,则采用的是“UML”,以合理的突显出本系统的模块化设计思想,并让系统中的各大功能,都能够实现“协调运行,互不影响”运行过程,以尽可能的满足人们对其的实际需求。

3.2 系统架构的实现

针对本系统中的不同模块,我们作出了下述几方面的思考 :

1)应用服务器,采用“Sun Solaris”来作为其的操作系统,它能够进行加载的软件有两个,其中一个是网络入侵告警,而另一个则是“IBM Web Sphere”。

2)日志服务器,选用“Sun Solaris”来作为其的操作系统,它能够实现加载的软件仅有一个,即 :日志管理模块。

3)系统消息 服务器,采用“SunSolaris”来作为其的操作系统,它能够进行加载的软件也有两个,一个是信息服务程序,而另一个则是“IBM MQServer”。

4)数据库服务器,采用“Sun Solaris”来作为其的操作系统,选取的数据库是“Oracle 9i”。

3.3 数据采集功能的实现

由于本系统对数据的真实性以及实时性,有着较高的要求。因此,我们就必须要保障数据信息能够及时的被系统捕获,同时被快速的传送到相应的模块当中,对其进行有效的分析和处理,然后再依照最终的处理结果,判断是否需要实现入侵报警。于是,针对这一问题,我们选用了多种数据采集技术,例如 :安全配置采集技术、安全事件采集技术以及漏洞采集技术等。这些技术不仅具有较高的数据采集功能,还能够对“agent”进行全面的支持,以实现对各类数据进行分析、处理、告警以及响应的过程。

4论析入侵告警的实现

4.1短信告警

它的实现原理是 :通过在本系统和短信网关中间,增设一个“转化程序”的方式,对告警信息进行及时、有效的转化,使其能够准确的转变成为可以供短信网关进行识别的有效信息,然后再经由网关将该信息发送到相应的移动设备当中,比如 :手机等,从而实现短信告警的功能。该功能的实现,具有两大优势,它们分别是 :1)可以进一步提升告警信息的传输效率 ;2)不会受到地域以及时间的限制,只要相关管理员具备移动设备,那么他就能够及时的获取到告警信息 ;3)能够提高管理及技术人员,对移动通信网进行管理及维护的效率。

4.2声音告警

为了提高本系统入侵告警的准确性与实时性,我们还特意设计了一种“声音告警功能”,它不仅能够支持不同格式的音频,还具备对语音卡进行声音告警的拓展性能,它的实现原理是 :当系统一旦发现存在着威胁性的数据或者是事件之时,就会触发本功能,此时,本功能就会借助语音卡,将前一阶段已经预设好的告警音频,及时的播放出来,以告知管理人员移动通信网中出现了威胁。

5 结束语

综上所述,网络入侵告警的实现,不仅保障了我国移动通信网的安全性与可靠性,还在很大程度上提高了通信网的运行效率。因此,为了进一步将我国移动通信网的业务拓展开来,让其能够为我国广大市民提供更优质服务,我们就应当将网络入侵告警系统更为广泛的应用在移动通信网网管系统的建设当中。与此同时,我们还应当采取更为先进的技术与设备,对该入侵告警系统进行合理的改进并完善,使其能够符合我国移动通信行业未来的发展要求。

摘要：随着通信技术的不断发展,我国对移动通信网网管系统的要求有了进一步的提升,而网络入侵告警在网管系统中的实际应用,不仅提高了移动通信网网管系统的安全性与可靠性,还在很大程度上降低了系统建设及后期运行时的成本。因此,本文将针对网络入侵告警系统,对其在移动通信网网管系统中的实现设计进行深入的分析和探究。

综合网管系统接口适配技术研究 第7篇

网络管理接口适配是电信管理网建设的一种核心技术, 是电信管理网建设时的热点问题之一, 在通信网络管理中同样起着举足轻重的作用。由于不同的网络管理接口适用于不同的网络设备, 网络管理接口标准化组织过多等问题导致了网络管理接口技术的选择又是一个难点[1]。

1 网管接口的标准化与多样化

各大标准化组织对于网络管理标准的研究主要集中在网络管理框架、网络管理研究方法论和网管接口等方面, 而其标准化的核心内容则是网管接口设计与适配。

ITU-T第4研究组负责TAN (M系列) 的标准化。11.30 10定义了TMN的原则和框架, TMN框架中最重要的接口是操作系统之间的Q接口, 包括通信协议和信息模型两个方面。TMN标准接口主要采用了CMIP协议标准, 如X.21和X.215等系列通信规程和协议。

传输网的标准由ITU-T第15研究组制定, G.805和G.872定义了传输网和光传输网的逻辑模型, 是传输网信息模型的基础[2]。ITU-T于1992年开始推出了G.774系列SDH网元信息模型建议。

为了获得更加灵活和简便的网管接口适配, ITU-T在标准化工作中引入了IT业界广泛支持的技术。但是官方的标准化工作进展相对缓慢, 远远满足不了网管系统建设的要求, 于是一些民间的自发性网管标准化组织, 如电信网管论坛TMF和SONET互操作论坛等应运而生。

现行的网管接口具有鲜明的多样性特点, 如接口交互协议有Q3/CMIP, SNMP, CORBA, TCP/IP, TLI和RS232等;信息模型和数据表示方式, 则既有遵循国际标准的模型, 也有厂商的私有模型, 而且后者数量很大;网管接口被分为网元层, 网元管理层和子网管理层等;而且, 甚至同一厂商不同版本的网管接口也同时存在。

2 适配接入方案

CESEC传输网网管系统可以实现对多个厂商的网络设备进行综合管理。三级网管系统使用了不同厂商提供的北向接口, 其通信协议和信息模型有差异明显。二级网管系统和三级网管系统之间的接口适配可以大大简化其接口的交互操作, 适配器的网络配置如图1所示。

在运行过程中, 适配器通过北向接口与三级网管系统交互, 接口协议多样, 如Q3/CMIP, SNMP, CORBA/1I0P, TCP/IP, TL1以及RS232等, 接口信息模型则主要是G7系列, 如G.774, G.855和各厂商的私有模型[3]。二级网管系统通过统一的接口与各适配器进行交互, 其接口通信协议采用BUPT-ORB, 信息模型则采用TMF509。

在传输网中, 网管系统的接口适配器主要完成如下的功能:

(1) 以代理 (AGENT) 的身份负责与二级网管系统交互、初始化, 并维护系统管理对象的管理信息树MIT (Management Information Tree) 。

(2) 完成二级网管系统管理者 (MANAGER) 对管理网络复杂度, 网络构成复杂度, 功能模型, 拓扑模型, 管理构成和管理体系等A、B、C各层对象的创建、删除、修改和查询等操作功能。

(3) 接收网管系统上报的事件, 完成事务处理并向后传递至二级网管系统。

如上所述, 接口适配器在传输网网管系统中具有双重身份, 与二级网管系统交互时充当AGENT, 而与厂商网管系统交互时充当MANAGER, 这种角色认定在适配器的功能结构与工作流程也有明显的反映。

从应用方面来看, 网络管理接口适配器可实现的功能很多, 如连接各厂家网络管理接口, 提供标准的北向接口, 屏蔽不同的厂家私有网管接口协议、信息模型和功能的差异性, 向上层网管系统提供统一网络管理接口协议, 实现网络管理系统与被管网络之间的快速互连互通和互操作, 提供性能、配置、告警等多方面的管理功能。

3 接口适配器的实现

网络管理接口适配器具备和目前各专业网络大量设备厂商的接入能力, 支持从厂家标准OMC北向接口、厂家私有OMC北向接口、设备直连接口的接入, 支持的接入技术包括:CORBA、MML、SNMP、DB、TCP/IP、FTP、We bSe rvice等

适配器分为两大模块, 分别是AGENT模块和适配模块, AGENT模块负责维护管理信息树MIT, 与二级网管系统MANAGER进行有效交互;适配模块负责厂商北向接口与统一接口的信息转换, 并实现与厂商网管系统的交互。

AGENT模块与适配模块之间采用应用程序接口API (Application Programming Interface) , 接口共分为三部分, 分别是通过AGENT管理对象类成员函数来提供的MIT初始化接口、通过AGENT管理对象类成员函数来提供的管理对象操作接口, 以及通过全局函数提供的通知上报接口。适配模块实现的功能主要是管理信息的双向适配功能, 即与厂商网管系统的双向交互操作, 它采用硬编码方法来实现管理信息适配功能。

4 接口协议技术特点比较

当前通信网络管理接口的协议技术很多, 但并非每种协议技术对不同应用环境下的网络管理接口都适用, 实际使用时, 应根据网络管理接口所处的应用环境, 结合不同协议技术的特点, 选择合适的接口技术。下面从标准制定组织、技术优势、接口参考模型、协议交互模式、信息建模能力等方面来比较几种接口协议技术的特点, 具体内容见表1。

5 结论

网络管理接口的工程应用环境非常复杂, 因此接口适配工作应考虑接口所处环境、工程阶段和实际需求, 遵循简单、适用、合理的原则进行接口协议选择, 获得网管系统最大性能的发挥和后期建设规划需求, 以达到网络管理接口实现和系统建设的最优状态。

参考文献

[1]曾明, 李建军等.网络工程与网络管理[M].北京:电子工业出版社, 2003.

[2]吴信才.地理信息系统原理与方法[M].北京:电子工业出版社, 2002.