CN107667504A - 使用回声定位进行用户体验质量的分析 - Google Patents

Abstract

本文描述的技术涉及对客户端设备体验质量诊断文件的分析，该客户端设备体验质量诊断文件包括客户端设备的操作日志或诊断文件。客户端设备体验质量诊断文件可以由客户端设备生成并发送到网络节点进行分析。可以分析诊断文件，以确定设备的关键性能指示符和设备的体验质量，并且确定导致降级的体验质量的网络问题(例如掉话)的根本原因。在一些实施例中，诊断文件可以被聚合，以形成聚合诊断的数据库，其可以用于进一步分析网络以确定网络问题的根本原因。在一些实施例中，聚合诊断可以根据位置、时间、设备类型、设备问题或接入技术进行索引。

Description

使用回声定位进行用户体验质量的分析

一个或更多优先权申请

本专利申请要求于2015年7月20日递交的序列号为14/803,769的美国实用专利申请的优先权，其要求于2015年5月29日递交的序列号为62/168,468的美国临时专利申请的优先权。序列号14/803,769和62/168,468的申请的全部内容通过引用并入本文中。

背景技术

现代电信系统包括第二、第三和第四代(2G，3G和4G)蜂窝无线接入技术的多样混合，其可以是交叉兼容的，并且可以共同操作来提供数据通信服务。全球移动系统(GSM)是2G电信技术的一个例子；通用移动电信系统(UMTS)是3G电信技术的一个例子；以及包括LTE高级和演进高速分组接入(HSPA+)在内的长期演进(LTE)都是4G电信技术的例子。

组成现代电信网络的基础设施包括多个不同组件或设备(这里称为节点)，其被配置为生成、发送、接收、中继和/或路由数据分组，使得数据服务可以被请求并且被提供到订阅计划的用户设备(UE)，该计划由实现电信网络的一个或更多服务提供商或网络通信提供商提供。

然而，经由节点提供的数据服务和/或数据通信常常会经历由于大量用户和UE经由电信网络访问和请求数据而导致服务质量降级的问题。例如，由于对数字内容的高传输需求(即，数据传输过载)，导致可能与数据流量拥塞相关联的服务质量降级的问题，并且这可能导致数据分组丢失、分组排队延迟、无法建立连接和其他数据通信和连接问题。如果服务提供商或网络通信提供商没有解决这些问题，则这些问题降低在UE处的网络的服务质量(QoS)和最终用户的用户体验质量(QoE)。

附图说明

参考附图阐述了详细说明，其中，参考标号的最左边的数字表示参考标号首次出现的附图。在不同图中使用相同的参考标号表示相似或相同的条目或特征。

图1A描绘了根据本公开的实施例的示例环境，其中，可以从多个节点收集跟踪文件并将其相关以识别网络优化机会。

图1B描绘了根据本公开的实施例的QoE优化系统的体系架构的一部分的示例。

图1C描绘了根据本公开的实施例的示例性环境，其中可以从客户端设备收集客户端设备QoE诊断文件和跟踪文件，可以从网络收集跟踪文件，并且可以执行QoE分析。

图2描绘了根据本公开的实施例的客户端设备的示例组件，该客户端设备被配置为发起数据通信并在跟踪文件中记录跟踪文件条目。

图3A描绘了根据本公开的实施例的可以记录在跟踪文件中的示例数据分组。

图3B描绘了根据本公开的实施例的示例跟踪文件。

图4描绘了根据本公开的实施例的被配置为收集和使跟踪文件相关以及执行网络分析的设备的示例组件。

图5是根据本公开的实施例的通过网络传输并且表示水平相关性的示例数据分组通信图。

图6是根据本公开的实施例的表示垂直相关性的示例模型。

图7是根据本公开的实施例的用于在跟踪文件中记录跟踪条目的示例过程的流程图。

图8是根据本公开的实施例的用于收集和使跟踪文件相关以便可以执行网络分析的示例过程的流程图。

图9是根据本公开的实施例的用于收集和使跟踪文件相关以便可以执行网络分析的另一示例过程的流程图。

图10描绘了用于接收跟踪文件、确定跟踪文件中包括的数据的性能度量、以及生成性能度量的图形表示或文本表示的另一示例过程的流程图。

图11描绘了用于接收一个或更多跟踪文件、将与设备的不同层或不同设备相关联的跟踪文件数据相关、基于阈值或模型分析相关数据、并且确定与相关数据相关联的通信呈现降低的QoE的另一示例过程的流程图。

图12是与由设备参与的通信相关联的性能度量的图形表示的示例。

图13是与由设备参与的通信相关联的性能度量的图形表示的示例。

图14是与由设备参与的通信相关联的性能度量的图形表示的示例。

图15是与由设备参与的通信相关联的性能度量的图形表示的示例。

图16是与由设备参与的通信相关联的性能度量的图形表示的示例。

图17是与由设备参与的通信相关联的性能度量的文本表示的示例。

图18描绘了根据本公开的实施例的客户端设备体验质量(QoE)诊断文件的示例。

图19是根据本公开的实施例的用于收集诊断、过滤诊断和发送客户端设备QoE诊断文件的示例过程的流程图。

图20是根据本公开的实施例的用于接收和分析设备诊断的示例过程的流程图。

图21是根据本公开的实施例的用于发送诊断消息的示例过程的流程图。

图22是根据本公开的实施例的聚合的设备QoE度量的图形表示的示例。

图23是根据本公开的实施例的聚合的设备QoE度量的图形表示的示例。

图24是根据本公开的实施例的聚合的设备QoE度量的图形表示的示例。

具体实施方式

本文描述的技术通过利用更广的基于网络的方法来确定引起服务质量降级的问题的根本原因(例如，出现了什么问题、问题出现的原因、问题出现在电信网络中的什么地方)而给服务提供商和/或网络提供商提供了优化数据服务的QoE的机会。为了确定问题的根本原因，这些技术可以从电信网络中的多个不同节点(或从电信网络中的两个节点之间的通信接口)或从设备之一的通信协议栈的多个或单个层中收集不同的跟踪文件。每个跟踪文件包括许多不同数据分组的识别日志，其通过电信网络中的节点生成、接收、发送、中继和/或路由，并且每个跟踪文件日志条目可以与时间戳相关联。一旦被收集，这些技术可以将来自多个不同节点的不同跟踪文件相关，以使用更广泛的基于网络的分析来识别服务优化机会。同时或者反之，技术可以将来自设备之一的不同层的通信协议栈的数据相关，或者可以简单地确定来自特定设备的特定层的数据的性能度量。例如，在使跟踪文件相关并确定QoE已经经历一定程度的降级之后，这些技术可以提供警报通知和用于优化的建议，使得可以实现补救动作来解决问题的根本原因。

在各种实施例中，当跟踪文件相关性和分析确定关键性能指示符(KPI)不满足与QoE相关联的最小服务水平或服务目标时，技术向网络管理员提供警报通知和建议。然后，网络管理员可以启动补救动作。在可替换的实施例中，当不满足服务水平或服务目标时，跟踪文件的收集、跟踪文件的相关性和分析以及补救动作的实现可以经由预设的网络配置自动执行。

在一些实施例中，客户端设备可以收集关于客户端设备的诊断，诸如用于客户端设备的各种单独组件的操作日志或报告。诊断可以被过滤和/或组合以生成客户端设备QoE诊断文件，其可以被发送到网络节点以用于分析。在一些实施例中，在网络节点处操作的QoE分析器可以分析客户端设备QoE诊断文件以确定设备KPI、设备QoE和/或确定导致QoE减小的网络或设备中的问题(例如掉话)的根本原因。在一些实施例中，可以将从QoE诊断文件确定的QoE诊断文件和/或KPI聚合以形成聚合的QoE诊断或聚合的KPI的数据库，其可用于进一步分析网络以确定问题的根本原因。例如，根本原因分析可以在单个呼叫的设备KPI、来自单个设备的聚合呼叫，或来自多个设备的聚合呼叫的边界内执行。在一些实施例中，QoE诊断文件和/或KPI可以根据位置、时间、设备类型、设备问题或接入技术被索引。

图1A描绘了用于从使用电信网络交换数据分组的不同节点收集多个跟踪文件的示例性环境100。为此，环境100可以包括客户端设备102(在本文中被视为节点)、移动电信网络(MTN)104，其包括多个MTN节点106(1)...106(N)，一个或更多数据服务器108和体验质量(QoE)优化系统110。此外，环境100示出了在每个节点处记录的跟踪文件。例如，客户端设备102与一个或更多客户端设备节点跟踪文件112相关联，并且MTN节点106(1)...106(N)的每一者与一个或更多MTN节点跟踪文件114(1)...114(N)相关联。在各种实施例中，数据服务器108每一者可以与一个或更多数据服务器节点跟踪文件116相关联。

如上所述，客户端设备102也可以被称为UE。因此，客户端设备102可以包括但不限于智能电话、移动电话、蜂窝电话、平板计算机、便携式计算机、膝上型计算机、个人数字助理(PDA)、电子书装置、手持游戏单元、个人媒体播放器设备、可穿戴设备或任何其他便携式电子设备，其可以产生语音和/或数字数据、通过MTN 104请求语音和/或数字数据、通过MTN104接收语音和/或数字数据，和/或通过MTN 104交换语音和/或数字数据。

MTN 104可以被配置为实现上面讨论的第二、第三和第四代(2G、3G和4G)蜂窝无线接入技术中的一个或更多。因此，MTN 104可以实现GSM、UMTS和/或LTE/LTE高级电信技术。GSM、UMTS、LTE、LTE高级和/或HSPA+电信技术中的不同类型的MTN节点106(1)...106(N)可以包括但不限于以下的组合：基站收发台BTS(例如，NodeB，高级NodeB)、无线电网络控制器(RNC)、服务GPRS支持节点(SGSN)、网关GPRS支持节点(GGSN)、代理、移动交换中心(MSC)、移动性管理实体(MME)、服务网关(SGW)、分组数据网络(PDN)网关(PGW)、演进分组数据网关(e-PDG)或被配置为在客户端设备102和数据服务器108之间通信和/或路由数据分组的任何其他数据流量控制实体。MTN节点106(1)...106(N)可以配置有在MTN节点跟踪文件114(1)...114(N)中生成和/或记录条目的硬件和软件。虽然图1A示出了MTN 104，但是，在本文件的上下文中理解为，这里讨论的技术也可以在其他网络技术中实现，诸如作为广域网(WAN)、城域网(MAN)、局域网(LAN)、邻域区域网(NAN)、个人区域网(PAN)等的一部分的节点。

在各种实施例中，每个跟踪条目包括标识，该标识与通过用于MTN节点106(1)...106(N)的接口通信的数据分组相关联，或与由MTN节点106(1)...106(N)路由的数据分组相关联的，如这里进一步讨论。在各种实施例中，MTN节点106(1)...106(N)中的一些可以是被配置为访问提供数据通信服务(例如，使得客户端可以访问数据服务器108处的信息)的基于IP的网络的核心网络(例如，回程部分、载波以太网)的一部分。数据服务器108可以由基于网页的内容提供商拥有和/或操作，包括但不限于： GoogleAmazon 等。

在各种实施例中，MTN 104可以被配置为使用有线和/或无线链路在客户端设备102和数据服务器108之间交换数据分组。此外，MTN 104可以被配置为确定通信路径或“管路”，使得可以相应地路由和交换数据分组。

