基于电信IPTV的服务质量监测与实现

熊 雄，刘 新，叶德建

(复旦大学软件学院宽带网络与互动多媒体实验室，上海 20120 3)

基于电信IPTV的服务质量监测与实现

熊 雄，刘 新，叶德建

(复旦大学软件学院宽带网络与互动多媒体实验室，上海 20120 3)

信息化网络的高速发展对于网络的服务质量提出更高的要求，但目前国内缺少一套行之有效的服务质量监测系统来对IPTV网络质量进行评估，网络数据包的抓取与分析对于网络服务质量监测必不可少，而现有的网络服务质量监测系统是以解码器输出的数据作为网络数据进行分析，解码器对于流媒体数据的纠错会使得评估不准确。同时机顶盒作为IPTV的载体，内存和CPU的性能远不及PC，导致现有的PC抓包软件根本无法在机顶盒上运行。针对这一现状，基于用户体验质量的评估，考虑到IPTV上流媒体数据和各种控制协议的组合，采用状态机处理数据组合中的各种逻辑，计算丢包率、MDI指标、请求响应时延等参数供服务质量监测使用，并与传统网络服务质量监测进行实验对比，结果证明了监测系统的准确性。

电信网络电视；服务质量；机顶盒；网络抓包；用户体验质量；状态机

1 概述

随着信息化网络高速发展，网络电视(Internet Pr otocol Television, I PTV)的应用已经成为国内网络发展的主流趋势，而这也对网络的服务质量提出了更高的要求，如何提高IPTV服务质量这一问题现已成为业界关注的焦点。由于IPTV是电视类的媒体业务，用户希望得到如同有线电视的服务水平，包括频道切换速度、节目的图像质量、播放的流畅性等。而传统的宽带业务质量监测侧重于数据链路层和网络层的监测，无法直接反映用户对IPTV业务的主观感受，因此不能满足IPTV质量监测的需求[1]。

为了保证IPTV业务的高效运营，端到端的服务质量保障是电信运营商的强烈需求，但无论是视频质量管理还是IP网络资源管理，对电信运营商而言都是全新的挑战，IPTV服务质量保障的最终目标是提供理想的用户体验[2]。在传统的电信业务中服务质量(Quality of Service, QoS)通常指网络性能，尤其是网络传输性能。但IPTV是一种上层应用的业务，这使得传统的QoS根本无法满足对最终用户感受的评估。目前业界往往采用体验质量(Quality of Experience, QoE)一词来描述面向最终用户应用的业务质量。QoE在ITU-T P.10/G.100[3]中被定义为最终用户对使用的应用或业务的总体主观可接受程度，可见QoE相比QoS更强调最终用户的业务使用感受。

文献[4]采用模糊理论的方法计算QoE到QoS的映射。文献[5]综述了用户体验质量的模型与评价方法等方面的工作，介绍了QoE领域的研究现状和进展。文献[6]则概述了IPTV几种常见的QoE业务质量指标。文献[7]在理论层面上对于IPTV质量监测进行了框架性的描述。目前对于IPTV的服务质量进行监测还只是停留在理论阶段，在此前提下，本文参考电信IPTV的规范，在对QoE的研究基础上，通过对网络原始数据包的抓取与分析达到对IPTV服务质量的监测。

2 IPTV服务质量监测的设计思路

2.1 设计目标

主观QoE主要是用户对IPTV业务使用中的主观感受，这些感受是对服务接入速度、内容质量、使用操作便利性等多方面的综合，如视频内容的清晰度和流畅程度；直播频道的切换速度；VOD节目进行快进、快退和暂停操作的响应速度；业务请求的响应速度、业务内容的完整性等。

监测系统的设计目标是：通过对网络包的实时监控，获取数据包丢包率、媒体传输指标(Media Del ivery Index, MDI)、请求响应时延(Request Response Time, RRT)等QoS参数，并将参数与IPTV中对于直播和点播中的各种操作进行组合，以便对于IPTV服务质量作出总体上的评估。同时模块具有以下特性：

(1)准确性：对于数据包的抓取和分析可以准确地反映网络质量的变化情况。

(2)可控性：监测系统在可接受的CPU和内存消耗范围内运行。

(3)实时性：监测系统必须实时地反映网络变化情况，这一点也在准确性中体现。

2.2 系统设计

