用于生成对基于web的应用的客户体验的洞悉的方法和装置

摘要

提供了能够提供对基于web的应用的用户体验的洞悉和理解的方法、装置和计算机程序产品。一种方法包括收集和测量应用级关键性能指示器，通过监视网络中的网络侧用户业务而检测用户动作，将用户动作与应用级关键性能指示器相关以便评估和量化用户的体验质量（QoE），以及将不良QoE与网络侧关键性能指示器相关以便确定不良QoE的底层根本原因。

说明书

技术领域

实施例一般涉及能够提供对基于web（网络）的应用的用户体验的洞悉（insight）和理解的方法和装置。

背景技术

移动设备技术演进和无线电接入网络的增加的容量已经产生了在移动电话（例如智能电话）上或在平板上使用包括web浏览、社交联网或观看来自视频存储库（例如YouTube?、Netflix?、Hulu?等）的在线视频的基于因特网的应用的机会。这些移动设备的用户具有与可以通过经由高速低等待时间固定网络连接到因特网所实现的相同水平的用户体验的期望。然而，移动无线电接入技术具有一些固有限制，诸如有时狭窄的最后一英里链路、非均匀无线电覆盖和较高的本征等待时间。因此，在整个覆盖区域上提供同类的服务质量是困难（或昂贵）的，尤其是因为由于用户的移动性，需求不是位置约束的。

基于因特网的应用可以经由数据服务（例如通过通用分组无线电服务（GPRS）的分组数据承载、增强数据GSM演进（EDGE）、3G、高速分组接入（HSPA）或长期演进（LTE）无线电接入）而访问内容服务器。原则上，现有系统可以通过其承载中心的服务质量（QoS）架构保证良好的服务质量，所述承载中心的服务质量（QoS）架构包括诸如区分、优先化、分组调度、业务工程、拥塞控制、高速缓存和应用感知解决方案之类的机制；然而，它们仅在规划和定尺寸足够准确、在系统中不存在配置问题或失败、资源未被过量预订、需求不集中在小区域上（例如在公共事件的情况下）或者无线电覆盖在任何地方都处于可接受的水平时有效。

而且，由于不同QoS类的有限数目和众多应用的不同要求，可以由网络提供的QoS是重要的但是不是良好体验质量（QoE）的仅有促成者。除了良好的QoS水平之外，用户体验还可以取决于服务的可用性、控制和信令平面的等待时间、网络元件的处理能力以及在运营商的网络外部的因素，诸如因特网往返时间（RTT）、内容服务器的负载、移动设备的能力等。

因此，提供对流行因特网应用的无缝访问的运营商的能力和拥有用户体验而不仅仅是比特管道的能力被视为关键区分性因素。这要求包括获得对最终用户体验的洞悉、不良用户体验的检测、根本原因分析（诊断）和问题解决的客户体验管理。缺少检测何时和何地用户可能对其应用的质量不满意的能力或者调查底层问题的原因的失败可以造成订户的延长的不满意以及最终增加的流失率（churnrate）和运营商的收入损失。

发明内容

一个实施例针对一种方法，其包括通过应用监视实体收集和测量应用级关键性能指示器。方法还可以包括通过监视网络中的网络侧用户业务而检测用户动作，将用户动作与应用级关键性能指示器相关以便评估和量化用户的QoE，以及将不良QoE与网络侧关键性能指示器相关以便确定不良QoE的底层根本原因。

另一实施例针对一种装置。装置包括至少一个处理器，以及包括计算机程序代码的至少一个存储器。至少一个存储器和计算机程序代码利用至少一个处理器使装置至少收集和测量应用级关键性能指示器，通过监视网络中的网络侧用户业务而检测用户动作，将用户动作与应用级关键性能指示器相关以便评估和量化用户的QoE，以及将不良QoE与网络侧关键性能指示器相关以便确定不良的QoE的底层根本原因。

另一实施例针对一种装置。装置包括用于收集和测量应用级关键性能指示器的构件。装置还可以包括用于通过监视网络中的网络侧用户业务而检测用户动作的构件，用于将用户动作与应用级关键性能指示器相关以便评估和量化用户的QoE的构件，以及用于将不良QoE与网络侧关键性能指示器相关以便确定不良QoE的底层根本原因的构件。

另一实施例针对一种体现在计算机可读介质上的计算机程序。计算机程序被配置成控制处理器以执行过程。过程包括测量应用级关键性能指示器，通过监视网络中的网络侧用户业务而检测用户动作，将用户动作与应用级关键性能指示器相关以便评估和量化用户的QoE，以及将不良QoE与网络侧关键性能指示器相关以便确定不良QoE的底层根本原因。

附图说明

为了本发明的适当理解，应当对附图做出参照，其中：

图1图示了根据一个实施例的框图；

图2图示了描绘根据实施例的工作流的框图；

图3图示了描绘根据一个实施例的操作的四个模式的图；

图4图示了根据一个实施例的用于生成应用级KPI的点的示例；

图5图示了根据实施例的基于DPI探测器（probe）系统的监视的示例；

图6图示了根据实施例的用于检测不完整的下载的方法的示例；

图7图示了根据一个实施例的用于IP2IMSI服务器实现方式的一些替换方案；

图8图示了根据一个实施例的提供数据库的实施例的框图；

图9图示了根据实施例的装置的框图；以及

图10图示了根据一个实施例的方法的流程图。

具体实施方式

移动接入网络的系统资源（例如传输带宽、空中接口、硬件、处理元件）有时不能够向想要使用诸如web浏览、社交联网（例如Facebook^TM）、微博（例如Twitter^TM）或观看在线视频之类的基于因特网的应用的每一个用户赋予令人满意的体验。这可能是由于例如无线电接入技术自身中的限制、不准确的定尺寸和规划假设、非最优配置、无线电覆盖问题、不足硬件容量、有限用户设备（UE）能力、用户的移动性（例如集中在某一位置处的许多活动用户可能生成超过系统容量的需求）等而发生。而且，升级系统以能够在某个有问题的位置处提供充分或至少更好的体验的操纵成本可能仅仅高于所要求的投资的预期回报，使网络运营商不愿实施这样的升级。此外，网络元件的次优或不正确配置或UE或用户的订阅简档的次优或错误配置也可能导致不良的用户体验以及运营商网络外部的一些问题（例如在内容服务器侧的问题）。

基于因特网的应用生成当今移动数据业务中的大部分，并且它们被用户视为应当在它们被需求的任何时间和任何地方都普遍可用的服务；因此，实现关于这些应用的高客户满意度的运营商的能力是必需的。由于甚至在当今前沿的无线解决方案的情况下，并未针对用户可能具有的每一个会话赋予对这些基于因特网的应用的良好访问，因此客户体验管理可以给网络运营商带来明显价值。当今，网络运营商通常能够访问关于诸如承载建立成功率、切换成功率、掉话等之类的网络服务质量测量的报告/仪表板，但是具有对流行的基于因特网的应用的用户体验的非常有限的洞悉或没有该洞悉。

