IPTV承载网建设是一项复杂的系统工程，涵盖网络业务能力的规划、网络流量模型的建立、网络拓扑的设计、网络设备的选型、端到端QoS机制的设计与实施等多个方面。承载网不做与时俱进的调整，再好的IPTV系统也只能是空中楼阁。

    IPTV业务对承载网提出了新的要求：

    IPTV采用流媒体方式实现即时视频、音频等业务，因而对IP承载网的端到端时延、抖动、误码率有较高的要求。

    视频直播：采用单向流媒体传送，同步、实时性要求比较高，对数据包时延的敏感度高；

    视频点播：非交互式的流媒体应用，对同步、实时性的要求不是很高，可以通过设置缓存来降低对时延的敏感度；

    视频电话/会议：交互式流媒体应用，对同步、实时性要求很高，与普通电话要求相当。

    流式媒体流一般来说具有较大的平均包长度，并且包长度变化范围较大，是一种可变速率的数据流，随着视频画面的变化，媒体流会呈现较大的突发；另外，视频流是持续的，持续时间比较长（一般以10分钟计），正常情况下不允许中断，一旦中断，必须尽快恢复。

    针对IPTV业务端到端服务质量的要求，承载网需要在用户PC、STB和CS（中央服务器）、ES（边缘服务器）之间提供完善的QoS 保证。根据国内外的研究成果，扣除服务器、终端编解码、缓存等时间，IPTV业务对承载网的QoS要求大致如下：

    IPTV业务的QoS要求

    业务 时延 抖动 丢包率

    视频直播（BTV） 1s 1s 1/1000

    视频点播（VOD） 1s 1s 1/1000

    可视电话/视频会议90ms 20ms 1/1000

    为了保证用户连续、不中断的收看视频节目，需要保证网络传送的可靠性，在故障的情况下，应在<1s的时间内进行恢复，对可视电话来说，故障恢复时间应<50ms。在BTV业务中，为了获得与传统电视一样的用户体验，在节目切换时，获得新的节目的时间应<2s。

    但是现有宽带网络基本上是为WWW、E-mail、FTP等传统Internet业务设计的，虽然也能够提供基于Web的视频（如在线电视、视频通信）等内容，但距离真正商业规模运营仍存在较大差距，表现在如下方面：

    网络架构不合理、带宽不足：现有宽带网络多采用集中式外挂BAS，单个BAS集中处理数千至数万用户的业务流，吞吐量有限，同时接入层DSLAM/LAN Switch均采用多级汇聚，带宽收敛比很大，每用户实际平均带宽仅100K左右，与IPTV所需的兆（Mbps）级带宽差距遥远。

    无法支持全程全网组播：由于历史的原因，现有城域网L2/L3、路由器组播能力参差不齐，无法全程全网支持组播。虽然通过单播方式也可提供直播电视服务，但视频服务器、网络设备不堪重负，网络扩容赶不上用户的发展，迅速导致网络拥塞，服务质量下降。

    缺乏QoS保证：早期的城域网设备在DiffServ/802.1P等QoS保障机制方面的能力参差不齐，无法保障端到端的QoS；导致视频断断续续，时好时坏，用户无法尽情享受节目内容；更有甚者，闻其声不见其人，倒退到贝尔时代。

    缺乏运营能力：网上大量城域网设备支持可控组播能力差，缺乏对业务、用户控制能力，非法用户轻而易举盗用业务，甚至恶意插播非法内容。

    综上所述，现有城域网网络结构如果不进行改造将无法支撑大规模运营要求，只能进行测试或者很小规模的试商用。

    IPTV业务承载网建设策略

  &nb