郭建華，向 華

（1.廣東技術師范學院計算機科學學院 廣州510665；2.億陽信通股份有限公司 北京100093）

1 引言

為了增強核心競爭力，建設“以客戶為中心”的運維支撐系統(tǒng)成為電信運營商的重要目標[1，2]。網絡相關的投訴在移動通信客戶投訴中占很大比例，網絡投訴的應答和處理需要結合相關的網絡運維信息和專業(yè)知識進行分析，客服人員接到網絡投訴后，一般只能簡單記錄后轉發(fā)給網維部門處理。這種傳統(tǒng)的網絡投訴處理方式，對于客戶而言因為得不到及時有效的應答，感知較差；對于網維部門而言，面對數量巨大、信息記錄不規(guī)范的投訴工單，難以進行有效的分析和歸并處理。在運維支撐系統(tǒng)上建設“以客戶為中心”的網絡投訴支撐平臺，幫助客服人員規(guī)范記錄網絡投訴，并自動分析投訴原因，直接有效地應答客戶，是解決上述問題的有效途徑。

支持跨部門的業(yè)務協作和信息共享，并且適應未來的業(yè)務變化，是網絡投訴支撐平臺需要考慮的核心問題。電信管理論壇（TMF）提出的下一代運營軟件系統(tǒng)（next generation operations systems and software，NGOSS）體系[3]是下一代運維支撐系統(tǒng)的參照規(guī)范，為解決上述核心問題提供了清晰的指導思想。NGOSS體系包括增強的電信運維流程框架（enhanced telecom operations map,eTOM）、共享信息和數據模型（shared information/data,SID）以及技術中立的軟件體系結構（technology neutral architecture,TNA），其基本思想可以概括為：以業(yè)務運營流程為業(yè)務需求驅動，以共享信息數據模型為信息交換基礎，應用基于組件的軟件體系結構實現分布異構環(huán)境中的應用集成系統(tǒng)，以期實現業(yè)務運營流程的自動化[4，5]。本文參照NGOSS的思想來研究移動通信網絡投訴支撐平臺，以提高網絡投訴的客戶感知和處理效率為目標，在客服部門和網維部門之間建立端到端的網絡投訴處理流程和共享信息數據模型，進而設計適應業(yè)務變化的，基于組件的軟件體系結構。

2 端到端的網絡投訴處理流程

eTOM流程框架是電信運營流程向導的藍圖，采用多級視圖和矩陣結構對電信企業(yè)運營流程進行了規(guī)范描述。eTOM通過三級視圖對電信運營流程元素提供了詳盡的列表，并且提供了端到端業(yè)務流程的部分流程樣例[6]。因為各個運營商的管理流程差異很大，eTOM的主要價值并非其流程樣例，而在于指導電信企業(yè)利用流程元素構建具體的端到端業(yè)務流程。

網絡投訴處理流程服務的對象是客戶，在eTOM 1級視圖中屬于運營（Operation）區(qū)域，在2級視圖中屬于保障（Assurance）垂直流程組，3級視圖中為該流程組定義了一系列流程元素。為了簡化流程，提高處理效率，我國電信運營商網絡投訴處理的重點在于問題處理，因此客戶QoS/SLA管理、客戶保持與忠誠度等流程元素可以暫時忽略，簡化的網絡投訴處理流程如圖1所示。

端到端的網絡投訴處理流程跨越3個水平流程組：市場、產品和客戶，服務，資源，流程步驟描述如下：

（1）客戶感知網絡服務問題并報告給客服人員；

（2）客服人員通過“問題處理”流程發(fā)送投訴描述給“服務問題管理”流程；

（3）“服務問題管理”流程通過“資源故障管理”進行資源層問題分析；

（4）“資源故障管理”定位投訴原因后，逐級返回投訴解釋；

（5）客服人員根據返回的投訴解釋回復客戶投訴，網絡投訴處理終結。

網絡投訴處理流程雖然比較簡單，卻反映了實現流程自動化時橫向層面的系統(tǒng)融合，引導出了網絡投訴支撐平臺的系統(tǒng)需求，網絡投訴支撐平臺著重實現網絡運維信息和專業(yè)知識的共享，以支撐網絡投訴的規(guī)范描述和自動分析。客服人員利用網絡投訴支撐平臺，能夠快速定位投訴原因，提高投訴一次完成率，提升客戶感知；同時對投訴進行規(guī)范描述和初步歸并，提高網維部門的投訴處理效率。

