集約化移動(dòng)無(wú)線網(wǎng)絡(luò)網(wǎng)管系統(tǒng)建設(shè)探討

王兵++沈建軍++羅萍

【摘 要】針對(duì)LTE網(wǎng)絡(luò)網(wǎng)元數(shù)量和設(shè)備提供商多、版本升級(jí)頻繁以及集約維護(hù)等問題，中國(guó)電信建設(shè)了LTE無(wú)線網(wǎng)絡(luò)一級(jí)架構(gòu)的綜合網(wǎng)管系統(tǒng)。通過對(duì)運(yùn)維集約化形式下4G無(wú)線網(wǎng)絡(luò)管理系統(tǒng)建設(shè)面臨的問題進(jìn)行分析，介紹了綜合網(wǎng)管系統(tǒng)的系統(tǒng)架構(gòu)、接口和數(shù)據(jù)等方案，總結(jié)了系統(tǒng)建設(shè)和應(yīng)用推廣過程中面臨的問題，并提出了相應(yīng)的解決思路，從而實(shí)現(xiàn)全網(wǎng)數(shù)據(jù)集中、能力統(tǒng)一、快速部署、降低投資等目標(biāo)。

【關(guān)鍵詞】網(wǎng)管系統(tǒng) 需求管理 集約化 大數(shù)據(jù)

doi：10.3969/j.issn.1006-1010.2017.02.005 中圖分類號(hào)：TN929.5 文獻(xiàn)標(biāo)志碼：A 文章編號(hào)：1006-1010（2017）02-0021-06

引用格式：王兵，沈建軍，羅萍. 集約化移動(dòng)無(wú)線網(wǎng)絡(luò)網(wǎng)管系統(tǒng)建設(shè)探討[J]. 移動(dòng)通信， 2017，41（2）： 21-26.

1 引言

網(wǎng)管系統(tǒng)是網(wǎng)絡(luò)維護(hù)管理的重要手段，考慮到網(wǎng)絡(luò)規(guī)模、用戶規(guī)模以及技術(shù)水平，國(guó)內(nèi)傳統(tǒng)的網(wǎng)管建設(shè)一般為二級(jí)建設(shè)方式，即省級(jí)和集團(tuán)級(jí)分別建設(shè)，各省系統(tǒng)相互獨(dú)立，通過規(guī)范的集團(tuán)-省接口將匯聚后的數(shù)據(jù)信息上傳給集團(tuán)級(jí)網(wǎng)管。這種模式下省級(jí)系統(tǒng)和集團(tuán)級(jí)系統(tǒng)兩級(jí)網(wǎng)管中的數(shù)據(jù)有不同顆粒度，數(shù)據(jù)量在技術(shù)可管理范圍內(nèi)，但各省網(wǎng)管系統(tǒng)的功能、數(shù)據(jù)模型、分析算法等各方面都可能不一致，為全國(guó)一張網(wǎng)進(jìn)行統(tǒng)一管理造成一定難度。

隨著網(wǎng)絡(luò)技術(shù)、大數(shù)據(jù)處理技術(shù)、存儲(chǔ)技術(shù)的逐步成熟，構(gòu)建新一代移動(dòng)無(wú)線網(wǎng)絡(luò)綜合網(wǎng)管系統(tǒng)也成為可能。中國(guó)電信從2014年開始建設(shè)新一代移動(dòng)無(wú)線網(wǎng)絡(luò)綜合網(wǎng)管系統(tǒng)，目前網(wǎng)管系統(tǒng)已完成架構(gòu)搭建和數(shù)據(jù)集中，初步實(shí)現(xiàn)了全國(guó)統(tǒng)一能力和統(tǒng)一模型，走出網(wǎng)管系統(tǒng)IP化、扁平化、融合化、智能化的第一步。

2 4G無(wú)線網(wǎng)絡(luò)管理面臨的問題

目前各大運(yùn)營(yíng)商基本已建設(shè)了一張覆蓋全國(guó)的4G無(wú)線網(wǎng)絡(luò)。4G網(wǎng)絡(luò)具有以下特點(diǎn)：

（1）網(wǎng)元數(shù)量多：扁平化的LTE網(wǎng)絡(luò)中無(wú)線基站和拉遠(yuǎn)端是無(wú)線網(wǎng)絡(luò)的末梢節(jié)點(diǎn)，由于頻段高，為達(dá)到覆蓋效果，基站和拉遠(yuǎn)端數(shù)量比3G時(shí)代的基站數(shù)量更多，根據(jù)公開數(shù)據(jù)，三大運(yùn)營(yíng)商的基站數(shù)量總和超過百萬(wàn)，小區(qū)數(shù)量更是數(shù)百萬(wàn)之多。

