通信基站運維綜合管理系統(tǒng)V10設計說明書.doc

通信基站運維綜合管理系統(tǒng)V1.0設計說明書第1章 緒論本文主要介紹通信基站運維綜合管理系統(tǒng)V1.0的設計與實現(xiàn)。本章首先介紹本系統(tǒng)的背景知識以及研究意義；然后闡述國內(nèi)外研究以及開發(fā)的最新動態(tài)，最后介紹本文的主要內(nèi)容以及組織結構安排。1.1 研究背景與意義本節(jié)主要介紹本文涉及的一些無線通信知識，首先介紹與本文描述的通信基站運維綜合管理系統(tǒng)V1.0相關的WCDMA的概念，UTRAN系統(tǒng)，RAN系統(tǒng)以及Rbs的知識，然后詳細描述本系統(tǒng)在WCDMA系統(tǒng)所處的位置和該系統(tǒng)所需要提供的功能。最后再系統(tǒng)闡述本文的研究意義。1.1.1 3G無線通信相關知識 WCDMA1：Wideband Code Division Multiple Access寬帶碼分多址。是一種由碼分多址（CDMA），演變而來的第三代無線通信技術。WCDMA采用直接序列擴頻碼分多址、頻分雙工方式。WCDMA是一種由3GPP具體制定的，基于GSM MAP核心網(wǎng)，UTRAN為無線接口的第三代移動通信系統(tǒng)。 UTRAN：The UMTS Terrestrial Radio Access Network，陸地無線接入網(wǎng)。信令網(wǎng)和數(shù)據(jù)傳輸網(wǎng)在邏輯上分開2；UTRAN和CN的功能將和傳輸功能完全分開；UTRAN和CN使用的尋址方式將和傳輸功能的尋址方式無關；宏分級（FDD模式）的處理完全在UTRAN內(nèi)，RRC的連接的移動性完全由UTRAN控制；定義UTRAN接口時候，通過接口的功能的劃分應有盡量少的可選項；應基于此接口控制的實體的邏輯模型。 UTRAN由一組通過Iu接口連接到核心網(wǎng)CN的無線網(wǎng)絡子系統(tǒng)RNS組成。一個RNS由一個無線網(wǎng)絡控制器（RNC）和一個或者多個節(jié)點（Node B）組成。Rbs通過Iub接口連接到RNC。圖1.1是UTRAN系統(tǒng)的部分平面結構圖。從圖中可以看出：RNC主要負責跟核心網(wǎng)的交互以及與Rbs進行交互。Rbs主要負責與RNC交互，以及用戶手機交互。從軟件架構的角度，UTRAN主要分為以下3個邏輯節(jié)點： （1）RNC（Radio Network Controller）無線網(wǎng)絡控制器。RNC主要負責跟核心網(wǎng)以及Rbs進行交互，并且負責管理無線鏈路。RNC控制通過Rbs的信息量。RNC同時負責建立信道，處理與UE的連接，控制無線基站的資源的優(yōu)化。WCDMA的Rbs提供無線資源以及無線廣播，并且負責接受與發(fā)送UE信號。圖1.1 UTRAN系統(tǒng)的平面結構 （2）OSS-RC (Operation Support System-Radio and Core) 運維支撐系統(tǒng)-無線基站跟核心網(wǎng)。OSS-RC主要處理從RNC過來的操作管理任務，比如軟件的安裝與升級，RAN層的管理配置，告警處理等。 （3）COMINF (Common Operate&Manage Infrastructure) 通用操作管理架構。COMINF主要管理包括從網(wǎng)絡設備到OSS-RC所需要攜帶的路由等網(wǎng)絡協(xié)議。COMINF同時提供安全性服務，客戶幫助信息，軟件管理，備份解決方案等服務。UTRAN的拓撲結構和關鍵節(jié)點的外部接口如圖1.2所示：（節(jié)點跟接口在下圖中僅僅是一個邏輯插圖，跟實際情況不一定完全吻合。比如Mub和Iub接口可能承載相同的媒體，W-Rbs也可能以級聯(lián)拓撲的形式連接）Rbs3（Radio Base Station）：WCDMA中的Rbs就是UTRAN系統(tǒng)節(jié)點中基站的特有名稱。Node B是一個邏輯節(jié)點，負責發(fā)送，接收從UE過來的信道。Rbs節(jié)點除了處理最基本的功能以外，同時還控制與監(jiān)管天線設備。Rbs通過luant接口或者其他一些專有的規(guī)范標準來控制與監(jiān)管TMA、RET等天線設備。Rbs Element Manager：基站管理軟件，并不是UTRAN系統(tǒng)中的一個獨立節(jié)點，但是他是Rbs系統(tǒng)的一部分，EM一般運行在PC端口，控制了包含一系列操作管理應用軟件的安裝。Rbs Cabinet Viewer：機箱機柜查看器，是部署在OSS-RC上的一個應用程序，但是他仍然屬于Rbs系統(tǒng)的一部分。機箱機柜查看器提供了一個可視化視圖，并且提供了一個工具來處理由事件干擾引起的錯誤。圖1.2 UTRAN系統(tǒng)的拓撲結構圖1.3是Rbs所處的位置以及Rbs與其他節(jié)點的關系：圖1.3 Rbs與RNC、OSS-RC的關系從圖上可以看出：Rbs主要通過Mub接口與OSS-RC交互，通過lub接口與RNC交互，通過Uu接口與UE交互。管理軟件EM在OSS-RC節(jié)點上，負責管理與配置Rbs4。圖1.4是Rbs外部接口的平面圖：圖1.4 Rbs的外部接口Mub：Mub接口是由Rbs所提供的，由管理軟件EM，機箱機柜查看器，網(wǎng)絡管理系統(tǒng)等系統(tǒng)使用。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) 國際電信聯(lián)盟電信標準化部，電信管理網(wǎng)絡。由于該軟件系統(tǒng)緊緊負責基站的管理與配置，暫時不考慮traffic事件部分，僅考慮操作管理部分。TMN操作管理部分策略主要由： 代理模式的使用，比如OSS-RC作為管理人，Rbs EM作為代理。 使用管理對象（Managed Object，MO）模型，即管理一系列抽象或者物理或者邏輯上的資源。 管理信息庫（Management Information Base，MIB）的使用，即一個存儲了TMN中所有MO的信息庫。 管理信息模型（Management Information Model，MIM）的使用，即抽象出一個面向對象的語言來抽象規(guī)定MO的定義，定義MO數(shù)據(jù)的基本操作。 一個基本的邏輯架構模型如圖1.5所示：圖1.5 TMN管理部分邏輯架構模型本文所描述的通信基站運維綜合管理系統(tǒng)V1.0是一個OSS-RC系統(tǒng)下的子系統(tǒng)服務，從TMN管理部分的架構邏輯模型上來看，該系統(tǒng)處于架構的在表現(xiàn)層。通常，配站工程師會在軟件中對基站進行配置，該軟件系統(tǒng)將用戶配置基站的數(shù)據(jù)信息收集起來，通過MO攜帶數(shù)據(jù)，通過COBRA等公共協(xié)議與指定基站進行通信，向下層傳送管理和配置的信息，將所需配置信息發(fā)送到指定基站的中央處理單元，而在基站端，通常會有一個類似于接口的子系統(tǒng)，對發(fā)送過來的消息進行解析并處理，并將配置信息進行反饋。這樣就可以做到基站的安裝跟配置分開進行，并且還可以隨時對基站進行調(diào)控容量，監(jiān)視基站中設備的狀態(tài)等操作?；就ㄐ沤Y構示意圖如圖1.6所示:圖1.6 基站通信結構本文中通信基站運維綜合管理系統(tǒng)V1.0主要提供以下功能：功能特點：1，IT資源可視化，輕松讀懂各種IT數(shù)據(jù)2，業(yè)務拓撲視圖，直觀展現(xiàn)出業(yè)務與IT的關系3，IT資產(chǎn)管理與IT監(jiān)控管理、運維流程管理等無縫集成，實現(xiàn)對以虛擬化和云計算為核心支撐的IT體系綜合管控。4，完善的IT網(wǎng)絡運維管理體系，依托統(tǒng)一的服務支持平臺，形成自動化、流程化的服務支持。技術特點：1，運行環(huán)境安裝配置方便(.NetFramework,Asp.Net,IIS)2，技術成熟，主流技術，配套技術文檔完善，眾多開源或免費的文檔或項目可供參考3，擁有眾多新技術，方便構建企業(yè)級應用4，開發(fā)部署工具功能強大5，能與Windows平臺緊密結合，最大限度利用系統(tǒng)功能1.1.3 研究意義 隨著中興，華為等新興無線通信公司的崛起，無線通信行業(yè)的競爭越來越激烈，各大公司紛紛推出了新產(chǎn)品，軟硬件更新速度日益加快，而市場上也出現(xiàn)了基站類型新舊各異，功能各異的復雜情況，即使是同一站型，也會因為需求的變動而導致硬件不同，或者設備參數(shù)不同等問題。將原有硬件進行整合，升級改造，已經(jīng)成為了當前3G基站發(fā)展的一個主流趨勢。這樣不僅僅可以節(jié)約成本，復用原有的硬件設備，提高利用率，同時可以在更好的兼容基站的原有設備的基礎上，達到硬件微小改動，功能大大提升，基站大不一樣的特點。目前市場上的一些基站管理配置系統(tǒng)，由于需求已經(jīng)隨著市場的變化而發(fā)生了重大改變，從原有的固定不變，幾乎很少改動的硬件架構，變成當前這種需求隨著市場的變化而迅速變化的情況。以市場為導向的新需求，使得軟件層次的架構的變動勢在必行。原有的架構層次過于簡單，在新項目的開發(fā)中出現(xiàn)了架構兼容性不夠，代碼耦合度過強等問題，導致系統(tǒng)難以維護，升級，一旦有新需求變化，總會進行大幅修改，顯然已經(jīng)無法適應產(chǎn)品的不斷更新的新要求。如何設計出一個通用的基站管理系統(tǒng)，滿足需求經(jīng)常變動的特點，成為一個亟待解決的問題，也是本文的主要研究目的。1.2 國內(nèi)外研究動向 愛立信：愛立信的基站管理系統(tǒng)采用了CI/RI（Configuration Item/Resource Item）的架構。將基站資源抽象為一系列Resource Item，將一組相近的資源以聚集的形式構成Configuration Item，構建出一個邏輯上的Rbs進行配置。該管理系統(tǒng)使用了MVC，Java Bean，SAX等技術，提供了一個用戶友好型界面，通過一個通用平臺CPP與基站端進行通信?？蛻舳说交径说耐ㄐ攀褂昧薈OBRA的技術處理并發(fā)。目前愛立信在市場上的主流基站及新硬件設備如圖1.7所示5。圖1.7 愛立信主流基站及新硬件設備 華為6：提供了一個基于JAVA Web的網(wǎng)頁版基站軟件管理系統(tǒng)。該管理系統(tǒng)使用了J2EE架構，并且使用了Struts+Hibernate+Spring等比較流行的框架。圖1.8是部分華為在WCDMA市場上的主流基站。圖1.8 華為在WCDMA市場上的主流基站1.3 本文主要內(nèi)容 本文一共分為五章，系統(tǒng)的介紹了通信基站運維綜合管理系統(tǒng)V1.0的設計與實現(xiàn)，下面從分章節(jié)的角度詳細闡述本文將要論述的主要內(nèi)容： 第一章：首先介紹了本系統(tǒng)所需要的無線通信的背景知識，該系統(tǒng)在UTRAN系統(tǒng)中所處的位置以及該系統(tǒng)所擔當?shù)穆毮艿?，其次介紹了國內(nèi)外研究開發(fā)的動態(tài)，本章最后介紹了本文的主要內(nèi)容。 第二章：主要介紹了本系統(tǒng)的需求分析以及詳細架構設計。在需求分析中使用了ADMENS矩陣分析法。架構設計的時候先介紹系統(tǒng)的總體架構設計，再分層分別介紹每一層的設計。在介紹的時候不僅僅介紹了設計的思路，同時從設計模式的角度給出了實現(xiàn)策略。 第三章：根據(jù)上一章設計出的架構，分架構層次，依次詳細闡述了每一層的實現(xiàn)過程。實現(xiàn)過程主要以詳細的UML類圖以及時序圖為例進行闡述，同時將設計過程中用到的設計模式串聯(lián)起來。 第四章：描述了系統(tǒng)測試的主要方法，以及本系統(tǒng)測試的步驟，最后展示了部分測試用例，同時總結了測試結果。第五章：總結了本論文的主要工作，分析系統(tǒng)中一些值得改進的地方，并且提出了后續(xù)研究的一些展望。58第2章 基站管理配置軟件系統(tǒng)的需求分析以及設計第2章 通信基站運維綜合管理系統(tǒng)V1.0的需求分析以及設計本章詳細描述了基站管理系統(tǒng)的需求分析與架構設計。在需求分析中應用了ADMENS矩陣分析法進行分析，架構設計的時候體現(xiàn)了分層的思想，同時為了更好的局部結構，設計模式在本系統(tǒng)中得到了充分的應用。2.1 系統(tǒng)的需求分析通信基站運維綜合管理系統(tǒng)V1.0提供了一個基站管理配置的平臺，針對不同種類的基站進行配置，同時提供了對基站的配置進行修改，刪除，以及導入導出配置腳本等功能。在進行本文的需求分析的時候會借助ADMENS矩陣進行分析。ADMENS矩陣7（Architectural Design Method has been Extended to Method System，架構設計方法已經(jīng)擴展到方法體系），又稱為“需求層次-需求方面矩陣”。該矩陣分析法可以幫助架構師告別需求列表的陳舊方式，順利過渡到二維需求觀，借此避免遺漏需求、并進一步清理需求間關系和發(fā)現(xiàn)衍生需求。ADMENS二維矩陣進行需求分析的“四步法”主要由以下4個角度分析：需求結構化，分析約束影響，確定關鍵質(zhì)量以及確定關鍵功能。從“需求定義了直接還是間接目標”的角度，把需求劃分為3種類型：1. 功能需求：直接體現(xiàn)出各個需求的目標要求。2. 質(zhì)量屬性：由運行期質(zhì)量和開發(fā)期質(zhì)量組成。3. 約束需求：由業(yè)務環(huán)境因素，使用環(huán)境因素以及技術環(huán)境因素組成。從業(yè)務級需求，用戶級需求，開發(fā)級需求三個角度對本系統(tǒng)的需求進行具體分析，形成一個二維需求分析矩陣。總結成下表：表2.1 ADMENS矩陣廣義功能質(zhì)量約束業(yè)務級需求業(yè)務目標快、好、省技術性約束法規(guī)性約束技術趨勢競爭因素與競爭對手遺留系統(tǒng)集成標準性約束分批實施用戶級需求用戶需求運行期質(zhì)量用戶群特點用戶水平多國語言開發(fā)級需求行為需求開發(fā)期質(zhì)量開發(fā)團隊技術水平開發(fā)團隊磨合程度開發(fā)團隊分布情況開發(fā)團隊業(yè)務知識管理：保密要求管理：產(chǎn)品規(guī)劃安裝、維護2.1.1 業(yè)務級需求的分析本段主要依據(jù)：包含客戶或者出資者要達到的業(yè)務目標、所需要的預期投入資金、項目的工期進度要求，以及要符合哪些標準規(guī)范、對哪些遺留的系統(tǒng)進行整合改造等約束條件，對論文中闡述的系統(tǒng)進行業(yè)務級需求分析。下面詳細闡述本系統(tǒng)需要主要考慮的約束條件。 (1) 客戶的業(yè)務目標以及業(yè)務愿景。1. 軟件定位：基站管理軟件 2. 提供服務：提供一個通用的管理配置平臺，對同一家公司不同類型，不同硬件的基站進行配置。 (2) 客戶的業(yè)務質(zhì)量 1. 兼容新老基站。由于技術的改革，軟件必須兼容各種各樣的新老基站，在滿足新基站的配置要求的同時要做到向后兼容。特別是基站硬件的更新，各大無線通信公司目前都在做整合的研發(fā)，將老基站幾塊硬件板子的功能集成到一塊硬件上的創(chuàng)新研究，軟件變更需要跟硬件的變更同步化，滿足硬件變更所帶來的配置變更。 2. 易于變更配置。同一款基站，很有可能會配置不同的射頻單元，或者有扇區(qū)變動配置的需求，需要提供一個簡潔而又實用的向導來滿足配置的變更，同一種硬件配置也需要能夠方便的修改承載能力等，以達到資源的利用合理化。 (3) 技術標準 3GPP，以及各大廠商自己制定的標準。 (4) 對哪些遺留系統(tǒng)進行整合 基站零部件種類繁多，各種型號的基站之間硬件配置有較大區(qū)別，需要一個擴展性很強的系統(tǒng)來代替原有系統(tǒng)，以便將來產(chǎn)品進一步更新?lián)Q代。2.1.2 用戶級需求的分析用戶及需求的分析主要從如下幾個角度入手：用戶需要使用系統(tǒng)來完成哪些工作，對質(zhì)量有哪些要求，用戶群及所處的使用環(huán)境方面有哪些要求等條件來進行用戶級需求分析。下面結合本系統(tǒng)進行分析： （1） 用戶使用系統(tǒng)完成的輔助工作 該系統(tǒng)主要的用戶人員是基站配置人員，他們使用該系統(tǒng)進行基站的配置，修改，刪除等操作。配置向導里面的配置項有一些是有跟具體硬件相關的默認值的，還有一些必須要用戶來配置，這些配置向導按照基站的配置流程分多個頁面進行。該基站管理軟件主要提供四個配置向導界面：1. 機箱/機柜配置向導： 這部分的配置的硬件設備，除了基帶信號處理板的配置，還有一些硬件板，通常在交付客戶之前，在工廠就有一些燒制或者錄入的默認配置，插入機箱機柜中，所以需要在這里一并配置。在這個配置向導里面需要配置的主要有：選擇Rbs的類型，配置默認的IP地址，接口板等硬件設備。2. 基站站點配置向導 主要功能是建立扇區(qū)，配置小區(qū)，天線系統(tǒng)的相關硬件，電纜相關數(shù)據(jù)，該部分需要配置的硬件組合相對比較靈活，可以依照基站的承載能力等條件，自由組合配置。3. 修改配置向導 該配置向導比較特別，該功能的實現(xiàn)需要借助XML+SAX來實現(xiàn)，所以該配置向導的輸入僅為XML修改配置文件。該向導主要配置頁面僅僅由一個文件輸入頁面以及需要修改的目錄結果組成。4. 導入導出，刪除向導 這幾個功能也都是通過XML+SAX實現(xiàn)，所以該配置向導同上，輸入/輸出僅僅為XML文件。（2） 質(zhì)量要求1. 操作方便，界面友好。2. 系統(tǒng)具有很強的健壯性，盡量避免系統(tǒng)崩潰。3. 能夠滿足不同的配置的情況下，仍具有較強的可靠性。（3） 客戶需求約束 配站工程師水平參差不齊，提供一個用戶友好型，簡潔的配置界面，需要易于操作。2.1.3 開發(fā)級需求的分析本段主要依據(jù)：開發(fā)人員具體需要實現(xiàn)什么產(chǎn)品，開發(fā)維護期間對質(zhì)量有哪些考慮，開發(fā)團隊有無影響架構的情況等因素來進行需求分析。下面僅考慮本系統(tǒng)開發(fā)中需要用到的約束條件： （1） 開發(fā)人員需要實現(xiàn)目標 一個用戶友好型的通信基站運維綜合管理系統(tǒng)V1.0。需要提供如下基本服務： 1. 機柜機箱配置：需要實現(xiàn)機箱機柜的配置，以及出廠時安裝的其他硬件板的所有配置。機箱機柜通常會提供一系列的插槽，相關的硬件在出廠的時候分別安裝在具體的插槽中，一并交付，所以這些硬件板需要跟機柜機箱配置一同進行配置。 2. 基站配置：主要負責射頻單元硬件的配置，輔助單元（比如風扇、電源之類）的配置，以及天線系統(tǒng)相關設備的配置，這部分的硬件大多具有可以頻繁更換的特性，所以這部分代碼結構需要盡量松散，耦合度越低越好。 3. 導出/刪除功能：導出功能可以導出當前Rbs的配置XML文件，可以讓我們在測試環(huán)境中創(chuàng)建相同的用戶配置，也可以給其他站點進行相同的配置。刪除功能可以刪除當前Rbs中所有不重要的配置，重新配站的情況下可以使用。本系統(tǒng)使用SAX的技術來解析XML文件，所以在這里需要提供DTD文件規(guī)范XML文件的格式。 4. 修改功能：可以提供給基站操作人員在不停止Rbs的情況下，修改基站的配置的功能。主要有射頻單元的修改，天線的修改，扇區(qū)的增加、刪除，小區(qū)的增加、刪除等等功能。 （2） 開發(fā)期間的質(zhì)量約束 1. 以測試驅動的原則進行開發(fā)，盡量做到步步可測。 2. 代碼實現(xiàn)的時候盡量多用設計模式的原則，降低代碼的耦合度，提高可擴展性。 綜上所述，總結得到的ADMENS矩陣如下表所示：表2.2 ADMENS矩陣（需求層次-需求方面矩陣）功能質(zhì)量約束業(yè)務級需求業(yè)務目標及業(yè)務愿景l(fā) 軟件定位：基站管理軟件l 提供服務：對各種類型，各種硬件提供一個通用性的配站軟件商業(yè)質(zhì)量l 兼容新老基站配置l 容錯率高商業(yè)約束l 基站零部件種類繁多l(xiāng) 各種型號的基站，硬件之間有較大區(qū)別l 需要較強的可擴展可擴展性，以便將來產(chǎn)品更新?lián)Q代用戶級需求潛在用戶l 配站工程師運行期質(zhì)量l 操作簡單，易于上手l 多用性用戶約束l 工程師水平層次不齊，提供一些必要提示l 防御性編程，檢測未知的配置錯誤開發(fā)級需求開發(fā)期質(zhì)量l 可擴展性l 步步可測開發(fā)方約束l 只有一人l 時間短工程量大2.2 基站管理軟件系統(tǒng)的架構設計 本節(jié)主要是從整體上對本通信基站運維綜合管理系統(tǒng)V1.0的設計進行詳細闡述。本節(jié)主要分兩個層次來闡述，先從系統(tǒng)的邏輯架構，功能模塊以及魯棒性設計三個角度來闡述該基站管理軟件系統(tǒng)的設計，然后依據(jù)本系統(tǒng)的架構層次來具體闡述每一層的設計思路以及實現(xiàn)策略。2.2.1 系統(tǒng)總體概要設計本小節(jié)僅僅是對系統(tǒng)總體架構概要設計的介紹，不對具體細節(jié)的設計與實現(xiàn)做分析。本節(jié)從系統(tǒng)的邏輯架構，功能模塊以及魯棒性設計三個角度來闡述該基站管理軟件系統(tǒng)的概要設計。 系統(tǒng)的邏輯架構基站管理軟件系統(tǒng)的邏輯架構圖見圖2.1。該系統(tǒng)的設計思路以企業(yè)應用架構模式中流行的三層架構為基礎，根據(jù)本系統(tǒng)的需求分析而衍生出來的五層架構，每一層都依托在其下層之上來構建，上層使用下層定義的各種接口，而下層對上層如何調(diào)用一無所知。另外，每一層對自己的上層隱藏其實現(xiàn)細節(jié)。各層之間盡量做到相對透明89。在表現(xiàn)層中使用了當前最流行的MVC框架模式進行設計，在邏輯實現(xiàn)層中，參照企業(yè)級應用架構中的領域邏輯層的設計思路，上層參照服務層構建，將本系統(tǒng)所提供的服務獨立出一層，成為功能模塊層，對表現(xiàn)層提供服務，下層邏輯實現(xiàn)層使用領域模式，使用一系列對象來承擔相關邏輯，數(shù)據(jù)層分為2層，上層物理數(shù)據(jù)層是對物理硬件的一一對應，并且與MO進行聚集處理，下層邏輯數(shù)據(jù)層則是對應所在公司的Manage Object架構，使用一些簡單的POJO來構建數(shù)據(jù)庫，同時可以使用這些數(shù)據(jù)類承載本系統(tǒng)的配置信息，與其他子系統(tǒng)進行數(shù)據(jù)通信。 圖2.1 基站軟件系統(tǒng)的邏輯架構多層次的架構體系，使得系統(tǒng)的靈活性極大增強，每層僅僅對其上下層負責，降低了系統(tǒng)的耦合度，可以將一個新硬件的需求給軟件代碼帶來的影響在最小范圍內(nèi)擴散，很好的滿足頻繁增加新特性的需求。同時在每層之間按模塊劃分的策略和設計模式的大量應用，優(yōu)化了系統(tǒng)的局部細節(jié)，極大降低了各個子模塊之間的耦合度10。 表現(xiàn)層的設計概要：該層采用當今世界主流的GUI設計模式：MVC（Model-View-Controller）模式，即模型-視圖-控制器模式，MVC模式可以按照模型、繪圖表達方式和行繪圖為等角色把一個應用系統(tǒng)的各個部分解耦分割開來。使用該模式，可以將本系統(tǒng)中的圖形界面的繪制跟圖形界面的控制分開，很好的滿足了設計目標11。同時由于該基站管理配置系統(tǒng)的配置向導頁面中有許多共同的插件，可以將將視圖端以及控制器端共有的部分抽象到他們的父類，在父類中實現(xiàn)對頁面的控制等共有的邏輯，這樣的設計思想體現(xiàn)出了軟件設計模式中的里氏代換原則以及依賴倒轉原則。子類繼承時通過裝飾模式等設計方法來實現(xiàn)各自頁面不同的視圖，加減頁面12都不會對原來的架構有影響，滿足開閉原則，對應的視圖以及控制器僅僅通過模型端進行交互，滿足迪米特法則1314。 邏輯控制層部是整個系統(tǒng)中對配置行為進行控制的地方，同時也負責Rbs對象的創(chuàng)建等工作，該層分兩層實現(xiàn)： 功能模塊層設計概要：該層主要采用建造模式來實現(xiàn)，以功能模塊層的需求為依據(jù)分別建造，提供各種各樣的產(chǎn)品。對應于該管理軟件的功能，給出其相對應的類來提供目標功能模塊，組裝構建等細節(jié)等實現(xiàn)部分則對上層透明，該層并不負責細節(jié)邏輯的實現(xiàn)，而是一些實現(xiàn)功能的組合，具體的實現(xiàn)通過代理模式的思想交由下層負責。基于此，該層主要是一些功能等創(chuàng)建組合的控制的接口，通過這些接口來調(diào)用下層的邏輯實現(xiàn)層，并委托下層來實現(xiàn)需要的邏輯。每一個功能對應一個建造類，通過建造模式，可以做到復用邏輯實現(xiàn)層的零件產(chǎn)品，同時各功能模塊之間相對保持透明，滿足迪米特法則。 邏輯實現(xiàn)層設計概要：該層建立一個全部由對象組成的領域層，來對目標對象的業(yè)務建模，其中每一個對象僅僅負責一個單一的功能的實現(xiàn)。由于業(yè)務的具體行為是經(jīng)常變化的，因此易于修改和測試對邏輯實現(xiàn)層來說十分重要。該層主要采用享元模式來進行構建，內(nèi)蘊對象主要來存儲跟該邏輯對象配置相關的一些常量數(shù)據(jù)，外蘊對象主要來存儲該邏輯對象需要配置的數(shù)據(jù)對象。該層的主要功能是：向下調(diào)用下層數(shù)據(jù)層中的數(shù)據(jù)，并對數(shù)據(jù)直接進行讀寫等操作，實現(xiàn)一些獨立的，單一的，簡單化功能，向上接受上一層功能模塊層的委托調(diào)用，實現(xiàn)功能模塊層的需求15?；竟芾碥浖到y(tǒng)的數(shù)據(jù)操作部分主要集中在這一層，產(chǎn)品中有一系列的數(shù)據(jù)操作方法，對數(shù)據(jù)層的數(shù)據(jù)類進行讀寫操作。 數(shù)據(jù)層部分：該層分為2層，上層為物理數(shù)據(jù)層，與具體基站的物理硬件一一對應，下層為POJO層，作為與整個UTRAN系統(tǒng)的接口，將系統(tǒng)系統(tǒng)高層定義的MO與本軟件系統(tǒng)的數(shù)據(jù)進行一個一一映射。通常為了滿足硬件結構的變化，系統(tǒng)定義出的MO也會相應隨之調(diào)整，結構并不穩(wěn)定。如果數(shù)據(jù)層采用單一的層次，那么由于不停變化的需求，會導致數(shù)據(jù)層的經(jīng)常改動，影響架構的穩(wěn)定性16。 物理數(shù)據(jù)層設計概要：該層采用合成/聚集原則調(diào)用POJO層的數(shù)據(jù)對象，創(chuàng)建構建成不同型號的物理硬件的一系列對象，與真正的物理硬件一一對應17。 POJO層設計概要：POJO，即簡單的Java對象，僅包含一些屬性以及一些get，set方法，并不包含業(yè)務方法。該層主要作用就是提供一些最基本的數(shù)據(jù)供上層使用，對系統(tǒng)定義的MO數(shù)據(jù)進行一一映射，轉化成本系統(tǒng)所能夠使用的數(shù)據(jù)。 產(chǎn)品的功能模塊結構 產(chǎn)品的功能模塊結構見圖2.2。用戶需要先選定Rbs基站的型號，該系統(tǒng)則會根據(jù)用戶的選擇生成相應的基站配置界面，接下來就可以進行機箱機柜cabinet、站點site、扇區(qū)、天線系統(tǒng)等基站主要硬件的配置。該管理軟件同時提供了修改modify/導出export/刪除delete等功能，修改modify功能可以在不重啟基站的情況下，調(diào)整基站的扇區(qū)、載波配置等設備的負載量等配置信息；導出export功能則可以將當前基站的配置以XML的格式一次導出，以便下次配站使用；刪除Delete功能則是可以將基站當前配置刪除，方便用戶重新配站。圖2.2 產(chǎn)品的功能模塊結構圖 系統(tǒng)概要設計的魯棒性分析 系統(tǒng)概要設計的魯棒圖見圖2.3。 從圖中可以看到，當工程師選定了Rbs基站的類型以后，會有一個相對應的工廠方法，生成該Rbs基站相對應的實例，該實例以創(chuàng)建最大化的方式，初始化該基站的所有功能服務，并且保存該類型的基站所特有的數(shù)據(jù)邏輯。該基站的實例對象采用單例模式，在整個配置過程中只有這一個實例對象，方便記錄基站的配置信息以及對基站配置信息的修改信息。接下來的各種功能實現(xiàn)部分主要是對Rbs基站的配置數(shù)據(jù)進行操作，所以可以直接對這個單例對象進行操作。各功能模塊之間都做了很好的隔離，控制部分相對獨立，每個功能對于其他功能沒有影響，一個地方出錯了并不影響其他功能的使用，有很好的魯棒性。圖2.3 系統(tǒng)概要設計的魯棒圖2.2.2 POJO層的設計 MO（Manage Object）策略通常MO由高層系統(tǒng)工程師來設計與實現(xiàn)，將Rbs中的資源邏輯抽象為一系列對象，再由面向對象的軟件語言如Java，C+，在各自子系統(tǒng)實現(xiàn)細節(jié)，再由MO之間屬性的交互，來實現(xiàn)不同子系統(tǒng)間數(shù)據(jù)的交互。MO從高層體現(xiàn)出一致性，即各個子系統(tǒng)所使用的MO，雖然分屬各自的子系統(tǒng)，但是必須完全一樣。一般Rbs基站的軟件架構采用數(shù)據(jù)驅動的方式，各個子系統(tǒng)相對獨立，僅僅依賴數(shù)據(jù)的傳遞進行通信。MO就是數(shù)據(jù)交互的關鍵，MO承載了各自子系統(tǒng)的數(shù)據(jù)信息。一個MO中通常會包含兩類參數(shù)： 屬性，Attributes：跟MO抽象的資源相關的參數(shù)變量，這些資源可以在配置的時候給他們賦值，資源的狀態(tài)也可以通過讀取這些值來獲得。 行為，Actions：表示所能對一個MO采用的行動，比如加鎖，刪除等。本文所要實現(xiàn)的通信基站運維綜合管理系統(tǒng)V1.0，實際上就是采用一系列的Java類來對應MO，將配置信息存到MO中，通過配置這些MO的attributes和actions來實現(xiàn)對基站的配置，最后講收集到的所有配置信息，發(fā)送到中央處理單元中。 圖2.4是一個采用了MO模型的Rbs基站的示意圖：圖2.4 Rbs基站的MOM模型上圖中矩形代表Rbs節(jié)點整體，正面是Rbs從系統(tǒng)的角度所能看到的資源，側面則是對Rbs資源的抽象：MOM（MO Model）。從圖上可以看出：MO模型即是對Rbs系統(tǒng)的角度所能看到的資源的另一種表示所構建成的模型：抽象成為一系列可以管理的對象MO，從一系列對象的角度來看Rbs的資源。表2.3的MO取自愛立信Rbs基站，6601型號遠程基站，slot的信息表。表2.3 Slot信息表Possible parentsubrackPossible childrenAuxPlugInUnitBbifBoardPlugInUnitActionsupdateConfiguration()AttributesactiveSwAllocationproductDatareservedBySlotIdslotNumberslotState Slot：是對機框中插槽資源的一個抽象。從該表中可以看出：slot的父親節(jié)點只有一個，機框subrack；可能的孩子節(jié)點有3個，可插入插槽單元PlugInUnit，比如基帶板，射頻板，信號過濾板等；遠程單元AuxPlugInUnit，比如傾角調(diào)整器RET，塔放TMA等；一種基帶板與射頻單元的交互接口BbifBoard。該MO的action僅有一個：updateConfiguration。表示如果該基站是自動配置，則該action會觸發(fā)該插槽下硬件單元的自動配置行為。6個Attributes分別表示：activeSwAllocation表示此刻該插槽是否有PlugInUnit在使用，如果沒有PlugInUnit在次插槽被配置使用，則該屬性的值為空。productData屬性描述當前插入單元的信息，該屬性一旦賦值，則無論其插入硬件板是否工作，該值都不會變，該屬性的值只有在slot換新硬件板的時候才會改變。reservedBy該屬性以一個列表形式存在，是儲備這個MO的所有MO的一個列表。SlotId，該屬性的值是用來組成RDN的。slotNumber該屬性的值從左往右開始數(shù)起，從1開始，用來表示插槽位置的。slotState屬性用來表明該插槽的狀態(tài)。該MO的是在其父親MO的創(chuàng)建的時候創(chuàng)建的，并且不能被刪除。該MO插槽的數(shù)目是在其父親節(jié)點subrack中定義的。 MO的查找：RDN與LDN RDN：Relative Distinguished Name，相對標識名。RDN的命名跟該MO的父親節(jié)點相關。這個屬性的值在他被建立的時候就定義好了，并且不能改變。 LDN：Local Distinguished Name，本地專有名稱。由該Rbs節(jié)點中一系列的RDN所形成的一個獨一無二的名字。 RDN在查找父子節(jié)點的MO時候使用，LDN在全局查找MO的使用。 圖2.5是RNC中的一個MO的結構，由下可以看出RDN跟LDN如何命名，以及LDN是如何由RDN所形成的：圖2.5 一個使用RND/LDN的MO結構由上圖可以看出RncFunction這個MO的RDN=RncFunctionId=0，由于RncFunction本身就是根節(jié)點，所以LDN等于RDN。UtranCell這個MO的RDN=UtranCellId=100，LDN等于該MO的RDN加上這個MO所有父節(jié)點的RDN，所以UtranCell的LDN=RncFunctionId=0，UtranCellId=100，同理，Rach這個MO的RDN=RachId=0，LDN=RncFunctionId=0，UtranCellId=100，RachId=0。表中的MO的RDN命名規(guī)則：從機框最左邊的插槽開始，第一個插槽slot為：slot=1。因此該MO的RDN=SlotId=1。 MO的映射機制 MO的映射機制采用POJO模式策略。從高層系統(tǒng)規(guī)定定義的MO到該軟件配置管理系統(tǒng)的數(shù)據(jù)庫所采用的映射技術由POJO模式實現(xiàn)。POJO：Plain Old Java Object，簡單Java對象。POJO是一個簡單的普通的Java對象，它不包含業(yè)務邏輯或者持久化邏輯等，沒有從任何類繼承，不擔當任何特殊的角色，也沒有實現(xiàn)任何接口，更沒有被其他框架侵入的Java對象。每一個MO由一個POJO來負責實現(xiàn)，由一個具體的Java類來代表一個MO，Java中的字段設置成私有的，分別表示MO中的attribute跟action。一系列的get/set方法來負責數(shù)據(jù)的讀寫。2.2.3 物理數(shù)據(jù)層的設計 POJO層對應的數(shù)據(jù)庫數(shù)據(jù)，MO數(shù)據(jù)，僅僅只是系統(tǒng)高層對Rbs資源的一個邏輯抽象，并不完全對應具體硬件。整個UTRAN系統(tǒng)中，各個子系統(tǒng)之間的通信，是需要MO來傳遞數(shù)據(jù)的，而我們對Rbs的配置，實際上僅僅是對具體的一個類型的Rbs的具體硬件的配置，這兩者之間有一些區(qū)別。所以需要有一層數(shù)據(jù)層，來實現(xiàn)邏輯數(shù)據(jù)MO跟具體硬件的參數(shù)配置的映射關系。以下將從MO樹的建立，物理數(shù)據(jù)的建立和物理數(shù)據(jù)的實現(xiàn)策略三個方面具體闡述該層主要的設計步驟。 MO樹的建立由于在POJO層使用了POJO數(shù)據(jù)，所以僅僅只有get/set方法，并沒有任何關系，也沒有任何邏輯，需要在這一層給MO數(shù)據(jù)建立關系。這樣不僅可以實現(xiàn)各個MO之間的的先后順序，父子關系，依賴關系等邏輯，同時還可以使得邏輯控制層對MO數(shù)據(jù)的管理、使用更加方便。圖2.6是系統(tǒng)高層定義的MO結構樹的一部分：圖2.6 MO結構樹以系統(tǒng)高層定義的MO樹為基礎，本基站管理配置系統(tǒng)需要構建的樹的示意圖如圖2.7所示：圖2.7 MO結構示意圖所有的MO都有一個共同的根節(jié)點Root Node，由上圖信息可知，樹的根節(jié)點為ManagedElement這個對象，在這之下依次掛著各個MO。建立MO樹的規(guī)則是根據(jù)系統(tǒng)對MO結構圖的定義以及MO定義的信息表中可能的父類，可能的子類的信息來建立的：在本基站管理軟件系統(tǒng)的Java類中，用3個類來實現(xiàn)MO樹的創(chuàng)建，如圖2.8所示：圖2.8 MO樹的代碼結構Node類提供建立樹的一些最基本的方法，如getDepth、getChild、getParent方法等。MONode類繼承了Node類，在此基礎上擴展了一些方法，提供關于MO屬性的一些操作，比如lockable，deletable方法。MOProxyNode類同樣繼承自Node類，這個類跟MoNode不同，擴展的方法主要是用來獲取這個類，以及獲取相關的MO。 物理數(shù)據(jù)的建立這一層的主要目的就是：建立一個對應具體類型的Rbs，具體硬件的配置的數(shù)據(jù)層。這一層主要是將抽象管理對象MO的數(shù)據(jù)與具體硬件配置的數(shù)據(jù)聯(lián)系起來，基站軟件管理配置系統(tǒng)從用戶的角度來看，僅僅是對具體硬件進行配置，而并不是對抽象的MO的配置，所以需要一層數(shù)據(jù)層，來進行抽象數(shù)據(jù)與具體數(shù)據(jù)的轉換。下面以射頻單元硬件為例，分析本通信基站運維綜合管理系統(tǒng)V1.0是如何將抽象管理對象MO的數(shù)據(jù)與具體硬件配置的數(shù)據(jù)進行轉換的。圖2.9是愛立信一個遠程射頻單元的硬件實例圖：圖2.9 愛立信遠程射頻單元的硬件實例 從圖中可以看出，這個遠程射頻單元已經(jīng)進行了很好的封裝，其實內(nèi)部集成了上行信號處理板，下行信號處理板，空口等硬件，該硬件的外部則有連接基帶信號處理板的接口以及連接天線的接口等，這些硬件的具體分配資源不需要本系統(tǒng)進行深入配置，在下層子系統(tǒng)會有針對細節(jié)的配置，但是遠程射頻單元的型號，上下行信號處理板、空口等硬件的數(shù)目，外部接口的連接信息，是否發(fā)射分級，是否串聯(lián)等信息，這些配置信息都是需要在配置這個遠程射頻單元的時候同時配置的。而在系統(tǒng)高層定義的MO里面并沒有一個具體的MO與該硬件對應，統(tǒng)一歸類為AuxPlugInUnit這個MO，僅僅通過auType這個屬性來區(qū)分具體的類型。MO的定義高度抽象化，不會涉及細節(jié)，或者具體硬件。AuxPlugInUnit信息如表2.4所示：表2.4 AuxPlugInUnit信息表ActionsreadRepairDelivNote()reconfigureProgramPrepare()restartAuxUnit()AttributesadministrativeStatealramStatusauTypeAuxPlugInUnitIdpiuTypeproductNumberreservedByserialNumberuniqueHwIdunitType由上表可以看出，這個MO跟實際硬件之間并不完全匹配，比如與外部其他硬件的接口連線部分，沒有任何屬性可以用來保存與基帶信號處理板的連接配置或者與天線單元的連接配置，而保存這個連接配置信息的屬性卻屬于另一個MO，DigitalCable中。根據(jù)具體產(chǎn)品信息，該硬件實際使用到的所有MO如表2.5所示：表2.5 遠程射頻單元硬件使用的MO實際硬件抽象MO遠程射頻單元DigitalCableAuxPlugInUnitSectorAntennaAntennaBranchAntFeederCable 于是我們可以使用合成/聚合復用原則，建立一個Java類，其中包含了屬于這個硬件的所有MO的一個聚集，這樣可以通過配置這個類來配置這個硬件，同時間接配置了相關的MO。 該層具有十分重要的意義，是將抽象管理對象MO與具體硬件實例緊密聯(lián)系起來的橋梁。基站軟件管理配置系統(tǒng)僅僅是對具體硬件進行配置，而并不是對抽象的MO的配置。在這一層可以進行數(shù)據(jù)的轉換，轉換成UTRAN中通用的MO數(shù)據(jù)，這樣就可以供其他子系統(tǒng)使用。這一層起到承上啟下的作用。 物理數(shù)據(jù)的實現(xiàn)策略 本層物理數(shù)據(jù)的實現(xiàn)策略主要采用合成/聚合復用原則以及合成模式這兩個策略。下面分別具體闡述這兩種策略以及在本系統(tǒng)中采用的原因：合成/聚合復用原則：又叫做合成復用原則（CRP），指在一個新的對象里面使用一些已有的對象，使之成為新對象的一部分；新對象通過向這些對象的委派達到復用已有功能的目的。使用合成/聚合復用原則的原因有：1 新對象存取成分對象的唯一方法是通過成分對象的接口。本層的數(shù)據(jù)給下層MO數(shù)據(jù)層賦值只會調(diào)用POJO類中的set方法。2 這種復用支持包裝。3 這種復用所需的依賴較少。不同于繼承的實現(xiàn)，這樣實現(xiàn)的耦合度極低，有助于數(shù)據(jù)的靈活組合，利于架構的解耦。一旦有新硬件或者硬件的改動，改變起來比較方便。4 每一個新類可以將重點集中在一個任務上。本層物理數(shù)據(jù)層每一個類的主要任務就是將MO層的POJO類進行集成，以匹配真實物理硬件。 合成模式：屬于對象的結構模式，有時候又叫做“部分-整體”模式。合成模式將對象組織到樹結構中，可以用來描述整體與部分的關系。這樣設計使得我們可以找到一種無需一對多的關系即可獲得一對多的行為的替代方式。使用合成模式的主要原因有：1 有一些物理硬件可以做進一步的集成，集成化是未來無線基站硬件的趨勢，在該層就進行必要的數(shù)據(jù)集成，可以很好的滿足將來的需求變化。2 在一些集成了的硬件板的處理上，上層邏輯層不直接調(diào)用不直接配置的數(shù)據(jù)類，而是通過調(diào)用實際配置的數(shù)據(jù)類來進行委派。這樣可以增加代碼的復用性。3 在物理數(shù)據(jù)層就對數(shù)據(jù)進行必要的集成，當對集成硬件進行數(shù)據(jù)配置的時候，可以通過父類進行數(shù)據(jù)的遍歷，而不并每一次都去遍歷所有的子類，這樣可以減少數(shù)據(jù)配置中的錯誤。 合成模式的UML結構圖18如圖2.10所示：圖2.10 合成模式 該圖是合成模式中樹結構的一個靜態(tài)結構。最上方出現(xiàn)的父類節(jié)點，左下方是一個樹葉節(jié)點，右下方是一個樹枝節(jié)點，可以含有其他節(jié)點，如果沒有其他節(jié)點，則也退化成樹葉節(jié)點。由于本層數(shù)據(jù)層的設計只是聚集下層POJO層中的MO數(shù)據(jù)，使之與實際物理硬件對應，所以本系統(tǒng)只需要使用二層樹結構的合成模式即可，即父節(jié)點作為物理數(shù)據(jù)層中的數(shù)據(jù)類使用，子節(jié)點取自下層POJO數(shù)據(jù)層。本層的客戶端是上層的邏輯控制層19。在本層物理數(shù)據(jù)層架構的搭建的時候，使用合成模式的思想，但是并不完全依照合成模式來構建，因為本系統(tǒng)設計的一個主要目的就是給原來的系統(tǒng)解耦合，盡量做到低耦合，而且這兩層數(shù)據(jù)之間并沒有強耦合關系，所以不需要繼承的方式來實現(xiàn)，而是將下層數(shù)據(jù)層中的類以合成/聚集的方式使用。以上文中出現(xiàn)的遠程射頻單元為例，依據(jù)合成模式的思想，設計如圖2.11所示：圖2.11 遠程射頻單元的聚集模式 在該圖中，處于父節(jié)點位置的就是本層需要設計的數(shù)據(jù)類，遠程射頻單元類，5個子節(jié)點由表2.5中可以得到。跟合成模式不同，在這里并不使用繼承，而是使用聚集來實現(xiàn)，遠程射頻單元以聚集的方式將這五個POJO類聚集到父類中，使之成為一個整體。這樣同樣可以做到在向上層提供數(shù)據(jù)服務的時候，以一個整體的行為，以一對一的關系來進行交互，而不是傳統(tǒng)一對多的方式。這樣在邏輯控制層中，可以通過僅僅調(diào)用這一個數(shù)據(jù)類，就可以達到同時調(diào)用這5個MO類的數(shù)據(jù)的功能。 2.2.4 邏輯實現(xiàn)層的設計本節(jié)主要介紹了該層的實現(xiàn)策略，同時結合本層的主要功能需求，詳細分析了采用享元模式的原因。本層只負責簡單單一的行為邏輯，即每一個類只負責一種邏輯，邏輯的組合則交給上層2021。 邏輯實現(xiàn)層的實現(xiàn)策略：享元模式。享元模式是對象的結構模式。享元模式以共享的方式高效的支持大量的細粒度對象。享元對象區(qū)分內(nèi)蘊狀態(tài)和外蘊狀態(tài)。一個內(nèi)蘊狀態(tài)是存儲在享元對象內(nèi)部的，并且是不會隨著環(huán)境改變而有所不同的。因此一個享元可以具有內(nèi)蘊狀態(tài)并且內(nèi)蘊狀態(tài)可以共享。一個外蘊狀態(tài)是隨環(huán)境改變而改變的、不可以共享的狀態(tài)。享元對象的外蘊狀態(tài)必須由客戶端保存，并在享元對象被創(chuàng)建之后，在需要使用的時候再傳入到享元對象內(nèi)部。外蘊狀態(tài)不可以影響享元對象的內(nèi)蘊狀態(tài)，他們之間是相互獨立的。 圖2.12是享元模式的結構示意圖：圖2.12 享元模式 在上圖中，享原工廠負責創(chuàng)建和管理享元對象。這個角色必須保證享元對象可以被系統(tǒng)適當?shù)毓蚕?。當一個對象調(diào)用一個享元對象的時候，享元工廠會檢查系統(tǒng)中是否已經(jīng)有了一個符合要求的享元對象。如果已經(jīng)有了，享元工廠角色就應當提供這個已有的享元對象，如果系統(tǒng)中沒有一個適當?shù)南碓獙ο蟮脑?，享元工廠角色就應當創(chuàng)建一個合適的享元對象。抽象享元角色是所有享元類的超類，為這些類定義出需要實現(xiàn)的公共接口，外蘊狀