生成应用级洞悉要求应用级业务监视和用于量化用户体验的适合于每一个应用的特定方法，其也考虑到用户的动作（例如如果用户在已经接收到所请求的数据之前已经终止下载）。由本文中的实施例提供的分析框架旨在通过拦截和监视应用业务，生成应用级KPI，评估和量化用户体验以及从不同的角度和聚合水平向应用级用户体验提供高水平和详细视图二者来填补该差距。此外，某些实施例提供将应用级KPI与服务可用性相关KPI相关以便使得能够实现真实客户体验评估和根本原因分析的装置和方法。

为了管理客户体验，需要检测不良的用户体验并且应当定位和诊断问题的原因。本发明的某些实施例描述了一种框架，其引入用于完全从网络侧的数据收集和洞悉生成以便评估和量化用户体验、检测QoE问题、识别和定位受影响的用户并且以不仅对最终用户透明而且在所要求的计算和存储资源方面高效的方式提供诊断的方法和装置。通过在现实网络中部署本发明，自动识别涉及在线应用的问题成为可能，例如定位和识别有问题（例如过长）的网页下载或不良的视频体验的原因。

在运营商已经部署了用于web内容的媒体适配功能的情况下，诸如根据UE的屏幕分辨率或内容演示/回放能力而压缩内容或对多媒体数据（图像、音频、视频等）进行转码（通常从高分辨率朝向低分辨率）的诺基亚西门子网络浏览网关，在其中经适配的业务可用的位置处执行应用级测量可能是必要的，因为其为要被客户端接收的内容。此外，为了判定数据是否可以在起初以充足质量从原始内容服务器下载，可以要求在内容适配之前和在内容适配之后二者监视应用业务。一些实施例可以部署有网络中的不同位置处的多个应用级业务监视实体以便使应用级测量/KPI相关；因此，某些实施例的应用级体验质量评估和根本原因定位能力比在单个测量点的顶部可以实现的更加准确。

为了评估基于web的应用的用户体验，单独依靠要求用户数据传输的应用特定测量可能不是足够的。如果出于各种原因数据传输自身在起初不可能，则受影响的用户已经不满意，但是其通过仅仅聚焦于和从应用层数据传输的性质得到KPI的测量将是不可检测的。如果可以建立基本网络连接性（数据承载）或者UE具有已经建立的数据承载，则实际的应用使用仍旧可能被各种支持传输网络或应用层功能中的失败（诸如DNS解析中的失败、到内容服务器的失败的连接性）所阻止。因此，本发明的某些实施例可以被扩展到通过考虑服务可用性KPI和应用级KPI二者来评估基于web的应用的客户体验。

如以上概述的，本发明的一个实施例提供了一种用于实现分析框架的方法，所述分析框架能够提供对基于web的应用的用户体验的深度洞悉和理解、覆盖从网络连接、承载建立和应用使用开始的应用使用的整个生命周期。框架评估和量化客户体验，识别和定位受不良体验影响的用户并且执行诊断以找出问题的根本原因。分析框架可以依靠在网络连接性和应用使用的各种阶段期间所测量或收集的信息，所述信息通常以关键性能指示器（KPI）的形式提供。基于其在端到端系统架构内的源和它们提供的信息的类型，相关KPI可以被分类到以下三个组中：应用级KPI、服务可用性KPI或网络侧QoS/性能KPI。

应用级KPI基于在数据承载服务的成功建立之后在用户平面业务上执行的测量而生成；这可以包括UE与web/内容服务器之间的连接性建立（例如DNS、TCP）的成功/失败指示以及测量其使用和数据传送期间各种应用的性能和体验。

服务可用性KPI覆盖涉及UE到网络的附着的信令过程，其包括无线电连接性建立、分组数据协议（PDP）上下文的激活和最终建立利用外部分组数据网络（PDN）（诸如因特网）为UE提供连接性和数据服务的数据承载。这些KPI大多是示出信令过程中的某个阶段的成功/失败（包括失败情况中的错误原因）的简单二进制指示器。

网络侧KPI包括关于无线电小区或网络元件（例如eNB/NodeB/RNC等）的信息，其包括但不限于负载、拥塞状态、警报等。关于诸如切换、承载QoS参数重协商等之类的事件的信息也可以是网络侧信息的部分。

除以上KPI之外，框架还可以基于应用级业务监视来检测各种用户动作。例如，一个实施例可以检测到当取消浏览器中的下载时由用户发起的传输控制协议（TCP）连接终止。使用户动作与所测量的应用级KPI相关对于获得对用户体验的更加深度的洞悉是重要的，因为某些反应（在接收到所有内容之前关闭连接，终止但是重启连接或一次又一次地持续重请求相同的内容等），尤其是在它们与经由应用级KPI测量的不良体验相关时，得出用户被不能接收到具有充分质量的内容或者根本不能接收到内容所挫败的合理假设。

框架既是应用驱动的也是服务驱动的。也就是说，可以基于应用级性能（其要求数据服务可用并且用户可以建立数据连接）和提供对具有所有所要求的组成部分（具有低等待时间的数据连接建立、正确的QoS水平、无缝切换、响应系统等）的服务的访问的系统的能力来评估客户体验。网络侧KPI（服务可用性和QoS/性能KPI二者）和事件用于在检测到在应用/服务级的问题和受影响用户被识别和定位之后执行根本原因分析。

一些实施例可以聚焦于但不限于web业务，因为大部分基于因特网的应用通过web（例如使用HTTP/1.1协议）进行访问和操作（通常交互式地），即其可以被视为汇聚层/技术。web业务包括不仅常规web浏览（诸如阅读新闻门户/博客，使用Facebook?、Twitter?、基于web的GoogleMaps?、RSS馈送等）而且还有诸如YouTube?、Netflix?、Hulu?之类的通过HTTP下载多媒体内容的应用和呈现其它音频和/或视频内容的多媒体播放器。web内容下载要求传输控制协议/网际协议（TCP/IP）套件的一些突出协议的适当操作：域名系统（DNS）、用户数据报协议（UDP）、传输控制协议（TCP）、超文本传送协议（HTTP）和甚至用于特定移动视频会话的实时流式传输协议（RTSP）。

根据某些实施例，一个目标是根据以下方案和能力提供深度客户体验管理：

1.识别应用业务和用户行为的重要属性，并且提供用于从正在进行的应用会话收集所要求的信息的高效方法；

2.基于这些属性，识别和生成应用级动态KPI（诸如用于视频下载的ρ和活动因子KPI），其使得能够实现用户体验的可靠评定，包括QoE降级的检测；

3.识别和定位受不良体验影响的订户并且将其置于从网络的各种部分收集的网络级KPI的上下文中以用于根本原因分析；

4.通过监视相关服务可用性相关KPI而捕获最终用户的失败尝试以建立数据连接；

5.生成不同的聚合水平并且提供直接和所得到的KPI的统计分析方法；

6.提供验证框架以核实所识别的应用级KPI的可使用性和性能。

