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

第一个问题，功耗的确是手机网络的大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似乎可行。当然能源问题始终是个老大难。