IPTV的业务特征在三重播放(Triple-play)业务中得到了完整体现。在三重播放业务中,终端把广播、通信和互联网业务作为一体呈现给用户。三重播放涉及到广播、通信和互联网业务三大技术体制,要把3种原来有多处不相兼容的体制进行融合困难是显而易见的,因此有必要对现有的技术进行深入研究。由于3种体制技术原先各自独立,没有统一的标准可以遵循,给IPTV业务的开展带来了巨大的挑战。IPTV终端与平台之间由于没有标准的接口模型框架可以遵循,导致不同的IPTV系统各自处于相对封闭的状态,这种状况导致IPTV的运营成本及运营风险增大,阻碍了IPTV产业的健康发展。
业务融合需要技术融合支持,而技术要融合必须对现有的技术进行有条件地剥离和削减。本文从广播、通信、互联网3种网络业务融合的角度出发,展开相关研究,提出了横向的业务能力接口模型,并由此导出纵向标准化协议接口模型,解决目前IPTV业务开展中遇到的问题。
1 IPTV终端与平台标准化接口模型
IPTV业务的发展有其固有的过程。多业务融合的过程一定是沿着结合→整合→融合的路标进行。业务的结合是指业务功能的简单叠加,体现在一个终端上,从用户及技术两个角度看业务都是互相独立的;业务的整合是指通过统一的呈现的方式将多种独立的业务体现在一个终端上,从用户的角度看,业务是统一的,但从技术的角度看,多种业务还是互相独立的;业务的融合阶段是最终阶段,在用户和技术两个角度看业务都是统一提供的。标准化接口模型就是为了解决目前IPTV业务融合发展过程中遇到的问题而提出。
1.1 横向业务能力接口模型
IPTV业务的最终目标是将广播、通信和互联网业务进行融合,向用户提供无缝的融合业务。从现阶段看,IPTV业务虽然最终由终端通过统一的门户提供给用户,但是从技术发展阶段上看三大技术体制还处于较为独立的状态,可以说目前IPTV正处于业务整合阶段。
横向业务能力接口模型针对目前IPTV发展所处的阶段,提出了一种业务在终端融合,向不同的业务平台进行业务请求使用的架构。模型如图1所示。
图1中,IPTV终端整合了多种业务功能模块,从用户的角度来看,终端向用户提供统一的业务,但在技术实现上,可以由不同的业务平台分别提供业务能力。随着IPTV业务不断发展,分类平台的发展趋势是作为一个多业务平台统一集成。
1.2 纵向标准化协议接口模型
为了满足横向业务能力接口模型,IPTV终端需要具有相当的智能,为了实现3种业务,终端需要有条件地支持其涉及到的协议,这就是纵向标准化协议接口模型提出的原因。
根据大量的试验数据和解决方案的比较,结合技术发展和三网融合的趋势,可以得出结论,互联网技术是纵向接口技术架构的基础。互联网协议对业务的支持还在不断完善中,广播业务已经有标准的互联网协议支持其在IP网络上实现,通信类业务的发展特别是基于互联网协议——会话启动协议(SIP)的视频通信是未来通信的发展方向,互联网业务原先就完全使用互联网协议。纵向标准化协议接口模型如图2所示。
处于最下层的是数据链路层(即二层),在二层之上的是传输控制协议/网间协议(TCP/IP),再向上由大量的互联网应用协议组成,通过这些应用协议完成三大类业务的接口。从模型中可以看出三大类业务接口的承载协议都可以基于互联网协议。
2 纵向标准化协议接口模型关键技术分析
纵向标准化协议接口模型是实现终端与平台互联互通的技术关键。标准化接口的关键是协议流程的标准化,统一的协议流程使得平台可以兼容各类不同类型的终端,解决终端需要与平台捆绑的难题。
2.1 流控制与广播业务的实时流式媒体协议
IPTV系统中,基本音视频业务控制接口主要完成媒体数据从服务器侧以流方式传输到用户端。一般视频点播内容主要通过内容分发网络(CDN)完成,即视频数据通过内容分发网络被复制到位于网络边缘的边缘服务器中,然后通过流传输技术传送到机顶盒,最终实现边下载边播放的功能。
流传输[1]的内容包括数据包封装格式、数据包传输格式、流传输的建立、用户的暂停/快进/快退请求处理等,对应地,流传输技术包括流控制协议、文件打包格式、流传输协议等。在标准化接口中,本文采用目前广泛使用的实时流式媒体协议(RTSP)作为控制协议。
RTSP[2]是一个客户机/服务器(C/S)多媒体节目协议,它可以控制流媒体数据在IP网络上的发送,同时提供用于音频和视频流的视频录放(VCR)模式远程控制功能,如停止、快进、快退和定位。同时RTSP又是一个应用层协议,用来与诸如实时传送协议(RTP)、资源预留协议(RSVP)等更低层的协议一起,提供基于Internet的整套流化服务。
RTSP的接口采用控制关键字“方法”(Method)的方式,完成用户的流控请求与响应,不同的Method代表了用户的不同控制请求,如表1所示。
2.2 视频通信与通信业务的会话启动协议
SIP[3]的开发目的是用来帮助提供跨越因特网的高级电话业务。因特网电话(IP电话)正在向一种正式的商业电话模式演进,SIP就是用来确保这种演进实现而需要的下一代网络(NGN)系列协议中重要的一员[4]。SIP是在简单邮件传送协议(SMTP)和超文本传输协议(HTTP)基础之上建立起来的,被用来建立、改变和终止基于IP网络的用户间的呼叫。
SIP有两种消息类型:请求(从客户机发到服务器)、响应(从服务器发到客户机)。
SIP请求消息包含3个元素:请求行、头、消息体。
SIP响应消息包含3个元素:状态行、头、消息体。
请求行和头域根据业务、地址和协议特征定义呼叫的本质,消息体独立于SIP协议,并且可包含任何内容。
SIP定义了下述基本方法,如表2所示
IPTV中使用SIP作为视频通信、即时通信等通信类业务的协议基础,SIP本身也在不断地扩展以适应未来通信业务的开展。
2.3 应用认证与互联网业务的超文本传输协议
由于IPTV业务属于电信级业务,需要可管理、可计费,并且向合法的用户保证服务质量(QoS)。应用认证接口模块在IPTV接口模型中是最重要的模块,用户在使用任何业务之前都需要先和平台交互身份认证信息,也就是都需要使用应用认证接口模块,只有合法的用户才被允许使用IPTV业务。
在标准化的应用认证接口中,本文采用HTTP协议。HTTP协议是基于请求/响应方式(相当于客户机/服务器)。一个客户机与服务器建立连接后,发送一个请求给服务器,请求方式的格式为:统一资源标识符(URL)、协议版本号,后边是多用途因特网邮件扩充协议(MIME)信息,包括请求修饰符、客户机信息和可能的内容;服务器接到请求后,给予相应的响应信息,其格式为:一个状态行,包括信息的协议版本号、一个成功或错误的代码,后边是MIME信息,包括服务器信息、实体信息和可能的内容。
在IPTV中,应用认证采用HTTP中认证(WWW-Authentication)的方式[5],即挑战字(Challenge)交互。用户将身份信息与业务请求发送给平台,平台返回随机数挑战字,终端使用与平台共享的对称密钥加密挑战字并发送给平台,平台验证用户身份,并向合法的用户提供服务。
这种认证的方式结合了共享密钥,有效地统一了所有业务的认证鉴权,具有传输高效、信息安全的特性。
大量的互联网应用协议,如简单对象访问协议(SOAP)、超文本链接标记语言(HTML)及互联网应用,如信息浏览等,都基于HTTP。
3 标准化接口模型与中间件的关系
传统的数字电视系统提出了Java中间件概念[6-7],用以解决互联互通的问题。目前也有很多IPTV的终端或平台厂商提出了IPTV中间件的概念,认为中间件可以实现接口的互通。从本质上来说接口互通的基础是标准化的协议流程,中间件仅是纵向标准化接口模型的一种实现手段。
3.1 IPTV中间件
IPTV系统中的中间件分两类终端中间件和平台中间件两种。
终端中间件是隔离终端业务应用与底层操作系统及硬件的软件抽象层,向下有针对不同操作系统和硬件的接口,向上可提供与操作系统无关的支持各种上层业务应用的应用程序接口(API)。中间件提供的程序接口定义了一个相对稳定的高层应用环境,屏蔽了底层硬件和系统软件的差异。对终端应用软件提供商来说,通过终端中间件可以快速开发部署新的应用。
平台中间件是IPTV平台和应用之间的通用服务。平台中间件位于平台硬件、操作系统和数据库之上,应用程序之下。平台中间件具有标准的程序接口和协议,使得应用服务能够在异构平台之间快速部署。
由于IPTV业务是基于网络的业务,大量的中间件都与网络协议有关,基本的业务流程或协议标准可以通过使用中间件API的方式封装,达到方便应用商开发的目的,例如标准的流播放控制API、业务认证API、浏览器API等,但是对于中间件开发者而言,这些API的封装必须是严格标准化的协议接口,否则通过中间件的方式来实现终端与平台接口的互通将不可能实现。
3.2 接口标准化与中间件
中间件的提出是为了方便业务在异构平台间的集成和快速部署,从应用开发者的角度来看,中间件向应用开发者提供标准的API集或完整的软件开发工具包,使得开发人员在进行开发时无需关心底层的硬件平台、操作系统及网络架构。从中间件开发者的角度来看,开发者必须理解中间件需要封装的协议,并且将这些协议划分成多个逻辑单元,也就是不同的API。中间件与标准化接口功能模块的关系如图3所示。
中间件是接口协议实现的一种手段、一种表现方式,从标准化接口模型的角度来看,中间件规范了面向应用开发人员的接口,但是本质上说,只有当中间件本身封装的内容符合标准接口模型所规定的协议流程,才能真正解决IPTV终端与平台接口的标准化问题,实现互联互通。
4 结束语
IPTV的标准化是一个长期的过程,接口模型也会随着业务融合的阶段不同发生变化。但是IPTV的标准化是否成功具有明确的界定,即产业界认可并遵守,具有延续性和发展性特征,最终具有形成商用产品市场的能力。IPTV产业需要整合广播、通信和互联网三大技术体制。从技术发展的角度看,三大技术体制最终将会走向全IP化的道路。互联网协议目前已经拓展为可以支撑流媒体、通信和互联网的协议,可以作为IPTV业务融合的基础,是IPTV标准化接口协议模型的发展方向。中间件API封装标准接口协议向应用开发者提供了较低的进入门槛,并且能够适应不断变化的用户需求。相信在不久的将来,IPTV能够实现真正意义上的业务融合,并基于下一代网络向用户提供三重播放业务。
5 参考文献
[1] 罗斯青. IPTV流传输技术的现状与分析[J]. 当代通信, 2005(23):31-33.
[2] SCHULZRINNE H, RAO A, LANPHIER R. IETF RFC 2326 Real time streaming protocol[S]. 1998.
[3] ROSENBERG J, SCHULZRINNE H, CAMARILLO G, et al. IETF RFC 3261 Session initiation protocol[S]. 2002.
[4] 强磊. SIP协议全方位概要介绍[EB/OL]. [2004-11-11]. http://www.net130.com.
[5] FIELDING R, GETTYS J, MOGUL J, et al. IETF RFC 2616 Hypertext transfer protocol - HTTP/1.1[S]. 1999.
[6] 姚莉, 张萍,于鸿洋. 基于数字电视机顶盒的Java虚拟机的移植[J]. 电子技术应用, 2005,31(4):47-49.
[7] ETSI TS 102 81 Multimedia home platform (MHP) specification 1.1.1[S]. 2003.
收稿日期:2006-03-15
[摘要] IPTV产业近年来在全球发展迅速,是三重播放业务的典型代表。但是终端与平台接口标准的缺乏成为制约IPTV发展的“瓶颈”。实现IPTV标准化的进程需要研究IPTV与广播、通信及互联网3种体制的关系。采用IPTV终端与三网的横向接口模型,可以解决目前在业务整合阶段标准化接口模型架构的问题;采用以横向架构为基础的纵向协议接口模型,可以确定协议接口标准化向全IP演进的方向;以标准协议接口为基础,在IPTV中引入中间件的方式能够有效降低应用开发的门槛。
[关键词] 标准化;接口模型;整合;中间件
[Abstract] With the rapid growth of the global IPTV industry in recent years, IPTV has become a representative of the Triple-Play services. However, lack of standards for the interface between the terminal and the platform has been the bottleneck of IPTV development. In order to realize IPTV standardization, the relationship between the IPTV system and the broadcast cable network, telecommunication network and Internet should be carefully researched. The horizontal interface model between the IPTV terminal and the three networks is a solution to architecture of the standard interface model at the current phase of service integration. On the basis of the horizontal interface architecture, a vertical protocol interface model is proposed to validate the development trend of IPTV protocol interface standardization towards the all-IP. Based on the standard protocol interfaces, introduction of middleware effectively lowers the threshold of IPTV application development.
[Keywords] standardization; interface model; integration; middleware