公务员期刊网 论文中心 互联网电视论文范文

互联网电视论文全文(5篇)

互联网电视论文

第1篇:互联网电视论文范文

1.1Hbase原有系统架构

HBase是ApacheHadoop的数据库,能够对大型数据提供随机、实时的读写访问。HBase的目标是存储并处理大型的数据。HBase是一个开源的、分布式的、多版本的、面向列的存储模型,它存储的是松散型数据。相比传统的关系型数据库,HBase具有易扩展、大数量、扩展灵活、成本低等优势。

1.2OTT用户行为数据系统架构图

在OTT体系中,每个机顶盒终端就是一个用户,有唯一的用户标识UserID;用户通过机顶盒来访问和使用互联网电视业务,用户在盒端系统上产生的所有行为日志都上传给系统平台(OpenApi),由系统平台进行数据的处理后进行入库,供经分系统进行单用户或批量用户的查询。

2数据结构

2.1数据结构设计

Hbase底层是基于列式存储的,可以在不浪费存储空间的情况下将表设计得非常稀疏。因此可以将所有的用户行为数据存储在一张宽的表中,消除在进行“行为间组合查询条件”查询时带来的表联开销。由于Hbase目前并不能很好的处理两个或者三个以上的列族,本场景中采用单列族设计,列族的大版本数(MaxVersion)设定为1。想要获得较好的查询效率,应该将频繁查询的条件放在RowKey中,尽量保证查询条件都在RowKey中有所体现。从图3可以看出Hbase的查询效率从高到低依次为RowKey、ColumnFamily、ColumnQualifier、TimeStamp和Value。因此想要获得较好的查询效率,应该将频繁查询的条件放在RowKey中,尽量保证查询条件都在RowKey中有所体现。本应用场景中,需要频繁查询的条件依次为用户身份标识(userID)、行为发生时间、行为类型和行为类型所包含的字段及其属性值。根据查询条件的频繁度,可将RowKey设计成userID、行为发生时间和用户行为ID的组合。同时考虑到RowKey的散列性,Key设计方案为:反转userID+“,”+行为发生日期+“,”+用户行为ID。由于单个用户在特定的某一天,相同的行为类型可以发生多次(例如123456789用户在2013年9月1日这一天可以发生多次播放行为),如果采用真实的字段名称作为列名,后来写入的数据会把前面写入的数据覆盖掉。为了保证数据的完整性,需要在原有字段名的后面加上一个当天唯一的列ID以作区分。列ID仅仅为了保证数据的完整性,无任何实际意义,可以是一个从0开始依次递增的数字序列。

2.2数据格式

源数据部分表示由平台产生的原始日志,自定义部分表示源数据经过人工处理后的扩展属性,行为ID为人为定义,列ID为人工生成的标识ID。列ID在一天内的同一个行为日志中具有唯一性。由反转userID和用户行为发生的日期以及用户行为ID组成RowKey,由真实的列名加上列ID组成Hbase里面的列名。

3数据处理

源数据入库过程分为2个步骤,源数据处理和并行入库。源数据处理部分进行源数据整理,包括日志的清洗,RowKey和列ID的生成。并行入库过程将处理好的源数据以MapReduce方式将源数据导入到Hbase中。

3.1数据入库

源数据处理过程负责进行数据清洗及RowKey和列ID的生成,并将生成好的数据文件拷贝到HDFS中。一种列ID的设计方案是将列ID设定为一个从0开始依次递增的数字序列,此ID使得同一天内,同一种用户行为类型的每一条数据都具有唯一标识。以表1中模拟的播放日志数据为例。并行入库部分负责将处理好的源数据以MapReduce方式从HDFS导入到Hbase中。此方式通过读取HDFS上的文件,以Put的方式在Map过程中完成数据写入,无Reduce过程。

3.2数据查询

进行用户行为轨迹查询时需要输入userID的集合、用户行为发生的时间区间和行为类型信息这3个参数。这3个参数限定了查询的范围,即指定用户在指定时间内发生的指定行为。通过解析userID参数可以得到RowKey的前缀部分;解析用户行为发生的时间区间参数可以得到RowKey的中间部分;解析行为类型参数可以得到RowKey的后缀部分和各行为查询所需要的字段。组成RowKey的全部参数集合都确定后,可以通过迭代将查询所涉及到的RowKey全部穷举出来,生成Get对象的列表,进行批量提交。在生成Get对象的时候,可以调用多重列前缀过滤器(MultipleColumnPrefixFilter),使查询结果只包含所需字段,提高查询效率。

