IPTV端到端运维技术白皮书V1004131.docx

IPTV端到端运维技术白皮书V1004131.docx

《IPTV端到端运维技术白皮书V1004131.docx》由会员分享，可在线阅读，更多相关《IPTV端到端运维技术白皮书V1004131.docx（24页珍藏版）》请在冰豆网上搜索。

IPTV端到端运维技术白皮书V1004131

资料编码

IPTV端到端运维技术白皮书

关键词

MOS-V、FCC、RET、iVSE、U2520、MQMC、MDI、RTP、MPEG、TS、IPTV、VoD、RTSP。

摘要

随着三网融合的推进，IPTV业务开展得如火如荼。

同时，也给运营商提出了新的运维挑战：

如何评估视频质量、如何快速故障定界定位、运维中如何感知用户体验？

华为端到端IPTV运维解决方案从IPTV业务过程特点、IPTV业务组网特点两个方面为运营商提供评估、监控、故障定位方案。

帮助运营商顺利开展IPTV业务。

目录

1概述7

2IPTV运维面临的困惑8

2.1IPTV发展初期面临的困惑8

2.2难于管理终端用户视频体验9

2.3故障的时候，责任划分难10

2.4难以端到端故障准确定位10

3视频质量研究与标准11

3.1视频测试层次及指标11

3.1.2交互质量12

3.1.3内容质量13

3.1.4TS流质量13

3.1.5网络传输质量15

3.2MDI视频质量标准15

3.2.1流媒体传输指标15

3.2.2混合因素的影响计算16

3.2.3为什么要测量媒体流质量17

3.3TR101-290视频质量标准17

3.3.1TR101-290一级告警17

3.3.2TR101-290二级告警18

3.3.3TR101-290三级告警19

3.4MOS-V视频质量研究19

4IPTV运维端到端解决方案21

4.2IPTV过程端到端解决方案21

4.2.2IPTV业务开通前预评估22

4.2.3IPTV业务/网络设计22

4.2.4IPTV开户保障23

4.2.5IPTV业务运行保障23

4.2.6IPTV业务二次评估23

4.2.7IPTV业务再优化24

4.3IPTV网络端到端解决方案24

4.4核心价值24

5典型应用25

5.1成功案例25

5.1.1深圳电信IPTV评估优化项目评估成果25

5.1.2评估方案26

附录A：

参考文献28

附录B：

缩略语29

插图目录

图2-1视频质量与丢包率关系图9

图4-1IPTV运维端到端示意图21

图4-2IPTV过程端到端示意图22

图4-3开通前带宽评估模型22

图4-4IPTV网络断端到端示意图24

图5-1IPTV容量评估图25

图5-2IPTV质量评估图样26

图5-3故障定位步骤图26

图5-4带宽评估图27

表格目录

表3-1视频质量层次表11

附录B-1缩略语表28

1概述

随着三网融合的推进，IPTV业务正逐步得到规模应用，如何保证IPTV的业务质量、测试用户的视频体验、如何对IPTV故障进行定界定位等问题给IPTV运行维护工程师提出了新的挑战。

IPTV业务涉及STB、家庭网络、接入网络、承载网、IPTV业务头端等多个子系统，如何做到端到端IPTV业务质量监控、在出现故障的时候，如何快速快速、准确故障定界，然后及时故障定位是IPTV业务运维的关键。

在运营商准备发展IPTV的业务的时候，面临的普遍问题是我的网络能够承载IPTV业务吗？

能够承载多少用户？

能否发展高清？

IPTV运维过程中，如何评估视频、找出瓶颈、然后对网络/业务进行再优化？

本文描述了针对这些问题的服务解决方案、工具使用建议。

2IPTV运维面临的困惑

2.1IPTV发展初期面临的困惑

由于IPTV业务对涉及到现有网络、用户家庭网络，因而为IPTV业务是否能够成功开展提供了以下三个挑战。

第一个挑战：

现网络设备具有的特性可以支持开展IPTV业务吗？

IPTV业务涉及到现有网络的的方法面面，从接入网络到承载网，这些设备具有的组播功能吗？

