提交优异的IPTV网络服务质量

IPTV前端概述
       本文将重点讨论IP前端系统。一个IP前端的主要功能如下：
       数字节目采集：来自卫星或地面的节目源，以及为将这些内容进行数字传送（全国的或本地的）所做的准备。
       数字节目存储：保存并插入其它的非实况广播电视节目，例如本地内容、视频点播或广告节目等。
       数字节目分配和传送：将各类节目综合在一起，并进行速率调整、调制、封装（编码）、加密和其它技术处理，以用于节目传送。
       在这样的前端系统中，需要通过各种方式采集大量的节目，例如来自有线、卫星或地面无线广播电视等各种RF源信号，也可能有使用SDI或IP接 口传送来的节目。在多种信号格式输入并采用多种接口（如IP、SDI和RF接口）的情况下，为使系统提供可靠的、高质量的IPTV服务，就要对那些可能会对系统的完整性带来影响的一些重要因素予以足够的重视。因此，在对前端信号作进一步处理以及将信号送往电信网络之前，对被采集信号实行QoS监视就是十分必要的。为了保证质量，可利用全面的监视，如图1“关键监视点”中，给出了一些重要的信号监视点。
       前文提及的前端的三项主要功能在本文中可分别进行考虑，实际上，仅用一个单独的硬件组合，就可以进行多项处理。由于我们前端节目内容的主要部分来自地面电视和卫星的射频节目，我们必须着重考虑如何确定并保持地面和卫星信号的质量。以下将介绍一些关键的RF测量，这样我们就能够在观众无法正常收看节目之前及时发现问题。

IP广播电视输出—关键监视参数
      电信运营商面临的重大运营挑战是如何有效地提供优异的服务质量（QoS）等级，使他们能够在当今竞争激烈的市场中保持他们的优势地位。因此，提供一种直观而又简明的视频质量和诊断信息显示，为在日益复杂的广播电视环境中提交优异的服务质量提供支持成为一项重要的需求。为了获得高等级的QoS，我们必须为运营商和工程技术人员提供准确而又及时的系统性能信息。
     我们已经认识到，为了保持系统的高性能等级，必须提高我们系统的服务质量。但问题是，在IP环境中，当我们谈及服务质量时它究竟指的是什么？

什么是QoS？
     服务质量，即QoS，从技术观点来看，在ITU标准X.902中定义为“对一个或多个对象集体行为质量要求的集合”。在网络通信工程中，QoS可以用来为不同的数据流提供不同的优先级，或者说，为某一数据流提供某种性能等级的保证。在IPTV系统中，这种优先级对于实现良好的质量视频传送是十分重要的。
  ‘QoS的主要目标是提供包括专用带宽、可受控的抖动和时延……以及改善的损耗特性的优先级。’

关键性能指标
     如果对上述定义作进一步的说明，很明显，当我们谈及QoS时，必然涉及到服务提供商支持用户需求的能力，这至少包括以下4个方面：
        带宽
        等待时间或延迟
        抖动
        通信业务量损失
     如果对这4个方面作更细致的说明，还可以作如下表述：
        带宽- 网络应当具有足够的通信容量以支持用户对业务吞吐量的需求。
        等待时间或延迟- 将任意数据包从某一给定的传输节点发送到另一给定的接收节点的所需时间。
        抖动 - 数据包到达接收节点期间延时量的变化。
        通信量或数据包丢失- 多长时间丢失一次数据包？- 受影响的数据包有多少？

     以上4个方面可以称为KPI（关键性能指标），它常用来测量传输系统的性能。现在我们知道我们能够测量什么，但问题是我们为什么要测量？
