移动网管（精选8篇）
移动网管 篇1
在2011年铁通武汉分公司已经承接移动武汉分公司的江南4个区的集团专线和青山区的基线 (基站和线路) 代维工作。2012年12月移动武汉分公司正式把武昌区基线代维和洪山区、高新区、江阳区、江汉区、江岸区、桥口区的线路代维工作同时移交给铁通公司。随着“深化协同, 促进融合”大方向下, 铁通会在移动代维工作中占据越来越重的比例, 如何把代维工作做细做好再做细, 是铁通今后工作中的重要难点, 本文主要分析如何运用移动自有平台网管来解决代维工作中的重点、难点、疑点。
1 管线管理系统简要介绍
管线管理系统是集成城市管线数据, 对光缆、基站、设备、综合柜、光配、数配等管线数据进行统一的管理的系统, 实现了管线数据的输入、编辑、查询、处理、更新与输出等功能。
该系统以现有移动的管理数据为信息来源, 建立管线数据库, 并在此基础上实现规划各部门联网运行的管理系统, 此系统目的在于解决城市管线管理过程中各种信息的输入、设计、储存, 和以数据库为核心的数据浏览、查询、更新、统计功能, 并实现管线管理过程中的图形、表格的输出处理及规划管理的信息化等功能。
2 管线管理系统的实际工作运用
在代维工作中, 保证传输通道畅通不中断是代维的核心工作, 如何压缩故障处理时间, 简化故障处理流程, 降低故障发生次数, 都会是我们今后工作的重点。
在铁通初期代维工作中会存在无台账、无资料、无经验的问题, 再加上初期代维人员对移动自有光缆、基站、设备无法全面熟悉、掌握。此时, 管线管理系统就能在我们代维工作中起到关键作用。下面从代维工作的二种代维任务来介绍管线管理系统作用:
2.1 线路代维方面
在管线管理系统里可以把移动自有光缆的敷设方式 (杆路、管道或墙挂) 、起始点、终止点、芯数、在用芯数、总长度和段落长度等情况清晰的展现在网管中。
这些信息不仅仅方便了我们台账整理工作, 更能在我们处理紧急故障时, 能给我们分析, 判断做最有力的依据。
在代维工作中, 最常见的故障为光路中断, 一般都是运用OTDR (Optical Time Domain Reflectometer, 中文意思为光时域反射仪) 判断故障点, 如果把OTDR测出的出局公里数配合管线管理系统数据便能更准确判断出故障点的区域和路径, 这样必然会压缩故障分析时间和故障点处理时长, 从而做到压缩故障处理时间, 简化故障处理流程的专项工作。
2.2 基站代维方面
管线管理系统平台能清晰的把移动自有基站内情况反映出来, 包括机房的经纬度、所在楼层、综合柜数量、出局光缆、承载哪些传输设备 (780A、780B、01B、01D、110B等) 、光配、数配使用情况等。
在初期代维工作中, 如果对管辖内移动所以基站进行普查工作可能需要大量的人力和时间, 如果能把系统中的数据提取出来, 作为初期代维的资料和台账, 我认为会对我们的初期代维工作起到关键性的作用, 会让我们代维工作更合理、更科学。
想从根本上降低代维故障发生次数, 就必须建立合理的巡检安排和健全的资料系统。只有掌握到各个基站内光缆、设备、ODF、DDF的台账和资料后, 我们才能制定出最科学、最合理的日常巡检方法, 其中包括线路巡检、基站巡检、设备巡检等。那么如何才能做到制作健全的资料系统呢?
我认为必须把移动管线管理系统中的资料和现场普查工作资料互相结合, 才能做出具备准确性、实时性的资料系统。有了健全的资料系统后, 就能减轻代维工作量、提升代维工作质量。方能在日后巡检工作中必然会更加有准确性、针对性、合理性, 做到事前清清楚楚事后稳稳妥妥, 从而根本上降低故障发生次数。
3 综合资源管理系统简要介绍
随着移动公司网络发展, 网络容量愈来愈庞大, 新设备层出不穷, 通信线路正逐步迈向高密度、光纤化、区域密集化、路由复杂化。此时移动公司引进了综合资源管理系统, 此系统主要分为资源拓扑、业务开通、网络割接、统计分析、基础功能五大部分组成。因为代维工作特殊性, 所以主要介绍基础功能部分中:无线网系统和动力系统。
4 综合资源管理系统特点
(1) 综合性:全网资源, 包括物理资源;传输、交换、天线等多专业资源;移动网络部、财务部、市场部等多个部门长期使用;
(2) 动态性:改变传统资源管理系统作为公司网络资料备份的缺点, 移动公司已将资源管理系统纳入公司管理流程, 已实现定制业务工作流程, 网管系统数据长期定期更新, 保持与现场实际情况的一致;
(3) 准确性:以GIS系统为基础平台, 实现资源的集中控制、分布式管理;完善的统计分析功能和报表输出功能为决策提供帮助。
5 综合资源管理系统的实际工作运用
(1) 在综合资源管理无线网系统中, 有四个选项卡比较关键, 分别是无线机架、无线机框、无线机槽、无线板卡。
在这四个选项卡中, 内容基本包含移动自有基站内无线设备的厂商、型号、类型、是否在用、板卡、槽位等。拥有这些数据后, 我们可以结合基站无线设备现场状况制定出最合理的备品备件的选择方案, 随时都拥有我们需要的板卡型号和板卡数量。保证在基站无线设备出现故障后能第一时间更换正确的板卡, 确保故障延时最小化。
无线机架:
无线机框:
无线机槽:
无线板卡:
(2) 动力系统。
动力系统主要体现了移动自有基站内交流配电柜、开关电源、普通空调、动环监控等数据, 在我们日常代维工作中, 很多故障不一定都由于是传输或者设备引起, 不少故障都是因为机房电压不稳定、电源出现问题、空调停止工作等引起, 如果能对这些动力设备进行巡检统计、归纳后, 制定完善的巡检方案, 必然会减少非传输或设备原因的故障发生次数。
交流配电柜:
开关电源:
普通空调:
动环监控:
6 结语
代维工作是一项具有开创性和持续性的工作, 也是一项检验公司管理能力和技术水平的工作, 更是一项体现责任和信誉的工作。铁通代维工作担负着四个方面的责任, 即“政治责任”、“安全责任”、“管理责任”和““扭亏责任”。
在代维这份工作上蛮干、硬干势必是会吃亏的, 只有我们拥有更先进专业的技术和全面完善的资料时, 我们的代维工作才能顺利开展和展开, 本文主要介绍利用移动管线管理系统和综合资源管理系统来解决代维工作中的繁琐问题, 如何把代维工作中的重点、难点、疑点简单化、平面化才是我们将来代维工作的重中之重。
移动网管 篇2
近年来，随着移动通信业的高速成发展，电信部门管理手段的现代化也逐步受到各级领导的高度重视。为了使通信网络的管理更加合理化、科学化，就需要用现代化的技术手段来代替低效、繁琐的手工方式。因此使用计算机技术对移动通信设备进行管理已经势在必行，这时移动通信网本地网管系统就应运而生。
同时，随着计算机技术的迅速发展，许多传统学科与计算机技术相结合从而诞生了一批新兴学科，地理信息系统就是其中之一。其英文名称为geographic information system，简称gis。它能够处理大量含有地理成分的数据信息，使你可以简单而迅速地在大量的信息中查看其模式和关系，而不必不断地访问数据库。
在通信网络中，大量的设备都有其地理位置，同时，有大量的处理如果通过地图来进行，则会又方便又直观。因此在网管系统中，引入gis系统，在电子地图上显示基站、小区等各类通信网元的分布情况，并对网元进行实时监控管理、浏览配置信息和性能查看分析。
二、选题的目的及意义
选题背景出自项目“移动通信网本地网管系统”。该系统立足于tmn，以操作维护、环境监控工作为重点，实时监测全网的运行情况，快速响应网上的各种事件，提供性能分析报告，不仅为设备的集中操作提供了方便、可靠的技术手段，而且为网络优化和经营管理决策提供了参考依据。
地理视图作为本系统的一个子系统，是使用gis技术，在电子地图上，将各类通信网元按地理位置显示成一个分布图。用户可以对图进行操作，也可以对网元的告警、配置和性能信息进行查看和分析处理。地理视图是直接与用户交互的前台界面，其制作质量的高低将直接影响用户对整个系统的认识，可见地理视图在此项目中的重要作用和地位。此外，gis还广泛应用于诸如交通管理、商业销售等领域的软件开发中，因此，研究和开发gis系统是很有意义的。
三、研究的重点内容
本毕业设计涉及到的主要内容有：数据库存、internet网络应用、mapinfo和asp技术。
系统的gis软件平台采用了mapinfo公司的maxxtreme。mapxtreme是一个基于internet的地图应用服务器，可以通过internet或企业内部的internet向用户发布地理信息。
该地理视图系统是浏览器/地图服务器/数据库服务器三层结构，需要windows nt server。其中
地图服务器：windows nt，internet information server，mapxtreme
客户机：windows 95/98。
由于采用了maxxtreme，使系统在结构上成为浏览器/服务器的形式，顺应了企业内部网向intranetx演变的潮流。在服务器端是用微软的asp技术，需要用到其中的activex和vbscript技术。
地理视图子系统要通过socket通信方法从网管系统的其他子系统获得有关各种网元的数据流，对通信网中各种信息进行实时动态的监控、分析与显示，并将处理所得数据传入数据库，以便进行信息查询，同时数据库要动态更新。可见，本次毕业设计既需要了解硬件知识，又需要有较熟练的软件编程能力，既需要计算知识，又需要通信知识，是我所学专业知识在具体工作中的应用。
本次设计具有较高难度，但我相信，通过学习和不断的努力，我一定能高质量的完成本次毕业设计任务。
四、进度安排
3月20日-4月15日
分析题目，查阅资料，学习与毕业设计相关的知识，作好前期准备工作。
4月16日-5月10日
划分软件工能块，进行方案论证，编制软件。
5月11日-6月10日
移动网管 篇3
部署注重网络Qo S保障
《通信世界周刊》:良好的承载网络质量可以有效地保障用户IMS业务的使用, 目前业界普遍认为IP承载网络的QoS并不能完全满足电信级服务质量需求, 对此您怎么看?
程路:IMS对承载的需求主要包括多个省多个城市之间IMS系统互通和IMS业务系统互联。在IMS业务互联部分, 则包括内部网元的互联以及SBC (会话边界控制器, 功能是连接CMNET与IP承载网络) 与用户的互联。针对这些需求, 中国移动与合作伙伴共同制定了完善的实施方案, 并注重网络QoS的保障。
具体而言, 为保障用户IMS业务良好体验, 中国移动对IP承载网使用DiffServ和E-LSP等技术。CM-IMS设备接入IP承载网时, 需要配置三层接入设备 (CE) , 用于汇聚IMS网元的端口和流量, 实现统一接入承载网。同时, IMS系统核心设备所在的中心局房单独设置两对CE, 分别用于接入CMNET和IP专网局房内IMS系统设备和IMS AS共用CE。这些前期规划方案的实施, 有效地提高了承载网络运行质量。
IMS承载垮过三道坎
《通信世界周刊》:浙江移动IMS的部署进展快速且顺利, 请问浙江移动从最初开始建设到现在, 在IMS承载网建设方面都碰到了哪些问题?最后是如何解决的?
程路:目前技术上没有太大的问题。在IMS一期时, 由于是试验网络, 地市公司没有设置相应的CE设备, 其SBC设备不能接入当地承载网路, 而需要接到省公司CE上。今年新增了CE设备, 解决了这个问题, 网络结构更加清晰, 简化了维护管理工作。
还有就是承载网络的安全问题。由于IMS业务存在传统有线固话、IMS有线固话和PC客户端等多种接入方式, 而互联网与2G/3G的互通也给原来相对独立的核心网带来了安全隐患, 例如互联网上存在的各种病毒程序及黑客程序对核心网网络设备及业务服务器、客户信息都带来威胁, 因此在SBC与互联网间增加防火墙, 实现IMS网络与互联网络间的安全隔离加固十分迫切。今年我们在二期建设中在各地SBC与互联网间都增加了一对防火墙进行安全加固。
另一个问题是承载的运维管理方面。IMS技术首次部署, 个别核心网元所属专业维护人员还需重新调整职责, 以更好地发挥自身特长, 保证设备的正常运行。
IMS承载网带宽充足
《通信世界周刊》:IMS业务流量过大, 或者业务优先级没有很好的规划, 就会影响最终用户的业务体验, 目前浙江移动业务流量对IMS承载网影响如何?
程路:目前没有问题。2010年4月, 浙江移动IMS二期工程全面启动, 浙江移动在原有IMS试点网络基础上进行改造。二期工程使核心网容量达到150万用户规模, 满足到2011年中期要求。当前IMS用户数快速增长, 不过总数相比核心网容量还差很多。从承载的角度看, 现有用户使用IMS业务产生的流量, 对承载网络带宽利用率不足30%。
未来流量激增可能会对IMS承载网带来很大影响, 媒体流量相对信令流量来说会比较大。因此面对未来高带宽需求, 我们都在规划阶段预留了端口, 可以在需要的时候利用现有端口及预留端口捆绑等方式满足需求。
我们一直保持IP承载网络的宽带利用率不超过30%, 尽可能地保障IMS业务质量。目前IMS二期建设已经考虑未来流量可能大量增加的情况, 在承载网方面带宽是比较充足的。
《通信世界周刊》:据统计, 目前全球只剩下5%的IPv4地址可用, 预计明年3月份可能就开始出现空缺, 保守估计明年年底将全部用完, IPv6的试点与部署越来越迫切, 这些变化会对IMS承载网络带来影响吗?
移动网管 篇4
1 Te MIP体系结构
Te MIP完全满足OSI标准,并经实践证明:Te MIP与许多基于OSI的设备能够非常平滑地互连,同时提供接口与特种设备连接。另外,Te MIP完全基于TMN设计。
1.1 Te MIP概述
Te MIP就是为各种类型网络的综合管理提供的平台。Te MIP的运行环境非常灵活,根据特殊类型网络的要求,Te MIP能够建造特定的网络管理解决方案。目前,Te MIP可以在如下的环境下操作:GSM基础设施的监视和控制;SDH传输管理;交换管理的集成;大型语音/数据公司网;ATM、网络和业务管理;微波、无线网桥和其他传输网络;服务级网络管理;宽带管理。
1.2 Te MIP组成
Te MIP包含以下部分组成的集成软件包,这些部分提供了坚固、模块化、分布式的体系结构,也提供了开放的开发环境,以及综合的网络管理方案:Te MIP主体框架(Te MIP Framework);Te MIP差错和故障管理(Te MIP Fault Trouble Management);开发工具包-框架开发的工具包(Framework Developer’s Toolkit);可视Te MIP工具包(Visual Te MIP Toolkit);SNMP工具包(SNMP Toolkit);OSI接入模块工具包(OSI AM Toolkit);ASCⅡ接入模块工具包(ASCⅡAM Toolkit)。这种分布式体系结构包括表示模块、功能模块和接入模块,将现有应用模块集成到系统中的能力以及从图标地图的表示模块中启动应用的能力。Te MIP能连接到运行不同协议的网络中,并监视和控制网络部件(网元)。
1.3 Te MIP主体框架的管理模块
Te MIP主体框架是针对网络管理解决方案而提供的综合网络管理软件平台。Te MIP主体框架提供了基本的管理系统,由一组交互式的管理模块组成,可以为管理系统提供特别的功能。Te MIP电信网管平台基于TMN标准结构框架,采用三级应用结构:采集层(Access Modules)、处理层(Function Modules)、呈现层(Presentation Modules),通过Te MIP平台构架整个网管应用系统符合中国移动集团公司规范要求实现的三层结构。管理模块是由Te MIP核心和管理信息仓库(MIR)提供支持的,MIR存贮了所有实体信息。Te MIP主体框架如图1。
2 基于Te MIP体系的三层结构
2.1 数据采集层总体结构设计
数据采集层总体结构设计见图2。数据采集层利用不同的接口将六个厂家七种不同类型设备的性能数据、配置数据、告警数据接入网管系统原始数据库。在目前各厂家的接口并未完全统一的情况下,每种数据格式设置一个独立的接口模块,接口模块之间为相互独立的关系,与上层的处理层之间采用统一的数据接口。这样使得将来增加接口数量、改变单个接口结构非常方便,升级和扩容非常平滑。同时为用户提供图形界面,设置采集时间、周期及手工控制功能。在采集层的系统设计上从多方面体现了软件复用技术,数据采集层与数据处理层采用统一的标准接口,不同类型的数据采集服务都通过这一接口将数据传递到数据处理层;利用不同网络协议采集来的不同类型的数据共用统一的文本解析模块对数据格式进行解析。系统直接为操作者提供了控制采集层的业务,使操作者可以通过这些业务直接控制管理网,实现NSA体系结构。
通过用户界面,用户可控制数据采集形式和设置各种采集参数,而且当设备升级时通过修改数据解析规则达到系统平滑升级的目的。通过各个通用接口模块不仅使得管理网与被管理网之间网络通信协议的多样性、复杂性完全被隔绝,而且使管理网与被管理网之间的复杂的数据类型也初步统一。
2.2 数据处理层总体结构设计
数据处理层系统设计如图3所示。数据处理层的主要任务是将各厂家不同格式的数据内容转换为统一的格式,并将其保存在归一化数据库中。数据库接入模块、数据存储与管理控制模块是处理层的可重用公共组件。数据库接入模块作为应用层与处理层的接口同样适用于原始数据库和归一化数据库,用户可以直接利用应用层的应用服务获取信息,也可以直接利用数据接入模块提供的通用数据库接口方式直接访问数据库获取普通应用中所无法得到的信息。
处理层的主要任务是将各厂家不同的数据内容转换为统一的格式,并将其保存在归一化数据库中。因为每次设备版本升级时,数据内容与格式都有很大的改变,所以要求处理层能够动态地容纳这种变化。我们的对策是采用一种标准的解释语言XML进行数据转化,这样在数据映射关系发生变化时,用户可以通过修改XML文件解析规则来完成这些任务。
2.3 数据应用层总体结构设计
数据应用层从层次结构上可以分为服务方的业务逻辑层和客户方的表现逻辑层。系统的业务逻辑包括:性能管理应用模块、配置管理应用模块、故障管理应用模块、安全管理应用模块等。这些功能模块基于基本公共组件构建。如图4所示,公共组件包括:日志管理基本单元、区域管理基本单元、事件前向鉴别器(EFD)基本单元、告警管理基本单元、注册管理基本单元等。表现逻辑层由各种可视化应用系统组件构成,每个组件可以实现一个单独的可视化业务功能,系统应用可以通过这些业务功能灵活搭建,实现界面个性化设置、系统应用灵活组装。
3 结语
系统运行以来,运行数据表明,数据采集模块能够保证数据采集的完整性、准确性和及时性,采集到的数据在数据处理模块能得到及时地处理,不会造成数据的堆积,保证了系统的实时性。在功能上说,目前的移动网络管理系统主要实现了对GSM900/1800网中网元(MSC/GMSC/HLR/BSC/BTS)的管理功能。总体上说,这样的网络管理系统只是实现了真正网管意义上的一些初级功能,在现在移动业飞速发展的今天,它仍面临着诸多问题和挑战。
参考文献
[1]陈德荣,林家儒.数字移动通信系统[M].北京:北京邮电大学出版社,1996:82-96.
[2]孟洛明.通信网网管系统建设中的基本问题、现状和发展[J].通信世界,2000(07):2-4.
[3]杨玉,王文辉.网管系统在移动通信网络中的应用及问题[J].通信世界,2010(07):9-13.
移动网管 篇5
中国移动天津有限公司网络生产管理中心|李荣盛
传统单纯的移动通信业务已不能满足集团客户需求, 为应对日常工作所需, 集团客户一般需要数据专线、语音专线、集团短信业务、集团彩信业务、企业邮箱、主机托管、虚拟网等多类综合性业务。但中国移动开展固定业务又受制于固定网络资源的缺乏, 因而借运营商重组契机整合了铁通公司, 启动了跨省的IMS试商用工程, 希望通过引入IMS实现固定话音接入和业务控制, 以提供多媒体类和融合类业务能力, 为全业务运营尤其是对政企客户的争夺奠定基础, 这也是中国移动大力发展IMS的主要原因之一。
实际上, IMS的发展与集团客户的业务发展紧密相连, 这也对运营商的网络运维单位提出了要求。笔者在此并不希望对IMS的技术和其业务承载能力进行探讨, 而是希望针对IMS技术发展对中国移动网管支撑系统带来的影响和挑战进行阐述, 其中也将涉及集团客户业务对网管支撑系统的影响和挑战。
网络资源管理动态调配
首先, IMS对运营商网络资源管理提出了严格要求。当中国移动的市场人员面对客户进行业务洽谈时, 首先需要告诉客户中国移动能够提供何种业务以及这些业务的开通与响应时间等, 这些细节需要资源管理系统的有效支撑。对于集团客户而言, 网络接入方式和网络接入地点是首要的资源支撑内容, 业务安装部门需要以此为标准为客户设计最近的接入点和最安全的接入路由, 而这些新的固网业务需求都对中国移动的网络存量管理提出了新的挑战。
资源的快速开通意味着接入网的快速部署。对于移动通信而言, 由于其最初的通信模式 (无线通信) 决定了中国移动对于静态资源 (哑资源) 的弱化管理—国内对于基础资源的管理重视程度普遍较低, 中国移动在业务发展之初仅有移动通信业务, 其业务对于端到端的开通需求并不明显, 开通手机用户仅需要在HLR激活即可, 所以包括中国移动在内的大部分移动运营商对于无线通信网络资源的管控能力都很薄弱。
在这些静态资源中, 管理难度最大的就是管线管理, 因为这些资源在建设之初并未实施IT化管理, 因而在大规模建设后, 中国移动重新对已有管道、传输线路等进行反查时只能依靠手工完成, 其难度可想而知。
笔者认为, 为了能够获取全面、准确的资源管理, 运营商管理层需要切切实实地认识其重要性, 自上而下地坚决贯彻落实, 一方面严把入网关, 另一方面加强后期维护、督查等方面工作, 以保证数据资源的准确性, 使中国移动在日益激烈的市场竞争中实现快速的资源调度和网络接入。
监控管理从“网络”转向“业务”
经历了10多年的OSS建设, 中国移动的通信网监控已经相对成熟。目前, 通过建立话务网管、数据网管、传输网管、动环监控等系统, 中国移动已基本实现了全网监控。但问题在于, 现阶段大部分的监控系统大多仅停留于面向设备的监控阶段。在全业务竞争环境下, 端到端的产品监控能力需求已日渐突出, 如何对接入网设备进行管理和监控已经成为当前一个比较突出的问题。
另一方面, 要做到端到端的监控需要依赖于对资源信息的及时提供, 具体而言, 一个IP交换机端口究竟连接哪个客户, 这是一个典型的静态资源信息, 然而在实现面向业务的监控时就成为了一个比较难解决的问题, 因为物理资源对于逻辑业务承载关系是非常复杂的, 而物理资源的故障与所承载业务质量之间的关系更为复杂。因此, 当前中国移动需要尽快摸索出如何从面向设备的监控、面向网络的监控转变为面向端到端的业务监控, 以此为客户提供更好的服务质量。
建立面向客户感知的分析体系
当下, 中国移动对网络运行质量的分析已经形成了比较成熟的体系, 但是其面向客户、面向业务的分析能力却相对薄弱。在传统移动通信中, 运营商一般不会针对某个客户或某项业务进行分析 (只要分析网络本身运行质量即可) , 而事实上, 网管系统在日常分析中很多情况下无法区分出具体用户或具体业务。但在引入IMS网络后, 中国移动多业务并举, 如果还不能提供差异化服务便会造成客户感知度的下降, 甚至产生客户流失。因此, 中国移动迫切需要建立起“面向客户感知的分析”体系与“业务分析”体系, 尽可能从客户角度评价网络运行质量, 及时进行网络优化。
移动网管 篇6
随着移动通信网络规模的不断发展, 运营商之间的竞争也从原来的市场占有率之争转为面向用户服务之争, 而服务对支撑系统的依赖, 使得支撑系统建设得到很大发展, 随着经营分析系统、计费系统、网管系统等的深入使用, 为企业的运行积累了大量的历史数据。在多数情况下, 这些海量数据只是在原有的作业系统中供一些特定业务使用, 无法提炼和升华为有效的信息来供业务分析人员与企业决策者使用, 首先:联机作业系统由于需要保留足够量的详细历史数据, 以备后期查询, 从而使系统自身变得笨重不堪;其次:管理人员和决策者只能根据固定的报表系统获得有限的、零散的数据信息了解企业状况;再次:各专业间这些数据中的有效信息未能得到有效整合、关联、分析等处理, 使得历史数据没有被充分利用起来为业务开展提供服务, 因此难以适应未来激烈的市场竞争要求。
随着计算机技术的快速发展, 存储成本迅速降低和计算能力大大提高, 使得企业引入数据仓库成为必然, 它可以大大提高决策支持系统的能力, 并把企业决策者所需的信息从各个专业原始操作数据库中提取、分离出来, 把海量的、分散的、难以有效利用的原始数据转化为集中统一、随时可用的有效信息。
1 移动综合网管系统功能结构
根据网管系统所面向管理对象的不同, 可将其分为三大类功能要求:
1.1 面向移动通信网络部分
面向移动通信网络的管理部分主要功能包括:配置管理、性能管理、告警管理、拓扑监控、局数据管理等以及与移动通信网络相关的各种资源管理。这部分功能都是网管支撑系统中最基础也是最核心的部分, 它是网管系统的基石。
1.2 面向运维体制部分
这部分是面向企业运维体制和运维分析, 结合移动通信网络现有的运营思路和和维护模式, 面向运维体制相关的管理功能, 主要包括:报表管理、运行质量管理、维护管理及其他与运行维护相关的管理需求。
1.3 面向网管系统自身管理部分
面向网管系统自身的管理部分功能主要包含网管系统自身管理及安全管理功能。
从移动综合网管系统建设和演进发展思路来看, 这三大类功能并不都是独立存在的, 三大类管理功能之间是有数据依赖关系和管理功能支撑关系。
数据是移动综合网管支撑系统的基石。网络数据分布在多类网元中, 如MSC Server、MGW、HLR、BSC、RNC、SGSN、GGSN等, 区域和设备厂家也很分散。移动综合网管支撑系统正是通过对网元数据的采集、解析、关联、运算, 从而为网管系统使用者提供必要信息, 并为维护人员提供良好的运维支撑平台。
2 数据仓库概念简介
数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合, 用于支持管理决策, 我们可以从两个层面来理解, 第一, 数据仓库用于支持决策、面向分析型数据处理;第二, 数据仓库是对多个跨专业、异构的的数据源进行有效集成, 并在集成后按照主题进行重组。
企业数据仓库的建设, 将以企业现有业务系统的大量业务数据的积累作为基础。数据仓库并不是一个静态的概念, 只有把信息加以整理、归纳和重组, 并及时提供给相应的管理决策人员, 供他们做出改善业务经营的决策, 此时信息才能真正发挥作用, 而这个过程也是数据仓库的根本任务。因此, 从产业界的角度看, 数据仓库的建设不仅是一个工程, 更是一个过程。
整个数据仓库系统是一个包含四个层次的体系结构:
(1) 数据源:是数据仓库系统数据的源泉, 对于企业来讲, 它通常包括企业内部业务数据和企业外部数据。企业内部数据包括存放于数据库中的大量业务相关数据、企业内部各类文档资料等;而外部数据则包括市场信息、政策信息、竞争对手资料等;
(2) 数据的存储与管理:它是整个数据仓库系统中最为核心的部分。数据仓库的关键作用就是数据的存储和管理。由于数据仓库系统本身的组织管理方式决定了它不同于传统数据库, 同时也决定了其对外数据展现方式有所不同。企业需要从数据仓库的技术特点着手分析, 来决定采用什么产品和技术去建立自己的数据仓库系统。企业需要针对现有各业务系统的数据情况, 进行集成、抽取、清理, 并按照主题来进行组织。
(3) OLAP (联机分析处理) 服务器:对企业内需要分析的数据进行有效集成, 按业务需求进行多维模型的组织, 以便进行多角度、多层次、多方位的分析, 发现其内在趋势, 并提供数据分析和决策支持, 用不同的形式展现数据以满足用户的需求。
(4) 前端工具及应用:主要包括各种查询工具、报表工具、数据分析或挖掘工具, 以及各种基于数据仓库开发的工具应用等。
数据仓库具备良好的可用性、扩展性、易维护性, 弥补了传统数据库系统的不足, 使得业务相关的数据、模型、知识及方法的关联关系更加紧密, 极大的提高了现有业务数据的利用率, 从而使整个业务支撑系统变为一个有机整体, 提高了系统的集成性。数据仓库系统为移网综合网管系统提供强大的数据支撑能力, 一方面能极大限度确保各支撑系统间的数据一致性, 另一方面又支持目前应用系统业务的平滑扩展。
数据仓库系统的搭建将是一个逐步规划、循序渐进和逐步完善的系列过程, 当然, 一旦将数据仓库系统建立起来并投入应用后, 其数据分析和数据挖掘功能将为企业的管理和决策带来极大的益处。
3 移动综合网管数据仓库系统建设方案
3.1 系统建设原则
3.1.1 网管各专业基础数据的整合
针对网管系统中不同厂家、不同版本、不同网元粒度的原始数据, 规范现有数据的采集、命名、存储等过程, 严格而统一数据命名规范, 可以增强数据的可读性, 也便于将来数据的再利用;整理和修订已有系统的数据描述文档, 完善系统相关资料, 对数据库表结构、字段含义、字段属性等要有明确的定义, 对于新增的基础数据, 从一开始就需要准备好足够清晰的文档资料, 要避免与已接入系统的已有数据产生冲突, 保证数据一致性, 并落实底层个业务系统数据之间的关联关系, 使现有数据变得“透明”。
3.1.2 各业务系统数据质量的保证
所谓数据质量包括: (1) 数据的完整性;数据源是否完整、维度取值是否完整、数据间的约束关系是否完整等; (2) 数据的准确性;数据来源是否准确、映射算法是否准确、数据处理逻辑是否准确等; (3) 数据一致性;各业务系统之间同一指标数值是否一致, 系统中不同处理环节数据是否一致等。 (4) 数据的合理性;从业务角度判断数据源是否正确, 如“始发呼叫请求次数”与“呼叫继续次数”之间数值的合理性等。 (5) 数据的时效性;包括数据加工 (抽取、清理、转换等) 的及时性, 以及加工过程中发现数据异常时及时通知, 数据处理回退的及时性等。
3.1.3 业务系统数据模型的搭建
模型是所研究的系统、过程、事物或概念的一种表达形式, 是整个数据仓库系统建设的导航图, 要实现一个稳定、灵活的数据仓库系统, 模型是关键, 建模在设计工程上可以分为三大类:概念模型、逻辑模型、物理模型, 模型的建立要根据目前业务系统实际情况, 提出一个相对先进的模型, 不能太超前, 脱离实际或者导致工期太长, 也不能只停留在现有业务系统水平上, 那样失去了建设的意义。要在管理、使用、扩展、维护等方面适度拔高, 根据决策支持的需要来建设。
3.2 系统技术特点
3.2.1 跨专业业务支撑系统数据
由于将各专业数据预先进行了整合, 因此系统数据涵盖了上层应用所需的各类数据, 包括原始网管系统、动环监控系统、经营分析系统等基础数据, 为应用系统需求的快速实现提供了最基础的数据支撑, 而数据源的完整性、准确性、一致性是一个高质量数据仓库的必要前提。
3.2.2 灵活多变的数据组织模式
数据仓库系统采取了可靠有序的组织模式, 为跨专业、不同业务提供需要的服务, 能够针对管理决策层的要求, 搭建不同的多维数据模型, 从多角度、多侧面来观察各业务数据情况。系统具有很强的业务适应能力, 能够保证系统根据业务或市场决策的需要, 进行功能或主题的增加和规模扩充, 充分利用现有的资源, 并利用成熟的图形界面技术和经验, 保证用户界面的友好、易于使用和维护简单。
3.2.3 可靠而高效的数据存储
由于数据仓库对存储资源需求较高, 因此稳定而快速的数据存储能够最大程度的提高数据仓库的运行效率, 通过平台底层硬件冗余部署, 利用带库或虚拟带库进行关键数据的备份, 都将有效提高数据存储的安全性和可靠性。
3.2.4 统一的技术架构
数据仓库系统按照“自下而上、分而治之”的螺旋式开发方法, 系统建设的风险和成本会大大降低, 同时保证了平台的易使用性、易维护性、可扩展性和可持续发展性。在数据仓库系统中对原始数据在采集、清洗、计算、存储各环节都增加了相应的监控。数据物理存储根据业务特点进行适当分离, 采用数据分割技术, 将数据按照不同专业特点分散到各自的物理单元以便能够独立处理, 提高数据处理速度, 便于数据的重组和维护, 增加系统并行性, 提高了后续应用开发的效率, 同时对跨专业的关联分析应用提供良好的数据支持。
3.3 系统实现方式
按照企业决策层或用户需要, 进行移动综合网管数据仓库系统的模型设计, 设计时需要确定系统的边界, 所包含的主题域等, 此时需要有一个对业务需求、各专业现有数据情况非常清晰的专业人员, 然后开始各专业业务系统间的数据装载接口的设计, 采集程序对数据库进行原始数据采集、处理、存储;入库前, 对相关数据要进行过滤和筛选。按照网元类型或业务类型, 采取“抽取—转换—清洗—入库”的步骤。其中数据的存储、备份等工作将结合综合网管系统应用的开发工作或原支撑系统的改造工作一起逐步展开。在同一个模型的指导下, 根据数据仓库的主题域、通用维、业务规则建立不同数据集市, 按设备厂家、设备类型、报告类型等, 划分不同任务, 并行组织开发。
数据仓库创建后, 数据装载进程将从数据源抽取、转换、清洗后将数据采集到综合网管数据仓库中, 数据装载策略需要考虑装载周期以及数据追加策略两方面, 根据各专业业务数据实际情况, 装载周期应当综合考虑业务需求和系统装载的代价, 不同业务系统采用不同的装载周期, 但务必保证统一时间业务数据的完整性。系统应对数据采集进程有实时的监控, 一旦发现数据采集异常退出, 系统应能够自动重启数据采集进程, 并通过短信平台将错误信息发送给维护人员。同时, 数据装载进程需要有数据完整性校验机制, 一旦发现数据不完整, 可自动触发数据采集程序进行补采, 并在系统日志有记录。
在完成将数据加载到移动综合网管数据仓库后, OLAP服务器会根据最终的服务请求分解OLAP各种操作, 并使用数据仓库中的这些数据完成这些操作, 然后将处理结果通过前端工具以直观的方式来展现。
4 结束语
随着运营商网络维护和经营工作的逐步开展, 特别是在“全业务”运营模式下, 实现灵活多变的市场营销策略, 为客户提供更具针对性的服务, 同时最大限度合理配置和优化自身资源, 降低运营成本, 需要将网管各专业大量的数据运用多种分析方法进行深层次的挖掘, 让企业管理者了解网络的发展, 并为其决策提供丰富、真实、及时的运维信息。本文只是数据仓库在移动综合网管中的应用进行了初步探讨, 在实际工作需要按照应用和各专业实际情况, 逐步构建和完善数据仓库的模型, 使数据仓库技术能够真正为移动综合网管业务开展提供重要作用和服务支持。
摘要：由于移动通信业务涉及的网元种类繁多, 相关专业支撑系统相对独立, 企业管理层迫切需要从大量的跨专业数据中获取有效信息, 实时制定有效的决策, 提高企业的整体竞争力。移动综合网管系统是移动通信业务支撑的基础, 而数据仓库又具有对异构数据重新进行组织, 并对大规模数据进行综合分析的能力, 因此数据仓库技术在移动综合网管系统中的应用具有广阔前景。
关键词：移动综合网管,数据仓库,移动网管,移动通信
参考文献
[1]郑岩编著.《数据仓库与数据挖掘原理及应用》.2011-01-01/清华大学出版社.
[2]段云峰等编著.《数据仓库及其在电信领域中的应用》.电子工业出版社.
[3]徐洁磐编著.《数据仓库与决策支持系统——数据库应用系列丛书》2005-04-01/科学出版社.
移动网管 篇7
近几年移动通信行业发展迅速,用户数递增迅猛,运营商为了满足市场需求,网络建设规模也不断加大,并且同一个运营商还同时兼营多张网络。在这种运营环境下,移动综合网管系统管理的网元类型、网元数量也不断的增加,存储的数据量也呈几何级递增,各种网元的性能测量、故障等数据存储都从之前的G级别变为现在的T级别,尤其是经济发达的沿海地区,网络覆盖更为密集。
这种大数据量的存储给业务系统在做支撑时带来很大的性能压力、稳定性压力。例如:一张GSM小区的性能测量数据表,按每小时采集一次性能测量数据,小区数为5.5万个,存储时间为3年,表的大小可达到380G,而整个系统的数据总存储量会达到5T,可见整个系统中大表的数量是很多的。而这类大表要是没有合适的管理机制,还是以小表的方式来进行维护,会对整个业务系统的运行以及数据库的管理都会带来很大的影响。
2 大表对系统的消极影响
移动综合网管系统在大表模式下带来的消极影响主要可以体现在以下几个方面:
1)数据查询的系统开销大
由于表的数据量和索引都非常庞大,查询数据时的系统开销非常大。如果查询优化器选择全表扫描时,基本上执行不下去;数据的在磁盘上的分布比较单一,导致磁盘I/O容易集中在某一块,直接影响整个数据库的性能。
2)表管理的系统开销和风险大
表的整体性太强,管理上只能作为独立单元,管理负担比较重,管理过程中容易波及到整个系统。
以小区性能表为例,其中一个索引要占用的空间为38G,如果要重建该索引,需要将38G的索引作为一个完整的独立单元来操作,这会占用大量的系统资源,严重的话可能会导致系统崩溃;即使可以在线重建成功,重建的过程中该表资源被独占,影响业务系统数据的正常入库;空闲空间要求比较大,需要38G的空闲存储空间来存放索引副本,还需要一个临时事务日志表来记录重建索引期间对表所做的修改;还需要考虑的一种情况是重建期间出现意外导致重建中断,前面的所有工作都会失效,一切需要从头开始,风险不可控。
3)数据维护的系统开销大效率低
如果需要迁移某个月或者某周的数据,我们很难使用高效的方式来完成,整个过程非常漫长,还有可能是不可接受的。
另外这种性能测量数据的存储量是按时间递增的,当达到一个周期后,需要删除旧的数据以满足新数据的存储。而从一个大表里面删除大量的数据需要消耗大量的系统资源,很容易消耗掉回滚区,影响整个数据库的性能。
4)数据的可用性风险高
占用的存储空间大,在阵列环境下存在跨多个存储磁盘的情况,只要该表的存储空间中有一个数据块或者相关存储磁盘有问题,就很有可能会导致整张表不能被访问,直接影响到整个业务系统。这种情况如果要修复数据,系统必须关闭,直接影响到系统的可用性。
以上几个方面的主要原因是一张独立单元的大表,它是一个很大的整体。如果能将该表分割成多张小表,并且在业务系统使用时逻辑上又是一张大表,就能解决这些难题。而oracle提供的分区工具能帮助我们将大表进行分割管理。
3 Oracle分区技术
Oracle分区工具将表或者索引物理的分割成多个小单元。应用时从逻辑上看是一个表或者一个索引,而物理上却都是独立的对象,并且都可以独立管理。Oracle提供了范围分区、列表分区、哈希分区和组合分区方法分区。
3.1 范围分区
范围分区是根椐分区键的不同取值范围来指定存储在一起的数据,这是目前较常用的一种分区机制。范围分区的关键字是RANGE,VALUES LESS THAN:
3.2 列表分区
列表分区是根椐分区键的枚举离散数据集来指定存储在一起的数据。例如指定分区健值在{’杭州’,’宁波’,’舟山’,’丽水’}里面的存储在一个分区里面,分区健值在{’温州’,’台州’,’金华’,’衢州’}里面的存储在另一个分区里面。列表分区的关键字LIST,VALUES:
3.3 哈希分区
哈希分区是在分区健上建立一个哈希函数,数据会根据哈希函数的结果值来选择对应的分区。哈希分区方法会随机的将数据均衡的分布到不同的分区上,因此无法控制哪些数据该分布到那个分区上。关键字HASH,PARTITIONS:
3.4 组合分区
组合分区是范围分区和哈希分区的组合应用,组合分区支持两级,顶级的分区机制必须是范围分区,第二级是针对每个单独的范围分区使用列表分区或者哈希分区。
4 Oracle分区技术在移动综合网管系统中的应用
4.1 选择分区表策略
移动通信行业的性能测量数据都是按照时间进行存储的,随着时间的推移数据量会越来越大。以上面提到的小区性能测量表为例,数据每小时采集1次,数据量如表1所示。
数据存储周期是三年以上,业务系统的数据分析基本上是以周或者月作为周期。鉴于数据量的分析以及业务系统的需求可以以周为周期使用范围分区法进行分区,即7天的数据存储在一个分区里面。
4.2 选择分区索引策略
跟分区表对应的有分区索引,索引跟表类似,也可以分区。oracle提供了两种类型的分区索引:
1)本地索引
本地索引的分区方式跟它所在基础表的分区方式一样。索引分区跟基础表的分区一一对应。
2)全局分区索引
索引按照范围(9i/10g版本都支持)或者哈希(10g版本支持)分区,一个索引分区可以指向任意一个表分区。使用全局分区索引时需要注意索引分区数跟表分区数可能不同。
根据对移动综合网管系统的数据分析,采取本地索引分区更加合适。如果采取全局分区索引,那么在进行数据维护的时候很容易导致索引失效,需要经常性的索引重建,这会非常浪费系统资源。如下方式建立本地索引:
create index UIDX_pmcell on pmcell(start_time)local tablespace tp_indx;
4.3 分区后的效果
经过分区改造后的数据库和系统在使用体验和维护上都有了非常大的进步,上面的几个问题也得到了有效的解决。
1)数据查询的效率提高
分区后查询数据时可以只查询有效分区的数据,范围外的分区可以不用扫描。这将大大提高表查询的效率。
多个分区可以分布在多个表空,这就意味的数据可以分散在更多的磁盘上,I/O的均衡情况会有很大的改观,系统资源会得到充分利用,也会直接提高数据查询的效率。
2)有效的降低数据维护的开销
现在如果要删除某一周的数据,可以使用drop来删除某个分区,这种效率是使用delete命令不能比拟的,并且不带事务,系统资源占用可以忽略不计,如下语句:
alter table pmcell drop partition P201003160000
如果要导出某一周或者几周的数据,可以使用exp等高效方式来实现,如下语句:
3)表的可管理性大大提高,降低dba的维护负担
如果现在需要进行重建索引,那么重建索引的过程可以按分区分别进行,那么开销只是一个分区单元所消耗的,临时空间也是一个分区所需要的。
4)提高数据的可用性
分区状态下,如果个别分区出现了损坏,并不影响整张表的使用,只要查询的数据不在损坏的分区内,就可以正常访问。即使要恢复这些损坏的数据,也可以在不停业务系统的情况下在线处理。
5 总结
移动综合网管系统在应用分区技术对大表进行管理后,整个业务系统的性能得到了很大的提升,这是最终用户的体验,尤其系统在进行环比、同比等数据分析时平均响应速度至少提高10倍以上。同时也减轻了DBA的管理压力,特别在历史数据备份、历史数据恢复、数据修复、数据迁移方面,不用担心这些操作会影响系统使用、导致数据库宕机。
总之,在目前海量数据库越来越多的情况下,分区是极其有用的。当然分区只是一种手段,应用了分区技术还需要有相应的分区维护管理机制,否则像索引失效、范围分区没有及时分配等问题也同时存在。技术应用加上良好的管理才能真正体现出价值。
参考文献
[1]Thomas Kyte.Oracle9i&10g编程艺术:深入数据库体系结构[M].苏金国,译.北京:人民邮电出版社,2006.
[2]Price J.Oracle Database10g SQL开发指南[M].冯锐,由渊霞,译.北京:清华大学出版社,2005.
[3]Donald K.Burleson.Oracle高性能SQL调整[M].刘砚,黄春,译.北京:机械工业出版社,2002.
[4]盖国强,冯春培.oracle数据库性能优化[M].北京:人民邮电出版社,2005.
移动网管 篇8
本文以省级移动通信网管为研究对象, 移动通信网管功能为出发点, 以电信管理网 (Telecommunication Management Network, TMN) 体系结构为基础, 设计了移动通信网络管理系统数据处理层总体软件结构, 并给出了基于XML的详细设计。
1 TMN网络管理功能模型
网络管理涉及网络资源和活动的规划、组织、监视、计费和控制, 国际标准化组织一直致力于网络管理的标准化工作, 它定义了故障、配置、性能、账务和安全五大管理功能区域, 是网络管理系统最基本的管理功能。TMN网络管理功能模型如图1。
1.1 性能管理
性能管理是一组评价管理对象行为和通信活动有效性的设施, 提供对通信设备的性能、网络、或网络单元的有效性进行评价和给出报告的能力。性能管理的基本功能是收集统计数据, 对网络和网络设备的性能进行监视, 以便发现和校正网络或网络设备的性能和有效性偏离或下降, 并对网络的规划和设计提供支持。性能管理通常通过采用一定的性能指标来评价网络是否满足吞吐量的要求、是否有充裕的响应时间、是否过载或网络是否得到有效的使用。性能管理必须实现以下功能:性能监测功能、业务管理和网络控制功能、服务质量监视功能。
1.2 配置管理
网络的配置是网络上各种工作设备、备份设备、设备之间关系的状态, 为了保证网络经济、可靠、安全和高效的运行, 需要对网络上的配置进行调整。配置管理就是网络管理系统根据需要对网络中的网络单元 (NE) 进行控制和标识, 并从网络单元收集数据和给网络单元提供数据。从网络运行的角度看, 配置管理可以分为两个阶段:网络 (或设备) 初次运行的初始配置管理 (通常称为网络指配, 也称为网络预配置) 和网络 (或设备) 正常运行时的工作配置 (通常称为配置控制) 。从管理对象的角度看, 配置管理的对象分为两类:被管理网络本身和网络管理质量控制模式。
1.3 故障管理
故障管理是检测和确定网络环境中异常操作所需的一组设施。无论故障是短暂的还是持久的, 都可能是导致网络系统不能达到预期的运营指标。故障管理设施通过检测异常事件来发现故障, 通过日志来记录故障情况, 根据故障现象采取相应的跟踪、诊断和测试措施。故障管理有关的管理参数主要包括故障类型、故障原因、故障级别和故障时间等。
2 TMN的框架结构
为了适应现代电信网的发展, 1985年国际电报电话咨询委员会 (CCITT) 提出了TMN的构想, 用于实现对异构型互连网络、设备与业务进行有效的管理, 定义了TMN的框架结构、功能模型、信息模型与物理模型。TMN作为对电信网进行集中统一管理的解决方案, 目前已成为现代电信网络管理的发展方向, 没有TMN技术, 跨过多个电信子网提供业务将是非常困难的。TMN以灵活而有效的方式管理电信网。它将为电信网提供各种管理功能, 并且为TMN与电信网之间的通信提供各种通信机制。为此, 应提供一套有组织的网管体系结构, 以便把各种类型的操作支撑系统与电信设备相互连接。这可由采用统一的、带标准协议与标准接口的TMN网管体系结构来实现。下面主要介绍TMN与电信网的关系。
图2给出了TMN的原理框架结构。TMN建立在基础网之上, TMN按功能划分可以分成五层, 而管理功能 (如配置管理、故障管理等) 可根据需要安排在相应的管理层中。各管理层的任务如下:
网元层:由庞大的网元 (NE) 构成, 负责网元本身的基本管理功能。
网元管理层:监控网中某个区域的网元, 包括收集有关的统计数据、记录数据及与网元有关的其他数据。并允许网络管理层通过它与网元层进行会话。
网络管理层:监控网中的所有网元。它允许对网络进行重构, 并允许与业务管理层进行网络性能、利用率和可用性方面的交互式会话。
业务管理层:处理契约性业务, 如顾客与网络操作员接口, 与业务提供者进行交互式对话, 某一顾客将要访问的统计数据以及与商务管理层进行交互式会话。
商务管理层:处理网络操作员所有对顾客的提交, 如网络操作员之间的约定。
目前, 网元层、网元管理层与网络管理层已经制定了最终的国际标准, 而业务管理层与商务管理层正在进行国际标准化。
3 移动通信网管数据处理层总体结构设计 (见图3)
原始数据通过数据采集层进入系统后, 数据处理层对这些原始数据进行归纳整理, 实现数据结构规范化, 形成网管系统核心数据库, 为数据应用层实现具体功能提供支持, 便于系统的二次开发和新应用功能的提供。网管核心数据内的数据分为两部分:其一为各厂家原始数据库, 存放不同厂家各自的原始数据;系统数据库, 存放经过归一化处理的数据、汇总数据、系统设置数据、数据库日志资料等数据。数据处理层包括信息归一化、配置数据的存储、刷新和备份。还需要经过数据处理层进一步的处理。数据处理层的主要任务就是将各厂家不同的数据内容转化为统一的格式, 并将其保存在归一化数据库中。因为每次设备版本升级时, 数据内容都会有较大的变动, 所以要求数据处理层能够动态地容纳这种变化。数据处理层的数据处理工作可以分为两个部分:文本解析部分和数据汇总及归一化处理部分。文本解析又称为数据预处理, 它根据厂家提供的数据格式说明采用统一的文本解析模块对数据格式进行解析, 把文本格式的数据转换为数据库格式的数据, 从而把采集过来的数据文件的信息方便地存入数据库中。通过数据库复制的方式采集的数据不需要数据解析的过程, 因为它是把数据库格式的数据从一个数据库复制到另一个数据库的过程。经过文本解析后得到的数据仅仅是厂家提供的一种原始数据格式, 它与中国移动要求的TMN数据格式并不一致, 必须经过数据汇总和归一化处理后才能形成标准的TMN格式的数据。数据汇总和归一化处理是根据中国移动集团公司的要求, 将原始数据库中的内容经过一定的运算和处理, 转换成统一的数据格式, 从而形成可供查看和分析的各种指标, 并将其保存在归一化数据库中。
数据处理层包括配置数据、告警数据和性能数据处理三方面。以配置数据处理为例:
3.1 配置数据归一化
配置数据采集到网管系统之后, 必须进行归一化、数据结构规范化, 使应用层能够方便地使用这些数据。配置数据按交换子系统、基站子系统、中继路由设备、操作维护中心 (OMC) 、GPRS相关设备和移动智能网相关设备六个方面进行归一化处理。
3.2 配置数据的存储
省网管系统应能够将不同种配置数据转换成以上描述的归一化标准数据格式并存储到数据库中, 为性能、告警等应用提供数据支持, 为二次开发或其他的后处理提供标准的存储接口。
3.3 配置数据的刷新
省级网管系统发现新的配置数据采集结果与网管数据库中的配置数据不同时, 如网元的增加、删除、网元属性改变 (何种属性) , 需要用户确认, 并生成变更记录, 作为采集日志的一部分, 供用户后期查询, 同时更新网络拓扑图等相关的上层应用程序的配置数据, 使上层应用能够呈现网络的最新配置信息。可根据用户配置按网元进行自动或手动数据刷新, 配置数据变更日志在线存储不少于6个月, 时间可根据用户需要设定。超过存储期归档后用磁带或光盘转存。系统提供归档数据的查询处理工具。
3.4 配置数据的备份
省级网管应提供对配置数据的快照功能 (即备份功能) , 用户通过此功能可将当前网络的配置信息存储下来, 供其他应用所调用。快照可以由网管系统按照时间表的设置自动进行或由用户手动启动。快照功能可以按网元进行, 可以用磁带或光盘进行数据备份。快照后的配置信息可用于:网络配置信息的历史对比;配合性能, 告警数据做网络多维分析。
4 基于XML移动通信网管数据处理层详细设计 (见图4)
数据处理是一个繁琐的过程, 其难点在于程序应能动态地容纳设备版本升级等造成的数据内容的变化。采用数据字典可以很好地解决这个问题, 把厂家提供的数据格式和中国移动要求的数据格式及其数据之间的运算关系均以数据字典的形式保存, 程序依赖于数据字典对数据进行处理。每当数据格式和内容发生变化时, 可以改变数据字典的内容即可方便地实现升级, 从而做到程序与业务的真正无关性。可扩展性标识语言XML是另一种可以用来解决该问题的技术, 它通过XML文件来保存数据, 并通过DTD (数据类型定义) 文档对XML文件进行规范, 通过修改DTD文档可以达到数据格式和内容升级的目的, 因为XML允许用户定义自己的元素标记与属性, 所以它必须有一个式样表, 指定如何显示自己的元素。用户需要一种机制, 将自己的文档与式样表联系起来, 还需要一种机制, 防止自己的标注与网上其他人的标注发生冲突。所有这些都有相应的规范。XML样式的表现技术是由数据驱动的。XML的样式化是通过一个被称为样式单的文档来实现的。用XML文档存储数据, 并且XML中的数据也可以导入到高性能的关系型数据库中。每个主要的数据库厂家都提供了 (或准备提供) 在关系型数据库与XML之间的传输数据的方法, 而且还有很多第三方软件。数据可以从任何数据库中方便地读取, 转换到XML中。这样如果我们编写的程序是使用XML数据的, 那么就可以把程序到处移植而不需要修改代码。这就是将应用程序编写成使用XML数据的最大的优势。但是, 通过目前应用来看, XML技术还不成熟, 还有一些“瓶颈”没有突破。比如, 要把一个3 M的性能数据文件以XML文件形式保存, 其需要的存储容量近30 M;而相同的数据若要以数据库形式保存, 其占用的容量不到3 M。从目前情况来看, 在网管系统中, 大量的数据要用XML文件形式保存有很大的困难, 还需要进一步的探索。
参考文献
[1]孙青卉, 王钧铭.移动通信技术[M].北京:机械工业出版社, 2001:7-38.
[2]孟洛明, 亓峰.现代网络管理技术[M].北京:北京邮电大学出版社, 1999:2-29.
[3]陈建亚.现代通信网监控与管理[M].北京:北京邮电大学出版社, 2000:2-48.
[4]陈德荣, 林家儒.数字移动通信系统[M].北京:北京邮电大学出版社, 1996:62-75.
[5]孟洛明.通信网网管系统建设中的基本问题、现状和发展[J].通信世界, 2000 (7) :2-4.