整个IPTV服务质量监测系统分为3个部分：QoSCapture, QoSAnalyser和QoSLoader。整体布局如图1所示。

图1 IP TV监测系统

QoSCapture在整个监测系统中负责网络抓包的任务，并将抓取到的数据包信息整理后传递给QoSAnalyser，再由QoSAnalyser以统一的格式写入CSV文件并将文件上传至日志服务器，QoSLoader则负责控制QoSAnalyser和QoS Capture的运行并从更新服务器获取机顶盒配置文件的更新信息。这3个模块均在机顶盒上运行。本文着重介绍QoS Capture模块的设计。

考虑到在流媒体实时传播中，数据包与各种控制协议的配合，QoSCapture只抓取特定的数据包进行分析。为了抓取本地向网络发送的控制包，首先将网卡设置为混杂模式，然后根据IP地址在抓取到的数据包中筛选出和本机相关的包进行分析。抓取的数据包类型主要包括Internet组管理协议(Internet Group Management Protocol, IGMP)、传输控制协议(Transmission Control Protocol, TCP)、用户数据包协议(User Datagram Protocol, UDP)包。其中，IGMP[8]包用来传输组播命令；TCP[9]包根据不同的控制协议又分为：超文本传送协议(Hypertext T ransport Pro tocol, HTTP)和实时流传输协议(Real Time Streaming Protocol, RTSP)包，HTTP[10]用来传输认证信息和网页请求，RTSP[11]包用来传输点播命令；UDP包中只对使用实时传输协议[12](Real-time Transport Protocol, RTP)的流媒体数据包进行分析。

在整个抓包过程中，为了得到更准确的监控信息，QoS Capture按照电信提供的IPTV3.0规范对抓取的包按照控制协议进行归类，分别统计组播和点播下流媒体数据包的传输情况，并且将对于使用HTTP协议传输的数据包需要统计失败的次数以及失败的原因。设计中QoSCapture使用状态机来统计不同数据之间的组合。

2.2.1 质量监测描述

在质量监测系统中，QoSCapture需要对具体的数据信息做如下统计：

(1)在程序中，以5 s为一个统计周期，播放视频时每一统计周期需要向QoSAnalyser发送该周期的数据统计信息。如果此时处于正常播放状态，则发送该周期统计数据，包括周期开始和结束时间、收到的数据包数、丢包数、数据量、最大最小PCR值等；如果处于暂停、快进、快退状态，则发送一个填充包。如果一个统计周期内既有正常播放也有暂停、快进或快退操作，则舍弃该周期内的统计数据，只发送一个填充包。视频结束播放时通知QoSAnalyser。小窗口不统计。

(2)对每一股视频流，记录其类型(组播或点播)及请求响应时间(RRT)。组播请求响应时间从发送IGMP开始，到收到第一个视频包结束。点播请求响应时间从发RTSP请求开始，到收到第一个视频包结束。根据电信规范时移电视RRT不统计，且存在请求响应时间超过一定阈值从而认为其请求失败的情况，但为使QoSAnalyser能对属于该视频流的数据信息进行处理，每一股视频流都需要在其第一笔统计周期信息被发送给QoSAnalyser之前先发送一个记录其RRT的结构体，根据结构体内容可区分上述3种情况。

(3)在收到HTTP包时进行分析记录，以帮助QoS Analyser统计HTTP请求次数、HTTP请求失败次数、认证次数、认证失败次数。

(4)帮助QoSAnalyser统计其他信息，如视频播放过程中(包括组播和单播)的数据出错，导致无法再播放的次数。

(5)QoSCapture还需要定义时钟来驱动QoSAnalyser定时生成和上报CSV文件。

(6)QoSCapture还需要记录当前机顶盒的工作状态，据此处理抓获的网口数据并与QoSAnalyser交互，并且根据网口数据的分析结果维护和更新机顶盒工作状态。

2.2.2 状态机的设计

根据流媒体传输过程中的实际情况，网口抓包模块使用状态机描述各种数据包之间的组合，状态机的设计如下：

(1)idleState

空闲状态，机顶盒不播放任何视频，例如用户正在浏览EPG页面。

(2)multicastWaitDataState

组播发出第一个IGMP join包后转到该状态；在该状态收到第一个数据包后可以计算该组播流的RRT，并转到multicastPlayingState状态。

(3)multicastPlayingState

