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

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

第1章绪论

本文主要介绍通信基站运维综合管理系统V1。0的设计与实现。本章首先

介绍本系统的背景知识以及研究意义；然后阐述国内外研究以及开发的最新动

态，最后介绍本文的主要内容以及组织结构安排。

1.1研究背景与意义

本节主要介绍本文涉及的一些无线通信知识,首先介绍与本文描述的通信

基站运维综合管理系统V1.0相关的WCDMA的概念，UTRAN系统,RAN系统

以及Rbs的知识，然后详细描述本系统在WCDMA系统所处的位置和该系统所

需要提供的功能。最后再系统阐述本文的研究意义。

1。1。13G无线通信相关知识

WCDMA[1]:WidebandCodeDivisionMultipleAccess宽带码分多址。是一种由码

分多址(CDMA),演变而来的第三代无线通信技术。WCDMA采用直接序列扩

频码分多址、频分双工方式。WCDMA是一种由3GPP具体制定的，基于GSM

MAP核心网，UTRAN为无线接口的第三代移动通信系统.

UTRAN：TheUMTSTerrestrialRadioAccessNetwork，陆地无线接入网。信令

网和数据传输网在逻辑上分开[2];UTRAN和CN的功能将和传输功能完全分开；

UTRAN和CN使用的寻址方式将和传输功能的寻址方式无关；宏分级（FDD

模式）的处理完全在UTRAN内,RRC的连接的移动性完全由UTRAN控制；

定义UTRAN接口时候，通过接口的功能的划分应有尽量少的可选项；应基于

此接口控制的实体的逻辑模型。

UTRAN由一组通过Iu接口连接到核心网CN的无线网络子系统RNS组成。一

个RNS由一个无线网络控制器（RNC）和一个或者多个节点（NodeB）组成.Rbs

通过Iub接口连接到RNC。图1.1是UTRAN系统的部分平面结构图。

从图中可以看出：RNC主要负责跟核心网的交互以及与Rbs进行交互。Rbs

1

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

主要负责与RNC交互，以及用户手机交互.

从软件架构的角度,UTRAN主要分为以下3个逻辑节点：

（1）RNC（RadioNetworkController）无线网络控制器。RNC主要负责跟核心

网以及Rbs进行交互，并且负责管理无线链路.RNC控制通过Rbs的信息量。

RNC同时负责建立信道，处理与UE的连接,控制无线基站的资源的优化。

WCDMA的Rbs提供无线资源以及无线广播，并且负责接受与发送UE信号。

图1.1UTRAN系统的平面结构

（2）OSS-RC(OperationSupportSystem-RadioandCore)运维支撑系统-无线

基站跟核心网。OSS—RC主要处理从RNC过来的操作管理任务,比如软件的安

装与升级,RAN层的管理配置，告警处理等.

（3）COMINF(CommonOperate&ManageInfrastructure）通用操作管理架构。

COMINF主要管理包括从网络设备到OSS-RC所需要携带的路由等网络协议。

COMINF同时提供安全性服务,客户帮助信息,软件管理，备份解决方案等服务。

UTRAN的拓扑结构和关键节点的外部接口如图1。2所示：（节点跟接口

在下图中仅仅是一个逻辑插图，跟实际情况不一定完全吻合。比如Mub和Iub

接口可能承载相同的媒体，W—Rbs也可能以级联拓扑的形式连接)

