Design and implementation of ZigBee/IEEE Nodes for

Transcription

1 Design and implementation of ZigBee/IEEE Nodes for Wireless Sensor Networks Jin-Shyan Lee and Yang-Chih Huang Information and Communications Research Laboratory, Industrial Technology Research Institute (ITRI), Taiwan R ecently, the rapid advance of information technology and micro-electromechanical systems (MEMS) has enabled the development of small devices with embedded sensing, computing, and communication capabilities. A wireless sensor network (WSN) is composed of hundreds or even thousands of such sensor nodes which use wireless links to perform distributed sensing tasks. Sensors come in many types to monitor a wide variety of conditions, such as temperature, humidity, smoke, and light. The variety in types of sensors has received intensive research attention due to its enormous application potential in environmental monitoring, military surveillance, biomedical supervision, and other fields 1. Since the location of the sensor nodes may not be known in advance, there is a demand for the network to coordinate in a distributed manner, similar to the self-organising capabilities of a mobile ad hoc network (MANET). However, several differences exist between WSN and MANET as described in the following. The number of sensor nodes deployed in a WSN is expected to be several orders of magnitude higher than the number of nodes in a typical MANET. Sensor nodes may be more densely deployed, and they are also limited in power, computation and memory capacity. Sensor nodes are prone to failure, destruction, and energy depletion, and hence the topology of the WSN changes frequently for these reasons rather than from node mobility. Sensor nodes may not have global identifiers due to the amount of overhead assigning such identifiers for a large numbers of sensors. The WSN tends to operate as a collective structure, addressed by attribute, instead of supporting many independent point-to-point flows. Thus, traffic tends to be variable and highly correlated. Hence, protocols designed for MANETs are not directly usable in WSN due to these differences and several approaches have been proposed specifically for such WSN applications. Moreover, these applications require low power consumption, low complexity in wireless links, and low cost (relative to the device cost). So far, IEEE standard is the one that addresses these types of requirements. In order to fully understand the WSNs from a practical perspective, it is necessary to implement and test on realworld systems. However, most previous work has focused on the mathematical analysis and theoretical algorithms with extensive simulation results. In this paper, a ZigBee over IEEE platform, named ITRI ZBnode, has been designed and implemented for WSN utilization and verification. Moreover, we will show the examples of ZigBee-based network construction. Thus, our focus will be very much on the functional side of multi-hop topology formation and not so much on the algorithmic study. ZigBee/IEEE protocol stack The ZigBee stack architecture 4 is made up of a set of blocks called layers. Each layer performs a specific set of services for the layer above, including a data entity that provides a data transmission service and a management entity provides all other services. Each service entity exposes an interface to the upper layer through a service access point (SAP), and each SAP supports a number of service primitives to achieve the required functionality. The ZigBee stack architecture, as shown in Figure 1, is based on the standard open systems interconnection (OSI) seven-layer model but defines only those layers relevant to achieving functionality in the intended market space. The IEEE defines specifications of the physical layer (PHY) and medium access control sublayer (MAC) for supporting simple devices that consume minimal power and typically operate in a personal operating space (POS). The ZigBee Alliance builds on this foundation by providing the network (NWK) layer and the framework for the 204 Vol 39/7 September 2006