组播播放中的状态，在该状态下每一统计周期末QoSCapture需要发送该周期的统计数据给QoSAnalyser；在该状态收到IGMP leave包时组播结束，转到idleState。

点播时机顶盒与平台的交互较为复杂。为减少状态机的状态个数以对其进行一定程度的简化，对RTSP中请求的发出及其响应均放在一个状态中进行处理，可以在状态处理函数中使用静态局部变量表示子状态。以下几个点播过程启动过程中的状态均采用了该方法进行子状态的合并。

(4)vodWaitDescribeState

抓到第一个RTSP D ESCRIBE包时进入该状态，收到第二个DESCRIBE的成功响应后进入vodWaitSetupState。

(5)vodWaitSetupState

在该状态中等待SETUP的发送，在收到SETUP的成功响应后进入vodWaitPlayState。

(6)vodWaitPlayState

若当前是一股普通的点播流，则在该状态中等待非快进、快退的PLAY的发送，并在收到PLAY的成功响应后进入vodWaitDataState。根据目前的调研情况，除了华为高清以外的其他机顶盒其时移电视操作中会在该状态直接抓到PAUSE或者快进、快退的PLAY包，可据此区分出时移电视和普通的点播流，从而发送不同的RRT信息(时移电视RRT不统计)。

(7)vodWaitDataState

若当前是一股普通的点播流，则在该状态中等待点播流的第一个数据包，计算出RRT后进入vodPlayingState。华为高清机顶盒会在该状态直接抓到PAUSE或快进、快退的PLAY包，考虑到观看普通点播流时不太可能在SETUP成功之后、RTP数据到达机顶盒之前马上进行暂停或快进、快退操作，也可据此区分出时移电视和普通的点播流。

点播播放中的状态，在该状态下每一统计周期末QoS Capture需要发送该周期的统计信息给QoSAnalyser；在该状态收到TEARDOWN包的成功响应后点播结束，转到idleState。

(9)vodShiftingState

普通点播流或是时移电视暂停、快进、快退时，状态机均处于该状态，此时QoSCapture应为每一个统计周期发送一个填充包给QoSAnalyser。

(10)smallWindowIdleState

在HTTP响应包中发现小窗口后进入此状态，表示下一股视频流为小窗口播放状态，不统计相关信息；抓到视频流开始信息(join或DESCRIBE)时转到smallWindow PlayingState。考虑到小窗口也可能播放失败导致实际退出小窗口时网口没有相关退出信息，小窗口视频流启动时的信息也应该加以记录以供smallWindowPlayingState中收到新的视频流启动包时加以比对。

(11)smallWindowPlayingState

按照电信提供的接口规范、小窗口播放状态，不进行视频数据的统计和发送。抓到视频流结束信息(leave或TEARDOWN)时回到idleState。考虑到实际退出小窗口时可能没有相关退出信息，在该状态中收到不属于当前视频流的视频启动信息时需要根据该启动信息之前是否解析到新的小窗口标志选择留在当前状态或直接进入相应的视频启动状态。

如果说打字方面是“妇敲夫审”，那么唱起昆曲来，则是“妇唱夫随”了。张允和晚年与俞平伯等人一起成立了昆曲研习社，周有光常常陪同她去参加曲社活动。张允和70岁生日时,周有光送了她一套《汤显祖全集》，张允和心里甜滋滋的：“他真是懂我的心思。”

而在整个QoSCapture运行过程中，程序始终处于这些状态中的某一种。

3 状态的切换

状态之间的切换是整个模块设计中的难点，主要切换分为组播、小窗口和点播的切换。组播的切换如图2所示。

图2 组播中状态的切换

正常组播的播放流程切换只是在idleState、multicast WaitData和multicastPlaying之间进行。小窗口的切换过程如图3所示。

图3 小窗口切换

按照电信规范，小窗口播放的数据不参与统计，所以在设计中小窗口切换必须体现。点播的切换过程比较复杂，如图4所示。

图4 点播中状态的切换

因为点播状态中涉及到快进、快退、暂停等诸多操作，所以图4中省略了一些状态内部子状态的转换以及一些状态收到TEARDOWN请求的成功响应后转入idleState的状态转换。

4 实验结果及分析

为了测试服务质量检测系统的性能以及分析结果的准确性，将系统放在华为高清机顶盒EC5108上运行，机顶盒配置为：CPU为BMIPS4380 V4.4 FPU V0.1，CPU主频为404.48 MHz，内存为125 MB，并在网络环境中加入仿真模拟器，模拟网络的丢包和延时。

