五千年(敝帚自珍)

主题:【原创】互联网的继续革命【1】 -- 邓侃

共:💬128 🌺386
全看分页树展 · 主题 跟帖
家园 花,您的回复比我的提问含金量高多了。

第一个问题,功耗的确是手机网络的大Bug,您给的数据很有价值,比如GSM模块的功耗,micaz的功耗,还有gsm模块的启动电压很高,利用率不高,这些我之前都不太清楚,很受教了。

关于给M2M用户提供iguarantee带宽的问题,我估计当时的基站可能还都不支持这个优先级功能,不过我看过最近的中兴通讯关于他们最新基站协议的说明里面,已经有预先处理这个功能了,但是是否已经启用,不太清楚。您提的这个提供gurantee的服务,作为增值业务的想法不错啊,他们肯定又能赚一笔的。

第二,关于TinyOS和ARM的问题,我今天想了想,觉得有这种可能:因为TinyOS已经sensor OS的标准操作系统了,目前众多的sensor mode都支持TinyOS,市场上也有销售的各种各样的有不同功能的sensor,但是一个Mode上面能够集成的sensor终归是有限的,体积都是问题。而且gateway mode和sensor mode物理器件是一样的,只是跑不同的程序而已,这种情况下,距离root node(传感器网络的汇集节点)越近,gateway mode的带宽限制就越厉害。因此,可以出现这么两种需求:1,虽然我们把sensor mode都称为dust,但是在实际部署的时候,这个东西也是有成本的,不可能真的像宣传片中那样撒出去部署。所以在一定范围内,考虑冗余度的情况下,部属2-3个同类型sensor mode就足够了,而且最好能让这几个sensor mode接力工作,如果sensor mode1死掉了,那么就让sensor mode2接手,依次类推,这样似乎可以解决sensor稳定性的问题。但是如果要实现这种功能,就必须要一个真正的OS,把TinyOS移植到某个small os上,TinyOS负责控制sensor,small os负责监控多个TinyOS的运行,或者杀掉一些所负责的mode已经死掉的sensor。具体做法就是可以在一个ARM上面焊上多个sensor mode,而且ARM也够大,上面可以焊接的sensor mode可以有多少个就接多少个,不存在带宽体积不够的问题。2,还是我们前面所说的到了汇集节点附近的gateway mode可能受到带宽限制的问题,还是老办法,用一个ARM上面接多个gateway mode对带宽进行分流,每个gateway mode还是一个TinyOS控制,然后多个TinyOS由small os控制。

在这种架构下面,TinyOS就成了一个small os下面专门用于控制某个mode的一个驱动,因为有了真正OS的支持,这种东西可以比较容易地与互联网融合。当然,PC也可以作,Linux也可以,但是PC的成本和Linux的体积问题使得选用PC + Linux并不是个好办法,ARM + Small OS似乎可行。当然能源问题始终是个老大难。

全看分页树展 · 主题 跟帖


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河