2 application layer, which includes the application support (APS) sub-layer, the ZigBee device object (ZDO) and the manufacturer-defined application objects. Figure 1: The ZigBee/IEEE stack architecture. Wireless links under can operate in three licencefree industrial scientific medical (ISM) frequency bands. These accommodate over air data rates of 250 kbps in the 2.4 GHz band, 40 kbps in the 915 MHz band, and 20 kbps in the 868 MHz band. A total of 27 channels are allocated in , including 16 channels in the 2.4 GHz band, 10 channels in the 915 MHz band, and 1 channel in the 868 MHz band. The IEEE MAC sub-layer controls access to the radio channel using a CSMA-CA mechanism. Its responsibilities also include transmitting beacon frames, synchronisation and providing a reliable transmission mechanism. The responsibilities of the ZigBee NWK layer include mechanisms used to join and leave a network, to apply security to frames, and to route frames to their intended destinations. The discovery and maintenance of routes between devices are devolved on the NWK layer. Also, the discovery of one-hop neighbours and the storing of pertinent neighbour information are done at the NWK layer. In addition, the NWK layer of a ZigBee coordinator is responsible for starting a new network, when appropriate, and assigning addresses to newly associated devices. The ZigBee application layer consists of the APS sublayer, the ZDO and the manufacturer-defined application objects. The APS sub-layer is responsible for maintaining tables for binding, which is the ability to match two devices together based on their services and their needs, and forwarding messages between bound devices. The responsibilities of the ZDO include defining the role of the device within the network (e.g. ZigBee coordinator or end device), initiating and responding to binding requests and establishing a secure relationship between network devices. Another responsibility of the ZDO is discovery, which is the ability to determine which other devices are operating in the POS and the devices associated. The manufacturer-defined application objects adhere to profiles defined within the ZigBee Alliance. They implement the actual applications according to the ZigBee-defined application descriptions. The device profile is a series of messages which permit ZigBee devices to perform the functions forming the core capabilities of discovery, binding, and network management for ZigBee devices. Two different device types can participate in a ZigBee network: a full-function device (FFD) and a reduced-function device (RFD). An FFD can talk to RFDs or other FFDs, while an RFD can talk only to an FFD. An RFD is intended for applications that are extremely simple, such as a light switch or a smoke sensor. These do not need to send large amounts of data and would only associate with a single FFD at a time. Consequently, the RFD can be implemented using minimal resources and memory capacity. The FFD can operate in three modes, serving as a ZigBee coordinator, a router, or an end device. A ZigBee coordinator is the PAN coordinator defined in IEEE which is responsible for network formation and maintenance. A ZigBee router is an FFD participating in a ZigBee network. It is not the ZigBee coordinator but may act as an IEEE coordinator with the abilities of supporting associations and routing messages between devices. ZigBee end device, which is neither the ZigBee coordinator nor a ZigBee router, is an RFD or FFD participating in a ZigBee network. Two types of topologies are supported in : the star and peer-to-peer topology. The basic structure of a star network can be seen in Figure 2(a). After an FFD is activated for the first time, it may establish its own network and become the PAN coordinator. All star networks operate independently from all other star networks currently in operation. This is achieved by choosing a PAN identifier, which is not currently used by any other network within the radio sphere of influence. Once the PAN identifier is chosen, the PAN coordinator can allow other devices (FFDs and RFDs) to join its network. On the other hand, in a peer-to-peer topology, each device is capable of communicating with any other device within its radio sphere of influence. One device will be nominated as the PAN coordinator, for instance, by virtue of being the first device to communicate on the channel. Further network structures can be constructed out of the peer-to-peer topology, such as the cluster-tree network and mesh network, as shown in Figure 2 (b) and (c) respectively. A cluster-tree network is a special case of a peer-topeer network in which most devices are FFDs. An RFD may connect to a cluster tree network as a leave node at the end of a branch, because it may only associate with one FFD at a time. Any of the FFDs may act as a coordinator Figure 2: (a) Star; (b) cluster tree; and (c) mesh topologies in a ZigBee network. Vol 39/7 September

3 and provide synchronisation services to other devices or other coordinators. Only one of these coordinators can be the overall PAN coordinator, which may have greater computational resources than any other device in the PAN. In a mesh network, the routing of messages is performed as a decentralised, cooperative process involving many peer devices routing on each other s behalf. ITRI ZBnode: A Zigbee-ready platform The ZBnode is an autonomous, lightweight wireless communication and computing platform based on an IEEE radio module and a microprocessor. The first version of ZBnode was released as ITRI performed a project for developing a small device with sensing, computing, and networking (SCAN) capabilities. For general-purpose applications in the development stage, the first version adopted a powerful 32-bit microprocessor. Hence, it was also named SCAN-ZB32. The ZB32 device has no integrated sensors, since individual sensor configurations are required depending on the application. Instead, through predetermined sockets, ZB32 can be used with various serial devices, such as sensors, RFID readers, actuators, power chargers, and user interface components. As shown in Figure 3, the ZBnode hardware is built around a 32-bit RISC microprocessor which features an ARM 720T CPU core running up to 70 MHz. There are several integrated peripherals: JTAG for debugging, timers, counters, 10-bit AD converter, four UARTs, USB, infrared communications, pulse-width modulation (PWM), LCD controllers, and controller area network (CAN) interfaces. The external memory consists of 16 MB of in-system programmable Flash ROM and 16 MB of SDRAM. Four buttons and five LEDs are provided to implement a visual user application interface. Chipcon CC2420, an IEEE compliant RF transceiver, is connected to one of the serial peripheral interfaces of the microprocessor, and to an on-board 2.4 GHz chip antenna. Also, for better performance, the RF module can be switched to an external antenna via a standard SMA (sub-miniature type A) connector. The ZBnode is typically powered from a Li-ion battery with a DC input range from 3.5 to 5.5 V. Figure 4 shows the sensing module, on which several sensors are supplied for detecting environment conditions including temperature, humidity, and light. Also, a prototype area is provided for other extended sensing functions and a sounder could be used as the alarm notification. For general-purpose development, the ZBnode platform applied ARM Linux kernel 2.4 and the system software is a Figure 3: ITRI ZBnode hardware (SCAN-ZB32). 206 Vol 39/7 September 2006

