通信基站运维综合管理系统V1.0设计说明书

1、精选文档第1章 绪论本文主要介绍通信基站运维综合管理系统V1.0的设计与实现。本章首先介绍本系统的背景学问以及争辩意义；然后阐述国内外争辩以及开发的最新动态，最终介绍本文的主要内容以及组织结构支配。1.1 争辩背景与意义本节主要介绍本文涉及的一些无线通信学问，首先介绍与本文描述的通信基站运维综合管理系统V1.0相关的WCDMA的概念，UTRAN系统，RAN系统以及Rbs的学问，然后具体描述本系统在WCDMA系统所处的位置和该系统所需要供应的功能。最终再系统阐述本文的争辩意义。1.1.1 3G无线通信相关学问 WCDMA1：Wideband Code Division Multiple Acce

2、ss宽带码分多址。是一种由码分多址（CDMA），演化而来的第三代无线通信技术。WCDMA接受直接序列扩频码分多址、频分双工方式。WCDMA是一种由3GPP具体制定的，基于GSM MAP核心网，UTRAN为无线接口的第三代移动通信系统。 UTRAN：The UMTS Terrestrial Radio Access Network，陆地无线接入网。信令网和数据传输网在规律上分开2；UTRAN和CN的功能将和传输功能完全分开；UTRAN和CN使用的寻址方式将和传输功能的寻址方式无关；宏分级（FDD模式）的处理完全在UTRAN内，RRC的连接的移动性完全由UTRAN把握；定义UTRAN接口时候，通过

3、接口的功能的划分应有尽量少的可选项；应基于此接口把握的实体的规律模型。 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进行交互，并且负责管

4、理无线链路。RNC把握通过Rbs的信息量。RNC同时负责建立信道，处理与UE的连接，把握无线基站的资源的优化。WCDMA的Rbs供应无线资源以及无线广播，并且负责接受与发送UE信号。图1.1 UTRAN系统的平面结构 （2）OSS-RC (Operation Support System-Radio and Core) 运维支撑系统-无线基站跟核心网。OSS-RC主要处理从RNC过来的操作管理任务，比如软件的安装与升级，RAN层的管理配置，告警处理等。 （3）COMINF (Common Operate&Manage Infrastructure) 通用操作管理架构。COMINF主要管

5、理包括从网络设备到OSS-RC所需要携带的路由等网络协议。COMINF同时供应平安性服务，客户挂念信息，软件管理，备份解决方案等服务。UTRAN的拓扑结构和关键节点的外部接口如图1.2所示：（节点跟接口在下图中仅仅是一个规律插图，跟实际状况不肯定完全吻合。比如Mub和Iub接口可能承载相同的媒体，W-Rbs也可能以级联拓扑的形式连接）Rbs3（Radio Base Station）：WCDMA中的Rbs就是UTRAN系统节点中基站的特出名称。Node B是一个规律节点，负责发送，接收从UE过来的信道。Rbs节点除了处理最基本的功能以外，同时还把握与监管天线设备。Rbs通过luant接口或者其他

6、一些专有的规范标准来把握与监管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的关系从图上可以看出：Rb

7、s主要通过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），主要供应应基站站点操作

8、人员使用。VMI主要包括可视化指示器（LED灯），手动的可操作的开关/按钮（复位键）和传入的外部电源等。另外，装配的电缆螺丝等都属于这个接口。1.1.2 基站管理软件功能ITU-T TMN: Telecommunications Management Network standard from the ITU-T) 国际电信联盟电信标准化部，电信管理网络。由于该软件系统紧紧负责基站的管理与配置，临时不考虑traffic大事部分，仅考虑操作管理部分。TMN操作管理部分策略主要由：Ø 代理模式的使用，比如OSS-RC作为管理人，Rbs EM作为代理。Ø 使用管理对象（Manag

9、ed Object，MO）模型，即管理一系列抽象或者物理或者规律上的资源。Ø 管理信息库（Management Information Base，MIB）的使用，即一个存储了TMN中全部MO的信息库。Ø 管理信息模型（Management Information Model，MIM）的使用，即抽象出一个面对对象的语言来抽象规定MO的定义，定义MO数据的基本操作。 一个基本的规律架构模型如图1.5所示：图1.5 TMN管理部分规律架构模型本文所描述的通信基站运维综合管理系统V1.0是一个OSS-RC系统下的子系统服务，从TMN管理部分的架构规律模型上来看，该系统处于架构的在表

