城域网系列 – 5 ALU新ME的前世今生（IPTV 3）

作者 | 2010-04-25 09:58 | 类型 通讯产品 | 4条用户评论 »

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




系列目录 城域网系列

  1. 城域网系列1 – 前传（上）
  2. 城域网系列1 – 前传（下）
  3. 城域网系列2 – ATM插曲
  4. 城域网系列 – 3：大片之前的加片（上）
  5. 城域网系列 – 3：大片之前的加片（下）
  6. 城域网系列 – 4 AL ME大片前以太网的总结
  7. 城域网系列 – 5 ALU新ME的前世今生（上）
  8. 城域网系列 – 5 ALU新ME的前世今生（中1）
  9. 城域网系列 – 5 ALU新ME的前世今生（中2）
  10. 城域网系列 – 5 ALU新ME的前世今生（中3）
  11. 城域网系列 – 5 ALU新ME的前世今生（中4）
  12. 城域网系列 – 5 ALU新ME的前世今生（中5）
  13. 城域网系列 – 5 ALU新ME的前世今生：L2VPN
  14. 城域网系列 – 5 ALU新ME的前世今生（VOIP和IPTV）
  15. 城域网系列 – 5 ALU新ME的前世今生（IPTV 2）
  16. 城域网系列 – 5 ALU新ME的前世今生（IPTV 3）
  17. 城域网系列 – 5 ALU新ME的前世今生（IPTV 4）
  18. 城域网系列 – 5 ALU新ME的前世今生（MPLS/TE）
  19. 城域网系列 – 5 ALU新ME的前世今生（下）
  20. 城域网系列 – 6 另类玩法PBT
  21. 城域网系列 – 7：FMC 决战城域网（1）
  22. 城域网系列 – 7：FMC 决战城域网（2）
  23. 城域网系列 – 7：FMC 决战城域网（3）- 又见ATM
  24. 城域网系列 – 7：FMC 决战城域网（4）- 3G、IP和数据
  25. 城域网系列 – 7：FMC 决战城域网（4）- 3G、IP和数据（continue）

视频是带宽的主要占用者，所以说到IPTV，就要说一下带宽的问题，在有独立带宽保证的TV传输网络，网络本身基本上不需要提供什么QOS保证，这也符合internet的IP承载网带宽充足，就不需要QOS的观点。因为2001年的IT泡沫，带来了大量的骨干网光纤资源，而WDM技术的发展，目前已经超前IP流量，所以运营商的骨干网带宽到现在都不是问题，并且自有率很高，租用也比较容易，这都是托2001年IT泡沫的造福。但是在接入网方面，情况就完全不乐观了，而TV对接入网带宽要求较高，所以接入网带宽是IPTV的瓶颈。
标清视频需要4M的带宽，考虑到同时还有HSI是频道切换时的单播加速技术，那么最小带宽需要是6M，对于最大量的铜线接入技术，需要ADSL2+来承载，同时还受到距离的限制，不是所有的的用户的ADSL都可以达到的。所以基于ADSL的IPTV，质量保证技术要求就比较苛刻
接入网带宽提升方法很多，从早期的Ethernet到户，到已经喊了很久并开始逐渐部署的FTTH技术，但是这里主要的问题是成本谁来承担的问题，因为只是增加一个IPTV，每月每个用户增加的收入也就10-20欧，那么改造这样一个用户需要多少钱呢？没具体值，但看发达国家高昂的人力成本和较低的施工效率，一定是很高的，那么结果就是ROI非常低，所以没有人愿意承建。但高速信息公路是很好的东西，怎么办呢？两个办法：
1、 国家投入模式：如日本和新加坡，FTTX很好主要是以国家投入为主，这和我党改革开放要想富先修路的思想有点像
2、 运营商投入但要求专营权的形式：因为欧洲电信法早就通过了，所以所有驻地资源都必须开发，并且价格不能完全由卖方说了算，导致incumbent的运营商因为长期官僚和低效率的问题暴露出来，而新运营商得到不小的发展机会。但是对于FTTX，在国家模式不愿意的情况下，只有incumbent的carrier有能力建设，但他们提出，要我建可以，但要求一定年头的专营权，否则这种自己种树给大家乘凉的傻事，打死都不干
3、 像中国这样有钱有人成本低的国家，倒是可以大规模兴建FTTX，尤其是没有固网而最有钱的中移动，最应该用大量的利润快速覆盖FTTX，既能占领未来的接入网市场，又可以不用分很多利润给老外持股者，利民爱国的好事，要赶紧做呀

