Who will make the race in low power wireless standards?
- Ieee 1451.5
Wireless sensor network & standards
Wireless Sensor Networks (WSN) are spatially distributed, autonomous sensors that cooperatively
monitor environmental conditions with application in military and civil domains (nature
and species monitoring, agriculture, production and delivery, health care, etc.) . WSNs are
highly dynamic and transient in their nature – connectivity is often unpredictable, devices disappear
and reappear changing network addresses, new ones are added to extend the network
or replace failed ones. They often include an abstraction layer for communication mechanisms
with a wide variety of sensor devices.
Several standards are currently either ratified or under development for wireless sensor networks. There are a number of standardization bodies in the field of WSNs. The IEEE focuses on the physical and MAC layers, defining 802.15.4 standard for low rate, low power wireless sensor network; the Internet Engineering Task Force works on layers 3 and above, introducing 6lowpan for integrating networks built over IP6, alternatively ZIGBEE alliance also adopts 802.15.4, working on networking layer and application layer.
IEEE standard 802.15.4 intends to offer the fundamental lower network layers of a type of wireless personal area network (WPAN) which focuses on low-cost, low-speed ubiquitous communication between devices (in contrast with other, more end user-oriented approaches, such as Wi-Fi), lower power consumption, large scale.It addresses the lower protocol layers (physical and MAC).
ZigBee is a open specification suit for for low-power wireless mesh networking of monitoring and control devices. It works in cooperation with IEEE 802.15.4. ZigBee 2007 defines the upper layers of the protocol stack, from the Zigbee Network Layer (NWK) to the Zigbee Application Layer, including application profiles to be followed by developers whenever they build devices.Each application profile has a unique profile identifier. The purpose of a profile is to create an interoperable, distributed application layer for separate devices. Profiles are simply standard rules and regulations.
One primary weakness of ZIGBEE stack is not interoperable with IP protocol, which limits its connections to other board range of IP – enabled devices and web services. Yet, this is about to change when ZIGBEE IP standards, along with Smart Energy Profile 2.0 come into public use soon. The new standard is closely in cooperation with several standard groups, such as IETF, W3C,IPSO, adopting 6LowPan, IP6, EXI as standards.
The IETF 6LoWPAN working group target was to define how to carry IP-based communication over IEEE 802.15.4 links in a manner to conform to open standards and to provide interoperability with other IP links and devices. In this way, 6lowpan is essentially a IP based wireless sensor network,consists of an Adaptation Layer, that allows IEEE 802.15.4 frames to carry IPv6 on top of it, then work in compatibility with UDP or ICMP transport protocols, With its transparency in Internet integration and flexible features like IP6 fragmentation and mesh forwarding, different companies can easily integrate LowPAN – devices into existing IP-structures, thus eliminating the need for an array of complex gateways.
What the 2 protocols share in common is that they are both based on IEEE 802.15.4 standard, both benefit from built-in AES128 encryption. Other than this, they are different in terms of networking layer and application layers.Interoperability is one of the leading factors when choosing a wireless protocol, essentially what makes them different is IP interoperability.
Current Zigbee stack doesn’t comply with IP, but takes many concepts and replaces much of the IP layer. For example, the Zigbee NWK layer is analogous to the IP layer, the NWK routing protocol, AODV, is analogous to IP’s RIP or OSPF, and the Zigbee Application Framework is analogous to the TCP layer (without the TCP state machine and the weird sequence space thing). Zigbee has endpoints, TCP has ports. Zigbee has endpoint grouping, TCP has port binding. The price of not being interoperable with IP is that bridging between ZigBee and non-ZigBee networks requires a more complex application layer gateway.
6LoWPAN offers interoperability with other wireless 802.15.4 devices as well as with devices on any other IP network link (e.g., Ethernet or WiFi) with a simple bridge device. More than that, it enables the use of a broad body of existing standards as well as higher level protocols, software, and tools. Concerning the code size, full featured stack of ZIGBEE is 90 KB, much larger than that of 6LoWPan, which is about 30 KB.
6LoWPAN is pretty attractive, since it is IP-based—the standard Internet working protocol. Yet, with strong ventor ‘s support on various application profile, ZigBee is now shifting its focus, and start to converge to IP based – architecture including 6LowPan, IP6. In that sense, new emerging Zigbee IP standard will continue to lead.
as for me, 6LoWPAN seems to very promising, in particular because it allows you to directly address a sensor node using IPv6.
Ieee 1451.5 is the solution combines the above 2, still on the working, it could be a great solution if accepted by the industry like Ieee 1451.2 or its peers. Yet, zigbee and 6lowPan are coming to convergence of IP, is there still a need of IEEE 1451.5
Native IP support has brought billions PC, mobile phone into the web, IP4 in this week has already come to a depletion, IP6 is rushing to us, to be a best and uniform choice and opportunity, so will ultimately benefit the sensor network.
Maybe in next 2 years IP6 will be more available enough bridging the gaps between sensor network and web, more importantly sensor web, with every wireless node would become part of the Internet! zigbee standardlization so far is still a promising option in sensor network standared since its open application profiles in various domains, giving out a agreement among the vendors and developers.
hate translation, no gateway, zigbee+gateway type complex solutions seem unecessary when there is a direct IPV6 route you could take
although still waiting to see the performance of integration with zigbee and ip6, hopefully coming soon
sensor network (zigbee or 6lowpan ) + sensor makeup (sensorML) + restful service (CoAP) + sensor ontology = semantic sensor web ???
sensorML too complex? maybe with the help of exi, this problem could be eased ..