在机顶盒中安插代理器刺探IPTV用户体验质量

　  IPTV已进入商用阶段，其市场亦在蓬勃发展。与此同时，消费者期望IPTV能够提供与竞争性服务相当、甚至是更优异的服务质量(QoS)，而这已成为IPTV能否成功的关键所在。预计未来几年内，IPTV市场将达数十亿美元的规模；但对于那些没能融入这股发展潮流的公司来说，很可能成为外面的看客。

　　简单地增加原始带宽，并不能确保提供这种交互式电视服务所需的网络性能。观众对电视的容忍程度与对互联网接入的容忍程度并不相同。例如，用户能够容忍甚至预料互联网接入偶尔出现掉线状况。但是，若你提供的电视画面质量欠佳，或象互联网接入那样偶尔出现信号传输中断，你将被无数怒不可遏的用户的投诉电话所淹没，催使你尽快解决问题。这种情况一旦出现次数过多，大批观众/客户便会弃你而去。因此，网络性能保证已成为任何IPTV服务设计的成功要素。

　　弄清终端用户的体验质量(QoE)或其体验的服务质量(QoS)，是了解什么令用户对提供的服务感到不快的唯一方法；而了解体验质量与网络故障具有怎样的关联，是运营商借以把握怎样使用户满意、需要在哪些方面作出改进以及服务正以何种方式提供给用户的不二选择。但是，如果不能洞察用户从电视机获得的体验，就不可能实现出色的用户体验质量。

　　视频质量评估模型及其演变

　　虽然很早就涌现出来了一些评估用户会有何种体验的方法，但它们仅是基于服务提供商网络核心情况的简单推论——最好的情况下，也只是一种自圆其说的猜测。真正需要的是一种能从用户居家查明问题所在的方法。服务供应商必须能以某种方式直接深入用户室内查找问题。换句话，理想的情形是——用户客厅内的机顶盒(STB)能向服务提供商报告说，某用户家中出现了问题，以及具体是哪类问题。

　　就视频质量评估进行的许多研究已聚焦到一种“双端(dual ended)”模型上。这种双端模型(J.144)需要将受损信号与视频源进行对比。视频数字化、压缩、流传送(streaming)、网络传输和解压缩(见图1)等各种复杂处理过程，都可能导致视频受损。

　　对于在开发实验室内工作、能同时引入视频源和受损视频的的大多数工程师来说，这种双端模型能够满足他们的需求。但当视频源与受损视频相隔数里，如在向用户家中传输IPTV的场合，该模型就不再实用。此外，它的扩展性欠佳。而且，当需要从不同地点对通过IP网络将数百套IPTV节目向数百万用户发送的情况进行实时分析时，其对计算机实时处理能力的要求将使这样一种方案的实施和维护的成本非常昂贵。

　　近期进行的几项研究则试图定义一种完全无需参考的模型。对于VoIP来说，这样一种模型已存在数年，且由国际电信联盟(ITU)将其批准为G.107标准。这种VoIP模型也称为E-Model，它不需将任何“广为人知”的源置入网络中，以评估VoIP的质量。这种模型也被称作“非强加(non intrusive)”模型。

　　而在IPTV方面，也出现了一项专门针对其进行设计的技术——V-Factor。

　　这项正在申请专利的技术借鉴了几家实验室在过去10年间开发的运动图象质量标准(MPQM)研究成果。

　　MPQM是一种实时评估视频质量的单端模型。

　　MPQM模型不需任何“广为人知”的源并以与E-model评估VoIP质量相同的方式给视频质量打分。MPQM基于人类视觉系统(Human Vision System)，已将视频源在压缩、传输和解压缩这一整个处理过程中对图像质量(由人的视觉器官和相应脑神经感知)弱化的影响考虑在内)，而不是仅依靠核心网络的缺陷来推算视频质量。

　　导致视频质量降低的伪信号(artifact)大部分来自压缩本身，而诸如抖动、包丢失(packet loss)等网络故障也会造成视频质量下降。该模型的好处显而易见——能方便地整合进内容和传输链，甚至是嵌入在机顶盒内，而不是仅适用于实验室研究。这样一来，端对端的视频质量评估成为现实。

　　那么，MPQM与V-Factor具体有什么关联呢？V-Factor是对MPQM模型的实现。

　　V-Factor除了提供视频质量评分，还提供视频质量监控和问题根源诊断所需的额外信息。V-Factor提供的信息中，除了在欧洲电信标准化协会(ETSI) TR 101290中定义的广为人知的传输流关键参数(KPI)外，还包括与ITU Y1540/1541或互联网工程任务组(IETF) RFC2330定义的与网络层性能相关的参数。

　　为MPQM提供影响视频质量的参数

　　要展开工作，须为MPQM提供若干参数：包丢失率(PLR)、图像熵值(图像承载的信息量)、网络抖动、网络损耗和程序时钟参考(PCR)抖动。这里利用到了EPFL及其它实验室的成果，还考虑了MPEG2或H.264等编解码器类型因素。