（2）設(shè)備商多、設(shè)備網(wǎng)管數(shù)量多、數(shù)據(jù)種類多：目前無(wú)線網(wǎng)絡(luò)設(shè)備提供商（FDD和TDD）為7家左右，這些設(shè)備商在硬件架構(gòu)、軟件架構(gòu)、數(shù)據(jù)產(chǎn)生機(jī)制、功能實(shí)現(xiàn)機(jī)制方面都有自己的設(shè)計(jì)，與上層網(wǎng)管系統(tǒng)的接口也有很大區(qū)別，導(dǎo)致在網(wǎng)絡(luò)管理中面臨各方面的不一致性。

（3）網(wǎng)元多版本并存、升級(jí)頻繁：無(wú)線網(wǎng)設(shè)備的版本升級(jí)一般每年不超過2個(gè)，考慮到網(wǎng)元數(shù)量和省級(jí)安全要求，版本升級(jí)會(huì)持續(xù)一段時(shí)間，網(wǎng)絡(luò)上一般會(huì)存在多版本共存的現(xiàn)象。不同版本的設(shè)備以及北向接口會(huì)有所區(qū)別。

（4）集約化要求：集約化工作是運(yùn)營(yíng)商提升運(yùn)營(yíng)效率的重要舉措，在網(wǎng)絡(luò)管理方面不僅體現(xiàn)在組織結(jié)構(gòu)方面的調(diào)整，網(wǎng)管系統(tǒng)的集約化建設(shè)、配合集約化組織結(jié)構(gòu)的遠(yuǎn)程操作維護(hù)、故障精確定位以及派單量壓縮等也是新一代網(wǎng)管需要面臨的問題。特別是面臨多設(shè)備商時(shí)，多個(gè)設(shè)備網(wǎng)管的獨(dú)立實(shí)現(xiàn)跨設(shè)備商的統(tǒng)一網(wǎng)絡(luò)管理更是急需解決。

（5）數(shù)據(jù)分析要求：多網(wǎng)元、多業(yè)務(wù)、多用戶帶來(lái)越來(lái)越多的網(wǎng)絡(luò)數(shù)據(jù)，端到端分析、精細(xì)化經(jīng)營(yíng)等需求越來(lái)越多的跨專業(yè)數(shù)據(jù)關(guān)聯(lián)分析，而由于業(yè)務(wù)形態(tài)和市場(chǎng)變化都很快，這些數(shù)據(jù)分析已經(jīng)突破了原有的思維模式，呈現(xiàn)出各種不確定性和探索性，不再局限于某類固定數(shù)據(jù)范圍和分析算法。

3 集約化一級(jí)網(wǎng)管建設(shè)方案

3.1 網(wǎng)管架構(gòu)

網(wǎng)管專用承載網(wǎng)絡(luò)示意圖如圖1所示。其中，OMC（Operation and Maintenance Center，操作維護(hù)中心）是設(shè)備商的網(wǎng)管系統(tǒng)，省采集網(wǎng)關(guān)通過設(shè)備網(wǎng)管的北向接口匯聚無(wú)線網(wǎng)絡(luò)的數(shù)據(jù)，通過VPN（Virtual Private Network，虛擬專網(wǎng)）網(wǎng)絡(luò)建立的獨(dú)立承載網(wǎng)絡(luò)，確保網(wǎng)管在維護(hù)操作管理的安全性。

3.2 接口方案

綜合網(wǎng)管的數(shù)據(jù)來(lái)自設(shè)備網(wǎng)管的北向接口輸出，從數(shù)據(jù)源采集到綜合網(wǎng)管對(duì)外的數(shù)據(jù)輸出服務(wù)包括三層接口：第一層接口為設(shè)備網(wǎng)管OMC與采集網(wǎng)關(guān)之間的接口（簡(jiǎn)稱為I1），采用設(shè)備商的私有接口，采集全量（地域、時(shí)域）的數(shù)據(jù)源；第二層接口為省采集網(wǎng)關(guān)與統(tǒng)一應(yīng)用平臺(tái)采集層接口（簡(jiǎn)稱為I2），由省采集網(wǎng)關(guān)進(jìn)行省數(shù)據(jù)的匯聚與文件級(jí)標(biāo)準(zhǔn)化，保證原始數(shù)據(jù)的完整性；第三層接口為統(tǒng)一應(yīng)用平臺(tái)的對(duì)外接口（簡(jiǎn)稱為I3），由綜合網(wǎng)管對(duì)數(shù)據(jù)進(jìn)行解析、分析、處理后形成標(biāo)準(zhǔn)化的數(shù)據(jù)，通過標(biāo)準(zhǔn)化的接口進(jìn)行數(shù)據(jù)共享和數(shù)據(jù)輸出能力，為其他系統(tǒng)提供跨設(shè)備商的標(biāo)準(zhǔn)化數(shù)據(jù)源，同時(shí)也根據(jù)分析需求從其他系統(tǒng)采集數(shù)據(jù)。具體如圖2所示。

