激活城域网新能量开启运营商与OTT双赢模式
2014-03-06张鹏
本刊记者 | 张鹏
与其指望网络带宽的无限延展,不如将“内容拉近用户”,同时简化自身网络结构,以全新的“智能管道”角色来重新思考和解决“增速不增收”的产业难题。
管道资源是运营商的天然优势,也是赖以生存的根本。近些年,为了能够提供更好的业务体验、挖掘更广泛的商业盈利点,运营商们将工作重点纷纷转向了“宽带提速”,虽然10M、20M乃至100M的接入速率的确刷新了用户对网络的认知,但庞大的扩路工程和高昂的建网成本,却没能为运营商带来等价的服务体验和市场收益。
相反的,我们更多地看到:宽带基础业务“增量不增收”、OTT严重蚕食传统通信服务、用户投诉引发“假宽带”事件等等。
宽带提速无法解决所有问题
究其原因,不外乎以下三点。
首先,宽带提速不等于用户体验,通信网络经过多年沉淀,所承载业务的数量和种类与日俱增,且网络层级复杂、结构臃肿,信息从数据中心到达用户往往需要穿越核心、骨干、城域、接入,任何一个环节都有可能成为限制网速的瓶颈所在。想要单纯依靠拓宽道路来解决用户的体验问题,几乎是不可能完成的任务。
其次,网络不但要扩更要管,这就像是在平坦的道路上行驶车辆,如果没有完善的交规和严格的管控,再宽的路面也会出现拥塞现象。运营商网络也是如此,如果个人业务、家庭业务、政企业务、高价值专线业务不能有效隔离并适配以合理的网络策略,运营商将无法最终保证服务质量与收益。而这也是运营商提出“智能管道”的根本原因所在。
最后,大海般的管道也需要“蓄水池”。曾有观点认为,如果把网络管道设计得像海一样宽广,是不是就能解决所有问题,理论上说得通但实际则不然。现实情况是,业务需求永远“跑”在网络技术前面,以视频业务为例:在家庭用户接入速率2M时(并非独享),互联网上的视频类业务早已“满天下”;当家庭宽带实现10M/20M时,高清、蓝光等超大容量的视频源也早早登堂入室;而当100M似真似假地走近家庭时,支持4K格式的电视终端、OTT盒子以及相应的影视作品也已面世(以上提及数值并非独享带宽,因此单户家中的下载速率将更低)。
进一步说,在云计算、大数据以及移动互联等产业趋势的带动下,数据流量和业务需求总是“道高一尺魔高一丈”地牵引着后台网络、计算及存储等领域不断向前——即便实现了“海一样的管道”,恐怕那时的用户需求也要临近“宇宙般浩瀚”。
所以说,与其期待网络带宽的无限延伸,不如将“内容拉近用户”,同时审视自身网络结构,通过更加扁平化、低收敛比、智能化的网络格局承载起不同等级的网络功能与业务,并以全新的“智能管道”角色来重新思考和解决“增速不增收”的产业难题。
城域网成为通信网络的瓶颈
在这方面,华为作为运营商的长期合作伙伴,在经历了通信网络多年的发展变迁后也是深有同感。华为技术专家告诉《通信世界》记者,近年来,电信运营商可提供给用户的带宽越来越高,但仅仅是带宽的增长还无法使用户体验得到全方位的提升,更重要的是,运营商收入也未得到相应增长。
“我们认为,转机在于城域网,运营商在转向智能管道的探索过程中,城域网在整体网络中扮演中枢大脑的角色,通过技术的改造与创新,让城域网能够为不同业务、不同用户提供差异化的服务,将是运营商未来提高业务收入的关键所在。”该技术专家这样认为。
同时,中国移动集团互联网资源管理处秦越也表示,运营商为避免管道化,需要强化四网融合下的流量经营,除了采用大带宽、高速接口,如在城域网传输部署10G的PTN/PON接入环,网络层大量应用100GE链路以外,更应该加强网络的可视能力和可控能力,比如根据用户和业务进行网络的精确化控制,进而实现端到端的业务保障。
如此,过去并不热门的“城域网”重新回归大众视野,并在智能转型的道路上被运营商给予厚望。但是,运营商的城域网络在多年积累和沉积后,网络层级因业务承载增多而不断叠加,一些省份运营商的城域网节点布局也缺乏规划,部分机房空间有限设备陈旧,这些都为城域网的改造和优化设置了障碍。
与此同时,运营商在网络能力开放、内容交付、政企业务、IDC云应用以及数字家庭等方面的一系列需求却在不断膨胀中,城域网如何能够在不断承载新业务的同时,优化自身结构实现可持续性发展,成为了运营商无法逃避的一道现实考题。
挑战一:拥抱OTT如何实现双赢?
OTT一直是运营商“谈虎色变”的话题,在去年,运营商也曾希望通过政府力量对“微信们”征收一定费用,但无奈市场化浪潮永远推崇公平竞争,即便是国企姿态的运营商也要经受残酷的市场洗礼。
好在运营商并没有放弃尝试,从去年联通推出“微信沃卡”开启了破冰之旅,到今年MWC大会上中国移动宣布的“融合通信”计划(用户可直接在手机界面的消息、通话和联系人中实现文字、语音及图片形式的数据传输,无需开启微信模式),我们都可看出,运营商对于OTT的态度已经从最初的“排斥”转为了“接受”。
甚至一些省份的运营商还在思考,如何将OTT提供商彻底地“收编”,福建电信推出的智能管道开放合作计划就是这方面的有益尝试。
据福建电信方面介绍,该计划将通信能力(如会议、视频、语音、呼叫中心等)和信息服务(向合作伙伴提供用户鉴权、计费、收费)以SDK或者API的形式开放出来,供广大的OTT开发商使用,由此加深双方合作。据悉,类似智慧门铃、智慧钥匙等OTT应用已经上线。
至于城域网侧的技术实现,还有赖于华为的DSG2.0智能提速解决方案——通过将网络能力封装成多组API向OTT提供商开放,而OTT合作伙伴则通过注册账号,申请使用这些API进行开发,最终还可将自身产品与带宽绑定,设计出的业务带宽套餐将可包含在运营商或OTT门户网站中进行销售。
对于运营商建立网络能力开放平台,将具备无限创意的OTT提供商有效聚拢并赋予网络能力,这种做法对于OTT企业的便利自然不用多言,而运营商从中也可以通过申请API手续费、广告投放以及OTT应用分成等方式,获得额外的利润收入,确实得到了双赢的效果。
挑战二:CDN布网缓慢缺乏经济动力
CDN网络是城域网侧的重要网络形态,通过合理布点和内容下沉,无论对于运营商的IPTV业务还是内容交付,都起到了积极的保障作用,三家运营商对其也分别制定了长期和周密的发展规划,比如中国联通的“云计算+CDN”发展模式,中国电信倡导的CDN网络融合开放等等。但现实是,多年来国内运营商的CDN网络一直处于“缓步慢行”的状态,相较于核心、骨干、传输等其他网络层面的快速进程,CDN始终难见大规模动作。
究其缘由,除了技术能力限制外,恐怕还与运营商自身动力不足存在直接关系。据运营商内部人士表示,现阶段,CDN网络主要用于IPTV业务,虽然提升了IPTV视频业务的交付体验,但并不能产生直接的经济效益,再加之IPTV业务在运营商经营占比的份额本就不高,导致运营商对于耗资铺设CDN网络缺乏直接动力;而在部署方面,本地CDN也往往缺乏智能化识别热点业务的能力,很多合作ICP内容在引入时多采用固定布放,如此一来,不但成本较高,缺乏灵活性,而且对于用户侧的业务体验的提升能力也很有限。
如此看来,动力不足和技术受限就成为了目前制约CDN建设的两大核心难题。其实,动力不足源于CDN的“历史因素”——运营商最初建设CDN的本意就是为解决IPTV的“卡停顿”现象,这种头痛医头、脚痛医脚的网络修补方案导致了今天CDN网络缺乏长远的发展规划。
对此,相关运营商人士也表示,未来的CDN网络将不再局限于某一业务,我们通过软硬件解耦、标准能力调用以及统一运营等思路将使得未来的CDN网络具备“全网络适配”的基础平台能力。
对于运营商的长远发展而言,需要保障的服务质量的远不止IPTV这一项,华为技术专家对此也认为,可以采用Smart Cache等方案将合作ICP内容流化至本地CDN(独立设备或BRAS内置),借此破解OTT服务端的带宽瓶径。
挑战三:承载VPN/政企业务,是重建还是混传?
运营商虽坐拥大规模的个人消费用户,但涉及金融、政府、民生以及各行业的大企业VPN专线业务因具备较高的投资回报率,一直以来都是各家运营商看好并极力拓展的业务类别。
随着企业信息化需求和智慧城市理念的不断加深,目前运营商的各类政企业务也都在不同程度上体现出高带宽、多业务、灵活扩展以及低成本的需求趋势。
这对运营商而言,确实提出了不小的难题。一方面要确保企业用户稳定、安全的应用体验,另一方面还要在不增加硬性成本的基础上带给客户更多的商业价值。也就是说,如何以更低的建设成本,构建更加高效的政企专线已经是运营商关心的重点问题。
在这方面,华为技术专家告诉记者,如果采用重建一张网的方式,不仅投入成本巨大还将涉及链路设计等方面的问题。“我们建议采用IP硬管道的技术方案,也就是说,在同一个IP转发通道内进行硬隔离,软管道承载个人业务如上网、语音、视频等业务,硬管道来承载企业专线业务,如此一来不单大大降低了投入成本,同时还可以提供类SDH的高质量、低时延的传输保障。”
同时,城域网能力的不断强化对于运营商提升用户体验和加速业务交付,也起到了积极的推进作用。比如基于DSG(动态业务网关),运营商可根据不同的业务需求进行宽带提速;基于SA(内容感知)能力,运营商通过抓取价值用户的网络行为,可以有针对性地进行热点的精准营销。
而这些网络能力也在新技术的带动下也有了全新定义,类似SDN/NFV、虚拟化等新技术趋势激发了城域网的新活力。比如传统的城域数据机房中,网络软硬件的人工和运维费用都比较昂贵,而用户行为及分布式计算也导致了业务对DC资源需求不够确定。基于SDN的vDC网络架构就可以解决这一难题。
前述华为专家对此解释,通过引入SDN网络控制器对海量末端设备实现集中管理,VxLAN实现跨域大二层网络DC资源共享,NetMatrix等实现全业务自动化部署,而末端设备仅对业务实现硬件转发,这种“控制与转发分离”的网络形式将极大地降低末端设备成本(CAPEX)。