OpenWSN与目前热吵的ZigBee有什么关系吗？
首先，需要明确OpenWSN的用途，该开源项目的提出，一是为了满足科研人员对高性能WSN平台的需要（包括我自己），二是附带的为工业应用提供一个可靠的基础开发平台，毕竟，研究的成果应该到实际应用中去检验。
由此，可以理解OpenWSN与ZigBee的不同：
- OpenWSN为Open Source，强调公益性；ZigBee强调商业利益，几乎所有ZigBee解决方案都存在某种程序的封闭性，比如说Chipcon的方案绑定在Atmega MCU，Freescale的方案绑定在自己的MCU，且源代码一般不开放，如果需要获得源码，就要付出高昂的费用。
- OpenWSN重点关注的内容之一就是ZigBee中被封闭的部分，且其覆盖范围更宽。比如说，MAC和Routing, Location, Time Synchronization等，ZigBee毕竟只规定了很小一部分。
- OpenWSN关注底层，放开应用层(Application Layer)，因为OpenWSN相信，应该赋予使用者最大的自由，而应用层又是变化最多的，因此，OpenWSN不限定应用层，只提供若干规范的开发接口。而ZigBee则一直规定到应用层。
- OpenWSN目标中包括了mobile sink和mobile node情形，而ZigBee可以说只考虑了固定结点情形；
- 如果说ZigBee主要是满足当前实际需要，那么OpenWSN更强调未来。
- OpenWSN与ZigBee都强调互联互通，规范化，标准化
由此可见，OpenWSN更学术化一些，更适合在研究和原型化阶段采用。
那么，OpenWSN和ZigBee有什么关联吗？
OpenWSN首选了ZigBee Compatible Transceiver CC2420作为通信芯片，这使得OpenWSN平台可以被用来开发ZigBee应用，OpenWSN平台资源丰富，可以在一定程度上方便开发。
.
Wednesday, February 28, 2007
Tuesday, February 27, 2007
声明：openwsn.com is NOT me!
郑重声明：openwsn.com is NOT me!——都是重名惹得祸！
本人并未注册openwsn.com的域名！openwsn.com与OpenWSN Project/Group没有任何关系，尽管它的简介中也出现了open wireless sensor networks字样。事实上，该域名从注册之日起，其网站就从未运行过。今后，该网站若有任何活动，也与OpenWSN Project/Group无关。
也许，应该考虑起一个更好的名称！大家有更好的建议吗？
Sunday, February 11, 2007
OpenWSN Frame/Packet Summary (draft 20070210)
OpenWSN Frame/Packet Summary (draft 20070210)
this document describes the format of frames/packets in the OpenWSN system.
attention: this design may be different from what we have done now. we will adjust our system to the following. however, some detail are still in discussion.
IEEE 802.15.4 PPDU format
[4B Preamble][1B SFD][7b Framelength, 1b Reserved][nB PSDU/Payload]
QQQ: whether the higher 7 bit or lower 7 bit represent framelength? can any one answer me?
Note that the preamble byte and SFD (start of eliminator) will be processed by hardware chips. so the software only need care about the data from frame length byte. so the real OpenWSN PHY frame defined in OpenWSN software is as the following:
OpenWSN PHY format (TOpenFrame type defined in hal_openframe.h):
[7b Framelength, 1b Reserved][nB PSDU/Payload]
here, PSDU(or namely the payload of PPDU)
is essentially the MAC frame.
attention that OpenWSN MAC format may use the reserved values in IEEE 802.15.4 MAC in the future.
OpenWSN MAC/IEEE 802.15.4 MAC DATA (the payload of PHY frame)
Beacon Frame
[2B Frame Control] [1B Sequence Number][4 or 10 Address][2 Superframe Specification] [k GTS fields][m Padding address fields] [n Beacon payload][2 FCS]
Data Frame
[2B Frame Control] [1B Sequence Number][4 or 20 Address][n Data Payload][2 FCS]
ACK Frame
[2B Frame Control] [1B Sequence Number][2 FCS]
MAC Control Frame
[2B Frame Control] [1B Sequence Number][4 or 20 ADdress][1 Command Type][n Command Payload][2 FCS]
Frame Control
b2b1b0 frame type 000 beacon, 001 data 010 ACK 011 command 100-111 reserved
b12b13 reserved.
One problem puzzled the developer is the format of MAC address. the MAC address varies from 4 byte to even 20 bytes in 802.15.4. The type of address can be decided by the bit settings in Frame Control word in MAC frame.
In the current implementation of OpenWSN, it uses the short address of 802.15.4 MAC only. That is to say, the PAN id, source node id, and destination node id are all 16 bits.
In 802.15.4, the address(unique id) of a device/node, can be 16 bit/2 bytes (short address) or 64 bit/8 bytes (long address). The long 64 bits address is unique in the world. It should be allocated to the device before the device joins the network. While, the short 16 bit address is unique in a specific PAN. So the short address is only meaning full when combining with PAN id together.
However, there's some difference between OpenMAC and 802.15.4.
OpenMAC does more simplifications than 802.15.4 and also add some new features.
- OpenMAC doesn't provide Beacon Frame
- OpenMAC introduce RTS/CTS frame (not implemented till 20070130 in its simple MAC version, but the full version MAC will implement this mechanism)
- OpenMAC adopts the 802.15.4 MAC control frame and extend it to support RTS / CTS frame.
- OpenMAC adopts the 802.15.4 ACK frame. But the software implementation doesn't care this because the ACK frame is processed by cc2420 transceiver chip.
attention:
there's a macro defined in the OpenWSN software: MAC_HEADER_SIZE. this value is 7(???) = 2 frame control + 1 sequence + 4 address bytes (according to the DATA frame only).
OpenNET packet is essentially the payload of the OpenMAC frame.
NET layer also has its address. The NET layer address and MAC layer address are not same. In OpenNET design, every node is assigned a 16 bit unique id (node id) and 16 bit network id (the same as PAN id). So the design can be simplified ---- OpenMAC and OpenNET share the same address fields.
The OpenNET packet:
[4-20B Address] [1B packet control] [1B Command Type] [nB Data]
attention here the "type" byte is the network layer command/packet type. Don't confuse it with MAC layer command. The MAC layer command is used in MAC layer only.
[4-20B Address]
the 4-20B address is shared by OpenMAC frame and OpenNET packet. Due to the complexity address assignment mechanism of MAC address in full version 802.15.4, OpenNET may introduce self-owned address field in the future. But i think it isn't necessary now. So i still let OpenMAC and OpenNET share the same address field.
[1B packet control] = [b7,...b0]
the packet control byte are reserved for future use.
b0 REQUEST flag, default 0
b0 = 0, means this is a RESPONSE packet. the destination node does nothing when it received the packet. this type is usually sent from the sink node to all the other sensor nodes.
b0 = 1 means this is a REQUEST packet. the destination node is required to reply a RESPONSE type packet. this type is often sent from the sensor nodes to the sink nodes.
b1 BROADCASR flag, default 0
b1 = 0, not broadcast
b1 = 1, the current node should broadcast this packet out.
the above attributes can help to implement NET layer protocols such as SPIN.
[1B Command Type] = [b7,...b0]
b7 is used to distinguish whether the command is a OpenWSN system command or user command (namely, application defined command). b7 is 0 for openwsn system command and 1 for application command.
/* system used data types */
#define ODA_TYPE_DEBUG 0x00
#define ODA_TYPE_CONFIGURE 0x01
#define ODA_TYPE_DATA 0x02
#define ODA_TYPE_LOCATION 0x06
#define ODA_TYPE_UPGRADE 0x07
#define ODA_TYPE_PROBE 0x08 // probing neighbor nodes
/* user defined data type
* the developer can add more TYPE defines if necessary. */
#define ODA_TYPE_USER 0x80
#define ODA_TYPE_TEMPSENSOR (ODA_TYPE_USER + 5)
#define ODA_TYPE_VIBSENSOR (ODA_TYPE_USER + 6)
#define ODA_TYPE_STRAINSENSOR (ODA_TYPE_USER + 7)
#define ODA_TYPE_LIGHTSENSOR (ODA_TYPE_USER + 8)
#define ODA_TYPE_OTHER_USER_DEFINED (ODA_TYPE_USER + 100)
attention the values may be adjusted in the near future. however, i'll try my best to make they are stable.
UART frame is quite similar to the wireless PHY frame.
[1B SFD] [1B Length] [nB Payload]
in UART frame, a special byte is used to indicate the start of the frame. attention here OpenWSN uses the technique of ESCAPE character idea to avoid data confilications. The SFD (start of eliminator) byte is used to represent the start of the frame. if there are SFD characters in Length and Payload, then the UART driver will insert another SFD as ESCAPE character.
(??? i have forgot the detail of UART/SIO driver, so this idea need confirmation)
attention that the Payload of the frame is essentially anything. But in our reference implementation of OpenWSN, we makes the "TOpenFrame" describe above as the payload. So the host application can got all the information of the hardware wireless communications. This feature facilitate the developing of host GUI applications.
.
this document describes the format of frames/packets in the OpenWSN system.
attention: this design may be different from what we have done now. we will adjust our system to the following. however, some detail are still in discussion.
- OpenWSN PHY Frame (in wireless communication)
IEEE 802.15.4 PPDU format
[4B Preamble][1B SFD][7b Framelength, 1b Reserved][nB PSDU/Payload]
QQQ: whether the higher 7 bit or lower 7 bit represent framelength? can any one answer me?
Note that the preamble byte and SFD (start of eliminator) will be processed by hardware chips. so the software only need care about the data from frame length byte. so the real OpenWSN PHY frame defined in OpenWSN software is as the following:
OpenWSN PHY format (TOpenFrame type defined in hal_openframe.h):
[7b Framelength, 1b Reserved][nB PSDU/Payload]
here, PSDU(or namely the payload of PPDU)
is essentially the MAC frame.
- OpenWSN MAC Frame (in wireless communication)
attention that OpenWSN MAC format may use the reserved values in IEEE 802.15.4 MAC in the future.
OpenWSN MAC/IEEE 802.15.4 MAC DATA (the payload of PHY frame)
Beacon Frame
[2B Frame Control] [1B Sequence Number][4 or 10 Address][2 Superframe Specification] [k GTS fields][m Padding address fields] [n Beacon payload][2 FCS]
Data Frame
[2B Frame Control] [1B Sequence Number][4 or 20 Address][n Data Payload][2 FCS]
ACK Frame
[2B Frame Control] [1B Sequence Number][2 FCS]
MAC Control Frame
[2B Frame Control] [1B Sequence Number][4 or 20 ADdress][1 Command Type][n Command Payload][2 FCS]
Frame Control
b2b1b0 frame type 000 beacon, 001 data 010 ACK 011 command 100-111 reserved
b12b13 reserved.
One problem puzzled the developer is the format of MAC address. the MAC address varies from 4 byte to even 20 bytes in 802.15.4. The type of address can be decided by the bit settings in Frame Control word in MAC frame.
In the current implementation of OpenWSN, it uses the short address of 802.15.4 MAC only. That is to say, the PAN id, source node id, and destination node id are all 16 bits.
In 802.15.4, the address(unique id) of a device/node, can be 16 bit/2 bytes (short address) or 64 bit/8 bytes (long address). The long 64 bits address is unique in the world. It should be allocated to the device before the device joins the network. While, the short 16 bit address is unique in a specific PAN. So the short address is only meaning full when combining with PAN id together.
However, there's some difference between OpenMAC and 802.15.4.
OpenMAC does more simplifications than 802.15.4 and also add some new features.
- OpenMAC doesn't provide Beacon Frame
- OpenMAC introduce RTS/CTS frame (not implemented till 20070130 in its simple MAC version, but the full version MAC will implement this mechanism)
- OpenMAC adopts the 802.15.4 MAC control frame and extend it to support RTS / CTS frame.
- OpenMAC adopts the 802.15.4 ACK frame. But the software implementation doesn't care this because the ACK frame is processed by cc2420 transceiver chip.
attention:
there's a macro defined in the OpenWSN software: MAC_HEADER_SIZE. this value is 7(???) = 2 frame control + 1 sequence + 4 address bytes (according to the DATA frame only).
- OpenNET Packet (in wireless communication)
OpenNET packet is essentially the payload of the OpenMAC frame.
NET layer also has its address. The NET layer address and MAC layer address are not same. In OpenNET design, every node is assigned a 16 bit unique id (node id) and 16 bit network id (the same as PAN id). So the design can be simplified ---- OpenMAC and OpenNET share the same address fields.
The OpenNET packet:
[4-20B Address] [1B packet control] [1B Command Type] [nB Data]
attention here the "type" byte is the network layer command/packet type. Don't confuse it with MAC layer command. The MAC layer command is used in MAC layer only.
[4-20B Address]
the 4-20B address is shared by OpenMAC frame and OpenNET packet. Due to the complexity address assignment mechanism of MAC address in full version 802.15.4, OpenNET may introduce self-owned address field in the future. But i think it isn't necessary now. So i still let OpenMAC and OpenNET share the same address field.
[1B packet control] = [b7,...b0]
the packet control byte are reserved for future use.
b0 REQUEST flag, default 0
b0 = 0, means this is a RESPONSE packet. the destination node does nothing when it received the packet. this type is usually sent from the sink node to all the other sensor nodes.
b0 = 1 means this is a REQUEST packet. the destination node is required to reply a RESPONSE type packet. this type is often sent from the sensor nodes to the sink nodes.
b1 BROADCASR flag, default 0
b1 = 0, not broadcast
b1 = 1, the current node should broadcast this packet out.
the above attributes can help to implement NET layer protocols such as SPIN.
[1B Command Type] = [b7,...b0]
b7 is used to distinguish whether the command is a OpenWSN system command or user command (namely, application defined command). b7 is 0 for openwsn system command and 1 for application command.
/* system used data types */
#define ODA_TYPE_DEBUG 0x00
#define ODA_TYPE_CONFIGURE 0x01
#define ODA_TYPE_DATA 0x02
#define ODA_TYPE_LOCATION 0x06
#define ODA_TYPE_UPGRADE 0x07
#define ODA_TYPE_PROBE 0x08 // probing neighbor nodes
/* user defined data type
* the developer can add more TYPE defines if necessary. */
#define ODA_TYPE_USER 0x80
#define ODA_TYPE_TEMPSENSOR (ODA_TYPE_USER + 5)
#define ODA_TYPE_VIBSENSOR (ODA_TYPE_USER + 6)
#define ODA_TYPE_STRAINSENSOR (ODA_TYPE_USER + 7)
#define ODA_TYPE_LIGHTSENSOR (ODA_TYPE_USER + 8)
#define ODA_TYPE_OTHER_USER_DEFINED (ODA_TYPE_USER + 100)
attention the values may be adjusted in the near future. however, i'll try my best to make they are stable.
- OpenWSN UART/SIO Frame (in serial communication)
UART frame is quite similar to the wireless PHY frame.
[1B SFD] [1B Length] [nB Payload]
in UART frame, a special byte is used to indicate the start of the frame. attention here OpenWSN uses the technique of ESCAPE character idea to avoid data confilications. The SFD (start of eliminator) byte is used to represent the start of the frame. if there are SFD characters in Length and Payload, then the UART driver will insert another SFD as ESCAPE character.
(??? i have forgot the detail of UART/SIO driver, so this idea need confirmation)
attention that the Payload of the frame is essentially anything. But in our reference implementation of OpenWSN, we makes the "TOpenFrame" describe above as the payload. So the host application can got all the information of the hardware wireless communications. This feature facilitate the developing of host GUI applications.
.
Friday, February 09, 2007
The Future of Things 推荐,可能影响WSN的一些具体应用
Nanobatteries – Away with Exploding Batteries
http://www.tfot.info/content/view/111/61/
Blood Test Lab-on-a-Chip
http://www.tfot.info/content/view/98/60/
BioPen Senses BioThreats
http://www.tfot.info/content/view/96/56/
TFOT Top 2006 Stories in Science, Medicine, and Space
http://www.tfot.info/content/view/108/57/
TFOT Top 2006 Stories in Technology
http://www.tfot.info/content/view/109/58/
.
http://www.tfot.info/content/view/111/61/
Blood Test Lab-on-a-Chip
http://www.tfot.info/content/view/98/60/
BioPen Senses BioThreats
http://www.tfot.info/content/view/96/56/
TFOT Top 2006 Stories in Science, Medicine, and Space
http://www.tfot.info/content/view/108/57/
TFOT Top 2006 Stories in Technology
http://www.tfot.info/content/view/109/58/
.
Nokia发布了新的NFC无线标准Wibree, 替代Bluetooth?
速率比802.15.4/ZigBee高，可达1M，但距离也更近，较Bluetooth 2.0速率要低，但成本也更低
据说Nokia已经联合了CSR，Nodic等一批公司，样片在2007第二季度发布。
基本上可以说是ZigBee的有力竞争对手。看来，欧洲人还是很喜欢和美国对着干！
有关背景材料
Welcome to the No.1 online source of technical design information for Wibree
By Nodic
http://www.wibree.nordicsemi.no/
The Future of Things网站上的简介
这个网站很有意思，是一个了解趋势培养兴趣的好地方
http://www.tfot.info/content/view/97/59/
不知道这个网站怎么回事，和Nokia什么关系?
http://www.wibree.com/
http://www.wibree.org.uk/
业界的一些评论
Wibree Will Kill ZigBee, Long Live Bluetooth
http://www.theinquirer.net/default.aspx?article=34919
.
据说Nokia已经联合了CSR，Nodic等一批公司，样片在2007第二季度发布。
基本上可以说是ZigBee的有力竞争对手。看来，欧洲人还是很喜欢和美国对着干！
有关背景材料
Welcome to the No.1 online source of technical design information for Wibree
By Nodic
http://www.wibree.nordicsemi.no/
The Future of Things网站上的简介
这个网站很有意思，是一个了解趋势培养兴趣的好地方
http://www.tfot.info/content/view/97/59/
不知道这个网站怎么回事，和Nokia什么关系?
http://www.wibree.com/
http://www.wibree.org.uk/
业界的一些评论
Wibree Will Kill ZigBee, Long Live Bluetooth
http://www.theinquirer.net/default.aspx?article=34919
.
最新无线联网协议RuBee渐热 IEEE 1902.1
NFC的标准现在真是越来越多， 看IEEE又发布了新标准 IEEE 1902.1
特点和评价：低频长波，应该适用于有障碍物甚至金属物阻挡的场合；由此推断其通信速率无疑应该是很低的，似乎是主动RFID的合适选择，但不适合移动类应用，除非移动速率很低。
最新无线联网协议RuBee渐热
技术分类： 通信与网络 发表时间：2007-02-09
您已经熟悉了ZigBee，正在寻求WiBree的用途，现在要开始熟悉另一个无线联网协议RuBee，也称为IEEE 1902.1。零售商和制造商可以在RFID之外选择这个新标准，用于许多应用。
开发RuBee的IEEE工作组将于2月20日在美国麻省波士顿召开第一次会议。RuBee的支持方表示RuBee网络可在10到50英尺范围内采用长波长工作，并可使用低成本无线标签。网络中可包括成千上万的无线标签，工作频率低于450kHz，适用于恶劣环境下的实时库存应用，甚至可以在金属和水的附近以及存在电磁噪音的环境中工作。这种恶劣环境是RuBee吸引用户的关键，也是RFID进入广泛、高性价比实施的主要障碍。
使用RuBee的产品具有的另一项优势是能够直接将数据传到因特网，而RuBee的低速特性使它不适于跟踪许多仓库中的大量的运动中的产品。
但是，RuBee标准的支持各方并没有将其看作RFID的替代技术，而是适用于特定应用的另一种方案。RuBee无线标签可以采用有源标签或者无源标签，使用低廉的锂电池的标签的寿命可达10年以上。使用长波长技术也使其成本低，厚度不到1.5毫米，
可使用4位处理器进行编程。
RuBee标准的制定方认为RuBee网络填补了没有联网、不可编程的RFID标签与采用本地网(802.11)和个人网(802.15)的高带宽的辐射系统之间的空白。这种可搜索标签的实时协议使用IPv4地址，使用这种协议的产品有望在12到18个月内面世。
RuBee的最初支持方包括：大型零售公司，如英国的Tesco集团、德国的Metro连锁店、法国的家乐福和美国的BestBuy；芯片供应商、网络设备厂家和系统开发商，如惠普、IBM、索尼、松下、摩托罗拉和NCR。
1902.1标准将根据现有的RuBee协议，在物理层和数据连路层工作，支持不同制造商推出的标签、芯片、网络路由器和其他设备之间的互操作。
RuBee网络已经在商业应用中使用，包括：医院和手术室中的高价值医疗设备的智能货架；用于库存跟踪的智能商店和仓库货架以及用于牲畜、麋鹿和其他进口动物的农用网络。
Ref: EDN China
http://article.ednchina.com/Communinet/20070208094914.htm
特点和评价：低频长波，应该适用于有障碍物甚至金属物阻挡的场合；由此推断其通信速率无疑应该是很低的，似乎是主动RFID的合适选择，但不适合移动类应用，除非移动速率很低。
最新无线联网协议RuBee渐热
技术分类： 通信与网络 发表时间：2007-02-09
您已经熟悉了ZigBee，正在寻求WiBree的用途，现在要开始熟悉另一个无线联网协议RuBee，也称为IEEE 1902.1。零售商和制造商可以在RFID之外选择这个新标准，用于许多应用。
开发RuBee的IEEE工作组将于2月20日在美国麻省波士顿召开第一次会议。RuBee的支持方表示RuBee网络可在10到50英尺范围内采用长波长工作，并可使用低成本无线标签。网络中可包括成千上万的无线标签，工作频率低于450kHz，适用于恶劣环境下的实时库存应用，甚至可以在金属和水的附近以及存在电磁噪音的环境中工作。这种恶劣环境是RuBee吸引用户的关键，也是RFID进入广泛、高性价比实施的主要障碍。
使用RuBee的产品具有的另一项优势是能够直接将数据传到因特网，而RuBee的低速特性使它不适于跟踪许多仓库中的大量的运动中的产品。
但是，RuBee标准的支持各方并没有将其看作RFID的替代技术，而是适用于特定应用的另一种方案。RuBee无线标签可以采用有源标签或者无源标签，使用低廉的锂电池的标签的寿命可达10年以上。使用长波长技术也使其成本低，厚度不到1.5毫米，
可使用4位处理器进行编程。
RuBee标准的制定方认为RuBee网络填补了没有联网、不可编程的RFID标签与采用本地网(802.11)和个人网(802.15)的高带宽的辐射系统之间的空白。这种可搜索标签的实时协议使用IPv4地址，使用这种协议的产品有望在12到18个月内面世。
RuBee的最初支持方包括：大型零售公司，如英国的Tesco集团、德国的Metro连锁店、法国的家乐福和美国的BestBuy；芯片供应商、网络设备厂家和系统开发商，如惠普、IBM、索尼、松下、摩托罗拉和NCR。
1902.1标准将根据现有的RuBee协议，在物理层和数据连路层工作，支持不同制造商推出的标签、芯片、网络路由器和其他设备之间的互操作。
RuBee网络已经在商业应用中使用，包括：医院和手术室中的高价值医疗设备的智能货架；用于库存跟踪的智能商店和仓库货架以及用于牲畜、麋鹿和其他进口动物的农用网络。
Ref: EDN China
http://article.ednchina.com/Communinet/20070208094914.htm
Sunday, February 04, 2007
启用新的项目管理网站和系统
经过一个多星期的内部测试和使用,决定放弃原先的GForge平台,谢谢OSDN提供的服务, 凭心而论,GForge还是一套相当不错的平台,可以提供我想要得很多工具,特别是项目管理
切换到googlecode是因为看中了Google, 且它的SVN服务更稳定, 而Wiki服务也免除了我发布和修改文档的不便(不过相比较专业Wiki而言还是差不少). 而googlepages也能提供一个方便的网站. 只能说google确实强. 目前source code已经发布在googlecode中,请在Project Hosting中查找OpenWSN项目
美中不足的是googlecode在项目管理方面没有GForge那么强,对大项目多人管理还是存在严重不足.
http://openwsn.googlepages.com
OpenWSN root site. Provide links to other resources.
http://code.google.com/p/openwsn/
OpenWSN on Google Code
you can download source code from his site.
切换到googlecode是因为看中了Google, 且它的SVN服务更稳定, 而Wiki服务也免除了我发布和修改文档的不便(不过相比较专业Wiki而言还是差不少). 而googlepages也能提供一个方便的网站. 只能说google确实强. 目前source code已经发布在googlecode中,请在Project Hosting中查找OpenWSN项目
美中不足的是googlecode在项目管理方面没有GForge那么强,对大项目多人管理还是存在严重不足.
http://openwsn.googlepages.com
OpenWSN root site. Provide links to other resources.
http://code.google.com/p/openwsn/
OpenWSN on Google Code
you can download source code from his site.
Wednesday, January 31, 2007
又一个选择
Contiki：从不起眼的业余爱好者操作系统到博士论题
OSNEWS----还记得Contiki操作系统吗? 几年前它用来在非常古老的家用电脑象Commodore 64 和Apple II上运行网络服务器和网络浏览器。今天Contiki已经长大了，并从业余项目走到了严肃的，用于网络嵌入系统和无线传感器网络研究的嵌入式操作系统。它已经完善了，而且它的创始人Adam Dunkels宣布他的博士论题是Contiki及其组件； Protothread和捆绑有TCP/IP堆栈的 uIP。可能这是不起眼的业余操作系统要走的引人注目的方向，但可能这与它首次发布的时人们所期待的Contiki的方向相去甚远。
Ref
http://osfans-cn.blogspot.com/2007/01/contiki.html
http://www.sics.se/contiki/
http://web4.cs.ucl.ac.uk/staff/E.Rondini/Elisa%20Rondini/Home.html
Pyxos嵌入式控制平台以低成本无线传感器网络为目标应用
原文here
通体上我个人并不看好Pyxos，首先，它缺乏一个容易读且容易记住的好名字，hehe
不过，看看LonWorks/Echelon和ZIgBee两方的争论还是很有意思的，毕竟双方都不无道理
以下内容摘自原文
制造和供应链咨询公司ARC Advisory Group的高级分析师Harry Forbes同意这一点。“我们发现把ZigBee 1.0应用到工厂环境时会出现一些问题，”Forbes说。他最近完成了一份关于ZigBee的报告。
Forbes 在他的报告中写道：“ZigBee最显著的缺点是要为每个ZigBee网络选择单个RF通道，而且限制ZigBee协调器才有通道选择权。工业无线应用倾向于采用这样的无线电技术：即在极其嘈杂且充满变化的多径干扰模式的RF环境中，也能继续工作。出于这个原因，大部分工业无线应用采用跳频扩谱无线电技术。Forbes相信ZigBee联盟将做出某些改变以提高这项性能，但目前它仍是一个大问题。
不过，一些业内人士对Echelon公司借助Pyxos介入无线应用的计划表示了怀疑。
ZigBee联盟尤其提防再出现另一种用于嵌入式控制的专有技术。“ZigBee不同于以前创建的任何控制和传感技术。此前，没有一家开放标准机构（如IEEE）创制出一种简单、极其鲁棒同时又非常低成本的无线数据协议，”飞思卡尔半导体公司的无线技术和战略总监Jon Adams说。飞思卡尔是ZigBee联盟的成员，该联盟开发了利用此无线协议的开放性技术规范。
Jennic是一家基于 IEEE 802.15.4标准的无线微控制器的供应商，其首席执行官Jim Lindop持类似的看法。他表示Pyxos的专有形态以及Echelon公司缺乏开发无线协议的经验会带来一些问题。Lindop特意强调Jennic 公司的技术不涉及较高层协议，既不会同Echelon也不会同ZigBee协议栈有直接的竞争。他敦促Echelon以一种类似ZigBee的方式在 802.15.4标准的上层建立其Pyxos协议。
.
OSNEWS----还记得Contiki操作系统吗? 几年前它用来在非常古老的家用电脑象Commodore 64 和Apple II上运行网络服务器和网络浏览器。今天Contiki已经长大了，并从业余项目走到了严肃的，用于网络嵌入系统和无线传感器网络研究的嵌入式操作系统。它已经完善了，而且它的创始人Adam Dunkels宣布他的博士论题是Contiki及其组件； Protothread和捆绑有TCP/IP堆栈的 uIP。可能这是不起眼的业余操作系统要走的引人注目的方向，但可能这与它首次发布的时人们所期待的Contiki的方向相去甚远。
Ref
http://osfans-cn.blogspot.com/2007/01/contiki.html
http://www.sics.se/contiki/
http://web4.cs.ucl.ac.uk/staff/E.Rondini/Elisa%20Rondini/Home.html
Pyxos嵌入式控制平台以低成本无线传感器网络为目标应用
原文here
通体上我个人并不看好Pyxos，首先，它缺乏一个容易读且容易记住的好名字，hehe
不过，看看LonWorks/Echelon和ZIgBee两方的争论还是很有意思的，毕竟双方都不无道理
以下内容摘自原文
制造和供应链咨询公司ARC Advisory Group的高级分析师Harry Forbes同意这一点。“我们发现把ZigBee 1.0应用到工厂环境时会出现一些问题，”Forbes说。他最近完成了一份关于ZigBee的报告。
Forbes 在他的报告中写道：“ZigBee最显著的缺点是要为每个ZigBee网络选择单个RF通道，而且限制ZigBee协调器才有通道选择权。工业无线应用倾向于采用这样的无线电技术：即在极其嘈杂且充满变化的多径干扰模式的RF环境中，也能继续工作。出于这个原因，大部分工业无线应用采用跳频扩谱无线电技术。Forbes相信ZigBee联盟将做出某些改变以提高这项性能，但目前它仍是一个大问题。
不过，一些业内人士对Echelon公司借助Pyxos介入无线应用的计划表示了怀疑。
ZigBee联盟尤其提防再出现另一种用于嵌入式控制的专有技术。“ZigBee不同于以前创建的任何控制和传感技术。此前，没有一家开放标准机构（如IEEE）创制出一种简单、极其鲁棒同时又非常低成本的无线数据协议，”飞思卡尔半导体公司的无线技术和战略总监Jon Adams说。飞思卡尔是ZigBee联盟的成员，该联盟开发了利用此无线协议的开放性技术规范。
Jennic是一家基于 IEEE 802.15.4标准的无线微控制器的供应商，其首席执行官Jim Lindop持类似的看法。他表示Pyxos的专有形态以及Echelon公司缺乏开发无线协议的经验会带来一些问题。Lindop特意强调Jennic 公司的技术不涉及较高层协议，既不会同Echelon也不会同ZigBee协议栈有直接的竞争。他敦促Echelon以一种类似ZigBee的方式在 802.15.4标准的上层建立其Pyxos协议。
.
2006年度ACM Fellow获奖者列表
click here
attention:
Phillip B Gibbons ( Intel公司 ) won this pride because his work on:
并行计算；数据库；传感器网络
.
attention:
Phillip B Gibbons ( Intel公司 ) won this pride because his work on:
并行计算；数据库；传感器网络
.
Friday, January 26, 2007
Q: 如何用SVN实现OpenWSN的代码管理？
环境建设
Eclipse + Subclipse
Subclipse可以从这里下载
http://subclipse.tigris.org/install.html
一些使用说明
http://gforge.osdn.net.cn/forum/forum.php?thread_id=538&forum_id=521
ps:
for 使用sourceforge的普通用户
在TortoiseSVN的Responsitory Browser中，输入如下的URL：
https://openwsn.svn.sourceforge.net/svnroot/openwsn/trunk
可以浏览当前版本
ps:
关于SourceForge的SVN
After you have registered a new project on "sourceforge", you must enable SVN functionality in admin page before using it. -> it cost me serveral days to find this reason! :(
SourceForge SVN server:
https://openwsn.svn.sourceforge.net
SourceForge Path Responsitory:
/svnroot/openwsn
By default, the anonymous users can have "read" privelidge. Maybe you, the administrator needs to grant write access to the developers in the future.
SourceForge关于SVN的支持文档 Document E09
Eclipse + Subclipse
Subclipse可以从这里下载
http://subclipse.tigris.org/install.html
一些使用说明
http://gforge.osdn.net.cn/forum/forum.php?thread_id=538&forum_id=521
ps:
for 使用sourceforge的普通用户
在TortoiseSVN的Responsitory Browser中，输入如下的URL：
https://openwsn.svn.sourceforge.net/svnroot/openwsn/trunk
可以浏览当前版本
ps:
关于SourceForge的SVN
After you have registered a new project on "sourceforge", you must enable SVN functionality in admin page before using it. -> it cost me serveral days to find this reason! :(
SourceForge SVN server:
https://openwsn.svn.sourceforge.net
SourceForge Path Responsitory:
/svnroot/openwsn
By default, the anonymous users can have "read" privelidge. Maybe you, the administrator needs to grant write access to the developers in the future.
SourceForge关于SVN的支持文档 Document E09
Sunday, January 21, 2007
Q: 如何用SVN获取gforge上的source code?
Subversion相关文档 (英文)这里.
Subversion 匿名访问
svn checkout http://gforge.osdn.net.cn/svn/openwsn
开发者通过DAV访问Subversion
只有项目开发者才能通过这个方法访问SVN。用你的用户名替代developername，并在需要的时候输入你的口令。
svn checkout --username developername http://gforge.osdn.net.cn/svn/openwsn
以上操作可以在Eclipse中进行.
[下载每日快照]
浏览Subversion Tree浏览 SVN tree 可以让你了解项目代码的当前状态。你也可以看到代码的所有历史版本。
.Q: OpenNET设计思想要点(代设计文档)
因为本Group要解决的问题,我们需要网络层协议支持mobile sink结点. 这个要求与孙利民老师06年NSF基金的要求是很接近的. 而现有的大部分协议要么不支持mobile sink特性,要么不支持多个sink node,所以我们不得不自己设计一个.
to be continued
.
to be continued
.
Q:为什么Host上的应用开发优先选择Java?
大家注意到很多子项目的开发都优先推荐Java作为首选语言．这引起了很多年轻朋友们的激烈争辩，熟悉Windows开发的人认为选择C#会好一些，而做嵌入式方面的朋友，又不认可Java在自己这个领域的应用．本文希望能对这个问题作一些回答．
尽管相比于业务而言，语言和工具的选择比较次要，曾有人形象的说：一片树叶到了高手手中，也能成为致命的武器．所以我们不应该过度在意语言的选择．
这种观点有其正确的成分，但是，就一个具体的项目而言，是不能在不同开发环境之间摇摆的．更关键的是，我们当中的大多数人，精力有限，Focus到一种工具或者一种平台上，有助于我们积累经验和交流．
下面是我借鉴google搜索的结果，据说这种做法被某咨询公司用作市场占有率调查，准确度非常高 :)
搜索关键字 数量 搜索关键字 数量
Java语言...... 1,030,000 ...........C#语言 ........ 560,000
Java工具 ..... 2,260,000 ...........C#工具 ..........599,000
Java开发工具 1,030,000 ........C#开发工具.... 759,000
Java应用 ......7,820,000 ...........C#应用 ...........644,000
Java开源 ....1,300,000 .............C#开源 ...........974,000
Java........... 285,000,000 ..............C# ...........70,600,000
结论：C#网络资源大约是Java的 1/4 - 1/10．注意到我为了确认国内的情况，大量用中文搜索词．因为国内号称是Microsoft天下．我希望这个搜索对比能引起程序员朋友们的注意．
我想，这个结果应该能够反映这两种语言在现实世界中的地位．
此外，优选Java作为开发语言还有如下原因：
- Java有强大的开源社区支持，可以提供从操作系统／开发工具直至最终应用全系列的产品．而Windows世界中，开源的精神相对要欠缺很多．
- Java的很多资源可以"Free"获得，而Windows C#等却不可以，例如Java世界中的Eclipse可以做开发环境，非常优秀．这对于降低学术界的工作成本是非常必要的．因此，我们不难发现和理解，国外的大学中开源产品和非windows产品应用极为普遍，我们应该思考为什么．过去，盗版在中国的大学中盛行，而未来，license和费用将成为学术界的一个不得不认真对待的问题．毕竟，作研究的不会有很多钱．在这点上，我们应该学习国外大学．
- 国外学术界有使用Java的传统，网上可以找到大量的学术资源，例如各种算法实现，便于与国外同行作对比．
- Microsoft并不是一家技术上容易合作的公司，但愿我对它的这个评价是错的。
- 嵌入式系统领域Microsoft也不占统治地位，特别是在深度嵌入领域
综上，我希望未来Host上的应用开发能够以Java为主，可以选取Eclipse平台，GUI部分可以用Eclipse提供的SWT和JFace，这样我们可以充分利用国际上已有的资源，并且回避掉许多商业软件的license和费用问题．毕竟，我们不能要求我们的每一个位项目参与者都去买一套商业软件．而在一个公开的项目中采用盗版软件将是非常尴尬的事情．
补记：
参考著名杂志《国际电子工程EETimes》2007.03的一篇文章：
Java在嵌入式系统应用中迎来发展的好时光
说明:虽然现有的worldview客户端程序版本是采用C#开发的,但是我还是非常希望能够看到一个基于Eclipse和Java的新平台出现,这将赋予研究者们更多的资源
.
尽管相比于业务而言，语言和工具的选择比较次要，曾有人形象的说：一片树叶到了高手手中，也能成为致命的武器．所以我们不应该过度在意语言的选择．
这种观点有其正确的成分，但是，就一个具体的项目而言，是不能在不同开发环境之间摇摆的．更关键的是，我们当中的大多数人，精力有限，Focus到一种工具或者一种平台上，有助于我们积累经验和交流．
下面是我借鉴google搜索的结果，据说这种做法被某咨询公司用作市场占有率调查，准确度非常高 :)
搜索关键字 数量 搜索关键字 数量
Java语言...... 1,030,000 ...........C#语言 ........ 560,000
Java工具 ..... 2,260,000 ...........C#工具 ..........599,000
Java开发工具 1,030,000 ........C#开发工具.... 759,000
Java应用 ......7,820,000 ...........C#应用 ...........644,000
Java开源 ....1,300,000 .............C#开源 ...........974,000
Java........... 285,000,000 ..............C# ...........70,600,000
结论：C#网络资源大约是Java的 1/4 - 1/10．注意到我为了确认国内的情况，大量用中文搜索词．因为国内号称是Microsoft天下．我希望这个搜索对比能引起程序员朋友们的注意．
我想，这个结果应该能够反映这两种语言在现实世界中的地位．
此外，优选Java作为开发语言还有如下原因：
- Java有强大的开源社区支持，可以提供从操作系统／开发工具直至最终应用全系列的产品．而Windows世界中，开源的精神相对要欠缺很多．
- Java的很多资源可以"Free"获得，而Windows C#等却不可以，例如Java世界中的Eclipse可以做开发环境，非常优秀．这对于降低学术界的工作成本是非常必要的．因此，我们不难发现和理解，国外的大学中开源产品和非windows产品应用极为普遍，我们应该思考为什么．过去，盗版在中国的大学中盛行，而未来，license和费用将成为学术界的一个不得不认真对待的问题．毕竟，作研究的不会有很多钱．在这点上，我们应该学习国外大学．
- 国外学术界有使用Java的传统，网上可以找到大量的学术资源，例如各种算法实现，便于与国外同行作对比．
- Microsoft并不是一家技术上容易合作的公司，但愿我对它的这个评价是错的。
- 嵌入式系统领域Microsoft也不占统治地位，特别是在深度嵌入领域
综上，我希望未来Host上的应用开发能够以Java为主，可以选取Eclipse平台，GUI部分可以用Eclipse提供的SWT和JFace，这样我们可以充分利用国际上已有的资源，并且回避掉许多商业软件的license和费用问题．毕竟，我们不能要求我们的每一个位项目参与者都去买一套商业软件．而在一个公开的项目中采用盗版软件将是非常尴尬的事情．
补记：
参考著名杂志《国际电子工程EETimes》2007.03的一篇文章：
Java在嵌入式系统应用中迎来发展的好时光
说明:虽然现有的worldview客户端程序版本是采用C#开发的,但是我还是非常希望能够看到一个基于Eclipse和Java的新平台出现,这将赋予研究者们更多的资源
.
我的问题：关于规模 Help
回答了这么多问题
我也有一个问题
目前是否有上千个结点以上应用的真实实验？
或者是哪位朋友曾经做过5000个结点以上的网络仿真？包括ad-hoc领域研究也算上，我希望能取得一些测试数据来验证我对网络的一些想法。
.
我也有一个问题
目前是否有上千个结点以上应用的真实实验？
或者是哪位朋友曾经做过5000个结点以上的网络仿真？包括ad-hoc领域研究也算上，我希望能取得一些测试数据来验证我对网络的一些想法。
.
Q: OpenWSN为什么没有采用标准的802.15.4 MAC和ZigBEE协议？
我想首先纠正一个观点，不存在OpenWSN是否采用某一固定标准的说法。OpenWSN是一个开放的标准体系，它以Library的方式提供给开发人员和研究人员一套可灵活组合并且复用的组件。用802.15.4替换OpenMAC，用ZigBEE替换OpenNET没有任何问题，OpenWSN支持多种选择，而最终选择的自由是用户。OpenWSN不希望强加任何特定的约束给高层用户，它只是希望不同Group/Company的产品能够在底层上互通互换，即使做不到Hardware级别的互通，也可以提供自己特有的Software层次的HAL实现软件上的可移植。
为什么OpenWSN最初没有采用标准的802.15.4和ZigBEE，而是自己提出了一个OpenMAC和OpenNET是源于OpenWSN的定位之一，即它要服务于WSN领域的研究，换言之，MAC/NET本身就是研究的对象，将研究者约束在802.15.4和ZigBEE上显然是不合理的。
此外，实际应用的需求千差万别，802.15.4和ZigBEE并不是万能的。比如说，他们的设计都没有考虑移动mobile node/sink的情形，而我们在做的一个课题就遇到了mobile的问题，这时非得去用802.15.4和ZigBEE显然是没有必要的。而且，构建一套完整的ZigBEE开发环境对用户而言也是一笔不小的支出，至少在我们最初开始进入这个领域时，其价格还停留在十多万的级别。（很多报价很便宜的厂商最后能给802.15.4的代码就不错了，不仅如此，ZigBEE一般都是以二进制方式给出，因此无形中也就限制了使用者选择的硬件平台）因此，我们最初在从事无线Modem开发的基础上，选择了自己做一套。OpenMAC采用类似于802.11的Aloha方式，并没有许多人想象的那么复杂，在低负载时表现应该没有问题，高负载时时延会不确定（仅就目前版本而言）。
可以粗略的给出目前一些方案的定位示意，如下表格不严谨，仅供参考：
...........................|.......固定拓扑网络 .... 可变拓扑网络 ... 高速移动网络
低速率高延迟 ..|...802.15.4和ZigBEE ... OpenMAC ..................?
数据传输
高速率高延迟 ..|...........802.11 ................OpenMAC ..................?
数据传输
高速率低延迟 ..|.............. ?.............................. ?........................... ?
数据传输
标记?的表示目前尚没有好的解决方案。而且，上述解决方案的划分也没有考虑energy问题。如果再考虑energy，就会发现有更多的空白区域是15.4和ZigBEE没有覆盖的。
所以我们可以看出，802.15.4和ZigBEE作为鼓吹的WSN事实标准，也不是万能的，还有很大的研究空间。OpenMAC/NET不过是我们自己针对自己的应用设计的一个简单的MAC/NET协议实现而已。
欢迎其他的Group能够发布你们的MAC/NET研究成果，为OpenWSN提供更多的选择！当然，也非常希望有兴趣的开发人员能够为OpenWSN贡献一套802.15.4 MAC代码，这对高校研究人员构建异构层次网络拓宽研究内容是很有意义的。尽管我们可以拿到针对其他硬件平台的15.4 MAC实现，但是限于版权原因，不能将其加入OpenWSN项目，因此，有兴趣的开发者自己尝试一下还是有意义的。
.
为什么OpenWSN最初没有采用标准的802.15.4和ZigBEE，而是自己提出了一个OpenMAC和OpenNET是源于OpenWSN的定位之一，即它要服务于WSN领域的研究，换言之，MAC/NET本身就是研究的对象，将研究者约束在802.15.4和ZigBEE上显然是不合理的。
此外，实际应用的需求千差万别，802.15.4和ZigBEE并不是万能的。比如说，他们的设计都没有考虑移动mobile node/sink的情形，而我们在做的一个课题就遇到了mobile的问题，这时非得去用802.15.4和ZigBEE显然是没有必要的。而且，构建一套完整的ZigBEE开发环境对用户而言也是一笔不小的支出，至少在我们最初开始进入这个领域时，其价格还停留在十多万的级别。（很多报价很便宜的厂商最后能给802.15.4的代码就不错了，不仅如此，ZigBEE一般都是以二进制方式给出，因此无形中也就限制了使用者选择的硬件平台）因此，我们最初在从事无线Modem开发的基础上，选择了自己做一套。OpenMAC采用类似于802.11的Aloha方式，并没有许多人想象的那么复杂，在低负载时表现应该没有问题，高负载时时延会不确定（仅就目前版本而言）。
可以粗略的给出目前一些方案的定位示意，如下表格不严谨，仅供参考：
...........................|.......固定拓扑网络 .... 可变拓扑网络 ... 高速移动网络
低速率高延迟 ..|...802.15.4和ZigBEE ... OpenMAC ..................?
数据传输
高速率高延迟 ..|...........802.11 ................OpenMAC ..................?
数据传输
高速率低延迟 ..|.............. ?.............................. ?........................... ?
数据传输
标记?的表示目前尚没有好的解决方案。而且，上述解决方案的划分也没有考虑energy问题。如果再考虑energy，就会发现有更多的空白区域是15.4和ZigBEE没有覆盖的。
所以我们可以看出，802.15.4和ZigBEE作为鼓吹的WSN事实标准，也不是万能的，还有很大的研究空间。OpenMAC/NET不过是我们自己针对自己的应用设计的一个简单的MAC/NET协议实现而已。
欢迎其他的Group能够发布你们的MAC/NET研究成果，为OpenWSN提供更多的选择！当然，也非常希望有兴趣的开发人员能够为OpenWSN贡献一套802.15.4 MAC代码，这对高校研究人员构建异构层次网络拓宽研究内容是很有意义的。尽管我们可以拿到针对其他硬件平台的15.4 MAC实现，但是限于版权原因，不能将其加入OpenWSN项目，因此，有兴趣的开发者自己尝试一下还是有意义的。
.
Saturday, January 20, 2007
Subscribe to:
Posts (Atom)