不同層次的接口按照數(shù)據(jù)類型可分為實(shí)時(shí)告警數(shù)據(jù)和準(zhǔn)實(shí)時(shí)文件數(shù)據(jù)，按照數(shù)據(jù)內(nèi)容可分為告警、性能、基礎(chǔ)資源、測(cè)量報(bào)告、呼叫記錄等，按照數(shù)據(jù)加工可分為原始數(shù)據(jù)和標(biāo)準(zhǔn)化數(shù)據(jù)，形成服務(wù)于不同應(yīng)用不同需求、實(shí)現(xiàn)跨專業(yè)跨設(shè)備商的全方位無(wú)線網(wǎng)絡(luò)數(shù)據(jù)輸出能力。

3.3 網(wǎng)管系統(tǒng)部署方案

作為一級(jí)網(wǎng)管系統(tǒng)，統(tǒng)一應(yīng)用平臺(tái)日處理文件數(shù)據(jù)在TB級(jí)別以上，原始告警量平均每日接近1000萬(wàn)條，傳統(tǒng)的系統(tǒng)硬件架構(gòu)已經(jīng)很難滿足用戶的查詢速度要求。以Hadoop為代表的大數(shù)據(jù)處理技術(shù)經(jīng)過互聯(lián)網(wǎng)界近十年的實(shí)踐和應(yīng)用已經(jīng)逐步成熟，形成文件存儲(chǔ)、數(shù)據(jù)計(jì)算、資源管理等豐富完整的產(chǎn)品和社區(qū)生態(tài)鏈，成為事實(shí)上的大數(shù)據(jù)平臺(tái)技術(shù)的自然選擇。

網(wǎng)管系統(tǒng)硬件架構(gòu)示意圖如圖3所示：

統(tǒng)一應(yīng)用平臺(tái)的硬件平臺(tái)基于公共云資源池搭建，根據(jù)軟件分層處理功能，利用云資源池中虛擬機(jī)和物理機(jī)組成幾個(gè)相對(duì)獨(dú)立的集群，分別對(duì)外承擔(dān)數(shù)據(jù)采集、數(shù)據(jù)處理、數(shù)據(jù)庫(kù)服務(wù)、應(yīng)用和門戶服務(wù)、報(bào)表服務(wù)、GIS服務(wù)等能力，隨著網(wǎng)絡(luò)規(guī)模、用戶規(guī)模和數(shù)據(jù)規(guī)模的不斷擴(kuò)大，各能力集群的規(guī)?？蛇M(jìn)行無(wú)縫動(dòng)態(tài)調(diào)整。

3.4 數(shù)據(jù)規(guī)劃

網(wǎng)管系統(tǒng)的處理對(duì)象是數(shù)據(jù)，這些數(shù)據(jù)包括傳統(tǒng)的告警數(shù)據(jù)、基礎(chǔ)資源數(shù)據(jù)、網(wǎng)絡(luò)運(yùn)行指標(biāo)數(shù)據(jù)。此外，還有LTE無(wú)線網(wǎng)絡(luò)特有的MR（Measurement Report，測(cè)量報(bào)告）、CDR（Call Detail Record，呼叫詳細(xì)記錄）等數(shù)據(jù)。這些數(shù)據(jù)從多方位描述無(wú)線網(wǎng)絡(luò)的網(wǎng)絡(luò)資產(chǎn)、設(shè)備運(yùn)行狀態(tài)、網(wǎng)絡(luò)運(yùn)行質(zhì)量以及用戶體驗(yàn)，都是進(jìn)行網(wǎng)絡(luò)管理和網(wǎng)絡(luò)運(yùn)營(yíng)分析的基礎(chǔ)。