IPTV系统是建立在一个“尽力传送”的网络上，因为按照定义，IPv4和IPv6协议是“尽力传送”的传输系统协议。这两个协议均依赖于其它协议如TCP的支持，才能为用户提供QoS服务。然而，一个简单的事实是数据和话音业务可以在有抖动和延迟的情况下正常地复制，但是视频业务却不能这样处理。视频业务是按照UDP/RTP协议传送的，它要求网络有较高的可用性（带宽和时间），并要求执行强健的网络管理机制。在一种“尽力传送”的网络中它是不能正常传送的，因为携带视频数据的IP包不能准时并按照正确的顺序依次到达接收节点。这就给我们带来一个问题，我们怎样才能有效地检测IPTV传送网络中所出现的问题。
     前面我们已经将可以用来监视系统QoS的关键性能指标归结为4项，其中有关带宽的含义还可以讨论，在系统的设计阶段就应当考虑到该系统能否提供适当的通信业务量管理机制。我们所进行的运行测量，例如在网络中任一节点处测量当前的话路数以及每一话路或所有话路的占用带宽是非常有用的，可以把这些测量结果作为当前系统是否过载的指示。通过监视其它参数以获知问题的症状表现，就能够对任何过载进行预测。这些监测参数包括了前文所提及的另外三项关键性能指标。
     在其它的三项关键性能指标中，前两项是很难分开的，即时间等待/延时和IP抖动这两项。应当对链路中所有话路的这两项指标进行监视。作为一个例子，我们考虑传送某一个4.7Mb/s传送流的单个话路：

     假定每帧含有7个MPEG包，即每帧共有7×188字节=1316字节

     假定以太网帧采用IP/UDP/RTP封装，那么该以太网帧的大小为1370字节，对应的以太网的比特速率为4.886Mb/s：
     以太网速率（每秒传送的以太网帧数）=4886000[比特率]/(8[每字节的比特数]×1370[每帧字节数])=445.80帧/秒
     帧之间的时间间隔为1/445.8[以太网帧速率]=0.00224秒
     这就是说，理想的包到达时间应当是2.24ms。偏离这一理想值的任何变动均可能给接收设备带来数据缓冲问题。即便是固定的偏离也会有问题。不过IP包之间的可变定时即所谓IP抖动，如果尚未诊断出并且未被纠正的话，可能会引起更为严重的问题。IP包抖动对终端用户的影响与网络的设计部件例如路由器中缓存的容量大小有关，而且终端用户的接收设备采用什么样的设计方案也会对他接收的QoS带来明显的影响。如果用户的机顶盒采用了容量较大的输入缓存器，那么可能会消除大多数网络抖动带来的影响。然而，与那些较为保守的设计方案相比较，这种大容量缓存器的设计方案肯定会提高成本。因此，更可取的方案是测量并消除网络中的任何过大的IP包抖动。我们设置的网络监测点应当能够在较长的时间段内进行测量并能够显示数据包到达时间间隔（PIT）的变化，以确保不会给用户带来潜在的质量问题而引起用户的抱怨。

图2 包到达时间间隔的图示

     能否准确地测量并显示网络中的PIT是能否对该网络实行良好的诊断和管理的一个关键。在图2中，给出了包到达时间间隔的图示。
     在监测仪器中可以设置包到达时间间隔的容限区（图2中的红区），由图2可见，在刚过去的一段时间内，有几处的PIT指示进入了容限区。这种简明的图形显示给运营商或工程师提供了一种快速、便捷的方法，从而能够了解该网络的QoS相关重要信息，并可据此采取相应的校正措施。

跨层定时问题
     在通过IP网络传送MPEG流的过程中，这里还有一个相关联的、有时却被忽略的问题，即这些传送流包还要被封装到IP包（更确切地说，是UDP包或基于UDP协议的RTP包）中。通常情况下，每一IP包中含有7个TS包。这样，在处理某一IP包时，会影响到在同一时间进入到MPEG解码器端缓存器中的所有7个TS包。由于这些TS包在缓存器的输入端均具有相同的到达时间标记，那么，任何携带有PCR信息的TS包的时间标记均会出现错误，这将对PCR的定时测量带来影响。
     PCR准确度（PCR_AC）与到达时间无关，因此它不会受到影响。然而，PCR漂移率（PCR_DR）、频率偏置（PCR_FO）和总抖动（PCR_OJ）却与到达时间相关。基于IP的视频解码器把经过缓存后输出的IP包送入到MPEG解码器，在MPEG解码器中将数据流恢复为恒定的比特率。使用泰克公司MPEG传送流符合性分析仪并开启PCR内插值时可以模拟这一过程，它会把一个IP包中的多个TS包展开到两个IP包之间的时间段内。
     还有一点值得注意的是，在可变比特率的码流中是无法进行PCR测量的。这是因为在不能为每个TS包继续提供定时信息的情况下，重建TS包的到达时间也是不可能的。
     为了确保良好的视频质量，即使有了正确的PCR定时也是不够的。利用PCR可以使解码器的系统时钟与编码器的系统时钟保持同步，在一般情况下，通过插入在打包的基本流（PES）包头中的显示时间标记（PTS）来实现帧同步。PTS是一个33比特的数值，它以90kHz时钟频率（27MHz时钟除以300）为计时单位。PTS值指示的是数据帧在解码器端的显示时间。解码器端与编码器端的PCR以及二者之间的PTS/DTS均应当始终保持同步关系，如果解码器端与编码器端的PCR或PTS数值出现了任何变化，均可能造成缓存器的上溢或下溢，这样就会引起诸如彩色丢失之类的解码错误，这些错误是很容易被观众察觉的。实践证明，为了解决系统的定时故障，进行跨层时间相关的定时测量，如PIT、PCR和PTS定时测量等是十分有用的。

