通信基站运维综合管理系统V设计说明书.docx
《通信基站运维综合管理系统V设计说明书.docx》由会员分享，可在线阅读，更多相关《通信基站运维综合管理系统V设计说明书.docx（42页珍藏版）》请在冰豆网上搜索。
通信基站运维综合管理系统V设计说明书
第1章绪论
本文主要介绍通信基站运维综合管理系统V1.0的设计与实现。
本章首先介绍本系统的背景知识以及研究意义；然后阐述国内外研究以及开发的最新动态，最后介绍本文的主要内容以及组织结构安排。
1.1研究背景与意义
本节主要介绍本文涉及的一些无线通信知识，首先介绍与本文描述的通信基站运维综合管理系统V1.0相关的WCDMA的概念，UTRAN系统，RAN系统以及Rbs的知识，然后详细描述本系统在WCDMA系统所处的位置和该系统所需要提供的功能。
最后再系统阐述本文的研究意义。
1.1.13G无线通信相关知识
WCDMA[1]：
WidebandCodeDivisionMultipleAccess宽带码分多址。
是一种由码分多址（CDMA），演变而来的第三代无线通信技术。
WCDMA采用直接序列扩频码分多址、频分双工方式。
WCDMA是一种由3GPP具体制定的，基于GSMMAP核心网，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主要负责与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通过luant接口或者其他一些专有的规范标准来控制与监管TMA、RET等天线设备。
RbsElementManager：
基站管理软件，并不是UTRAN系统中的一个独立节点，但是他是Rbs系统的一部分，EM一般运行在PC端口，控制了包含一系列操作管理应用软件的安装。
RbsCabinetViewer：
机箱机柜查看器，是部署在OSS-RC上的一个应用程序，但是他仍然属于Rbs系统的一部分。
机箱机柜查看器提供了一个可视化视图，并且提供了一个工具来处理由事件干扰引起的错误。
图1.2UTRAN系统的拓扑结构
图1.3是Rbs所处的位置以及Rbs与其他节点的关系：
图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灯），手动的可操作的开关/按钮（复位键）和传入的外部电源等。
另外，装配的电缆螺丝等都属于这个接口。
1.1.2基站管理软件功能
ITU-TTMN:
TelecommunicationsManagementNetworkstandardfromtheITU-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管理部分的架构逻辑模型上来看，该系统处于架构的在表现层。
通常，配站工程师会在软件中对基站进行配置，该软件系统将用户配置基站的数据信息收集起来，，通过MO携带数据，通过COBRA等公共协议与指定基站进行通信，向下层传送管理和配置的信息，将所需配置信息发送到指定基站的中央处理单元，而在基站端，通常会有一个类似于接口的子系统，对发送过来的消息进行解析并处理，并将配置信息进行反馈。
这样就可以做到基站的安装跟配置分开进行，并且还可以随时对基站进行调控容量，监视基站中设备的状态等操作。
基站通信结构示意图如图1.6所示:
图1.6基站通信结构
本文中通信基站运维综合管理系统V1.0主要提供以下功能：
功能特点：
1，IT资源可视化，轻松读懂各种IT数据
2，业务拓扑视图，直观展现出业务与IT的关系
3，IT资产管理与IT监控管理、运维流程管理等无缝集成，实现对以虚拟化和云计算为核心支撑的IT体系综合管控。
4，完善的IT网络运维管理体系，依托统一的服务支持平台，形成自动化、流程化的服务支持。
技术特点：
1，运行环境安装配置方便?
（.Net?
Framework,?
Asp.Net,?
IIS）
2，技术成熟，主流技术，配套技术文档完善，众多开源或免费的文档或项目可供参考
3，拥有众多新技术，方便构建企业级应用
4，开发部署工具功能强大
5，能与Windows平台紧密结合，最大限度利用系统功能
1.1.3研究意义
随着中兴，华为等新兴无线通信公司的崛起，无线通信行业的竞争越来越激烈，各大公司纷纷推出了新产品，软硬件更新速度日益加快，而市场上也出现了基站类型新旧各异，功能各异的复杂情况，即使是同一站型，也会因为需求的变动而导致硬件不同，或者设备参数不同等问题。
将原有硬件进行整合，升级改造，已经成为了当前3G基站发展的一个主流趋势。
这样不仅仅可以节约成本，复用原有的硬件设备，提高利用率，同时可以在更好的兼容基站的原有设备的基础上，达到硬件微小改动，功能大大提升，基站大不一样的特点。
目前市场上的一些基站管理配置系统，由于需求已经随着市场的变化而发生了重大改变，从原有的固定不变，几乎很少改动的硬件架构，变成当前这种需求随着市场的变化而迅速变化的情况。
以市场为导向的新需求，使得软件层次的架构的变动势在必行。
原有的架构层次过于简单，在新项目的开发中出现了架构兼容性不够，代码耦合度过强等问题，导致系统难以维护，升级，一旦有新需求变化，总会进行大幅修改，显然已经无法适应产品的不断更新的新要求。
如何设计出一个通用的基站管理系统，满足需求经常变动的特点，成为一个亟待解决的问题，也是本文的主要研究目的。
1.2国内外研究动向
爱立信：
爱立信的基站管理系统采用了CI/RI（ConfigurationItem/ResourceItem）的架构。
将基站资源抽象为一系列ResourceItem，将一组相近的资源以聚集的形式构成ConfigurationItem，构建出一个逻辑上的Rbs进行配置。
该管理系统使用了MVC，JavaBean，SAX等技术，提供了一个用户友好型界面，通过一个通用平台CPP与基站端进行通信。
客户端到基站端的通信使用了COBRA的技术处理并发。
目前爱立信在市场上的主流基站及新硬件设备如图1.7所示[5]。
图1.7爱立信主流基站及新硬件设备
华为[6]：
提供了一个基于JAVAWeb的网页版基站软件管理系统。
该管理系统使用了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]（ArchitecturalDesignMethodhasbeenExtendedtoMethodSystem，架构设计方法已经扩展到方法体系），又称为“需求层次--需求方面矩阵”。
该矩阵分析法可以帮助架构师告别需求列表的陈旧方式，顺利过渡到二维需求观，借此避免遗漏需求、并进一步清理需求间关系和发现衍生需求。
ADMENS二维矩阵进行需求分析的“四步法”主要由以下4个角度分析：
需求结构化，分析约束影响，确定关键质量以及确定关键功能。
从“需求定义了直接还是间接目标”的角度，把需求划分为3种类型：
1.功能需求：
直接体现出各个需求的目标要求。
2.质量属性：
由运行期质量和开发期质量组成。
3.约束需求：
由业务环境因素，使用环境因素以及技术环境因素组成。
从业务级需求，用户级需求，开发级需求三个角度对本系统的需求进行具体分析，形成一个二维需求分析矩阵。
总结成下表：
表2.1ADMENS矩阵
广义功能
质量
约束
业务级需求
业务目标
快、好、省
技术性约束
法规性约束
技术趋势
竞争因素与竞争对手
遗留系统集成
标准性约束
分批实施
用户级需求
用户需求
运行期质量
用户群特点
用户水平
多国语言
开发级需求
行为需求
开发期质量
开发团队技术水平
开发团队磨合程度
开发团队分布情况
开发团队业务知识
管理：
保密要求
管理：
产品规划
安装、维护
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.2ADMENS矩阵（需求层次--需求方面矩阵）
功能
质量
约束
业务级需求
业务目标及业务愿景
软件定位：
基站管理软件
提供服务：
对各种类型，各种硬件提供一个通用性的配站软件
商业质量
兼容新老基站配置
容错率高
商业约束
基站零部件种类繁多
各种型号的基站，硬件之间有较大区别
需要较强的可扩展可扩展性，以便将来产品更新换代
用户级需求
潜在用户
配站工程师
运行期质量
操作简单，易于上手
多用性
用户约束
工程师水平层次不齐，提供一些必要提示
防御性编程，检测未知的配置错误
开发级需求
开发期质量
可扩展性
步步可测
开发方约束
只有一人
时间短工程量大
2.2基站管理软件系统的架构设计
本节主要是从整体上对本通信基站运维综合管理系统V1.0的设计进行详细阐述。
本节主要分两个层次来阐述，先从系统的逻辑架构，功能模块以及鲁棒性设计三个角度来阐述该基站管理软件系统的设计，然后依据本系统的架构层次来具体阐述每一层的设计思路以及实现策略。
2.2.1系统总体概要设计
本小节仅仅是对系统总体架构概要设计的介绍，不对具体细节的设计与实现做分析。
本节从系统的逻辑架构，功能模块以及鲁棒性设计三个角度来阐述该基站管理软件系统的概要设计。
2.2.1.1系统的逻辑架构
基站管理软件系统的逻辑架构图见图2.1。
该系统的设计思路以企业应用架构模式中流行的三层架构为基础，根据本系统的需求分析而衍生出来的五层架构，每一层都依托在其下层之上来构建，上层使用下层定义的各种接口，而下层对上层如何调用一无所知。
另外，每一层对自己的上层隐藏其实现细节。
各层之间尽量做到相对透明[8][9]。
在表现层中使用了当前最流行的MVC框架模式进行设计，在逻辑实现层中，参照企业级应用架构中的领域逻辑层的设计思路，上层参照服务层构建，将本系统所提供的服务独立出一层，成为功能模块层，对表现层提供服务，下层逻辑实现层使用领域模式，使用一系列对象来承担相关逻辑，数据层分为2层，上层物理数据层是对物理硬件的一一对应，并且与MO进行聚集处理，下层逻辑数据层则是对应所在公司的ManageObject架构，使用一些简单的POJO来构建数据库，同时可以使用这些数据类承载本系统的配置信息，与其他子系统进行数据通信。
图2.1基站软件系统的逻辑架构
多层次的架构体系，使得系统的灵活性极大增强，每层仅仅对其上下层负责，降低了系统的耦合度，可以将一个新硬件的需求给软件代码带来的影响在最小范围内扩散，很好的满足频繁增加新特性的需求。
同时在每层之间按模块划分的策略和设计模式的大量应用，优化了系统的局部细节，极大降低了各个子模块之间的耦合度[10]。
表现层的设计概要：
该层采用当今世界主流的GUI设计模式：
MVC（Model-View-Controller）模式，即模型-视图-控制器模式，MVC模式可以按照模型、绘图表达方式和行绘图为等角色把一个应用系统的各个部分解耦分割开来。
使用该模式，可以将本系统中的图形界面的绘制跟图形界面的控制分开，很好的满足了设计目标[11]。
同时由于该基站管理配置系统的配置向导页面中有许多共同的插件，可以将将视图端以及控制器端共有的部分抽象到他们的父类，在父类中实现对页面的控制等共有的逻辑，这样的设计思想体现出了软件设计模式中的里氏代换原则以及依赖倒转原则。
子类继承时通过装饰模式等设计方法来实现各自页面不同的视图，加减页面[12]都不会对原来的架构有影响，满足开闭原则，对应的视图以及控制器仅仅通过模型端进行交互，满足迪米特法则[13][14]。
逻辑控制层部是整个系统中对配置行为进行控制的地方，同时也负责Rbs对象的创建等工作，该层分两层实现：
功能模块层设计概要：
该层主要采用建造模式来实现，以功能模块层的需求为依据分别建造，提供各种各样的产品。
对应于该管理软件的功能，给出其相对应的类来提供目标功能模块，组装构建等细节等实现部分则对上层透明，该层并不负责细节逻辑的实现，而是一些实现功能的组合，具体的实现通过代理模式的思想交由下层负责。
基于此，该层主要是一些功能等创建组合的控制的接口，通过这些接口来调用下层的逻辑实现层，并委托下层来实现需要的逻辑。
每一个功能对应一个建造类，通过建造模式，可以做到复用逻辑实现层的零件产品，同时各功能模块之间相对保持透明，满足迪米特法则。
逻辑实现层设计概要：
该层建立一个全部由对象组成的领域层，来对目标对象的业务建模，其中每一个对象仅仅负责一个单一的功能的实现。
由于业务的具体行为是经常变化的，因此易于修改和测试对逻辑实现层来说十分重要。
该层主要采用享元模式来进行构建，内蕴对象主要来存储跟该逻辑对象配置相关的一些常量数据，外蕴对象主要来存储该逻辑对象需要配置的数据对象。
该层的主要功能是：
向下调用下层数据层中的数据，并对数据直接进行读写等操作，实现一些独立的，单一的，简单化功能，向上接受上一层功能模块层的委托调用，实现功能模块层的需求[15]。
基站管理软件系统的数据操作部分主要集中在这一层，产品中有一系列的数据操作方法，对数据层的数据类进行读写操作。
数据层部分：
该层分为2层，
升级会员 