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

本质上还是一个商业公司，尤其被intel风投接管之后。

军尚:呵呵，也不能说不火了吧

前端时间刚给个小公司讨论过类似的东西。

纯以技术成本而言，传统有线方法还有有很大优势的。无线衰减的随机性和室内的多径效应会让负责无线部署的人头大很一段时间的，没有专业网优人员的话，就只有多布中继点或者类似直放站的东西。作出一套能稳定运行的系统的整体成本会比有线打洞布线高不少。

但是如果考虑到一些隐性成本的话，可能就值得做的，比如那个公司的老板。毕竟同一栋楼里系统也是七七八八，中间牵扯的公关交涉成本，时间成本也是要折合进总体支出的。

Mesh的话最大的特色是各个节点都具有中继功能，但是缺乏稳定的自愈协议栈会是最大问题，像上文说的，本身无线信号就具有很大的随机性，再加上动态的背景噪声或干扰。在链路中断后还能不能再恢复起来是最大的问题。我以前跟过一个公司，他们做了一个学校的项目，刚布起来效果还不错，但是运行一段时间发现慢慢就有节点丢失。到现场一看，发现，学生中午晚上食堂附近的节点总会失去连接，应该是人多或是食堂设备提高了背景噪声。饭点过了后，大部分节点又从新加入网路，但是慢慢的总有一两个的路由表崩溃再也加不了网络了。。。这种协议栈的robust特性的测试会远远大于星型网路或是有线网络。

纯个人意见，谢绝追捕。^__^

基本都可以达到3dbm以上发射功率，和-100以下的接受灵敏度。

我测过RF230在1%丢包率时，1km左右的有效通信距离。

貌似ADI也新出了一款此类RFIC，可以看看最新一期ieee communication mag，设计人员发的paper。

上市后可以看看性能如何。

第一批的硬件，tinyos，和路由都是David Culler的那个组的几个博士搞出来的。

Philip Levis做的操作系统，当然不是他一个，但是是核心和领军性的人物。毕业后去了斯坦福。

做mica的硬件好像是Matt Welsh, （这个记不清了，不确定是不是他，要查查他的thesis）后来去了哈佛。

后来做了TelosB的Robert Szewczyk，自己创建了MoteIV，可惜没有经验下去，被风投强令改行，现在好像做java on wsn，然后出了一些终端产品，印象比较深的是一个给数据中心用的能耗检测，像一个万能插座，能记录从这个插座出去的电量。

还有一个越南裔的学生，（好像叫woo）好像是做路由的。记得他是应为他测出了一张RSSI的不规则分布图。

一时风云人物聚集啊。搞得我当时一直以为PhD要做到他们这样才算合格^_^.

牛人往往扎堆，这也算是一种群体效应。

Matt Welsh也做了一些OS方面的研究，与John Ousterhout唱对台戏。John提倡多线程，Matt跟着Eric Brewer反对，他们觉得多工作台的办法更好。

John和Eric都是伯克利的教授，后来John去了Sun Microsystems，眼见着这个太阳在下山，John就去了斯坦福。

Eric做教授不忘发财，90年代搞了一个Inktomi，风光一时。可惜没有经得起2001年经济危机的打击，垮了。但是Eric本人可是发了不少财。

就是像zigbee这种无线网络，当遇到2G/3G这种通讯技术时，除了自组织之后，还有那些优势。如您所说，最新的已经可以到1km，这个距离对于绝大部分应用已经很足够了，但是如果用上3G模块+sensor似乎可以做到类似的功能，您是否能对这两种模式做个评价？

之所以有个问题，是因为上次在maillist里面有人问了这么个问题，他们问是否可以把TinyOS移植到某个以ARM为基础的微内核OS上，这个从理论上讲当然没问题，我自己就做过很多移植，而TinyOS从操作系统的角度来讲，是很简单的。但是我想知道的是，他们这么作的意图，本来TinyOS和嵌入式OS是井水不犯河水，各管一块，但是既然他们想移植，说明两者已经在某些程度上开始交叉。一般来说，TinyOS是sensor network，而嵌入式OS可以组成GSM Network or Ethernet Network。

对于sensor这种东西，多线程的确不太适合，如果TinyOS做成了跟其他的嵌入式OS一样的东西（multi-thread, time-driven，memory protection），那么就没有很大优势了，而且如果这样，其他嵌入式OS厂商也很容易跟进，这似乎也可以解释在sensor OS领域，为什么没有其他OS厂商跟进，当然TinyOS的完全开源也是一个原因，另一个就是如果跟进TinyOS的思路，对原有OS的修改太大，几乎相当于重新设计。OS这种东西，技术也是要追求差异化的，同质化的东西只能拼市场和规模，太难。

对他们内部情况就不知道了，不过也真是牛人扎堆啊。这种插座了解一些，但是不知道是他们也在做这个，因为现在电源管理是个hot topic，大家想各种很奇妙的招数来降低PC的用电量，但是我以前一直纳闷这个电脑用了多少电量是怎么测量的，后来有人告诉我，买个插座就可以。

第一个问题，在有基础设施的情况下当然是可以替代的，但是功耗会是大问题，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在维护）来用。

WSN还是没有到爆炸式增长的阶段。各大公司都有投入，但是都不是主要注意方向，保持慢慢跟踪，有的跟着跟着就放弃比如intel在把xscale产品线卖掉的同时，把做WSN的那个研究组也给裁了。不过几个专做wsn的小公司其实背后都有intel vc的影子在，所以也是另一种慢慢跟踪了。

现在的蛋糕还不值得大家去抢。

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

回去再回复。：）

最合适的也是军方的特定项目．对日常民用而言，属于＂理论上看起来很美＂，而在实际操作当中，用mesh获得的优势远远弥补不了mesh本身的缺点．日常民用的mesh的背后推手主要是用新概念获得VC的startup以及醉心于发文章的学校教授．你大概可以推断出mesh是怎样的一种情况．