基于ＡＣＥ的網元文檔服務的設計與實現

摘 要：以ACE為底層平臺，以3G無線網管系統為應用背景，設計并實現了網元文檔服務。網元文檔采用XML格式存儲，以動態更新方式生成，以FTP方式和中轉方案上傳，滿足了用戶需求；提供了TMN標準中各模塊對網元信息遺漏的解決方案。

關鍵詞：網元文檔； 后管理模塊； 自適配通信環境； 第三代移動通信系統

中圖分類號：TP393.07文獻標志碼：A

文章編號：1001—3695(2007)03—0206—03

隨著第三代移動通信系統(3G)技術的日益成熟和商務化，3G網絡管理系統也成為移動通信網絡建設的焦點。3G網絡管理主要集中在對網絡環境的管理和對網絡設備的管理上[1，2]。這些網絡設備作為網絡管理系統中的網元 (NE) ，成為系統管理的基本對象。

對網元的管理重點在于對通信網絡中網元的配置、性能、軟件、告警、安全等信息進行監測和控制[3]。然而這些模塊各有側重，還不能提供足夠的網元信息。隨著網管規模的擴大，許多以前不需要網管管理的信息也迫切需要網管的參與。大量被管設備的生產信息、維修信息，對于實現被管設備的遠程維修、維護具有重要的參考價值。而這些信息是通用網管所不能提供的，于是網元文檔的需求應運而生。網元文檔描述了設備的基本信息、連接信息、模塊信息、配置信息、對端信息、版本信息、機框信息、機槽信息、單板信息等。其中單板信息包括了單板的生產信息、維修信息等。網元文檔服務就是要把網管系統所管理網元的這些信息呈現給用戶。文中以ACE為底層平臺，設計并實現了3G無線網管系統的網元文檔服務。網元文檔服務的提出與設計同時也豐富了TMN（Telecommunications Management Network）的知識框架，完善了其理論體系。

ACE（Adapter Communication Environment，自適配通信環境）是可以自由使用、開放源碼的面向對象構架。ACE提供了一組豐富的可復用C++包裝外觀和構架組件，可跨越多種平臺完成通用的通信軟件任務[4]。網元文檔服務使用了ACE提供的通信組件和線程控制組件，保證了開發的效率和質量。

1 網元文檔服務的設計與實現

1.1 網元文檔服務功能需求

網元文檔功能需求有如下特點：①主要功能。將網管系統所管理的所有網元文檔收集到用戶端。②內容的可擴展性。網元文檔內容沒有統一的業界標準，因此其屬性內容應該允許擴充。③任務量大。用戶往往要成批操作，經常對數百個網元請求生成網元文檔。在完成上述要求的同時，要求系統滿足效率性和可靠性。

1.2 網元文檔服務的設計思想

如圖1所示，GUI接收用戶請求，并顯示返回的結果信息。

圖1 網元文檔服務框架

網元文檔服務運行在服務器上，它接收GUI發送來獲取網元文檔的請求，并將該請求轉換成MML（Man Machine Language）命令格式，通過適配層下發到BAM（Back Administrator Moudle）；另外接收BAM反饋回來的報文，包括成功/失敗信息、任務進度信息等，并將處理后的信息發送到用戶界面。服務器與用戶界面及服務器內部服務與適配層的交互通過CORBA[5]接口實現。

適配層用于屏蔽不同網元之間報文格式之間的差異。適配層的存在使得呈現給服務器內部服務的是統一的報文格式。常用的通信協議有MML命令方式、Bin方式、BinMML方式等。由于不同的通信協議并不影響主題的開展，在接下來的討論中，將以MML命令報文作為適配層與BAM及BAM與網元之間的通信協議。

BAM接收適配層的命令，進行相應解析；發送命令到各個主控板、機框、機架、單板，并匯總返回的結果，執行生成網元文檔的任務，同時將進度上報。

1.3 網元文檔的生成

1.3.1 存儲方案

網元文檔有兩種存儲方案可供選擇，即數據庫格式存儲和文件流的格式存儲。數據庫格式便于檢索，但要求表結構固定，不便于擴展；文件流恰恰相反，不便于檢索，但存儲內容更加靈活。基于對網元文檔屬性內容可擴展性的考慮，文件流更為適合。鑒于XML作為文件存儲格式所表現出來的優越性，包括通用性、擴展容易、可讀性好。網元文檔遵守標準的XML文件格式。其存儲格式（部分內容）如下：

