通信基站运维综合标准管理专业系统设计项目说明指导书.doc

第1章 绪论本文重要简介通信基站运维综合管理系统V1.0设计与实现。本章一方面简介本系统背景知识以及研究意义；然后阐述国内外研究以及开发最新动态，最后简介本文重要内容以及组织构造安排。1.1 研究背景与意义本节重要简介本文涉及某些无线通信知识，一方面简介与本文描述通信基站运维综合管理系统V1.0有关WCDMA概念，UTRAN系统，RAN系统以及Rbs知识，然后详细描述本系统在WCDMA系统所处位置和该系统所需要提供功能。最后再系统阐述本文研究意义。1.1.1 3G无线通信有关知识 WCDMA1：Wideband Code Division Multiple Access宽带码分多址。是一种由码分多址（CDMA），演变而来第三代无线通信技术。WCDMA采用直接序列扩频码分多址、频分双工方式。WCDMA是一种由3GPP详细制定，基于GSM MAP核心网，UTRAN为无线接口第三代移动通信系统。 UTRAN：The UMTS Terrestrial Radio Access Network，陆地无线接入网。信令网和数据传播网在逻辑上分开2；UTRAN和CN功能将和传播功能完全分开；UTRAN和CN使用寻址方式将和传播功能寻址方式无关；宏分级（FDD模式）解决完全在UTRAN内，RRC连接移动性完全由UTRAN控制；定义UTRAN接口时候，通过接口功能划分应有尽量少可选项；应基于此接口控制实体逻辑模型。 UTRAN由一组通过Iu接口连接到核心网CN无线网络子系统RNS构成。一种RNS由一种无线网络控制器（RNC）和一种或者各种节点（Node B）构成。Rbs通过Iub接口连接到RNC。图1.1是UTRAN系统某些平面构造图。从图中可以看出：RNC重要负责跟核心网交互以及与Rbs进行交互。Rbs重要负责与RNC交互，以及顾客手机交互。从软件架构角度，UTRAN重要分为如下3个逻辑节点： （1）RNC（Radio Network Controller）无线网络控制器。RNC重要负责跟核心网以及Rbs进行交互，并且负责管理无线链路。RNC控制通过Rbs信息量。RNC同步负责建立信道，解决与UE连接，控制无线基站资源优化。WCDMARbs提供无线资源以及无线广播，并且负责接受与发送UE信号。图1.1 UTRAN系统平面构造 （2）OSS-RC (Operation Support System-Radio and Core) 运维支撑系统-无线基站跟核心网。OSS-RC重要解决从RNC过来操作管理任务，例如软件安装与升级，RAN层管理配备，告警解决等。 （3）COMINF (Common Operate&Manage Infrastructure) 通用操作管理架构。COMINF重要管理涉及从网络设备到OSS-RC所需要携带路由等网络合同。COMINF同步提供安全性服务，客户协助信息，软件管理，备份解决方案等服务。UTRAN拓扑构造和核心节点外部接口如图1.2所示：（节点跟接口在下图中仅仅是一种逻辑插图，跟实际状况不一定完全吻合。例如Mub和Iub接口也许承载相似媒体，W-Rbs也也许以级联拓扑形式连接）Rbs3（Radio Base Station）：WCDMA中Rbs就是UTRAN系统节点中基站特有名称。Node B是一种逻辑节点，负责发送，接受从UE过来信道。Rbs节点除了解决最基本功能以外，同步还控制与监管天线设备。Rbs通过luant接口或者其她某些专有规范原则来控制与监管TMA、RET等天线设备。Rbs Element Manager：基站管理软件，并不是UTRAN系统中一种独立节点，但是她是Rbs系统一某些，EM普通运营在PC端口，控制了包括一系列操作管理应用软件安装。Rbs Cabinet Viewer：机箱机柜查看器，是布置在OSS-RC上一种应用程序，但是她依然属于Rbs系统一某些。机箱机柜查看器提供了一种可视化视图，并且提供了一种工具来解决由事件干扰引起错误。图1.2 UTRAN系统拓扑构造图1.3是Rbs所处位置以及Rbs与其她节点关系：图1.3 Rbs与RNC、OSS-RC关系从图上可以看出：Rbs重要通过Mub接口与OSS-RC交互，通过lub接口与RNC交互，通过Uu接口与UE交互。管理软件EM在OSS-RC节点上，负责管理与配备Rbs4。图1.4是Rbs外部接口平面图：图1.4 Rbs外部接口Mub：Mub接口是由Rbs所提供，由管理软件EM，机箱机柜查看器，网络管理系统等系统使用。Iub：连接RNC跟Rbs有关接口。GUI：（Graphic User Interface）由管理软件EM或者机箱机柜查看器提供，提供了一种顾客和谐型图形化界面给基站操作人员操作和维护Rbs。VMI： （Visual and Mechanical Interface），重要提供应基站站点操作人员使用。VMI重要涉及可视化批示器（LED灯），手动可操作开关/按钮（复位键）和传入外部电源等。此外，装配电缆螺丝等都属于这个接口。1.1.2 基站管理软件功能ITU-T TMN：Telecommunications Management Network standard from the ITU-T) 国际电信联盟电信原则化部，电信管理网络。由于该软件系统紧紧负责基站管理与配备，暂时不考虑traffic事件某些，仅考虑操作管理某些。TMN操作管理某些方略重要由： 代理模式使用，例如OSS-RC作为管理人，Rbs EM作为代理。 使用管理对象（Managed Object，MO）模型，即管理一系列抽象或者物理或者逻辑上资源。 管理信息库（Management Information Base，MIB）使用，即一种存储了TMN中所有MO信息库。 管理信息模型（Management Information Model，MIM）使用，即抽象出一种面向对象语言来抽象规定MO定义，定义MO数据基本操作。 一种基本逻辑架构模型如图1.5所示：图1.5 TMN管理某些逻辑架构模型本文所描述通信基站运维综合管理系统V1.0是一种OSS-RC系统下子系统服务，从TMN管理某些架构逻辑模型上来看，该系统处在架构在体现层。普通，配站工程师会在软件中对基站进行配备，该软件系统将顾客配备基站数据信息收集起来，通过MO携带数据，通过COBRA等公共合同与指定基站进行通信，向下层传送管理和配备信息，将所需配备信息发送到指定基站中央解决单元，而在基站端，普通会有一种类似于接口子系统，对发送过来消息进行解析并解决，并将配备信息进行反馈。这样就可以做到基站安装跟配备分开进行，并且还可以随时对基站进行调控容量，监视基站中设备状态等操作。基站通信构造示意图如图1.6所示:图1.6 基站通信构造本文中通信基站运维综合管理系统V1.0重要提供如下功能：功能特点：1，IT资源可视化，轻松读懂各种IT数据2，业务拓扑视图，直观呈现出业务与IT关系3，IT资产管理与IT监控管理、运维流程管理等无缝集成，实现对以虚拟化和云计算为核心支撑IT体系综合管控。4，完善IT网络运维管理体系，依托统一服务支持平台，形成自动化、流程化服务支持。技术特点：1，运营环境安装配备以便(.NetFramework,Asp.Net,IIS)2，技术成熟，主流技术，配套技术文档完善，众多开源或免费文档或项目可供参照3，拥有众多新技术，以便构建公司级应用4，开发布置工具功能强大5，能与Windows平台紧密结合，最大限度运用系统功能1.1.3 研究意义 随着中兴，华为等新兴无线通信公司崛起，无线通信行业竞争越来越激烈，各大公司纷纷推出了新产品，软硬件更新速度日益加快，而市场上也浮现了基站类型新旧各异，功能各异复杂状况，虽然是同一站型，也会由于需求变动而导致硬件不同，或者设备参数不同等问题。将原有硬件进行整合，升级改造，已经成为了当前3G基站发展一种主流趋势。这样不但仅可以节约成本，复用原有硬件设备，提高运用率，同步可以在更好兼容基站原有设备基本上，达到硬件微小改动，功能大大提高，基站大不同样特点。当前市场上某些基站管理配备系统，由于需求已经随着市场变化而发生了重大变化，从原有固定不变，几乎很少改动硬件架构，变成当前这种需求随着市场变化而迅速变化状况。以市场为导向新需求，使得软件层次架构变动势在必行。原有架构层次过于简朴，在新项目开发中浮现了架构兼容性不够，代码耦合度过强等问题，导致系统难以维护，升级，一旦有新需求变化，总会进行大幅修改，显然已经无法适应产品不断更新新规定。如何设计出一种通用基站管理系统，满足需求经常变动特点，成为一种亟待解决问题，也是本文重要研究目。1.2 国内外研究动向 爱立信：爱立信基站管理系统采用了CI/RI（Configuration Item/Resource Item）架构。将基站资源抽象为一系列Resource Item，将一组相近资源以汇集形式构成Configuration Item，构建出一种逻辑上Rbs进行配备。该管理系统使用了MVC，Java Bean，SAX等技术，提供了一种顾客和谐型界面，通过一种通用平台CPP与基站端进行通信。客户端到基站端通信使用了COBRA技术解决并发。当前爱立信在市场上主流基站及新硬件设备如图1.7所示5。图1.7 爱立信主流基站及新硬件设备 华为6：提供了一种基于JAVA Web网页版基站软件管理系统。该管理系统使用了J2EE架构，并且使用了Struts+Hibernate+Spring等比较流行框架。图1.8是某些华为在WCDMA市场上主流基站。图1.8 华为在WCDMA市场上主流基站1.3 本文重要内容 本文一共分为五章，系统简介了通信基站运维综合管理系统V1.0设计与实现，下面从分章节角度详细阐述本文将要阐述重要内容： 第一章：一方面简介了本系统所需要无线通信背景知识，该系统在UTRAN系统中所处位置以及该系统所担当职能等，另一方面简介了国内外研究开发动态，本章最后简介了本文重要内容。 第二章：重要简介了本系统需求分析以及详细架构设计。在需求分析中使用了ADMENS矩阵分析法。架构设计时候先简介系统总体架构设计，再分层分别简介每一层设计。在简介时候不但仅简介了设计思路，同步从设计模式角度给出了实现方略。 第三章：依照上一章设计出架构，分架构层次，依次详细阐述了每一层实现过程。实现过程重要以详细UML类图以及时序图为例进行阐述，同步将设计过程中用到设计模式串联起来。 第四章：描述了系统测试重要办法，以及本系统测试环节，最后展示了某些测试用例，同步总结了测试成果。第五章：总结了本论文重要工作，分析系统中某些值得改进地方，并且提出了后续研究某些展望。第2章 通信基站运维综合管理系统V1.0需求分析以及设计本章详细描述了基站管理系统需求分析与架构设计。在需求分析中应用了ADMENS矩阵分析法进行分析，架构设计时候体现了分层思想，同步为了更好局部构造，设计模式在本系统中得到了充分应用。2.1 系统需求分析通信基站运维综合管理系统V1.0提供了一种基站管理配备平台，针对不同种类基站进行配备，同步提供了对基站配备进行修改，删除，以及导入导出配备脚本等功能。在进行本文需求分析时候会借助ADMENS矩阵进行分析。ADMENS矩阵7（Architectural Design Method has been Extended to Method System，架构设计办法已经扩展到办法体系），又称为“需求层次-需求方面矩阵”。该矩阵分析法可以协助架构师告别需求列表陈旧方式，顺利过渡到二维需求观，借此避免漏掉需求、并进一步清理需求间关系和发现衍生需求。ADMENS二维矩阵进行需求分析“四步法”重要由如下4个角度分析：需求构造化，分析约束影响，拟定核心质量以及拟定核心功能。从“需求定义了直接还是间接目的”角度，把需求划分为3种类型：1. 功能需求：直接体现出各个需求目的规定。2. 质量属性：由运营期质量和开发期质量构成。3. 约束需求：由业务环境因素，使用环境因素以及技术环境因素构成。从业务级需求，顾客级需求，开发级需求三个角度对本系统需求进行详细分析，形成一种二维需求分析矩阵。总结成下表：表2.1 ADMENS矩阵广义功能质量约束业务级需求业务目的快、好、省技术性约束法规性约束技术趋势竞争因素与竞争对手遗留系统集成原则性约束分批实行顾客级需求顾客需求运营期质量顾客群特点顾客水平多国语言开发级需求行为需求开发期质量开发团队技术水平开发团队磨合限度开发团队分布状况开发团队业务知识管理：保密规定管理：产品规划安装、维护2.1.1 业务级需求分析本段重要根据：包括客户或者出资者要达到业务目的、所需要预期投入资金、项目工期进度规定，以及要符合哪些原则规范、对哪些遗留系统进行整合改造等约束条件，对论文中阐述系统进行业务级需求分析。下面详细阐述本系统需要重要考虑约束条件。 (1) 客户业务目的以及业务愿景。1. 软件定位：基站管理软件 2. 提供服务：提供一种通用管理配备平台，对同一家公司不同类型，不同硬件基站进行配备。 (2) 客户业务质量 1. 兼容新老基站。由于技术改革，软件必要兼容各种各样新老基站，在满足新基站配备规定同步要做到向后兼容。特别是基站硬件更新，各大无线通信公司当前都在做整合研发，将老基站几块硬件板子功能集成到一块硬件上创新研究，软件变更需要跟硬件变更同步化，满足硬件变更所带来配备变更。 2. 易于变更配备。同一款基站，很有也许会配备不同射频单元，或者有扇区变动配备需求，需要提供一种简洁而又实用向导来满足配备变更，同一种硬件配备也需要可以以便修改承载能力等，以达到资源运用合理化。 (3) 技术原则 3GPP，以及各大厂商自己制定原则。 (4) 对哪些遗留系统进行整合 基站零部件种类繁多，各种型号基站之间硬件配备有较大区别，需要一种扩展性很强系统来代替原有系统，以便将来产品进一步更新换代。2.1.2 顾客级需求分析顾客及需求分析重要从如下几种角度入手：顾客需要使用系统来完毕哪些工作，对质量有哪些规定，顾客群及所处使用环境方面有哪些规定等条件来进行顾客级需求分析。下面结合本系统进行分析： （1） 顾客使用系统完毕辅助工作 该系统重要顾客人员是基站配备人员，她们使用该系统进行基站配备，修改，删除等操作。配备向导里面配备项有某些是有跟详细硬件有关默认值，尚有某些必要要顾客来配备，这些配备向导按照基站配备流程分各种页面进行。该基站管理软件重要提供四个配备向导界面：1. 机箱/机柜配备向导： 这某些配备硬件设备，除了基带信号解决板配备，尚有某些硬件板，普通在交付客户之前，在工厂就有某些烧制或者录入默认配备，插入机箱机柜中，因此需要在这里一并配备。在这个配备向导里面需要配备重要有：选取Rbs类型，配备默认IP地址，接口板等硬件设备。2. 基站站点配备向导 重要功能是建立扇区，配备社区，天线系统有关硬件，电缆有关数据，该某些需要配备硬件组合相对比较灵活，可以依照基站承载能力等条件，自由组合配备。3. 修改配备向导 该配备向导比较特别，该功能实现需要借助XML+SAX来实现，因此该配备向导输入仅为XML修改配备文献。该向导重要配备页面仅仅由一种文献输入页面以及需要修改目录成果构成。4. 导入导出，删除向导 这几种功能也都是通过XML+SAX实现，因此该配备向导同上，输入/输出仅仅为XML文献。（2） 质量规定1. 操作以便，界面和谐。2. 系统具备很强健壮性，尽量避免系统崩溃。3. 可以满足不同配备状况下，仍具备较强可靠性。（3） 客户需求约束 配站工程师水平参差不齐，提供一种顾客和谐型，简洁配备界面，需要易于操作。2.1.3 开发级需求分析本段重要根据：开发人员详细需要实现什么产品，开发维护期间对质量有哪些考虑，开发团队有无影响架构状况等因素来进行需求分析。下面仅考虑本系统开发中需要用到约束条件： （1） 开发人员需要实现目的 一种顾客和谐型通信基站运维综合管理系统V1.0。需要提供如下基本服务： 1. 机柜机箱配备：需要实现机箱机柜配备，以及出厂时安装其她硬件板所有配备。机箱机柜普通会提供一系列插槽，有关硬件在出厂时候分别安装在详细插槽中，一并交付，因此这些硬件板需要跟机柜机箱配备一同进行配备。 2. 基站配备：重要负责射频单元硬件配备，辅助单元（例如电扇、电源之类）配备，以及天线系统有关设备配备，这某些硬件大多具备可以频繁更换特性，因此这某些代码构造需要尽量松散，耦合度越低越好。 3. 导出/删除功能：导出功能可以导出当前Rbs配备XML文献，可以让咱们在测试环境中创立相似顾客配备，也可以给其她站点进行相似配备。删除功能可以删除当前Rbs中所有不重要配备，重新配站状况下可以使用。本系统使用SAX技术来解析XML文献，因此在这里需要提供DTD文献规范XML文献格式。 4. 修改功能：可以提供应基站操作人员在不断止Rbs状况下，修改基站配备功能。重要有射频单元修改，天线修改，扇区增长、删除，社区增长、删除等等功能。 （2） 开发期间质量约束 1. 以测试驱动原则进行开发，尽量做到步步可测。 2. 代码实现时候尽量多用设计模式原则，减少代码耦合度，提高可扩展性。 综上所述，总结得到ADMENS矩阵如下表所示：表2.2 ADMENS矩阵（需求层次-需求方面矩阵）功能质量约束业务级需求业务目的及业务愿景l 软件定位：基站管理软件l 提供服务：对各种类型，各种硬件提供一种通用性配站软件商业质量l 兼容新老基站配备l 容错率高商业约束l 基站零部件种类繁多l 各种型号基站，硬件之间有较大区别l 需要较强可扩展可扩展性，以便将来产品更新换代顾客级需求潜在顾客l 配站工程师运营期质量l 操作简朴，易于上手l 多用性顾客约束l 工程师水平层次不齐，提供某些必要提示l 防御性编程，检测未知配备错误开发级需求开发期质量l 可扩展性l 步步可测开发方约束l 只有一人l 时间短工程量大2.2 基站管理软件系统架构设计 本节重要是从整体上对本通信基站运维综合管理系统V1.0设计进行详细阐述。本节重要分两个层次来阐述，先从系统逻辑架构，功能模块以及鲁棒性设计三个角度来阐述该基站管理软件系统设计，然后根据本系统架构层次来详细阐述每一层设计思路以及实现方略。2.2.1 系统总体概要设计本小节仅仅是对系统总体架构概要设计简介，不对详细细节设计与实现做分析。本节从系统逻辑架构，功能模块以及鲁棒性设计三个角度来阐述该基站管理软件系统概要设计。2.2.1.1 系统逻辑架构基站管理软件系统逻辑架构图见图2.1。该系统设计思路以公司应用架构模式中流行三层架构为基本，依照本系统需求分析而衍生出来五层架构，每一层都依托在其下层之上来构建，上层使用下层定义各种接口，而下层对上层如何调用一无所知。此外，每一层对自己上层隐藏其实现细节。各层之间尽量做到相对透明89。在体现层中使用了当前最流行MVC框架模式进行设计，在逻辑实现层中，参照公司级应用架构中领域逻辑层设计思路，上层参照服务层构建，将本系统所提供服务独立出一层，成为功能模块层，对体现层提供服务，下层逻辑实现层使用领域模式，使用一系列对象来承担有关逻辑，数据层分为2层，上层物理数据层是对物理硬件一一相应，并且与MO进行汇集解决，下层逻辑数据层则是相应所在公司Manage Object架构，使用某些简朴POJO来构建数据库，同步可以使用这些数据类承载本系统配备信息，与其她子系统进行数据通信。 图2.1 基站软件系统逻辑架构多层次架构体系，使得系统灵活性极大增强，每层仅仅对其上下层负责，减少了系统耦合度，可以将一种新硬件需求给软件代码带来影响在最小范畴内扩散，较好满足频繁增长新特性需求。同步在每层之间按模块划分方略和设计模式大量应用，优化了系统局部细节，极大减少了各个子模块之间耦合度10。 体现层设计概要：该层采用当今世界主流GUI设计模式：MVC（Model-View-Controller）模式，即模型-视图-控制器模式，MVC模式可以按照模型、绘图表达方式和行绘图为等角色把一种应用系统各个某些解耦分割开来。使用该模式，可以将本系统中图形界面绘制跟图形界面控制分开，较好满足了设计目的11。同步由于该基站管理配备系统配备向导页面中有许多共同插件，可以将将视图端以及控制器端共有某些抽象到她们父类，在父类中实现对页面控制等共有逻辑，这样设计思想体现出了软件设计模式中里氏代换原则以及依赖倒转原则。子类继承时通过装饰模式等设计办法来实现各自页面不同视图，加减页面12都不会对本来架构有影响，满足开闭原则，相应视图以及控制器仅仅通过模型端进行交互，满足迪米特法则1314。 逻辑控制层部是整个系统中对配备行为进行控制地方，同步也负责Rbs对象创立等工作，该层分两层实现： 功能模块层设计概要：该层重要采用建造模式来实现，以功能模块层需求为根据分别建造，提供各种各样产品。相应于该管理软件功能，给出其相相应类来提供目的功能模块，组装构建等细节等实现某些则对上层透明，该层并不负责细节逻辑实现，而是某些实现功能组合，详细实现通过代理模式思想交由下层负责。基于此，该层重要是某些功能等创立组合控制接口，通过这些接口来调用下层逻辑实现层，并委托下层来实现需要逻辑。每一种功能相应一种建造类，通过建造模式，可以做到复用逻辑实现层零件产品，同步各功能模块之间相对保持透明，满足迪米特法则。 逻辑实现层设计概要：该层建立一种所有由对象构成领域层，来对目的对象业务建模，其中每一种对象仅仅负责一种单一功能实现。由于业务详细行为是经常变化，因而易于修改和测试对逻辑实现层来说十分重要。该层重要采用享元模式来进行构建，内蕴对象重要来存储跟该逻辑对象配备有关某些常量数据，外蕴对象重要来存储该逻辑对象需要配备数据对象。该层重要功能是：向下调用下层数据层中数据，并对数据直接进行读写等操作，实现某些独立，单一，简朴化功能，向上接受上一层功能模块层委托调用，实现功能模块层需求15。基站管理软件系统数据操作某些重要集中在这一层，产品中有一系列数据操作办法，对数据层数据类进行读写操作。 数据层某些：该层分为2层，上层为物理数据层，与详细基站物理硬件一一相应，下层为POJO层，作为与整个UTRAN系统接口，将系统系统高层定义MO与本软件系统数据进行一种一一映射。普通为了满足硬件构造变化，系统定义出MO也会相应随之调节，构造并不稳定。如果数据层采用单一层次，那么由于不断变化需求，会导致数据层经常改动，影响架构稳定性16。 物理数据层设计概要：该层采用合成/汇集原则调用POJO层数据对象，创立构建成不同型号物理硬件一系列对象，与真正物理硬件一一相应17。 POJO层设计概要：POJO，即简朴Java对象，仅包括某些属性以及某些get，set办法，并不包括业务办法。该层重要作用就是提供某些最基本数据供上层使用，对系统定义MO数据进行一一映射，转化成本系统所可以使用数据。2.2.1.2 产品功能模块构造 产品功能模块构造见图2.2。顾客需要先选定Rbs基站型号，该系统则会依照顾客选取生成相应基站配备界面，接下来就可以进行机箱机柜cabinet、站点site、扇区、天线系统等基站重要硬件配备。该管理软件同步提供了修改modify/导出export/删除delete等功能，修改modify功能可以在不重启基站状况下，调节基站扇区、载波配备等设备负载量等配备信息；导出export功能则可以将当前基站配备以XML格式一次导出，以便下次配站使用；删除Delete功能则是可以将基站当前配备删除，以便顾客重新配站。图2.2 产品功能模块构造图2.2.1.3 系统概要设计鲁棒性分析 系统概要设计鲁棒图见图2.3。 从图中可以看到，当工程师选定了Rbs基站类型后来，会有一种相相应工厂办法，生成该Rbs基站相相应实例，该实例以创立最大化方式，初始化该基站所有功能服务，并且保存该类型基站所特有数据逻辑。该基站实例对象采用单例模式，在整个配备过程中只有这一种实例对象，以便记录基站配备信息以及对基站配备信息修改信息。接下来各种功能实现某些重要是对Rbs基站配备数据进行操作，因此可以直接对这个单例对象进行操作。各功能模块之间都做了较好隔离，控制某些相对独立，每个功能对于其她功能没有影响，一种地方出错了并不影响其她功能使用，有较好鲁棒性。图2.3 系统概要设计鲁棒图2.2.2 POJO层设计2.2.2.1 MO（Manage Object）方略普通MO由高层系统工程师来设计与实现，将Rbs中资源逻辑抽象为一系列对象，再由面向对象软件语言如Java，C+，在各自子系统实现细节，再由MO之间属性交互，来实现不同子系统间数据交互。MO从高层体现出一致性，即各个子系统所使用MO，虽然分属各自子系统，但是必要完全同样。普通Rbs基站软件架构采用数据驱动方式，各个子系统相对独立，仅仅依赖数据传递进行通信。MO就是数据交互核心，MO承载了各自子系统数据信息。一种MO中普通会包括两类参数： 属性，Attributes：跟MO抽象资源有关参数变量，这些资源可以在配备时候给她们赋值，资源状态也可以通过读取这些值来获得。 行为，Actions：表达所能对一种MO采用行动，例如加锁，删除等。本文所要实现通信基站运维综合管理系统V1.0，事实上就是采用一系列Java类来相应MO，将配备信息存到MO中，通过配备这些MOattributes和actions来实现对基站配备，最后讲收集到所有配备信息，发送到中央解决单元中。 图2.4是一种采用了MO模型Rbs基站示意图：图2.4 Rbs基站MOM模型上图中矩形代表Rbs节点整体，正面是Rbs从系统角度所能看到资源，侧面则是对Rbs资源抽象：MOM（MO Model）。从图上可以看出：MO模型即是对Rbs系统角度所能看到资源另一种表达所构建成模型：抽象成为一系列可以管理对象MO，从一系列对象角度来看Rbs资源。表2.3MO取自爱立信Rbs基站，6601型号远程基站，slot信息表。表2.3 Slot信息表Possible parentsubrackPossible childrenAuxPlugInUnitBbifBoardPlugInUnitActionsupdateConfiguration()AttributesactiveSwAllocationproductDatareservedBySlotIdslotNumberslotState Slot：是对机框中插槽资源一种抽象。从该表中可以看出：slot爸爸节点只有一种，机框subrack；也许孩子节点有3个，可插入插槽单元PlugInUnit，例如基带板，射频板，信号过滤板等；远程单元AuxPlugInUnit，例如倾角调节器RET，塔放TMA等；一种基带板与射频单元交互接口BbifBoard。该MOaction仅有一种：updateConfiguration。表达如果该基站是自动配备，则该action会触发该插槽下硬件单元自动配备行为。6个Attributes分别表达：activeSwAllocation表达此刻该插槽与否有PlugInUnit在使用，如果没有PlugInUnit在次插槽被配备使用，则该属性值为空。productData属性描述当前插入单元信息，该属性一旦赋值，则无论其插入硬件板与否工作，该值都不会变，该属性值只有在slot换新硬件板时候才会变化。reservedBy该属性以一种列表形式存在，是储备这个MO所有MO一种列表。SlotId，该属性值是用来构成RDN。slotNumber该属性值从左往右开始数起，从1开始，用来表达插槽位置。slotState属性用来表白该插槽状态。该MO是在其爸爸MO创立时候创立，并且不能被删除。该MO插槽数目是在其爸爸节点subrack中定义。2.2.2.2 MO查找：RDN与LDN RDN：Relative Distinguished Name，相对标记名。RDN命名跟该MO爸爸节点有关。这个属性值在她被建立时候就定义好了，并且不能变化。 LDN：Local Distinguished Name，本地专有名称。由该Rbs节点中一系列RDN所形成一种独一无二名字。 RDN在查找父子节点MO时候使用，LDN在全局查找MO使用。 图2.5是RNC中一种MO构造，由下可以看出RDN跟LDN如何命名，以及LDN是如何由RDN所形成：图2.5 一种使用RND/LDNMO构造由上图可以看出RncFunction这个MORDN=RncFunctionId=0，由于RncFunction自身就是根节点，因此LDN等于RDN。UtranCell这个MORDN=UtranCellId=100，LDN等于该MORDN加上这个MO所有父节点RDN，因此UtranCellLDN=RncFunctionId=0，UtranCellId=100，同理，Rach这个MORDN=RachId=0，LDN=RncFunctionId=0，UtranCellId=100，RachId=0。表中MORDN命名规则：从机框最左边插槽开始，第一种插槽slot为：slot=1。因而该MORDN=SlotId=1。2.2.2.3 MO映射机制 MO映射机制采用POJO模式方略。从高层系统规定定义MO到该软件配备管理系统数据库所采用映射技术由POJO模式实现。POJO：Plain Old Java Object，简朴Java对象。POJO是一种简朴普通Java对象，它不包括业务逻辑或者持久化逻辑等，没有从任何类继承，不担当任何特殊角色，也没有实现任何接口，更没有被其她框架侵入Java对象。每一种MO由一种POJO来负责实现，由一种详细Java类来代表一种MO，Java中字段设立成私有，分别表达MO中attribute跟action。一系列get/set办法来负责数据读写。2.2.3 物理数据层设计 POJO层相应数据库数据，MO数据，仅仅只是系统高层对Rbs资源一种逻辑抽象，并不完全相应详细硬件。整个UTRAN系统中，各个子系统之间通信，是需要MO来传递数据，而咱们对Rbs配备，事实上仅仅是对详细一种类型Rbs详细硬件配备，这两者之间有某些区别。因此需要有一层数据层，来实现逻辑数据MO跟详细硬件参数配备映射关系。如下将从MO树建立，物理数据建立和物理数据实现方略三个方面详细阐述该层重要设计环节。2.2.3.1 MO树建立由于在POJO层使用了POJO数据，因此仅仅只有get/set办法，并没有任何关系，也没有任何逻辑，需要在这一层给MO数据建立关系。这样不但可以实现各个MO之间先后顺序，父子关系，依赖关系等逻辑，同步还可以使得逻辑控制层对MO数据管理、使用更加以便。图2.6是系统高层定义MO构造树一某些：图2.6 MO构造树以系统高层定义MO树为基本，本基站管理配备系统需要构建树示意图如图2.7所示：图2.7 MO构造示意图所有MO均有一种共同根节点Root Node，由上图信息可知，树根节点为ManagedElement这个对象，在这之下依次挂着各个MO。建立MO树规则是依照系统对MO构造图定义以及MO定义信息表中也许父类，也许子类信息来建立：在本基站管理软件系统Java类中，用3个类来实现MO树创立，如图2.8所示：图2.8 MO树代码构造Node类提供建立树某些最基本办法，如getDepth、getChild、getParent办法等。MONode类继承了Node类，在此基本上扩展了某些办法，提供关于MO属性某些操作，例如lockable，deletable办法。MOProxyNode类同样继承自Node类，这个类跟MoNode不同，扩展办法重要是用来获取这个类，以及获取有关MO。2.2.3.2 物理数据建立这一层重要目就是：建立一种相应详细类型Rbs，详细硬件配备数据层。这一层重要是将抽象管理对象MO数据与详细硬件配备数据联系起来，基站软件管理配备系统从顾客角度来看，仅仅是对详细硬件进行配备，而并不是对抽象MO配备，因此需要一层数据层，来进行抽象数据与详细数据转换。下面以射频单元硬件为例，分析本通信基站运维综合管理系统V1.0是如何将抽象管理对象MO数据与详细硬件配备数据进行转换。图2.9是爱立信一种远程射频单元硬件实例图：图2.9 爱立信远程射频单元硬件实例 从图中可以看出，这个远程射频单元已经进行了较好封装，其实内部集成了上行信号解决板，下行信号解决板，空口等硬件，该硬件外部则有连接基带信号解决板接口以及连接天线接口等，这些硬件详细分派资源不需要本系统进行进一步配备，在下层子系统会有针对细节配备，但是远程射频单元型号，上下行信号解决板、空口等硬件数目，外部接口连接信息，与否发射分级，与否串联等信息，这些配备信息都是需要在配备这个远程射频单元时候同步配备。而在系统高层定义MO里面并没有一种详细MO与该硬件相应，统一归类为AuxPlugInUnit这个MO，仅仅通过auType这个属性来区别详细类型。MO定义高度抽象化，不会涉及细节，或者详细硬件。AuxPlugInUnit信息如表2.4所示：表2.4 AuxPlugInUnit信息表ActionsreadRepairDelivNote()reconfigureProgramPrepare()restartAuxUnit()AttributesadministrativeStatealramStatusauTypeAuxPlugInUnitIdpiuTypeproductNumberreservedByserialNumberuniqueHwIdunitType由上表可以看出，这个MO跟实际硬件之间并不完全匹配，例如与外部其她硬件接口连线某些，没有任何属性可以用来保存与基带信号解决板连接配备或者与天线单元连接配备，而保存这个连接配备信息属性却属于另一种MO，Digital