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

通信基站运维综合管理系统V1.0设计说明书第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的连接，控制无线基站的资源的优化。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主要管理包括从网络设备到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类图以及时序图为例进行阐述，同时将设计过程中用到的设计模式串联起来。 第四章：描述了系统测试的主要方法，以及本系统测试的步骤，最后展示了部分测试用例，同时总结了测试结果。第五章：总结了本论文的主要工作，分析系统中一些值得改进的地方，并且提出了后续研究的一些展望。58第2章 基站管理配置软件系统的需求分析以及设计第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.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。用户需要先选定Rbs基站的型号，该系统则会根据用户的选择生成相应的基站配置界面，接下来就可以进行机箱机柜cabinet、站点site、扇区、天线系统等基站主要硬件的配置。该管理软件同时提供了修改modify/导出export/删除delete等功能，修改modify功能可以在不重启基站的情况下，调整基站的扇区、载波配置等设备的负载量等配置信息；导出export功能则可以将当前基站的配置以XML的格式一次导出，以便下次配站使用；删除Delete功能则是可以将基站当前配置删除，方便用户重新配站。图2.2 产品的功能模块结构图 系统概要设计的鲁棒性分析 系统概要设计的鲁棒图见图2.3。 从图中可以看到，当工程师选定了Rbs基站的类型以后，会有一个相对应的工厂方法，生成该Rbs基站相对应的实例，该实例以创建最大化的方式，初始化该基站的所有功能服务，并且保存该类型的基站所特有的数据逻辑。该基站的实例对象采用单例模式，在整个配置过程中只有这一个实例对象，方便记录基站的配置信息以及对基站配置信息的修改信息。接下来的各种功能实现部分主要是对Rbs基站的配置数据进行操作，所以可以直接对这个单例对象进行操作。各功能模块之间都做了很好的隔离，控制部分相对独立，每个功能对于其他功能没有影响，一个地方出错了并不影响其他功能的使用，有很好的鲁棒性。图2.3 系统概要设计的鲁棒图2.2.2 POJO层的设计 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.3 Slot信息表Possible parentsubrackPossible childrenAuxPlugInUnitBbifBoardPlugInUnitActionsupdateConfiguration()AttributesactiveSwAllocationproductDatareservedBySlotIdslotNumberslotState 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中定义的。 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/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。 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树的建立，物理数据的建立和物理数据的实现策略三个方面具体阐述该层主要的设计步骤。 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。 物理数据的建立这一层的主要目的就是：建立一个对应具体类型的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中。根据具体产品信息，该硬件实际使用到的所有MO如表2.5所示：表2.5 远程射频单元硬件使用的MO实际硬件抽象MO远程射频单元DigitalCableAuxPlugInUnitSectorAntennaAntennaBranchAntFeederCable 于是我们可以使用合成/聚合复用原则，建立一个Java类，其中包含了属于这个硬件的所有MO的一个聚集，这样可以通过配置这个类来配置这个硬件，同时间接配置了相关的MO。 该层具有十分重要的意义，是将抽象管理对象MO与具体硬件实例紧密联系起来的桥梁。基站软件管理配置系统仅仅是对具体硬件进行配置，而并不是对抽象的MO的配置。在这一层可以进行数据的转换，转换成UTRAN中通用的MO数据，这样就可以供其他子系统使用。这一层起到承上启下的作用。 物理数据的实现策略 本层物理数据的实现策略主要采用合成/聚合复用原则以及合成模式这两个策略。下面分别具体阐述这两种策略以及在本系统中采用的原因：合成/聚合复用原则：又叫做合成复用原则（CRP），指在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新对象通过向这些对象的委派达到复用已有功能的目的。使用合成/聚合复用原则的原因有：1 新对象存取成分对象的唯一方法是通过成分对象的接口。本层的数据给下层MO数据层赋值只会调用POJO类中的set方法。2 这种复用支持包装。3 这种复用所需的依赖较少。不同于继承的实现，这样实现的耦合度极低，有助于数据的灵活组合，利于架构的解耦。一旦有新硬件或者硬件的改动，改变起来比较方便。4 每一个新类可以将重点集中在一个任务上。本层物理数据层每一个类的主要任务就是将MO层的POJO类进行集成，以匹配真实物理硬件。 合成模式：属于对象的结构模式，有时候又叫做“部分-整体”模式。合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。这样设计使得我们可以找到一种无需一对多的关系即可获得一对多的行为的替代方式。使用合成模式的主要原因有：1 有一些物理硬件可以做进一步的集成，集成化是未来无线基站硬件的趋势，在该层就进行必要的数据集成，可以很好的满足将来的需求变化。2 在一些集成了的硬件板的处理上，上层逻辑层不直接调用不直接配置的数据类，而是通过调用实际配置的数据类来进行委派。这样可以增加代码的复用性。3 在物理数据层就对数据进行必要的集成，当对集成硬件进行数据配置的时候，可以通过父类进行数据的遍历，而不并每一次都去遍历所有的子类，这样可以减少数据配置中的错误。 合成模式的UML结构图18如图2.10所示：图2.10 合成模式 该图是合成模式中树结构的一个静态结构。最上方出现的父类节点，左下方是一个树叶节点，右下方是一个树枝节点，可以含有其他节点，如果没有其他节点，则也退化成树叶节点。由于本层数据层的设计只是聚集下层POJO层中的MO数据，使之与实际物理硬件对应，所以本系统只需要使用二层树结构的合成模式即可，即父节点作为物理数据层中的数据类使用，子节点取自下层POJO数据层。本层的客户端是上层的逻辑控制层19。在本层物理数据层架构的搭建的时候，使用合成模式的思想，但是并不完全依照合成模式来构建，因为本系统设计的一个主要目的就是给原来的系统解耦合，尽量做到低耦合，而且这两层数据之间并没有强耦合关系，所以不需要继承的方式来实现，而是将下层数据层中的类以合成/聚集的方式使用。以上文中出现的远程射频单元为例，依据合成模式的思想，设计如图2.11所示：图2.11 远程射频单元的聚集模式 在该图中，处于父节点位置的就是本层需要设计的数据类，远程射频单元类，5个子节点由表2.5中可以得到。跟合成模式不同，在这里并不使用继承，而是使用聚集来实现，远程射频单元以聚集的方式将这五个POJO类聚集到父类中，使之成为一个整体。这样同样可以做到在向上层提供数据服务的时候，以一个整体的行为，以一对一的关系来进行交互，而不是传统一对多的方式。这样在逻辑控制层中，可以通过仅仅调用这一个数据类，就可以达到同时调用这5个MO类的数据的功能。 2.2.4 逻辑实现层的设计本节主要介绍了该层的实现策略，同时结合本层的主要功能需求，详细分析了采用享元模式的原因。本层只负责简单单一的行为逻辑，即每一个类只负责一种逻辑，逻辑的组合则交给上层2021。 逻辑实现层的实现策略：享元模式。享元模式是对象的结构模式。享元模式以共享的方式高效的支持大量的细粒度对象。享元对象区分内蕴状态和外蕴状态。一个内蕴状态是存储在享元对象内部的，并且是不会随着环境改变而有所不同的。因此一个享元可以具有内蕴状态并且内蕴状态可以共享。一个外蕴状态是随环境改变而改变的、不可以共享的状态。享元对象的外蕴状态必须由客户端保存，并在享元对象被创建之后，在需要使用的时候再传入到享元对象内部。外蕴状态不可以影响享元对象的内蕴状态，他们之间是相互独立的。 图2.12是享元模式的结构示意图：图2.12 享元模式 在上图中，享原工厂负责创建和管理享元对象。这个角色必须保证享元对象可以被系统适当地共享。当一个对象调用一个享元对象的时候，享元工厂会检查系统中是否已经有了一个符合要求的享元对象。如果已经有了，享元工厂角色就应当提供这个已有的享元对象，如果系统中没有一个适当的享元对象的话，享元工厂角色就应当创建一个合适的享元对象。抽象享元角色是所有享元类的超类，为这些类定义出需要实现的公共接口，外蕴状