IPTV测试

IPTV测试（精选4篇）

IPTV测试 篇1

0 引言

三网融合在全国范围内的加速推进,作为突破口的IPTV业务近几年发展得如火如荼[1]。IPTV视频点播业务(VOD)的提出顺应了市场要求,不仅满足了用户实现互动点播的要求,还为运营商提供了新的增值空间[2]。

对IPTV系统业务性能进行测试是运营商在开展IPTV业务之前需要进行的一个关键步骤。目前在最后一公里范围内对VOD性能测试还只是局限于简单的侦听测试。在此基础上,笔者提出一种改进型的测试方案,实现VOD仿真测试。该方案能有效扩大VOD网络的测试范围,提高测试结果的准确性,弥补了现有测试方案的不足,因此具有重要意义。

1 IPTV系统VOD性能测试的现状分析

目前业界公认的IPTV业务包含两种,即TV直播和VOD点播。IPTV网络测试也主要针对TV直播性能测试和VOD点播性能测试两个方面。TV直播业务通常采用组播方式进行传输,业务开展地较早,测试技术较成熟,业内主要有侦听和仿真两种测试手段。视频点播在网络架构和数据交互上与TV直播存在明显的差异,因此测试重点和测试方案也不尽相同。

1.1 VOD网络的架构

视频点播通常采用单播传输。图1为VOD网络架构示意图。

与组播数据传输的不同的是,点播要求服务器为每一个点播用户单独传输点播数据,即提供端到端的服务。IPTV视频点播网络采用CDN技术[3],将内容从中心存储服务器分发到边缘服务器,这样既保证了点播数据传输流畅,达到快速响应用户访问请求,又避免了网络带宽有限,减轻了骨干网络和中心设备的压力。用户端通过网络机顶盒(STB)接入点播网络,STB通过发起HTTP和RTSP请求,申请点播数据。服务器响应请求,通过UDP协议或RTP协议将点播数据传输给用户端。图2为点播网络交互过程示意图。

1.2 VOD网络的测试现状

由于业务发展存在先后,目前业内对VOD网络性能测试只能进行简单的侦听测试。具体为:STB进行视频点播,利用集线器(Hub)对数据进行分流,提供一路数据给IPTV测试仪;IPTV测试仪通过侦听STB的点播数据,分析网络的传输性能。由于该测试方案必须依赖机顶盒的存在,主要存在如下3点弊端:

1) 测试环境有限

目前的视频点播测试必须依赖STB和Hub的存在,当遇到不能提供该条件的环境时,例如外出现场测试等,目前的测试方案就显得无能为力,因此测试环境有限。

2) 测试范围有限

IPTV测试仪主要对最后一公里的线路进行测试,由于目前视频点播测试方案必须依赖于STB的存在,因此不能排除STB自身的因素导致的VOD点播数据传输质量的下降,因此测试范围有限。

3) 测试准确性有限

目前的视频点播测试依赖的外界设备太多,引入的外界干扰也就随之增加,这有悖于测试的宗旨。这样导致的结果是使测试准确性下降。

2 VOD仿真测试方案设计与实现

基于上文分析,解决目前VOD性能测试中存在的弊端的最根本方法就是摆脱对STB的依赖,尽量减少外部设备的引入,独立进行测试。一方面扩展IPTV测试仪的测试环境和测试范围;另一方面减少外界干扰的引入,提高测试精度。

本文提出一种新的测试方案,即IPTV测试仪主动发起请求获取点播数据,实现VOD仿真测试。

2.1 方案设计详细步骤

2.1.1 请求认证

IPTV测试仪与IPTV网络进行交互前先要经过认证。认证过程采用HTTP协议交互,其中用户名和密码等重要信息必须经过3DES加密才能上传[4]。认证成功,业务管理平台会分配一个临时身份证明用户令牌(UserToken),表示为合法用户。

2.1.2 获取点播服务器入口地址

认证通过,IPTV测试仪主动发起HTTP请求,登陆IPTV业务管理服务器EPG服务平台并获得点播服务器入口地址。

2.1.3 与点播服务器交互