如以上提到的，ρ是应用级KPI的一个示例。在一个实施例中，ρ可以是视频特定KPI并且可以被定义为视频的持续时间（即在没有中断的情况下播放视频所花费的时间）与视频的下载时间（即下载对应视频内容所花费的时间）之比。如果ρ＞1，其可以指示视频内容下载得比其回放的速率（即媒体速率）更快，这意味着在回放中不存在由于缺少数据的中断或冻结，因为在媒体播放器中总是存在一些预缓冲的视频内容。如果ρ＜1，其可以指示存在其中回放由于例如媒体播放器中的缓冲欠载运行（underrun）而冻结的一个或多个时段。该KPI可以在视频内容的下载期间的任何点处连续地计算：当视频仍旧在下载并且仅完整视频内容的某个部分已经从服务器发送并且由客户端接收（由0＜frac＜1表示）的同时，持续时间应当指示仅回放所下载的部分（而非完整内容）所花费的时间；因此，ρ可以计算为：

并且字节长度是视频数据的总大小。计算瞬时（即实时）视频体验仅要求直至给定时间点所下载的视频数据的量在视频的下载期间被连续测量和累积。这可以以轻量的方式完成而不对视频流进行解码或者以任何其它方式窥探内容。由于计算瞬时视频体验的能力，可以针对每一个视频会话记录两个特征ρ值以促进对视频体验的更加深度的洞悉的生成：贯穿整个下载的瞬时ρ的最小值，称为ρ_min，以及在下载的结束处的ρ，称为平均ρ或ρ_avg。当然还可以在每一个视频下载期间记录ρ的附加快照/采样。

通过使ρ_avg和ρ_min与是观看整个视频直到其结束为止（完整下载）还是预先终止它（不完整下载）的用户决策（其也可以在网络侧容易地检测到）相关，视频体验可以被量化成如下的不同水平，以最差的情况开始：

·ρ_avg＜1并且下载不完整（被用户终止）：这意味着视频回放严重受缓冲欠载运行影响，并且用户可能由于因为所请求的内容未以可接受的质量递送所致的不满意而最终终止连接；

·ρ_avg＜1并且下载完成（完全被用户观看）：这意味着尽管回放在某个时间内被冻结，但是用户终究仍旧坚持观看了整个视频；

·ρ_avg＞1并且ρ_min＜1并且下载不完整：这意味着，平均来看，视频以可接受的质量被下载但是存在其中其被短暂冻结的至少一个点；然而，由于ρ_avg大于1，用户在有问题的部分之后继续观看（尽管并未直到结束），因而视频下载的终止可能不是由于质量问题；

·ρ_avg＞1并且ρ_min＜1并且下载是完整的：这意味着平均视频质量是可接受的并且用户观看了整个视频而不管有问题的部分。

应用级KPI的另一示例称为活动因子，其表示在在线视频的下载期间实际数据传送所花费的时间比。活动因子可以视为与ρ互补并且可以针对分裂成多个部分并且利用超文本传送协议（HTTP）逐步下载而下载的视频进行测量，每一个部分要求单独的HTTP请求以被媒体播放器发送，如引言中所讨论的那样。活动因子取0和1之间的值并且被定义为：a）在此期间在视频内容服务器与客户端浏览器/播放器之间发生实际数据传送的时间；和b）在视频传送的开始和结束之间所经过的总时间之比。如果活动因子接近1，这意味着在视频数据部分的下载之间不存在空闲时段或者仅存在短暂的空闲时段，即客户端必须一下载了前一部分就请求下一部分，因为单独的部分的下载速率不太（或者完全不）高于媒体速率。组合ρ和活动因子也是可能的；例如，如果接近1的活动因子与对应的ρ_avg＜1测量一致，这意味着视频会话贯穿整个下载时间是有问题的并且视频播放器不可以在任何点处预缓冲足够的数据以使得推迟下一请求是可能的。如果活动因子相当低于1或者接近0，则这反映出当单独的视频部分的累积下载速率可以保持相当高于媒体速率时的下载。活动因子可以在视频下载已经结束之后计算，因为其要求所有视频部分的下载时间是已知的；另一方面，活动因子极度轻量，因为其计算不要求视频持续时间的知识（并且当然视频内容根本未被解析/解码）。

根据某些实施例，应用级KPI可以在能够访问普通用户业务的任何核心网络元件中测量。从网络管理系统（MMS）（诸如诺基亚西门子网络NetAct）以及业务分析工具（诸如诺基亚西门子网络Traffica）获得服务可用性和网络侧KPI是可能的。NMS（例如NetAct）能够提供关于网络元件的无线电/传输相关配置的信息以及状态信息（例如已启用/活动特征的列表）、可以帮助问题定位的拓扑信息、无线电连接性/PDP激活/承载建立/切换失败统计量等。业务分析工具（例如Traffica）的任务是收集、存储和（向各种网络分析和报告工具）服务关于对应于不同聚合水平（从单独用户直至聚合小区/eNB/RNC/等吞吐量）和不同时间粒度（例如以小时分辨率聚合测量和呈现统计量）的应用使用分布和业务量的信息。一些网络侧QoS和性能KPI也由业务分析工具直接测量和存储，诸如小区无线电负载、传输负载、承载建立成功率、切换统计量等；这些中的一些还可以从NMS可得到。业务分析工具还能够提供诸如数据承载建立、修改或去激活（deactivation）之类的各种事件的实时报告。

可以借助于附着到用户平面或控制平面接口（诸如LTESGi、S1-U或S1-MME）的探测器提供可替换或附加的信息源。特别地，深度分组信息（DPI）探测器不仅能够窥探协议报头而且能够深钻至用户TCP/IP、HTTP和应用数据的级别（倘若内容未被加密）。因此，DPI探测器适合用于执行详细的应用级测量并且因而也生成应用KPI。在探测器系统中，多个探测器可以部署在不同接口上在相同网络中。这可以提供网络中的相同事件的多个测量点，其允许追踪从承载建立到用户平面业务的用户活动并且还允许跟随控制平面信令消息流。因此，DPI探测器系统能够直接提供应用级和服务可用性KPI二者。

应当指出的是，某些实施例可以应用于向用户提供因特网连接性的任何固定或移动系统，因为实施例引入用于通过可以被高效使用的动态KPI集合的客户体验评定而不管接入技术（例如xDSL、WiFi、WiMAX、GPRS、EDGE、HSPA、HSPA+、LTE以及更高）的方法。

如以上概述的，某些实施例提供了一种能够提供对基于web的应用的用户体验的重要洞悉的分析框架。某些实施例被配置成基于监视用户行为/动作、应用级KPI以及可选地服务可用性KPI来评估和量化用户体验。实施例然后可以通过识别和定位受影响的订户以及将其不良体验与网络侧KPI相关来检测QoE降级并且调查问题的根本原因。