1.3.2 生成方案

網元文檔生成功能最初的設計方案是：每次用戶要求生成網元文檔時，就查詢網元文檔的每一個屬性，并最后組成一份完整的網元文檔并呈現給用戶。然而一條MML命令通常對應一條屬性信息，即對于包含數千條屬性的網元文檔來說，就需要下發數千條MML命令，才能得到完整的文檔信息。而幾千條MML命令報文的下發和解析，所需時間太長。實驗數據表明，對于一個包含350塊單板的RAC網元，其生成文檔的時間達到7 min。而商用局點中，單個網元安裝1 000塊以上單板是比較常見的。按照實驗數據統計的時間進行估算，這樣的站點生成文檔將達到20 min，顯然是用戶所不能忍受的。

針對這種情況，有兩種方案可供選擇:

(1)每天的某個固定時間（如凌晨）定時生成網元文檔。通常來說，網絡設備在24 h內更改量不會很大，則可以在用戶需要時，將這份已經生成但卻是過時的數據提供給用戶。該方案能夠迅速地將網元信息反饋給用戶，并且基本上保證是比較新（24 h內）的數據。缺點是，在某些特殊情況下，小概率事件還是可能發生的，在某個較小的時間段內對網元進行了較大調整。這時用戶得到的就是大量的錯誤數據，將會導致用戶作出錯誤的決策。

(2)采用動態配置。在這個方案中，網元文檔的生成可分為兩種情況，即網絡初次運行時文檔的始化生成和網絡運行過程中設備增加、修改、刪除時的文檔更新。一般來說，初始化網元文檔的工作量較大，但是頻度低（一次）；而動態更新任務恰恰相反，工作量一般較小，但是頻度高（這個視實際運行過程中管理需要來確定）。動態配置避免了用戶得到臟的數據，并能保證用戶較快得到結果，但實現復雜。

綜合比較，可采用第二種方案。相對來說，對于動態地增加單板、改變單板的位置、為單板增加扣板、維修處理等變動，可采用動態更新的方法，即只對修改后的元件下發命令，獲取信息，并將更新后的信息保存到網元文檔中。歸納網元各個元件的變動有如下三種情況：①增加，多指增加物理元件，如增加單板。②修改，多見于修改軟件信息或配置信息，如增加維修記錄（指修改歷史信息）、更換軟件版本（修改版本信息）。③刪除，如卸載軟件版本、拆除物理元件。BAM的運行系統監控整個網元，一旦發現改動，則發送與該改動相關的命令字到主動請求模塊。主動請求模塊是一個隨系統而運行的線程，一旦接收到該命令字后，則檢查日志，判斷該改動是來自于服務器還是來自于現場運行環境。如果來自于服務器，則返回該命令字，不作處理；否則，查看MML命令配置文件（表1），將命令字對應的MML命令取出，并執行該MML命令。最后，將命令執行結果更新到網元文檔中。

網元文檔更新后，BAM發送MML通知報文告知服務器獲取新的網元文檔。

1.4 網元文檔的上傳

網元文檔可以通過CORBA接口、MML接口及FTP方式傳送。CORBA接口有數據長度的限制；MML接口具有靈活、方便、適合小數據的特點；而FTP方式則對于大數據量也能在很短時間內安全可靠地傳送。由于網元文檔數據量較大，從幾千字節到十幾兆字節不等，文中采納FTP方式上傳。網元文檔存儲的路徑一般是其網元類型為文件名的文件夾，同時以網管服務器為該網元分配的唯一ID為文件名，以避免多個網元可能重名的情況，造成網元文檔的覆蓋，并方便文檔檢索。

網元文檔上傳功能最初的設計方案采用的是在所有傳輸過程中，將GUI和網元均作為FTP客戶端，而網元文檔服務器作為FTP服務器，向客戶端和網元提供FTP服務。網元文檔生成后，服務器端下發上傳命令，同時將FTP用戶名、密碼、文件保存路徑一并下發。網元上傳文件，同時上報進度。但是對某些用戶，由于其特定的網絡安全策略，在網管系統和網元設備之間往往會添加防火墻的設置，導致網管系統的FTP端口不能被網元訪問，從而使得網元文檔的上傳功能不可用。