10、现层。通常，配站工程师会在软件中对基站进行配置，该软件系统将用户配置基站的数据信息收集起来，通过MO携带数据，通过COBRA等公共协议与指定基站进行通信，向下层传送管理和配置的信息，将所需配置信息发送到指定基站的中心处理单元，而在基站端，通常会有一个类似于接口的子系统，对发送过来的消息进行解析并处理，并将配置信息进行反馈。这样就可以做到基站的安装跟配置分开进行，并且还可以随时对基站进行调控容量，监视基站中设备的状态等操作。基站通信结构示意图如图1.6所示:图1.6 基站通信结构本文中通信基站运维综合管理系统V1.0主要供应以下功能：功能特点：1，IT资源可视化，轻松读懂各种IT数据2，业务拓扑

11、视图，直观呈现出业务与IT的关系3，IT资产管理与IT监控管理、运维流程管理等无缝集成，实现对以虚拟化和云计算为核心支撑的IT体系综合管控。4，完善的IT网络运维管理体系，依托统一的服务支持平台，形成自动化、流程化的服务支持。技术特点：1，运行环境安装配置便利 (.Net Framework, Asp.Net, IIS)2，技术成熟，主流技术，配套技术文档完善，众多开源或免费的文档或项目可供参考3，拥有众多新技术，便利构建企业级应用4，开发部署工具功能强大5，能与Windows平台紧密结合，最大限度利用系统功能1.1.3 争辩意义 随着中兴，华为等新兴无

12、线通信公司的崛起，无线通信行业的竞争越来越激烈，各大公司纷纷推出了新产品，软硬件更新速度日益加快，而市场上也消灭了基站类型新旧各异，功能各异的简单状况，即使是同一站型，也会由于需求的变动而导致硬件不同，或者设备参数不同等问题。将原有硬件进行整合，升级改造，已经成为了当前3G基站进展的一个主流趋势。这样不仅仅可以节省成本，复用原有的硬件设备，提高利用率，同时可以在更好的兼容基站的原有设备的基础上，达到硬件微小改动，功能大大提升，基站大不一样的特点。目前市场上的一些基站管理配置系统，由于需求已经随着市场的变化而发生了重大转变，从原有的固定不变，几乎很少改动的硬件架构，变成当前这种需求随着市场的变化

13、而快速变化的状况。以市场为导向的新需求，使得软件层次的架构的变动势在必行。原有的架构层次过于简洁，在新项目的开发中消灭了架构兼容性不够，代码耦合度过强等问题，导致系统难以维护，升级，一旦有新需求变化，总会进行大幅修改，明显已经无法适应产品的不断更新的新要求。如何设计出一个通用的基站管理系统，满足需求经常变动的特点，成为一个亟待解决的问题，也是本文的主要争辩目的。1.2 国内外争辩动向 爱立信：爱立信的基站管理系统接受了CI/RI（Configuration Item/Resource Item）的架构。将基站资源抽象为一系列Resource Item，将一组相近的资源以聚集的形式构成Confi

14、guration 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

15、本文主要内容 本文一共分为五章，系统的介绍了通信基站运维综合管理系统V1.0的设计与实现，下面从分章节的角度具体阐述本文将要论述的主要内容： 第一章：首先介绍了本系统所需要的无线通信的背景学问，该系统在UTRAN系统中所处的位置以及该系统所担当的职能等，其次介绍了国内外争辩开发的动态，本章最终介绍了本文的主要内容。 其次章：主要介绍了本系统的需求分析以及具体架构设计。在需求分析中使用了ADMENS矩阵分析法。架构设计的时候先介绍系统的总体架构设计，再分层分别介绍每一层的设计。在介绍的时候不仅仅介绍了设计的思路，同时从设计模式的角度给出了实现策略。 第三章：依据上一章设计出的架构，分架构层次，依

16、次具体阐述了每一层的实现过程。实现过程主要以具体的UML类图以准时序图为例进行阐述，同时将设计过程中用到的设计模式串联起来。 第四章：描述了系统测试的主要方法，以及本系统测试的步骤，最终呈现了部分测试用例，同时总结了测试结果。第五章：总结了本论文的主要工作，分析系统中一些值得改进的地方，并且提出了后续争辩的一些展望。精选文档第2章 通信基站运维综合管理系统V1.0的需求分析以及设计本章具体描述了基站管理系统的需求分析与架构设计。在需求分析中应用了ADMENS矩阵分析法进行分析，架构设计的时候体现了分层的思想，同时为了更好的局部结构，设计模式在本系统中得到了充分的应用。2.1 系统的需求分析通信

17、基站运维综合管理系统V1.0供应了一个基站管理配置的平台，针对不同种类的基站进行配置，同时供应了对基站的配置进行修改，删除，以及导入导出配置脚本等功能。在进行本文的需求分析的时候会借助ADMENS矩阵进行分析。ADMENS矩阵7（Architectural Design Method has been Extended to Method System，架构设计方法已经扩展到方法体系），又称为“需求层次-需求方面矩阵”。该矩阵分析法可以挂念架构师告辞需求列表的陈旧方式，顺当过渡到二维需求观，借此避开遗漏需求、并进一步清理需求间关系和发觉衍生需求。ADMENS二维矩阵进行需求分析的“四步法”主要

