《通信基站运维综合管理系统V1.0设计说明书试卷教案.pdf》由会员分享，可在线阅读，更多相关《通信基站运维综合管理系统V1.0设计说明书试卷教案.pdf（56页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、通信基站运维综合管理系统V1.0 设计说明书第第 1 1 章章绪论绪论本文主要介绍通信基站运维综合管理系统 V1。0 的设计与实现。本章首先介绍本系统的背景知识以及研究意义；然后阐述国内外研究以及开发的最新动态，最后介绍本文的主要内容以及组织结构安排。1.1 研究背景与意义本节主要介绍本文涉及的一些无线通信知识,首先介绍与本文描述的通信基站运维综合管理系统 V1.0 相关的 WCDMA 的概念，UTRAN 系统,RAN 系统以及 Rbs 的知识，然后详细描述本系统在 WCDMA 系统所处的位置和该系统所需要提供的功能。最后再系统阐述本文的研究意义。1。1。1 3G 无线通信相关知识WCDMA1
2、:Wideband Code Division Multiple Access宽带码分多址。是一种由码分多址(CDMA),演变而来的第三代无线通信技术。WCDMA 采用直接序列扩频码分多址、频分双工方式。WCDMA 是一种由 3GPP 具体制定的，基于GSMMAP 核心网，UTRAN 为无线接口的第三代移动通信系统.UTRAN：The UMTS Terrestrial Radio Access Network，陆地无线接入网。信令网和数据传输网在逻辑上分开2;UTRAN和CN的功能将和传输功能完全分开；UTRAN 和 CN 使用的寻址方式将和传输功能的寻址方式无关；宏分级（FDD模式）的处理完
3、全在 UTRAN 内,RRC 的连接的移动性完全由 UTRAN 控制；定义 UTRAN 接口时候，通过接口的功能的划分应有尽量少的可选项；应基于此接口控制的实体的逻辑模型。UTRAN 由一组通过 Iu 接口连接到核心网 CN 的无线网络子系统 RNS 组成。一个 RNS 由一个无线网络控制器（RNC）和一个或者多个节点（Node B）组成.Rbs通过 Iub 接口连接到 RNC。图 1.1 是 UTRAN 系统的部分平面结构图。从图中可以看出：RNC 主要负责跟核心网的交互以及与 Rbs 进行交互。Rbs1通信基站运维综合管理系统V1.0 设计说明书主要负责与 RNC 交互，以及用户手机交互.
4、从软件架构的角度,UTRAN 主要分为以下 3 个逻辑节点：（1）RNC（Radio Network Controller）无线网络控制器。RNC 主要负责跟核心网以及 Rbs 进行交互，并且负责管理无线链路.RNC 控制通过 Rbs 的信息量。RNC 同时负责建立信道，处理与 UE 的连接,控制无线基站的资源的优化。WCDMA 的 Rbs 提供无线资源以及无线广播，并且负责接受与发送 UE 信号。图图 1.11.1 UTRAN 系统的平面结构（2）OSS-RC(Operation Support System-Radio and Core)运维支撑系统-无线基站跟核心网。OSSRC 主要处理
5、从 RNC 过来的操作管理任务,比如软件的安装与升级,RAN 层的管理配置，告警处理等.（3）COMINF(Common Operate&Manage Infrastructure）通用操作管理架构。COMINF 主要管理包括从网络设备到 OSS-RC 所需要携带的路由等网络协议。COMINF 同时提供安全性服务,客户帮助信息,软件管理，备份解决方案等服务。UTRAN 的拓扑结构和关键节点的外部接口如图 1。2 所示：（节点跟接口在下图中仅仅是一个逻辑插图，跟实际情况不一定完全吻合。比如 Mub 和 Iub接口可能承载相同的媒体，WRbs 也可能以级联拓扑的形式连接)Rbs3（Radio Ba
6、se Station）：WCDMA 中的 Rbs 就是 UTRAN 系统节点中基站的特有名称。Node B 是一个逻辑节点，负责发送，接收从 UE 过来的信道。Rbs 节点除了处理最基本的功能以外，同时还控制与监管天线设备。Rbs 通过2通信基站运维综合管理系统V1.0 设计说明书luant 接口或者其他一些专有的规范标准来控制与监管 TMA、RET 等天线设备。Rbs Element Manager：基站管理软件，并不是 UTRAN 系统中的一个独立节点,但是他是 Rbs 系统的一部分,EM 一般运行在 PC 端口,控制了包含一系列操作管理应用软件的安装。Rbs Cabinet Viewer
7、：机箱机柜查看器，是部署在 OSS-RC 上的一个应用程序，但是他仍然属于 Rbs 系统的一部分.机箱机柜查看器提供了一个可视化视图，并且提供了一个工具来处理由事件干扰引起的错误。PSTN/ISDN NetworkCircuit swithed CNIP NetworkPacket swithed CNExternal MgmtSystemMunUTRANIu-csMurRNSRNC ElementManagerRNCIurRBS SystemRBS CabinetviewerRBS ElementManagerIubIuantRBSRBSIubRNCIu-psRNSMurMubRBSMuiO
8、SS-RCRadio-partMubCOMINFUuUECOMINFCOMINF Common Operation&MaintenanceInfrastructureCNCNCore NetworkIPIPInternet ProtocolISDNISDNIntegrated Service Digital NetworksIubIubInterface between RNC-RBSIu-csIu-csInterface UTRAN-Circuit switched CNIu-psIu-psInterface UTRAN-Packet switched CNIurIurInterface b
9、etween two RNCsIuantIuantInterface between RBS and TMA/RETMubMubManagement Interface towards RBSMuiMuiMunMunMurMurOSS-RCOSS-RCPSTNPSTNRBSRBSRNCRNCRNSRNSUEUEUTRANUTRANUuUuUEUuManagement Interface for COMINFManagement Interface towards OSS-RCManagement Interface towards RNCOperation Support System-Rad
10、io and CorePublic Switched Telehone NetworkRadio Base StationRadio Network ControllerRadio Network SubsystemUser EquipmentUMTS Terrestrial Radio Access NetworkRBS-UE interface图图 1.21.2 UTRAN 系统的拓扑结构图 1.3 是 Rbs 所处的位置以及 Rbs 与其他节点的关系:3通信基站运维综合管理系统V1.0 设计说明书图图 1.31.3 Rbs 与 RNC、OSS RC 的关系从图上可以看出：Rbs 主要通过
11、 Mub 接口与 OSS-RC 交互，通过 lub接口与 RN C 交互,通过 Uu 接口与 UE 交互。管理软件 EM 在 OSS RC 节点上，负责管理与配置 Rbs4.图 1.4是 Rbs 外部接口的平面图:图图 1.41.4 Rbs的外部接口Mub：Mub 接口是由 Rbs 所提供的，由管理软件 EM，机箱机柜查看器，网络管理系统等系统使用。Iub:连接 RNC跟 Rbs 的相关接口。GUI:（Graphic User Interface）由管理软件 EM 或者机箱机柜查看器提供,提供了一种用户友好型的图形化界面给基站操作人员操作和维护 Rbs。VMI：（Visual and Mech
12、anical Interface），主要提供给基站站点操作人员使用。VMI主要包括可视化指示器(LED灯），手动的可操作的开关/按钮（复4通信基站运维综合管理系统V1.0 设计说明书位键）和传入的外部电源等.另外，装配的电缆螺丝等都属于这个接口。1.1.2 基站管理软件功能ITUTTMN:Telecommunications Management Network standardfromtheITUT)国际电信联盟电信标准化部，电信管理网络。由于该软件系统紧紧负责基站的管理与配置,暂时不考虑 traffic 事件部分,仅考虑操作管理部分。TMN 操作管理部分策略主要由：代理模式的使用，比如 O
13、SSRC 作为管理人,Rbs EM 作为代理。使用管理对象（Managed Object，MO)模型,即管理一系列抽象或者物理或者逻辑上的资源。管理信息库（Management Information Base，MIB）的使用，即一个存储了TMN 中所有 MO 的信息库.管理信息模型（Management Information Model，MIM）的使用,即抽象出一个面向对象的语言来抽象规定 MO 的定义，定义 MO 数据的基本操作。一个基本的逻辑架构模型如图 1。5 所示：图图 1.51.5 TMN 管理部分逻辑架构模型本文所描述的通信基站运维综合管理系统 V1。0 是一个 OSS-RC
14、系统下的子系统服务，从 TMN 管理部分的架构逻辑模型上来看，该系统处于架构的在表现层。通常,配站工程师会在软件中对基站进行配置，该软件系统将用户配置5通信基站运维综合管理系统V1.0 设计说明书基站的数据信息收集起来，通过 MO 携带数据，通过 COBRA 等公共协议与指定基站进行通信，向下层传送管理和配置的信息，将所需配置信息发送到指定基站的中央处理单元，而在基站端，通常会有一个类似于接口的子系统，对发送过来的消息进行解析并处理，并将配置信息进行反馈。这样就可以做到基站的安装跟配置分开进行，并且还可以随时对基站进行调控容量，监视基站中设备的状态等操作。基站通信结构示意图如图 1。6 所示：
15、图图 1.61.6 基站通信结构本文中通信基站运维综合管理系统 V1.0 主要提供以下功能：功能特点功能特点:1,IT 资源可视化,轻松读懂各种 IT 数据2，业务拓扑视图，直观展现出业务与 IT 的关系3,IT 资产管理与 IT 监控管理、运维流程管理等无缝集成，实现对以虚拟化和云计算为核心支撑的 IT 体系综合管控。4，完善的 IT 网络运维管理体系,依托统一的服务支持平台，形成自动化、流程化的服务支持。技术特点：技术特点：1，运行环境安装配置方便(。NetFramework,Asp.Net，IIS)2,技术成熟，主流技术,配套技术文档完善,众多开源或免费的文档或项目可供参考3,拥有众多新
16、技术,方便构建企业级应用4，开发部署工具功能强大5，能与 Windows 平台紧密结合，最大限度利用系统功能6通信基站运维综合管理系统V1.0 设计说明书1。1.3 研究意义随着中兴，华为等新兴无线通信公司的崛起，无线通信行业的竞争越来越激烈,各大公司纷纷推出了新产品，软硬件更新速度日益加快，而市场上也出现了基站类型新旧各异，功能各异的复杂情况，即使是同一站型，也会因为需求的变动而导致硬件不同，或者设备参数不同等问题。将原有硬件进行整合，升级改造，已经成为了当前 3G 基站发展的一个主流趋势.这样不仅仅可以节约成本,复用原有的硬件设备，提高利用率，同时可以在更好的兼容基站的原有设备的基础上,达
17、到硬件微小改动，功能大大提升，基站大不一样的特点。目前市场上的一些基站管理配置系统，由于需求已经随着市场的变化而发生了重大改变，从原有的固定不变,几乎很少改动的硬件架构，变成当前这种需求随着市场的变化而迅速变化的情况.以市场为导向的新需求,使得软件层次的架构的变动势在必行。原有的架构层次过于简单,在新项目的开发中出现了架构兼容性不够,代码耦合度过强等问题，导致系统难以维护，升级，一旦有新需求变化，总会进行大幅修改，显然已经无法适应产品的不断更新的新要求。如何设计出一个通用的基站管理系统，满足需求经常变动的特点，成为一个亟待解决的问题，也是本文的主要研究目的。1.2 国内外研究动向爱立信：爱立信
18、的基站管理系统采用了 CI/RI（Configuration Item/ResourceItem）的架构。将基站资源抽象为一系列 Resource Item，将一组相近的资源以聚集的形式构成 Configuration Item，构建出一个逻辑上的 Rbs 进行配置。该管理系统使用了 MVC，Java Bean,SAX 等技术，提供了一个用户友好型界面，通过一个通用平台 CPP 与基站端进行通信。客户端到基站端的通信使用了 COBRA 的技术处理并发。目前爱立信在市场上的主流基站及新硬件设备如图 1。7 所示 5。7通信基站运维综合管理系统V1.0 设计说明书图图 1.71.7 爱立信主流基站
19、及新硬件设备华为6:提供了一个基于 JAVA Web的网页版基站软件管理系统。该管理系统使用了 J2EE 架构，并且使用了 Struts+Hibernate+Spring 等比较流行的框架。图 1。8 是部分华为在 WCDMA 市场上的主流基站.图图 1 1。8 8 华为在 WCDMA 市场上的主流基站1。3 本文主要内容本文一共分为五章,系统的介绍了通信基站运维综合管理系统 V1.0 的设计与实现，下面从分章节的角度详细阐述本文将要论述的主要内容：第一章：首先介绍了本系统所需要的无线通信的背景知识，该系统在UTRAN 系统中所处的位置以及该系统所担当的职能等，其次介绍了国内外研8通信基站运维
20、综合管理系统V1.0 设计说明书究开发的动态，本章最后介绍了本文的主要内容。第二章：主要介绍了本系统的需求分析以及详细架构设计。在需求分析中使用了 ADMENS 矩阵分析法.架构设计的时候先介绍系统的总体架构设计，再分层分别介绍每一层的设计.在介绍的时候不仅仅介绍了设计的思路，同时从设计模式的角度给出了实现策略。第三章：根据上一章设计出的架构,分架构层次，依次详细阐述了每一层的实现过程。实现过程主要以详细的 UML 类图以及时序图为例进行阐述，同时将设计过程中用到的设计模式串联起来.第四章：描述了系统测试的主要方法，以及本系统测试的步骤,最后展示了部分测试用例,同时总结了测试结果。第五章：总结
21、了本论文的主要工作，分析系统中一些值得改进的地方，并且提出了后续研究的一些展望。9第 2 章 基站管理配置软件系统的需求分析以及设计第第 2 2 章章通信基站运维综合管理系统通信基站运维综合管理系统 V1.0V1.0 的需求分析以及的需求分析以及设计设计本章详细描述了基站管理系统的需求分析与架构设计。在需求分析中应用了 ADMENS 矩阵分析法进行分析，架构设计的时候体现了分层的思想，同时为了更好的局部结构，设计模式在本系统中得到了充分的应用.2.1 系统的需求分析通信基站运维综合管理系统 V1.0 提供了一个基站管理配置的平台,针对不同种类的基站进行配置，同时提供了对基站的配置进行修改，删除
22、，以及导入导出配置脚本等功能。在进行本文的需求分析的时候会借助 ADMENS 矩阵进行分析。ADMENS 矩阵7（Architectural Design Method has been Extended toMethodSystem，架构设计方法已经扩展到方法体系），又称为“需求层次-需求方面矩阵”.该矩阵分析法可以帮助架构师告别需求列表的陈旧方式，顺利过渡到二维需求观，借此避免遗漏需求、并进一步清理需求间关系和发现衍生需求。ADMENS 二维矩阵进行需求分析的“四步法”主要由以下 4 个角度分析：需求结构化，分析约束影响，确定关键质量以及确定关键功能.从“需求定义了直接还是间接目标”的角度
23、,把需求划分为 3 种类型：1。功能需求：直接体现出各个需求的目标要求。2.质量属性:由运行期质量和开发期质量组成。3。约束需求：由业务环境因素，使用环境因素以及技术环境因素组成.从业务级需求，用户级需求，开发级需求三个角度对本系统的需求进行具体分析，形成一个二维需求分析矩阵。总结成下表：表表 2 2。1 1 ADMENS矩阵广义功能10质量约束技术性约束第 2 章 基站管理配置软件系统的需求分析以及设计业务级需求业务目标快、好、省法规性约束技术趋势竞争因素与竞争对手遗留系统集成标准性约束分批实施用户级需求用户需求运行期质量用户群特点用户水平多国语言开发级需求行为需求开发期质量开发团队技术水平
24、开发团队磨合程度开发团队分布情况开发团队业务知识管理:保密要求管理：产品规划安装、维护2.1。1 业务级需求的分析本段主要依据：包含客户或者出资者要达到的业务目标、所需要的预期投入资金、项目的工期进度要求，以及要符合哪些标准规范、对哪些遗留的系统进行整合改造等约束条件，对论文中阐述的系统进行业务级需求分析。下面详细阐述本系统需要主要考虑的约束条件。（1）客户的业务目标以及业务愿景。1.软件定位：基站管理软件2。提供服务：提供一个通用的管理配置平台，对同一家公司不同类型，不同硬件的基站进行配置。（2)客户的业务质量1.兼容新老基站。由于技术的改革，软件必须兼容各种各样的新老基站，在满足新基站的配
25、置要求的同时要做到向后兼容。特别是基站硬件的更新，各大无线通信公司目前都在做整合的研发，将老基站几块硬件板子的功能集成到一块硬件上的创新研究，软件变更需要跟硬件的变更同步化，满足硬件变更所带来的配置变更。2。易于变更配置。同一款基站，很有可能会配置不同的射频单元，或者有扇11第 2 章 基站管理配置软件系统的需求分析以及设计区变动配置的需求，需要提供一个简洁而又实用的向导来满足配置的变更，同一种硬件配置也需要能够方便的修改承载能力等，以达到资源的利用合理化。（3)技术标准3GPP，以及各大厂商自己制定的标准。（4)对哪些遗留系统进行整合基站零部件种类繁多，各种型号的基站之间硬件配置有较大区别，
26、需要一个扩展性很强的系统来代替原有系统，以便将来产品进一步更新换代。2.1.2 用户级需求的分析用户及需求的分析主要从如下几个角度入手：用户需要使用系统来完成哪些工作，对质量有哪些要求，用户群及所处的使用环境方面有哪些要求等条件来进行用户级需求分析。下面结合本系统进行分析：（1）用户使用系统完成的辅助工作该系统主要的用户人员是基站配置人员,他们使用该系统进行基站的配置，修改，删除等操作.配置向导里面的配置项有一些是有跟具体硬件相关的默认值的,还有一些必须要用户来配置，这些配置向导按照基站的配置流程分多个页面进行。该基站管理软件主要提供四个配置向导界面：1。机箱/机柜配置向导：这部分的配置的硬件
27、设备，除了基带信号处理板的配置，还有一些硬件板，通常在交付客户之前，在工厂就有一些烧制或者录入的默认配置,插入机箱机柜中，所以需要在这里一并配置。在这个配置向导里面需要配置的主要有:选择Rbs 的类型,配置默认的 IP 地址，接口板等硬件设备。2。基站站点配置向导主要功能是建立扇区，配置小区,天线系统的相关硬件，电缆相关数据,该部分需要配置的硬件组合相对比较灵活，可以依照基站的承载能力等条件，自由组合配置。3。修改配置向导该配置向导比较特别，该功能的实现需要借助 XML+SAX 来实现，所以该配置向导的输入仅为 XML 修改配置文件。该向导主要配置页面仅仅由一个文件输入页面以及需要修改的目录结
28、果组成。4。导入导出，删除向导这几个功能也都是通过 XML+SAX 实现,所以该配置向导同上，输入/输出仅仅为 XML 文件。（2）质量要求12第 2 章 基站管理配置软件系统的需求分析以及设计1。操作方便,界面友好。2.系统具有很强的健壮性,尽量避免系统崩溃。3.能够满足不同的配置的情况下,仍具有较强的可靠性。(3)客户需求约束配站工程师水平参差不齐，提供一个用户友好型，简洁的配置界面，需要易于操作。2.1。3 开发级需求的分析本段主要依据：开发人员具体需要实现什么产品，开发维护期间对质量有哪些考虑,开发团队有无影响架构的情况等因素来进行需求分析.下面仅考虑本系统开发中需要用到的约束条件:(
29、1）开发人员需要实现目标一个用户友好型的通信基站运维综合管理系统 V1.0。需要提供如下基本服务:1.机柜机箱配置：需要实现机箱机柜的配置，以及出厂时安装的其他硬件板的所有配置。机箱机柜通常会提供一系列的插槽,相关的硬件在出厂的时候分别安装在具体的插槽中,一并交付，所以这些硬件板需要跟机柜机箱配置一同进行配置。2。基站配置：主要负责射频单元硬件的配置,辅助单元（比如风扇、电源之类）的配置，以及天线系统相关设备的配置,这部分的硬件大多具有可以频繁更换的特性，所以这部分代码结构需要尽量松散，耦合度越低越好。3。导出/删除功能:导出功能可以导出当前 Rbs 的配置 XML 文件，可以让我们在测试环境
30、中创建相同的用户配置,也可以给其他站点进行相同的配置。删除功能可以删除当前 Rbs 中所有不重要的配置,重新配站的情况下可以使用。本系统使用SAX的技术来解析XML文件，所以在这里需要提供DTD文件规范XML文件的格式。4.修改功能：可以提供给基站操作人员在不停止 Rbs 的情况下，修改基站的配置的功能。主要有射频单元的修改，天线的修改,扇区的增加、删除，小区的增加、删除等等功能.(2）开发期间的质量约束1。以测试驱动的原则进行开发，尽量做到步步可测。2.代码实现的时候尽量多用设计模式的原则,降低代码的耦合度,提高可扩展性.综上所述，总结得到的 ADMENS 矩阵如下表所示：13第 2 章 基
31、站管理配置软件系统的需求分析以及设计表表 2.22.2 ADMENS 矩阵（需求层次-需求方面矩阵）功能功能质量质量商业质量商业质量约束约束商业约束商业约束业务级需求业务目标及业务愿景业务目标及业务愿景软件定位：基站管理软件提供服务:对各种类型,各种硬件提供一个通用性的配站软件兼容新老基站配置基站零部件种容错率高类繁多各种型号的基站，硬件之间有较大区别需要较强的可扩展可扩展性,以便将来产品更新换代用户级需求潜在用户潜在用户配站工程师运行期质量运行期质量操作简单，易于上手多用性用户约束用户约束工程师水平层次不齐，提供一些必要提示防御性编程，检测未知的配置错误开发级需求开发期质量开发期质量可扩展性
32、步步可测开发方约束开发方约束只有一人时间短工程量大2。2 基站管理软件系统的架构设计本节主要是从整体上对本通信基站运维综合管理系统 V1.0 的设计进行详细阐述。本节主要分两个层次来阐述，先从系统的逻辑架构,功能模块以及鲁棒性设计三个角度来阐述该基站管理软件系统的设计，然后依据本系统的架构层次来具体阐述每一层的设计思路以及实现策略。2。2.1 系统总体概要设计本小节仅仅是对系统总体架构概要设计的介绍，不对具体细节的设计与实14第 2 章 基站管理配置软件系统的需求分析以及设计现做分析.本节从系统的逻辑架构，功能模块以及鲁棒性设计三个角度来阐述该基站管理软件系统的概要设计.2。2。1.1 系统的
33、逻辑架构基站管理软件系统的逻辑架构图见图 2.1。该系统的设计思路以企业应用架构模式中流行的三层架构为基础，根据本系统的需求分析而衍生出来的五层架构，每一层都依托在其下层之上来构建,上层使用下层定义的各种接口，而下层对上层如何调用一无所知。另外，每一层对自己的上层隐藏其实现细节。各层之间尽量做到相对透明89。在表现层中使用了当前最流行的 MVC 框架模式进行设计，在逻辑实现层中，参照企业级应用架构中的领域逻辑层的设计思路，上层参照服务层构建，将本系统所提供的服务独立出一层，成为功能模块层，对表现层提供服务，下层逻辑实现层使用领域模式，使用一系列对象来承担相关逻辑,数据层分为 2层，上层物理数据
34、层是对物理硬件的一一对应，并且与 MO 进行聚集处理,下层逻辑数据层则是对应所在公司的 Manage Object 架构，使用一些简单的 POJO 来构建数据库，同时可以使用这些数据类承载本系统的配置信息,与其他子系统进行数据通信。15第 2 章 基站管理配置软件系统的需求分析以及设计图图 2 2。1 1 基站软件系统的逻辑架构多层次的架构体系，使得系统的灵活性极大增强，每层仅仅对其上下层负责，降低了系统的耦合度，可以将一个新硬件的需求给软件代码带来的影响在最小范围内扩散，很好的满足频繁增加新特性的需求。同时在每层之间按模块划分的策略和设计模式的大量应用，优化了系统的局部细节，极大降低了各个子
35、模块之间的耦合度10。表 现 层 的 设 计 概 要：该 层 采 用 当 今 世 界 主 流 的 GUI 设 计 模式:MVC(ModelView-Controller)模式,即模型-视图-控制器模式，MVC 模式可以按照模型、绘图表达方式和行绘图为等角色把一个应用系统的各个部分解耦分割开来。使用该模式，可以将本系统中的图形界面的绘制跟图形界面的控制分开，很好的满足了设计目标11。同时由于该基站管理配置系统的配置向导页面中有许多共同的插件，可以将将视图端以及控制器端共有的部分抽象到他们的父类，在父类中实现对页面的控制等共有的逻辑，这样的设计思想体现出了软件设计模式中的里氏代换原则以及依赖倒转原
36、则。子类继承时通过装饰模式等设计方法来实现各自页面不同的视图，加减页面12都不会对原来的架构有影响，满足开闭原则，对应的视图以及控制器仅仅通过模型端进行交互，满足14迪米特法则13。逻辑控制层部是整个系统中对配置行为进行控制的地方，同时也负责 Rbs 对象的创建等工作，该层分两层实现：功能模块层设计概要:该层主要采用建造模式来实现，以功能模块层的需求为依据分别建造，提供各种各样的产品。对应于该管理软件的功能，给出其相对应的类来提供目标功能模块，组装构建等细节等实现部分则对上层透明，该层并不负责细节逻辑的实现,而是一些实现功能的组合，具体的实现通过代理模式的思想交由下层负责。基于此，该层主要是一
37、些功能等创建组合的控制的接口，通过这些接口来调用下层的逻辑实现层，并委托下层来实现需要的逻辑。每一个功能对应一个建造类，通过建造模式，可以做到复用逻辑实现层的零件产品，同时各功能模块之间相对保持透明，满足迪米特法则.逻辑实现层设计概要：该层建立一个全部由对象组成的领域层，来对目标对象的业务建模，其中每一个对象仅仅负责一个单一的功能的实现.由于业务的具体行为是经常变化的，因此易于修改和测试对逻辑实现层来说十分重要。该层主要采用享元模式来进行构建，内蕴对象主要来存储跟该逻辑对象配置相关的一些常量数据，外蕴对象主要来存储该逻辑对象需要配置的数据对象。该层的主要功能是：向下调用下层数据层中的数据，并对
38、数据直接进行读写等操作,实现一些独立的，单一的，简单化功能，向上接受上一层功能模块层的委托调16第 2 章 基站管理配置软件系统的需求分析以及设计用，实现功能模块层的需求15.基站管理软件系统的数据操作部分主要集中在这一层,产品中有一系列的数据操作方法，对数据层的数据类进行读写操作。数据层部分：该层分为 2 层，上层为物理数据层，与具体基站的物理硬件一一对应,下层为 POJO 层，作为与整个UTRAN 系统的接口，将系统系统高层定义的 MO 与本软件系统的数据进行一个一一映射。通常为了满足硬件结构的变化，系统定义出的 MO 也会相应随之调整，结构并不稳定。如果数据层采用单一的层次,那么由于不停
39、变化的需求，会导致数据层的经常改动,影响架构的稳定性16。物理数据层设计概要:该层采用合成/聚集原则调用 POJO 层的数据对象,创建构建成不同型号的物理硬件的一系列对象，与真正的物理硬件一一对应17。POJO 层设计概要：POJO,即简单的 Java 对象，仅包含一些属性以及一些 get，set 方法,并不包含业务方法。该层主要作用就是提供一些最基本的数据供上层使用，对系统定义的 MO 数据进行一一映射，转化成本系统所能够使用的数据。2.2。1。2 产品的功能模块结构产品的功能模块结构见图 2。2。用户需要先选定Rbs 基站的型号，该系统则会根据用户的选择生成相应的基站配置界面，接下来就可以
40、进行机箱机柜 cabinet、站点 site、扇区、天线系统等基站主要硬件的配置。该管理软件同时提供了修改 modify/导出 export/删除 delete 等功能，修改modify 功能可以在不重启基站的情况下，调整基站的扇区、载波配置等设备的负载量等配置信息；导出 export功能则可以将当前基站的配置以 XML 的格式一次导出,以便下次配站使用；删除 Delete 功能则是可以将基站当前配置删除，方便用户重新配站。图图 2 2。2 2 产品的功能模块结构图17第 2 章 基站管理配置软件系统的需求分析以及设计2。2。1.3 系统概要设计的鲁棒性分析系统概要设计的鲁棒图见图 2。3。从
41、图中可以看到,当工程师选定了 Rbs 基站的类型以后，会有一个相对应的工厂方法，生成该 Rbs 基站相对应的实例，该实例以创建最大化的方式,初始化该基站的所有功能服务,并且保存该类型的基站所特有的数据逻辑。该基站的实例对象采用单例模式，在整个配置过程中只有这一个实例对象，方便记录基站的配置信息以及对基站配置信息的修改信息。接下来的各种功能实现部分主要是对 Rbs 基站的配置数据进行操作,所以可以直接对这个单例对象进行操作。各功能模块之间都做了很好的隔离,控制部分相对独立，每个功能对于其他功能没有影响，一个地方出错了并不影响其他功能的使用，有很好的鲁棒性。图图 2.32.3 系统概要设计的鲁棒图
42、2.2.2 POJO 层的设计2.2.2.1 MO（ManageObject）策略通常 MO 由高层系统工程师来设计与实现，将 Rbs 中的资源逻辑抽象为一18第 2 章 基站管理配置软件系统的需求分析以及设计系列对象，再由面向对象的软件语言如Java,C+，在各自子系统实现细节，再由 MO 之间属性的交互,来实现不同子系统间数据的交互。MO 从高层体现出一致性，即各个子系统所使用的 MO，虽然分属各自的子系统，但是必须完全一样。一般 Rbs 基站的软件架构采用数据驱动的方式，各个子系统相对独立，仅仅依赖数据的传递进行通信。MO 就是数据交互的关键,MO 承载了各自子系统的数据信息。一个 MO
43、 中通常会包含两类参数：属性,Attributes：跟 MO 抽象的资源相关的参数变量,这些资源可以在配置的时候给他们赋值，资源的状态也可以通过读取这些值来获得。行为，Actions：表示所能对一个 MO 采用的行动，比如加锁，删除等。本文所要实现的通信基站运维综合管理系统 V1。0，实际上就是采用一系列的 Java 类来对应 MO,将配置信息存到 MO 中，通过配置这些 MO 的 attributes和 actions 来实现对基站的配置,最后讲收集到的所有配置信息，发送到中央处理单元中。图 2.4 是一个采用了 MO 模型的 Rbs 基站的示意图:图图 2 2。4 4 Rbs 基站的 MO
44、M 模型上图中矩形代表 Rbs 节点整体，正面是 Rbs 从系统的角度所能看到的资源,侧面则是对 Rbs 资源的抽象：MOM（MO Model）。从图上可以看出:MO 模型即是对 Rbs 系统的角度所能看到的资源的另一种表示所构建成的模型：抽象成为一系列可以管理的对象 MO，从一系列对象的角度来看 Rbs 的资源。表 2。3 的 MO 取自爱立信 Rbs 基站，6601 型号远程基站,slot 的信息表。表表 2 2。3 3Slot 信息表Possible parentPossible childrensubrackAuxPlugInUnitBbifBoard19第 2 章 基站管理配置软件系
45、统的需求分析以及设计PlugInUnitActionsAttributesupdateConfiguration（）activeSwAllocationproductDatareservedBySlotIdslotNumberslotStateSlot：是对机框中插槽资源的一个抽象。从该表中可以看出：slot 的父亲节点只有一个，机框 subrack;可能的孩子节点有 3 个,可插入插槽单元 PlugInUnit，比如基带板,射频板，信号过滤板等;远程单元 AuxPlugInUnit，比如倾角调整器RET，塔放TMA 等；一种基带板与射频单元的交互接口 BbifBoard。该 MO 的 act
46、ion 仅有一个：updateConfiguration。表示如果该基站是自动配置，则该 action 会触发该插槽下硬件单元的自动配置行为。6 个 Attributes 分别表示：activeSwAllocation 表示此刻该插槽是否有PlugInUnit 在使用，如果没有 PlugInUnit 在次插槽被配置使用,则该属性的值为空。productData 属性描述当前插入单元的信息,该属性一旦赋值,则无论其插入硬件板是否工作，该值都不会变，该属性的值只有在 slot 换新硬件板的时候才会改变。reservedBy 该属性以一个列表形式存在,是储备这个 MO 的所有 MO 的一个列表。Sl
47、otId，该属性的值是用来组成 RDN 的。slotNumber 该属性的值从左往右开始数起，从 1 开始,用来表示插槽位置的。slotState 属性用来表明该插槽的状态。该 MO 的是在其父亲 MO 的创建的时候创建的,并且不能被删除。该 MO 插槽的数目是在其父亲节点 subrack 中定义的。2。2.2.2 MO 的查找：RDN 与 LDNRDN:Relative Distinguished Name，相对标识名.RDN 的命名跟该 MO 的父亲节点相关。这个属性的值在他被建立的时候就定义好了，并且不能改变.LDN：Local Distinguished Name,本地专有名称。由该
48、Rbs 节点中一系列的 RDN所形成的一个独一无二的名字。RDN 在查找父子节点的 MO 时候使用，LDN 在全局查找 MO 的使用。图2.5 是RNC 中的一个 MO的结构，由下可以看出 RDN 跟 LDN 如何命名，以及 LDN 是如何由 RDN 所形成的:20第 2 章 基站管理配置软件系统的需求分析以及设计图图 2 2。5 5 一个使用 RND/LDN 的 MO 结构由上图可以看出 RncFunction 这个 MO 的 RDN=RncFunctionId=0”，由于 RncFunction 本身就是根节点，所以 LDN 等于 RDN。UtranCell 这个 MO 的RDN=Utra
49、nCellId=”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.3 MO 的映射机制MO的映射机制采用 POJO 模式策略.从高层系统规定定义的 MO到该软件
50、配置21第 2 章 基站管理配置软件系统的需求分析以及设计管理系统的数据库所采用的映射技术由 POJO 模式实现.POJO：Plain Old Java Object，简单 Java 对象。POJO 是一个简单的普通的Java 对象，它不包含业务逻辑或者持久化逻辑等，没有从任何类继承，不担当任何特殊的角色，也没有实现任何接口，更没有被其他框架侵入的 Java 对象.每一个 MO 由一个 POJO 来负责实现，由一个具体的 Java 类来代表一个MO,Java 中的字段设置成私有的，分别表示 MO 中的 attribute 跟 action。一系列的 get/set 方法来负责数据的读写.2.2