本文件中讨论的数据服务和数据访问应用程序可以包括但不限于网页浏览、视频流、视频会议、网络游戏、社交媒体应用或客户端设备102上的任何应用或设置，其被配置为通过MTN 104生成数据并且与数据服务器108交换数据。

在各种实施例中，QoE优化系统110可以被配置为监控和确定与特定服务水平或服务目标(例如，阈值或模型)相关联的不同数据服务的KPI是否被满足或不被满足，这可能会影响QoE。网页浏览以及在客户端设备102上执行的其他应用程序的KPI的示例可以包括网页加载时间、域名系统(DNS)查找时间、传输控制协议(TCP)连接时间、TCP往返时间(RTT)、超文本传输协议(HTTP)响应时间等。用于视频流和视频会议以及在客户端设备102上执行的其他应用的KPI的示例示例可以包括应用开始延迟，目录浏览，搜索延迟，视频启动延迟，快进和倒带延迟，多个缓冲事件，每个缓冲事件的持续时间，重新缓冲比例，视频帧速率等。UE的其他KPI可以包括应用层KPI(诸如平均/最小/最大比特率，流量突发性，传输的数据字节量)，传输层KPI(诸如传输控制协议(TCP)重传和TCP重置)，无线电层KPI(例如无线电链路控制(RLC)重传和RLC往返时间(RTT))和物理层KPI(诸如物理重传，物理RTT，物理上行链路(UL)干扰，UE功率，RACH时间)。以上提供的KPI作为示例而呈现，因此列表并不详尽。相反，服务提供商和/或网络提供商可以构想大量不同的KPI，这些KPI有助于测量与提供的数据服务相关联的QoE。

图1B描绘了根据本公开的实施例的QoE优化系统110的体系架构150的一部分的示例。如图所示，体系架构150的QoE分析器152可以接收一个或更多跟踪文件154(1)，154(2)...154(J)。QoE分析器152可以确定与来自一个或更多跟踪文件154(1)，154(2)...154(J)的全部或子集的数据的KPI 156相关联的性能度量。QoE分析器152还可以将来自一个或更多跟踪文件154(1)，154(2)...154(J)的数据相关，并且基于性能阈值或性能模型158分析相关数据，以确定由一个或更多跟踪文件154(1)，154(2)...154(J)表示的通信是否呈现出(exhibit)质量降级的QoE。QoE分析器152产生的性能度量或相关数据然后可用于生成一个或更多图形表示160和/或一个或更多文本表示162。可替代地或另外地，当QoE分析器152确定由一个或更多跟踪文件154(1)，154(2)...154(J)表示的通信呈现出质量降级的QoE时，可以提供警报164。

在各种实施例中，一个或更多跟踪文件154(1)，154(2)...154(J)可以是来自单个节点的跟踪文件(例如，跟踪文件112，114或116)或可以是来自多个节点的跟踪文件(例如，跟踪文件112，114或116中的多个跟踪文件)。每个跟踪文件154可以包括来自设备(例如，客户端设备102，MTN节点106或数据服务器108中的一个)的通信协议栈(例如，通信协议栈222)的单层或来自该设备的多层的数据。例如，跟踪文件154可以包括传输控制协议(TCP)日志，分组捕获(PCAP)日志，高通可扩展诊断模块(QXDM)日志，应用程序日志(例如，LogCat日志)等。包含在跟踪文件154中的数据可以与任何种类的通信相关联，诸如无线通信，基于分组的无线通信等。本文进一步描述了这种通信的示例。

可以通过自动日志解析器工具从跟踪文件中提取数据，该工具例如可以与跟踪文件接收模块410(在此针对图4进一步讨论)相关联。跟踪文件154和/或所提取的数据然后可以被存储在QoE优化系统110的跟踪文件数据库412(在此针对图4进一步讨论)中。在一些实施例中，跟踪文件接收模块410或QoE优化系统110的另一个模块然后可以将从跟踪文件154提取的数据和/或跟踪文件154本身提供给QoE分析器152。

QoE分析器152可以由QoE优化系统110的一个或更多模块来实现，例如跟踪文件相关模块414，跨文件分析模块416和跟踪分类模块422。在一些实施例中，QoE分析器152可以检索与单个设备的跟踪文件154中包括的单个层(例如，无线电层)相关联的数据。这样的数据可以例如从跟踪文件数据库412检索，或者可以由跟踪文件接收模块410提供给QoE分析器152。

然后，QoE分析器152可以确定与接收/检索的数据的KPI相关联的性能度量。当接收/检索的数据与无线电层相关联时，QoE分析器152可以确定与无线电层KPI相关联的性能度量，诸如RLC重传，分组丢失，网络信令，无线电资源控制(RRC)状态持续时间，无线电状态转换时间，在不同无线电状态下花费的时间，无线电状态转换的次数、或重新配置响应时间。当接收/检索的数据与网络、传输或因特网层相关联时，QoE分析器152可以确定与KPI相关联的性能度量，例如域名服务(DNS)RTT，TCP RTT，超文本传输协议(HTTP)RTT，TCP重传，TCP重复确认，TCP重置，TCP故障，增量帧或序列号。然后，QoE分析器152可以将所确定的性能度量和其相关联的KPI的指示提供给QoE优化系统110的另一模块，诸如呈现和通知模块424。该另一个模块然后可以生成用于一些或所有性能度量的文本表示162或用于一些或所有性能度量的图形表示160中的一个或两个。

图12-16是由QoE分析器152确定的性能度量的图形表示160的示例。在图12中，图形表示1200是无线电状态概要图。在图13中，图形表示1300是一个或更多搜索按键HTTP响应时间的图。如图14所示，图形表示1400是一个或更多搜索按键HTTP响应时间的组成部分的图。在图15，图形表示1500是搜索按键响应时间与无线电状态的相关性的图。如图16所示，图形表示1600是HTTP按键响应时间与无线电状态的相关性的图。也可以或替代地生成与KPI 156相关联的性能度量或相关数据的任何数量的其他类型的流程图和图。

图17是由QoE分析器152确定的性能度量的文本表示162的示例。在图17中，文本表示1700是无线电状态转换日志。还可以或替代地生成与KPI 156相关联的性能度量或相关数据的任何数量的其他文本或日志表示。

回到图1B，QoE分析器152还可以或替代地检索与单个设备的一个或更多跟踪文件154中包括的多个层(例如，无线电层和网络层)相关联的数据。例如，可以从跟踪文件数据库412检索到这样的数据，或者可以由跟踪文件接收模块410提供给QoE分析器152。然后，QoE分析器152可以将从多个层的不同层所接收/检索到的数据彼此相关。例如，相关的数据可以表示数据分组。QoE分析器152可以将来自表示数据分组的第一层的数据与来自表示数据分组的第二层的数据相关。在一些实施例中，QoE分析器152可以基于第一层和第二层中的数据分组的IP有效载荷的表示而关联数据。如上所述，QoE分析器152的相关性可以由QoE优化系统110的模块(诸如跟踪文件相关模块414)来实现。下面参考图6更详细地描述层之间的相关性。

在一些实施例中，QoE分析器152还可以或替代地从多个设备的多个跟踪文件154检索数据。例如，可以从跟踪文件数据库412检索这样的数据，或者可以由跟踪文件接收模块410提供给QoE分析器152。然后，QoE分析器152可以使数据相关。可以基于跟踪识别(跟踪ID)来相关数据。每个设备可以对相同的数据分组、请求/响应对或通信会话使用相同的跟踪ID。由QoE分析器152进行的多个设备的跟踪文件154之间的相关可以由QoE优化系统110的模块(诸如跟踪文件相关模块414)来实现。这一相关性在本文中进一步详细描述。

在各种实施例中，QoE分析器152然后可以基于性能阈值或模型158中的一个或两者来分析相关数据。性能阈值或模型158可以是静态的或学习的。例如，性能阈值或模型158可以表示数据分组、请求/响应或会话的典型通信。当相关数据与来自性能阈值或模型158的相容阈值不匹配或超出该相容阈值时，QoE分析器152可以确定由相关数据表示的通信呈现出降低的QoE。对相关数据的这种分析可以由QoE优化系统110的模块(诸如跨文件分析模块416)来实现。该分析在本文中进一步详细描述。

当QoE分析器152确定由相关数据表示的通信呈现降低的QoE时，QoE优化系统110的模块可以提供对降低的QoE的警报164。呈现和通知模块424可以是这样的模块的示例，并且可以响应于QoE分析器152确定减少的QoE来提供减少的QoE的警报。

另外或替代地，QoE优化系统110的模块(诸如呈现和通知模块424)可以针对相关数据生成图形表示160或文本表示162。

图1C示出了示例性环境170，其中客户端设备102可以向QoE分析器180发送一个或更多客户端设备QoE诊断文件176，并且可以由QoE分析器180执行分析。在一些实施例中，除了或代替一个或更多客户端设备QoE诊断文件176之外，QoE分析器180可以接收跟踪文件174(1)、174(2)...174(K)和一个或更多客户端设备跟踪文件178。

QoE分析器180可以对应于图1B的QoE分析器152，并且可以由QoE优化系统110的一个或更多模块来实现。在一些实施例中，QoE分析器180可以与QoE分析器152和/或QoE优化系统110并行地执行操作，而在一些实施例中，QoE分析器180可以替代QoE分析器152和/或QoE优化系统110而执行操作。

在一些实施例中，一个或更多跟踪文件174(1)，174(2)...174(K)可以对应于图1A的跟踪文件114和116以及图1B的跟踪文件154。在一些实施例中，一个或更多客户端设备跟踪文件178可以对应于图1A的一个或更多客户端设备跟踪文件112和图1B的跟踪文件154。

客户端设备102可以包括客户端设备体验质量(QoE)模块172，其可以在硬件、固件或软件中实现，以执行操作，以生成、聚集、收集、制定、过滤、分区、估计、记录、跟踪或执行任何预处理或后处理，以将一个或多个客户端设备QoE诊断文件176发送到QoE分析器180。在一些实施例中，客户端设备QoE模块172可以监控客户端设备的一些或全部操作，并且可以生成或收集对应于每个操作的操作日志或报告。例如，客户端设备QoE模块172可以监控客户端设备102的呼叫状态，用户界面状态，IP多媒体子系统(IMS)会话发起协议(SIP)消息，客户端设备102切换，实时传输协议(RTP)统计，呼叫设置，信号数据，无线电带数据，位置数据，时间戳和设备数据。在一些实施例中，客户端设备QoE模块172可以创建监控客户端设备102的操作的操作日志，而在一些实施例中，客户端设备QoE模块172可以收集和过滤包括在一个或更多客户端设备QoE诊断文件176中的数据。在一些实施例中，一个或更多客户端设备QoE诊断文件176可以包含在客户端设备102上生成、聚集和/或收集的可以从其确定(由客户端设备QoE模块172或者由QoE分析器180)KPI和/或客户端设备QoE的信息。在一些实施例中，QoE模块172例如通过监控意图来监控客户端设备102中的应用之间的消息，以确定客户端设备102的操作状态。客户端设备QoE模块172和一个或更多客户端设备QoE诊断文件176同样结合图18-21讨论。