IPTV虽然不那么好，但却是triple play的核心，所以也是AL新ME核心，主要包括如下内容：
1、 基于VPLS/TE的IPTV承载方案：
（1） 核心是环网方案，AL称为daisy chain，就是环形H-VPLS，如果环上的节点或者链路故障了，则通过TE FRR做环回，这种方式的问题是有点复杂不说，也浪费带宽，H通过PIM redundancy优化了这个方案，后来AL也follow了。
（2） 树形H-VPLS方案，通过VRRP in VPLS来解决链路备份问题，同时也解决了这种拓扑下组播流量的多发问题，好像整体上还要配合一些MAC withdrawal技术，记不得了，反正很烦
2、 频道快速切换和丢帧重传
这是基本的QOE保证，始作俑者是思科和微软，一些简单分析如下：
（1） 频道切换问题：这个问题的本质是MPEG等视频压缩标准+组播定速报文发送导致的，因为其基本原理是增量压缩技术，如果其基础帧，这里就I帧拿不到或者丢失，那么即使后面的B/P帧正常收到，也无法解码，这些帧就废了。等到下一个I帧到达后，图像才能开始，但这个时间因为受到组播定速发送的限制，是秒级附近，所以我们在看数字电视的时候，频道切换不如模拟电视快，很不爽。优化技术原理也很简单，就是在系统得到频道请求的同时，先用单播把最近一个I帧甚至其后的组播流量真正到来前的B/P帧给加速发过来，如果只有I帧，很多情况下就会有马赛克，如果不加速，那么就不能赶上组播的速度，和组播同步的时候还是有马赛克，而加速带来的问题就是，组播来了以后，要有一个减速，具体效果是有快进感，在技术实现细节上，可以通过修改视频帧的时间间隙参数使这个快进尽量平滑一点，这样处理后的视频，效果基本接近传统电视了
（2） 视频丢帧问题：数据通讯丢包是正常的，所以在协议设计上都有相应的重传机制，而组播因为其性质决定了没有该特性，但丢包怎么办？优化方法就是增加了单播的重传机制，此时需要STB要感知到丢包并发出请求，这在早期的STB可能是不支持的，如果是基于Linux的STB，那么一般是可以通过Java做一个补丁支持该功能，否则就可能需要STB上游的设备支持一个proxy，但能否搞定不是很清楚
以上的功能需要IPTV的headend服务器提供相应的功能配合，在用户数越来越多的情况下，对集中式的服务器的压力和带宽浪费都是问题，尤其是很多人同时打开电视的时间段，比如晚上的某段时间，或者热点节目的时候等。解决办法是可以在承载网络的一些节点上增加一些视频cache卡，这种情况下，这个节点应该是可以被STB通过L3访问到的，当然通过L2也可以，那会导致很多终端用户和这个视频存贮节点在一个大的L2 domain，这是很不好的网络设计，所以原则上这个节点应该是L3节点，而最好不用纯L2节点。上面只是一些简单的分析和描述，但也可以看出为了保证达到和传统电视一样的QOE，IPTV很麻烦

系列前一篇 系列下一篇
(1个打分， 平均：5.00 / 5)

工具箱
本文链接 | | 打印此页 | 4条用户评论 »

雁过留声

“城域网系列 – 5 ALU新ME的前世今生（IPTV 3）”有4个回复

  1. ufoism 于 2010-04-25 5:20 下午

    各位前辈 小生最近在学习 h264和fpga，

    想以此为切入点搞芯片设计

    h264学的很痛苦 问下这条路好走么

    我的数学不是很好

  2. fullmesh 于 2010-04-25 6:06 下午

    MS的方案里，快速频道切换（FCC）和丢包重传（RET）都是通过一个Dserver来缓存一段时间的视频数据来实现。STP需要向D－server单播请求FCC or RET。 在ALU的方案里， D－server被集成到Edge router，应该是以视频业务板的形式出现的，该业务板需要缓存巨量的视频数据。

  3. Mine 于 2010-04-25 8:29 下午

    思科有个开源的叫VQE的东东就是为了解决这些问题的，不过个人觉得还是受接入网络影响更大，网络质量或者承载量不行，啥都没用

  4. ABC 于 2010-04-25 8:34 下午

    看吧，骨干网的扩充势在必行。看这次能否催生出新的“7750”。