從數(shù)據(jù)格式和實(shí)時(shí)性要求來(lái)看，這些數(shù)據(jù)可分為準(zhǔn)實(shí)時(shí)文件型和實(shí)時(shí)消息型，其中告警數(shù)據(jù)是實(shí)時(shí)消息型，其他數(shù)據(jù)基本是準(zhǔn)實(shí)時(shí)文件型，產(chǎn)生文件的時(shí)間粒度從5分鐘到24小時(shí)不等；從數(shù)據(jù)量來(lái)看，文件型數(shù)據(jù)大致可分為大數(shù)據(jù)和小數(shù)據(jù)，其中MR、CDR數(shù)據(jù)全網(wǎng)每日原始文件超過20 TB，占所有數(shù)據(jù)量的95%以上，是網(wǎng)管系統(tǒng)中的“大數(shù)據(jù)”；從使用需求來(lái)看，除了告警的實(shí)時(shí)呈現(xiàn)外，對(duì)數(shù)據(jù)的分析還包括目標(biāo)詳單的查詢和基于固定模板的統(tǒng)計(jì)匯總。針對(duì)不同的數(shù)據(jù)特征應(yīng)用需求，各類數(shù)據(jù)需要基于不同的工具或組件實(shí)現(xiàn)。

網(wǎng)管系統(tǒng)軟件架構(gòu)示意圖如圖4所示：

傳統(tǒng)的性能數(shù)據(jù)、資源數(shù)據(jù)、參數(shù)數(shù)據(jù)等數(shù)據(jù)量較小的結(jié)構(gòu)化數(shù)據(jù)采用Oracle數(shù)據(jù)庫(kù)，MR、CDR數(shù)據(jù)量較大，基于開源大數(shù)據(jù)庫(kù)框架Hadoop實(shí)現(xiàn)，利用HBase進(jìn)行統(tǒng)計(jì)分析，同時(shí)通過Hive進(jìn)行單條記錄查詢。而告警數(shù)據(jù)為實(shí)時(shí)流數(shù)據(jù)，基于Storm進(jìn)行告警消息的標(biāo)準(zhǔn)化、與基礎(chǔ)信息的關(guān)聯(lián)以及實(shí)時(shí)分析等。

3.5 網(wǎng)管功能

傳統(tǒng)網(wǎng)管能力主要包括三個(gè)方面：網(wǎng)絡(luò)規(guī)模、運(yùn)行狀態(tài)監(jiān)控和運(yùn)行質(zhì)量分析。在集約化運(yùn)營(yíng)維護(hù)大背景下，利用一級(jí)平臺(tái)進(jìn)行跨設(shè)備商的操作也是必要功能。同時(shí)，隨著運(yùn)營(yíng)商從網(wǎng)絡(luò)維護(hù)到網(wǎng)絡(luò)運(yùn)營(yíng)的轉(zhuǎn)型，獨(dú)立的無(wú)線網(wǎng)分析遠(yuǎn)遠(yuǎn)無(wú)法滿足業(yè)務(wù)支撐和用戶支撐的需求，端到端聯(lián)合分析能力也是網(wǎng)管建設(shè)的目標(biāo)之一。

3.6 管理對(duì)象分析及基礎(chǔ)信息模型

LTE無(wú)線網(wǎng)絡(luò)中設(shè)備形態(tài)已不同于2G/3G時(shí)代，其最重要的典型特征在于扁平化以及射頻拉遠(yuǎn)站的大量使用，網(wǎng)絡(luò)管理對(duì)象下沉，RRU（Radio Remote Unit，射頻拉遠(yuǎn)單元）和小區(qū)成為最基礎(chǔ)的網(wǎng)元粒度，具有相對(duì)完整協(xié)議棧的基站依然是管理對(duì)象，但由于BBU（Building Base band Unit，基帶處理單元）池的大量采用而弱化，表現(xiàn)在其數(shù)量的大量減少。

根據(jù)LTE網(wǎng)絡(luò)的這一變化，形成天線、RRU、BBU、小區(qū)、站址為中心的管理對(duì)象。其中，天線、RRU、BBU是物理對(duì)象，是資源、現(xiàn)場(chǎng)維護(hù)、故障處理的基礎(chǔ)單元；小區(qū)是邏輯對(duì)象，是網(wǎng)絡(luò)優(yōu)化的基礎(chǔ)單元；站址對(duì)象確保物理對(duì)象和邏輯對(duì)象的精準(zhǔn)定位。這些管理對(duì)象之間通過特定標(biāo)識(shí)進(jìn)行關(guān)聯(lián)，以全面支持資源管理、維護(hù)操作、問題定位和性能優(yōu)化。具體如圖5所示：

圖5 基礎(chǔ)信息模型關(guān)系示意圖