一个实施例针对一种用户体验评估的方法，其可以包括测量应用级KPI并且检测用户动作，例如借助于轻量网络侧用户业务监视。方法然后可以将用户动作与应用级KPI相关以便评估和量化用户体验，并且将不良用户体验与网络侧KPI相关以便找出底层根本原因。方法还可以将在应用级检测到的问题链接到订户身份（IMSI）和位置以提供针对运营商服务（诸如客户关怀、市场部门以及网络定尺寸和优化活动）的洞悉。因此，一个实施例提供了用户体验评估（基于应用KPI、所检测到的用户动作和可选地基于服务可用性KPI）、不良QoE检测、用户标识、定位和根本原因分析（基于将应用级、服务可用性和网络侧KPI相关）的该方法。

图1图示了根据一个实施例的框架的框图的示例。根据该实施例的核心框架包括三个实体：应用监视实体（AME）100、IP2IMSI服务器105和分析实体（AE）110，其连接到彼此并且还连接到附加的网络侧数据源，诸如NMS、探测器或业务监视系统115，取决于实际实现方式。因此，由某些实施例提供的解决方案的整体部分与这些工具对接并且在AME100、IP2IMSI服务器105和AE110之间。

在一个实施例中，AME100通过在网络中的某个点处拦截和监视用户平面业务来收集应用级KPI并且检测用户120的对应动作。因此，AME100可以提供反映在良好或不良服务条件下的应用质量和用户行为二者的信息。针对AME100的合适位置包括但不限于运营商的无线应用协议（WAP）/互联网网关（GW），诸如诺基亚西门子网络浏览GW或诺基亚西门子网络Flexi网关平台；网络监视和管理工具，诸如Traffica；运营商前提内的独立HTTP代理服务器，其被配置在订户的浏览器中以使得web业务经由代理访问；3G/HSPA系统中的无线电网络控制器（RNC）；LTE系统中的演进节点B（eNB）；基于DPI探测器系统的拦截；或在不终止任何协议层的情况下嗅探用户平面业务的独立网络元件。

AME100能够访问未经加密的用户平面web业务以使得能够访问协议报头，并且偶然地访问所下载的内容以生成应用级KPI，其被发送（推送）到AE110或使其可用于经由数据库接口的查询。如果web内容适配机制应用于网络中的web业务（诸如实现在NSN浏览GW中的一个），则可能要求监视多个位置处的应用业务（即在内容适配之前和之后二者）以便执行关于实际上被客户端接收的业务的测量并且还能够判定是否起初以充分质量（在时间方面，足够的吞吐量等）从原始内容服务器接收了数据。

根据实施例，AE110基于从AME100接收的应用级KPI和对应用户动作生成对客户体验的洞悉。从该信息，可以评估在成功的数据承载建立之后发起的应用会话。可能甚至由于无线电接入或承载建立连接性过程期间的较早失败而未开始的那些会话在该点处可能未被检测和评估，但是这样的失败通常已经通过其它手段（例如经由仪表板）被收集和呈现给网络运营商。然而，为了适当的客户体验评定，AE110从网络管理系统收集相关KPI。此外，通过测量不同位置处的多个AME100实例中的应用KPI（例如在内容适配的情况中）或分离地对应于外部网络（诸如AME100与基于因特网的内容服务器之间的往返时间）和运营商的网络（诸如网络侧连接建立等待时间或RTT、DNS或TCP失败等）的应用KPI，问题的基本定位也是可能的。例如，该定位可以通过检查有问题的KPI的集合是对应于服务器侧测量还是运营商的网络来完成，因而分离服务器侧和网络侧问题。

该应用驱动的方案是轻量的，因为其仅要求由AME100生成的数据，而没有与来自网络的其它部分的数据源的实时相关，诸如服务可用性或网络侧KPI。而且，AME100中的应用级KPI的生成是可缩放的，因为它们不要求捕获所拦截的应用数据以用于离线分析或执行计算上昂贵且不可缩放的任务，诸如对视频流进行解码。因此，实施例比诸如具有内容适配的HTTP代理（例如NSN浏览GW）之类的已经存在和开发的网络侧解决方案轻得多，所述HTTP代理不仅中继HTTP消息而且必须根据UE能力对多媒体内容进行转码。应用级体验质量评估可以已经通过检测在其他情况下将根本不会揭露的问题（例如经由监视常规KPI，诸如承载建立/切换成功率或掉话）而向运营商提供了大量附加价值。

当由于例如已经负面地影响用户体验的覆盖孔洞或承载建立/PDP上下文激活失败而不能够启动应用时，可以通过将服务可用性KPI添加到用户体验评估的范围中而灵活地扩展以上概述的轻量应用驱动的方案。这要求服务可用性KPI（包括不成功的无线电接入尝试、承载建立失败、切换失败等）从NMS、从业务监视系统或从部署在信令接口（诸如LTE中的S1-MME）上的探测器获得，取决于实现方式。服务可用性KPI的收集及其与应用级KPI的相关可以要求相比于轻量应用驱动的方案更重型的装置，因为两种类型的KPI需要从不同的源收集并且通过AE110联合评估。

基于应用级KPI和用户动作的相关（以及如果收集的话，还包括服务可用性KPI），AE110可以评估和量化不同聚合水平中（在给定小区/eNB/RNC/TA等中，聚焦于单个用户、用户集合或所有用户，考虑不同时间间隔等）的当前QoE。通过针对运营商设置的阈值验证QoE、执行逐日或逐周的趋势分析、识别持续的问题、最受影响的订户或者使用将用户体验与用户的位置、网络状态、不良服务期间的用户行为或任何其它上下文信息组合和相关的任何其他评估方法而分析用户体验的趋势是可能的。

图2图示了描绘根据一个实施例的分析框架的工作流的框图。在实施例中，对于某些操作而言可能要求受不良体验质量影响的订户的标识。例如，可能需要受影响订户的标识以便将在应用级检测到的不良体验质量（KPI和用户动作）与订户的永久身份（例如国际移动订阅标识符（IMSI））链接；这可能是所要求的，因为可自动从业务自身得到的仅有的用户身份是UE的动态生成的移动IP地址，其仅在给定时间对用户唯一并且可以稍后被重分配给另一用户的UE。此外，可能需要受影响订户的标识以准确地定位用户或其中经历不良性能的网络区域（即获得其中用户在不良体验期间正在连接到网络的小区、BTS等）。另外，受影响订户的标识可以用于将从应用级KPI和用户动作得到的用户体验与服务可用性KPI相关。

为了将应用级KPI与永久用户身份相关，临时IP地址可以映射到订户的IMSI。临时IP地址到IMSI的该映射可以由IP2IMSI服务器105基于在数据承载激活期间由网络执行的IP到IMSI绑定而执行。这些绑定是从NMS115（例如Traffica）经由其往返时间（RTT）导出功能收集的或者通过RADIUS协议直接与网络元件之一（诸如网关通用分组无线电系统支持节点（GGSN）/分组网关（PGW）/移动性管理实体（MME））对接地收集的。基于IMSI，可以针对当检测到不良体验时订户位于其中的小区/eNB/BTS/RNC等的身份而查询NMS115。作为结果，可以定位用户。由于在无线电网络侧连接建立、承载管理或移动性事件（切换）等期间从信令消息得到服务可用性KPI，因此它们已经直接包含订户的IMSI以及准确的位置信息（指示其中已经出现问题的无线电小区和/或网络元件）。