3.2.1单用户查询

查询数据时,根据上文提到的查询逻辑,将生成的Get的列表一次性提交,获取查询结果。由于Hbase的设计是基于列的,想要使查询结果按行显示,还需进行查询结果的解析。同时,部分在HBase中无法实现的数据筛选功能如“行为间组合查询条件”、值过滤等,可在此时通过编程语言灵活实现。遍历结果进行解析时,可以生成一个哈希表resultMap、resultMap的key为列ID、value为真实字段名的字符串组合。在遍历中可以根据列ID将真实字段名所对应的查询值替换哈希表中value的值。遍历完成后对resultMap的值集合进行排序,排序结果即为用户的行为轨迹。此方法仅需对查询结果进行一次遍历即可完成解析。

3.2.2批量用户查询

批量用户查询时采用MapReduce方式提交查询、解析查询结果。由于Hbase官方提供的MapReduce接口InputFormat(TableInputFormat)只支持Scan方式来获取数据,并不适用Get方式。因此实现批量用户行为轨迹的分布式提取和解析,需要自定义3个类,即PrefixInputFormat(继承自InputFormat)、PrefixSplit(继承自InputSplit)和PrefixRecordReader(继承自RecordReader)。自定义这3个类的目的在于将输入的userID参数(包含RowKey前缀信息)、日期区间参数(包含RowKey中间部分信息)和用户行为类型参数(包含RowKey的后缀信息和查询所需的列)传入到PrefixInputFormat中,在PrefixInputFormat根据每个userID所在的Region将其分配到不同的PrefixSplit上,在PrefixRecordReader中根据PrefixSplit传入的参数信息完成RowKey的组装和Get列表的生成,并将Get列表作为VALUEIN传递给Mapper进行查询和解析。

4性能对比

测试数据:天翼视讯9月1日到10日之间10d的登陆、播放、访问和订购数据,总计条数约1亿条,日志文件总大小21G;任务描述:找出在9月1日到9月10日这段时间内输入用户集合中同时发生播放、订购、访问、登陆4种行为的活跃用户,并提取这部分用户在这段时间内的用户行为轨迹。

5结论

第2篇:互联网电视论文范文

1.1处理器

传统的数字电视与现今的互联网电视其最大的区别就在于CPU,前者CPU的主要功能是管理用户接口,因此其操作系统规模有限,而后者的CPU的功能十分强大,主要是用来支持应用框架以及应用软件标准等,因此其操作系统需要承担一定量的负载,因此其规模非常大。现阶段互联网电视处理器主要有两种架构:

①APM,即指令集机器,这种架构能够处理32位精简指令;

②MIPS,这是一种微处理器,属于中央处理器架构,前者主要是利用裁剪通用芯片,其主要的优势是降低功耗,使得计算效率得到制定目标。这两种结构所在公司,并不从事处理器的生产工作,而是将其设计产品转卖给其他企业以及公司,而由这些公司进行生产。目前使用的互联网电视终端还没有一个独立的CPU单元,其所使用的技术主要是封装技术,这是一个集成电路,其目标明确。

1.2操作系统

目前所使用的互联网电视操作系统主要有三大类:

①Android系统,其应用优势是成本低,具有的非常巨大的发展空间;

②AppleISO系统;

③企业依据自身发展情况而研发的系统,比较有代表性有康佳研发的Linux系统OMI操作系统,结合了计算机开源技术,能进行个性化加载和运行;海信自主开发的HITV-OS操作系统,并有后台系统作为支持,可以实现下载和计费等功能。AppleiOS是一个传统技术的操作系统、它有一个基于微内核Mach的Darwi。内核,用的是Objective-C这个C语言的超集。而Android在Linux内核之上,集成了一个Java虚拟机Dalvik,应用层跑在虚拟机之上,GoogleIV是以Android为基础,第一代GoogleTVGoogleIV1.0)是以Android2.1为基础;而第二代GoogleTV(GoogleIV2.0)则将Android基础的版本更新到3.1GoogleTV的软件架构是以双系统架构为基础,Android系统十DTV系统,由于双系统的设计,GoogleTV内没有实际DTV的功能模块,只有一些对DTV系统进行控制的通信模块。

1.3互联网电视对音视频的处理

