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

第1章绪论

本文主要介绍通信基站运维综合管理系统V1.0的设计与实现。本章首先介绍本系统的背景知识以及研究意义；然后阐述国内外研究以及开发的最新动态，最后介绍本文的主要内容以及组织结构安排。

1.1研究背景与意义

本节主要介绍本文涉及的一些无线通信知识，首先介绍与本文描述的通信基站运维综合管理系统V1.0相关的WCDMA的概念，UTRAN系统，RAN系统以及Rbs的知识，然后详细描述本系统在WCDMA系统所处的位置和该系统所需要提供的功能。最后再系统阐述本文的研究意义。

1.1.1 3G无线通信相关知识

WCDMA[1]：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的连接，控制无线基站的资源的优化。WCDMA的Rbs提供无线资源以及无线广播，并且负责接受与发送UE信号。

图1.1UTRAN系统的平面结构

（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也可能以级联拓扑的形式连接）Rbs[3]（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 上的一个应用程序，但是他仍然属于Rb s 系统的一部分。机箱机柜查看器提供了一个可视化视图，并且提供了一个工具来处理由事件干扰引起的错误。

RNC Element

Manager RNC

Mur RNC Iur

RBS RBS Iub RNS

RBS

Iub Mur Mub RBS Element

Manager Mub

RNS OSS-RC Radio-part UTRAN External Mgmt

System

Mun

Packet swithed CN Iu-ps Circuit swithed CN Iu-cs UE

Uu

UE Uu IP Network PSTN/ISDN Network

COMINF Common Operation & Maintenance

Infrastructure

CN Core Network

IP Internet Protocol

ISDN Integrated Service Digital Networks

Iub Interface between RNC - RBS

Iu-cs Interface UTRAN - Circuit switched CN

Iu-ps Interface UTRAN - Packet switched CN

Iur Interface between two RNCs

Iuant Interface between RBS and TMA/RET

Mub Management Interface towards RBS Mui Management Interface for COMINF Mun Management Interface towards OSS-RC Mur Management Interface towards RNC OSS-RC Operation Support System-Radio and Core PSTN Public Switched Telehone Network RBS Radio Base Station RNC Radio Network Controller RNS Radio Network Subsystem UE User Equipment UTRAN UMTS Terrestrial Radio Access Network Uu RBS - UE interface

RBS Cabinet

viewer

RBS System

COMINF

Mui Iuant

图1.2 UTRAN 系统的拓扑结构

图1.3是Rbs 所处的位置以及Rbs 与其他节点的关系：

图1.3Rbs与RNC、OSS-RC的关系

从图上可以看出：Rbs主要通过Mub接口与OSS-RC交互，通过lub接口与RN C交互，通过Uu接口与UE交互。管理软件EM在OSS-RC节点上，负责管理与配置Rbs[4]。