根據(jù)以上規(guī)劃以及維護(hù)優(yōu)化需求建立LTE基礎(chǔ)資源信息表，每個(gè)管理對(duì)象一張表，在每個(gè)管理對(duì)象中根據(jù)維護(hù)需求增加相關(guān)屬性，比如：在BBU表中包括廠家、制式、S1配置帶寬等，在RRU表中包括端口數(shù)量、所服務(wù)營(yíng)業(yè)部等，在天線表中包括天線的一些特定屬性及經(jīng)緯度信息等。

目前基礎(chǔ)資源信息表中已包含超過500個(gè)屬性，根據(jù)維護(hù)和優(yōu)化需求，可組成面向不同維護(hù)角色、不同分析角度的資源子模型。

4 互聯(lián)網(wǎng)時(shí)代網(wǎng)管建設(shè)思路

4.1 從私有接口到標(biāo)準(zhǔn)接口

近年來(lái)，大數(shù)據(jù)這個(gè)概念已經(jīng)甚囂塵上，但是數(shù)據(jù)量并不是無(wú)線移動(dòng)網(wǎng)絡(luò)一級(jí)網(wǎng)管建設(shè)最大的難題。事實(shí)上，數(shù)據(jù)以及數(shù)據(jù)接口的不規(guī)范、不穩(wěn)定這個(gè)大數(shù)據(jù)領(lǐng)域最常面臨的問題也是一級(jí)網(wǎng)管建設(shè)最大的挑戰(zhàn)。

從接口協(xié)議上看，可采用從私有接口到標(biāo)準(zhǔn)接口逐步過渡的建設(shè)思路。3GPP以及3GPP2組織投入在各網(wǎng)元之間接口的研究力度很大，但對(duì)網(wǎng)管方面的研究遠(yuǎn)比不上對(duì)網(wǎng)絡(luò)的研究，在建設(shè)網(wǎng)管時(shí)，NMS（Network Management System，網(wǎng)絡(luò)管理系統(tǒng)）與EMS（Element Management System，網(wǎng)元管理系統(tǒng)）之間的數(shù)據(jù)接口一直存在標(biāo)準(zhǔn)接口和私有接口兩種方案。NMS與EMS之間標(biāo)準(zhǔn)化接口不僅需要對(duì)網(wǎng)絡(luò)的深刻理解，也需要對(duì)網(wǎng)絡(luò)組織、網(wǎng)絡(luò)接口協(xié)議、軟件編程、數(shù)據(jù)庫(kù)等都有深入研究和積累。而在網(wǎng)管建設(shè)初期，網(wǎng)管方面的技術(shù)積累一般比較少，采用私有接口可跨過漫長(zhǎng)的標(biāo)準(zhǔn)化過程，根據(jù)設(shè)備商的自有能力快速部署，并可通過跨設(shè)備商的橫向分析逐步學(xué)習(xí)到相對(duì)健康高效的接口方案。

但采用私有接口時(shí)網(wǎng)管建設(shè)工作量相對(duì)較大，對(duì)一級(jí)系統(tǒng)而言這個(gè)問題尤其突出。以中國(guó)電信為例，從設(shè)備網(wǎng)管到省采集網(wǎng)關(guān)、從省采集網(wǎng)關(guān)到統(tǒng)一應(yīng)用平臺(tái)，全網(wǎng)超過100個(gè)設(shè)備網(wǎng)管、200個(gè)省采集網(wǎng)關(guān)服務(wù)器共接入了7個(gè)設(shè)備商三大類數(shù)據(jù)，平均每個(gè)設(shè)備商有2個(gè)以上的在網(wǎng)版本，并不斷發(fā)生版本滾動(dòng)更新，任何數(shù)據(jù)源頭、數(shù)據(jù)傳輸環(huán)節(jié)中的變化都會(huì)引起網(wǎng)管中數(shù)據(jù)的波動(dòng)，導(dǎo)致數(shù)據(jù)異常，很多時(shí)候需要人工一一排查，否則影響網(wǎng)管的正常使用。因此，從長(zhǎng)遠(yuǎn)考慮，獨(dú)立出數(shù)據(jù)中間層、標(biāo)準(zhǔn)化NMS接口是一級(jí)網(wǎng)管建設(shè)的最終方案，使網(wǎng)管建設(shè)能夠?qū)Ｗ⒂跀?shù)據(jù)分析和能力建設(shè)。

4.2 漸進(jìn)式網(wǎng)管建設(shè)