在程序运行过程中，对机顶盒进行随机操作，如点播、直播、快进、快退等，并以5 s为周期对CPU和内存的占用率进行记录，如图5所示。

图5 C PU和内存占用率

在程序运行过程中，程序对CPU的占用率基本稳定在0.2%～3%之间，满足电信规定的CPU占用率维持在10%以下的要求，而内存占用率始终维持在0.2%，即消耗内存0.25 MB，满足电信规定的内存占用率在5%以下的要求。在程序运行中，使用损伤仪对网络丢包进行模拟，模拟结果如图6所示。

图6 丢包率统计

在测试中，使用损伤仪分别对网络进行0.2%的丢包、0.5%的丢包和1%的丢包模拟，程序以5 s为一个周期对收到的数据包总数和丢包个数进行统计，并依此算出丢包率。对于监测到的丢包率做出统计：在0.2%丢包的情况下，测试结果基本稳定在0.2%左右；在0.5%的情况下，测试结果在0.46%～0.52%的范围内；在1%的情况下，测试结果在0.95%～1.05%的范围内。在使用损伤仪模拟的过程中，损伤仪给出的模拟丢包率是一个平均值，而包的丢失在整个程序运行过程中是随机出现的，这就使得模拟丢包率越大，而在实际抓包过程中丢包率的计算结果波动也会越大。

通过主观用户体验评测，给出了视频播放质量大致对应的丢包率范围，如表1所示。

表1 主观用户体验与丢包率范围

同时对程序运行过程在正常情况下和增加时延的情况下的RRT进行了统计，统计情况描述如图7所示。

图7 RRT统计

正常情况下组播RRT的测试结果大部分在0～300 ms范围内，点播RRT测试结果大部分是在200 ms～700 ms范围内，电信规范给出的正常RRT应维持在1 s以内，超过1 s将会造成用户体验质量的下降。在增加时延后的网络，在RRT测试中也有所反映，如在增加网络延时1 s和2 s的环境下，RRT的测试结果完全能够反映出增加的时延。

在保证提取到的数据准确的前提下，本文将基于用户体验质量设计的服务质量监测系统，对于新增加的监测内容与传统的服务质量监测系统进行对比，并描述新增监测内容对于用户体验质量评估的重要性。

流媒体服务器IP的记录：在整个服务质量监测过程中，不同的节目将因为流媒体数据传送的速度不同而使用不同的标准对用户体验质量进行评估。例如比特率高的片源对于媒体丢包速率容忍度更高。但传统的服务质量监测系统只能够反映出片源码率的不同，并不能对不同的流媒体服务器做不同的评估。表2给出了不同片源对于媒体丢包速率的可接受范围，电信标准将码率超过4 Mb/s的片源定义为高清片源。

表2 最大可接受媒体丢包速率 (个·s–1)

频道切换的记录：在频道切换过程中，服务质量监测系统会记录下新频道的请求响应时延；而传统的服务质量监测只能够记录下单位时间接收到的数据包量在这段时间内一个减少到增多的过程。对于这一过程，接收到数据包的数量变化并不能正确反映出用户体验质量的变化。而在频道切换过程中请求响应时延却能在一定程度上影响用户的体验。在切换过程中，对于2种监控系统获取的丢包个数如图8所示。

图8 频道切换丢包数的获取

在频道切换过程中，因为流媒体服务器的变换将导致流媒体数据包的序号出现跳跃，使用传统的质量监测系统将会反映为出现大量丢包从而影响对于用户体验的评估。

电子节目菜单(Electronic Program Gui de, EPG)页面小窗口播放的记录：小窗口的播放并不属于用户的播放需求，所以小窗口的播放并不能真正反映用户体验质量，在电信规范中，这一段时间的播放也将不被纳入统计。而传统的视频服务质量监测系统会将小窗口的播放等同于正常播放进行统计。

视频点播中时移操作的记录：在视频点播中的时移操作如快进、快退、暂停等，会使得视频播放非常不流畅，但这是播放器对于时移操作的正常反应，因此，时移操作过程中也不会对用户体验质量进行评估。而传统的视频服务质量却并不能对此做出区分。