在互联网电视终端对音视频的处理有两种方式:利用GPU实现视频的解码和现实,简称硬解;利用CPU进行软件解码,简称软解。在播放720p(1280×720)和1080p(1920×1080)等高清视频非常耗费资源,如果通过CPU运算来解码,CPU占用率、温度、耗电量居高不下。而利用GPU进行高清视频解码技术,CPU占用率通常可以控制在10%以内。Android和AppleiOS平台都通过GPU的方式进行解码。

2结语

第3篇:互联网电视论文范文

MOS值评价体系是将图像质量划分为1~5的等级来评定图像质量的好坏,评定视频质量时综合考虑丢包率、抖动和编码类型等多种客观因素。如表1所示为国际电信联盟ITU给出的MOS值与人主观评价之间的对应关系。针对互联网电视业务而言,对用户体验造成影响的主要有三个部分:视频源质量、网络传输质量以及终端用户的主观感受,MOS旨在合理地整合这三个方面,模拟出真实用户收看视频时的体验情况。为了估计MOS值,我们可以从以下几个方面获取关于视频质量信息。

(1)数据报文分析主要分析数据包的基本信息,包括地址,端口等,用户标识视频流属性,对于TCP传输会统计对其重传,窗口大小变动等做统计。

(2)RTP、TS分析通过RTP协议特性分析网络层丢包,延时,抖动等网络质量性能参数。对TS流进行分析,统计视频流码率、MID-DF、MID-MLR、TR101290规定的流媒体传输参数(该层分析为网络分析和编码分析的交叉领域,得出参数与两者都有一定关系)。

(3)视频内容分析通过分析PES帧头对流内容的宏观分析得出视频质量的一些参数,比如分辨率、帧率、DTS时戳、PTS时戳等。

(4)视频帧质量分析将IP报文中内容还原为视频帧,并进行计数,同时也统计到达视频流信噪比PSNR。通过对视频帧的还原可以分析视频帧损害比率、废弃比率、过期比率等参数。

2OTT视频质量保障方法

2.1OTT质量保障方法

OTT视频质量保障系统对节目视频从源头到机顶盒终端,全流程监测分析其视频质量,通过在CDN节点部署视频分析设备、并在机顶盒嵌入监控模块的方式,并把链路上各环节的视频流参数实时上传到保障系统,保障系统根据全部上传数据分析OTT的业务质量,当OTT业务质量劣化时提前预警,并对故障进行分析以改善OTT业务的用户体验。视频分析设备的部署示意图为图1。从拓扑图可知,通过在CDN的核心节点、CDN的边缘节点部署视频分析设备,以及在终端内植入软探针,全流程地获取用户观看视频的体验。

2.2质量监测功能介绍

OTT一般是通过CDN平台分发,因此需要对视频源从CDN入口下发到用户整个业务流线质量进行端到端的质量监测,让整个业务平台运营状态可视化、逻辑结构区分,高效运营。OTT视频质量保障系统主要包括的功能模块为:CND节点监测、终端监测、告警及故障管理等模块。

2.2.1CDN节点监测

CDN节点监测模块可以同时监测分析节点内数万个并发视频,实时分析节点内所有视频流的视频质量,主要包括:网络传输质量(MDI媒体传输质量指标、视频流速率、封包丢失、网络带宽利用率等参数)、码流质量(ISOTR101290定义的全部三级告警参数)、视频内容层质量参数等详细信息。

2.2.2终端监控

终端监测模块主要对获取的所有相关信息进行分类汇总显示。

(1)集中质量监控。集中监控所有监控节点包括机顶盒和视频源的视频流播放状况。

(2)提供完整的网络层质量分析。该模块除了提供应用层的详细解码分析之外,还提供了网络层详细解码分析,并以图形化的方式显示出来,帮助用户分层的进行故障排查,迅速解决问题,提高效率。

(3)终端故障分布分析。通过对终端所属各区域进行终端故障统计得出该区域终端数量,故障等级分布以及主要故障。

(4)完整的监测报告及历史监控记录查询。该模块提供了完整的报表功能,帮助用户进行OTT网络质量统计,了解整个OTT网络业务质量的整体趋向,并可作为评判网络质量及运维质量的标准。

2.2.3EPG监控

EPG监测模块实现机顶盒对EPG交互信息的监控,并进一步对视频源服务器实现监控,在控制信令发生异常时向服务器发出警报。

3利用视频网络传输质量