IPTV测试仪主动向业务管理服务器发起请求登录点播服务器请求响应,IPTV测试仪即转向与点播服务器交互。交互类型包括HTTP交互和RTSP交互。交互内容主要包括发送请求申请数据、获取节目参数、视频TS内容分发服务器IP以及TS内容的传输方式等。其中节目参数包括ProgramID、SessionID和节目详细地址信息等。

2.1.4 与视频TS内容分发服务器交互

IPTV测试仪利用已获取的地址信息,与视频TS内容分发服务器交互,获得IPTV点播数据流。

2.1.5 视频数据的接收处理

IPTV测试仪接收视频数据到缓冲区,并实时将数据传输给后台硬件设备。硬件设备对数据进行同步分析,其中包括FPGA对测试指标的提取,如MDI测试指标、PCR精度、PCR间隔、媒体丢包率等;STB测试板对视频流进行实时回放,实现QoS指标测试[4]。

2.2 方案实现

本方案通过增加功能测试模块来实现。具体为利用Linux Socket网络编程技术实现该模块[5],将该模块加入IPTV测试仪系统中,结合系统现有设备共同实现VOD仿真测试。方案实现过程如图3所示。

步骤1,IPTV测试仪接入IPTV网络。目前接入方式有3种,即XDSL接入、LAN接入和WLAN接入。

步骤2,IPTV测试仪与业务管理服务器交互,发起认证请求,完成认证。交互过程中需调用加密函数对需要上传的用户信息进行加密处理。主要实现程序如下:

1) 发起GET 请求,相应程序为

Get /iptvepg/……;

2) 加密并上传用户信息,相应程序为

char * CTCGetAuthInfo(char* UserID,char* UserKey,char* LocalMAC……);

POST /iptvepg/……;

3) 获取UserToken,表示该终端为合法终端。在接下来的交互过程中,若目前的UserToken过期,则必须返回重新认证,重新获取用户令牌。

步骤3,认证完成之后,IPTV测试仪继续与业务管理服务器交互并登陆EPG服务系统,获得点播服务器入口地址,登录点播服务。主要实现程序如

GET /iptvepg/platform/…… HTTP/1.1;

GET /……/vod_portal.jsp/…… HTTP/1.1;

步骤4,IPTV测试仪与点播服务器进行交互。交互内容包括发送HTTP请求,申请点播节目数据;获取相关节目参数,主要有ProgramID、SessionID和节目详细地址信息等;获取视频TS内容分发服务器IP以及TS内容的传输方式等。该交互过程为后面的RTSP交互作准备。节目详细地址信息如

rtsp://172.16.243.90:554/vod/…….mpg;

步骤5,IPTV测试仪利用前面获得信息与主管理服务器进一步进行RTSP交互[6],主要实现程序如下:

1) 发送DESCRIBE请求,程序段为

DESCRIBE rtsp://172.16.243.90:554/vod/…….mpg?userid=…… RTSP/1.0;

2) 发送SETUP请求,程序段为

SETUP rtsp://172.16.243.90:554/vod/…….mpg/trackID=…… RTSP/1.0;

3) 发送PLAY请求,程序段为

PLAY rtsp://172.16.243.90:554/vod/…….mpg?userid=…… RTSP/1.0;

步骤6, IPTV测试仪与TS内容分发服务器交互,接收点播数据流。接收过程中测试仪只需发送PAUSE命令暂停数据的接收;停止测试只需发送TEARDOWN命令,如

PAUSE rtsp://172.16.243.90:554/vod/…….mpg/trackID=…… RTSP/1.0;

TEARDOWN rtsp://172.16.243.90:554/vod/…….mpg/trackID=…… RTSP/1.0;

步骤7,IPTV测试仪接收点播数据流的同时,后台的设备对数据进行分析处理,包括FPGA对MDI测试指标、PCR精度、PCR间隔、媒体丢包率等测试指标的提取,STB测试板对视频流进行实时回放。上层软件则完成数据的后期处理并实现界面显示。

3 VOD仿真测试方案结果验证