给定用户的位置，针对根本原因分析所要求的附加网络侧KPI可以仅从对应于用户位置的NMS115查询。因此，所传送的数据量比将要求网络侧KPI的恒定监视的解决方案少得多并且集中得多。出于性能和可缩放性原因，可能重要的是零星、非持续的用户体验问题不立即触发根本原因分析，从而节约收集、存储和分析网络侧KPI的成本。因此，单个有问题的网页或在线视频下载可能不触发立即的根本原因分析，除非这些问题变得明显、持续或在给定位置处重现、高于目标或涉及对运营商重要的订户（例如非常重要的人、高收入生成者或在真实生活中具有扩展的社交网络和高影响力的那些人）。

诸如重配置之类的自动化动作也可以在框架与操作支持系统（OSS）125集成的情况下触发。此外，可以向运营商的客户关怀提供有价值的信息以能够更好地处理传入的用户抱怨（例如通过具有关于一般水平已知问题或为何特定用户可能不满意的更准确的信息）；市场部门可以检查最近引入（和大量销售）的服务的质量等；具有所检测到的问题的尊贵订户也可以触发自动通知或警告。另一使用情况可以是通过通知适当操作人员或触发自动或半自动工作流来触发某些有问题的情况中的故障检修过程。

基于例如所要求的信息的类型和量、所支持的使用情况和分析框架的能力，其可以根据至少四个操作模式而被配置，如图3的示例中图示的：

1.轻量应用级客户体验洞悉：

该模式可以向独立应用级客户体验评估提供基本诊断能力（例如分离服务器/网络侧问题）。在该模式内，AE110能够提供对在成功的数据承载建立之后开始的应用会话的洞悉。

2.订户标识和定位的实现方式：

可以实现IP地址到IMSI的映射以便将应用级QoE与真实订户身份链接并且用于定位。这还促进查询当在应用级检测到不良用户体验时对用户位置特定的网络侧KPI，其对于根本原因分析可能是所要求的。

3.外加服务级KPI的整体洞悉生成：

除了应用级KPI之外，对于覆盖从无线电附着通过承载建立到应用使用的体验的整体客户体验评估而言可能需要收集服务可用性KPI。该模式使得能够实现高级分析技术，其操作在服务可用性和应用级KPI的合并的数据库上，例如可能检测是否用户体验在应用级上良好但是被不成功的网络连接性或承载建立尝试所超过，这指示尽管有良好的应用级体验，但是用户可能仍旧对该特定应用会话不满意。

4.附加自动化动作：

可能的校正动作、运营商客户关怀或市场部门的通知、故障检修工作流的触发及其实现方式取决于实际OSS环境并且因此可能要求定制和（可能专有的）系统集成。

由AME100提供的客户体验评估和量化可以通过基于用户的反馈机制来核实，例如将由框架计算的QoE与人类测试者的意见相比较。如果在AE110与用户的反馈之间在评估用户体验方面存在差异，可以更新或精炼KPI生成和/或用户体验的量化以更好地匹配用户的意见。可替换地或此外，基于UE的监视应用或插件还可以部署到所选手机以直接监视应用级事件和测量KPI（诸如视频回放冻结、网页下载时间等）并且将其与在网络侧由AME100计算的应用级KPI比较；这不直接验证用户体验而是对在网络侧测量的应用级KPI准确地反映在UE侧的事件进行核实。

在一个实施例中，AME100处的应用级KPI的生成和用户动作的检测可以通过在应用活动期间拦截/监视用户平面数据流来促进。这可以以各种方式实现。图4图示了用于生成AME100中的应用级KPI的可能点的一些示例。在图4的示例中，四个可替换位置可以用作拦截点，其中AME100可以被集成以生成应用级KPI。例如，AME100可以集成在以下中：（a）核心网络元件，诸如PGW400（在LTE中）或者在GGSN405（在3G/HSPA/HSPA+系统中）中；（b）因特网GW/WAPGW/HTTP代理410；和/或（c）独立嗅探器420；（d）在诸如无线电网络控制器（RNC）或演进的节点B（eNB）之类的无线电接入网络元件中。根据实施例，独立嗅探器节点420不终止任何协议层（如与终止TCP连接的HTTP代理相反）。基于代理的实现方式在其中代理执行web内容适配的情形中可以是优选的，因为在该情况中原始和经适配的内容二者在相同的网络元件中是可用的。

对以上结合图4讨论的AME100的基于网络元件的实现方式的替换方案是基于深度分组检查（DPI）探测器系统的监视。图5图示了基于DPI探测器系统的监视的示例，其包括将DPI探测器附着到其中用户平面数据流可用的各种网络接口，诸如3G/HSPA/HSPA+系统中的Gn/Gi接口或LTE系统中的S1-U/SGi接口。如图5的示例中图示的，探测器i可以附着在MME510和GGSN/PGW500之间的接口上，探测器j可以附着在安全GW520和GGSN/PGW500之间的接口上，并且探测器k可以附着在GGSN/PGW500与防火墙/NAT/外部PDN530之间的接口上。在一个实施例中，可能要求对未经加密的用户数据的访问，这意味着探测器可以被部署在其中普通用户平面数据流可访问的接口上（例如在下行链路中在安全网关之前，如果存在这样的网络元件的话）。

通过监视应用业务，AME100能够测量和生成应用级KPI；这些包括涉及DNS或TCP的连接性问题，测量DNS名称解析的等待时间或建立TCP连接，测量TCPRTT及其变化、HTTPRTT、HTTP对象的下载时间以及访问从DNS、IP、TCP和HTTP协议报头可得到的任何信息，诸如HTTP对象的内容类型或大小。通过监视发送到客户端的TCP数据段和客户端发送回的TCP确认（ACK），跟踪客户端已经没有错误地接收的数据量是可能的（即确认的字节数目）。而且，通过监视由客户端TCP接收器报告的公告的窗口大小，可以检测客户端侧应用是否不消耗数据（尽管数据由网络及时递送），或者应用可能仍旧接收了更多数据。这些测量可以被AE110利用以便检测客户端自身是否限制可实现的用户体验（例如通过不能够处理所接收的数据）或者是否网络（或内容服务器）未以良好用户体验所要求的速率递送数据。

根据实施例，AME100还能够直接检测所下载的内容的类型或类别（基于其可以识别并且在用户体验评估期间使用其重要性）并且还可以检测某些用户动作并且将该信息连同应用级KPI一起传达给AE110。由于用户终止所致的不完整的下载可以以至少两种方式来检测，这二者可以被实现以使检测更加鲁棒。图6图示了根据一个实施例的用于检测用户已经中断HTTP对象的下载的方法的示例。第一方法是测量在相同TCP连接中在从HTTP服务器610发送到浏览器600的HTTP响应报头之后接收到的字节数目，并且检查内容长度字段是否匹配所测量的数据。如果所测量的数据小于内容长度字段中所指示的量并且用户已经关闭连接（即首先发送TCP结束（FIN）），这是用户中断的下载的指示。附加方法是查找TCP结束（FIN）和具有由客户端设置的重置（RST）标志的后续TCP段；RST标志指示客户端已经在没有接收到由服务器发送的所有数据的情况下突然关闭TCP连接。