在網(wǎng)管建設(shè)中，重點(diǎn)在于功能設(shè)計(jì)以及支撐功能的數(shù)據(jù)。從功能設(shè)計(jì)來(lái)看，一級(jí)網(wǎng)管面向全國(guó)運(yùn)營(yíng)維護(hù)所涉及的多種角色包括基礎(chǔ)資源管理、網(wǎng)絡(luò)監(jiān)控、運(yùn)營(yíng)分析三大類以及一線操作角色、本地網(wǎng)/省/集團(tuán)的技術(shù)管理角色等，形成二維角色矩陣，每個(gè)矩陣元素的要求都不一致；從數(shù)據(jù)來(lái)看，數(shù)據(jù)來(lái)源于不同設(shè)備商（目前7個(gè)設(shè)備商、TDD/FDD兩個(gè)技術(shù)體制），數(shù)據(jù)種類豐富（目前包括基礎(chǔ)資源信息、告警實(shí)時(shí)消息、性能數(shù)據(jù)、測(cè)量數(shù)據(jù)等），形成面向不同功能又相互關(guān)聯(lián)的數(shù)據(jù)集合。

面對(duì)這樣的功能規(guī)劃和數(shù)據(jù)集合，網(wǎng)管建設(shè)不宜激進(jìn)，應(yīng)穩(wěn)步推進(jìn)。首期以完成網(wǎng)絡(luò)搭建、關(guān)鍵數(shù)據(jù)采取以及基本網(wǎng)管能力為目標(biāo)，滿足運(yùn)營(yíng)維護(hù)基本要求，達(dá)到網(wǎng)管能用；第二期可根據(jù)首期的應(yīng)用情況，擴(kuò)大數(shù)據(jù)采集范圍、提升數(shù)據(jù)質(zhì)量、優(yōu)化功能操作、增加輔助數(shù)據(jù)和維護(hù)監(jiān)控管理功能、做好需求管理，達(dá)到網(wǎng)管好用；第三期則在穩(wěn)健的數(shù)據(jù)基礎(chǔ)和管理手段上，在應(yīng)用上進(jìn)行擴(kuò)展，在架構(gòu)上進(jìn)行優(yōu)化，進(jìn)入迭代增強(qiáng)的良性循環(huán)中。

4.3 敏捷式需求管理思路

在傳統(tǒng)的二級(jí)網(wǎng)管建設(shè)中，省級(jí)網(wǎng)管只承載省級(jí)需求，由省公司主導(dǎo)建設(shè)，集團(tuán)公司主導(dǎo)集團(tuán)網(wǎng)管建設(shè)，承載集團(tuán)級(jí)需求，用戶需求直達(dá)網(wǎng)管。

一級(jí)網(wǎng)管系統(tǒng)一般由集團(tuán)公司主導(dǎo)，而用戶則從集團(tuán)一直到本地網(wǎng)甚至區(qū)縣一線維護(hù)人員，因此最大的困難在于如何發(fā)現(xiàn)和體現(xiàn)用戶的真正需求。傳統(tǒng)的需求調(diào)研方法是通過集團(tuán)發(fā)文征集分公司需求，而被征集者往往人數(shù)和角色都很有限，所以看上去很規(guī)范嚴(yán)謹(jǐn)?shù)男枨蠊芾硗饔谛问剑斐蓱?yīng)用與實(shí)際需求不符等。

由于集團(tuán)和省的需求不同，31個(gè)省在組織結(jié)構(gòu)、運(yùn)維體系、數(shù)據(jù)口徑、網(wǎng)絡(luò)運(yùn)行評(píng)估要求、維護(hù)技術(shù)力量等各方面也存在不一致性，在需求管理中面對(duì)統(tǒng)一與個(gè)性、基礎(chǔ)與提升、近期與長(zhǎng)遠(yuǎn)等之間的各種矛盾時(shí)，既要考慮為維護(hù)力量薄弱省份提供基礎(chǔ)網(wǎng)管能力，又要兼顧技術(shù)強(qiáng)省的個(gè)性分析監(jiān)控要求；既要為省級(jí)用戶提供基礎(chǔ)監(jiān)控流水查詢，又要為集團(tuán)用戶宏觀展現(xiàn)全網(wǎng)運(yùn)行質(zhì)量；既要為技術(shù)主管提供報(bào)表服務(wù)，又要為一線技術(shù)人員提供基礎(chǔ)數(shù)據(jù)進(jìn)行線外加工分析。在傳統(tǒng)的需求調(diào)研階段，這些需求很難全面展現(xiàn)出來(lái)，而在網(wǎng)管系統(tǒng)真正投入運(yùn)行、直接面對(duì)用戶時(shí)才會(huì)逐步表現(xiàn)出來(lái)，并呈現(xiàn)出發(fā)散特征。