本方案已应用到IPTV测试仪中。图4为使用该测试方案进行IPTV视频点播仿真测试的场景示意图。如图4所示,IPTV测试仪经xDSL MODEM接入IPTV视频点播网络,独立进行点播仿真测试,无需STB的帮助。图4为IPTV测试仪使用该方案测试的认证交互过程。可以看出,使用该方案能够通过认证。图5为IPTV测试仪完成与主控制服务器之间的RTSP交互并获得的点播数据的网络交互过程。图6中深色阴影部分即为点播数据流,由TS内容分发服务器发往IPTV测试仪。图6为IPTV测试仪中STB测试板对接收到的视频数据进行实时回放。综上可知,使用该方案可以实现IPTV测试仪独立进行视频点播仿真测试,达到设计要求。

4 小结

视频点播业务是IPTV业务中的一个重要部分,VOD网络测试对VOD网络的建设和后期维护起着重要作用。本文介绍了IPTV视频点播网络的整体架构,分析了目前VOD性能测试的不足,最后提出了一种VOD仿真测试方案并对方案进行了验证。验证结果表明本方案稳定可靠。本方案已应用到重邮东电IPTV测试仪中,效果良好。

摘要：为了提高对IPTV系统视频点播业务的性能测试,在介绍视频点播系统的整体架构基础上,较全面地分析了目前视频点播性能测试的研究现状,提出了一种视频点播仿真测试方案,并对方案进行了设计与实现。该方案已应用于IPTV测试仪中,效果良好。

关键词：IPTV,视频点播,仿真测试

参考文献

[1]王莹程.IPTV的发展和挑战[J].电信科学,2010(6):129-131.

[2]贺铁龙.基于IP技术的三网融合[J].中国有线电视,2010(7):795-798.

[3]冯建新,高益寰,王光兴.IPTV-CDN网络的构建[C]//中国通信学会第五届学术年会论文集.南京:中国通信学会,2008:213-217.

[4]赵湘阳,张自忠,席兵.IPTV测试仪系统设计与实现[J].电视技术,2009,33(9):115-117.

[5]YD/T 1696-2007,机顶盒与IPTV业务平台接口技术要求[S].2007.

[6]IETF RFC 2326,Real time streaming protocol(RTSP)[S].1998.

IPTV系统测试仪表现状(上) 篇2

近年, 虽然国内IPTV用户规模有了较快速的发展, 但是其发展速度并没有达到市场先前的预期。IPTV产业链的状况还不是很理想, 一方面没有标准出台, 另一方面测试仪器的功能还不是很健全, 无法满足对业务和设备的测试要求。

2 IPTV测试仪的应用场景

目前, 国内IPTV业务已经在以上海、哈尔滨为代表的多个城市中成功商用, 这些城市的IPTV初期运营网络已经有了一段时间的运维经验。从目前的情况来看, 最后一公里的维护仍是网络维护中的重点, 而且其维护质量的重要性将随着用户数量和竞争的加剧而与日俱增。当前的IPTV业务处于运营初期, 缺乏相应的监控系统, 此种情况下的IPTV维护主要依赖于手持式IPTV测试终端。虽然随着技术的发展和用户数量的增加, 必然要使用IPTV监控系统, 但监控系统的监测单元只分布于网络节点处, 监控网络层及应用层数据, 因此最后一公里的维护、测试仍要靠手持式终端来完成。

手持IPTV测试仪表主要应用在IPTV业务最后一公里的线路开通和故障排查。在国内, IPTV用户主要分两类:家庭用户和政企客户。对于家庭用户, IPTV业务的接入主要以ADSL为主, 目前也有少量的FTTH方式;对于政企客户, IPTV业务的接入主要以光纤接入到CPE, 然后通过以太网交换机分发到各个用户。因此, 手持IPTV测试仪必须同时支持对这两种的IPTV业务的维护。目前, 手持IPTV测试仪主要需求是ADSL线路和10/100Mbit/s以太网接口的维护。

3 IPTV测试指标介绍

3.1 手持IPTV测试仪的技术规格

国内IPTV技术规范仍在标准化进程中, 各厂商的设备技术规格不统一。由此各地的IPTV网络有不同的部署架构, 技术规格和网络设置。因此, 手持IPTV测试仪必须支持国内市场现有的多种技术规格。

手持IPTV测试仪必须支持以下的技术规格:

物理层接口:xDSL接口, 以太网接口

数据链路层封装格式:PPPoE, 以太网封装, VLAN

网络层封装格式:UDP, RTP, TCP

流媒体标准:MPEG-2 TS, ISMA