18、由以下4个角度分析：需求结构化，分析约束影响，确定关键质量以及确定关键功能。从“需求定义了直接还是间接目标”的角度，把需求划分为3种类型：1. 功能需求：直接体现出各个需求的目标要求。2. 质量属性：由运行期质量和开发期质量组成。3. 约束需求：由业务环境因素，使用环境因素以及技术环境因素组成。从业务级需求，用户级需求，开发级需求三个角度对本系统的需求进行具体分析，形成一个二维需求分析矩阵。总结成下表：表2.1 ADMENS矩阵广义功能质量约束业务级需求业务目标快、好、省技术性约束法规性约束技术趋势竞争因素与竞争对手遗留系统集成标准性约束分批实施用户级需求用户需求运行期质量用户群特点用户水平多

19、国语言开发级需求行为需求开发期质量开发团队技术水平开发团队磨合程度开发团队分布状况开发团队业务学问管理：保密要求管理：产品规划安装、维护2.1.1 业务级需求的分析本段主要依据：包含客户或者出资者要达到的业务目标、所需要的预期投入资金、项目的工期进度要求，以及要符合哪些标准规范、对哪些遗留的系统进行整合改造等约束条件，对论文中阐述的系统进行业务级需求分析。下面具体阐述本系统需要主要考虑的约束条件。 (1) 客户的业务目标以及业务愿景。1. 软件定位：基站管理软件 2. 供应服务：供应一个通用的管理配置平台，对同一家公司不同类型，不同硬件的基站进行配置。 (2) 客户的业务质量 1. 兼容新老基

20、站。由于技术的改革，软件必需兼容各种各样的新老基站，在满足新基站的配置要求的同时要做到向后兼容。特殊是基站硬件的更新，各大无线通信公司目前都在做整合的研发，将老基站几块硬件板子的功能集成到一块硬件上的创新争辩，软件变更需要跟硬件的变更同步化，满足硬件变更所带来的配置变更。 2. 易于变更配置。同一款基站，很有可能会配置不同的射频单元，或者有扇区变动配置的需求，需要供应一个简洁而又有用的向导来满足配置的变更，同一种硬件配置也需要能够便利的修改承载力量等，以达到资源的利用合理化。 (3) 技术标准 3GPP，以及各大厂商自己制定的标准。 (4) 对哪些遗留系统进行整合 基站零部件种类繁多，各种型号

21、的基站之间硬件配置有较大区分，需要一个扩展性很强的系统来代替原有系统，以便将来产品进一步更新换代。2.1.2 用户级需求的分析用户及需求的分析主要从如下几个角度入手：用户需要使用系统来完成哪些工作，对质量有哪些要求，用户群及所处的使用环境方面有哪些要求等条件来进行用户级需求分析。下面结合本系统进行分析： （1） 用户使用系统完成的帮助工作 该系统主要的用户人员是基站配置人员，他们使用该系统进行基站的配置，修改，删除等操作。配置向导里面的配置项有一些是有跟具体硬件相关的默认值的，还有一些必需要用户来配置，这些配置向导依据基站的配置流程分多个页面进行。该基站管理软件主要供应四个配置向导界面：1.

22、机箱/机柜配置向导： 这部分的配置的硬件设备，除了基带信号处理板的配置，还有一些硬件板，通常在交付客户之前，在工厂就有一些烧制或者录入的默认配置，插入机箱机柜中，所以需要在这里一并配置。在这个配置向导里面需要配置的主要有：选择Rbs的类型，配置默认的IP地址，接口板等硬件设备。2. 基站站点配置向导 主要功能是建立扇区，配置小区，天线系统的相关硬件，电缆相关数据，该部分需要配置的硬件组合相对比较机敏，可以依照基站的承载力量等条件，自由组合配置。3. 修改配置向导 该配置向导比较特殊，该功能的实现需要借助XML+SAX来实现，所以该配置向导的输入仅为XML修改配置文件。该向导主要配置页面仅仅由一

23、个文件输入页面以及需要修改的名目结果组成。4. 导入导出，删除向导 这几个功能也都是通过XML+SAX实现，所以该配置向导同上，输入/输出仅仅为XML文件。（2） 质量要求1. 操作便利，界面友好。2. 系统具有很强的健壮性，尽量避开系统崩溃。3. 能够满足不同的配置的状况下，仍具有较强的牢靠性。（3） 客户需求约束 配站工程师水平参差不齐，供应一个用户友好型，简洁的配置界面，需要易于操作。2.1.3 开发级需求的分析本段主要依据：开发人员具体需要实现什么产品，开发维护期间对质量有哪些考虑，开发团队有无影响架构的状况等因素来进行需求分析。下面仅考虑本系统开发中需要用到的约束条件： （1） 开发