3 網絡投訴支撐平臺的共享信息/數據模型

3.1 網絡投訴支撐的可聚合商業(yè)實體

SID是NGOSS的共享信息模型框架，其目標是建立企業(yè)級的全局數據管理中心，為電信運營商的信息集成平臺提供統(tǒng)一和標準的信息服務。與eTOM的水平流程組相對應，SID框架首先從商業(yè)視角劃分為市場/銷售、產品和客戶，服務，資源，供應商/合作伙伴等4個水平層次的信息管理域，然后針對每個域定義可聚合商業(yè)實體（aggregate business entity,ABE）和商業(yè)實體（business entity,BE），一個BE代表了一個與運營相關的物理或邏輯上的事物，如客戶、客戶訂單、客戶賬戶等，一個ABE則是在一組高內聚、低耦合的BE上定義的信息和操作[7]。

網絡投訴處理流程主要涉及客戶域和資源域的信息共享。移動通信環(huán)境下，引發(fā)網絡投訴的資源層問題主要是網絡故障和網絡覆蓋缺陷。基站斷站是引發(fā)投訴的主要網絡故障，基站斷站會引發(fā)局部區(qū)域突然信號變弱或中斷，MSC和BSC的故障也會引發(fā)更大區(qū)域的接通或信號問題，網絡故障原因可進一步追溯到設備故障和工程割接。網絡覆蓋缺陷包括信號盲區(qū)和弱信號區(qū)，需要通過網絡優(yōu)化和規(guī)劃建站來解決，有的網絡覆蓋缺陷屬于物業(yè)難點，短期內不能解決。網絡故障和網絡覆蓋缺陷引發(fā)的是一定區(qū)域的服務質量下降或服務中斷，而客戶的網絡投訴在地理上也分布在上述區(qū)域，因此，地理信息是網絡投訴分析的紐帶信息。本文以地理信息為紐帶按照如下步驟進行網絡投訴分析：（1）確定投訴客戶的地理位置；（2）關聯查找投訴客戶周邊區(qū)域的網絡信息，包括其他同類投訴、故障基站、信號盲區(qū)、弱信號區(qū)等；（3）通過網絡信息分析投訴原因，給出解釋口徑。

與此相對應，定義如下ABE：投訴定位（ComplaintLocation）ABE、網絡信息查詢（NetInfoQuery）ABE、投訴原因分析（ComplaintAnalysis）ABE。

投訴定位ABE：屬于客戶域，根據用戶的投訴描述模糊查找相關地物（包括建筑物、街道、企業(yè)、學校等），確定投訴用戶的地理位置（地理位置統(tǒng)一用經度和緯度描述，下同）。

網絡信息查詢ABE：屬于資源域，根據某一地理位置，查詢周邊區(qū)域（一般以基站覆蓋半徑范圍為基準）的相關網絡信息。

投訴原因分析ABE：屬于資源域，根據投訴周邊區(qū)域的網絡信息進行分析，找出可能的投訴原因。

圖6所示膠粘修復結構示意圖，金屬裂紋母板兩端施加100MPa均勻的拉伸載荷；表1所示為上述材料的材料力學性能列表。

3.2 網絡投訴支撐的商業(yè)實體UML模型

從投訴定位ABE抽象出客戶（Customer）、客戶投訴（NetComplaint）、投訴類型（ComplaintType）、基礎地物（Feature）等BE，從網絡信息查詢ABE抽象出信號盲區(qū)（BliandArea）、弱信號區(qū)（WeakArea）、物業(yè)難點（PropertyDifficulty）、網元（NetElement）、網元告警（NeAlarm）、工程割接（Changeover）等BE，從投訴原因分析ABE抽象出投訴解釋器（ComplaintExplainer）BE，參考 SID的設計模式，建立的BE UML模型如圖2所示。

