展会信息港展会大全

运营商采取什么样的商业模式切入物联网领域
来源:互联网   发布日期:2012-11-25 09:20:56   浏览:7969次  

导读:现在大多数运营商都采取开放能力、建设平台的战略来切入物联网。详细来说,所谓开放能力,就是充分发挥运营商的网络优势,给物联网业务(或物联网应用提供商)提供网络通信服务,最典型的就是基于GPRS或者3G的数据通信服务。 本文站在移动运营商(比如国内的...
    现在大多数运营商都采取“开放能力、建设平台”的战略来切入物联网。详细来说,所谓开放能力,就是充分发挥运营商的网络优势,给物联网业务(或物联网应用提供商)提供网络通信服务,最典型的就是基于GPRS或者3G的数据通信服务。
 
  本文站在移动运营商(比如国内的中国移动、中国联通等)的角度上,分析一下应该采取什么样的商业模式切入物联网领域。众所周知,物联网的预测市场空间是巨大的,说是仅仅在通信领域,就至少有500亿个网络连接的需求。这是个什么概念呢?举例来说,现在中国移动有六到七亿用户,如果这物联网领域的500个通信连接完全由中国移动完成,那么中国移动的用户数至少要膨胀100倍。不管这是不是靠谱,至少很多人,尤其是一些行业巨头(比如本文提到的运营商),都相信了,或者至少装着相信了。不论真相信也好,还是装着相信也好,最终的企业战略,确实是按照相信的前提来制定。即使是装着相信,如果装得时间足够长,也会变成真实。
 
  现在大多数运营商都采取“开放能力、建设平台”的战略来切入物联网。详细来说,所谓开放能力,就是充分发挥运营商的网络优势,给物联网业务(或物联网应用提供商)提供网络通信服务,最典型的就是基于GPRS或者3G的数据通信服务。而建设平台,则是在开放能力的基础上,进一步建设一个包含软件和硬件的基础平台,这个平台可以对物联网应用或系统进行集中管理、集中监控并提供基础服务。注意,这里的物联网应用或系统,不仅仅是运营商自建的应用或系统,而是整个物联网行业内所有的应用和系统。运营商的想法是,仅仅给你通信管道用是不够的,还希望把连接在管道两端的物联网终端、物联网业务软件系统统一管理起来,或者部分的管理起来。对于物联网终端的管理,运营商给出的理由是,可以实时监控通信管道和终端的状态,在故障的时候及时报警。运营商认为网络是自己的,没有人比自己更能够了解网络的状态,因此由运营商提供通信管道(本质上是通信网络)监控服务是天经地义的。而对物联网的业务系统,运营商希望通过统一的管理平台,对之提供一些有价值的服务。比如运营商的物联网平台可以提供一组API,物联网业务系统通过这一组API来实时获取终端的状态,对终端进行实时的配置和调试,甚至集中升级等。
 
  要实现平台战略,运营商必须定义明确的对接接口,以实现物联网终端与平台、物联网业务系统与平台之间的有效对接。只有对接成功,才能完成诸如状态监控、基础服务提供等任务。举例来说,中国移动定义了WMMP协议,来规范物联网终端与中国移动物联网平台之间的通信。任何物联网终端,如需跟中国移动的物联网平台进行对接,则必须实现WMMP协议。对于平台与业务系统,也定义了相应的接口,比如基于SOAP协议的接口等。
 
  我认为这个战略是有意义的,但在推行的时候却有一厢情愿的味道。运营商认为通信管道的状态监控和物联网终端的统一管理是非常关键的,但是物联网业务提供商却不一定这样认为,至少认为不是最关键的问题。同时,运营商认为平台提供的行业管理、终端和通信管道的控制等服务是有价值的,但物联网业务提供商或许认为这些服务都是鸡肋。即运营商的期望与物联网业务提供商的真正需求可能不对等。最关键的是,要获取运营商的这些服务,物联网业务提供商还必须做很多额外的工作,比如要实现WMMP协议、实现平台与业务系统之间的API接口等。权衡下来,付出可能大于受益,于是物联网业务提供商就会选择不跟运营商的平台进行对接,这样运营商希望做行业管理者的愿望就会落空。从国内的实践情况来看,大部分的物联网提供商都不会选择与运营商的平台进行对接,除非运营商给予较多补助,弥补了对接成本和对接受益之间的差异。这对运营商来说非常危险,如果这样持续下去,运营商“开放能力、建设平台”的战略就会落空,运营商希望做行业领头羊的愿望也会落空,跟传统互联网、移动互联网时代的命运相似,运营商将又一次沦落成物联网时代的管道提供商,又做一次冤大头。
 
  “开放能力、建设平台”战略本身是好的,通过开放现有能力给服务提供商,以一种更加开放合作的姿态呈现自己,在此基础上,提供更多的基础服务,使物联网业务提供商把更多的精力聚焦于业务和应用的开发上。问题的关键在于,运营商提供给应用提供商的服务太局限了。不仅内容单一(仅仅是通信管道和终端的监控等),而且还需要应用提供商付出很大的配合成本。所谓“理想很丰满,现实很骨干”。那是不是这个战略就无效了呢?我认为不然,运营商需要重新评估和优化自己的产品offer,为应用提供商提供切实有价值的内容,这个战略还是能够实现的。我认为,面向物联网终端的物联网操作系统,是解决这个问题的关键。
 
  物联网操作系统的概念就不细说了,如果您不清楚,请参考下列连接:http://blog。csdn。net/hellochina15/article/details/7371140,下面看一下,如果运营商推出了面向物联网终端的操作系统,僵局将如何被打破。
 
  首先看服务提供商的配合成本问题。在没有物联网操作系统的情况下,物联网应用提供商需要实现运营商定义的一些协议,比如WMMP等。这可不是一个小的工作量,即使运营商提供了源代码和实现参考,把这些东西移植到某个特定的平台上,还是困难重重甚至是不可能的。但是如果有了物联网操作系统,运营商则可以把这些协议内嵌到操作系统中,只要应用提供商选择了物联网操作系统,那么就天然支持与运营商物联网平台的对接,无需做任何额外付出。显然,业务提供商配合问题得到了很好的解决。
 
  再看一下运营商提供的服务内容单一的问题。显然,现在的管道和终端状态监控等服务,物联网业务提供商并不是非常在乎。在没有物联网操作系统的支撑下,运营商也无法扩展更多的基础服务。但如果有了物联网操作系统,基于这个软件平台,运营商提供给应用提供商的额外服务就可以无限扩展了。首先物联网操作系统可以内嵌各种常用物联网协议的支持,比如NFC、Zigbee、GPRS/LTE等无线通信支持,这样物联网业务提供商和终端开发厂商就避免了自己实现这些基础协议的成本,只聚焦于业务和应用实现即可。其次,运营商可以对某些常用的场景进行抽象总结,开发出对应的功能模块内置在物联网操作系统中。比如针对远程抄表应用,运营商可以开发出通用的抄表策略和本地数据缓存解决模块,供电力公司的抄表终端直接使用。最后,物联网操作系统可以与运营商的网络进行联动,选择在网络不拥塞的时候上报采集的数据。这样不但降低运营商网络压力,提升网络应用效率,同时可降应用企业的成本,毕竟在网络空闲时发送数据比在网络高峰时发送数据,成本要低得多。
 
  物联网操作系统对行业应用提供商的吸引力也是巨大的。原来运营商能够吸引行业应用提供商的,只有网络通信能力。现在则增加了一个可以节约巨大开发成本的软件开发平台。设想一下,在没有物联网操作系统的情况下,物联网行业提供商需要针对终端做操作系统选型、本地通信协议(Zigbee/NFC等)开发、网络通信协议(GPRS/LTE等)开发、业务应用开发等等工作。现在运营商提供了一个具备所有这些功能的操作系统,业务提供商只需把这个操作系统拿过来,做适当定制开发,甚至只需做一些简单配置即可应用,节约的成本和减少的产品上市时间是无法估量的。不仅如此,使用运营商提供的操作系统,还可以直接享用运营商提供的管道和终端监控、终端在线升级、终端远程调试等功能,这又是一个额外的大礼包。显然,应用提供商对运营商的依赖程度将大大增强,运营商在行业内的地位将大大提升,做行业领头羊的愿望完全可以实现。
 
  对运营商自身来说,意义和收益就更大了。推出物联网操作系统后,运营商对行业应用提供商和终端产品提供商的把控能力将大大增强,可以很容易地建立自己在物联网行业内的领导者地位。同时对运营商自身资源使用效率的提升,也有重大意义。通过在操作系统内设定合适的网络使用策略,可以大大降低物联网终端对运营商网络的冲击,有效保护运营商投资。运营商也可以物联网平台为依托,建立类似iOS和Android操作系统的应用商店,推出针对消费者和行业客户的应用。比如还是以电力抄表为例,电力公司可以开发一个平衡电网使用效率的应用软件,放到运营商的应用商店内,供消费者下载使用。消费者通过这个软件,可以更加低成本的使用电力资源(比如在电网负荷最低的时候启动本地电池充电功能)。显然这是一个潜力巨大的市场。如果能够成功,运营商就是现在的Apple公司。在这个操作系统得到广泛使用的情况下,运营商甚至可以以此为依托,定义硬件规范,部分切入IT行业,实现彻底的CT向IT行业的转型。
 
  总之,在当前形势下,运营商推出一个物联网操作系统,将会使“开放能力、建设平台”的战略得到真正落地。就像多米诺骨牌,这个操作系统是整个骨牌系统中的最关键的一张。如果推出成功,那么整个骨牌将倒向运营商,否则将会倒向背离运营商的方向。而且推出这个操作系统的投入也不是非常大的,毕竟物联网是一个全新的行业,没有历史包袱,不存在无边无际的适配泥潭。当前形式下,似乎也只有运营商是最适合做这件事情的。需要强调的是,这不仅仅对运营商自身有利,对整个物联网行业的健康发展也具有非常大的促进作用。运营商如果能够成功迈出这关键的一步,必定能够在IT行业的历史中刻下最光辉的一笔。

赞助本站

人工智能实验室

相关热词: 运营商 物联网

AiLab云推荐
展开

热门栏目HotCates

Copyright © 2010-2024 AiLab Team. 人工智能实验室 版权所有    关于我们 | 联系我们 | 广告服务 | 公司动态 | 免责声明 | 隐私条款 | 工作机会 | 展会港