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

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

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

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

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

　　流式媒体流一般来说具有较大的平均包长度，并且包长度变化范围较大，是一种可变速率的数据流，随着视频画面的变化，媒体流会呈现较大的突发；另外，视频流是持续的，持续时间比较长（一般以10分钟计），正常情况下不允许中断，一旦中断，必须尽快恢复。
针对IPTV业务端到端服务质量的要求，承载网需要在用户PC、STB和CS（中央服务器）、ES（边缘服务器）之间提供完善的QoS 保证。根据国内外的研究成果，扣除服务器、终端编解码、缓存等时间，IPTV业务对承载网的QoS要求大致如表1。

业务 延时(ms) 抖动(ms) 丢包率
视频直播(BTV) 1000 1000 1/1000
视频点播(VOD) 1000 1000 1/1000
可视电话/视频会议 90 20 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业务承载网建设策略

　　原有网络如何改造，新增网络如何构建，是IPTV开展前期就需充分考虑的问题，包括骨干网、城域网和接入网各个层面。

　　1.骨干网策略

　　骨干网一般采用网状结构，或网状+星型的结构，对各种方向的流量进行调度，使之通过最短的路径、最少的跳数通过骨干网。

　　在承载IPTV业务时，在目前已经存在一张数据网络的情况下，有两种策略，一种是对现有网络进行优化改造，使之满足IPTV业务的要求；一种是新建一个物理平面，满足包括IPTV、NGN、3G业务在内的多种业务的要求。

　　新建第二平面（精品网）的主要考虑是：

 · 业务不同：原网络面向Internet基础业务；第二平面面向精品网的VPN、视频等增值业务；

　　· 用户不同：原网络面向普通用户，用户数量庞大，难以控制；精品网面向高价值客户，用户数量小，行为规范；

　　· 设备要求不同：原网络因历史沉淀，设备档次参差不齐，改造实施困难；新网络充分考虑未来业务需求，设备要求一次到位，便于实施。

　　网络优化 第二平面

　　网络适应与扩展能力 网络流量和物理拓扑不匹配，扩展的带宽被免费流量吃掉 各平面内网络流量和物理拓扑容易匹配，网络扩容落到了实处

　　管理及维护工作量 由于基础型Internet业务和增值类业务的发展趋势、流量模型变化的差异，统一承载将导致管理、维护工作复杂 可根据各类业务的不同特点来管理各平面的网络资源，简化管理及维护工作量

　　QoS部署 业务种类多，区分困难，尤其是一些免费实时业务和跨运营商业务 精品网络用户规范，业务易区分，QoS部署简化

　　可靠性 单一链路、节点失效会影响所有业务 单一链路、节点失效仅影响一类业务

　　安全性 Internet上的病毒、黑客严重威胁大客户的安全，很难追查 用户数量小，行为较规范，可追查，安全威胁小

　　负载分担 按照流量进行负载分担 按照业务进行负载分担

　　投资 扩充链路容量，增加板卡，更新部分设备 新增设备

　　利用和改造现有IP城域网提供IPTV业务，在初期业务量不大的情况下，可以考虑适当改造以满足当前业务发展需求，同时有效控制大规模一次性投入。适合于小规模、实验性开展IPTV业务，但无法满足IPTV业务对承载网的接口及带宽、QoS保证、转发能力等技术要求，无法支撑IPTV业务以及未来NGN、3G业务的大规模商用。

　　新建第二承载平面虽然建网初期的成本相对高一些，但是解决了IPTV规模化开展过程中的流量瓶颈、QoS保证等一系列问题，而且扩展能力强。除了支持IPTV业务，还能够满足NGN、MPLS VPN、3G等电信级业务的大规模商用，是面向未来丰富的宽带增值业务发展需求的组网模式，投资性价比高。在投资允许的情况下，推荐采用新建第二承载平面方式来为IPTV业务提供网络承载。

　　2.城域网及接入网策略

　　在城域网组网上，为了更好地承载IPTV业务，可采用星型+环形的结构，更符合IPTV业务流量模型，星型结构承载单播（VOD）、环形结构承载组播(BTV)。采用星型+环形的结构，组播业务采用专用链路，提高了安全性。其中环网不需要复制多份内容，节省带宽，提高可靠性；互为主备，RPR环网保障业务安全性。

　　在宽带接入部分，为更好地支持组播业务开展，需减少DSLAM/L2级联级数，BAS节点逐步下移，大容量的DSLAM/L2设备尽量与BAS直连。

　　目标城域网除了提供IPTV业务承载，还面向未来的NGN、3G分组语音等电信级业务的承载需求，因此对城域网BRAS设备和DSLAM/LanSwitch设备都提出了功能和性能上的要求。

　　· 对新建BRAS的技术要求：

　　必须支持IGMP V1/V2、PIM-SM/DM等组播路由协议；

　　支持802.1P、DiffServ映射；

　　支持面向端口及面向用户的组播报文复制；

　　支持对大量的STB以及IAD等终端的身份认证；

　　提供高密度的接口特性以满足扁平化组网需求；

　　提供强大的组播转发能力和业务控制能力，能够感知和识别普通上网、IPTV、NGN等多种业务并进行分流，保障不同业务的服务质量；

　　BRAS需要保障IPTV等多业务的运营安全，营造安全稳定的运营环境。

　　· 对DSLAM/Lan switch的技术要求：

　　必须支持基本的组播协议如IGMP Snooping和IGMP Proxy；

　　支持802.1p，支持至少4个优先级队列；

　　支持可控组播，实现组播权限控制；

　　支持两级组播复制，以保障组播业务复制效率；

　　支持模块化的多FE/GE上行接口，以保障随业务发展灵活的从FE升级到GE；

　　IP上行接口提供足够的组播复制性能，至少提供400Mbps以上转发能力；

　　支持频道快速切换以获得与普通电视一样的体验；

　　支持多PVC，提供足够的PVC/VLAN资源，以支持不同业务的隔离与分流；

　　DSLAM作为组播复制和控制点，建议支持组播视频业务的自动发放功能。

文章转载地址：http://www.cnpaf.net/Class/iptv/0610316011994880820.html