图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，运行环境安装配置方便(.Net Framework, https://www.wendangku.net/doc/da18645528.html,, 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]：提供了一个基于JA V A 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矩阵（需求层次--需求方面矩阵）

功能质量约束

业务级需求业务目标及业务愿景

●软件定位：基站管理

软件

●提供服务：对各种类

型，各种硬件提供一个通

用性的配站软件商业质量

●兼容新老基站配置

●容错率高

商业约束

●基站零部件种

类繁多

●各种型号的基

站，硬件之间有较

大区别

●需要较强的可

扩展可扩展性，以

便将来产品更新换

代

用户级需求潜在用户

●配站工程师运行期质量

●操作简单，易于上

手

●多用性

用户约束

●工程师水平层

次不齐，提供一些

必要提示

●防御性编程，

检测未知的配置错

误

开发级需求开发期质量

●可扩展性

●步步可测开发方约束

●只有一人

●时间短工程量大

2.2基站管理软件系统的架构设计

本节主要是从整体上对本通信基站运维综合管理系统V1.0的设计进行详细阐述。本节主要分两个层次来阐述，先从系统的逻辑架构，功能模块以及鲁棒性设计三个角度来阐述该基站管理软件系统的设计，然后依据本系统的架构层次来具体阐述每一层的设计思路以及实现策略。

2.2.1系统总体概要设计

本小节仅仅是对系统总体架构概要设计的介绍，不对具体细节的设计与实现做分析。本节从系统的逻辑架构，功能模块以及鲁棒性设计三个角度来阐述该基站管理软件系统的概要设计。

2.2.1.1系统的逻辑架构

基站管理软件系统的逻辑架构图见图2.1。该系统的设计思路以企业应用架构模式中流行的三层架构为基础，根据本系统的需求分析而衍生出来的五层架构，每一层都依托在其下层之上来构建，上层使用下层定义的各种接口，而下层对上层如何调用一无所知。另外，每一层对自己的上层隐藏其实现细节。各层之间尽量做到相对透明[8][9]。

在表现层中使用了当前最流行的MVC框架模式进行设计，在逻辑实现层中，参照企业级应用架构中的领域逻辑层的设计思路，上层参照服务层构建，将本系统所提供的服务独立出一层，成为功能模块层，对表现层提供服务，下层逻辑实现层使用领域模式，使用一系列对象来承担相关逻辑，数据层分为2层，上层物理数据层是对物理硬件的一一对应，并且与MO进行聚集处理，下层逻辑数据层则是对应所在公司的Manage Object架构，使用一些简单的POJO 来构建数据库，同时可以使用这些数据类承载本系统的配置信息，与其他子系统进行数据通信。

图2.1基站软件系统的逻辑架构

多层次的架构体系，使得系统的灵活性极大增强，每层仅仅对其上下层负责，降低了系统的耦合度，可以将一个新硬件的需求给软件代码带来的影响在最小范围内扩散，很好的满足频繁增加新特性的需求。同时在每层之间按模块划分的策略和设计模式的大量应用，优化了系统的局部细节，极大降低了各个子模块之间的耦合度[10]。

表现层的设计概要：该层采用当今世界主流的GUI设计模式：MVC （Model-View-Controller）模式，即模型-视图-控制器模式，MVC模式可以按照模型、绘图表达方式和行绘图为等角色把一个应用系统的各个部分解耦分割开来。使用该模式，可以将本系统中的图形界面的绘制跟图形界面的控制分开，很好的满足了设计目标[11]。同时由于该基站管理配置系统的配置向导页面中有许多共同的插件，可以将将视图端以及控制器端共有的部分抽象到他们的父类，在父类中实现对页面的控制等共有的逻辑，这样的设计思想体现出了软件设计模式中的里氏代换原则以及依赖倒转原则。子类继承时通过装饰模式等设计方法来实现各自页面不同的视图，加减页面[12]都不会对原来的架构有影响，满足开闭原则，对应的视图以及控制器仅仅通过模型端进行交互，满足迪米特法则

[13][14]。

逻辑控制层部是整个系统中对配置行为进行控制的地方，同时也负责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中，通过配置这些MO的attributes 和actions来实现对基站的配置，最后讲收集到的所有配置信息，发送到中央处理单元中。

图2.4是一个采用了MO模型的Rbs基站的示意图：

图2.4 Rbs基站的MOM模型

上图中矩形代表Rbs节点整体，正面是Rbs从系统的角度所能看到的资源，侧面则是对Rbs资源的抽象：MOM（MO Model）。从图上可以看出：MO模型即是对Rbs系统的角度所能看到的资源的另一种表示所构建成的模型：抽象成为一系列可以管理的对象MO，从一系列对象的角度来看Rbs的资源。

表2.3的MO取自爱立信Rbs基站，6601型号远程基站，slot的信息表。

表2.3Slot信息表

Possible parent subrack

Possible children AuxPlugInUnit BbifBoard PlugInUnit

Actions updateConfiguration()

Attributes activeSwAllocation productData

reservedBy

SlotId

slotNumber

slotState

Slot：是对机框中插槽资源的一个抽象。

从该表中可以看出：slot的父亲节点只有一个，机框subrack；可能的孩子节点有3个，可插入插槽单元PlugInUnit，比如基带板，射频板，信号过滤板