基于NGOSS的移動(dòng)通信網(wǎng)絡(luò)投訴支撐平臺(tái)研究*

郭建華，向 華

（1.廣東技術(shù)師范學(xué)院計(jì)算機(jī)科學(xué)學(xué)院 廣州510665；2.億陽(yáng)信通股份有限公司 北京100093）

1 引言

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

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

2 端到端的網(wǎng)絡(luò)投訴處理流程

eTOM流程框架是電信運(yùn)營(yíng)流程向?qū)У乃{(lán)圖，采用多級(jí)視圖和矩陣結(jié)構(gòu)對(duì)電信企業(yè)運(yùn)營(yíng)流程進(jìn)行了規(guī)范描述。eTOM通過三級(jí)視圖對(duì)電信運(yùn)營(yíng)流程元素提供了詳盡的列表，并且提供了端到端業(yè)務(wù)流程的部分流程樣例[6]。因?yàn)楦鱾€(gè)運(yùn)營(yíng)商的管理流程差異很大，eTOM的主要價(jià)值并非其流程樣例，而在于指導(dǎo)電信企業(yè)利用流程元素構(gòu)建具體的端到端業(yè)務(wù)流程。

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

端到端的網(wǎng)絡(luò)投訴處理流程跨越3個(gè)水平流程組：市場(chǎng)、產(chǎn)品和客戶，服務(wù)，資源，流程步驟描述如下：

（1）客戶感知網(wǎng)絡(luò)服務(wù)問題并報(bào)告給客服人員；

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

（3）“服務(wù)問題管理”流程通過“資源故障管理”進(jìn)行資源層問題分析；

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

（5）客服人員根據(jù)返回的投訴解釋回復(fù)客戶投訴，網(wǎng)絡(luò)投訴處理終結(jié)。

網(wǎng)絡(luò)投訴處理流程雖然比較簡(jiǎn)單，卻反映了實(shí)現(xiàn)流程自動(dòng)化時(shí)橫向?qū)用娴南到y(tǒng)融合，引導(dǎo)出了網(wǎng)絡(luò)投訴支撐平臺(tái)的系統(tǒng)需求，網(wǎng)絡(luò)投訴支撐平臺(tái)著重實(shí)現(xiàn)網(wǎng)絡(luò)運(yùn)維信息和專業(yè)知識(shí)的共享，以支撐網(wǎng)絡(luò)投訴的規(guī)范描述和自動(dòng)分析?？头藛T利用網(wǎng)絡(luò)投訴支撐平臺(tái)，能夠快速定位投訴原因，提高投訴一次完成率，提升客戶感知；同時(shí)對(duì)投訴進(jìn)行規(guī)范描述和初步歸并，提高網(wǎng)維部門的投訴處理效率。

3 網(wǎng)絡(luò)投訴支撐平臺(tái)的共享信息/數(shù)據(jù)模型

3.1 網(wǎng)絡(luò)投訴支撐的可聚合商業(yè)實(shí)體

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

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

與此相對(duì)應(yīng)，定義如下ABE：投訴定位（ComplaintLocation）ABE、網(wǎng)絡(luò)信息查詢（NetInfoQuery）ABE、投訴原因分析（ComplaintAnalysis）ABE。

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

網(wǎng)絡(luò)信息查詢ABE：屬于資源域，根據(jù)某一地理位置，查詢周邊區(qū)域（一般以基站覆蓋半徑范圍為基準(zhǔn)）的相關(guān)網(wǎng)絡(luò)信息。

投訴原因分析ABE：屬于資源域，根據(jù)投訴周邊區(qū)域的網(wǎng)絡(luò)信息進(jìn)行分析，找出可能的投訴原因。

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

3.2 網(wǎng)絡(luò)投訴支撐的商業(yè)實(shí)體UML模型

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

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

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

投訴定位ABE中，客戶報(bào)告（Report）客戶投訴，兩者之間是聚合關(guān)系，一個(gè)客戶投訴關(guān)聯(lián)一個(gè)投訴類型（ComplaintType），基礎(chǔ)地物在投訴定位時(shí)起輔助作用，客戶投訴與基礎(chǔ)地物之間沒有直接關(guān)聯(lián)。

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

3.3 網(wǎng)絡(luò)投訴原因分析模型

對(duì)于投訴原因的追溯，采用職責(zé)鏈（chain of responsibility）設(shè)計(jì)模式[8]實(shí)現(xiàn)，投訴解釋器具有與自身關(guān)聯(lián)的一個(gè)后繼者（successor），后繼者是隱式的解釋者，沿著后繼者傳遞建立一條解釋鏈，當(dāng)投訴解釋器接收到解釋請(qǐng)求后，首先檢查自身是否有后繼者，有則將解釋請(qǐng)求轉(zhuǎn)給后繼者解釋，否則利用自身的接口解釋，沿著解釋連越往后傳遞，解釋的原因越具體。

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

4 基于組件的網(wǎng)絡(luò)投訴支撐平臺(tái)體系結(jié)構(gòu)

NGOSS在技術(shù)上采用基于組件的面向?qū)ο蠓植际较到y(tǒng)結(jié)構(gòu)，在eTOM的功能定義的指導(dǎo)下將功能分解為對(duì)象和對(duì)象接口，通過接口交互實(shí)現(xiàn)靈活的應(yīng)用集成，接口交互可以是面向操作的遠(yuǎn)程過程調(diào)用和面向數(shù)據(jù)流的異步消息機(jī)制。

根據(jù)網(wǎng)絡(luò)投訴處理流程，在功能上分解出基礎(chǔ)地物查詢、網(wǎng)絡(luò)投訴定位、網(wǎng)絡(luò)信息查詢、網(wǎng)絡(luò)投訴分析等面向?qū)ο蟮墓δ芙M件。在網(wǎng)絡(luò)投訴支撐平臺(tái)的實(shí)現(xiàn)上，因?yàn)橄嚓P(guān)功能主要是由人工驅(qū)動(dòng)而非數(shù)據(jù)流驅(qū)動(dòng)的，采用面向操作的遠(yuǎn)程過程調(diào)用的方式提供接口交互。網(wǎng)絡(luò)投訴支撐平臺(tái)的體系結(jié)構(gòu)如圖4所示。

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

5 網(wǎng)絡(luò)投訴支撐平臺(tái)的實(shí)現(xiàn)和應(yīng)用

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

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

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

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

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

3 TMF.GB921_concepts_and_principles_v8-1，2008

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

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

6 TMF.GB922 SID concepts v8.0，2008

7 Gamma E,Helm R,Johnson R,et al.設(shè)計(jì)模式——可復(fù)用面向?qū)ο筌浖幕A(chǔ).李英軍，馬曉星，蔡敏等譯.北京:機(jī)械工業(yè)出版社,2005