QoE分析器180可以包括网络KPI模块182，QoE聚合器模块184和QoE趋势模块186。此外，QoE分析器180可以包含处理器(诸如一个或更多处理器402)，存储器(诸如存储器404)，设备OS(诸如设备OS 406)，以及图4的一些或所有模块408-426(如本文针对图4中进一步讨论的)。

QoE分析器180可以接收一个或更多客户端设备QoE诊断文件176，并且可以分析一个或更多文件176，以确定KPI，KPI可用于确定客户端设备102正在经历降级或减少的QoE，或者可以确定客户端设备102先前已经经历了降级或减少的QoE。在一些实施例中，KPI可以在被发送到QoE分析器180之前由客户端设备102(或由客户端设备QoE模块172)确定。作为示例，客户端设备语音质量QoE KPI可以基于实时分组协议(RTP)数据(例如RTP丢失率)和SIP消息跟踪数据(例如编解码器类型和采样率)而进行预测(如本文针对图18-21进一步讨论的)。降级或减少的QoE的示例可以是掉话，掉话频率的增加，语音、视频或数据通信的质量降级，以及呼叫建立问题，例如连接的延迟、不能连接。在一些实施例中，QoE分析器180可以基于客户端设备102的操作状态、由客户端设备102测量或确定的KPI和/或QoE，或者由客户端设备102测量或确定的QoS来确定降级或减少的QoE。

作为非限制性示例，语音呼叫的QoE KPI可以指示是否掉话，是否出现呼叫建立失败，语音呼叫中的任何停播时间的存在和量(例如，由数据传输错误引起的不期望的静音)，平均意见得分(MOS评分)(指示0到5范围内的语音呼叫质量)，供应状态，注册状态和/或呼叫建立所需的时间量。作为示例，LTE上语音(VoLTE)呼叫的“良好”QoE可能是“无掉话”，“无呼叫建立失败”，“无停播”，“平均4.3MOS”，“无供应问题”，“无注册问题”和“4秒呼叫建立时间”。另一方面，作为示例，“不良”QoE VoLTE呼叫可以包括“呼叫建立成功”但“9秒呼叫建立时间”的指示。在该示例中，呼叫建立时间可以比平均呼叫建立时间长5秒，这可以指示减少的QoE。此外，“不良”QoE VoLTE呼叫可能包括“30秒的停播开始40秒后进入呼叫”，“停播后发生掉话”的指示。此外，“较差”QoE VoLTE呼叫的示例可以包括“一旦尝试即掉话(由于供应问题)”的指示。如在本公开的上下文中可以理解的，用于VoLTE呼叫的QoE的这些示例是示例性的，并且可以包括其他因素、指示和/或时间长度。

网络KPI模块182可以执行确定或估计客户端设备102的KPI或QoS的操作。网络KPI模块182可以基于可用于QoE分析器180的数据或参数来确定客户端设备102的基于网络的KPI，诸如一个或更多客户端设备跟踪文件178和/或跟踪文件174。在一些实施例中，网络KPI模块182可以部分地基于客户端设备102的QoS，或者部分地基于由一个或更多客户端设备跟踪文件178和/或一个或更多跟踪文件174确定的KPI，来确定客户端设备102的基于网络的KPI。

QoE聚合器模块184可以聚合从一个或更多客户端设备QoE诊断文件176和/或网络KPI模块182确定的，或从客户端设备102接收的(例如，如由客户端设备QoE模块172确定的)客户端设备KPI或者客户端设备QoE。在一些实施例中，QoE聚合器模块184可以使用一个或更多客户端设备QoE诊断文件176聚合KPI，而在一些实施例中，QoE聚合器模块184可以聚合网络和设备QoE KPI，而在一些实施例中，设备QoE KPI可以通过多个通信(例如，语音呼叫)对多个客户端设备进行聚合。

QoE趋势模块186可以确定单个客户端设备102的QoE趋势，或者可以确定多个客户端设备和/或连接到MTN 104的节点的QoE趋势。在一些实施例中，QoE趋势模块186可以随着时间针对单个客户端设备102聚合一个或更多客户端设备QoE诊断文件176，而在其他实施例中，QoE趋势模块186可以在任何时间段上针对多个设备聚合QoE诊断文件。在一些实施例中，QoE聚合器模块184可以聚合由QoE分析器180或客户端设备102确定的客户端设备KPI和/或QoE。在一些实施例中，QoE趋势模块186可以生成表示趋势数据的图形和/或文本表示，和/或可以生成指示已经检测到或可以补救趋势的警报。QoE分析器180，网络KPI模块182，QoE聚合器模块184和QoE趋势模块186也可结合图18-21讨论。

图22-24是根据本公开的实施例的阐释趋势的聚合设备KPI和/或QoE度量的图形表示的示例。在一些实施例中，图形表示2200、2300和2400可以由QoE分析器180针对单个客户端设备102来确定，或者可以由QoE分析器180和/或QoE趋势模块186针对在一段时间内的表示多个设备的聚合数据来确定。在图22中，图形表示2200是对每个区域或市场的掉话率的分析。在图23中，图形表示2300是根据设备模型和掉话源索引的掉话率的图。在图24中，图形表示2400是在一段时间T1，T2，T3，T4和T5中由接入技术索引的掉话率的图。还可以或替代地生成客户端设备KPI和/或QoE的任何数量的其他流程图和图表。

图2示出了客户端设备102的示例性组件，其被配置为向MTN 104无线地发送对数据的请求或者通过MTN 104从数据服务器108接收数据。因此，客户端设备102可以包括一个或更多处理器202，用于与MTN 104无线通信的无线电收发机204以及存储设备操作系统(OS)208的存储器206，被配置为通过MTN 104请求/接收数据的各种软件应用程序210，网络接口模块212和客户端设备节点跟踪文件112。

在各种实施例中，存储在客户端设备102处的应用程序210可以包括但不限于通过第N个软件应用程序220的网页浏览器应用程序214，视频流应用程序216，在线游戏应用程序218等。在客户端设备102上执行期间，每个应用程序210可被配置为使得客户端设备102通过MTN 104发起与数据服务器108的数据通信。

客户端设备102可以被配置为使用任何公共无线和/或有线网络接入技术通过电信网络进行通信。此外，客户端设备102可以被配置为运行任何兼容设备OS，包括但不限于Microsoft WindowsGoogleAppleLinux以及任何其他常见的移动设备OS。

一个或更多处理器202中的每一者可以包括一个或更多中央处理单元(CPU)和一个或更多控制单元(CU)，一个或更多中央处理单元(CPU)具有执行算术和逻辑运算的多个算术逻辑单元(ALU)，以及一个或更多控制单元(CU)从处理器高速缓存级存储器中提取指令和存储内容，然后在程序执行期间通过调用ALU来执行指令。在实现方式中，一个或更多处理器202可以被配置为执行存储在存储器206中的每个软件应用程序210。在各种实施例中，网络接口模块212可以被配置为检测指向应用程序210中的一者的动作(例如，操作、命令、用户输入)，该动作触发生成数据传输请求和传输数据传输请求。

存储器206可以使用诸如计算机存储介质的计算机可读介质来实现。计算机可读介质包括至少两种类型的计算机可读介质，即计算机存储介质和通信介质。计算机存储介质包括以用于存储信息(诸如计算机可读指令，数据结构，程序模块或其他数据)的任何方法或技术实现的易失性和非易失性、可移除和不可移除的介质。计算机存储介质包括但不限于RAM，ROM，EEPROM，闪存或其他存储器技术，CD-ROM，数字通用盘(DVD)或其他光学存储器，磁带盒，磁带，磁盘存储或其他磁存储设备，或可用于存储信息以由计算设备访问的任何其他非传输介质。相比之下，通信介质可以体现为计算机可读指令，数据结构，程序模块或调制数据信号(例如载波或其他传输机制)中的其他数据。

在各种实施例中，存储器206可以存储客户端设备QoE模块172，如图1C所示。

在各种实施例中，客户端设备节点跟踪文件112可以对应于与客户端设备102的网络接口模块212相关联的通信协议栈222的多个层中的各个层。例如，通信协议栈222中的多个层可以对应于开放系统互连(OSI)模型，其以抽象层表征和标准化通信系统的功能。多个层也可以对应于因特网协议(IP)套组。例如，在各种实施例中，客户端设备102可以针对物理层，数据链路/无线电层，网络层/因特网层，传输层，会话层，呈现层，以及应用层中的每一者记录单个客户端设备节点跟踪文件112，随着数据分组在多层之间生成并且配置，以用于通过MTN 104从客户端设备102通信到数据服务器108。

另外，客户端设备102可以针对通信协议栈212的多个层的特定集合而记录单个客户端设备节点跟踪文件112。例如，客户端设备102可以针对应用程序/呈现/会话层记录第一客户端设备节点跟踪文件112、针对传输/网络层记录第二客户端设备节点跟踪文件112、针对数据链路层记录第三客户端设备节点跟踪文件112，以及针对物理层记录第四客户端设备节点跟踪文件112。通过记录客户端设备102的层级处的跟踪文件，QoE优化系统110可能够在收集层级(与节点级相比)处的跟踪文件之后，确定在更粒化级别的问题的根本原因。当识别出优化QoE的补救动作时，这可以有进一步的帮助。

与客户端设备102处的多个不同层类似，每个MTN节点106(1)...106(N)以及每个数据服务器108也可以针对单个层或者MTN节点106/数据服务器108的通信协议栈的层的一个或更多定义的组合来记录不同跟踪文件(例如，114(1)...114(N)和116)。因此，QoE优化系统110还可以在MTN节点106(1)...106(N)和数据服务器108处识别在更粒化级别的问题的根本原因。

图3A描绘了被配置为记录在客户端设备节点跟踪文件112，MTN节点跟踪文件114(1)...114(N)或数据服务器节点跟踪文件116之一中的示例数据分组300。数据分组300可以以与一个或更多通信或数据交换/格式化协议(例如TCP、IP、HTTP或其他旨在通过MTN104通信或交换内容的协议)相关联的方式被配置。

在各种实施例中，数据分组300可以包括报头部分302和有效载荷部分304。数据分组还可以包括包括N个字段的部分，其至少一部分用于创建数据分组的跟踪ID 306。在各种实施例中，用于创建跟踪ID 306的字段可以是报头部分302、有效载荷部分304或其组合的一部分。

在各种实施例中，N个字段中的一个或更多字段可以与通常包括在数据分组中的路由和寻址信息相关联，或者可以与被定义并且对于特定协议是唯一的一个或更多字段相关联。例如，字段可以包括分组数据协议(PDP)地址，源端口号，目的端口号，校验和号(针对IPv4或IPv6)，序列号，确认号，互联网协议(IP)地址，源地址，目的地址或数据分组中可能有助于将一个数据分组与另一数据分组区分开的任何其他字段。此外，一个字段还可以帮助识别请求/响应序列或对，或建立的特定通信会话，使得数据分组可以正确匹配和/或相关，即使作为整体跟踪ID 306可能不是精确的匹配。

因此，跟踪ID 306可以由单个字段或两个字段、三个字段、四个字段等的组合组成。用于构成跟踪ID 306的字段越多，可以帮助确保跟踪ID 306对于数据分组是唯一的或将相关数据分组进行相关，使得可以通过其通信路径跟踪数据分组。在至少一个实施例中，跟踪ID 306包括四个字段：PDP地址、校验和号、源端口号和目的端口号。