24、人员需要实现目标 一个用户友好型的通信基站运维综合管理系统V1.0。需要供应如下基本服务： 1. 机柜机箱配置：需要实现机箱机柜的配置，以及出厂时安装的其他硬件板的全部配置。机箱机柜通常会供应一系列的插槽，相关的硬件在出厂的时候分别安装在具体的插槽中，一并交付，所以这些硬件板需要跟机柜机箱配置一同进行配置。 2. 基站配置：主要负责射频单元硬件的配置，帮助单元（比如风扇、电源之类）的配置，以及天线系统相关设备的配置，这部分的硬件大多具有可以频繁更换的特性，所以这部分代码结构需要尽量松散，耦合度越低越好。 3. 导出/删除功能：导出功能可以导出当前Rbs的配置XML文件，可以让我们在测试环境中创

25、建相同的用户配置，也可以给其他站点进行相同的配置。删除功能可以删除当前Rbs中全部不重要的配置，重新配站的状况下可以使用。本系统使用SAX的技术来解析XML文件，所以在这里需要供应DTD文件规范XML文件的格式。 4. 修改功能：可以供应应基站操作人员在不停止Rbs的状况下，修改基站的配置的功能。主要有射频单元的修改，天线的修改，扇区的增加、删除，小区的增加、删除等等功能。 （2） 开发期间的质量约束 1. 以测试驱动的原则进行开发，尽量做到步步可测。 2. 代码实现的时候尽量多用设计模式的原则，降低代码的耦合度，提高可扩展性。 综上所述，总结得到的ADMENS矩阵如下表所示：表2.2 ADM

26、ENS矩阵（需求层次-需求方面矩阵）功能质量约束业务级需求业务目标及业务愿景l 软件定位：基站管理软件l 供应服务：对各种类型，各种硬件供应一个通用性的配站软件商业质量l 兼容新老基站配置l 容错率高商业约束l 基站零部件种类繁多l 各种型号的基站，硬件之间有较大区分l 需要较强的可扩展可扩展性，以便将来产品更新换代用户级需求潜在用户l 配站工程师运行期质量l 操作简洁，易于上手l 多用性用户约束l 工程师水平层次不齐，供应一些必要提示l 防备性编程，检测未知的配置错误开发级需求开发期质量l 可扩展性l 步步可测开发方约束l 只有一人l 时间短工程量大2.2 基站管理软件系统的架构设计 本节主

27、要是从整体上对本通信基站运维综合管理系统V1.0的设计进行具体阐述。本节主要分两个层次来阐述，先从系统的规律架构，功能模块以及鲁棒性设计三个角度来阐述该基站管理软件系统的设计，然后依据本系统的架构层次来具体阐述每一层的设计思路以及实现策略。2.2.1 系统总体概要设计本小节仅仅是对系统总体架构概要设计的介绍，不对具体细节的设计与实现做分析。本节从系统的规律架构，功能模块以及鲁棒性设计三个角度来阐述该基站管理软件系统的概要设计。 系统的规律架构基站管理软件系统的规律架构图见图2.1。该系统的设计思路以企业应用架构模式中流行的三层架构为基础，依据本系统的需求分析而衍生出来的五层架构，

28、每一层都依托在其下层之上来构建，上层使用下层定义的各种接口，而下层对上层如何调用一无所知。另外，每一层对自己的上层隐蔽其实现细节。各层之间尽量做到相对透亮89。在表现层中使用了当前最流行的MVC框架模式进行设计，在规律实现层中，参照企业级应用架构中的领域规律层的设计思路，上层参照服务层构建，将本系统所供应的服务独立出一层，成为功能模块层，对表现层供应服务，下层规律实现层使用领域模式，使用一系列对象来担当相关规律，数据层分为2层，上层物理数据层是对物理硬件的一一对应，并且与MO进行聚集处理，下层规律数据层则是对应所在公司的Manage Object架构，使用一些简洁的POJO来构建数据库，同时可

29、以使用这些数据类承载本系统的配置信息，与其他子系统进行数据通信。 图2.1 基站软件系统的规律架构多层次的架构体系，使得系统的机敏性极大增加，每层仅仅对其上下层负责，降低了系统的耦合度，可以将一个新硬件的需求给软件代码带来的影响在最小范围内集中，很好的满足频繁增加新特性的需求。同时在每层之间按模块划分的策略和设计模式的大量应用，优化了系统的局部细节，极大降低了各个子模块之间的耦合度10。 表现层的设计概要：该层接受当今世界主流的GUI设计模式：MVC（Model-View-Controller）模式，即模型-视图-把握器模式，MVC模式可以依据模型、绘图表达方式和行绘图为等角色把一个应用系统的

