基于網絡監測系統的感知評估體系設計與實現

方正波，曹龍漢，2，雒江濤

(1.重慶郵電大學通信網與測試技術重點實驗室，重慶 400065;2.重慶通信學院控制工程重點實驗室，重慶 400035)

隨著移動數據業務的不斷豐富，各國運營商在近年來明確提出了對QoE(Quality of Experience)的評估要求。然而對于傳統的感知評估系統只能夠提供粗糙的網絡運營狀況而不能反映用戶的真實感受，更無法結合具體的用戶在使用某項業務時的感知結果。同時，感知結果的量化需要大量的網絡數據和用戶數據做基礎進行建模分析才能得到，并且還要對量化方法的有效性進行不斷的監控和修正，從而得到正確真實的用戶感受［1］。概括來說，就是在基于Web的網絡監測系統在用戶感知評估體系的基礎上建立一個模型與用戶的實際感知結合起來，運維人員可以方便地通過任何瀏覽器快速訪問計算機網絡查詢網絡的運行狀況。用戶感知模塊在網絡監測系統中有著不同尋常的意義，它為運營商準確掌握某項新業務在整個網絡中用戶使用的感知結果分布情況以及全網的感知趨勢分析提供了極大的便利。

1 用戶感知度的新型評估體系

為了獲得終端用戶感知結果，首先要建立一套衡量用戶感知的有效標準，可以通過采用QoE評估體系來實現。與傳統的評估體系相比，評估工作的方向也有所轉變，如圖1所示。

圖1 基于終端用戶感知出發的QoE評估體系

1.1 用戶感知體系結構

QoS(Quality of Service)是衡量網絡服務質量的一種安全機制，QoS的最終目標是提高QoE。常見的一些QoS性能如WAP連接成功率、平均時延等都可以作為衡量用戶感知的指標。因此測量這些指標在某種意義上等同于評估用戶對服務性能的滿意度。然而，鑒于不同的用戶有不同的感知需求，常用的QoS指標卻往往不能完全與用戶的體驗質量相吻合。在選擇QoS指標作為QoE評估體系的組成部分時，應先做詳細的分析，以求達到最大的用戶體驗相關性。QoS實際包含了KQI和KPI兩個方面［2］。

KQI(Key Application Quality Index)關鍵質量指標是一組可以被測量和監控的業務/應用的性能指標，針對不同業務提出的貼近用戶感受的業務質量參數，如網頁打開時延等，主要是從業務應用的層面來看待網絡質量。

KPI(Key Performance Index)是網絡和產品設備的性能指標，可以用不同的測量和統計方法來得到不同的表征KPI，它是整個體系中最底層的可以直接獲得的反映網絡質量的指標。

在QoE用戶感知評估體系的建立過程中，最大的難度在于必須要建立在用戶主觀的滿意度上來構成一個客觀的、可再現的和可操作的體系。運維人員可隨時監測整體網絡真實的用戶感知狀態分布以及進行數據的深度鉆取某些用戶感知結果。

QoE用戶感知的評估體系的基本架構如圖2所示。

圖2 QoE用戶感知評估體系架構圖

從上圖可以看到，實際QoE用戶感知評估體系是一個分層的結構，從直接反映用戶層的主觀感受QoE到業務層表征服務參數KQI的選擇與定義，最后到網絡技術能直接表征指標KPI的層面。

1.2 QoE(QoS)、KQI與 KPI映射關系

真實的用戶感受在評估體系中要有一套準確的映射機制，才能將用戶的真實感受轉化為能夠表征用戶感知的KPI，最后以直觀數據的方式進行評估。

QoE需要相應的業務與網絡QoS作為保證，而相應的業務與網絡QoS以KQI和KPI作為基礎?；赒oE的評估體系是以用戶感知為起點，然后再往下層分解。在分解的過程中，分析出各種應用的KQI以及與底層表征KPI，最終得出QoE、KQI以及KPI之間的對應關系。

在建立了這一套體系之后，評估終端用戶感知就成為一個匯總的過程。將QoE劃分為各類業務應用，確定反映QoE要素的表征KQI及測量方法，業務應用的KQI根據可靠性(Reliability)和舒適性(Comfort)原則進行分類。KQI從最終用戶的角度說明某項業務的服務質量，而不用考慮服務底層的技術方面(協議)或相應的網絡解決方案。