模型中，帶有地理位置的網絡實體，包括網絡投訴、網元、信號盲區(qū)等，抽象為網絡對象（NetObject），而網絡對象的地理位置及其在地圖上的展現（figure）則通過聚合地理對象（GeoObject）來實現，從地理對象派生出點（point）、線（line）、多邊形（polygon）等形狀對象。網絡對象與地理對象之間不是派生關系，而是聚合關系，其優(yōu)點在于兩者之間的耦合很松散，網元在SID框架中已納入資源模型的范疇，與地理對象建立聚合關系不會破壞原有的資源模型，另外，一個網絡對象可以同時使用一個或多個地理對象靈活表示。同理，基礎地物與地理對象也是聚合關系。

網絡信息查詢 ABE 中，基站（BTS）、MSC、BSC 等從網元派生，規(guī)劃站（PlanedBTS）作為一種特殊的基站從 BTS中派生，網元與網元告警之間是聚合關系（NeHasAlarm），一個網元告警關聯一個網元類型（AlarmType）。在地理上，網元可以根據其所處的地理位置和網絡覆蓋區(qū)域，同時使用多個地理對象描述，基站的覆蓋區(qū)域用其覆蓋半徑粗略描述，也可用測繪所得的覆蓋區(qū)域精確描述，而BSC和MSC的覆蓋區(qū)域通過其管理或關聯的基站覆蓋區(qū)域描述。

投訴定位ABE中，客戶報告（Report）客戶投訴，兩者之間是聚合關系，一個客戶投訴關聯一個投訴類型（ComplaintType），基礎地物在投訴定位時起輔助作用，客戶投訴與基礎地物之間沒有直接關聯。

投訴原因分析ABE中，在地理上直接呈現的網絡對象作為分析的起點，但是更深層的原因需要逐步追溯，如從網元追溯到網元告警，再追溯到工程割接。在資源模型中，網元并不需要具備解釋投訴的能力，為了不破壞原有的資源模型，抽象出投訴解釋器（ComplaintExplainer）BE，將網絡對象、網元告警、告警類型、工程割接的BE與投訴解釋器聚合，使其具備投訴解釋能力。投訴解釋器BE以兩種方式解釋投訴，一是面向網維人員的技術解釋（TechExplain），使用技術語言解釋投訴原因；另一是面向客戶的客戶解釋（CustExplain），使用客戶服務語言解釋投訴原因。一個投訴解釋器解釋（CanExplain）一類或多類投訴類型，兩者之間存在關聯關系。

3.3 網絡投訴原因分析模型

對于投訴原因的追溯，采用職責鏈（chain of responsibility）設計模式[8]實現，投訴解釋器具有與自身關聯的一個后繼者（successor），后繼者是隱式的解釋者，沿著后繼者傳遞建立一條解釋鏈，當投訴解釋器接收到解釋請求后，首先檢查自身是否有后繼者，有則將解釋請求轉給后繼者解釋，否則利用自身的接口解釋，沿著解釋連越往后傳遞，解釋的原因越具體。

4條解釋鏈按照優(yōu)先級排序，其業(yè)務含義是：新的網絡投訴產生時，首先查詢其周邊是否有同類投訴，如果有，則沿用原投訴的解釋，統(tǒng)一客戶解釋口徑，并作投訴歸并，否則，查詢其發(fā)生的地理位置是否在信號盲區(qū)、弱覆蓋區(qū)、故障網元覆蓋區(qū)，如果處在某一問題覆蓋區(qū)，則按照解釋鏈追溯解釋原因，如NetElement—NeAlarm—AlarmType—Changeover鏈，最后可能由工程割接聚合的投訴解釋器作出解釋。如果網絡投訴發(fā)生位置同時處在多個問題區(qū)域中，則同時沿著多條解釋鏈進行追溯，追溯出的解釋按照優(yōu)先級排序后由客服人員選擇客戶解釋。如果追溯失敗，則交給網維人員人工分析。

4 基于組件的網絡投訴支撐平臺體系結構

NGOSS在技術上采用基于組件的面向對象分布式系統(tǒng)結構，在eTOM的功能定義的指導下將功能分解為對象和對象接口，通過接口交互實現靈活的應用集成，接口交互可以是面向操作的遠程過程調用和面向數據流的異步消息機制。