图3B描绘了示例跟踪文件308，其可以对应于在客户端设备处记录的客户端设备节点跟踪文件112，在MTN节点106(1)...106(N)处记录的MTN节点跟踪文件114(1)...114(N)，或在数据服务器108处记录的数据服务器节点跟踪文件116。跟踪文件308可以包括QoE优化系统110可以使用的节点识别符310，从而它知道在QoE优化系统110收集跟踪文件之后，跟踪文件与哪个节点(例如，客户端设备102，MTN节点106(1)...106(N)中的一个，或数据服务器108)相关联。因此，QoE优化系统110能够识别出现问题的根本原因所在的一个或更多节点，然后相应地执行补救动作。

在各种实施例中，跟踪文件308被配置为记录经由节点或节点接口通信的数据分组的条目，例如跟踪列312(例如，跟踪列312中的跟踪ID 306可以对应于使用节点进行通信的多个不同的客户端设备)。此外，跟踪文件308被配置成接收以每个条目的时间戳的形式存在的定时信息314，并且将时间戳与条目相关联/存储时间戳，如图所示。因此，跟踪文件308可以顺序地记录与何时接收、发送、路由等数据分组相关联的许多数据分组ID和时间戳的列表。

在每个节点处，通过使用时间源(例如，本地时间源或远程时间源)记录时间戳。在一个实施例中，时间源对于节点或至少一些节点可以是公共的。可替代地，对于每个节点或至少一些节点，时间源可以是不同的。因此，合并在一起(从多个跟踪文件)的定时信息314可以为近似合并的定时信息，因为一些节点可以使用可能不同步的不同时间源。

图4示出了QoE优化系统110的示例组件。在各种实施例中，QoE优化系统110可以是服务提供商实体或电信提供商实体，其可以为MTN节点106(1)...106(N)之一的一部分，或者经由网络连接与MTN节点106(1)...106(N)通信。此外，在各种实施例中，QoE优化系统110可以是作为客户端设备102或数据服务器108的一部分的独立应用。

在各种实施例中，QoE优化系统110可以是一个或更多服务器或者计算设备，其包括一个或更多处理器402和存储设备OS 406的存储器404，以及网络接口模块408，网络接口模块408使得QoE优化系统110的跟踪文件接收模块410能够通信并且接收来自图1A的节点的跟踪文件，并且将跟踪文件或从跟踪文件检索的数据存储在跟踪文件数据库412中。

QoE优化系统110的一个或更多处理器402中的每一者可以包括具有执行算术和逻辑运算的多个ALU的一个或更多CPU，以及从处理器高速缓存存储器提取指令和内容，然后在程序执行期间根据需要通过调用ALU来执行指令的一个或更多CU。一个或更多处理器402还可以被配置为执行存储在存储器404中的模块。

可以使用计算机可读介质(诸如计算机存储介质)来实现存储器404。计算机可读介质包括至少两种类型的计算机可读介质，即计算机存储介质和通信介质。计算机存储介质包括以用于存储信息(诸如计算机可读指令，数据结构，程序模块或其他数据)的任何方法或技术实现的易失性和非易失性、可移除和不可移除的介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字通用盘(DVD)或其他光学存储、磁带盒，磁带，磁盘存储或其他磁存储设备或可用于存储信息以由计算设备访问的任何其他非传输介质。相比之下，通信介质可以体现为计算机可读指令、数据结构、程序模块或调制数据信号(例如载波或其他传输机制)中的其他数据。

在各种实施例中，存储器404还可以存储跟踪文件相关模块414、跨文件分析模块416、控制模块418、关键性能指示符(KPI)模块420、跟踪分类模块422、呈现和通知模块424以及补救动作模块426。

在各种实施例中，存储器404还可以存储网络KPI模块182、QoE聚合器模块184和QoE趋势模块186，如图1C所示。

上文关于QoE分析器152所描述的跟踪文件相关模块414被配置为合并和/或以其他方式将客户端设备节点跟踪文件112，MTN节点跟踪文件114(1)...114(N)，和/或数据服务器节点跟踪文件116相关。通过合并和/或相关跟踪文件，跟踪文件相关模块414匹配来自可能与相同的数据分组相关联的不同节点的跟踪ID 306。因此，随着数据分组从客户端设备102通信和/或路由到一个或更多数据服务器108(例如，经由MTN 104中确定的路线/路径的上行链路)或从一个或更多数据服务器108通信和/或路由到客户端设备102(例如，经由MTN 104中确定的路线/路径的下行链路)，跟踪ID 306保持恒定。在至少一些实施例中，跟踪文件相关模块414可以合并或以其他方式将收集的跟踪文件的总数的子集相关。

在一些实施例中，跟踪文件相关模块414还被配置为匹配对应的请求/响应数据分组，其可能不具有相同的跟踪ID 306，但是可以通过引用跟踪ID 306中的一个或更多字段来配对，所述跟踪ID 306将响应分组与请求分组(例如，传达该响应分组“2”响应于请求分组“1”的顺序指示符)相关联。在另外的实施例中，跟踪文件相关模块414可以通过引用跟踪ID306中将数据分组与通信会话相关联的一个或更多字段来匹配在所建立的通信会话(例如，视频流)内通信的一组数据分组。由跟踪文件相关模块414使用的、用于匹配请求分组和响应分组或匹配在所建立的通信会话内通信的数据分组的一个或更多字段可以取决于所使用的通信协议的类型。

在各种实施例中，一旦针对单个数据分组、针对请求/响应分组对、和/或针对所建立的通信会话内通信的数据分组，跟踪文件相关模块414将跟踪文件合并或以其他方式相关并匹配跟踪ID 306，则跨文件分析模块416可以使用相关性来执行网络通信分析并确定可能导致QoE质量降级的问题的根本原因。在各种实施例中，跨文件分析模块416可以针对匹配的跟踪ID 306使用定时信息314来执行网络通信分析并且确定可以经由定时问题识别的问题的根本原因。示例网络通信分析可以涉及：分组延迟、延迟映射、掉包率、拥塞窗口、分组丢失、分组错误率、重传请求的位置和多个重传请求等。此外，来自网络通信分析的结果可以识别沿着通信路径的一个或更多节点，其为问题的根本原因的，以及可以识别为什么一个或更多节点是问题的根本原因。因此，QoE优化系统110可以通过补救动作，通过消除问题或部分问题来识别优化QoE的机会。

在各种实施例中，跨文件分析模块416可以根据从控制模块418接收的指令来跨多个相关的跟踪文件来执行分析。控制模块418可以从网络管理员接收要执行的特定类型的分析。例如，网络管理员可以向控制模块418输入识别要分析的一个或更多KPI的命令，以确保是否满足定义的服务等级或服务目标。在各种实施例中，KPI模块420针对在客户端设备102上执行的不同应用程序210定义不同KPI(如上所列举的)。此外，如由服务提供商或网络电信提供商(例如，由作为服务提供商或网络电信提供商的代理的网络管理员)定义的，KPI模块420还可以定义KPI的特定服务等级或服务目标(例如，如性能阈值或模型158)。

在一些实施例中，跨文件分析模块416可以自动执行分析。因此，网络管理员可以配置QoE优化系统110的跟踪文件接收模块410以收集不同的跟踪文件，使得它们可以合并或以其他方式通过跟踪文件相关模块414相关，并且跨文件分析模块416可以以周期性方式(每小时、每天、每两天等)执行某类型的分析。在各种实施例中，可以针对各个KPI或KPI的特定组合单独地执行该自动分析。在其他实施例中，可以针对被配置为在客户端设备102上执行的各种应用程序210中的特定应用来执行自动和周期性分析。

在各种实施例中，跟踪分类模块422可以由跨文件分析模块416使用，以对已经与所收集的跟踪文件合并或以其他方式相关的跟踪ID 306进行分类。这种分类或过滤可能有助于跨文件分析模块416执行的分析。例如，跟踪分类模块422可以使用一个或更多字段对跟踪ID进行分类，以便识别从特定客户端设备102发送的或发送到特定客户端设备102(例如，特定用户或订户)的数据分组。跟踪分类模块422可以使用时间戳来对跟踪ID 306进行分类，以便识别特定时序窗中的数据分组。跟踪分类模块422可以使用跟踪分类模块422可以使用一个或更多字段对跟踪ID 306进行分类，以便识别来自特定类型的设备(例如，来自制造商的模型)的数据分组。跟踪分类模块422可以使用一个或更多字段对跟踪ID 306进行分类，以便识别为特定应用通信的数据分组。跟踪分类模块422可以使用一个或更多字段对跟踪ID 306进行分类，以便识别传送到特定源/从特定源传送的数据分组(例如，数据服务器108)。

在各种实施例中，QoE优化系统110使用呈现和通知模块424在跨文件分析模块416执行网络性能分析之后，格式化并呈现诸如警报164的通知或警报(例如，经由图形用户界面)。在一个实施例中，通知可以指出网络通信是良好的，并且正在满足一个或更多KPI和服务水平。因此，QoE目前尚未降级。在替选实施例中，警报可以报告网络通信正在导致QoE的降级，因为不满足一个或更多KPI和特定的服务水平。在该替选实施例中，呈现和通知模块424可以传送问题的根本原因和/或该问题的一个或更多原因的位置(例如，一个或更多节点)。

在一些实施例中，呈现和通知模块424还可以被配置为生成图形表示160或文本表示162，如本文更详细地描述的。此外，呈现和通知模块424可以使QoE优化系统110的用户能够发起从客户端设备102、MTN节点106或数据服务器108之一到客户端设备102、MTN节点106或数据服务器108中的另一个的数据分组的测试通信。与该测试通信相关联的数据将在一些或所有跟踪文件112-116中表示，并且可用于收集和分析。

在各种实施例中，补救动作模块426可以包括修复所识别的网络通信问题的指令。因此，跨文件分析模块和/或呈现和通知模块424可以访问补救动作模块，以确定问题的一个或更多建议的解决方案，并且然后经由图形用户界面呈现所选择的解决方案，使得它们可以被实现。在至少一个实施例中，补救动作模块426被配置为响应于问题的识别而自动地实现解决方案。

图5示出了经由可以是MTN 104的一部分的第二节点506(例如，RNC)和第三节点508(例如，核心网络节点)，在第一节点502(例如，客户端设备102或UE)和第四节点504(例如，数据服务器108)之间交换的数据分组的示例时序图500。提供该示例来示出QoE优化系统110如何使用跟踪文件308中的定时信息314来识别网络通信问题。因此，第一节点502在客户端节点跟踪文件112中记录跟踪条目，第二节点506在MTN节点跟踪文件114(1)中记录跟踪条目，第三节点508在MTN节点跟踪文件114(2)中记录跟踪条目，以及第四节点在服务器节点跟踪文件116中记录跟踪条目。虽然图5中描绘了四个节点，但是在本文件的上下文中可以理解，附加节点可能涉及在客户端设备102和数据服务器108之间交换数据分组，特别是MTN 104内的附加节点。图5中的示例性时序图500表示跨越网络的多个节点之间通信的分组的水平相关性。水平相关性可以使用基于分组的报头信息的水平唯一跟踪ID来使跨越多个节点使分组相关。相比之下，垂直相关性是指在单个节点处在多个不同层(例如，OSI模型层或栈)之间通信的数据分组，如针对图6进一步讨论的。垂直相关性可以使用基于IP有效载荷的垂直唯一跟踪ID，以便它们随着通过层通信时使分组相关。