由AME100测量/检测的应用级KPI和用户动作可以由UE的动态IP地址识别。然而，如以上所讨论的，订户标识、问题定位和根本原因分析可能全部要求临时IP地址被映射到永久IMSI。图7图示了用于IP2IMSI服务器105实现方式的两种替换方案。在图7的示例中，IP2IMSI服务器105可以（a）在业务分析工具（例如用于FlexiNG的Traffica）的顶部上实现；或者（b）经由通过RADIUS协议连接到GGSN/PGW/MME700来实现。

基于业务分析工具（例如Traffica）的实现方式可以利用被包括在无论何时数据承载（例如PDP上下文）被激活、修改或去激活时由业务分析工具生成的会话承载RTT报告中的信息。一个这样的报告包含一组参数，其包括承载和订户身份、网络元件身份和QoS参数；最重要地，在报告被数据承载创建（即PDP上下文激活）触发的情况下，分配给UE的动态IPv4/IPv6地址和订户的永久IMSI二者被包含在会话承载RTT报告中。IP2IMSI服务器105可以经由称为Traffica适配器的功能通过RTT导出机制收集这些报告（例如通过FTP接收数据），例如在图7中，其从报告中提取IP地址和IMSI并且将其连同承载创建事件的时间戳（携带在会话承载RTT报告的Fng_Bearer_Bearer_Creation_Date/Time字段中）一起存储在数据库710中。在实施例中，数据库710由IP2IMSI服务器105所有，其实现用于基于IP地址和时间戳查找IMSI的查询接口并且返回所供给的IP地址在给定时间绑定到的IMSI。在数据库中连同IP到IMSI映射一起存储时间戳使得能够正确地解析对应于例如较旧测量或应用级KPI的IP地址，即使IP地址已经被重分配给另一UE。

对基于业务分析工具（例如Traffica）的实现方式的替换方案是通过RADIUS协议连接到GGSN/PGW700或直接连接到MME并且基于UE的动态IP地址检索订户标识符（国际移动订阅标识符（IMSI）、国际移动设备标识符（IMEI）、移动站国际订户目录号（MSISDN））。在该实施例中，如图7中图示的，称为RADIUS模块720的实体被提供并且能够操作为RADIUS服务器或RADIUS代理。在RADIUS服务器模式中，模块720从GGSN/PGW/MME700接收RADIUS认证和计费消息，提取订户标识符，创建有效RADIUS响应并且将其返回到GGSN/PGW/MME700。在RADIUS代理模式中，所接收的RADIUS消息在GGSN/PGW/MME700与外部RADIUS服务器730之间转发。在任何情况中，所获得的IP和IMSI身份被报告给IP2IMSI服务器105以连同接收到第一RADIUS消息的时间戳一起存储在映射数据库中。

基于业务分析工具（例如Traffica）的标识的优点不仅在于可以从会话承载RTT报告提取用户身份而且在于经由相同报告（在括号中示出）的以下字段直接提供用户的定位：

·小区ID（用于2G/GPRS的Fng_Bearer_Cell_Id和用于LTE的Fng_Bearer_eCell_Id）；

·LAC/RAC/SAC/TAC（Fng_Bearer_LAC/RAC/SAC/TAC）；

·eNB身份（用于LTE的Fng_Bearer_eNodeB_IP_Address）；

·MME身份（用于LTE的Fng_Bearer_MME_IP_Address）；

·PGW/SGSN身份（Fng_Bearer_PDN_GW_GGSN_Control/User_Plane_IP_Address）；

·SGW身份（用于LTE的Fng_Bearer_Serving_GW_Access_User_Plane_IP_Address）；

·无线电接入技术（Fng_Bearer_Radio_Access_Technology）。

使用订户标识的基于RADIUS的实现方式，定位步骤可能需要通过附加方法完成，可能地经由NMS。另一方面，基于RADIUS的实现方式不要求业务分析工具（例如Traffica）被部署在运营商的网络中。

图8图示了用于创建具有用于服务可用性和应用级KPI的IMSI密钥（key）的公共数据库810的实施例的框图。根据一个实施例，由AME100生成的应用级KPI和用户动作可以被收集在数据库中，所述数据库可以由AE100查询以执行分析过程。数据库可以具有不同级，诸如由UE的临时IP地址索引的初始原始数据库800和作为借助于通过IP2IMSI服务器105将IP映射到IMSI的原始数据库的变换的合并数据库。为了提供真实用户体验评估，除应用级KPI和用户动作之外，某些实施例还可以收集涉及网络附着、承载建立、移动性等的服务可用性KPI。某些实施例甚至可以创建用于存储从业务分析工具（例如Traffica）收集的服务可用性KPI和由AME100生成的应用级KPI二者的公共数据库810，如图8中图示的。在传送至公共数据库810之前，应用级KPI的IP密钥基于来自IP2IMSI服务器105的查询而被映射到IMSI密钥，而已经具有IMSI密钥的服务可用性KPI可以在没有改变的情况下传送。从单独的原始数据库800传送至公共数据库810的数据可以从对应的单独数据库中删除。

可替换地，在某些实施例中，服务可用性KPI甚至可以被初始收集在公共数据库810中，从而消除对于临时原始数据库800的需要；然而，在该实施例中，仅可以在公共数据库810被托管在靠近网络元件（例如对应的Traffica网络元件服务器）的节点处时确保高性能，服务可用性KPI在所述网络元件处生成。

基于部署的特定类型，AE110查询包含应用级KPI和用户动作的数据库，或者在其中还收集服务可用性KPI的情况中，AE110可以直接查询公共数据库810。当存在由服务可用性KPI捕获的网络连接性阶段期间的失败指示（无线电附着、承载建立失败等）时，其按定义被视为不良用户体验而不管用户想要使用的特定应用如何（其不能已知），因为对于用户而言根本不可能开始使用应用。类似地，从应用级KPI可得到的在应用级的连接性失败（DNS查找失败、TCP连接问题等）也可以同样被视为不良的用户体验，在它们出现在连接性过程的早期阶段处从而防止应用使用时或者在它们在应用的实际使用期间较晚出现二者时。如果应用可以成功地启动并且数据被传送，AE110基于将用户的动作和应用级KPI（由AME100测量的）相关来量化用户体验，诸如用于视频下载的ρ和活动因子KPI、DNS查找的等待时间、TCP连接建立的等待时间、客户端侧和服务器侧HTTPRTT、HTTP对象的下载时间等。

