通信基站运维综合标准管理系统V设计项目说明指导书.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，DigitalCable中。依据具体产品信息，该硬件