视频编码格式:H.264, AVS, MPEG-4, MPEG-2, WM9

测试方式:监听, 串接, 仿真STB, 仿真ADSL Modem和STB

3.2 IPTV的测试指标

合理的测试指标能够帮助运维人员准确的判断故障类型和提高基层维护人员的工作效率。在宽带接入网, 完整的IPTV测试需要提供以下指标:

xDSL线路质量, 支持对ADSL线路各项指标的分析, 如噪声、频率、电平和损耗等

以太网CRC错误

IP速率

RTP丢包和抖动

RFC 4445 MDI (媒体传输质量指标)

PCR速率

TR 101 290告警 (针对MPEG-2 TS格式)

每个测试指标提供不同故障判断依据。由于RFC4445 MDI同时考虑了IP传输层和MPEG层的因素, 建议作为首选判断指标。然后, 通过其它的测试指标辅助判断问题根源。考虑对现场问题的深入分析和实验室故障重现的需要性, 测试仪必须具有视频流捕捉功能。

在IPTV部署中, 测试是必不可少的步骤。选择合理的视频质量测试指标可以有效地提高排查故障效率, 同时降低建设监测系统投入。所有的测试依赖于对技术规范和系统行为的了解。因此, IPTV的架构将影响视频质量测试的合理性和可靠性。

IPTV服务概念源于北美的运营商。由于设备供应商的实现方式不同, 市场上出现了多样的架构体系。尤其在中国, 技术实现差异, 视频内容来源, IP网络状况等因素导致多种的IPTV实现方式。

在国外, MPEG-2 TS封装格式是主流。其原因在于内容供应商与运营商之间的合作模式:内容供应商直播节目和点播节目, 运营商负责将视频内容通过其IP网络进行传播, 提供收费节目。MPEG-2 TS封装格式的优点在于提供方便的节目传输和方便的增值服务。针对MPEG-2TS封装的视频流, 标准组织制定了TR 101 290视频传输质量监测方法。TR101 290是量化的测量方式, 其告警能够告知维护人员视频流的问题对最终观看质量的影响。对于IP传输视频业务的需求, RFC 4445 MDI提供了在IP传输层面的告警方式。配合TR101 290和RFC 4445 MDI, 视频网络出现的问题可以分离到不同的层面:节目源 (视频源, 编码器, 服务器) , IP设备和网络。国外通用的IPTV视频质量监测方案为:在视频头端确认TR101 290质量良好情况;使用RFC 4445 MDI监测各IP节点的视频质量。这种实现方式最大地平衡了质量监测的需求和监测设备的成本投入。

在国内, 目前部分电信级IPTV运营存在ISMA格式的网络架构。但是, ISMA的视频封装格式没有对应的视频监测标准。因为视频内容压缩后直接封装到IP封包, 所以ISMA的视频仅能够从IP层判断其传输质量, 没有判断音频和视频同步等问题的相应指标。

虽然IPTV设备供应商在实现上逐渐趋向与MPEG-2TS封装格式, 但是在实现上仍然有很大的差异。不同厂家对如何传输视频流有不同理解, 以及封装格式、新功能实现、网络纠错方式的变化, 这些都对测试仪的视频质量测试能力提出了更高的要求。

(1) TR 101 290

这个指标是广泛使用的视频传输质量指标, 它可以跨越不同的传输媒体:卫星, HFC, IP。它针对MPEG-2TS传输的质量制定了三级告警。每层告警针对不同程度的视频传输问题:第一级是严重的网络传输问题告警,

IPTV测试 篇3

三网合一已经明确写入我国信息产业发展的规划纲要中,而三重播放业务又是目前公认的实现三网合一的有效途径。作为三重播放业务的代表,IPTV充分利用宽带网络基础设施,在电视机,计算机,手机等音视频终端上为广大用户提供了传统电视、VoD点播、TV直播等形式各异、种类繁多的数字多媒体服务,为内容提供商和电信运营商提供了前所未有的发展机遇,更为IP技术找到了通往全面繁荣的应用道路。目前,我国已经完全具备了发展IPTV的技术条件和市场条件。

2 IPTV测试

2.1 网络测试概述