通过将用户动作与应用体验质量相关，可以定义不同的客户体验类别。例如，最差类别可以对应于网络连接性阶段（承载建立）期间或者稍后在应用使用（DNS、TCP、HTTP）期间体验到明显失败，其是直接从服务可用性和应用级KPI可检测的。另一方面，最佳类别可以对应于成功的连接性（承载建立和应用级二者）和由应用级KPI测量的良好体验。在最差和最佳类别之间，即在其余（并非不重要）情况中，可以基于由应用级KPI和用户的动作提供的体验的粒度创建不同的附加类别。一般地，相同的体验质量（即相同的应用KPI）应当被视为在用户的动作指示失望的行为的情况下更差。这样的用户动作可以包括在所请求的数据被下载之前终止连接、一次又一次地重复重请求相同的内容、终止和重建立网络连接性（承载）等。

用户体验评估还可以考虑给定订户所习惯于的通常质量。换言之，可以检查用户的体验与其自身的历史相比是否已经被降级。合理的是，这样的情况由于质量改变的方向（即降低）的心理效应而使用户不满意，即使对应于降低的质量的客户体验类别将不被视为特别差。事实上，可以存在其所习惯的质量不那么好的其他用户，并且因此对于这些用户，相同的体验将根本不被视为相对不良。出于基准目的，可以存储针对给定用户和/或在给定位置和/或在一天中的给定时间等测量的最佳体验质量以评定系统可以提供的最大可实现质量。应当指出的是，用户特定基准还可以并入终止限制，而系统范围基准由于移动设备的多样性而不表现出该偏见。

可以通过对用户已经使用/请求的应用/内容进行分类来进一步详述起初的用户体验的量化或不良用户体验的影响。可以标识各种类，诸如：仅仅用于闲暇活动或打发时间的内容或应用（例如在线音乐、Last.fm等）；规律地使用但是不重要的应用（诸如Facebook?、Twitter?等）；以及重要的服务，其在被请求时必须立即可用并且没有错误，否则它们几乎不可避免地导致严重的失望（诸如在线地图、飞机/火车的时间表、政府页面、医学或教育机构、web商店等）。大部分内容或应用的类别可以容易地由AME100基于内容服务器名称来识别，其被包括在网页的URL中（例如用于GoogleMaps的“maps.google.com”、用于Facebook?的“*.facebook.*”或“*.fb.*”等）。针对每一个类别构建匹配模式（通配符、正则表达式等）的列表使得能够快速分类内容或应用。同样，在某些实施例中，其仅可以使用在其中体验不良好以减少处理的情况中。然而，构建关于受访内容类型和对应体验的每个用户统计量也是可能的，并且可以是对于流失预测的有价值的洞悉，因为具有关于重要应用或内容的增加的不良体验的用户更可能切换运营商。

将不良的应用体验质量和指示不满意/失望的用户动作与网络侧KPI相关（在定位受影响用户之后）以便找到根本原因。如以上讨论的，网络侧KPI可以提供关于系统的操作的信息，诸如小区的无线电负载、传输节点的拥塞状态、切换问题、硬件负载/状态、警报等。不良用户体验背后的（一个或多个）最合理的根本原因可以由框架以不同方式暗示。例如，当不良QoE与网络侧奇怪状态（例如非常高的负载、拥塞、已知HW/无线电覆盖限制等）的清楚指示、影响用户的切换问题、承载QoS重协商、UE的有限能力等一致时，其很可能是QoE问题的原因。而且，通过记录人工/半人工故障检修会话期间的根本原因以及由决策做出过程检查以进入诊断的对应KPI，某些实施例可以稍后针对这些所记录的模式匹配相同KPI的当前状态以暗示在先前诊断的类似情况下发现的根本原因。

根据实施例，AE110还可以检查UE能力起初是否使得能够实现无缝应用使用。例如，如果IMEI标识具有低处理能力和由于有限编码和调制能力所致的窄的可实现带宽的设备，尝试以高清晰度观看YouTube^TM视频将由于设备自身而是有问题的。为了找出UE设备是否是瓶颈，某些实施例监视在不同协议层上由AME100收集的UE的反馈，诸如TCPACK率、TCP公告的窗口大小等。基于这些测量，AE110可以检测客户端应用（例如YouTube^TM插件或应用）是否不能够从TCP接收缓冲器读取所下载的数据因而应用自身是瓶颈（由客户端发送的TCPACK中的减小或最终为零的公告的窗口大小指示）。如果UE限制被清楚地指示，某些实施例甚至可以跳过其它网络侧KPI的更昂贵的收集和相关，因为诊断是UE限制自身。对于交叉验证，这样的发现可以对照设备的IMEI来检查，就像是其指示强大的新型号UE那样，UE限制的征兆是测量错误（仅在罕见地发生并且不与给定订户相关的情况下可能）或可以甚至指示设备误配置，如果针对给定用户频繁检测到的话。

UE侧限制可能不仅源自设备自身而且来自其固件、操作系统（OS）或用于访问web的特定浏览器类型和版本。在客户体验的评估期间检查特定固件、OS、浏览器等的已知限制、问题或程序错误（bug）提供上下文信息，所述上下文信息可以用于评定用户体验自身和用于发现不良体验的原因二者，诸如当由用户运行的浏览器的特定版本已知为具有再现问题或已知为不能够播放用户所请求的YouTube^TM视频的类型（诸如Flash/HTML5）时。检测OS/浏览器类型和版本通过解释由客户端应用发送的HTTP请求消息的HTTP用户代理字段而是可能的，而固件版本是IMEI号码的部分。固件、浏览器和操作系统的已知限制可以还从诸如技术审阅或基准测试结果（仅适用于最新和/或最流行的型号）之类的web/出版社出版物收集和经由通过收集可以最频繁地与不良质量应用会话相关联的设备/OS/浏览器类型和配置的统计评估二者来收集。

除了UE能力之外，可以检查设备配置以及还有用户的订阅简档，因为这些也可以限制可实现的体验质量（例如某些订阅包在可实现的带宽上施加约束）。此外，即使订阅允许使得能够实现良好用户体验的所要求的服务质量，网络也可能不能够建立具有所要求的QoS设置的数据承载（例如由于临时过载等）。判定不良用户体验的原因是否是以上问题中的一个，AE110可以检查其中传送应用数据的数据承载的QoS参数（可用作服务可用性KPI的部分）并且还可以通过使用RADIUS/Diameter协议之一或在基于One-NDS的HSS实现方式的情况中使用轻量目录访问协议（LDAP）查询而与归属位置寄存器（HLR）/归属订户服务器（HSS）对接来检查用户的订阅简档。来自运营商的关于诊断质量的反馈可以被考虑到以精炼根本原因分析。

针对用户体验评估存在的最新方法通常通过在均匀尺度上（例如从1到5）单独评估某些QoS测量并且计算其加权平均（利用分析或实验校准模型所定义的权重）作为总体得分或者在一个或多个QoS输入参数（诸如网页的下载时间、在视频回放期间的停滞事件的数目或持续时间等）上应用对数或负指数公式而产生总体得分或索引（例如平均意见得分），其基于若干输入参数的组合和聚合。关于这样的评估的一个问题是一旦已经计算了得分或索引，其不携带如何和为何给出得分的特定值并且贡献于该值的元素是什么的指示；因此，深钻和分析在一般或在给定特定情况下基于其的评估导致不良体验的最常见分量是什么也是不可能的。这同时还使根本原因分析更加复杂，因为得分不给出关于问题的可能位置的任何提示。而且，这样的评估是刚性的，因为其均匀地应用于所有用户会话并且不考虑给定用户习惯于的通常体验或同时使用网络的其他人的体验、最终设备的能力、所请求的内容的类型等。