針對這種情況，使用中轉服務器的改進方案。無論網元是否具有FTP功能，其文件傳輸均以網元作為FTP服務器，而以網管服務器作為FTP客戶端。當某種網元不具有FTP服務器功能時，為其尋找一個可提供FTP服務的網元作為其中轉服務器，目標網元作為FTP客戶端將文件傳輸到該中轉服務器上；然后網管服務器作為一個FTP客戶端，從中轉服務器上將文件取到自身中。當某種網元具有FTP功能時，只要將該網元本身作為自己的中轉服務器，按照同樣的方式，即可獲取文件。在設置中轉服務器的條件下，服務器首先獲得中轉服務器的IP、用戶名、密碼等信息，并告知網元；然后網元將網元文檔上傳到中轉服務器，上傳成功后，通知服務器；最后，服務器通過FTP登錄到中轉服務器將相關文檔下載到本地。文檔上傳流程圖如圖2所示。

1.5 網元文檔的下載

網元文檔的下載是指GUI登錄到網元文檔服務器，將上傳到網元文檔服務器的網元文檔下載到用戶端。該過程較為簡單，不作詳細介紹。

2 關鍵技術

2.1 多線程執行

并發是網元文檔服務必要的需求。一方面，分布式系統中允許存在多個客戶的并發訪問方式；另一方面，多處理器平臺上的網絡服務器常常通過使用并發來提高整個系統的性能。網元文檔服務對于并發的支持表現在兩個方面：①使用多個線程來解批處理問題；ACE提供了Task框架，可以管理多個線程的執行。在該框架中，一個主線程MainTask被啟動，成為網絡看守的主事件循環，并等待響應客戶端的消息到來。客戶端每發送一個消息，就啟動一個線程來處理一個與網元交互的請求。該線程執行完某種處理后，會自動消亡。對于每一個網元也將啟動一個線程來執行相應的任務，任務執行完后自動消亡。②控制線程的數量。線程并不是越多越好，實驗數據（Sun Blade服務器：2GB內存，雙CPU）表明，當線程的數量達到一定數目時，在本實驗中線程數為1 000后，系統性能下降，處理出現瓶頸。于是在本系統中，當線程數達到500時，將暫停后面的任務，直到前面線程執行完畢，再喚醒后面的線程。

2.2 同步機制

網元文檔服務中啟用了多個線程，包括上報進度線程、任務超時計算線程、主線程。這些線程會訪問一些共同關心的數據，如各線程均會訪問任務時間。多個線程訪問同一段內存很可能造成數據的錯誤，所以，必須有一定的同步機制來序列化多線程控制的執行。ACE中的鎖機制可以解決這個問題。ACE中有幾種包裝為同步多線程提供了接口。在Guard接口包裝中，Gurard有效地利用C++類構造器和析構器的語義來確保在進入和退出代碼塊時分別自動獲取和釋放鎖ACE_Write_Guard和ACE_Read_Guard。

首先定義ACE_Mutex m_iTimerMute

上報進度線程

Guard包裝有效地保證了線程間的互斥。如上例，保證了同一時間對m_iTimer只能有一個操作。

2.3 通信機制

GUI及BAM與網元文檔服務器的網元文檔傳輸采用FTP協議方式；網元文檔服務器與BAM命令通信采用MML協議方式；GUI與網元文檔服務器的信息傳遞采用CORBA調用方式。這里討論MML協議及FTP協議的使用。

MML基于TCP協議，其報文格式如下：

發送與接收使用ACE提供的通信組件ACE：：Socket類，使用Socket通信的過程可參考文獻[6]。ACE同樣提供了FTP通信組件ACE：：FTP類，使用FTP通信的過程可參考文獻[6]。

3 結束語

文中設計并實現了一種網元文檔服務，解決了網元文檔生成、上傳時間長的問題，并提出了一系列技術，包括XML存儲方案、中轉服務器、多線程機制、同步機制等來保證系統可靠、高效地運行。網元文檔服務解決了網管各模塊包括故障、配置、性能、安全等對網元信息的遺漏，給出了解決方案，并已得到成功應用。但如果進行推廣，文檔內容及格式還需要進一步規范。

本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文。