现代网络测试技术种类繁多,按照测试方法,可以分为主动测试和被动测试;按照测试对象,可以分为有线网络测试和无线网络测试;按照测试手段,可以分为传统测试仪和虚拟仪器为代表的网络测试仪。IPTV测试无论从理论还是测试方法都源于现代网络测试,但同时也具有自己的特点。

2.2 IPTV用户QoE测试

IPTV用户QoE测试着眼于IPTV用户的观看体验,以此为评判相关设备和网络性能优劣的依据。它主要有频道切换时间和视频质量评定两方面的内容,测试结果具有很好的直观性。而一般网络测试是以RFC2544为测试指导,以获取诸如延时、丢包率、带宽利用率等各专业参数为测试基点。随着应用测试的不断发展,用户QoE测试的各种指标得到了越来越广泛的认可和应用。

在用户QoE测试中,视频质量评定是主要指标。这一指标现有3个评价标准:MDI,MOS_V和全参考视频质量评定指标PEVQ。在这3个指标中,RFC4445 MDI同时考虑了IP传输层和MPEG层的因素,无论是测试的效率还是测试的公平性,MDI都具有较大优势,一般作为首选判断指标。MDI包括了2个参数[1]:

1)延迟因素(Delay Factor,DF):该数值表明被测试视频流的延迟和抖动状况,单位是毫秒(ms)。DF将视频流抖动的变化换算为对视频传输和解码设备缓冲的需求,被测视频流抖动越大,DF值越大。当网络设备和解码器的缓冲区容纳的视频内容时间不小于被测视频流DF读数时,将不会出现视频播放质量的下降[2]。

2)媒体丢包速率(Media Loss Rate,MLR):MLR的单位是每秒的媒体封包丢失数量,该数值表明被测试视频流的传输丢包速率。视频信息的封包丢失将直接影响视频播放质量,理想的IP视频流传输要求MLR数值为零。具体的视频播放设备对丢包可通过视频解码进行补偿或者丢包重传,在实际测试中MLR的阈值可相应调整[3]。

3 用户QoE测试MDI算法及实现方案

3.1 用户QoE测试MDI测试算法

3.1.1 MDI:DF

流媒体应用有实时性的特点。在流媒体通过IP网络传输的同时,终端解码器在消耗已接收到的媒体流信息。IP网络传输媒体流出现的抖动表现为同一媒体流的IP封包传输间隔的不均匀。

在采样周期中,DF首先计算在测量点每个IP视频封包到达时间变化,然后与预期的视频流速度对比,采样周期默认为1 s,DF数值在每次采样周期完成后更新。参照RFC4445,具体DF的计算如下:

设在测量点有虚拟缓存为VB,在测试周期内第i个包到来时,将有2个VB值:VBi,pre和VBi,post,即

式中:j=1,2,…,i-1;Sj为当第j个包到达时的媒体有效载荷的大小;Ti为在测试周期内第i个包到达时的时间;MR为媒体流码率;VBi,pre为在第i个包到达前虚拟缓冲器的大小;VBi,post为在第i个包到达后虚拟缓冲器的大小。

在测试前首先设定初始条件VB0=0,若在测试周期(通常设定为1 s)内,有k个包到达,则会得到2×k+1个有效的VB值,从这2×k+1个值中取VBmax和VBmin,那么

DF=[VBmax-VBmin]/媒体流码率

式中:媒体流码率单位为byte/s。DF的计算将网络抖动换算为对媒体流解码缓冲的需求。当解码器的缓存保存媒体信息不小于DF数值,解码器不会出现缓存内容耗尽的情形,因此网络的抖动将不影响视频播放的质量。

3.1.2 MDI:MLR

MLR是计算媒体封包在采样周期内的丢失总数,MLR=媒体封包丢失总数/采样周期,默认采样周期为1 s。媒体封包在MPEG-2 TS封装格式是指有效的MPEG封包(不包括填充MPEG封包)

3.2 用户QoE测试MDI测试算法实现

从DF的算法来看,关键点是2个VB值:VBi,pre和VBi,post的获取,算法实现流程如图1所示。