综上所述，使用传统的视频服务质量监测方案并不能满足对于用户体验质量进行评估的需求。本文描述的服务质量监测系统对于不同的流媒体服务器发送的数据进行区分，并记录下整个播放过程中，用户对于播放器的操作，使得参数对于用户体验质量的评估有更高的契合度。

5 结束语

本文在传统服务质量监测系统架构上，增加了对于IPTV使用过程中的各种操作的监控，使得通过网络抓取到的数据更易于对用户体验质量进行评估，目前该系统已成功应用于和电信合作的各种型号的机顶盒。在下一步工作中，将参照主观用户体验质量对提取的参数进行拟合，以便对用户体验质量进行数值化评级，并针对得到的用户体验评级结果进行相应的策略提升研究，从而最终达到提高用户体验质量的目的。

[1] 罗斯青, 段保通. IPTV 端到端业务质量监测技术研究[J].电信科学, 2008, (3): 37-41.

[2] 洪 眉, 李林江, 王志中, 等. 面向用户感知的IPTV服务质量保障方案[J]. 通信技术, 2012, 45(12): 104-107.

[3] ITU. ITU-T P.10/G.100-2006 Vocabulary for Performance and Quality of Service[S]. 2006.

[4] 倪 萍, 廖建新, 朱晓民, 等. 一种基于QoS的QoE到SLA映射方法[J]. 电子与信息学报, 2010, 32(6): 1463-1468.

[5] 林 闯, 胡 杰, 孔祥震. 用户体验质量(QoE)的模型与评价方法[J]. 计算机学报, 2012, 35(1): 1-15.

[6] 徐啸涛, 俞金秀, 胡蕊莉. IPTV业务质量指标研究[J]. 计算机与网络, 2012, 38(19): 65-67.

[7] 魏 敏. IPT V 质量监测的研究与实现[J]. 福建电脑, 201 1, (7): 123-124.

[8] Fenner W. Internet Group Manageme nt P rotocol, V ersion 2[EB/OL]. (1997-11-15). http://w ww.embed.com.cn/protocol/ rfc/rfc2236.txt.

[9] Embed Corporation. Transmission Control Pr otocol[EB/OL]. (2009-10-10). h ttp://www.embed.com.cn/protocol/rfc/rfc793. txt.

[10] Embed Cor poration. HTTP Authentication: Basic and Digest Access Authenti cation[EB/OL]. (2004-06-22). http://www. embed.com.cn/protocol/rfc/rfc2617.txt.

[11] IETF. Real Time Streaming Protocol(RTSP)[EB/OL]. (1998-04-20). http://www.ietf.org/rfc/rfc2326.txt.

[12] IETF. R TP: A Transport Protocol for R eal-time A pplications[EB/OL]. (2003-07-08). http://www.ietf.org/rfc/rfc3550. txt.

编辑 顾逸斐

Monitoring and Implementation of QoS Based on IPTV of Telecom

XIONG Xiong, LIU Xin, YE De-jian

(Laboratory of Broadband Networks and Interactive Multimedia, School of Software, Fudan University, Shanghai 201203, China)

As the rapid development of information technology, the Quality of Service(QoS) of the network must be better. But it is lack of a well-established service quality monitoring system to assess the quality of the IPTV network. The data packet’s capture and analysis for the QoS of the netw ork monitoring is essen tial, and existing network monitoring system based on the decoder data flow which makes the assessment inaccurate. Set-top boxes, as the carrier of IPTV, whose memory an d CPU performance is far less than t he PC, the p acket capture software on the PC cannot run on the set-top box. Based on the quality of experience, this paper designs set capture program running on the se t-top box, uses th e state machine to describe th e logic between the data and the c ontrol information, and clas sifies data packets for IPTV on control information to calculate the packet loss rate, MDI, the request response time and other parameters for QoS of monitoring system. Compared with the traditional monitor system, the result proves the monitor system has accuracy.

Internet Protocol Television(IPTV) of Telecom; Quality of Service(QoS); set-top box; network packet capture; quality of user experience; state machine

10.3969/j.issn.1000-3428.2014.05.053

上海科技发展攻关计划基金资助项目(12511503002)。

熊 雄(1987－)，男，硕士研究生，主研方向：网络多媒体技术；刘 新，讲师；叶德建，副教授。

2013-04-08

2013-05-27E-mail：10212010029@fudan.edu.cn

1000-3428(2014)05-0257-05

A

TP391