根據網絡投訴處理流程，在功能上分解出基礎地物查詢、網絡投訴定位、網絡信息查詢、網絡投訴分析等面向對象的功能組件。在網絡投訴支撐平臺的實現上，因為相關功能主要是由人工驅動而非數據流驅動的，采用面向操作的遠程過程調用的方式提供接口交互。網絡投訴支撐平臺的體系結構如圖4所示。

網絡投訴支撐平臺首先基于企業(yè)服務總線，利用客戶服務服務器、網絡管理服務器、地理數據服務器等各專業(yè)服務器提供的數據服務，構建共享信息/數據服務器，按照網絡投訴支撐BE UML模型的規(guī)范對外提供數據服務。在此基礎上，建立包含各組件的組件服務器，各組件統(tǒng)一發(fā)布到企業(yè)服務總線上，供其他系統(tǒng)集成應用。

5 網絡投訴支撐平臺的實現和應用

參考廣東某移動運營商的網絡管理系統(tǒng)和客服服務系統(tǒng)環(huán)境，對上述網絡投訴支撐平臺進行了構建。采用Oracle數據庫構建了共享信息/數據服務器，實現時對各商業(yè)實體的屬性進行了細化。采用JBOSS服務器構建了組件服務器，并在JavaEE平臺上完成各功能組件的開發(fā)。各功能組件提供了WebService和Serverlet兩種不同的集成接口，分別用于數據集成和門戶集成，在呈現上則采用地理信息系統(tǒng)對投訴位置和網絡信息進行直觀展現?？头障到y(tǒng)通過集成網絡投訴平臺的各個組件實現了網絡投訴分析功能，以下以基站割接導致的客戶投訴為例來說明網絡投訴分析的應用。網維部門計劃于某日對“白馬花園”基站進行割接，并提前1天在網管系統(tǒng)中填寫了基站割接計劃。基站割接時導致該基站覆蓋的白馬花園小區(qū)部分區(qū)域無信號，某客戶事后進行投訴，客服人員接到該投訴后，根據投訴描述地點利用基礎地物查詢功能在電子地圖上找到了投訴位置，并利用網絡投訴定位功能規(guī)范記錄了投訴經緯度位置。接著啟動網絡投訴分析功能，分析結果顯示，投訴描述的時間范圍內，“白馬花園”基站因工程割接產生了斷站告警，“白馬花園”基站在地圖上以警告色高亮顯示，并附注了投訴的解釋口徑。分析結果界面如圖5所示。客服人員根據解釋口徑及時回復客戶，實現一次截單。

6 結束語

本文參考NGOSS的電信運維支撐系統(tǒng)建設思想，以提高移動通信中的網絡投訴客戶感知和投訴處理效率為目標，建設網絡投訴支撐平臺，利用eTOM流程元素構建網絡投訴處理流程，根據流程需求抽象出ABE和BE，并建立了共享信息/數據的UML模型和投訴解釋鏈模型，設計出了技術中立的基于組件的平臺軟件體系結構。最后在某電信運營商的網絡管理系統(tǒng)和客服服務系統(tǒng)環(huán)境構建了網絡投訴支撐平臺，并在客戶服務系統(tǒng)中進行集成應用，實現了網絡投訴的自動分析和一次截單。本文為落實“以客戶為中心”的運維支撐系統(tǒng)建設目標提供了一個最佳的切入點，并為NGOSS思想的實施提供了一個實踐案例。

1 溫熙華.全業(yè)務模式下OSS的建設思路.電信技術，2009（4）:12～17

2 邱雪松.全業(yè)務運營環(huán)境下中國聯通0SS規(guī)劃建議.通信世界 B，2009（22）:14～15

3 TMF.GB921_concepts_and_principles_v8-1，2008

4 盧捍華，王亞石，閔麗娟等.基于NGOSS的OSS/BSS框架.電信科學，2009（10）:57～62

5 張雷.NGOSS新一代電信運營支撐系統(tǒng).通信世界B，2008（1）:23～24

6 TMF.GB922 SID concepts v8.0，2008

7 Gamma E,Helm R,Johnson R,et al.設計模式——可復用面向對象軟件的基礎.李英軍，馬曉星，蔡敏等譯.北京:機械工業(yè)出版社,2005