图中:idlePro为空闲进程,等待事件发生;UDPPro为提取UDP数据包的报文头信息;RTPPro为提取RTP数据包中的包文头信息;calPro为计算进程,计算VBi,pre和VBi,post;start REQ为请求信号,指示的是UDP数据包;UDP RES为响应信号,指示UDPPro进程处于空闲状态,允许传送UDP数据包;send UDPdata为发送UDP数据包;RTPOP为指示信号,表明UDP数据包中存在RTP;RTP RES为响应UDPPro进程,准备接收RTP数据包;send RTPdata为发送RTP数据包;CALOP为指示信号,表明RTPPro已经提取有效负荷S;cal RES为响应信号,允许RTPPro进程传递参数;send calpar为发送有效参数给calPro进程;noRTP为指示信号,表明UDP数据包中不存在RTP数据包,系统回复到idlePro进程,等待另一事件发生;endOP为结束信号,表明一个完成的计算过程,同时使能系统回复到idlePro进程,等待另一个事件发生。

MLR参数的获取必须考虑多个节目流的问题,这只需要在统计时根据节目流的PID值进行区分即可。根据上述算法,应在一个采样周期内(1 s)提取RTP帧中的CSRS_counter(连续计数)字段以统计媒体丢包数。算法实现流程同上。

4 用户QoE测试硬件实现方案

由测试需求可以看到,MDI测试的内容涉及网络的各个层次,在测试时就是要根据算法实现对协议帧相关字段参数的提取。举例说明:在MDI:MLR测试中,为了实现对不同业务流的识别,就需要根据数据帧的MAC地址和IP地址对其进行过滤,这就必须要从MAC帧和其承载的IP包中提取对应的字段进行统计。IPTV测试层次模型和OSI 7层模型的对照如图2所示。

测试仪总体功能模块如图3所示。图中,FPGA模块是整个硬件系统的核心,主要功能是:对从MAC芯片进来IP帧进行拆解;根据MDI测试要求提取MAC地址、IP地址、UDP包头长度、RTP中CSRS的连续计数字段等相关测试参量;与ARM协作,完成MDI测试量的统计。依需求分析,FPGA功能模块设计方案如图4所示。

5 FPGA数据提取模块设计实现

根据上面的分析,显然数据提取模块是FPGA模块的核心。具体开发时,可以选用ALTERA公司或Xilinx公司的FPGA芯片,并利用各自公司提供的功能强大的EDA集成开发软件进行开发。

5.1 数据提取模块的设计

数据提取模块的主要作用是为数据统计模块提取数据帧中相关字段的参数,其设计采用有限状态机FSM的设计方法。数据提取模块状态转移如图5所示。

IPTV测试仪开机以及被复位后的状态称之为初始状态S0(init);数据提取模块并不在init停留,而是在下一个时钟周期立即跳转至等待状态S1(idle),此后不断查询与MAC芯片接口的以太网接口模块,一旦监测到RSX信号为高电平,则跳转至启动状态S2(start);在启动状态start,数据提取模块使能以太网接口的RENB信号,开始读取数据;在下一个时钟周期内,当RVAL和RSOP信号同时有效时,数据采集模块由start跳转到提取状态S3(execute),开始采样标志分组或信元第一个双字的数据;随后在信号RVAL有效时,继续接收分组或信元的中间部分数据;最后,当包尾标志信号REOP有效时,这一时钟下所接受的数据为包尾。此时,采样结束,数据提取模块也由提取状态execute进入等待状态idle。但是在提取包尾时必须检验尾字节的有效字节数以及该接收包是否有错,如果有错,则丢弃该数据帧,这就是丢弃状态S4(discard)。除了以上5个状态之外,还有一个结束状态end,此时表示测试工作结束。

5.2 数据提取模块的仿真验证

以提取IPTV数据包的源MAC地址和目的MAC地址为例,仿真图如图6所示。

通过提取包括源MAC地址和目的MAC地址在内的一系列参数,在一段时间内,对相同源点和目的节点的IPTV数据流,IPTV测试仪通过对其MDI:DF和MDI:MLR的统计就能对该IPTV数据流进行有效地监测。如上图6所示,仪表监测到RSX为高电平,说明有新的IPTV业务流到来,通过使能RENB(低电平有效),得到图6中的MAC芯片内的数据。FPGA在RSOP有效状态(高电平有效)下立即提取目的MAC地址(DSMAC,需要1.5周期),紧接着再提取源MAC地址(SRMAC,需要1.5周期)。得到DSMAC和SRMAC后,使能enDS信号和enSR信号,将它们写入缓存器(FIFO)。与之类似,也能完成对其他参数的提取。