就有DHCPOption82功能吗？

这些设备支持IGMP功能吗？

这需要根据IPTV的特性，对现有网络进行全网协议能力评估。

协议能力评估也是为后续顺利开展IPTV业务做铺垫，特别是做好接入层面的设备能力评估，可有大大减少后续开户的故障和用户投诉。

第二个挑战：

网络能承载多少IPTV流、能承受多少用户。

IPTV业务属于高带宽业务，要求端到端网络具有大容量承受能力，特别是对于后期IPTV高清、单播VoD业务的开展，对网络的要求会更高。

另外，IPTV业务对网络的传输时延、抖动、丢包等都有很高的要求，特别是高清频道，对丢包更是有严格要求，如下图所示：

MPEG2高清频道需要达到10E-7的丢包率要求。

图2-1视频质量与丢包率关系图

如何评估网络的视频承载能力是IPTV开展成功的有一挑战，对IPTV用户的视频体验至关重要。

第三个挑战：

如何保证顺利保障IPTV开户

在IPTV开户过程中，一般来说，开户工作人员的网络技能都不高，如何制定有效的开户流程、操作规范是减少开户问题的又一挑战，另外，在开户出现问题的时候，如何按流程进行故障定位、利用哪些工具抓取现场现象也很重要，这可以避免工作人员二次上门，减少用户投诉。

面对上述难题，IPTV运营商的网络运维部门往往很头疼。

IPTV业务能正在开起来吗？

开起来后能保证不出问题吗？

2.2难于管理终端用户视频体验

IPTV业务面对的是大量的用户，动辄几十万，甚至上百万，如何管理这些用户、如何了解这些用户视频体验是IPTV运营中的另一大挑战。

另外，由于目前视频标准还不是很统一，大部分STB厂家都没有在STB上实现视频质量监控，这也是了解用户视频体验的难点之一。

并且，IPTV用户涉及家庭网络，接入线路等，这些在网管系统上目前也没有管理，这也给IPTV监控和故障定位造成了难度。

根据统计，大部分用户在发现质量不好的时候，并不是所有用户都会投诉，而是在一定时间后就会转到其他运营商，从而导致用户流失、形象变坏。

2.3故障的时候，责任划分难

目前各大运营商开展的IPTV业务中，都需要多个部门对IPTV业务进行共同维护，典型场景是，IPTV业务系统，包括STB管理部分属于业务系统部门维护，而承载部分属于网络部门维护，当出现问题的时候，这两个部门经常互相推卸责任，导致故障定位时间延长。

在各种故障类型中，特别是质量类问题最难进行故障分责，网络丢包、时延、抖动、视频源质量、STB播放问题都有可能导致视频马赛克、卡顿，黑屏，这些问题如何进行故障定界也是困扰IPTV运营的因素之一。

因此需要业务加网络的端到端视频监控，出现问题的时候，做到秒级故障分责，分钟级故障定位。

2.4难以端到端故障准确定位

IPTV涉及IPTV业务系统、EPG中间件、三层承载网络、城域网、接入网、家庭网络、STB用户，只要任何一个环节出现故障，都有可能导致用户视频质量，如何端到端地7*24小时监控，准确定位是哪一个环节出现问题是困扰运营商的最大因素。

一般来说，上述的各个系统都有可能是不同厂家提供的，有不同的管理系统，如何让他们端到端协调一致地监控IPTV服务是最大的难题，从现有的方案来看，业界有主动视频测试、被动视频测试、内置探针视频测试、外置探针视频测试等等方案，如何让这些方案端到端部署在IPTV系统上进行视频监控也是一大问题。

3视频质量研究与标准

如何评价用户的视频体验、评价网络传输对视频造成的影响，如何计算视频内容的损伤是IPTV视频质量研究的目标，目前已有一些成熟的标准，比如MDI、TR101-290等，另外，MOS-V是业界普遍认可评价用户体验的指标，但MOS-V标准还不统一，业界有许多厂家都在研究自己的MOS-V算法。

