基于网络监测系统的感知评估体系设计与实现

2013-08-13方正波曹龙汉雒江涛

电视技术 2013年5期

方正波，曹龙汉，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作为基础。基于QoE的评估体系是以用户感知为起点，然后再往下层分解。在分解的过程中，分析出各种应用的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个感知状态用户数的分布情况以及在这个时间段内的感知规律曲线。同样，在数据的深度钻取时，选取按查看用户和接入网等方式进行钻取，从不同角度对数据进行深度挖掘。