為了避免這種情況，除集團(tuán)層面的戰(zhàn)略性需求之外，其他需求管理可在一定程度上借鑒互聯(lián)網(wǎng)應(yīng)用的敏捷思路。在網(wǎng)管建設(shè)早期，以最基礎(chǔ)能力快速推出網(wǎng)管，同時(shí)輔助開放式問題管理平臺(tái)進(jìn)行需求搜集，從用戶反饋問題中挖掘需求，形成實(shí)質(zhì)上的“眾籌需求”，快速解決問題中的Bug，從而快速部署用戶關(guān)注度高的功能需求。在網(wǎng)管逐步成熟后，則引入Kano模式，通過專家團(tuán)隊(duì)對(duì)需求進(jìn)行管控，確定需求優(yōu)先級(jí)，保證網(wǎng)管的迭代過程，并在每期網(wǎng)管中分層次體現(xiàn)出必要性功能、增強(qiáng)性功能以及亮點(diǎn)引導(dǎo)性功能。

事實(shí)上，綜合網(wǎng)管用戶表達(dá)的需求與最終產(chǎn)品之間的不對(duì)等會(huì)長(zhǎng)期存在，這方面需要網(wǎng)管產(chǎn)品需求分析人具備一定的洞察力和表達(dá)能力，同時(shí)通過用戶需求宣講、需求分析人員的反宣講等過程進(jìn)行數(shù)次磨合，并在功能上線后進(jìn)行打磨，向用戶需求無(wú)限逼近，打破工程以“期”的絕對(duì)劃分模式。

4.4 層次化用戶管理與扁平化用戶服務(wù)