Rbs[3］（RadioBaseStation）：WCDMA中的Rbs就是UTRAN系统节点中

基站的特有名称。NodeB是一个逻辑节点，负责发送，接收从UE过来的信道。

Rbs节点除了处理最基本的功能以外，同时还控制与监管天线设备。Rbs通过

2

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

luant接口或者其他一些专有的规范标准来控制与监管TMA、RET等天线设备。

RbsElementManager：基站管理软件，并不是UTRAN系统中的一个独立

节点,但是他是Rbs系统的一部分,EM一般运行在PC端口,控制了包含一系列

操作管理应用软件的安装。

RbsCabinetViewer：机箱机柜查看器，是部署在OSS-RC上的一个应用程

序，但是他仍然属于Rbs系统的一部分.机箱机柜查看器提供了一个可视化视

图，并且提供了一个工具来处理由事件干扰引起的错误。

PSTN/ISDNNetworkIPNetwork

ExternalMgmt

CircuitswithedCNPacketswithedCNSystem

Iu-csIu-ps

Mun

MurRNSRNSUTRAN

RNCElement

RNCRNC

Manager

Iur

RBSSystemIubIub

Mur

RBSCabinet

viewerIuantMubOSS-RC

RBSElementRBSRBSRBSRadio-part

ManagerMub

Mui

COMINF

UuUu

UEUE

COMINFCommonOperation&MaintenanceMuiManagementInterfaceforCOMINF

InfrastructureMunManagementInterfacetowardsOSS-RC

CNCoreNetworkMurManagementInterfacetowardsRNC

IPInternetProtocolOSS-RCOperationSupportSystem-RadioandCore

ISDNIntegratedServiceDigitalNetworksPSTNPublicSwitchedTelehoneNetwork

IubInterfacebetweenRNC-RBSRBSRadioBaseStation

Iu-csInterfaceUTRAN-CircuitswitchedCNRNCRadioNetworkController

Iu-psInterfaceUTRAN-PacketswitchedCNRNSRadioNetworkSubsystem

IurInterfacebetweentwoRNCsUEUserEquipment

IuantInterfacebetweenRBSandTMA/RETUTRANUMTSTerrestrialRadioAccessNetwork

MubManagementInterfacetowardsRBSUuRBS-UEinterface

图1.2UTRAN系统的拓扑结构

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

3

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

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

从图上可以看出：Rbs主要通过Mub接口与OSS-RC交互，通过lub接口

与RNC交互,通过Uu接口与UE交互。管理软件EM在OSS—RC节点上，负

责管理与配置Rbs[4].

图1.4是Rbs外部接口的平面图:

图1.4Rbs的外部接口

Mub：Mub接口是由Rbs所提供的，由管理软件EM，机箱机柜查看器，

网络管理系统等系统使用。

Iub:连接RNC跟Rbs的相关接口。

GUI:（GraphicUserInterface）由管理软件EM或者机箱机柜查看器提供,

提供了一种用户友好型的图形化界面给基站操作人员操作和维护Rbs。

VMI：（VisualandMechanicalInterface），主要提供给基站站点操作人员

使用。VMI主要包括可视化指示器(LED灯），手动的可操作的开关/按钮（复

4

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

位键）和传入的外部电源等.另外，装配的电缆螺丝等都属于这个接口。

1.1.2基站管理软件功能

ITU—TTMN:TelecommunicationsManagementNetworkstandardfrom

theITU—T)国际电信联盟电信标准化部，电信管理网络。由于该软件系统紧紧

负责基站的管理与配置,暂时不考虑traffic事件部分,仅考虑操作管理部分。

TMN操作管理部分策略主要由：

➢代理模式的使用，比如OSS—RC作为管理人,RbsEM作为代理。

➢使用管理对象（ManagedObject，MO)模型,即管理一系列抽象或者物理或

者逻辑上的资源。

➢管理信息库（ManagementInformationBase，MIB）的使用，即一个存储了

TMN中所有MO的信息库.

➢管理信息模型（ManagementInformationModel，MIM）的使用,即抽象出一

个面向对象的语言来抽象规定MO的定义，定义MO数据的基本操作。

一个基本的逻辑架构模型如图1。5所示：

图1.5TMN管理部分逻辑架构模型

本文所描述的通信基站运维综合管理系统V1。0是一个OSS-RC系统下的

子系统服务，从TMN管理部分的架构逻辑模型上来看，该系统处于架构的在

表现层。通常,配站工程师会在软件中对基站进行配置，该软件系统将用户配置

5

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

基站的数据信息收集起来，，通过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平台紧密结合，最大限度利用系统功能