虽然本文所描述的实施例还可以在其有意义时利用类似于得分的度量（例如通过使ρ与用户的动作相关，可能生成针对视频的得分），这些仅表征来自特定方面的体验并且它们仅是对用户体验的评估的贡献者，其还考虑更多的附加方面，诸如所有应用级KPI、内容类型、用户习惯于的其自身体验、同时的其他用户的体验、网络基准、UE能力等。所有这些可用于评估体验并且还用于根本原因分析，因为它们未聚合成单个得分。因此，某些实施例能够深钻和分析为何给定会话被评估为不良、识别对于用户、应用或在给定客户体验类别内最频繁的问题（如果仅高级分类可用的话这将是不可能的）。另一方面，用户（即网络运营商）不必被呈现有所有这些细节以便具有网络中的用户体验的概览，因为实施例能够生成对在最高级（例如所有业务经过相同GW）开始的不同聚合水平的用户体验的洞悉，其然后可以缩窄到特定用户、订阅类别、应用、位置、网络元件、小区等。然而，还重要的是，聚合不应当隐藏在较低水平之一表达的但是仅对应于总体业务内的较小份额（并且因此可能不可见）的问题，例如如果99%的会话被评估为具有良好体验但是其余1%全部来自相同的少数小区，其可以指示局部问题。为了捕获这些情况但是仍旧不利用细节使运营商过载，可以在每一个聚合水平处收集最有问题的应用、用户、网络元件等并且将其呈现为仪表板。

图9图示了根据实施例的装置10的示例。应当指出的是，本领域普通技术人员将理解到，装置10可以包括图9中未示出的组件或特征。在图9中仅描绘了对于本发明的说明而言必要的那些组件或特征。在一个实施例中，装置10可以是网络元件。例如，装置10可以实现为AME100和/或AE110，如以上讨论的。

如图9中图示的，装置10包括用于处理信息和执行指令或操作的处理器22。处理器22可以是任何类型的通用或专用处理器。虽然在图9中示出单个处理器22，但是根据其它实施例，可以利用多个处理器。事实上，作为示例，处理器22可以包括通用计算机、专用计算机、微处理器、数字信号处理器（DSP）、现场可编程门阵列（FPGA）、专用集成电路（ASIC）和基于多核处理器架构的处理器中的一个或多个。

装置10还包括存储器14，其可以耦合到处理器22，以用于存储信息和可以由处理器22执行的指令。存储器14可以是一个或多个存储器并且具有适合于本地应用环境的任何类型，并且可以使用任何合适的易失性或非易失性数据存储技术实现，诸如基于半导体的存储器设备、磁性存储器设备和系统、光学存储器设备和系统、固定存储器和可拆卸存储器。例如，存储器14可以包括随机存取存储器（RAM）、只读存储器（ROM）、诸如磁盘或光盘之类的静态存储装置或任何其它类型的非暂时性机器或计算机可读介质的任何组合。存储在存储器14中的指令可以包括程序指令或计算机程序代码，其在由处理器22执行时使得装置10能够执行如本文所描述的任务。

装置10还可以包括用于向装置10发射和从装置10接收信号和/或数据的一个或多个天线25。装置10还可以包括被配置成发射和接收信息的收发器28。例如，收发器28可以被配置成将信息调制到载波波形上以供（一个或多个）天线25传输并且解调经由（一个或多个）天线25接收的信息以供装置10的其它元件的进一步处理。在其它实施例中，收发器28可以能够直接发射和接收信号或数据。

处理器22可以执行与装置10的操作相关联的功能，包括但不限于天线增益/相位参数的预编码、形成通信消息的各个位的编码和解码、信息的格式化以及装置10的总体控制，包括涉及通信资源的管理的过程。

在实施例中，存储器14存储在由处理器22执行时提供功能的软件模块。模块可以包括例如提供用于装置10的操作系统功能的操作系统。存储器还可以存储一个或多个功能模块（诸如应用或程序）以提供用于装置10的附加功能。装置10的组件可以以硬件来实现，或者实现为硬件和软件的任何合适的组合。

在实施例中，装置10可以由存储器14和处理器22控制成例如通过监视网络侧用户业务测量和/或生成应用级KPI并且检测用户动作。装置10然后可以由存储器14和处理器22控制成将用户动作与应用级KPI相关以便评估和量化针对应用的用户的QoE。装置10还可以由存储器14和处理器22控制成将针对用户的不良QoE与网络侧KPI相关以便确定不良QoE的底层根本原因。在实施例中，装置10由存储器14和处理器22控制成将在应用级检测到的不良QoE链接到订户身份和位置以例如向运营商提供洞悉。根据一个实施例，装置10还可以由存储器14和处理器22控制成将从应用级KPI和用户动作得到的QoE与服务可用性KPI相关。

图10图示了用于测量和提供对在使用应用中用户的体验质量的洞悉的方法的流程图的示例。方法可以包括，在900处，例如通过监视网络侧用户业务而测量和/或生成应用级KPI。方法还可以包括，在910处，检测用户动作，以及在920处，将用户动作与应用级KPI相关以便评估和量化针对应用的用户的QoE。方法还可以包括，在930处，将针对用户的不良QoE与网络侧KPI相关以便确定不良QoE的底层根本原因。方法还可以包括，在940处，将在应用级检测到的不良QoE链接到订户身份和位置从而向运营商提供关于用户的QoE和不良QoE的底层原因的洞悉。根据一个实施例，方法还可以包括，在950处，将从应用级KPI和用户动作得到的QoE与服务可用性KPI和网络QoSKPI相关。

在一些实施例中，本文所描述的任何方法的功能可以通过存储在存储器或其它计算机可读或有形介质中并且由处理器执行的软件实现。在其它实施例中，功能可以由硬件执行，例如通过使用专用集成电路（ASIC）、可编程门阵列（PGA）、现场可编程门阵列（FPGA）或硬件和软件的任何其它组合。

本发明的所描述的特征、优点和特性可以以任何合适的方式组合在一个或多个实施例中。相关领域技术人员将认识到，本发明可以在没有特定实施例的一个或多个具体特征或优点的情况下实践。在其它实例中，可以在可能未在本发明的所有实施例中呈现的某些实施例中认识到附加特征和优点。

本领域普通技术人员将容易理解到，如以上讨论的本发明可以利用以不同次序的步骤实践，和/或利用以不同于所公开的那些的配置的硬件元件实践。因此，尽管已经基于这些优选实施例描述了本发明，但是对本领域技术人员将显而易见的是，某些修改、变化和替换构造将是显而易见的，而保持在本发明的精神和范围内。为了确定本发明的边界和界限，因此应当对随附权利要求做出参考。