網(wǎng)管上線后，在應(yīng)用推動(dòng)下，用戶數(shù)量會(huì)增長(zhǎng)很快。由于一級(jí)網(wǎng)管用戶具有層次和角色的多樣性，并且因?yàn)閸徫徽{(diào)整，用戶角色變化較快。面對(duì)如此數(shù)量多、角色多、變化快的情況，傳統(tǒng)的集中式面對(duì)面培訓(xùn)在現(xiàn)場(chǎng)培訓(xùn)的時(shí)間效率、培訓(xùn)結(jié)束后的傳承效果等方面都很難達(dá)到預(yù)期。

反觀互聯(lián)網(wǎng)應(yīng)用，很多受歡迎的互聯(lián)網(wǎng)應(yīng)用基本沒有用戶培訓(xùn)，用戶服務(wù)也大多采用在線方式，這得益于其功能設(shè)計(jì)的簡(jiǎn)潔和易用。網(wǎng)管系統(tǒng)是專業(yè)系統(tǒng)，在設(shè)計(jì)簡(jiǎn)潔和易用性方面很難完全達(dá)到互聯(lián)網(wǎng)應(yīng)用的水平，但可以借鑒互聯(lián)網(wǎng)應(yīng)用的服務(wù)模式，并與傳統(tǒng)培訓(xùn)模式相結(jié)合，促進(jìn)用戶快速與系統(tǒng)建立友好的關(guān)系。

在傳統(tǒng)面對(duì)面培訓(xùn)中，以網(wǎng)管內(nèi)部架構(gòu)、算法邏輯、流程及配置、新功能等為主，面向各省網(wǎng)管管理員及骨干人員，他們負(fù)責(zé)承接省內(nèi)網(wǎng)管的工作管理，包括用戶角色配置、需求確認(rèn)、工程接入等，并且他們也是網(wǎng)管培訓(xùn)的頂層人員，負(fù)責(zé)組織省內(nèi)的針對(duì)性培訓(xùn)等；同時(shí)，在網(wǎng)管系統(tǒng)中增加需求管理，建立交流社區(qū)，形成需求可跟蹤、經(jīng)驗(yàn)可分享、規(guī)范可查閱的開放透明平臺(tái)，促進(jìn)一線用戶自助服務(wù)和互助服務(wù)。

此外，還可以結(jié)合QQ交流群、視頻集中答疑、在線幫助等，為一線用戶直接提供操作類應(yīng)答，作為集中培訓(xùn)的輔助手段，為新入崗的用戶提供技術(shù)指導(dǎo)。

5 結(jié)束語(yǔ)

與傳統(tǒng)二級(jí)架構(gòu)的網(wǎng)管系統(tǒng)相比，一級(jí)架構(gòu)的無(wú)線綜合網(wǎng)管系統(tǒng)有其獨(dú)特的優(yōu)勢(shì)，也有其難度，這些難度體現(xiàn)在由于用戶量和數(shù)據(jù)量增大而帶來(lái)的架構(gòu)方面的顛覆、由于接口多樣性而帶來(lái)的數(shù)據(jù)難度、由于數(shù)據(jù)種類豐富和數(shù)據(jù)格式不統(tǒng)一而帶來(lái)的數(shù)據(jù)管控方式的變化、由于用戶層次多及角色多而帶來(lái)的需求管理方面和用戶服務(wù)方面的困境。因此，不能簡(jiǎn)單地將其看為一個(gè)二級(jí)系統(tǒng)的擴(kuò)大版、增強(qiáng)版，而需要引入新的思路面對(duì)各方面的變化，在逐步探索中形成穩(wěn)定成熟的建設(shè)和管理模式。網(wǎng)管系統(tǒng)的生命周期與網(wǎng)絡(luò)生命周期相同，對(duì)于一個(gè)網(wǎng)管系統(tǒng)，10年生命周期是相對(duì)合理的，而其規(guī)模建設(shè)應(yīng)在生命周期的前5年之內(nèi)完成，為后5年乃至更長(zhǎng)時(shí)間內(nèi)的成熟應(yīng)用打下良好基礎(chǔ)。

中國(guó)電信4G無(wú)線綜合網(wǎng)管系統(tǒng)是國(guó)內(nèi)第一個(gè)無(wú)線與移動(dòng)專業(yè)方面的綜合網(wǎng)管系統(tǒng)，目前已完成超過40萬(wàn)個(gè)基站、150萬(wàn)個(gè)LTE小區(qū)、7個(gè)無(wú)線設(shè)備商的基本運(yùn)營(yíng)數(shù)據(jù)接入，在系統(tǒng)建設(shè)中，綜合網(wǎng)管系統(tǒng)搭建了可平滑擴(kuò)展的軟件、硬件架構(gòu)，解決了數(shù)據(jù)、接口、工程方面的諸多難題，目前為全網(wǎng)近3千名無(wú)線網(wǎng)維護(hù)運(yùn)營(yíng)人員提供了基本網(wǎng)絡(luò)故障監(jiān)控、運(yùn)營(yíng)分析能力，實(shí)現(xiàn)了從二級(jí)網(wǎng)管向一級(jí)網(wǎng)管的突破。

本文通過介紹4G無(wú)線綜合網(wǎng)管系統(tǒng)建設(shè)的相關(guān)內(nèi)容，提出了所面臨的一些問題和解決思路。作為互聯(lián)網(wǎng)時(shí)代中的網(wǎng)管系統(tǒng)，互聯(lián)網(wǎng)技術(shù)和思維已經(jīng)滲入到網(wǎng)管系統(tǒng)建設(shè)的方方面面；而作為專業(yè)網(wǎng)管系統(tǒng)，傳統(tǒng)的一些管理方式依然不能完全摒棄。中國(guó)電信4G無(wú)線綜合網(wǎng)管系統(tǒng)是一級(jí)網(wǎng)管的試水者，需要在未來(lái)工作中繼續(xù)探討將兩者如何更好地結(jié)合。

參考文獻(xiàn)：

[1] 瓊斯. 軟件工程最佳實(shí)踐[M]. 吳舜賢，楊傳輝，韓生亮，譯. 北京： 機(jī)械工業(yè)出版社， 2014.

[2] 陳波波. 基于KANO模型的質(zhì)量評(píng)價(jià)研究[D]. 北京： 北京郵電大學(xué)， 2008.

[3] IT架構(gòu)設(shè)計(jì)研究組. 大數(shù)據(jù)時(shí)代的IT架構(gòu)設(shè)計(jì)[M]. 北京： 電子工業(yè)出版社， 2014.

[4] 顧炯炯. 云計(jì)算架構(gòu)技術(shù)與實(shí)踐[M]. 北京： 清華大學(xué)出版社， 2014.

[5] 懷特. Hadoop權(quán)威指南[M]. 4版. 南京： 東南大學(xué)出版社， 2015.

[6] 3GPP TS 32.435. Telecommunication management； Performance measurement； eXtensible Markup Language （XML） file format definition （Release 9）[S]. 2009.

[7] 3GPP TS 32.401. Telecommunication management； Performance Management （PM）； Concept and requirements （Release 9）[S]. 2009.

[8] 3GPP TS 32.102. Telecommunication management； Architecture （Release 9）[S]. 2010.

[9] 3GPP TS 32.302. Telecommunication management； Configuration Management （CM）； Notification Integration Reference Point （IRP）； Information Service （IS） （Release 9）[S]. 2009.

[10] 如何進(jìn)行需求管理[EB/OL]. （2016-09-01）. http：//www.zhihu.com/question/19844142.★