4 Figure 4: Sensing module for ITRI SCAN-ZB32. Linux-based framework written in ANSI C using an open ARM-Linux compiler suite. In a protocol stack, the services of a layer are the capabilities it offers to the user in the next higher layer by building its functions on the services of the next lower layer. In this paper, the ZBnode platform has implemented the ZigBee over IEEE stack upon this reference model. The protocol stack is embedded into the driver with convenient APIs available for application developers. Within this framework, applications are typically partitioned into: 1) a ZigBee protocol layer that is communicating with the IEEE front-end through commands and events, keeping track of point-to-point connections with individual state machines; 2) a command line terminal for control and debugging; and 3) a user-defined application object. The whole application is defined at compile time and then programmed into the flash memory of the ZBnode using either an in-system programmer through the JTAG interface or an X modem terminal via the RS-232 port if Linux kernel is loaded in advance. ZigBee-based network formation In addition to managing network joining and address assignment, the network formation process also provides a tree routing algorithm without a routing table required. The Cskip address allocation algorithm provides address ranges that allows any device to quickly identify whether a particular network address belongs to a descendant of that device, or elsewhere in the device tree. As a result, any device could make simple routing decisions based on passing a packet up or down the device tree. The most significant benefit with tree routing is its simplicity and its limited use of resources. By having a simple algorithm to determine whether an address is a child or a descendant of a child, or elsewhere on the tree, any router can make a routing decision simply by looking at the destination address. In these cases, a router simply decides to route a packet to one of its children or to its parent. As a result, precious memory resources need not be used to store routing information. Hence, very low cost devices can be deployed Figure 5: Network formation of a 20-node tree topology. Vol 39/7 September

5 Table 1: Comparison with other commercial platforms. without a routing table, but can still participate in any ZigBee compliant network. Based on the ITRI ZBnode platform, a 20-node tree network topology (including a 4-node backbone and 16 mobile nodes) has been successfully constructed at the annual project review in August 2005, as shown in Figure 5. In a ZigBee network, it is common for a device to lose its association and re-associate with another device in the tree. For the re-associated devices, the previous location in the tree is shown in grey. There is a grey arrow linking the old location to the new location in the tree with an arrow head indicating the old and new location. A chain of linked re-associated nodes is used to display multiple re-associations of the same device. Figure 5 also displays the 16 mobile nodes moved along the backbone. A possible application may be the location tracking of multiple mobile devices. Conclusions After a brief overview of the emerging ZigBee/IEEE wireless technology, this paper has presented the implementation of a ZigBee-ready platform: ITRI ZBnode for WSN applications. Also, network formation of a tree topology has been demonstrated via practical experiments. So far, several IEEE platforms have been available on the market. Table 1 compares ITRI SCAN-ZB32 with other commercial platforms. With a more powerful 32-bit processor and Linux kernel, ZB32 is very suitable for practical implementation and verification of complex algorithms and theory. However, the power consumption would be an issue in applications to mobile devices without alternating current mains. Currently, the platform is undergoing a major hardware and software revision. A much smaller 8-bit ZBnode platform, named SCAN-ZB8, has been developed using a single chip (integrating an IEEE RF, an 8051 microprocessor, and a temperature sensor) with much lower power consumption. ITRI ZBnode Crossbow Dust Networks SCAN-ZB32 Mote 2400-Mica Z Mote 2020 Hardware Microprocessor 32-bit Hynix ARM7 8-bit Atmel AVR 16-bit TI MSP430 RF Transceiver CC2420 CC2420 CC2420 Flash Memory 16MB 128 KB 60KB RAM N/A 4KB 2KB EEPROM N/A 4KB N/A Programming Interfaces RS-232, JTAG RS-232 N/A Node Size (mm) 76 x 68x x 32 x x 75 x 28 Supported Sensors (via Temperature, Light, Humidity Temperature, Light, Temperature, an expansion connector) Acceleration, Light, Tilt Acoustic, Magnetic Software/Stack OS ARM Linux 2.4 Tiny OS N/A Compatible Yes Partial Partial ZigBee Compliant Yes Partial No ZigBee Interoperability Yes No No Mesh Networking ZigBee Mesh XMesh TM SmartMesh TM Acknowledgement This work was supported by the Ministry of Economic Affairs under the Embedded System Software Laboratory in Domestic Communication and Optoelectronics Infrastructure Construction Project. The authors would like to thank all the long-term contributors in the SCAN project, with special thanks to department manager Chin- Sung Chen, hardware team leader Ching-Chin Huang, and software team leader Chung-Chou Shen. References 1. Xue, G. and Hassanein, H., Editorial: On current areas of interest in wireless sensor networks designs, Computer Communications, 29, 4, , IEEE , Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (LR-WPANs), New York, USA, Lee, J.S., An experiment on performance study of IEEE wireless networks, Proc. IEEE Int. Conf. Emerging Technologies & Factory Automation, 2, , Catania, Italy, September 19-22, ZigBee Alliance, ZigBee Specification Version 1.0, San Ramon, CA, USA, Vol 39/7 September 2006