图5示出了从第一节点502(例如，经由上行链路)发送到第四节点504的初始数据分组，以及从第四节点504(例如，经由下行链路)发送到第一节点502的响应数据分组。因此，图5示出了第一节点502处的RTT 510，其表示初始数据分组的发送与响应数据分组的接收之间的时间。

如图5所示，初始数据分组在第一节点502处生成并发送到第二节点506。因此，第一节点502可以用时间戳在客户端节点跟踪文件112中记录数据分组的条目(例如，在图5中用“1”标记)。第二节点506接收初始数据分组，可以访问、改变和/或添加路由信息，然后将初始数据分组中继514到第三节点508。与该功能相关联，第二节点506可以用时间戳在MTN节点跟踪文件114(1)中记录数据分组的条目(例如，在图5中用“2”标记)。类似地，第三节点508接收中继的数据分组，可以访问、改变和/或添加路由信息，并且然后将数据分组中继516到第四节点504。这里，第三节点508可以用时间戳在MTN节点跟踪文件114(2)中记录数据分组的条目(例如，在图5中用“3”标记)。

然后，第四节点504接收初始数据分组，并且产生并发送518响应分组，在服务器节点跟踪文件116中用时间戳记录接收的数据分组和/或发送的响应数据分组响应的条目(例如，在图5中用“4”标记)。类似于上行链路，第三节点508和第二节点506在520和522处将响应分组路由并中继回到第一节点502，并且用时间戳记录响应分组的条目(例如，用“5”和“6”标记)。第一节点502然后针对响应分组利用时间戳记录条目(例如，在图5中用“7”标记)，并且完成RTT。

当QoE优化系统110收集与图5中的示例时序图相关联的跟踪文件时，QoE优化系统110可以确定RTT 510比正常长或者比在第一节点502处使用的特定应用程序所期望的更长。在该确定之后，QoE优化系统110可以利用合并的跟踪文件和单独的时间戳(如上文针对图4所讨论的)以计算节点(无论是上行链路还是下行链路)之间的单个分组的通信延迟，并且识别在上行链路和/或下行链路期间可能对长于期望的RTT贡献最多的一个或更多节点(例如，在该所在的节点，数据分组被延迟)。

在各种实施例中，图5的时序图500可以表示客户端设备102和数据服务器108之间的TCP握手(例如，同步请求和确认响应)。在其他实施例中，图5中的时序图可以表示客户端设备102和DNS服务器之间的DNS查找。在另外的实施例中，图5的时序图可以表示客户端设备102和数据服务器108之间的HTTP请求和数据分组响应。

图6示出了垂直相关性600的示例，其表示当在单个节点处，在通信协议栈(诸如，通信协议栈222)的多个不同层(例如，1...N)处产生和/或在其之间通信的分组。例如，不同的层可以与OSI模型相关联，并且因此可以是物理层、数据链路层、网络层、传输层、会话层、表示层和应用层(以及层内的子层)。此外，垂直相关性可以使用基于IP有效载荷的垂直唯一跟踪ID在当其通过层通信时使数据分组相关。这种垂直相关性将在下面参照图1B更详细地描述。

图7-11说明了示例性过程。每个过程被示出为逻辑流程图中的框的集合，其表示可以在硬件、软件或其组合中实现的一系列操作。在软件的上下文中，这些框表示当由一个或更多处理器执行时执行所述操作的计算机可执行指令。通常，计算机可执行指令可以包括执行特定功能或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等。描述操作的顺序不旨在被解释为限制性的，并且任何数量的所描述的框可以以任何顺序和/或并行组合以实现该过程。出于讨论的目的，参考图1A的示例环境100、图1B的示例结构、图2和图4的示例组件、图3A的示例数据分组、图3B的示例跟踪文件、图5的示例时序图、和/或图6的示例垂直相关性，来描述图7-11中的过程。

图7示出了用于在跟踪文件中记录条目的示例性过程700的流程图。示例性过程700可以在生成、通信、接收、发送、路由、中继和/或存储数据分组的节点处(例如，客户端设备102、MTN节点106(1)...106(N)、数据服务器108)执行。

在框702，节点监控已经由节点生成、通过节点通信、在节点处接收、由节点发送、路由、中继和/或在节点处存储的数据分组。在各种实施例中，如上所讨论的，监控可以在节点级(例如，节点的单个跟踪文件)或层级(例如，节点的多个跟踪文件)。

在框704，节点在跟踪文件306中针对被监控的数据分组创建并记录一个或更多条目。如上所讨论的，每个条目可以包括表示将数据分组与其他数据分组区分开的跟踪ID306的一个或更多字段。在各种实施例中，节点可以针对数据分组在与节点的不同层相关联的不同跟踪文件中记录单独的条目。或者，节点可以在节点的单个跟踪文件中针对与不同层相关联的数据分组记录单独的条目。

在框706，在跟踪文件306中记录条目时节点对每个跟踪ID 306打上时间戳。因此，节点可以访问时间源以确定每个条目的定时信息。

在框708，节点将一个或更多跟踪文件发送到QoE优化系统110。在各种实施例中，节点可以响应于来自QoE优化系统110的请求(例如周期性请求或按需请求)将跟踪文件发送到QoE优化系统110。在替换的实施例中，节点可以知道或报告安排，并且根据报告安排主动地将跟踪文件发送到QoE优化系统110。

图8示出了用于收集跟踪文件、合并跟踪文件以及执行网络通信分析的示例性过程800的流程图。示例性过程800可以由作为QoE优化系统110的一部分的组件执行。

在框802，跟踪文件接收模块410可以自动地从多个节点(例如，客户端设备102、MTN节点106(1)和数据服务器108)收集跟踪文件。在各种实施例中，跟踪文件接收模块410可以根据周期性安排来自动收集跟踪文件。在各种实施例中，跟踪文件接收模块410可以自动地从MTN 104的节点中识别的子集收集跟踪文件。

在框804，跟踪文件相关模块414合并所收集的跟踪文件。在各种实施例中，合并可以包括在单个节点(例如，层级)上合并对应于不同层的跟踪文件，以及合并从不同节点(例如，节点级)接收的跟踪文件。

在框806，跨文件分析模块416分析合并的跟踪文件，以确定客户端设备的用户的QoE是否已经降级到预定等级。在各种实施例中，跨文件分析模块416使用跟踪ID的时间戳来执行分析，其与单个数据分组、请求/响应分组对、作为建立的通信会话的一部分的一组数据分组相匹配。此外，作为分析的一部分，跨文件分析模块416可以识别(例如，经由KPI模块420和/或控制模块418)用于评估的一个或更多KPI和与KPI相关联的特定服务水平或服务目标。如果不满足特定服务等级(例如，网页加载时间长于两秒，RTT大于1秒等)，则可以发现QoE降级到预定等级。作为分析的一部分，跨文件分析模块416可以使用跟踪排序模块422对合并的跟踪ID进行分类，从而可以执行分析。

在框808，跨文件分析模块416识别所识别的节点内的一个或更多节点和/或一个或更多层，其可能是导致降级的QoE的问题的根本原因。

在框810，呈现和通知模块424可以格式化并生成通过GUI待传送到网络管理员的报告或警报。报告或警报可能会提供跨跟踪文件分析的结果。

在框812，补救动作模块426可以实现补救动作以解决导致降级的QoE的问题。在各种实施例中，可以根据控制模块418中的预定指令来自动实现补救动作。在其他实施例中，可以响应于由网络管理员提供给控制模块418的选择和输入来实现补救动作。

图9示出了用于收集跟踪文件、合并跟踪文件以及执行网络通信分析的另一个示例过程900的流程图。示例过程900可以由作为QoE优化系统110的一部分的组件执行。

在框902，控制模块418可以接收来自网络管理员的请求，以从多个不同节点收集跟踪文件以用于跨跟踪文件分析。

在框904，跟踪文件接收模块410可以从多个节点(例如，客户端设备102、MTN节点106(1)和数据服务器108)收集跟踪文件。

在框906，跟踪文件相关模块414合并所收集的跟踪文件。在各种实施例中，合并可以包括在单个节点(例如，层级)上合并对应于不同层的跟踪文件，以及合并从不同节点(例如，节点级)接收的跟踪文件。

在框908，跨文件分析模块416可以识别一个或更多跟踪ID，其提供被请求的跨跟踪文件分析的基础。

在框910，跨文件分析模块416可以基于所识别的跟踪ID来确定与所请求的跨跟踪文件分析相关联的KPI是否满足预定等级。

在框912，呈现和通知模块424可以格式化并将请求分析的结果呈现给网络管理员。

在框914，补救动作模块426可以实现解决问题的补救动作。

图10示出了另一示例过程1000的流程图，该另一示例过程1000用于接收跟踪文件，确定跟踪文件中包括的数据的性能度量，以及生成性能度量的图形或文本表示。示例过程1000可以由作为QoE优化系统110的一部分的组件执行。

在框1002，QoE优化系统110可以从参与无线通信的设备接收跟踪文件。跟踪文件至少可以包括与设备的通信协议栈的无线电层相关联的数据。该设备可以是用户设备、电信基站、无线接入点、无线电网络控制器或核心电信网络元件之一。跟踪文件可能与用于测量射频性能的数据收集和诊断记录工具相关联。在一些实施例中，跟踪文件还可以包括与设备的通信协议栈的因特网层、网络层或传输层相关联的数据。或者，QoE优化系统110可以从设备接收另一个跟踪文件(在1002处)，并且另一个跟踪文件可以包括与设备的通信协议栈的因特网层、网络层或者传输层相关联的数据。

在1004，QoE优化系统110可以至少部分地基于与无线电层相关联的数据，针对设备确定与无线电层密钥性能指示符相关联的一个或更多性能度量。无线电层密钥性能指示符可以包括无线电链路控制(RLC)重传、分组丢失、网络信令、无线电资源控制(RRC)状态持续时间、无线电状态转换时间、在不同无线电状态中花费的时间、无线电状态转换的数量、或重新配置响应时间中的至少一个。同样在1004，QoE优化系统110可以至少部分地基于与因特网层、网络层或传输层相关联的数据，针对该设备确定与因特网层、网络层或传输层的关键性能指示符相关联的一个或更多附加性能度量。因特网层、网络层或传输层的关键性能指示符可以包括域名服务(DNS)往返时间(RTT)、传输控制协议(TCP)RTT、超文本传输协议(HTTP)RTT、TCP重传、TCP重复确认、TCP重置、TCP故障、增量帧或序列号中的至少一者。

在1006，QoE优化系统110可以生成一个或更多性能度量的一个或更多图形或文本表示。图形或文本表示包括图形、图表或日志表示中的至少一个(例如参见图12和13)。此外，在1006，QoE优化系统110可以生成一个或更多附加性能度量的一个或更多附加图形或文本表示。

在1008，QoE优化系统110可以基于性能阈值或性能模型中的一个或更多分析数据。在1010，基于分析，QoE优化系统110可以确定无线通信呈现降低的QoE。

图11示出了另一个示例过程1100的流程图，该另一个示例过程1100用于接收一个或更多跟踪文件，使与设备的不同层相关联的跟踪文件数据与不同设备相关，基于阈值或模型分析相关数据，并且确定与相关数据相关联的通信呈现出降低的QoE。示例性过程1100可以由作为QoE优化系统110的一部分的组件执行。