30、各个部分解耦分割开来。使用该模式，可以将本系统中的图形界面的绘制跟图形界面的把握分开，很好的满足了设计目标11。同时由于该基站管理配置系统的配置向导页面中有很多共同的插件，可以将将视图端以及把握器端共有的部分抽象到他们的父类，在父类中实现对页面的把握等共有的规律，这样的设计思想体现出了软件设计模式中的里氏代换原则以及依靠倒转原则。子类继承时通过装饰模式等设计方法来实现各自页面不同的视图，加减页面12都不会对原来的架构有影响，满足开闭原则，对应的视图以及把握器仅仅通过模型端进行交互，满足迪米特法则1314。 规律把握层部是整个系统中对配置行为进行把握的地方，同时也负责Rbs对象的创建等工作，该层

31、分两层实现： 功能模块层设计概要：该层主要接受建筑模式来实现，以功能模块层的需求为依据分别建筑，供应各种各样的产品。对应于该管理软件的功能，给出其相对应的类来供应目标功能模块，组装构建等细节等实现部分则对上层透亮，该层并不负责细节规律的实现，而是一些实现功能的组合，具体的实现通过代理模式的思想交由下层负责。基于此，该层主要是一些功能等创建组合的把握的接口，通过这些接口来调用下层的规律实现层，并托付下层来实现需要的规律。每一个功能对应一个建筑类，通过建筑模式，可以做到复用规律实现层的零件产品，同时各功能模块之间相对保持透亮，满足迪米特法则。 规律实现层设计概要：该层建立一个全部由对象组成的领域层

32、，来对目标对象的业务建模，其中每一个对象仅仅负责一个单一的功能的实现。由于业务的具体行为是经常变化的，因此易于修改和测试对规律实现层来说格外重要。该层主要接受享元模式来进行构建，内蕴对象主要来存储跟该规律对象配置相关的一些常量数据，外蕴对象主要来存储该规律对象需要配置的数据对象。该层的主要功能是：向下调用下层数据层中的数据，并对数据直接进行读写等操作，实现一些独立的，单一的，简洁化功能，向上接受上一层功能模块层的托付调用，实现功能模块层的需求15。基站管理软件系统的数据操作部分主要集中在这一层，产品中有一系列的数据操作方法，对数据层的数据类进行读写操作。 数据层部分：该层分为2层，上层为物理数

33、据层，与具体基站的物理硬件一一对应，下层为POJO层，作为与整个UTRAN系统的接口，将系统系统高层定义的MO与本软件系统的数据进行一个一一映射。通常为了满足硬件结构的变化，系统定义出的MO也会相应随之调整，结构并不稳定。假如数据层接受单一的层次，那么由于不停变化的需求，会导致数据层的经常改动，影响架构的稳定性16。 物理数据层设计概要：该层接受合成/聚集原则调用POJO层的数据对象，创建构建成不同型号的物理硬件的一系列对象，与真正的物理硬件一一对应17。 POJO层设计概要：POJO，即简洁的Java对象，仅包含一些属性以及一些get，set方法，并不包含业务方法。该层主要作用就是供应一些最

34、基本的数据供上层使用，对系统定义的MO数据进行一一映射，转化成本系统所能够使用的数据。 产品的功能模块结构 产品的功能模块结构见图2.2。用户需要先选定Rbs基站的型号，该系统则会依据用户的选择生成相应的基站配置界面，接下来就可以进行机箱机柜cabinet、站点site、扇区、天线系统等基站主要硬件的配置。该管理软件同时供应了修改modify/导出export/删除delete等功能，修改modify功能可以在不重启基站的状况下，调整基站的扇区、载波配置等设备的负载量等配置信息；导出export功能则可以将当前基站的配置以XML的格式一次导出，以便下次配站使用；删除Delete功

35、能则是可以将基站当前配置删除，便利用户重新配站。图2.2 产品的功能模块结构图 系统概要设计的鲁棒性分析 系统概要设计的鲁棒图见图2.3。 从图中可以看到，当工程师选定了Rbs基站的类型以后，会有一个相对应的工厂方法，生成该Rbs基站相对应的实例，该实例以创建最大化的方式，初始化该基站的全部功能服务，并且保存该类型的基站所特有的数据规律。该基站的实例对象接受单例模式，在整个配置过程中只有这一个实例对象，便利记录基站的配置信息以及对基站配置信息的修改信息。接下来的各种功能实现部分主要是对Rbs基站的配置数据进行操作，所以可以直接对这个单例对象进行操作。各功能模块之间都做了很好的隔离