6

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

1。1.3研究意义

随着中兴，华为等新兴无线通信公司的崛起，无线通信行业的竞争越来越激烈,

各大公司纷纷推出了新产品，软硬件更新速度日益加快，而市场上也出现了基

站类型新旧各异，功能各异的复杂情况，即使是同一站型，也会因为需求的变

动而导致硬件不同，或者设备参数不同等问题。将原有硬件进行整合，升级改

造，已经成为了当前3G基站发展的一个主流趋势.这样不仅仅可以节约成本,

复用原有的硬件设备，提高利用率，同时可以在更好的兼容基站的原有设备的

基础上,达到硬件微小改动，功能大大提升，基站大不一样的特点。目前市场上

的一些基站管理配置系统，由于需求已经随着市场的变化而发生了重大改变，

从原有的固定不变,几乎很少改动的硬件架构，变成当前这种需求随着市场的变

化而迅速变化的情况.以市场为导向的新需求,使得软件层次的架构的变动势在

必行。原有的架构层次过于简单,在新项目的开发中出现了架构兼容性不够,代

码耦合度过强等问题，导致系统难以维护，升级，一旦有新需求变化，总会进

行大幅修改，显然已经无法适应产品的不断更新的新要求。如何设计出一个通

用的基站管理系统，满足需求经常变动的特点，成为一个亟待解决的问题，也

是本文的主要研究目的。

1.2国内外研究动向

爱立信：爱立信的基站管理系统采用了CI/RI（ConfigurationItem/ResourceItem）

的架构。将基站资源抽象为一系列ResourceItem，将一组相近的资源以聚集的形

式构成ConfigurationItem，构建出一个逻辑上的Rbs进行配置。该管理系统使用

了MVC，JavaBean,SAX等技术，提供了一个用户友好型界面，通过一个通用

平台CPP与基站端进行通信。客户端到基站端的通信使用了COBRA的技术处

理并发。目前爱立信在市场上的主流基站及新硬件设备如图1。7所示［5]。

7

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

图1.7爱立信主流基站及新硬件设备