在框1102，QoE优化系统110可以从参与基于分组的无线通信的设备接收跟踪文件。跟踪文件可以包括用于设备的通信协议栈的第一层的第一数据以及用于通信协议栈的第二层的第二数据。基于分组的无线通信可以包括从远程服务或远程站点在用户设备处接收的数据分组。

在1104，QoE优化系统110可以基于由第一数据和第二数据表示的分组的有效载荷来将第一数据与第二数据相关。相关可以包括将第一数据中的有效载荷的表示与第二数据中的有效载荷的表示相关。

在1106，当从参与或中继基于分组的无线通信的多个设备接收到多个跟踪文件时，QoE优化系统110可以将那些跟踪文件相关。

在1108，QoE优化系统110可以基于通信性能阈值或通信性能模型中的一个或更多来分析相关数据。如果多个跟踪文件相关，则QoE优化系统110还可以分析相关的跟踪文件。

在1110，基于分析，QoE优化系统110可以确定基于分组的无线通信呈现出降低的QoE。

在1112，QoE优化系统110可以生成相关数据的图形或文本表示。可替选地或另外，在1114，当基于分组的无线通信呈现降低的QoE时，QoE优化系统110可以提供警报。

图18描绘了根据本公开的实施例的一个或更多客户端设备体验质量(QoE)诊断文件176的示例。在各个实施例中，可以由图1C中的客户端设备QoE模块172生成一个或更多QoE诊断文件176。在一些实施例中，一个或更多客户端设备QoE诊断文件176可以包括与客户端设备102的模块、组件和操作相关的诊断文件，以跟踪设备操作和状态。在一些实施例中，一个或更多QoE诊断文件176可以包含在客户端设备102上生成、聚集和/或收集的信息，从中可以确定客户端设备KPI和/或QoE。一个或更多客户端设备QoE诊断文件176可以以与一个或更多通信或数据交换/格式化协议(例如旨在通过MTN 104进行通信或交换内容的TCP、IP、HTTP或其他协议)相关联的方式被配置。例如，一个或更多QoE诊断文件176可以以基于可扩展标记语言(XML)的格式，诸如JSON(JavaScript对象表示法)进行配置。在一些实施例中，如图1C所示，除了或代替一个或更多客户端设备跟踪文件178，一个或更多QoE诊断文件176可以由客户端设备102发送。在各种实施例中，一个或更多客户端设备QoE诊断文件176可以包括与语音呼叫、视频呼叫和/或包括客户端设备102的数据传输有关的信息。在一些实施例中，一个或更多客户端设备QoE诊断文件176可以包括当进行呼叫时指示客户端设备102的活动或操作的按时间顺序的诊断文件或日志。

在各种实施例中，一个或更多客户端设备QoE诊断文件176可以包括与呼叫状态1802、用户界面(UI)状态1804、一个或更多IP多媒体子系统(IMS)会话发起协议(SIP)消息1806、切换1808、实时传输协议(RTP)统计1810、呼叫设置1812、信号数据1814、无线电带数据1816、位置1818、时间戳1820和/或设备数据1822相关的数据。

在各种实施例中，呼叫状态1802数据可以指示何时尝试进行呼叫、何时建立呼叫(例如，何时呼叫开始振铃)、何时连接呼叫(例如，何时开始语音或视频数据)以及何时断开呼叫。在各种实施例中，在呼叫期间连续地更新呼叫状态1802。

在各种实施例中，用户界面(UI)状态1804可以指示在客户端设备1804的用户界面处接收到的输入。例如，UI状态1804可以指示接收到输入以发起或终止呼叫、静音或保持呼叫、输入电话号码或设备身份、更改音量等。UI状态1804可以跟踪在客户端设备102处接收的一些或全部输入，并且可以反映用户的实际输入或输入尝试。在一些实施例中，UI状态1804可以限于某些应用的数据，诸如配置用于语音或视频呼叫的客户端设备上的应用。在一些实施例中，UI状态1804可以指示来自触摸屏、显示器、触笔或各种按钮(诸如，音量按钮或电源按钮)的接收到的输入。UI状态1804可以指示接收的用户输入是成功还是不成功。UI状态1804还可以跟踪在客户端设备1804的显示器上显示的数据，诸如在呼叫之前、期间或之后显示的屏幕。

在各种实施例中，一个或更多IP多媒体子系统(IMS)会话发起协议(SIP)消息1806可以包括由客户端设备102进行的每个通信的会话信息。一个或更多IMS SIP消息1806可以包括诸如消息类型(例如，文本、数据文件、视频、图像、音乐、音频等)、会话描述协议(SDP)参数和原因代码(例如，响应于操作中的事件的问题消息、状态代码和返回代码)之类的字段。原因代码的示例可以包括指示在操作期间检测到的错误事件的错误消息，或指示在通信操作期间操作成功的消息。

在各种实施例中，切换1808数据可以记录用于通信的切换操作和客户端设备的状态。在一些实施例中，切换1808数据可记录基站之间、接入点之间、或基站和接入点之间的切换操作。例如，切换1808可以指示单个无线电语音呼叫连续性(SRVCC)、电路交换回退(CSFB)、系统间(无线电间接入技术(RAT))移动性(例如，2G/3G和LTE之间的转换)以及LTEX2切换。

在各种实施例中，实时传输协议(RTP)统计1810指示各种分组统计，例如分组丢失、分组延迟、延迟抖动、发送/接收的字节、发送/接收的分组、总字节、总分组、分组丢失率、分组丢弃率、突发丢失率和突发长度、间隙损失率和间隙长度、往返延迟、单向延迟、回声路径延迟、碰撞率等。

在各种实施例中，呼叫设置1812可以指示客户端设备的设置，诸如操作模式或呼叫偏好。例如，呼叫设置1812可以指示是否启用或禁用LTE上语音(VoLTE)，无论WiFi呼叫是优选的还是被允许的，呼叫注册，用户身份模块(SIM)卡供应等。

在各种实施例中，信号数据1814可以包括指示信号强度和/或质量的参数，例如接收信号强度指示符(RSSI)、参考信号接收功率(RSRP)、参考信号接收质量(RSRQ)、信号与干扰加噪声(SINR)比、接收到的信号代码功率(RSCP)、Ec/Io(例如，每芯片接收能量(码位)和干扰电平(以dB为单位)的比率)、信噪比(SNR)等。

在各种实施例中，无线电带数据1816可以指示客户端设备是否正在使用特定带(例如，2、4或12)或载波聚合(例如，2和4)。在一些实施例中，无线电带数据1816可以包括上行链路频率、下行链路频率、带的宽度、双工间隔和/或带隙。

在各种实施例中，位置1818可以指示在通信或通信尝试之前、期间或之后的任何时刻的客户端设备的位置。位置1818可以由GPS位置数据、基站身份或位置源的组合来确定。在一些实施例中，位置1818可以包括组合使用的移动网络代码(MNC)和移动国家代码(MCC)，以唯一地识别移动网络运营商网络。在一些实施例中，位置1818可以包括基站或小区身份、和/或纬度、经度和高度信息。

在各种实施例中，时间戳1820可以唯一地识别包括在一个或更多客户端设备QoE诊断文件176中的一些或所有数据点的时间。在一些实施例中，时间戳1820可以由本地时间源或远程时间源提供。例如，每个操作日志、报告或意图可以具有相关联的时间戳1820。

在各种实施例中，设备数据1822可以指示客户端设备102的设备和/或系统信息，诸如制造商、型号、操作系统、操作版本、硬件组件、软件组件、芯片制造商、升级历史等。设备数据1822还可以指示在客户端设备102上安装或操作的任何应用和/或软件，以及用于任何相关联软件的软件版本。

图19是根据本公开的实施例的用于收集诊断信息、过滤诊断信息和发送客户端设备QoE诊断文件的示例性过程1900的流程图。在一些实施例中，客户端设备QoE诊断文件对应于图1C和图18中的一个或更多客户端设备QoE诊断文件176。例如，示例性过程1900可由客户端设备102执行。

在1902，收集诊断。在一些实施例中，诊断可以包括用于在进一步分析时确定客户端设备KPI和/或QoE的设备报告、操作日志、意图或其他数据。通过客户端设备QoE模块172，可以在客户端设备102中收集诊断。在一些实施例中，客户端设备QoE模块172可以操作为客户端设备102上的后台进程(例如，作为无头进程或无头跟踪收集器)，并且可以从在客户端设备102上运行的硬件和/或软件收集诊断信息、日志、报告或意图(即，通常用于进一步的动作的客户端设备102中的应用之间的消息)。在一些实施例中，以预定的间隔，诸如每5秒、每5分钟、每天、每周或任何其他预定的间隔，收集诊断信息。在一些实施例中，响应于来自QoE优化系统110的请求(例如，周期性请求或按需请求)收集诊断信息。在替选实施例中，客户端设备102可以知道报告安排，并可以根据报告安排主动收集诊断信息。在一些实施例中，响应于诸如发起通信、结束通信的事件，当检测到错误事件或响应于由客户端设备102上操作的应用或软件产生的诊断数据、日志数据或意图而收集诊断。在一些实施例中，要收集的诊断包括结合图18讨论的诊断(或可以包括结合图21讨论的消息)。在一些实施例中，要收集的诊断被生成为用于各种应用、进程或线程的调试文件，并且不由客户端设备QoE模块172生成。在一些实施例中，诊断被各种应用程序被动地收集，该各种应用程序将文件写入到文件夹、文件或目录中，而在其他实施例中，各种组件被主动轮询并收集数据。

在1904，过滤诊断。在一些实施例中，响应于检测到错误消息来执行过滤，而在一些实施例中，基于呼叫状态、呼叫进程或唯一呼叫身份来执行过滤。在一些实施例中，执行过滤以减少要在客户端设备QoE诊断文件中传输的数据量。在一些实施例中，响应于可用带宽、网络上的流量或所检测到的错误的优先级来执行诊断过滤1904。在一些实施例中，执行诊断过滤1904以包括与特定通信(例如，语音呼叫)相关联的所有操作日志、设备报告、诊断文件或意图，或包括与通信位置相关联的所有数据(例如，如果诊断特定位置的根本原因)。例如，可以执行操作1904以过滤和选择设备报告、日志或意图，该设备报告、日志或意图与被监控以用于确定设备QoE的KPI的类型相关。在一个非限制性示例中，客户端设备可以针对语音呼叫生成20个日志并且针对诸如网页浏览的数据呼叫生成10个日志。如果这些日志以混合顺序在客户端设备中报告，则可以执行操作1904以识别用于语音呼叫的日志，并且将要包括在客户端诊断QoE文件中的20个语音呼叫日志分离。在一些实施例中，响应于用户偏好来执行诊断过滤1904。在一些实施例中，诊断过滤1904可以包括对诊断进行匿名化和加密。在一些实施例中，诊断过滤1904可以包括将数据格式化为标准化格式。例如，诊断过滤1904可以包括将在操作1902中收集的多个意图存储为基于可扩展标记语言(XML)的格式，例如JSON(JavaScript对象表示法)。