36、，把握部分相对独立，每个功能对于其他功能没有影响，一个地方出错了并不影响其他功能的使用，有很好的鲁棒性。图2.3 系统概要设计的鲁棒图2.2.2 POJO层的设计 MO（Manage Object）策略通常MO由高层系统工程师来设计与实现，将Rbs中的资源规律抽象为一系列对象，再由面对对象的软件语言如Java，C+，在各自子系统实现细节，再由MO之间属性的交互，来实现不同子系统间数据的交互。MO从高层体现出全都性，即各个子系统所使用的MO，虽然分属各自的子系统，但是必需完全一样。一般Rbs基站的软件架构接受数据驱动的方式，各个子系统相对独立，仅仅依靠数据的传递进行通信。MO就是数

37、据交互的关键，MO承载了各自子系统的数据信息。一个MO中通常会包含两类参数：Ø 属性，Attributes：跟MO抽象的资源相关的参数变量，这些资源可以在配置的时候给他们赋值，资源的状态也可以通过读取这些值来获得。Ø 行为，Actions：表示所能对一个MO接受的行动，比如加锁，删除等。本文所要实现的通信基站运维综合管理系统V1.0，实际上就是接受一系列的Java类来对应MO，将配置信息存到MO中，通过配置这些MO的attributes和actions来实现对基站的配置，最终讲收集到的全部配置信息，发送到中心处理单元中。 图2.4是一个接受了MO模型的Rbs基站的示意图：图

38、2.4 Rbs基站的MOM模型上图中矩形代表Rbs节点整体，正面是Rbs从系统的角度所能看到的资源，侧面则是对Rbs资源的抽象：MOM（MO Model）。从图上可以看出：MO模型即是对Rbs系统的角度所能看到的资源的另一种表示所构建成的模型：抽象成为一系列可以管理的对象MO，从一系列对象的角度来看Rbs的资源。表2.3的MO取自爱立信Rbs基站，6601型号远程基站，slot的信息表。表2.3 Slot信息表Possible parentsubrackPossible childrenAuxPlugInUnitBbifBoardPlugInUnitActionsupdateConfigura

39、tion()AttributesactiveSwAllocationproductDatareservedBySlotIdslotNumberslotState Slot：是对机框中插槽资源的一个抽象。从该表中可以看出：slot的父亲节点只有一个，机框subrack；可能的孩子节点有3个，可插入插槽单元PlugInUnit，比如基带板，射频板，信号过滤板等；远程单元AuxPlugInUnit，比如倾角调整器RET，塔放TMA等；一种基带板与射频单元的交互接口BbifBoard。该MO的action仅有一个：updateConfiguration。表示假如该基站是自动配置，则该action会触发

40、该插槽下硬件单元的自动配置行为。6个Attributes分别表示：activeSwAllocation表示此刻该插槽是否有PlugInUnit在使用，假如没有PlugInUnit在次插槽被配置使用，则该属性的值为空。productData属性描述当前插入单元的信息，该属性一旦赋值，则无论其插入硬件板是否工作，该值都不会变，该属性的值只有在slot换新硬件板的时候才会转变。reservedBy该属性以一个列表形式存在，是储备这个MO的全部MO的一个列表。SlotId，该属性的值是用来组成RDN的。slotNumber该属性的值从左往右开头数起，从1开头，用来表示插槽位置的。slotState属性

41、用来表明该插槽的状态。该MO的是在其父亲MO的创建的时候创建的，并且不能被删除。该MO插槽的数目是在其父亲节点subrack中定义的。 MO的查找：RDN与LDN RDN：Relative Distinguished Name，相对标识名。RDN的命名跟该MO的父亲节点相关。这个属性的值在他被建立的时候就定义好了，并且不能转变。 LDN：Local Distinguished Name，本地专出名称。由该Rbs节点中一系列的RDN所形成的一个独一无二的名字。 RDN在查找父子节点的MO时候使用，LDN在全局查找MO的使用。 图2.5是RNC中的一个MO的结构，由下可以看出RDN跟

42、LDN如何命名，以及LDN是如何由RDN所形成的：图2.5 一个使用RND/LDN的MO结构由上图可以看出RncFunction这个MO的RDN=RncFunctionId="0"，由于RncFunction本身就是根节点，所以LDN等于RDN。UtranCell这个MO的RDN=UtranCellId="100"，LDN等于该MO的RDN加上这个MO全部父节点的RDN，所以UtranCell的LDN=RncFunctionId="0"，UtranCellId="100"，同理，Rach这个MO的RDN=RachI

43、d="0"，LDN=RncFunctionId="0"，UtranCellId="100"，RachId="0"。表中的MO的RDN命名规章：从机框最左边的插槽开头，第一个插槽slot为：slot=1。因此该MO的RDN=SlotId="1"。 MO的映射机制 MO的映射机制接受POJO模式策略。从高层系统规定定义的MO到该软件配置管理系统的数据库所接受的映射技术由POJO模式实现。POJO：Plain Old Java Object，简洁Java对象。POJO是一个简洁的一般的J