估计MOS值方法由于在实际中视频传输网络可能十分巨大,而且用户观看视频的隐私性需要保证,所以往往不适合采取对视频解压的方法分析视频质量。利用网络传输质量估计MOS值是最常使用的视频质量监控方法,下面我们将描述如何只用网络传输质量估计MOS值。

3.1有关视频网络传输质量的参数

我们采用两个参数描述视频传输质量,一个是视频播放清晰度质量,另一个是视频播放流畅度质量。而视频传输质量受到网络传输特性的影响。网络传输特性往往归纳为三个指标:延迟、抖动和丢包。我们把从发送视频数据包到接收到视频数据包的时间设为传输延迟。在视频传输应用中,恒定的延迟表现为视频观看时间的推迟。为了避免网络抖动而产生的视频播放效果恶化,网络节点和视频解码器往往需要对视频缓冲。实验数据表明,视频播放延迟不影响视频观看质量。而网络传输的抖动和丢包会对视频产生影响。抖动影响视频播放流畅度质量,丢包影响视频播放清晰度质量。思科公司和IneoQuest公司共同提出了IPTV视频传输质量测试标准RFC4445MDI(MediaDeliv-eryIndex)媒体传输质量指标。其中MDI包括两个参数,一个是DelayFactor,延迟因素,简称DF。另一个是MediaLossRate,媒体丢包速率,简称MLR。其中DL对应网络传输的抖动,MDI对应网络传输的丢包率。DF将网络传输视频流的抖动换算成对视频传输和解码设备的缓冲需求,影响视频播放的流畅度。MLR对应传输过程的丢包率,影响视频质量。我们对视频流畅度和视频质量的测算进行了些调整。因为在一般视频质量测算的过程中,我们很难知道视频传输和解码设备的缓冲能力,所以我们用视频抖动来估算视频播放的流程度。在视频信息传输过程中,丢不同的包会对视频质量产生不同的影响。我们根据丢的包是I帧,P帧,B帧,视频头文件还是音频信息来判断丢包对视频产生的影响。在接收端,我们可以知道到丢包的类型和数据包接收的间隔。我们可以从视频数据包接收的间隔判断视频的抖动率。

3.2视频编码结构决定不同数据包丢失对视频的影响不同

电视节目的视频图像内容编码采取GOP结构,丢包造成不同类型的帧数据的丢失会对视频质量产生不同的影响。GOP的长度一般是12帧到15帧,包括I帧、P帧和B帧。GOP结构通过帧间预测提高视频压缩率。I帧是独立压缩的一帧,一般压缩比大概为1:7。P帧由I帧预测而来,一般压缩比大概1:20。B帧则由相邻的I帧和P帧共同预测,一般压缩比大概为1:50。一般一帧的数据比一个数据包要多,所以丢一个数据包只会对视频的一小块造成影响。I帧信息的丢包比P帧和B帧信息的丢包影响更加严重。一个原因是I帧信息的错误会因为视频编码的GOP结构扩大,另一个原因是I帧的错误持续时间长,对视觉的影响较大。I帧的信息如果丢包,往往会因为视频编码对像素值的预测而持续很多帧,对视觉产生较大影响。而P帧或者B帧的信息如果丢包,虽然P帧与B帧的压缩率更高,丢包后影响的图像范围更大,但是因为持续时间短,对视觉的影响并不是很大。此外因为P帧预测B帧,所以P帧丢包影响比B帧更大。此外,如果视频头文件丢包,则整段视频无法解压,对视频质量影响严重。不过互联网电视一般采用MPEGTS编码方式,一个视频头文件只对应一段视频。一个视频头文件的丢包不会导致所有视频无法解压。此外,电视节目视频中有音频编码。因为音频的所占体积更小一些,所以音频的丢包相对于视频图像内容的丢包会对视频产生更大的影响。

3.3利用模糊逻辑得到MOS估计值

我们采用模糊逻辑(FuzzyLog-ic)对MOS的估值进行计算。我们用两个指标描述视频传输质量,视频播放清晰度质量和视频播放流畅度质量。我们用这两个指标来判断MOS的估计值。为了表示简便,让我们用3个档次(低(L),中(M),高(H))来作为这两个指标的隶属函数,该隶属函数用以描述清晰度与流畅度的好坏程度。我们假设对MOS的估计有劣、次、中、良、优六档,对应MOS值1~5。通过视频播放清晰度质量和视频播放流畅度质量两个指标来对MOS的估计,两个指标和对MOS估计结果的关系的如图3的规则表所示。视频播放清晰度质量和视频播放流畅度质量两个指标的不同关系造成了不同MOS估计结果的决定。模糊逻辑处理把一个明确的输入转化为一个模糊隶属值(fuzzymem-bershipvalue)。这个隶属函数有以下特点:

(1)提供了设计者的知识,逻辑关系清晰。

(2)在模糊集合之间提供了平滑的过渡,以平滑变化的参数代表性质的改变,较符合人的认知。

(3)计算简单,逻辑调整方便。模糊隶属函数的典型形状是三角形、梯形和高斯函数。

4结论

第4篇:互联网电视论文范文

互联网电视产业链由内容提供、内容集成、内容分发、电视终端和用户组成,涉及硬件、软件和服务的多个方面,各个环节需协力共同发展,才能推动互联网电视整个产业链的进步。

1.电视终端

互联网电视的接入方式主要包括机顶盒+电视机和互联网电视一体机两种。以乐视、小米为代表的互联网企业积极探路,推出各类盒子,争夺互联网电视入口;以TCL、海信为代表的传统电视制造商,在传统产业基础上,不断革新,大力研发互联网电视一体机,并与互联网企业开展合作,推动互联网电视的发展。互联网电视从根本上改变了传统电视“从上至下”的内容传播模式,成为家庭娱乐服务中心,从用户需求出发,导出服务内容。互联网电视终端的快速发展,对终端元器件要求也不断提高。互联网电视芯片不同于传统电视芯片,在计算能力和显示能力方面有很高的要求,目前互联网电视专用高端芯片仍以高通、Marvell、MTK等国外品牌为主,但尚未获得统治地位。国产芯片海思、瑞芯等加大技术研发力度,主要用于电视盒子。目前,市场上的互联网电视(包括机顶盒和一体机)采用的主要是Android操作系统或基于Android系统的深度开发,但由于Android系统是为移动设备开发的操作系统,对电视设备来说,在大屏上的视频播放和智能交互性等方面都有很大的不足。国外多家厂商积极探索操作系统研发,但总体尚未成熟。国内也正积极研发自主知识产权的智能电视操作系统。

2.内容分发

传统的有线运营商以收取用户收视维护费为主要盈利手段,当内容提供商和集成商通过运营商网络向用户提供互联网电视业务时,网络运营商也积极寻求在该市场占有一席之地。另外,国内三大电信运营商均已具备开展互联网视听节目服务和手机电视分发服务业务的资格,凭借其在市场渠道建设、移动互联网业务、消费者互动等方面的丰富经验,与多家牌照商、终端厂商开展合作,成为有线运营商的直接竞争对手。

3.内容提供和集成

为了保证我国互联网电视的健康发展,正式把接入互联网的电视终端纳入了监管范畴,从而对互联网电视产业进行有效的规范和引导。广电总局对互联网电视采取“集成业务+内容服务”的管理模式,分别颁发两类牌照,即“互联网电视集成业务牌照”与“互联网电视内容服务牌照”。另外,海信、TCL等电视厂商,乐视、小米等互联网公司都建立了自有电视内容平台,但由于政策限制,多选择与牌照方合作的方式,为用户提供视频服务。

二、互联网电视运营模式

“互联网思维”融入电视彻底改变了传统电视的运作模式。互联网电视产业链上各利益主体跨界合作,抢占入口的新模式不断涌现,在不同模式下,各利益主体的地位也不同,目前,尚未形成统一的发展模式。从海外互联网电视发展情况来看,美国互联网电视行业处于起步阶段,但发展较为迅速。国外互联网电视产业呈现以内容为主导的发展态势。苹果TV机顶盒:自2007年首发AppleTV机顶盒以来,已历经三代产品,因此,其盈利模式不仅有硬件收入,更有平台分成。从国内来看,产业链多方开展合作,软硬件结合,带动互联网电视的发展,但各主体利益诉求不同,还需不断磨合。具有代表性的有:产业链垂直整合模式。乐视网与七大牌照方之一的中国网络电视台达成战略合作。乐视互联网电视以低价的终端吸引用户,培养用户的内容使用习惯,成为未来盈利的重要手段。“电视终端厂商+互联网企业”合作模式。随着软硬件一体化成为未来发展的趋势,互联网企业和电视终端厂商纷纷联手,旨在实现产业链共赢。“电视终端厂商+有线运营商”合作模式。借力运营商丰富的渠道和推广经验,运营互联网电视。采取硬件免费、服务收费的联合运营模式。根据国外发展经验,在互联网电视时代,用户对于信息不再是被动接受,而是“双向化”的选择,用户对于内容和服务的需求日益提升。国外内容主导型的模式已经逐步建立,内容和服务方面的竞争日益激烈;而国内受制于监管政策,牌照商在整个产业链中处于核心位置,各方在开展互联网电视业务过程中,都和牌照商紧密合作,国内的互联网电视发展模式尚未清晰。预计未来,能够建立丰富内容优势的电视厂商或具有更大的发展空间。