在1906，发送一个或更多客户端设备QoE诊断文件。在一些实施例中，在设备通信期间或整个设备通信期间实时地发送一个或更多客户端设备QoE诊断文件。可以将一个或更多客户端设备QoE诊断文件发送到图1C的QoE分析器180，例如，当网络流量低时，在最小值时，或者非高峰时间期间。例如，一个或更多客户端设备QoE诊断文件可以仅在当客户端设备102连接到WiFi网络时才被发送，或者可以是当网络流量较低时在夜间发送。在一些实施例中，除了一个或更多客户端设备跟踪文件178以外、或代替一个或更多客户端设备跟踪文件178，一个或更多客户端设备QoE诊断文件176可以被发送到QoE分析器180。

图20是根据本公开的实施例的用于接收和分析设备诊断的示例过程2000的流程图。示例过程2000可以由作为QoE优化系统110的一部分的组件执行，例如由QoE分析器180执行，而在一些实施例中，过程2000中的一些或所有操作可以由客户端设备来执行。

在2002，请求设备诊断。在一些实施例中，QoE分析器180可以从客户端设备102请求诊断。在一些实施例中，请求2002可以包括针对客户端设备设置安排，以将设备诊断发送到QoE分析器180，而在一些实施例中，请求可以是按需请求。在一些实施例中，对设备诊断2002的请求可以指定设备诊断的数量、类型、频率、格式和规范，并且在一些实施例中，请求2002可以包括对一个或更多客户端设备QoE诊断文件的请求。在一些实施例中，请求2002可以响应于对网络问题的识别，诸如由QoE趋势模块186进行的识别(出现了网络问题)。在一些实施例中，请求2002可以响应于客户或用户对QoE降低或减弱的抱怨或报告。

在2004，接收设备诊断。在一些实施例中，设备诊断作为一个或更多客户端设备QoE诊断文件176被接收。例如，可以从客户端设备接收作为JSON XML文件的设备诊断，并且可以包括设备报告、操作日志、设备意图和/或与设备通信有关的信息。在一些实施例中，从单个客户端设备接收多个设备诊断，并且在一些实施例中，从多个客户端设备接收多个设备诊断。在一些实施例中，接收到的设备诊断是在操作1906中发送的一个或更多客户端设备QoE诊断文件。

在2006，从在操作2004中接收的设备诊断确定设备KPI和/或QoE。在一些实施例中，分析设备报告、操作日志、设备意图和/或与设备通信相关的信息，以确定设备KPI，设备QoE从设备KPI确定。例如，如果设备KPI包括“呼叫建立时间”的指示，则分析设备诊断以确定呼叫建立操作中涉及的设备操作和时间戳，从而确定“呼叫建立时间”。作为另一示例，可以基于实时分组协议(RTP)数据(例如RTP丢失率)和SIP消息跟踪数据(诸如编解码器类型和采样率)来预测语音质量设备KPI。如在本公开的上下文中可以理解的，在操作2006中可以确定任何数量的设备KPI。

在2008，设备KPI和/或QoE被聚合。在一些实施例中，在一段时间内针对单个设备聚合设备KPI和/或QoE，而在一些实施例中，针对位置、设备特性或某种其他聚合度量或参数，在一段时间内的单个时间点，针对多个设备聚合设备KPI和/或QoE。在一些实施例中，设备KPI和/或QoE由设备类型、设备位置、QoE问题或接入技术之一进行聚合和索引。例如，针对特定设备的设备KPI和/或QoE被索引以创建特定于设备类型、硬件组件类型、软件组件类型等的KPI和/或QoE的数据库。在另一示例中，针对特定位置的所有设备KPI和/或QoE被聚合，而在另一示例中，可以聚合针对QoE问题(例如增加的掉话率)的设备KPI。在一些示例中，可以根据接入技术(例如2G/3G、LTE、VoLTE、Wi-Fi呼叫等)对设备KPI和/或QoE进行索引。在一些实施例中，设备诊断文件在确定设备KPI和/或QoE之前被聚合。

在2010，确定网络KPI。在一些实施例中，可以基于由QoE分析器180接收的跟踪文件174或180来确定网络KPI。在一些实施例中，网络KPI可以指代QoS数据。在一些实施例中，网络KPI可以类似于在客户端设备102处经历的客户端设备KPI和/或QoE。

在2012，将在2006确定的设备KPI和/或QoE与在2010处确定的网络KPI进行比较。在一些实施例中，可以执行比较操作2012以检测任何降低的或减弱的QoE问题。例如，可以基于在2006确定的设备KPI和/或QoE来确定掉话率，而掉话率也可以基于在2010确定的网络KPI来确定。在一些实施例中，设备掉话率可以与网络掉话率比较。在一个示例中，低于设备掉话率的网络掉话率可以指示降低的或减弱的QoE的可能性。

在2014，将设备KPI和/或QoE与聚合的设备KPI和/或QoE进行比较。在一些实施例中，将用于单个设备的设备KPI和/或QoE与聚合的设备KPI和/或QoE进行比较，该聚合的设备KPI和/或QoE与单独设备相关联。在一些实施例中，将用于单个设备的设备KPI和/或QoE与聚合的设备KPI和/或QoE进行比较，该聚合的设备KPI和/或QoE与多个客户端设备相关联。

下面描述过程2000的示例。作为示例，第一客户端设备102可以在第一位置处经历掉话(例如，降低的或减弱的QoE)。第一客户端设备102可以发送指示掉话时客户端设备情况的一个或更多客户端设备QoE诊断文件176(例如，操作日志、设备意图、设备报告)。QoE分析器180可以接收一个或更多客户端设备QoE诊断文件176(例如，操作2004)，可以在操作2006中确定设备KPI和/或QoE，并且可以将确定的客户端设备KPI和/或QoE与QoE分析器180先前从多个客户端设备接收和确定(例如，操作2006和2008)的聚合的设备KPI和/或QoE进行比较。在该示例中，聚合的设备KPI和/或QoE可以由设备类型、QoE问题和/或客户端设备位置索引。因此，将指示第一位置处的掉话(例如，减弱的QoE)的第一客户端设备KPI和/或QoE与聚合的设备KPI和/或QoE进行比较(例如，操作2014)，该聚合的设备KPI和/或QoE与第一位置相关。

在2016，确定了QoE减弱的根本原因。在上面的示例中，将来自第一客户端设备的设备KPI和/或QoE与聚合的设备KPI和/或QoE进行比较，以确定在第一位置处掉话的根本原因。在该示例中，第一位置处的第一客户端设备的信号强度在掉话前可能已经较低。通过将第一客户端设备所经历的信号强度与聚合的设备KPI和/或QoE进行比较，可以确定根本原因。例如，如果第一位置处的聚合的设备KPI和/或QoE也显示了低信号强度，则该数据可以暗示在第一位置处的信号强度较低，并且接收可能需要被升级(例如，由一个服务提供商)。然而，如果第一位置处的聚合的设备KPI和/或QoE指示信号强度没有减弱或降低(例如，其他设备没有类似的问题)，则减少的QoE的根本原因可以是第一客户端设备。在一些实施例中，如果参数低于性能阈值或模型，或低于经由聚合的设备诊断确定的可接受的平均值或者中值，则可将参数视为“低”。

在另一示例中，聚合的设备KPI和/或QoE(例如，在操作2008中被聚合)可以指示减少的QoE。在一些实施例中，聚合的设备KPI和/或QoE可以由设备模型或操作系统版本索引。在一个示例中，可以确定具有特定操作系统版本的设备可能正在经历减少的QoE。在这种情况下，可以确定(例如，在操作2016中)QoE的根本原因是特定的操作系统版本。在另一示例中，减少的QoE可能是特定于设备类型的。在这种情况下，QoE减少的根本原因可能是设备类型。

在另一示例中，聚合的设备KPI和/或QoE可以由位置索引。如果聚合数据显示在特定位置(或特定位置处和特定时间)处的问题趋势，则可以确定QoE的根本原因(例如，在操作2016中)为常规或暂时的网络问题。

在一些实施例中，可以在不参考聚合的设备KPI和/或QoE的情况下确定减少的QoE的根本原因(例如，在操作2016中)。在一个示例中，一个或更多客户端设备QoE诊断文件176可以指示进行呼叫尝试(例如，呼叫状态＝尝试)，随后是“未供应”的错误代码(例如，呼叫设置＝未供应)，随后客户端设备断开连接的指示(例如，呼叫状态＝断开连接)。在这样的示例中，可以在2016确定QoE减小的根本原因是未提供SIM卡。此外，在一些实施例中，QoE分析器180可以通过向客户端设备发送软件更新来执行自我修复，以便提供SIM卡，由此纠正错误。

作为另一示例，可以通过查看一个或更多客户端设备QoE诊断文件176来确定减少的QoE的根本原因(例如，在操作2016中)。在一个示例中，一个或更多客户端设备QoE诊断文件176可以包括反映在客户端设备通信中使用编解码器的操作日志(或设备报告或意图)。客户端设备QoE诊断文件可以指示在呼叫失败之前发生编解码器切换操作。在这种情况下，可以将编解码器转换操作确定为减少QoE的根本原因。此外，在本公开的上下文中可以理解，在该示例中，基于网络的KPI可能无法确定该减少的QoE的根本原因，因为编解码器转换可能对于基于网络的KPI不透明。

图21是根据本公开的实施例的用于生成和/或发送诊断消息的示例过程2100的流程图。例如，示例过程2100可以由客户端设备102执行。

过程2100可以包括生成和/或发送消息2102-2116中的一些或全部消息。在一些实施例中，在检测到触发事件发生时，诊断消息2102-2106可以不是顺序地生成和/或发送而是单独生成和/或发送。在一些实施例中，消息2102-2116可以对应于一个或更多客户端设备QoE诊断文件176。在一些实施例中，消息2102-2116可以在单个客户端设备QoE诊断文件中单独生成并且发送。描述操作/消息的顺序不旨在被解释为某种限制，并且任何数量的所描述的操作可以以任何顺序和/或并行地组合以实现该过程和/或发送本文中所描述的消息。

在2102，可以生成和/或发送呼叫状态消息。在各种实施例中，当语音呼叫的状态改变时，可以生成和/或发送呼叫状态消息。呼叫状态的变化可以包括以下呼叫状态的改变或者从以下呼叫状态的改变：ATTEMPTING、ESTABLISHED、CONNECTED、DISCONNECTING、HELD、ENDED、INCOMING、MUTED、UNMUTED、CSFB_STARTED、CSFB_SUCCESSFUL、CSFB_FAILED、SRVCC_STARTED、SRVCC_SUCCESSFUL、SRVCCC FAILED、ASRVCC_STARTED、ASRVCC_SUCCESSFUL、ASRVCC_FAILED、EPDG_HOSTARTED、EPDG_HO_SUCCESSFUL、和/或EPDG_HO_FAILED(尝试、已建立、已连接、断开、保持、结束、呼入、静音、取消静音、CSFB开始、CSFB成功、CSFB失败、SRVCC-开始、SRVCC_成功，SRVCCC_失败、ASRVCC_开始、ASRVCC_成功、ASRVCC_失败、EPDG_HO_启动、EPDG_HO_成功、和/或EPDG-HO_失败)。

在2104，生成和/或发送用户界面(UI)状态消息。在各种实施例中，当呼叫的UI状态改变时，可以生成和/或发送UI状态消息。在一些实施例中，仅在主动语音呼叫会话期间生成和/或发送UI状态消息。UI状态的改变可能包括对以下UI状态的更改：CALL PRESSED,END_PRESSED,MUTE_PRESSED,UNMUTE_PRESSED,HOLD_PRESSED,UNHOLD_PRESSED,CALL_CONNECTED,CALL_DISCONNECTED,RINGING,以及SCREEN_ON,SCREEN_OFF(呼叫_已按压、结束_已按压、静音_已按压、不静音_已按压、保持_已按压、未保持_已按压、呼叫连接、呼叫断开、响铃和屏幕_打开，屏幕_关闭)。