44、ava对象，它不包含业务规律或者长久化规律等，没有从任何类继承，不担当任何特殊的角色，也没有实现任何接口，更没有被其他框架侵入的Java对象。每一个MO由一个POJO来负责实现，由一个具体的Java类来代表一个MO，Java中的字段设置成私有的，分别表示MO中的attribute跟action。一系列的get/set方法来负责数据的读写。2.2.3 物理数据层的设计 POJO层对应的数据库数据，MO数据，仅仅只是系统高层对Rbs资源的一个规律抽象，并不完全对应具体硬件。整个UTRAN系统中，各个子系统之间的通信，是需要MO来传递数据的，而我们对Rbs的配置，实际上仅仅是对具体的一个类型的Rbs

45、的具体硬件的配置，这两者之间有一些区分。所以需要有一层数据层，来实现规律数据MO跟具体硬件的参数配置的映射关系。以下将从MO树的建立，物理数据的建立和物理数据的实现策略三个方面具体阐述该层主要的设计步骤。 MO树的建立由于在POJO层使用了POJO数据，所以仅仅只有get/set方法，并没有任何关系，也没有任何规律，需要在这一层给MO数据建立关系。这样不仅可以实现各个MO之间的的先后挨次，父子关系，依靠关系等规律，同时还可以使得规律把握层对MO数据的管理、使用更加便利。图2.6是系统高层定义的MO结构树的一部分：图2.6 MO结构树以系统高层定义的MO树为基础，本基站管理配置系统

46、需要构建的树的示意图如图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属性的一些操作

47、，比如lockable，deletable方法。MOProxyNode类同样继承自Node类，这个类跟MoNode不同，扩展的方法主要是用来猎取这个类，以及猎取相关的MO。 物理数据的建立这一层的主要目的就是：建立一个对应具体类型的Rbs，具体硬件的配置的数据层。这一层主要是将抽象管理对象MO的数据与具体硬件配置的数据联系起来，基站软件管理配置系统从用户的角度来看，仅仅是对具体硬件进行配置，而并不是对抽象的MO的配置，所以需要一层数据层，来进行抽象数据与具体数据的转换。下面以射频单元硬件为例，分析本通信基站运维综合管理系统V1.0是如何将抽象管理对象MO的数据与具体硬件配置的数据

48、进行转换的。图2.9是爱立信一个远程射频单元的硬件实例图：图2.9 爱立信远程射频单元的硬件实例 从图中可以看出，这个远程射频单元已经进行了很好的封装，其实内部集成了上行信号处理板，下行信号处理板，空口等硬件，该硬件的外部则有连接基带信号处理板的接口以及连接天线的接口等，这些硬件的具体安排资源不需要本系统进行深化配置，在下层子系统会有针对细节的配置，但是远程射频单元的型号，上下行信号处理板、空口等硬件的数目，外部接口的连接信息，是否放射分级，是否串联等信息，这些配置信息都是需要在配置这个远程射频单元的时候同时配置的。而在系统高层定义的MO里面并没有一个具体的MO与该硬件对应，统一归类为AuxP

49、lugInUnit这个MO，仅仅通过auType这个属性来区分具体的类型。MO的定义高度抽象化，不会涉及细节，或者具体硬件。AuxPlugInUnit信息如表2.4所示：表2.4 AuxPlugInUnit信息表ActionsreadRepairDelivNote()reconfigureProgramPrepare()restartAuxUnit()AttributesadministrativeStatealramStatusauTypeAuxPlugInUnitIdpiuTypeproductNumberreservedByserialNumberuniqueHwIdunitType由上

50、表可以看出，这个MO跟实际硬件之间并不完全匹配，比如与外部其他硬件的接口连线部分，没有任何属性可以用来保存与基带信号处理板的连接配置或者与天线单元的连接配置，而保存这个连接配置信息的属性却属于另一个MO，DigitalCable中。依据具体产品信息，该硬件实际使用到的全部MO如表2.5所示：表2.5 远程射频单元硬件使用的MO实际硬件抽象MO远程射频单元DigitalCableAuxPlugInUnitSectorAntennaAntennaBranchAntFeederCable 于是我们可以使用合成/聚合复用原则，建立一个Java类，其中包含了属于这个硬件的全部MO的一个聚集，这样可以通过

51、配置这个类来配置这个硬件，同时间接配置了相关的MO。 该层具有格外重要的意义，是将抽象管理对象MO与具体硬件实例紧密联系起来的桥梁。基站软件管理配置系统仅仅是对具体硬件进行配置，而并不是对抽象的MO的配置。在这一层可以进行数据的转换，转换成UTRAN中通用的MO数据，这样就可以供其他子系统使用。这一层起到承上启下的作用。 物理数据的实现策略 本层物理数据的实现策略主要接受合成/聚合复用原则以及合成模式这两个策略。下面分别具体阐述这两种策略以及在本系统中接受的缘由：合成/聚合复用原则：又叫做合成复用原则（CRP），指在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新对