三、互联网电视发展建议

目前,台式电脑、平板电脑和智能手机等终端已形成相对稳定的竞争格局,而我国在这三大互联网入口方面的发展相对滞后。但对于互联网电视来说,美国等国家互联网电视发展虽起步相对较早,但仍处于起步阶段,我国应重点把握好该机遇,从国家政策、产业链主体等多方面支持民族产业发展。

政策层面:积极完善相关政策,营造良好的产业环境,鼓励和扶持内资企业研发相关核心技术,发展本土互联网电视芯片、互联网电视操作系统;探索互联网监管模式。受制于我国特殊的监管政策,互联网电视牌照商在保证了内容安全性的同时,也影响了内容的丰富性,加大了互联网电视企业内容整合的难度和成本。

第5篇:互联网电视论文范文

电信运营商介入互联网电视业务有利于整个产业的发展,可以解决目前互联网电视商业模式不清晰、缺乏方便快捷认证能力,缺乏前/后向计费渠道,缺乏用户投诉、售后服务和售后营销渠道,以及网络质量无法保障的问题。借鉴移动互联网的发展模式,电信运营商在电视产业的布局需要以类似于智能手机的“云管端”的方式构建互联网电视应用的运营管理模式,吸纳和保有用户入网,提升宽带价值。而且与互联网内容提供商和服务提供商的关系应该从OTT(OverTheTop)转变为产业合作关系,双方协同发展,为用户提供高体验、高品质的应用和服务。

2电视应用管理模式

电信运营商开展互联网电视业务的根本目的是利用电视的屏幕来扩展互联网业务,视频业务虽然是互联网电视的核心关键业务,但是如何加入其他增值应用和行业应用才是需要解决的首要问题。本文提出了统一的电视应用管理模式以实现对视频业务和增值业务(应用)的统一管理,具体包括建设半开放、半封闭的电视应用管理系统,采用松耦合方式与应用系统对接,以及按套餐方式对应用进行打包销售。在统一的电视应用管理模式中,创新性地提出应用管理平台和电视应用商店互相配合完成应用管理,包括应用上传、应用的产品打包和应用,以实现电视应用的有效管控,引入视频业务和游戏、音乐、教育、、咨询、阅读、行业等各种增值应用。下面从应用打包销售、电视应用管理系统来对这种应用管理模式进行详细的说明。

2.1应用打包销售

付费牵涉到安全和用户接受度问题,通过运营商平台收费已经常态化、正规化,用户能接受,而且用户比较信赖。电信运营商能够成批引入应用,打包销售,不仅可以打造出具有持续盈利能力的价值链,从用户和收入来源上掌控应用,而且使得电信运营商的计费手段成为电视行业的标准支付手段,避免沦落为纯管道。为了推动互联网电视用户规模化发展,本文建议使用套餐方式打包出售应用和服务。例如将视频业务和音乐、阅读等各种增值应用业务打包,与宽带业务、手机业务进行捆绑销售,用户缴纳套餐费用后,可以随意使用套餐中的产品,而不是以传统的按消费次数进行收费。打包销售应用是目前移动互联网新兴的应用销售方式,以KDDI推出的SmartPass手机应用套餐服务为例,每月只需要交390日元,相当于乘一两次地铁的钱就可免费下载500多个KDDI打包应用。具体计费方法建议采用如下2种方式。

a)采用一定的用户规模预测量提前与CP/SP进行分成。例如KDDI的SmartPass套餐是按照400万用户的预测量提前给内容提供商/服务提供商(CP/SP)分成,即拥有400万用户数就可以达到盈亏的平衡点。

b)对于某些应用,可以根据应用的活跃使用量,与CP/SP分享套餐订阅收入。例如对于某些非常热门的游戏应用可以采用这种方式,以提高游戏厂商热情。