3.1视频测试层次及指标

客观视频质量指标包括四个层次,自底向上分别为：

IP承载网传输质量、视频传送流（MPEGTS）质量、视频内容质量、交互质量。

即IPTV的质量体验可分为4个层次，每个层次又有不同的指标可以衡量该层次的质量。

其架构如下：

表3-1视频质量层次表

视频质量层次

对应的指标

交互质量

TransactionQuality

ChannelZaptime

IGMPJoin/leavelatency

Boottime

RTSP时延

…..

内容质量

ContentQuality

MOS

AVsync

…..

码流质量

MediaStreamQuality

MDI指标

290指标

IP传输质量

TransimissionQuality

IP丢包率、抖动

RTP丢包率、抖动

……

3.1.2交互质量

由于接入和交付的主体是机顶盒，因此该层次的测试主要在机顶盒这一侧进行。

从STB来说，主要是接入的方便性和及时性，直播业务观看的时延和点播业务的时延。

其测试指标如下：

●ZAPtime

组播切换时间，是指用户观看一个直播频道时退出然后切换到另一个频道，或者在几个频道间轮流/随机切换。

在IPTV网络中，网络设备通过组播来向用户传送IPTV节目流，终端用户的机顶盒采用IGMP（因特网组管理协议），通过离开和加入不同节目所对应的组播流来切换频道。

显然，机顶盒离开和加入组播流的速度将直接影响用户的频道切换体验质量。

如果用户期望的频道切换时延在一秒钟左右，则在端到端IPTV路径中的每个网络设备所能引入的时延应不超过100毫秒。

因此，对于支持IGMP协议的网络设备的频道切换的性能验证是IPTV设备评估必不可少的测试项目。

●IGMP加入时延

影响直播开始播放的时间和频道切换的时间；

●IGMP加入成功率

体现接入服务的质量。

●IGMP退出时延

影响频道切换时间和退出的时间

●IGMP退出成功率

体现接入服务的质量

●RTSP时延

体现点播的服务质量

3.1.3内容质量

ITU（国际电信联盟）目前还没有定义出统一的关于客观视频MOS测量的国际标准。

根据测量方法的不同，客观视频MOS测量可分为主动式（全参考模型）和被动式（无参考模型）两大类。

主动式视频MOS测量采用测试仪表向被测设备或网络发送一个标准的参考视频流文件，然后接收经过被测设备或网络后的视频流文件，通过一定的算法比较这两个视频流文件的差异，可计算出视频MOS分值（1－5分）。

这种全参考模型的测量方法一般比较复杂，计算量较大，测试结果也相对比较准确，它适合于在实验室环境对视频编解码设备做功能性验证测试。

被动式视频MOS测量则采用测试仪表对网络中的实际视频流进行监测和捕获，然后对其数据流特征进行分析，并给出MOS分值。

用这种无参考模型的测量方法进行准确、客观的MOS计算的难度更大，目前这方面的国际标准的制定工作还比较滞后。

3.1.4TS流质量

RFC4445MDI（媒体传输质量指标）是由Cisco和IneoQuest提出，用于评估媒体流（包括视频流和音频流）在IP网络传输质量，网络设备视频业务的性能（组播/单播）和实时监测分析视频流。

MDI主要由两个参数组成:

MDI:

DF（延迟因素）和MDI:

MLR（媒体丢失率/乱序）。

此外，也有一些参数可以作为重要参考依据。

●MDI:

DF，延迟因素

表明IPTV设备需要对特定码率的视频流拥有多长时间的缓存才可以避免输出的视频流没有出现丢包，单位是ms。

以2M的H.264码流为例，其每个IP报文包含1316Byte，则

MDI:

DF=1316Bytex8/2,000,000bps=0.005264s=5.26ms

所以2MH.264码流理想的延迟抖动因素值为5.26ms。

在QOS为1级时，允许的延时抖动在50ms左右。

而测试中，可以根据实际情况，当MDI：

DF低于20ms时，并且抖动变化不太剧烈的时候，认为是可以接受的。

●MDI:

MLR，媒体丢失率

是指采样周期内IP封包内的MPEG封包每秒丢失速率。

一般认为1000个报文丢失1个是可以忍受的上限。

●MLT，累计丢包时间

累积丢包时间没有一个固定的或者参考的阈值，主要是用来观察该节点发生错误的时候，其丢包的程度，并评估对整个业务的影响。

●MLQ，累计丢包数量

同累计丢包时间，只不过统计的是丢包的数量。

●Outage，媒体断流次数和累积时间

在任意测试点，监测Outage，保证系统的流畅，连续性。

断流时间过长，用户侧直观现象是黑屏，或画面停止。

由于大多数STB具备缓存机制，当outage断流时间小于STB的缓存时间时，用户不会感觉到视频流出现了断流。

但对于IPTV研发测试人员，需要跟踪并深入分析发生断流的原因，因为它可能引发更大的故障。

●IP-SBR，IP码流速率

观察该值的变化能够知道视频编码器的效率和设置是否恰当。

根据最大，最小，平均的视频IP速率，可以决定是否对视频编码器进行优化，核实网络对IPTV业务的带宽是否满足需求。

●V-TSB，PCR速率

PCR时钟是一个27Mhz的采样时钟。

在视频解码的时候，该时钟用于同步视频和音频。

PCR速率是根据PCR时钟和视频压缩格式换算得出的视频编码速率。

PCR如果发生较大的抖动变化，用户侧将出现音视频不同步的故障。

根据以上的测试参数，IPTV测试人员能够分清视频质量出现故障的根源所在：

节目源故障，线路故障，设备性能故障，配置的故障等等。

3.1.5网络传输质量

对于IP传输层质量来说，其测试可以参考RFC2544标准，指标主要包括：

●PacketsLoss，IP丢包率

●PacketDelay，IP延迟

●Jitter，IP包抖动

●RTPLossRate，RTP丢包率

●RTPJitter，RTP抖动

●IPBurstLossRate，IP突发丢包率

3.2MDI视频质量标准

这个指标主要针对IP层传输视频流的视频质量指标，是主要IPTV测试的行业标准。

该指标对IP有广泛的适用性。

针对IPTV实现的多样性，厂家可以对RFC 4445 MDI进行灵活扩展。

目前支持ISMA和MPEG-2 TS的应用。

MDI同时具有良好的扩展性，能够在目前硬件芯片水平上达到同时监测上千路视频流的能力。

3.2.1流媒体传输指标

MDI（MediaDeliveryIndex，流媒体传输指标）引入了两个子概念，DF（DelayFactor，时延因素）和MLR（MediaLossRate，媒体流丢包率）。

其中DF可以看作是时延抖动对于媒体流的影响，MLR可以简单看作是丢包率对于流媒体的影响。

DF的具体算法如下：

DF=[VB（max）-VB（min）]/MR①

其中

VB（i,pre）=sum（Sj）-MR*Ti;wherej=1..i-1②

VB（i,post）=VB（i,pre）+Si③

这套公式基于这样一个假设：

对于一个稳定播放的客户端而言，存在两种速率。

一是媒体播放速率，这个速率是一定的，由媒体流格式以及码率大小决定，在公式中被抽象为MR；另一个是媒体流到达速率，即媒体流数据包到达终端设备端口的速率，宏观统计上来看，在没有丢包的环境里，这个速率应该和媒体播放速率相等，但是在一个小时间分片中，可能是媒体播放速率的几倍，也可能等于零。

而网络所引入的时延抖动，正是造成这两种速率之间存在差异的主要原因之一。

假设在媒体终端设备开始播放以后，上述两种速率能够保持完全的一致，那么终端设备的buffer里的数据量总是能够保持恒定，因为由于播放而消耗掉的数据量总是能够在新的数据到达之时得到及时的补充。

但是在引入了时延抖动以后，情况就变得没有那么乐观了。