在2106，可以生成和/或发送切换状态消息。在各种实施例中，当正在进行的呼叫从连接到网络的一个信道传输或切换到另一个信道时，可以生成和/或发送切换状态消息。在一些实施例中，仅在主动语音呼叫会话期间生成和/或发送切换状态消息。切换状态消息可以利用以下切换状态信息中的一个或更多进行发送：INTER_HO_STARTED,INTER_HO_FAILED,INTER_HO_SUCESSFUL，INTRA_HO_STARTED,INTRA_HO_FAILED,INTRA_HO_SUCCESSFUL，以及MEASUREMENT_REPORT_DELIVERED(INTER_HO_启动、INTER_HO_失败、INTER_HO_成功、INTRA_HO_启动、INTRA_HO_失败、INTRA_HO_成功以及已传送测量报告)。

在2108，生成和/或发送信令消息。在各种实施例中，信令消息可以指示在主动分组交换语音呼叫期间，客户端设备102何时传送或发送IP多媒体子系统(IMS)会话发起协议(SIP)消息。在一些实施例中，信令消息可以包括信令消息中的IMS SIP消息的内容。

在2110处，生成和/或发送实时传输协议(RPT)下行链路(DL)消息。在一些实施例中，可以在主动呼叫期间以规律的调度间隔生成和/或发送RPT DL消息。在一些实施例中，RTP DL消息可以包括RTP DL丢失率、RPT DL延迟(例如，在流中所选择的分组之间的端到端往返延迟)、RTP DL抖动(例如，由于网络拥塞、不当排队或配置错误而导致的分组之间的延迟)和/或RTP DL测量周期。

在2112，生成和/或发送RTP上传消息。在一些实施例中，RTP上传消息可以包括类似于RTP DL消息的统计，但是针对上行链路分组。

在2114，生成和/或发送应用程序调用消息。在各种实施例中，应用程序呼叫消息指示移动始发呼叫何时发起。在各种实施例中，应用程序调用消息可以指示在客户端设备上发起呼叫的特定应用程序。

在2116，生成和/或发送加密消息。在各种实施例中，加密消息指示客户端设备何时完成与网络协商加密方案。

以下提供过程2100的示例。为了在第一客户端设备处发起语音呼叫，用户按下第一客户端设备的用户界面中的“发送”按钮。在这样的示例中，消息2104可以由第一客户端设备生成(例如，指示“呼叫-已按压”)。接下来，第一客户端设备可以在第一客户端设备中运行的应用程序中发起语音呼叫，并且可以生成指示呼叫状态(例如，“尝试”)的消息2102。与发起语音呼叫一起，第一客户端设备向网络发送请求，网络响应第一客户端设备：已建立语音呼叫，并且第一客户端设备开始输出回铃音。因此，第一客户端设备可以生成消息2102(例如，“已建立”)。第二客户端设备可以应答来自第一客户端设备的语音呼叫请求，因此，第一客户端设备可以生成指示更新的呼叫状态(例如，“已连接”)的消息2102。当进行语音呼叫时，第一客户端设备监控上行链路和/或下行链路，并且生成指示连接状态的消息。例如，第一客户端设备可以接收在特定时间段内从第二客户端设备发送的100％的语音分组，并且可以生成指示分组的百分之零的丢失的RTP DL消息2110。在随后的时间段内，第一客户端设备可以接收从第二客户端设备发送的75％的语音分组，并且可以生成指示25％的丢失的RTP DL消息2110。接下来，第一客户端设备可以发起到3G网络的切换，并且可以生成指示该转换的切换状态消息2106(例如，“INTER-HO启动”)。在该示例中，在切换成功之后(并且生成指示“INTER-HO-成功”的消息2106)，该呼叫可能被丢弃，并且第一客户端设备生成指示该状态(例如，“已断开”)的切换状态消息2106。如在本公开的上下文中将理解的，这些消息可以被实时发送，或者可以被组合成单个报告(例如，格式化为单个JSON容器的客户端设备诊断文件)，并且可以被发送到网络节点(例如，在夜间)进行分析，以确定第一客户端设备KPI和/或QoE。如将在本公开的上下文中进一步理解的，该示例是示意性的，并且语音呼叫可以包括任何数量的所生成的消息。

如上所述，图22-24是根据本公开的实施例的聚合的设备QoE度量的图形表示的示例。在一些实施例中，图形表示2200、2300和2400可以由QoE分析器180针对单个客户端设备102确定、或者可以针对表示在一段时间内多个设备的聚合数据，由QoE分析器180和/或QoE趋势模块186确定。在图22中，图形表示2200是对每个区域或市场的设备掉话率的分析。在图23中，图形表示2300是根据设备模型和掉话源索引的掉话率的曲线图。在图24中，图形表示2400是在一段时间T1、T2、T3、T4和T5中通过接入技术索引的掉话率的曲线图。还可以或代替地生成客户端设备QoE的任何数量的其他类型的图表或者示图。

结论

虽然已经以特定于结构特征和/或方法动作的语言对主题内容进行了描述，但是应当理解，所附权利要求中限定的主题内容不一定限于所描述的特定特征或动作。而是，特定特征和动作被公开为实现权利要求的示例性形式。

Claims (20)

1.一种方法，包括：

从客户端设备接收至少一个诊断文件，所述至少一个诊断文件指示所述客户端设备的操作日志；

分析所述至少一个诊断文件，以确定所述客户端设备的设备体验质量QoE；

基于所述至少一个诊断文件，确定所述客户端设备的降级QoE事件；以及

至少部分地基于所述至少一个诊断文件，确定所述降级QoE事件的位置。

2.根据权利要求1所述的方法，其中所述至少一个诊断文件包括状态信息和位置信息，所述状态信息指示针对语音通信的所述客户端设备的状态，所述位置信息指示针对所述语音通信的所述客户端设备的位置。

3.根据权利要求2所述的方法，其中所述状态信息至少包括与掉话相关联的错误消息，并且其中所述位置信息包括所述客户端设备在所述掉话时的位置。

4.根据权利要求1所述的方法，还包括分析所述至少一个诊断文件，以确定所述客户端设备的第一掉话率。

5.根据权利要求4所述的方法，还包括：

确定所述客户端设备的网络关键性能指示符KPI；

分析所述客户端设备的网络KPI，以确定所述客户端设备的第二掉话率；以及

比较所述第一掉话率和所述第二掉话率，以确定掉话率差。

6.根据权利要求1所述的方法，还包括：

从多个客户端设备中的每一者接收至少一个诊断文件，所述多个客户端设备包括所述客户端设备；

部分地基于与所述多个客户端设备中的每一者相关联的所述至少一个诊断文件，确定所述多个客户端设备中的每一者的至少一个设备QoE；

聚合来自所述多个客户端设备中的每一者的所述至少一个设备QoE，以形成聚合的设备QoE；以及

分析所述聚合的设备QoE，以确定至少一个QoE趋势。

7.根据权利要求6所述的方法，还包括根据设备类型、设备位置、QoE问题或接入技术中的至少一个来对所述聚合的设备QoE进行索引。

8.根据权利要求1所述的方法，还包括对所述至少一个诊断文件进行匿名化和加密。

9.一种或更多种非暂时性计算机可读介质，具有存储在其上的计算机可执行指令，当所述计算机可执行指令由计算设备执行时，使所述计算设备执行操作，所述操作包括：

从客户端设备接收至少一个诊断文件；

分析所述至少一个诊断文件，以确定所述客户端设备的设备体验质量QoE；

基于所述至少一个诊断文件，确定所述客户端设备的降级QoE事件；以及

确定所述降级QoE事件的位置。

10.根据权利要求9所述的一种或更多种非暂时性计算机可读介质，其中所述至少一个诊断文件包括状态信息和位置信息，所述状态信息指示针对语音通信的所述客户端设备的状态，所述位置信息指示针对所述语音通信的所述客户端设备的位置。

11.根据权利要求10所述的一种或更多种非暂时性计算机可读介质，其中所述状态信息至少包括与掉话相关联的错误消息，并且其中所述位置信息包括所述客户端设备在所述掉话时的位置。

12.根据权利要求9所述的一种或更多种非暂时性计算机可读介质，其中所述操作还包括分析所述至少一个诊断文件，以确定所述客户端设备的第一掉话率。

13.根据权利要求12所述的一种或更多种非暂时性计算机可读介质，其中所述操作还包括：

确定所述客户端设备的网络关键性能指示符KPI；

分析所述客户端设备的网络KPI，以确定所述客户端设备的第二掉话率；以及

比较所述第一掉话率和所述第二掉话率，以确定掉话率差。

14.根据权利要求9所述的一种或更多种非暂时性计算机可读介质，其中所述操作还包括：

从多个客户端设备中的每一者接收至少一个诊断文件，所述多个客户端设备包括所述客户端设备；

部分地基于与所述多个客户端设备中的每一者相关联的所述至少一个诊断文件，确定所述多个客户端设备中的每一者的至少一个设备QoE；

聚合来自所述多个客户端设备中的每一者的所述至少一个设备QoE，以形成聚合的设备QoE；以及

分析所述聚合的设备QoE，以确定至少一个QoE趋势。

15.根据权利要求9所述的一种或更多种非暂时性计算机可读介质，其中所述操作还包括根据设备类型、设备位置、QoE问题或接入技术中的至少一个来对所述聚合的设备QoE进行索引。

16.根据权利要求9所述的一种或更多种非暂时性计算机可读介质，其中所述操作还包括对所述至少一个诊断文件进行匿名化和加密。

17.一种系统，包括：

一个或更多处理器；

存储器；

一个或更多模块，存储在所述存储器中，并且能够由所述一个或更多处理器执行，以执行操作，所述操作包括：

从客户端设备接收至少一个诊断文件，所述至少一个诊断文件指示所述客户端设备的操作日志；

分析所述至少一个诊断文件，以确定所述客户端设备的设备体验质量QoE；

基于所述至少一个诊断文件，确定所述客户端设备的降级QoE事件；以及

至少部分地基于所述至少一个诊断文件，确定所述降级QoE事件的位置。

18.根据权利要求17所述的系统，其中所述至少一个诊断文件包括状态信息和位置信息，所述状态信息指示针对语音通信的所述客户端设备的状态，所述位置信息指示针对所述语音通信的所述客户端设备的位置。

19.根据权利要求18所述的系统，其中所述状态信息至少包括与掉话相关联的错误消息，并且其中所述位置信息包括所述客户端设备在所述掉话时的位置。

20.根据权利要求17所述的系统，其中所述操作还包括：

从多个客户端设备中的每一者接收至少一个诊断文件，所述多个客户端设备包括所述客户端设备；

部分地基于与所述多个客户端设备中的每一者相关联的所述至少一个诊断文件，确定所述多个客户端设备中的每一者的至少一个设备QoE；

聚合来自所述多个客户端设备中的每一者的所述至少一个设备QoE，以形成聚合的设备QoE；以及

分析所述聚合的设备QoE，以确定至少一个QoE趋势。