华为[6］:提供了一个基于JAVAWeb的网页版基站软件管理系统。该管理系统使

用了J2EE架构，并且使用了Struts+Hibernate+Spring等比较流行的框架。图1。

8是部分华为在WCDMA市场上的主流基站.

图1。8华为在WCDMA市场上的主流基站

1。3本文主要内容

本文一共分为五章,系统的介绍了通信基站运维综合管理系统V1.0的设计与实

现，下面从分章节的角度详细阐述本文将要论述的主要内容：

第一章：首先介绍了本系统所需要的无线通信的背景知识，该系统在

UTRAN系统中所处的位置以及该系统所担当的职能等，其次介绍了国内外研

8

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

究开发的动态，本章最后介绍了本文的主要内容。

第二章：主要介绍了本系统的需求分析以及详细架构设计。在需求分析中

使用了ADMENS矩阵分析法.架构设计的时候先介绍系统的总体架构设计，再

分层分别介绍每一层的设计.在介绍的时候不仅仅介绍了设计的思路，同时从设

计模式的角度给出了实现策略。

第三章：根据上一章设计出的架构,分架构层次，依次详细阐述了每一层的

实现过程。实现过程主要以详细的UML类图以及时序图为例进行阐述，同时

将设计过程中用到的设计模式串联起来.

第四章：描述了系统测试的主要方法，以及本系统测试的步骤,最后展示了

部分测试用例,同时总结了测试结果。

第五章：总结了本论文的主要工作，分析系统中一些值得改进的地方，并

且提出了后续研究的一些展望。

9

第2章基站管理配置软件系统的需求分析以及设计

第2章通信基站运维综合管理系统V1.0的需求分析以及

设计

本章详细描述了基站管理系统的需求分析与架构设计。在需求分析中应用

了ADMENS矩阵分析法进行分析，架构设计的时候体现了分层的思想，同时

为了更好的局部结构，设计模式在本系统中得到了充分的应用.

2.1系统的需求分析

通信基站运维综合管理系统V1.0提供了一个基站管理配置的平台,针对不

同种类的基站进行配置，同时提供了对基站的配置进行修改，删除，以及导入

导出配置脚本等功能。在进行本文的需求分析的时候会借助ADMENS矩阵进

行分析。

ADMENS矩阵［7］（ArchitecturalDesignMethodhasbeenExtendedto

MethodSystem，架构设计方法已经扩展到方法体系），又称为“需求层次--需求

方面矩阵”.该矩阵分析法可以帮助架构师告别需求列表的陈旧方式，顺利过渡

到二维需求观，借此避免遗漏需求、并进一步清理需求间关系和发现衍生需求。

ADMENS二维矩阵进行需求分析的“四步法”主要由以下4个角度分析：

需求结构化，分析约束影响，确定关键质量以及确定关键功能.

从“需求定义了直接还是间接目标”的角度,把需求划分为3种类型：

1。功能需求：直接体现出各个需求的目标要求。

2.质量属性:由运行期质量和开发期质量组成。

3。约束需求：由业务环境因素，使用环境因素以及技术环境因素组成.

从业务级需求，用户级需求，开发级需求三个角度对本系统的需求进行具

体分析，形成一个二维需求分析矩阵。总结成下表：

表2。1ADMENS矩阵

广义功能质量约束

技术性约束

10

第2章基站管理配置软件系统的需求分析以及设计

法规性约束

业务级需求业务目标快、好、省技术趋势

竞争因素与竞争对手

遗留系统集成

标准性约束

分批实施

用户群特点

用户级需求用户需求运行期质量用户水平

多国语言

开发团队技术水平

开发团队磨合程度

开发团队分布情况

开发级需求行为需求开发期质量开发团队业务知识

管理:保密要求

管理：产品规划

安装、维护

2.1。1业务级需求的分析

本段主要依据：包含客户或者出资者要达到的业务目标、所需要的预期投

入资金、项目的工期进度要求，以及要符合哪些标准规范、对哪些遗留的系统

进行整合改造等约束条件，对论文中阐述的系统进行业务级需求分析。下面详

细阐述本系统需要主要考虑的约束条件。

（1）客户的业务目标以及业务愿景。

1.软件定位：基站管理软件

2。提供服务：提供一个通用的管理配置平台，对同一家公司不同类型，不同

硬件的基站进行配置。

（2)客户的业务质量

1.兼容新老基站。由于技术的改革，软件必须兼容各种各样的新老基站，在满

足新基站的配置要求的同时要做到向后兼容。特别是基站硬件的更新，各大无

线通信公司目前都在做整合的研发，将老基站几块硬件板子的功能集成到一块

硬件上的创新研究，软件变更需要跟硬件的变更同步化，满足硬件变更所带来

的配置变更。

2。易于变更配置。同一款基站，很有可能会配置不同的射频单元，或者有扇

11

第2章基站管理配置软件系统的需求分析以及设计

区变动配置的需求，需要提供一个简洁而又实用的向导来满足配置的变更，同

一种硬件配置也需要能够方便的修改承载能力等，以达到资源的利用合理化。

（3)技术标准

3GPP，以及各大厂商自己制定的标准。

（4)对哪些遗留系统进行整合

基站零部件种类繁多，各种型号的基站之间硬件配置有较大区别，需要一

个扩展性很强的系统来代替原有系统，以便将来产品进一步更新换代。

2.1.2用户级需求的分析

用户及需求的分析主要从如下几个角度入手：用户需要使用系统来完成哪

些工作，对质量有哪些要求，用户群及所处的使用环境方面有哪些要求等条件

来进行用户级需求分析。下面结合本系统进行分析：

（1）用户使用系统完成的辅助工作

该系统主要的用户人员是基站配置人员,他们使用该系统进行基站的配

置，修改，删除等操作.配置向导里面的配置项有一些是有跟具体硬件相关的默

认值的,还有一些必须要用户来配置，这些配置向导按照基站的配置流程分多个