抖动的引入导致在某个时间分片里，数据到达的速率远远小于数据消耗的速率，在这种情况下，为了维持画面的流畅，终端设备不得不消耗buffer中储存的数据，这个时候buffer中的数据会持续减少，如果这种状况无法很快扭转的话，buffer中的数据会很快消耗殆尽，从而造成播放画面中断，或者产生大量马赛克等影响视频质量的问题；同样的道理，如果数据到达的速率大于数据消耗的速率，则会造成buffer的溢出，从而导致部分数据被丢失，而这种丢失是无法挽回的，当播放到这些被丢弃的数据时，由于信息已经缺失，画面中断或者马赛克的现象就无法避免了。

前文中提到的VB（i,pre）和VB（i,post）就是基于上述假设得来的，在公式②中，sun（Sj）可以看作是第i个报文之前的所有报文所携带的数据总和；MR*Ti是第i个报文到达之前的时间乘以媒体播放速率，可以看作在第i个报文到达之前正常播放的视频流所消耗掉的数据总量；两者的差值VB（i,pre）描述了第i个报文到达之前buffer中所剩余的数据量。

当这个数值小于等于0的时候，就可以看作buffer中的数据已经被消耗光了。

公式③就比较好理解了，它描述了在第i个报文到达之后buffer中所剩余的数据量——到达之前的数据量加上报文携带的数据量。

当这个数值超过buffer的容量，就可以看作是buffer溢出了。

公式②和公式③描述了媒体流传递过程中时延抖动所引入的两种影响，DF（时延因素）被简单地计算为VB（max）和VB（min）的差值除以媒体播放速率，单位是s或者ms，可以看作是和时延抖动近似的一个指标。

对于视频质量测量而言，DF这个指标更贴近于实际应用。

由此时延抖动对于视频造成的损伤可以在一定程度上被量化，使这种损伤可以更容易地被测量和比较，甚至可以利用这种量化方法在统计的基础上制定一套诸如视频质量和时延因素的对照关系表。

3.2.2混合因素的影响计算

但是网络不会总是理想的只引入单一的一种影响，更多的情况中当视频流通过一个网络之后会受到丢包和时延抖动两种因素的影响（当然还有其他的因素影响，不过这个就不在MDI所能讨论的范畴之内了），在两种影响叠加的情况下，视频质量受到的影响如何评估也是一个难题。

虽然协议中没有明确地提出解决方法，但是却有意无意地暗示了一种变通的方法——其实MLR和DF是可以互相转换的。

比如VB（i,pre）<0的时候，这个数值完全可以换算成某一个丢包率；VB（i,post）>buffer的时候，这个数值也可以换算成某个丢包率。

（取决于编码格式和报文中有效数据的长度）

而在某个点丢包/乱续（MDI把乱续也看作是丢包的一种）的时候，这些被丢弃的报文所代表的VB（i,pre）可以被计算得出，虽然RFC中没有给出明确的计算方法。

3.2.3为什么要测量媒体流质量

用IP网络承载视频，决定视频质量的因素有很多，不是仅仅考察传输网络就能确定的。

即使在同一个网络中，采用不同的编码格式，或者采用不同的头端系统，视频质量可能有天壤之别。

采用什么样的编码格式或者头端系统都需要建立在网络情况的基础之上，要做上述讨论，必须了解现有的运营网络是什么样的，升级后的网络是什么样的，网络的MDI情况如何，在这些数据的基础上再进行编码格式和头端系统的选择才有意义。

比如MPEG2的带宽开销大，但是纠错能力强；MPEG4带宽开销小，但是在轻微的丢包就会严重的影响视频质量；小缓存的机顶盒频道切换时间短，价格低廉，但是对于时延抖动敏感；大缓存的机顶盒能够忍受较大的时延抖动，但是切换时间和价格却大大地提高了。

如何快速而稳定的开展IPTV业务。

建议先针对现网进行测试，得到各项MDI指标，然后根据MDI的指标考虑升级网络、部署QoS等工作，根据现有网络的能力，明确网络状况对服务器的突发指标、机顶盒的缓存指标等指标的要求，再选择编码格式和头端系统。

3.3TR101-290视频质量标准