2.2电视应用管理系统

电信运营商负责建设、管理和维护终端管理平台、应用管理平台和应用商店,打造“终端管理平台+应用管理平台+电视应用商店+管道+电视桌面”的应用管理系统,如图1所示。应用管理平台对互联网电视业务进展集中的管理和维护,包括业务申请、业务审批、业务开通、业务信息查询,以及应用打包等功能;电视桌面提供互联网电视终端,例如智能机顶盒或智能电视一体机,开机后桌面的鉴权,同时提供各种应用使用的计费/统计功能,为业务运营提供数据,例如应用使用次数;电视应用商店利用运营商的渠道优势,将应用汇聚到运营商的电视应用商店中,将认证、鉴权、计费能力开放给开发者,不仅可以掌握电视应用市场的主动权,具备监控和管理应用的能力,而且增加了运营商在产业链中的参与角色;终端管理平台主要是完成对互联网电视终端进行远程管理,主要功能包括终端注册认证、异网接入禁止、业务与配置信息的管理,与IPTV系统中的终端管理平台类似,本文不做详细说明。终端管理平台、应用管理平台、电视桌面和电视应用商店相互配合完成电视应用的运营和管理,流程说明如下。

a)互联网电视终端开机启动后,电视桌面就到终端管理平台进行终端验证,只有通过验证才能使用。

b)用户只能通过电视桌面上的应用商店客户端下载和安装应用,各种应用系统与应用管理平台采用松耦合的方式进行对接。

c)用户使用某个应用时,电视桌面首先判断用户订购的套餐中是否包括该应用或者是免费应用,如果是已经订购的应用或者是免费应用,那么将控制转移给应用本身,如果是用户还未订购过该应用,则连接应用管理平台进行应用鉴权、应用订购。

3应用管理平台

应用管理平台不仅进行用户、用户和电视桌面的有效管理,而且还负责应用打包、应用运营管理,包括用户开机登录时的互联网电视用户认证和应用的认证鉴权,并根据用户下载和使用应用时产生的CDR数据及业务订购关系产生计费话单(该计费话单将作为IT/CRM进行用户计费、SP结算的依据)。电视应用管理平台包括用户管理、CP/SP管理、业务管理、认证鉴权、计费结算、桌面后台等模块。CP/SP管理模块对CP/SP的基本信息管理、生命周期管理、信息度管理、监控报警等功能,完成CP/SP合作引入;用户管理模块对互联网电视用户基本信息的管理,以及包括开户、销户、应用订购关系的管理;业务管理模块对互联网电视业务进展集中的管理和维护,包括业务申请、业务审批、业务开通、业务信息查询,以及应用打包等功能;桌面后台模块提供机顶盒开机后桌面的鉴权,同时提供各种应用使用的计费/统计功能,为业务运营提供数据,例如应用使用次数。在实际建设方案中,为了平台建设轻量化,可以采用IT/CRM(省电信公司)实现互联网电视业务的开户、计费和结算,通用数据库(UDB)提供的天翼账号以实现与宽带账户、移动业务等账号的统一管理,以及翼支付提供在线支付能力。为了对应用进行打包销售,借鉴IPTV业务管理体系中的内容管理方式,提出了类似的应用管理方式,将业务分为应用、应用服务和产品3级结构,应用只有打包为服务,然后打包为产品才能提供给用户,详细说明如下。

a)应用:由CP/SP提供,向用户直接提供业务服务的逻辑对象,应用可以是视频应用或者增值应用,每个应用都有一个唯一的应用ID;应用的操作对象就是应用软件本身,例如AndroidAPK。

b)应用服务:是电信运营商与CP/SP的界面,也是双方业务协商时采用的逻辑对象。每个应用服务都有一个唯一的应用服务ID。服务带有应用的价格描述,但是只用于应用销售的建议和结算,不用于面向用户的直接销售。

c)产品:由电信运营商提供,是电信运营商和用户的界面,也是直接用于向用户销售的逻辑对象,每一个产品都有一个唯一的产品ID。产品中包含有销售价格、有效期及计价方式等信息。多个应用可以打包为1个应用服务,即允许1个应用可以属于单个或多个应用服务;多个应用服务能够打包为1个产品,同时允许1个应用服务分别打包到多个产品。应用、应用服务和产品之间的对应关系。

4结束语