提取完毕之后,将提取的参数送入统计模块进行统计,然后通过地址匹配模块写入FIFO预先开辟好的存储区中,由ARM读取。

6 小结

目前,IPTV测试的发展如火如荼,各种新的测试方案层出不穷,但是MDI测试以其高效实用的特点成为广大用户和工程技术人员的首选。从测试本质上讲,MDI测试是以传输层作为主要测试对象,传输好即质量好,没有对视频质量做出更深层次的考察。而这正是MOS_V和PEVQ所主要关注的,只是这2个指标过于繁琐,一般适用于大型验收测试和研究测试,如何将MDI和这两个指标结合,是今后应当关注的重点。

摘要：分析了IPTV用户QoE测试中的MDI测试参数,重点提出MDI测试的算法和实现方案,并采用FPGA提取IPTV业务流的关键信息,为MDI测试提供可靠的测试数据。

关键词：IPTV测试,用户QoE测试,MDI

参考文献

[1]杨中贤.IPTV QoE测试指标概述[J].电信网技术,2007(12):28-30.

[2]陈国顺,余达太,刘增良.基于虚拟仪器的网络化测试系统设计与应用[J].电子测量技术,2007,30(3):13-16.

IPTV测试 篇4

关键词：IPTV测试仪,软件平台,嵌入式Linux,图形用户界面

0 引言

交互式网络电视(IPTV)是一种利用宽带网,集互联网、多媒体、通信等技术于一体,向家庭用户提供包括数字电视在内的多种交互式服务的技术[1]。伴随着国家三网融合的推进,经过5年多的探索和发展,国内IPTV产业已经日渐成熟,拥有了初具规模的用户群,成为电信运营商不可忽视的经济增长点[2]。随着IPTV产业的爆发式增长,IPTV服务质量成为运营商面临的突出问题,为了提高用户对IPTV的认同率,运营商必须做到及时发现并快速准确解决问题,要做到这一点必须依赖于可靠而有效的监测系统和方法。

本文的研究目的在于设计一种基于嵌入式Linux的IPTV测试仪软件平台的实现方案。软件应能准确测量IPTV的所有性能指标,提供良好的图形用户界面,同时具有很强的兼容性和可扩展性,并兼备相应的网络维护和数据管理功能。该方案应用于IPTV网络最后1 km的维护,经实际测试表明软件具有很好的可靠性和实用性。

1 开发平台简介与软件总体结构

1.1 开发平台简介

Linux是一种自由和开放源码的类Unix操作系统,作为一个现代网络型操作系统,其中所涉及的技术涵盖了操作系统技术的最新成果。Linux是一个领先的操作系统,世界上运算最快的超级计算机都是运行Linux操作系统[2]。

Qt是诺基亚开发的一个跨平台的C++图形用户界面应用程序框架,其宗旨是“一次编码到处编译”。Qt具有完全面向对象,拥有丰富的API,支持2D/3D图形渲染,支持OpenGL,容易扩展,并且允许真正地组件编程等优势[3]。Qt开发员仅需要学会一种API来写入应用程序,该程序可在任何地方运行。

本文采用Fedora 9嵌入式操作系统,以Qt 4.6为主要编程工具,实现图形界面和应用程序的功能。

1.2 软件总体结构

根据功能需求,IPTV测试仪应具有IPTV测试、在线视频播放、线缆测试、xDSL测试、数据管理、网络应用等功能。因此,从IPTV测试仪的功能角度出发,本文将测试仪的软件平台划分为应用层、控制层和功能层3层,如图1所示。

1)应用层。用于封装与具体测试项无关的呈现和管理模块,如绘图控制模块负责将测试数据以曲线图形式直观呈现,数据管理模块用于测试结果的保存、删除和导出到外设等管理,网络应用包括Ping,Traceroute等IP数据测试和PPPoE拨号等IP连接特性测试。应用层的各个模块均由控制层进行调度和管理,各个模块之间相对独立。