图3 RTP包统计图示

     接着我们还要讨论下一项KPI指标即数据包丢失。前文我们已经提到了路由器的缓存容量问题，正是网络路由器输出端口的缓存器问题可能会引起数据包的丢失。特别是处于网络集聚点的路由器，当进入该路由器端口的数据量接近它的缓存器的最大输入容量时，将会因为路由器缓存数据的溢出而导致其输出接口处的包丢失。虽然这一过程也许不是一个瞬时事件，然而却会造成数据通信量的逐步增加，这种情况通常会出现在傍晚电视收看的高峰时段。如果没有适当的通信业务量管理机制和通信量储备，或者通信量的储备已被耗尽，那么数据包的丢失可能会通过网络扩散而激增，从而影响到终端用户的观看效果。正因为如此，网络监视系统的一项基本功能就是必须能够发现包丢失或包无序的错误。如图3所示，监视系统提供了RTP包的统计数据。由网络引入的延时会导致包无序，不过，如果终端用户的接收设备采用了大容量的缓存器，它能在机顶盒中对数据包重新排列并恢复数据包的正常顺序，从而可以消除包延时带来的影响。尽管如此，监视设备必须能够检测到包无序事件并能够及时地为运营商和工程师提供诊断信息，以便在用户抱怨之前排除这种故障。

媒体交付指数（Media Delivery Index）
     包延迟和包丢失均已纳入IETF RFC 4445的定义之中，RFC引入了媒体交付指数（MDI）的概念，并将它定义为单一的品质因数，它可用来量化两类IP传输损伤，即包抖动（或包延迟）以及包丢失。可以把这两个测试参数定义为媒体延迟因子（Media Delay Factor，MDI-DF）和媒体丢失率（Media Loss Rate，MDI-MLR）。
     延迟因子用来指示在正常比特率下必须缓存（即延迟）多长（多少比特）的数据流以防止包丢失。
     媒体丢失率是在1秒的周期内丢失的数据包数。
     尽管MDI已普遍地为业界所接受，并将它作为“事实上”的包延迟和包丢失的测量项目，然而它并非是没有任何问题的。其中一个主要问题是MDI没有考虑被测IP包中的有效载荷。这就是说，无论IP包的有效载荷是什么，是音频，是数据还是视频，它均用同样的方式予以处理。这样，当通信业务是按照基本UDP协议（也即非RTP协议）传输时，这个问题就暴露出来了。在原始的UDP协议中，并没有提供检测包丢失的任何方法。因此，对于原始的UDP协议，MDI的包丢失部分必须从MPEG的连续性计数错误的指示中导出。至于任何其它错误，例如传送流的语法错误，则是MDI无法检测的。

结语
     很明显，通过IP网络传送高质量的数字视频是一项富有挑战性的任务。细分后的IP业务，如高速数据、VolP和视频有着完全不同的带宽和QoS需求。传输视频需要高度的可用性（带宽和时间），它要求执行强健的网络管理机制以及采用适当的监视工具，以确保24/7全天候地保持这种传输管理机制。可以看出，IP视频不能幸存在“尽力传送”的环境中——视频包必须顺次到达且无丢失。
     如果要在这样的环境中传输视频，必需使用测试设备，并在整个网络中正确地配置仪器监测点的位置，用来提供系统的KPI重要数据。利用这种方法，运营商和工程师就能够有效地管理好网络系统，防止信号质量的劣化，避免可能影响终端用户观看体验的错误发生。
泰克公司的MTM400A传送流监视器为基于RF、IP和ASI接口的MPEG传送流的实时传送流监视提供了完整的解决方案。它将强大的置信度监视功能和深入的诊断测量组合在一起，成为单一的整体解决方案。它具有独特的FlexVuPlus用户接口，可以提供视频质量和诊断信息的简明指示，从而能够在日益复杂的广播电视传输环境中确保优异的QoS等级。