這里的表征KPI不限于信令統計的KPI，為了描述一種感知項，多種測量方法下KPI可以相互補充。現在信令統計的KPI由于更能反映用戶的實際感知，因此正越來越成為一種流行的趨勢［2－4］。

1.3 WEB 應用框架

一套完整的評估體系自然離開不了便利的WEB應用框架用以直觀地呈現數據和圖。基于Java+JS(Ext庫)+HTML語言，采用SSH框架搭建起的B/S應用，使每一層都向另外的層次以一種松散的方式來提供接口，因此開發人員無需考慮底層技術，從而減輕從頭構建持久層代碼的精力，這對客戶端來說更為重要。

通常利用面向對象的方法建立對應的模型，以基本的Java為基礎，編寫基本DAO接口，運用Hibernate框架實現的DAO類來實現數據庫與Java類之間的通信。

Spring是業務層上最流行的框架之一，它是決定如何將對象融合在一起的微容器。Spring允許一種高級的構造器注入(Constructor Injection)形式——對象通過簡單的XML文件進行連接，該配置文件包含對各種對象的引用，完成系統所要求的業務邏輯。

應用上述開發框架，將視圖、模型和控制相對分離，另外還實現了持久層和業務邏輯層的分離。從而無論數據庫怎樣變化也不會對影響到前端，大幅提高了系統的可復用性。由于表現層、業務層和持久層之間的耦合度較小，因此有利于團隊開發。

2 設計與實現

在實現的過程中共有3個步驟組成，即業務感知項的定義、存儲過程以及最后的業務查詢與數據的深度鉆取，而重點和難點也在于如何定義我們所需要的感知項。

2.1 業務感知項的定義

根據用戶感知度新型感知體系首先需要對定義的感知項進行量化，理清QoE—KQI—KPI之間的映射關系，從QoE出發，根據業務應用進行劃分，確定各種業務應用對應的KQI，選取KQI所需要表征的KPI以及權重系數(根據重要性和使用率)，網頁瀏覽所對應的量化如圖3所示。

在QoE評估體系中各個表征KPI的獲得不來自單一的手段，而通常所采用的KQI也并不是客觀存在的，因此根據實際需要定義的業務感知項來確定KPI的組成部分，使得其可行并盡可能接近現實［5］。目前主流的方法主要有兩類:

1)信令采集統計

通過采集網絡中實際發生的信令，獲得基于信令統計的表征KPI指標，例如彩信發送成功率等。由于這種方

圖3 網頁瀏覽量示意圖

式比較能反映用戶實際的感知情況，所以正越來越成為用戶感知QoE測量方式的流行趨勢。

2)網管統計

網管指標來自于全網24×7的數據，因此數據非常的全面詳細，而且能夠彌補信令采集的不足，是個經濟合適的方案。

這兩種測量方式的綜合使用能互補各自的弱點，因此基本能測量各種影響終端用戶感知的因素。這兩種數據源都含有一定的QoE元素，重要的是通過對自身情況的分析，得到一個合適的平衡。

定義分為兩步，定義KPI指標項以及最終的感知項定義。

將信令采集基礎指標、現場測試指標、定義KPI指標項以及最終的定義感知項分別存儲在表T_STAT_SENSE_INDICATORS、T_STAT_SNESE_TEST_INDICATORS、T_STAT_SENSE_KPI和 T_STAT_SENSE_DEF中，其中信令采集基礎指標表和現場測試指標表有對應指標的CDR表名/詳細信息表名和字段，方便在存儲過程中的數據查詢計算。通過 Ext提供的 Ext.tree.DWRTreeLoader類將KPI基礎指標和現場測試等數據生成KPI動態遍歷指標樹，選取需要表征KPI對應的子節點，定義對應指標合適的優秀、合格和客戶容忍值保存在T_STAT_SENSE_KPI表中。

將KPI值換算為百分制，具體的計算公式為

式中:KPI為換算后的百分制對應的得分;E，Q，T分別為定義的優秀值、合格值和客戶能容忍的值;Xreal為KPI測量值。

最后定義感知項，同樣取表T_STAT_SENSE_KPI的指標生成指標樹，選取所需QoE元素經過加權運算后生成QoE計算公式，取合適的優良中差值作為QoE最終感知結果參照值。