这个指标是广泛使用的视频传输质量指标，它可以跨越不同的传输媒体：

卫星，HFC，IP。

它针对MPEG-2 TS传输的质量制定了三级告警。

每层告警针对不同程度的视频传输问题。

3.3.1TR101-290一级告警

第一级是严重的网络传输问题告警，对视频观看有明显的影响。

比如，黑屏，严重马赛克；第一级共6种错误，包括：

同步丢失错误、同步字节错误、PAT错误、连续计数错误、PMT错误及PID错误。

1.传送码流同步丢失：

连续检测到连续5个正常同步视为同步，连续检测到2个以上不正确同步则为同步丢失错误。

传输流失去同步，标志着传输过程中会有一部分数据丢失，直接影响解码后的画面的质量。

2.同步字节错误：

同步字节值不是0X47。

同步字节错误和同步丢失错误的区别在于同步字节错误传输数据仍是188或204包长，但同步字头的0X47被其他数字代替。

这表明传输的部分数据有错误，严重时会导致解码器解不出信号。

3.PAT错误：

标识节目相关表PAT的PID为0x0000，PAT错误包括标识PAT的PID没有至少0.5s出现一次，或者PID为0x0000的包中无内容，或者PID为0x0000的包的包头中的加密控制段不为0。

PAT丢失或被加密，则解码器无法搜索到相应节目；PAT超时，解码器工作时延。

4.连续计数错误：

TS包头中的连续计数器是为了随着每个具有相同PID的TS包的增加而增加，为解码器确定正确的解码顺序。

TS包头连续计数不正确，表明当前传输流有丢包、包重叠、包顺序错现象，会导致解码器不能正确解码。

5.PMT错误：

节目映射表PMT标识并指示了组成每路业务的流的位置，及每路业务的节目时钟参考（PCR）字段的位置。

PMT错误包括标识PMT的PID没有达到至少0.5s出现一次，或者所有包含PMT表的PID的包的包头中的加密控制段不为0。

PMT被加密，则解码器无法搜索到相应节目；PMT超时，影响解码器切换节目时间。

6.PID错误：

检查是否每一个PID都有码流，没有PID就不能完成该路业务的解码。

3.3.2TR101-290二级告警

第二级是音视频解码问题，一定情况下会对视频观看效果有影响。

比如，音视频不同步，频道切换速度。

第二级共6种错误，包括：

传输错误、CRC错误、PCR间隔错误、PCR抖动错误、PTS错误及CAT错误。

1.传输错误：

TS包头中的传送包错误指示为“1”，表示在相关的传送包中至少有1个不可纠正的错误位，只有在错误被纠正之后，该位才能被重新置0。

而一旦有传送包错，就不再从错包中得出其他错误指示。

2.CRC错误：

在PSI和SI的各种表中出现循环冗余检测码CRC出错，说明这些表中的信息有错，这时不再从出现错误的表中得出其他错误信息

3.PCR间隔错误：

PCR用于恢复接收端解码本地的27MHz系统时钟，如果在没有特别指明的情况下，PCR不连续发送时间一次超过100ms或PCR整个发送间隔超过40ms，则导致接收端时钟抖动或者漂移，影响画面显示时间。

4.PCR抖动错误：

PCR的精度必须高于500ns或PCR抖动量不得大于±500ns。

PCR抖动过大，会影响到解码时钟抖动甚至失锁。

5.PTS错误：

播出时间标记PTS重复发送时间大于70ms，则对帧图像正确显示产生影响。

PTS只有在TS未加扰时方能接收。

6.CAT错误：

TS包头中的加密控制段不为0，但却没有相应的PID为0x0001的条件接收表CAT，或在PID为0x0001的包中发现非CAT表。

CAT表将指出授权管理信息EMM包的PID并控制接收机的正确接收，如果CAT表不正确，就不能正确接收。

3.3.3TR101-290三级告警

第三级是更严格的告警级别，主要针对高要求的视频传输。

TR101-290本身没有针对特定传输媒体的测量方法，因为网络传输的故障将反映到第一级告警中。

在