2)控制层。管理各功能子界面之间的切换、隐藏、销毁等操作,同时组织、控制和管理其他功能模块,并与其他模块协商接口细节。以xDSL测试为例,xDSL测试包括ADSL,VDSL,ADSL 2,ADSL 2+等测试,在进行ADSL测试的同时不能进行VDSL测试,此时控制层就必须进行管理,防止系统崩溃。

3)功能层。封装了与特定功能实现相关的后台操作、库文件调用和驱动程序交互接口。从用户的角度出发,其作用体现为用户从选择某项功能测试、配置相关测试参数、执行测试到结束测试的整个过程。

2 主要模块设计

如图1中软件总体架构所示,系统的软件部分主要分为主控模块和测试数据管理模块。其中主控模块包括软硬件交互和测试功能实现、异常处理、测试数据的实时显示以及曲线图绘制。测试数据管理模块用于对测试结果的处理,包括存储、查看、删除、导出到外设等。

2.1 主控模块

主控模块是整个软件架构的核心。用于控制其他功能模块的运行和交互,实现软硬件的交互和测试结果的实时处理等。如图2所示,以IPTV测试为例,用户首先对测试参数进行配置(频道选择、测试模式选择等),在对配置项进行合法性检验后主控模块会创建一个新的测试线程,主要实现测试指标的实时处理和曲线图绘制。而主线程则管理各界面的切换控制、测试结果的实时显示以及测试线程的终止等操作。

Qt有很多自带的类,其中QThread类就用于实现线程的相关操作[4]。本例中启动测试线程代码为:

首先重载QThread类,然后创建线程类对象,之后调用类的成员函数即可启动线程。测试结束后主控模块负责终止线程,并根据用户的选择保存测试结果。

2.2 测试数据管理模块

在一次IPTV测试过程中,一部分参数是不会发生变化的,如IP地址、端口号等,一部分参数是在有错误发生时才发生变化的,比如TR101 290的测试指标,而MDI等指标却是实时变化的[1,4,5]。为了节约资源,同时提高程序的执行效率,设计了如图3所示的存储模式。

以频道为单位对测试结果进行存储,其中在测试过程中不发生变化的参数只存储一次,由于TR101 290指标在有错误时发生变化,因此只在错误发生时刻记录该值,而MDI等指标则每秒钟记录一次。在测试过程中这些结果都保存在RAM内存中,测试过程结束后根据用户的选择将RAM内存中的数据写入Flash中永久保存。

对于保存在Flash中的文件,用户可以对其进行查看、删除以及导出到外设等操作,这符合测试仪表的规范。

3 软件测试

IPTV测试仪表应用于IPTV网络最后1 km的维护,如图4所示,主要测试节点都在客户家庭,如Modem前后端、STB前后端、TV前端等,可在这些节点进行测试[6]。统计显示,IPTV的主要故障点均为上述节点。通过本测试方案可以方便地测试接入线路质量、网络状况以及故障定位。

1)测试环境包括1台IPTV测试仪;1个电信IPTV账号;1个Modem。

2)测试结果。图5为MDI:DF参数实测结果,本文的软件平台能同时以数字形式实时呈现测试指标值,以及以曲线图形式直观反应测试指标的变化趋势。图6为数据管理界面,通过本模块可以实现测试文件的查看、删除和导出到外设等操作。

4 小结

本文针对IPTV测试仪的功能需求,研究并设计了一种基于嵌入式Linux系统的IPTV测试仪表软件平台的实现方案。通过实际IPTV业务环境下的测试结果表明,该软件平台不仅能准确提取IPTV的各项测试指标,而且具有良好的图像用户界面,同时具备一定的数据管理和网络应用功能。目前此方案已成功商用于某市的电信IP-TV服务提供商,市场反应良好。

参考文献

[1]赵湘阳,张治中,席兵.IPTV测试仪系统设计与实现[J].电视技术,2009,33(9):115-117.

[2]方磊.IPTV视频传输质量监测系统的研究与实现[D].重庆:重庆邮电大学,2007.

[3]BLANCHETTE J,SUMMERFIELD M.C++GUI programming with Qt4[M].2nd ed.北京:电子工业出版社,2008.

[4]ETSI TR101290,Measurement guide-lines for DVB systems[S].2001.

[5]易欣,张治中.基于WinCE的IPTV测试仪前台软件设计[J].电视技术,2009,33(12):108-111.