式中:N為KQI個數，Wi為對應KQIi權重，n為KPI個數，wi為對應KPIi權重。

具體的感知結果SENSE為

式中:E，W和C為定義的感知值，E＞W ＞C或者E＜W ＜C，視具體情況而定。1，2，3，4分別代表優良中差最終的評估結果。

效果如圖4所示。

圖4 業務感知定義界面(截圖)

2.2 存儲過程

考慮到現網數據量非常大，在此通常采用ORACAL作為數據庫，選取時間粒度為1 h，通過數據庫調度任務機制，每隔1 h對此存儲過程運行一次，定時器設置參數:

Interval= ＞ TRUNC(sysdate，’mi’)+1/(24)

部分參考代碼如下:

'insert into T_STAT_SENSE(

ID，TIMEX，SENSE，KPI，KPIVALUE，IMSI，ACCESSTYPE

)

//將數據插入表T_STAT_SENSE中

select?||to_char(sysdate，'yyyymmddhh24miss')||?||EXCEPTID.NEXTVAL，?||to_char(currentTime，

'yyyy－MM －dd hh24:mi:ss')||?，

//插入對應字段的數據

(case

when d.kpivalue ＞ ='||E||'then 1

when d.kpivalue ＞ ='||E||'and d.kpivalue ＜ '||W||'then 2

when d.kpivalue ＞ ='||W||'and d.kpivalue ＜ '||C||'then 3

when d.kpivalue ＜ ='||C||'then 4

end)as sense，

//根據kpivalue來判斷感知結果

?||DEF_ID||?，d.kpivalue as kpivalue，d.imsi as imsi，d.AN_type from(select imsi as IMSI，'||replaceformla||'as kpivalue，AN_TYPE

from('||sqlstr1||')group by imsi，AN_TYPE

)d';

這里，DEF_ID是感知項的ID，它由系統時間和數據庫序列號發生器拼接，replaceformla是對公式進行處理后得到的值，sqlstr1對不同指標表的聯合查詢語句。

值得注意的是，由于這里是對每個用戶進行評估，從而在實際的現網中每小時生成有數十萬甚至百萬的海量數據，因此建議對T_STAT_SENSE進行按天分表，以提高在后續查詢和鉆取環節中的效率。

2.3 感知結果查詢

感知結果的查詢共有兩個部分組成，全網用戶感知結果分布和某一個感知結果的深度鉆取。全網用戶感知結果分布在一時間段內，以選定周期(1小時/1天/1周/1月)為時間粒度，獲得用戶感知優良中差這4個感知狀態用戶數的分布情況以及在這個時間段內的感知規律曲線。同樣，在數據的深度鉆取時，選取按查看用戶和接入網等方式進行鉆取，從不同角度對數據進行深度挖掘。

3 實現效果

利用FusionCharts插件實現圖形直觀、動態顯示。服務器端選用Tomcat6.0作為Web組件的容器，選用Oracle數據庫。服務器端實現了XML文件的動態生成，能夠快速進行感知項定義查詢，感知結果查詢與鉆取等服務，具體實現效果如圖5所示。

當點擊網格部分的數據，通過內部的邏輯連接，跳轉至相應的頁面并對數據按照不同的方式進行鉆取。

圖5 業務感知查詢界面(截圖)

4 結束語

通過現場測試，充分證明了用戶感知度新型評估體系的真實性和可行性，同時驗證了在SSH框架下對表現層、業務層、持久層開發方案的正確性。這種評估體系直觀、靈活，并實時反映被測網絡運行狀態。但對QoE的量化與權重精確化等還需進一步深入研究。

［1］移動端到端用戶感知評估體系建立與優化［EB/OL］.［2012－06－20］.http://www.mscbsc.com/bbs/thread－318016－1－1.html.

［2］馮國玲，徐旭東.用戶感知評估體系的設計與實現［J］.河北工業科技，2009(3):190－192.

［3］李 榮.淺析移動通信中得用戶感知［J］.電信快報，2008(5):12－15.

［4］熊熙玲，朱巍.QoE——一個不該被遺忘的角落［J］.互聯網周刊，2001(9):95－97.

［5］張文.基于用戶體驗質量設計分組網絡QoS機制［J］.現代電信科技，2004(9):34－36.