页面进行。该基站管理软件主要提供四个配置向导界面：

1。机箱/机柜配置向导：

这部分的配置的硬件设备，除了基带信号处理板的配置，还有一些硬件板，

通常在交付客户之前，在工厂就有一些烧制或者录入的默认配置,插入机箱机柜

中，所以需要在这里一并配置。在这个配置向导里面需要配置的主要有:选择

Rbs的类型,配置默认的IP地址，接口板等硬件设备。

2。基站站点配置向导

主要功能是建立扇区，配置小区,天线系统的相关硬件，电缆相关数据,该部

分需要配置的硬件组合相对比较灵活，可以依照基站的承载能力等条件，自由

组合配置。

3。修改配置向导

该配置向导比较特别，该功能的实现需要借助XML+SAX来实现，所以该

配置向导的输入仅为XML修改配置文件。该向导主要配置页面仅仅由一个文

件输入页面以及需要修改的目录结果组成。

4。导入导出，删除向导

这几个功能也都是通过XML+SAX实现,所以该配置向导同上，输入/输出仅

仅为XML文件。

（2）质量要求

12

第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矩阵如下表所示：

13

第2章基站管理配置软件系统的需求分析以及设计

表2.2ADMENS矩阵（需求层次-—需求方面矩阵）

功能质量约束

业务级需求业务目标及业务愿景商业质量商业约束

软件定位：基站管理兼容新老基站配置基站零部件种

软件容错率高类繁多

提供服务:对各种类各种型号的基

型,各种硬件提供一个通站，硬件之间有较

用性的配站软件大区别

需要较强的可

扩展可扩展性,以便

将来产品更新换代

用户级需求潜在用户运行期质量用户约束

配站工程师操作简单，易于上工程师水平层

手次不齐，提供一些

多用性必要提示

防御性编程，

检测未知的配置错

误

开发级需求开发期质量开发方约束

可扩展性只有一人

步步可测时间短工程量

大

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

本节主要是从整体上对本通信基站运维综合管理系统V1.0的设计进行详细阐

述。本节主要分两个层次来阐述，先从系统的逻辑架构,功能模块以及鲁棒性设

计三个角度来阐述该基站管理软件系统的设计，然后依据本系统的架构层次来

具体阐述每一层的设计思路以及实现策略。

2。2.1系统总体概要设计

本小节仅仅是对系统总体架构概要设计的介绍，不对具体细节的设计与实

14

第2章基站管理配置软件系统的需求分析以及设计

现做分析.本节从系统的逻辑架构，功能模块以及鲁棒性设计三个角度来阐述该

基站管理软件系统的概要设计.

2。2。1.1系统的逻辑架构

基站管理软件系统的逻辑架构图见图2.1。该系统的设计思路以企业应用架

构模式中流行的三层架构为基础，根据本系统的需求分析而衍生出来的五层架

构，每一层都依托在其下层之上来构建,上层使用下层定义的各种接口，而下层

对上层如何调用一无所知。另外，每一层对自己的上层隐藏其实现细节。各层

之间尽量做到相对透明［8］[9]。

在表现层中使用了当前最流行的MVC框架模式进行设计，在逻辑实现层

中，参照企业级应用架构中的领域逻辑层的设计思路，上层参照服务层构建，

将本系统所提供的服务独立出一层，成为功能模块层，对表现层提供服务，下

层逻辑实现层使用领域模式，使用一系列对象来承担相关逻辑,数据层分为2

层，上层物理数据层是对物理硬件的一一对应，并且与MO进行聚集处理,下层

逻辑数据层则是对应所在公司的ManageObject架构，使用一些简单的POJO来

构建数据库，同时可以使用这些数据类承载本系统的配置信息,与其他子系统进

行数据通信。

15

第2章基站管理配置软件系统的需求分析以及设计

图2。1基站软件系统的逻辑架构

多层次的架构体系，使得系统的灵活性极大增强，每层仅仅对其上下层负

