主题：【原创】互联网的继续革命【1】 -- 邓侃
家园 zigbee确实不行， 我们做过实验，使用Crossbow的sensor其信号覆盖范围直径小于10m，当然这里面有为了省电而降低发射功率的问题，但是这样的信号覆盖范围实在不足以支撑很多实际的应用。
再次感叹一下Berkeley的TinyOS。
个人还是比较看好通信网络+TCP这种模式，3G以后，网速不再成为问题，而大规模山寨手机的价格已经可以降到100RMB以下，意味着通信模块的价格也可以到50RMB左右（估算）。而现在高速行进过程的无线网络链接已经解决，比如在时速350km的高速铁路上的通信网络连接，已经不是问题。
家园 CC2520+CC2591, or RF230 基本都可以达到3dbm以上发射功率，和-100以下的接受灵敏度。
我测过RF230在1%丢包率时，1km左右的有效通信距离。
貌似ADI也新出了一款此类RFIC，可以看看最新一期ieee communication mag，设计人员发的paper。
上市后可以看看性能如何。
家园 我一直想问个问题， 就是像zigbee这种无线网络，当遇到2G/3G这种通讯技术时，除了自组织之后，还有那些优势。如您所说，最新的已经可以到1km，这个距离对于绝大部分应用已经很足够了，但是如果用上3G模块+sensor似乎可以做到类似的功能，您是否能对这两种模式做个评价？
之所以有个问题，是因为上次在maillist里面有人问了这么个问题，他们问是否可以把TinyOS移植到某个以ARM为基础的微内核OS上，这个从理论上讲当然没问题，我自己就做过很多移植，而TinyOS从操作系统的角度来讲，是很简单的。但是我想知道的是，他们这么作的意图，本来TinyOS和嵌入式OS是井水不犯河水，各管一块，但是既然他们想移植，说明两者已经在某些程度上开始交叉。一般来说，TinyOS是sensor network，而嵌入式OS可以组成GSM Network or Ethernet Network。
家园 可以一起探讨一下 第一个问题，在有基础设施的情况下当然是可以替代的，但是功耗会是大问题，GSM模块的功耗，我测过的几个，一般都在100mA以上，启动时更会冲到200mA以上。这主要是因为手机网络在设计时或者说标准制定时对节能考虑的很少，3G也存在同样的问题，尤其是TD.Green的概念是最近1，2年才开始有paper出现，相对的WSN则一开始就以功耗为第一优先考虑，像您用过的micaz发送功耗不超过30mA，而那几款新的芯片也是靠设计提高解码效率和降低损耗来提高作用距离而不是靠单纯提高发射功率。cell network+嵌入式平台+sensor会比较适合市内有源的应用，比如说M2M。最好的一个例子是通用在做的给他们自己大型医疗设备用M2M监控插件，由于用在医院环境，同时有源接入，不用考虑功耗，就是手机网络based。北京有个女海归做的山寨公司，前几年还见报了，具体名字我忘了。
但是像一些特种应用，比如野外的环境监测，地质，海洋监测，还有目前比较热门的桥梁监测。功耗就是大问题了，靠电池供电的话，一是总电量就撑不住太长时间，二是要采用sleep/active 来在不需要传输时降低功耗的方法话，gsm模块的启动电压峰会在瞬间拉低电池电压，使得电压达不到启动的最低电压要求，导致只能利用总电量的一部分。
还有一个问题就是很多环境是不存在基站的，比如那个火山应用，还有欧洲对阿尔卑斯山，极地环境的监测，地铁，地下隧道等。而且有的情况下有基站不一定等于基站好用，移动服务商主要是提供语音业务，数据业务的优先级是很低。当年某次在香港大屿山测试时，GSM模块的信号强度是满格，但是链路质量则相当差，平均5到6次拨号才能联通一次，导致严重的数据堆积。所以某次在跟中移动研究院开会时讨论过，能不能给在中移动注册过的M2M用户提供guaranty的后台带宽，来作为一个他们的增值业务^_^.
3G模块，本人没有亲测过，不好说，但是原理应该是类似的。
TinyOS的问题从名字就知道了啦。tiny，呵呵主要是当年是mica平台用的at64（好像是这个，实在太老了），ram和rom都极其有限，只好采用ncc和gcc双次扫描编译，加严格的静态化变量，取消所有的动态生成功能。来保证目标文件的foot point最小。
所以移植到arm上其实没有太大的意义。一个最好的例子是Imote2，PXA271based1一个平台，同样支持tinyos。但是往往用的人都会把firmware重烧成linux（最开始是intel发布的，现在好像是个剑桥的team在维护）来用。
- 复 可以一起探讨一下
家园 花，您的回复比我的提问含金量高多了。 第一个问题，功耗的确是手机网络的大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似乎可行。当然能源问题始终是个老大难。
家园 在西班牙一个小破岛开会，上网不便。 回去再回复。：）
家园 关于TinyOS 再次感叹一下Berkeley的TinyOS。感叹什么呢？是好还是坏？为什么？
- 复 关于TinyOS
家园 我是感慨TinyOS从initial release到 事实上的sensor operating system standard，总共就5年时间，相对于好多其他出现了10几年仍然只能在实验室存活的OS，太幸福了。
家园 明白了，这是时势造英雄。 明白了，这是时势造英雄。
当时SmartDust的情况是，刚开始大家的精力集中在Mote上，主要挑战是微硬件。Mote微硬件有了着落，大家的心思开始想TinyOS，想Mesh Networking，想Streaming Database.
家园 没记错的话 第一批的硬件，tinyos，和路由都是David Culler的那个组的几个博士搞出来的。
Philip Levis做的操作系统，当然不是他一个，但是是核心和领军性的人物。毕业后去了斯坦福。
做mica的硬件好像是Matt Welsh, （这个记不清了，不确定是不是他，要查查他的thesis）后来去了哈佛。
后来做了TelosB的Robert Szewczyk，自己创建了MoteIV，可惜没有经验下去，被风投强令改行，现在好像做java on wsn，然后出了一些终端产品，印象比较深的是一个给数据中心用的能耗检测，像一个万能插座，能记录从这个插座出去的电量。
还有一个越南裔的学生，（好像叫woo）好像是做路由的。记得他是应为他测出了一张RSSI的不规则分布图。
一时风云人物聚集啊。搞得我当时一直以为PhD要做到他们这样才算合格^_^.
- 复 没记错的话
家园 我只知道这个东西是David Culler小组作的， 对他们内部情况就不知道了，不过也真是牛人扎堆啊。这种插座了解一些，但是不知道是他们也在做这个，因为现在电源管理是个hot topic，大家想各种很奇妙的招数来降低PC的用电量，但是我以前一直纳闷这个电脑用了多少电量是怎么测量的，后来有人告诉我，买个插座就可以。
- 复 没记错的话
家园 一时牛人辈出 牛人往往扎堆，这也算是一种群体效应。
做mica的硬件好像是Matt WelshMatt Welsh也做了一些OS方面的研究，与John Ousterhout唱对台戏。John提倡多线程，Matt跟着Eric Brewer反对，他们觉得多工作台的办法更好。
John和Eric都是伯克利的教授，后来John去了Sun Microsystems，眼见着这个太阳在下山，John就去了斯坦福。
Eric做教授不忘发财，90年代搞了一个Inktomi，风光一时。可惜没有经得起2001年经济危机的打击，垮了。但是Eric本人可是发了不少财。
- 复 一时牛人辈出
家园 我还是同意Matt Welsh的思路， 对于sensor这种东西，多线程的确不太适合，如果TinyOS做成了跟其他的嵌入式OS一样的东西（multi-thread, time-driven，memory protection），那么就没有很大优势了，而且如果这样，其他嵌入式OS厂商也很容易跟进，这似乎也可以解释在sensor OS领域，为什么没有其他OS厂商跟进，当然TinyOS的完全开源也是一个原因，另一个就是如果跟进TinyOS的思路，对原有OS的修改太大，几乎相当于重新设计。OS这种东西，技术也是要追求差异化的，同质化的东西只能拼市场和规模，太难。
家园 个人觉得，没人争还是应为市场太小 WSN还是没有到爆炸式增长的阶段。各大公司都有投入，但是都不是主要注意方向，保持慢慢跟踪，有的跟着跟着就放弃比如intel在把xscale产品线卖掉的同时，把做WSN的那个研究组也给裁了。不过几个专做wsn的小公司其实背后都有intel vc的影子在，所以也是另一种慢慢跟踪了。
现在的蛋糕还不值得大家去抢。
家园 crossbow的学术气息比较重 如果追求合理功耗下的通信距离，用CC1系列吧，当然编写软件就麻烦了很多，什么都得自个来。