52、象通过向这些对象的委派达到复用已有功能的目的。使用合成/聚合复用原则的缘由有：1 新对象存取成分对象的唯一方法是通过成分对象的接口。本层的数据给下层MO数据层赋值只会调用POJO类中的set方法。2 这种复用支持包装。3 这种复用所需的依靠较少。不同于继承的实现，这样实现的耦合度极低，有助于数据的机敏组合，利于架构的解耦。一旦有新硬件或者硬件的改动，转变起来比较便利。4 每一个新类可以将重点集中在一个任务上。本层物理数据层每一个类的主要任务就是将MO层的POJO类进行集成，以匹配真实物理硬件。 合成模式：属于对象的结构模式，有时候又叫做“部分-整体”模式。合成模式将对象组织到树结构中，可以用来

53、描述整体与部分的关系。这样设计使得我们可以找到一种无需一对多的关系即可获得一对多的行为的替代方式。使用合成模式的主要缘由有：1 有一些物理硬件可以做进一步的集成，集成化是将来无线基站硬件的趋势，在该层就进行必要的数据集成，可以很好的满足将来的需求变化。2 在一些集成了的硬件板的处理上，上层规律层不直接调用不直接配置的数据类，而是通过调用实际配置的数据类来进行委派。这样可以增加代码的复用性。3 在物理数据层就对数据进行必要的集成，当对集成硬件进行数据配置的时候，可以通过父类进行数据的遍历，而不并每一次都去遍历全部的子类，这样可以削减数据配置中的错误。 合成模式的UML结构图18如图2.10所示：

54、图2.10 合成模式 该图是合成模式中树结构的一个静态结构。最上方消灭的父类节点，左下方是一个树叶节点，右下方是一个树枝节点，可以含有其他节点，假如没有其他节点，则也退化成树叶节点。由于本层数据层的设计只是聚集下层POJO层中的MO数据，使之与实际物理硬件对应，所以本系统只需要使用二层树结构的合成模式即可，即父节点作为物理数据层中的数据类使用，子节点取自下层POJO数据层。本层的客户端是上层的规律把握层19。在本层物理数据层架构的搭建的时候，使用合成模式的思想，但是并不完全依照合成模式来构建，由于本系统设计的一个主要目的就是给原来的系统解耦合，尽量做到低耦合，而且这两层数据之间并没有强耦合关系

55、，所以不需要继承的方式来实现，而是将下层数据层中的类以合成/聚集的方式使用。以上文中消灭的远程射频单元为例，依据合成模式的思想，设计如图2.11所示：图2.11 远程射频单元的聚集模式 在该图中，处于父节点位置的就是本层需要设计的数据类，远程射频单元类，5个子节点由表2.5中可以得到。跟合成模式不同，在这里并不使用继承，而是使用聚集来实现，远程射频单元以聚集的方式将这五个POJO类聚集到父类中，使之成为一个整体。这样同样可以做到在向上层供应数据服务的时候，以一个整体的行为，以一对一的关系来进行交互，而不是传统一对多的方式。这样在规律把握层中，可以通过仅仅调用这一个数据类，就可以达到同时调用这5

56、个MO类的数据的功能。 2.2.4 规律实现层的设计本节主要介绍了该层的实现策略，同时结合本层的主要功能需求，具体分析了接受享元模式的缘由。本层只负责简洁单一的行为规律，即每一个类只负责一种规律，规律的组合则交给上层2021。 规律实现层的实现策略：享元模式。享元模式是对象的结构模式。享元模式以共享的方式高效的支持大量的细粒度对象。享元对象区分内蕴状态和外蕴状态。一个内蕴状态是存储在享元对象内部的，并且是不会随着环境转变而有所不同的。因此一个享元可以具有内蕴状态并且内蕴状态可以共享。一个外蕴状态是随环境转变而转变的、不行以共享的状态。享元对象的外蕴状态必需由客户端保存，并在享元对象被创建之后，在需要使用的时候再传入到享元对象内部。外蕴状态不行以影响享元对象的内蕴状态，他们之间是相互独立的。 图2.12是享元模式的结构示意图：图2.12 享元模式 在上图中，享原工厂负责创建和管理享元对象。这个角色必需保证享元对象可以被系统适当地共享。当一个对象调用一个享元对象的时候，享元工厂会检查系统中是否已经有了一个符合要求的享元对象。假如已经有了，享元工厂角色就应当供应这个已有的享元对象，假如系统中没有一个适当的享元对象的话，享元工厂角色就应当创建一个合适的享元对象。抽象享元角色是全部享元类的超类，为这些类定义出需要实现的公共接口，外蕴状态可以在该