责，降低了系统的耦合度，可以将一个新硬件的需求给软件代码带来的影响在

最小范围内扩散，很好的满足频繁增加新特性的需求。同时在每层之间按模块

划分的策略和设计模式的大量应用，优化了系统的局部细节，极大降低了各个

子模块之间的耦合度［10]。

表现层的设计概要：该层采用当今世界主流的GUI设计模

式:MVC(Model—View-Controller)模式,即模型-视图-控制器模式，MVC模式

可以按照模型、绘图表达方式和行绘图为等角色把一个应用系统的各个部分解

耦分割开来。使用该模式，可以将本系统中的图形界面的绘制跟图形界面的控

制分开，很好的满足了设计目标［11］。同时由于该基站管理配置系统的配置向导

页面中有许多共同的插件，可以将将视图端以及控制器端共有的部分抽象到他

们的父类，在父类中实现对页面的控制等共有的逻辑，这样的设计思想体现出

了软件设计模式中的里氏代换原则以及依赖倒转原则。子类继承时通过装饰模

式等设计方法来实现各自页面不同的视图，加减页面［12]都不会对原来的架构有

影响，满足开闭原则，对应的视图以及控制器仅仅通过模型端进行交互，满足

迪米特法则［13］［14］。

逻辑控制层部是整个系统中对配置行为进行控制的地方，同时也负责Rbs对象

的创建等工作，该层分两层实现：

功能模块层设计概要:该层主要采用建造模式来实现，以功能模块层的需求

为依据分别建造，提供各种各样的产品。对应于该管理软件的功能，给出其相

对应的类来提供目标功能模块，组装构建等细节等实现部分则对上层透明，该

层并不负责细节逻辑的实现,而是一些实现功能的组合，具体的实现通过代理模

式的思想交由下层负责。基于此，该层主要是一些功能等创建组合的控制的接

口，通过这些接口来调用下层的逻辑实现层，并委托下层来实现需要的逻辑。

每一个功能对应一个建造类，通过建造模式，可以做到复用逻辑实现层的零件

产品，同时各功能模块之间相对保持透明，满足迪米特法则.

逻辑实现层设计概要：该层建立一个全部由对象组成的领域层，来对目标

对象的业务建模，其中每一个对象仅仅负责一个单一的功能的实现.由于业务的

具体行为是经常变化的，因此易于修改和测试对逻辑实现层来说十分重要。该

层主要采用享元模式来进行构建，内蕴对象主要来存储跟该逻辑对象配置相关

的一些常量数据，外蕴对象主要来存储该逻辑对象需要配置的数据对象。该层

的主要功能是：向下调用下层数据层中的数据，并对数据直接进行读写等操作,

实现一些独立的，单一的，简单化功能，向上接受上一层功能模块层的委托调

16

第2章基站管理配置软件系统的需求分析以及设计