　　包丢失率是从网络和流传送损伤及用于图像压缩的缓冲器的深度推导出的。图像熵值的计算也考虑了若干因素，如将被或已被抖动或丢帧影响的视频帧的属性等，其中I、B和P帧丢失对终端用户接收到的视频质量的影响各不相同。它还考虑了帧的相对大小及GOP大小。在以GOP=1压缩的视频流中丢失的一个I帧的影响与以GOP=12压缩的视频流中丢失的一个I帧的影响不同。GOP描述I、B和P帧的顺序；而I帧的部分或全部丢失，会使下一个相关的B和P帧的重构非常困难。从信息的角度，I帧拥有比B或P帧更大的熵值。

　　采用这样一种模型，就能够方便地针对诸如视频点播(VoD)这样的单点视频流或类似IPTV这样的多点视频流，部署端对端的监测系统。通过将非强加的硬件探针部署在网络中的不同位置，IPTV服务提供商能轻易地监测其整个服务流程的性能。即便是内容提供商提供的视频流，也能通过诸如ASI这样的接口进行监控。通过在机顶盒中配置一个V-Factor代理器，就能够方便地对用户家中遇到的体验问题进行诊断和修复。

　　V-Factor能为IPTV服务提供商提供自定义的KPI和SLS监测，它还提供一个先进的告警系统。该系统不仅为视频流(图像冻结，定义阀值下的V-Factor)，同时也为音频流提供实时信息。

　　将V-Factor技术嵌入机顶盒

　　即使在一年前，将此类网络保障措施直接设计进用户的机顶盒中还无法成为一种选择。但这种能力现已成为现实。例如，QoSmetrics近期宣布，其用于确保核心IPTV性能的V-Factor技术，现可直接嵌入用户的机顶盒中，以实现真实的端对端IPTV性能保证。

　　正如前面所指出的，需为V-Factor背后的MPQM模型提供用户家中的机顶盒容易收集的实时信息和参数，该模型才能工作。典型的参数包括音视频缓冲器的大小。这些缓冲器的大小，将帮助MPQM模型计算机顶盒能够处理信息流中视频和音频部分的多少抖动。而告知该模型系统是否采用了诸如前向纠错(FEC)等包丢失掩饰技术，同样非常重要。

　　然后，该模型需访问某些实时数据。这些实时数据与IP层、MPEG2TS层或RTP层(当选用的是RTP协议时)相关。从机顶盒内收集实时数据有几种不同方法。一种带有直接API的V-Factor库即将发布，可将其看作一个包装程序(需将全部IP包转发至API的应用程序)，也可看作一个通过坐落在网络驱动器与较高层间的直接传送(pass through)模块。

　　根据机顶盒的软件架构，可将电视的统计数据甚至是通过本地配置收集的数据提供给V-Factor库。为了适应大多数机顶盒供应商的需要，V-Factor库具有极大灵活性。实时收集的信息包括每一时间间隔(从10秒到1分钟)内的I、B和P帧的数量以及相同时间内的Quantiser_Scale(量子化器度量)平均值。为测量某些丢失数据对视频质量的影响，就要为该模型提供真实的包丢失统计数据；相关数据也可由API提供。

　　另外，可从检测到的抖动(IP抖动或PCR整体抖动)，使用Markov模型直接评估包丢失。代码大小与使用的各版API有很大关系，也与操作系统环境有关。在类似Linux这样的环境中，包括全部选项及根据统计连接起来的库在内的代码大小在2MB以内。通过采用一个动态连接的共享库，可轻易地将代码大小缩小6倍。

　　当需将V-factor整合进IPTV路由器或一台支持IPTV的DSLAM时，还提供有一个通用库。该库为多个电视频道实时提供全被动(full passive)视频监控能力。

　　服务质量和网络监控不仅是网络运营的关键组成部分，对于实现业务持续发展——包括营业收入、客户挽留和增长保证，也具有重要意义。成功的服务提供商都认识到，积极主动的监控必须在整个服务期间周而复始地进行，要从其决定评估网络能力、启动新的IPTV服务那一刻起，贯穿部署、试运行、运行，直至向用户提供服务等级协议(SLA)这一整套环节。

　　要持续提高评估精度，就得采用深入网络进行检测的工具，而非简单告知服务是否正在进行。合适的工具需具有穷追不舍的能力，以将故障精确定位至具体设备或应用(无论其身处网络核心或家中)，还要具有完全评估包丢失、抖动、延时及其它指标的能力，这些指标对通过IP传输的视频质量有显著影响。针对IPTV这样一个正在茁壮成长的市场，在用户机顶盒中安插一个“代理器(agent)”，将是确保真实的端对端高质量IPTV性能的一种意义深远的方法。