1 ZIGBEE OVER TINYOS: IMPLEMENTATION AND EXPERIMENTAL CHALLENGES André Cunha1, Ricardo Severino1, Nuno Pereira1, Anis Koubâa1,2, Mário Alves1 1 IPP-HURRAY Research Group, Polytechnic Institute of Porto (ISEP/IPP),Porto, Portugal 2 Al-Imam Muhammad Ibn Saud University, Computer Science Dept., Riyadh, Saudi Arabia {arec, rars, nap, aska, mjf}@isep.ipp.pt Abstract: The IEEE 802.15.4/Zigbee protocols are a promising technology for Wireless Sensor Networks (WSNs). This paper shares our experience on the implementation and use of these protocols and related technologies in WSNs. We present problems and challenges we have been facing in implementing an IEEE 802.15.4/ZigBee stack for TinyOS in a two-folded perspective: IEEE 802.15.4/ZigBee protocol standards limitations (ambiguities and open issues) and technological limitations (hardware and software). Concerning the former, we address challenges for building scalable and synchronized multi-cluster ZigBee networks, providing a trade-off between timeliness and energy-efficiency. On the latter issue, we highlight implementation problems in terms of hardware, timer handling and operating system limitations. We also report on our experience from experimental test-beds, namely on physical layer aspects such as coexistence problems between IEEE 802.15.4 and 802.11 radio channels. Keywords: Wireless Sensor Networks, ZigBee, IEEE 802.15.4, TinyOS 1. INTRODUTION Tree topology. The major problems related to the open-ZB protocol stack implementation are IEEE 802.15.4/ZigBee [1,2] and TinyOS [3] are presented in Section 3. Section 4 reports some currently buzzwords, since these technologies have experience from experimental test-beds. Finally, been playing and important role in leveraging a new Section 5 provides some concluding remarks. generation of large-scale networked embedded systems. The IEEE 802.15.4/ZigBee protocol stack 2. ON THE IEEE 802.15.4/ZIGBEE PROTOCOLS has several interesting technical features for serving as a federating communication technology for 2.1 Protocols Overview Wireless Sensor Networks (WSN). TinyOS is the The IEEE 802.15.4 protocol [1] specifies the most widespread operating system for embedded Medium Access Control (MAC) sub-layer and the resource-constrained systems. Physical Layer of Low-Rate Wireless Private Area Within this context, we have been investigating the Networks (LR-WPANs). The ZigBee protocol [2] potentiality of the IEEE 802.15.4/ZigBee protocols relies on the IEEE 802.15.4 layers, building up the for time-critical WSN applications. We have Network and Application Layers. developed the open-ZB [4] open source toolset, ZigBee defines three types of devices: (1) ZigBee encompassing a simulation model [5] and a protocol Coordinator (ZC): one for each PAN, initiates and stack over TinyOS [11], for the MICAz/TelosB [6] configures the network formation; (2) ZigBee Router motes. This toolset has been mainly used to test, (ZR): associated (as a child node) with the ZC or validate and demonstrate our theoretical proposals with a previously associated ZR, participates in through a number of experimental test-beds. multi-hop message routing; (3) ZigBee End Device This paper describes the most important problems (ZED): device with sensing/actuating capabilities but encountered in the implementation of the IEEE that does not allow other devices to associate with it 802.15.4/ZigBee protocol stack over TinyOS and and does not participate in routing. also in our experimental test-beds, identifying some The IEEE 802.15.4 Physical Layer is responsible for of the most relevant challenges to be addressed. data transmission and reception using a certain radio The remainder of the paper is organized as follows: channel. It offers three operational frequency bands: Section 2 overviews relevant aspects of the IEEE 2.4 GHz, 915 MHz and 868 MHz. There is one 802.15.4/ZigBee protocols, focusing on the Cluster- channel between 868 and 868.6 MHz, ten channels 1 This work was partially funded by FCT under the CISTER Research Unit (FCT UI 608), PLURALITY and CMU-PT projects, and by the ARTIST2/ARTISTDesign NoEs. between 902 and 928 MHz, and sixteen channels topology (Fig. 2b) each node can directly between 2.4 and 2.4835 GHz. Direct Sequence communicate with any other node within its radio Spread Spectrum (DSSS) modulation is used. range or through multi-hop. The cluster-tree The IEEE 802.15.4 MAC protocol supports two topology (Fig. 3) is a special case of a mesh network operational modes that may be selected by the ZC: where there is a single routing path between any pair (1) the non beacon-enabled mode, in which the of nodes and a distributed synchronization MAC is simply ruled by non-slotted CSMA/CA; (2) mechanism (operates in beacon-enabled mode). the beacon-enabled mode, ruled by slotted 2.2 Cluster-tree network model CSMA/CA, in which beacons are periodically sent by the ZC to synchronize nodes that are associated with The Cluster-Tree network concept is outlined in the it, and to identify the PAN. In beacon-enabled mode, ZigBee specification and exemplified in Fig. 3. A the ZC defines a Superframe structure (Fig. 1) which unique ZC identifies the entire network and each ZR is constructed based on: (1) the Beacon Interval (BI), assumes the role of cluster-head, allowing the which defines the time between two consecutive association of other ZRs and ZEDs in a parent-child beacon frames; (2) the Superframe Duration (SD), relationship. Inside each cluster, messages must be which defines the active portion in the BI, and is relayed by the cluster-head, i.e. as in star topologies. divided into 16 equally-sized time slots, during However, the IEEE 802.15.4/ZigBee specifications which frame transmissions are allowed. Optionally, do no clearly describe how the cluster-tree model can an inactive period is defined if BI > SD. During the be implemented, providing just a broad view on how inactive period (if it exists), all nodes may enter in a the cluster-tree network should operate and on the sleep mode (to save energy). tree routing algorithm. BI and SD are determined by two parameters - the Beacon Order (BO) and the Superframe Order (SO): BO BI=⋅ aBaseSuperframeDuration 2 ⎪⎫ ⎬for 014≤≤ SO BO ≤ SO SD=⋅ aBaseSuperframeDuration 2 ⎭⎪ aBaseSuperframeDuration = 15.36 ms (assuming 250 kbps in the 2.4 GHz band) denotes the minimum Fig. 3 Cluster-tree network topology Superframe Duration, corresponding to SO = 0. During the SD, nodes compete for medium access More specifically, the Cluster-Tree model includes using slotted CSMA/CA, in the Contention Access more than one ZigBee Router that periodically Period (CAP). IEEE 802.15.4 also supports a generates beacons to synchronize nodes (or clusters Contention-Free Period (CFP) within the SD, by the of nodes) in their neighbourhood. If these periodic allocation of Guaranteed Time Slots (GTS). beacon frames are sent in an unorganized fashion, without any particular schedule, they will collide with each other or with other frames. These collisions result in the loss of synchronization between a parent ZigBee Router and their child devices, which prevents them to communicate. Only some basic approaches dealing with this problem were proposed for discussion by the Task Group 15.4b [7], which is a group aiming to improve some inconsistencies of the original specification. Fig. 1 Superframe structure [1] Therefore, beacon scheduling mechanisms such as the one proposed in [10] are required to avoid beacon It can be easily observed in Fig. 1 that low duty- frame collisions in ZigBee cluster-tree networks. cycles can be configured by setting small SO values as compared to BO, resulting in greater sleep 2.3 Cluster-tree vs mesh topologies (inactive) periods. Table 1 summarizes some of the differences between ZigBee supports three network topologies – star, ZigBee mesh and cluster-tree topologies. mesh and cluster-tree, illustrated in Figs. 2 and 3. Table 1 – Mesh vs. Cluster-Tree Mesh Cluster-Tree Synchronization No Yes Inactive Periods ZEDs All Nodes Real-Time No Yes (GTS) Communications a) star topology b) mesh topology Redundant Paths Yes No Routing Protocol Yes No Fig 2. ZigBee star and mesh network topologies Overhead Commercially Yes No In the star topology (Fig. 2a) communications must Available always be relayed through the ZC. In the mesh The synchronization (beacon-enabled mode) feature solutions based on the ZigBee cluster-tree model. of the cluster-tree model may be seen both as an Nevertheless, we consider this model as a promising advantage and as a disadvantage, as reasoned next. and adequate solution for WSN applications with On one hand, synchronization enables dynamic duty- real-time and energy-efficiency requirements. cycle management in a per cluster basis, allowing 3. OPEN-ZB STACK: PROBLEMS/CHALLENGES nodes (ZEDs and ZRs) to save their energy by entering the sleep mode. In contrast, in the mesh 3.1 Introduction topology (as in [1]), only the ZEDs can have inactive The main problems we have encountered during the periods; note that as the mesh network model implementation of the IEEE 802.15.4/ZigBee supports no synchronization, ZRs are forced to be protocol stack [4,11] are related to both hardware always active for complying with their routing constraints and the lack of details in the standard duties. These energy saving periods enable the specifications regarding important aspects of the extension of the network lifetime, which is one of the beacon-enabled mode and of the cluster-tree model. most important requirements of WSNs. In addition, We have implemented the beacon-enabled mode of synchronization allows the dynamic reservation of the IEEE 802.15.4 MAC sub-layer and the required guaranteed bandwidth in a per-cluster basis, through functionalities in the ZigBee Network Layer to the allocation of GTS in the CFP.