用，实现功能模块层的需求[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产品的功能模块结构图

17

第2章基站管理配置软件系统的需求分析以及设计

2。2。1.3系统概要设计的鲁棒性分析

系统概要设计的鲁棒图见图2。3。从图中可以看到,当工程师选定了Rbs基站

的类型以后，会有一个相对应的工厂方法，生成该Rbs基站相对应的实例，该

实例以创建最大化的方式,初始化该基站的所有功能服务,并且保存该类型的基

站所特有的数据逻辑。该基站的实例对象采用单例模式，在整个配置过程中只

有这一个实例对象，方便记录基站的配置信息以及对基站配置信息的修改信息。

接下来的各种功能实现部分主要是对Rbs基站的配置数据进行操作,所以可以

直接对这个单例对象进行操作。各功能模块之间都做了很好的隔离,控制部分相

对独立，每个功能对于其他功能没有影响，一个地方出错了并不影响其他功能

的使用，有很好的鲁棒性。

图2.3系统概要设计的鲁棒图

2.2.2POJO层的设计

MO（ManageObject）策略

通常MO由高层系统工程师来设计与实现，将Rbs中的资源逻辑抽象为一

18

第2章基站管理配置软件系统的需求分析以及设计

系列对象，再由面向对象的软件语言如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。4Rbs基站的MOM模型

上图中矩形代表Rbs节点整体，正面是Rbs从系统的角度所能看到的资源,

侧面则是对Rbs资源的抽象：MOM（MOModel）。从图上可以看出:MO模型

即是对Rbs系统的角度所能看到的资源的另一种表示所构建成的模型：抽象成

为一系列可以管理的对象MO，从一系列对象的角度来看Rbs的资源。

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

表2。3Slot信息表

Possibleparentsubrack

AuxPlugInUnit

PossiblechildrenBbifBoard

19

第2章基站管理配置软件系统的需求分析以及设计

PlugInUnit

ActionsupdateConfiguration（）

activeSwAllocation

productData

reservedBy

AttributesSlotId

slotNumber

slotState

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

从该表中可以看出：slot的父亲节点只有一个，机框subrack;可能的孩子节

点有3个,可插入插槽单元PlugInUnit，比如基带板,射频板，信号过滤板等;远

程单元AuxPlugInUnit，比如倾角调整器RET，塔放TMA等；一种基带板与射

频单元的交互接口BbifBoard。

该MO的action仅有一个：updateConfiguration。表示如果该基站是自动配

置，则该action会触发该插槽下硬件单元的自动配置行为。

6个Attributes分别表示：activeSwAllocation表示此刻该插槽是否有

PlugInUnit在使用，如果没有PlugInUnit在次插槽被配置使用,则该属性的值为

空。productData属性描述当前插入单元的信息,该属性一旦赋值,则无论其插入

硬件板是否工作，该值都不会变，该属性的值只有在slot换新硬件板的时候才

会改变。reservedBy该属性以一个列表形式存在,是储备这个MO的所有MO的

一个列表。SlotId，该属性的值是用来组成RDN的。slotNumber该属性的值从

左往右开始数起，从1开始,用来表示插槽位置的。slotState属性用来表明该插

槽的状态。该MO的是在其父亲MO的创建的时候创建的,并且不能被删除。

该MO插槽的数目是在其父亲节点subrack中定义的。

2。2.2.2MO的查找：RDN与LDN

RDN:RelativeDistinguishedName，相对标识名.RDN的命名跟该MO的父亲节

点相关。这个属性的值在他被建立的时候就定义好了，并且不能改变.

LDN：LocalDistinguishedName,本地专有名称。由该Rbs节点中一系列的RDN

所形成的一个独一无二的名字。

RDN在查找父子节点的MO时候使用，LDN在全局查找MO的使用。

图2.5是RNC中的一个MO的结构，由下可以看出RDN跟LDN如何命名，

以及LDN是如何由RDN所形成的:

20

第2章基站管理配置软件系统的需求分析以及设计

图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=｛RachId=”0"}，LDN={RncFunctionId="0”，

UtranCellId="100"，RachId="0”｝。

表中的MO的RDN命名规则：从机框最左边的插槽开始,第一个插槽slot

为：slot=1。因此该MO的RDN={SlotId="1"｝。

2.2。2.3MO的映射机制

MO的映射机制采用POJO模式策略.从高层系统规定定义的MO到该软件配置

21

第2章基站管理配置软件系统的需求分析以及设计

管理系统的数据库所采用的映射技术由POJO模式实现.

POJO：PlainOldJavaObject，简单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。1MO树的建立

由于在POJO层使用了POJO数据，所以仅仅只有get/set方法，并没有任

何关系，也没有任何逻辑,需要在这一层给MO数据建立关系。这样不仅可以实

现各个MO之间的的先后顺序，父子关系，依赖关系等逻辑，同时还可以使得

逻辑控制层对MO数据的管理、使用更加方便。

图2.6是系统高层定义的MO结构树的一部分：

22

第2章基站管理配置软件系统的需求分析以及设计

图2.6MO结构树

以系统高层定义的MO树为基础,本基站管理配置系统需要构建的树的示

意图如图2.7所示：

图2.7MO结构示意图

23

第2章基站管理配置软件系统的需求分析以及设计

所有的MO都有一个共同的根节点RootNode，由上图信息可知,树的根节

点为ManagedElement这个对象,在这之下依次挂着各个MO。建立MO树的规

则是根据系统对MO结构图的定义以及MO定义的信息表中可能的父类，可能

的子类的信息来建立的：

在本基站管理软件系统的Java类中,用3个类来实现MO树的创建，如图

2.8所示：

图2.8MO树的代码结构

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爱立信远程射频单元的硬件实例

24

第2章基站管理配置软件系统的需求分析以及设计

从图中可以看出，这个远程射频单元已经进行了很好的封装，其实内部集成了

上行信号处理板，下行信号处理板，空口等硬件，该硬件的外部则有连接基带

信号处理板的接口以及连接天线的接口等，这些硬件的具体分配资源不需要本

系统进行深入配置，在下层子系统会有针对细节的配置，但是远程射频单元的

型号,上下行信号处理板、空口等硬件的数目，外部接口的连接信息，是否发射

分级，是否串联等信息，这些配置信息都是需要在配置这个远程射频单元的时

候同时配置的.

而在系统高层定义的MO里面并没有一个具体的MO与该硬件对应，统一

归类为AuxPlugInUnit这个MO，仅仅通过auType这个属性来区分具体的类

型.MO的定义高度抽象化,不会涉及细节，或者具体硬件。

AuxPlugInUnit信息如表2。4所示:

表2。4AuxPlugInUnit信息表

readRepairDelivNote()

ActionsreconfigureProgramPrepare（）

restartAuxUnit（)

administrativeState

alramStatus

auType

AuxPlugInUnitId

AttributespiuType

productNumber

reservedBy

serialNumber

uniqueHwId

unitType

由上表可以看出，这个MO跟实际硬件之间并不完全匹配，比如与外部其

他硬件的接口连线部分，没有任何属性可以用来保存与基带信号处理板的连接

配置或者与天线单元的连接配置，而保存这个连接配置信息的属性却属于另一

个MO，DigitalCable中。根据具体产品信息，该硬件实际使用到的所有MO如

表2。5所示：

表2.5远程射频单元硬件使用的MO

实际硬件抽象MO

DigitalCable

AuxPlugInUnit

25

第2章基站管理配置软件系统的需求分析以及设计

远程射频单元SectorAntenna

AntennaBranch

AntFeederCable

于是我们可以使用合成/聚合复用原则，建立一个Java类，其中包含了属于这

个硬件的所有MO的一个聚集,这样可以通过配置这个类来配置这个硬件，同时

间接配置了相关的MO。

该层具有十分重要的意义，是将抽象管理对象MO与具体硬件实例紧密联

系起来的桥梁.基站软件管理配置系统仅仅是对具体硬件进行配置,而并不是对

抽象的MO的配置。在这一层可以进行数据的转换,转换成UTRAN中通用的

MO数据，这样就可以供其他子系统使用。这一层起到承上启下的作用。

2。2.3.1物理数据的实现策略

本层物理数据的实现策略主要采用合成/聚合复用原则以及合成模式这两个策

略。下面分别具体阐述这两种策略以及在本系统中采用的原因：

合成/聚合复用原则：又叫做合成复用原则(CRP)，指在一个新的对象里面

使用一些已有的对象，使之成为新对象的一部分;新对象通过向这些对象的委派

达到复用已有功能的目的。

使用合成/聚合复用原则的原因有：

1．新对象存取成分对象的唯一方法是通过成分对象的接口。本层的数据给

下层MO数据层赋值只会调用POJO类中的set方法。

2．这种复用支持包装.

3．这种复用所需的依赖较少。不同于继承的实现,这样实现的耦合度极低，

有助于数据的灵活组合，利于架构的解耦.一旦有新硬件或者硬件的改动,改变

起来比较方便.

4．每一个新类可以将重点集中在一个任务