Open-ZB: an open-source implementation of

the IEEE 802.15.4/ZigBee protocol stack on TinyOS

André Cunha1, Anis Koubâa1,2, Ricardo Severino1, Mário Alves1

1
IPP-HURRAY! Research Group, Polytechnic Institute of Porto, School of Engineering (ISEP/IPP), Porto, Portugal
2
Al-Imam Muhammad Ibn Saud University, Computer Science Dept., 11681 Riyadh, Saudi Arabia
[email protected], [email protected], [email protected], [email protected]

Abstract conjunction with the IEEE Task Group 15.4 in order to

The IEEE 802.15.4/ZigBee protocols are gaining specify a full protocol stack for low cost, low power,
increasing interests in both research and industrial low data rate wireless communications, as well as to
communities as candidate technologies for Wireless foster its worldwide use. The ZigBee specification,
Sensor Network (WSN) applications. In this paper, we with a new release in December 2006, aims at the
present an open-source implementation of the IEEE provision of a standard protocol that facilitates the
802.15.4/ZigBee protocol stack under the TinyOS interoperability between multiple hardware and
operating system for the MICAz and TelosB motes. software platforms from different providers. Fig. 1
This work has been driven by the need for an open- shows the layered architecture of the IEEE
source implementation of the IEEE 802.15.4/ZigBee 802.15.4/ZigBee protocol stack.
protocols, filling a gap between some newly released
complex C implementations and black-box
implementations from different manufacturers. In
addition, we share our experience on the challenging
problems that we have faced during the
implementation of the protocol stack. We strongly
believe that this open-source implementation will
potentiate research works on the IEEE
802.15.4/ZigBee protocols, allowing their
demonstration and validation through
experimentation. Fig. 1. The IEEE 802.15.4/ZigBee protocol stack
architecture
1. Introduction The IEEE 802.15.4/ZigBee protocols have attracted
several recent research works (e.g. [4-9]). Most of
The IEEE 802.15.4 protocol specifies the Medium those research studies have typically focused on the
Access Control (MAC) sub-layer and the Physical evaluation/improvement of some characteristics of the
Layer of Low-Rate Wireless Private Area Networks standard protocols either analytically or by simulation.
(LR-WPANs) [1]. Although this standard protocol was No experimental work has argued any of those
not specifically developed for Wireless Sensor research results due to the lack of a real open-source
Networks (WSNs), it provides enough flexibility for implementation of the IEEE 802.15.4/ZigBee protocol
fitting different requirements of WSN applications by stack. This lack prevents from experimentally
adequately tuning its parameters. In fact, low-rate, demonstrating the feasibility of the proposed
low-power consumption and low-cost wireless approaches and from the accurate validation of these
networking are key features of the IEEE 802.15.4 theoretical results, since simulation tools are usually
protocol, which typically fit the requirements of WSNs not sufficient to evaluate the real behaviour of the
[2]. Moreover, the ZigBee specification [3] relies on protocols due to many abstractions in the simulation
the IEEE 802.15.4 Physical and Data Link Layers, models.
building up the Network and Application Layers, thus Therefore, there is a tremendous motivation for
defining a full protocol stack for LR-WPANs. developing an open-source implementation of IEEE
The ZigBee Alliance - an organization with more 802.15.4/ZigBee for different sensor network
than 150 company members - has been working in platforms to (1) foster the development of research
works focusing on the IEEE 802.15.4/ZigBee protocol 2. IEEE 802.15.4/ZigBee Overview
stack, (2) provide a means to validate, demonstrate and
evaluate the real deployment of IEEE 802.15.4/ZigBee 2.1. IEEE 802.15.4 Physical and Data Link
networks. Layers
In this paper, we propose Open-ZB [10], an open-
source implementation of the IEEE 802.15.4/ZigBee The IEEE 802.15.4 specification defines two
protocol stack under the TinyOS operating system. different types of devices: the Full Function Devices
Currently, the implementation supports the MICAz (FFDs) that implement the full protocol stack and the
[11] and TelosB motes [11]. In addition, for the sake of Reduced Function Devices (RFDs) that only
a comparative evaluation between simulation and implement a subset of the protocol stack. The FFDs
experimentation of the IEEE 802.15.4/ZigBee protocol can have three different roles in the network: (1) the
stack, we have also developed a simulation model Personal Area Network (PAN) Coordinator: the
[12,13] using the OPNET tool [14]. This simulation principal controller of the PAN, identifying the
model implements the Physical and the Data Link network and its configurations; (2) the Coordinator:
Layers of the IEEE 802.15.4 protocol standard, provides synchronization services through the
supporting the physical layer characteristics, the transmission of beacons; this device must be associated
beacon-enabled mode, the Slotted CSMA/CA, the to a PAN Coordinator and does not create its own
protocol frame formats and a battery module that network; (3) the End-Devices: do not implement the
computes the consumed and remaining energy levels. previous functionalities and must associate with a
The Open-ZB implementation was developed in the Coordinator before interacting with the network.
context of the ART-WiSe research framework [15], The RFD is an End-Device operating with the
which consists in providing real-time and reliable minimal implementation of the IEEE 802.15.4
communications for WSNs using COTS (Commercial- protocol. A RFD is intended for supporting simple
Off-The-Shelf) technologies. We expect that the line of tasks, such as a light switch or a passive infra-red
work we have been following in the assessment, sensor; they do not have the need to send large
improvement and engineering of IEEE amounts of data and can only associate with a single
802.15.4/ZigBee networks will have significant FFD at a time.
repercussions. IEEE 802.15.4 and ZigBee are The IEEE 802.15.4 Physical Layer is responsible
emerging technologies with plenty of potentialities for for data transmission and reception using a certain
WSN applications. Nevertheless, for these radio channel and according to a specific modulation
technologies to gain widespread use we believe it is and spreading technique. It offers three operational
important to provide open-source implementations of frequency bands: 2.4 GHz, 915 MHz and 868 MHz.
these protocols, to act as common platforms for the There is 1 channel between 868 and 868.6 MHz, 10
scientific community to discuss, interact and channels between 902 and 928 MHz, and 16 channels
contribute. Moreover, it is important for the scientific between 2.4 and 2.4835 GHz. Lower frequencies are
community to collaborate with the official working more suitable for longer transmission ranges due to
groups from the IEEE and with the ZigBee Alliance in lower propagation losses. Low rate transmissions
a way that our findings can contribute for improving provide better sensitivity and larger coverage area.
the current protocol standards. Higher rate means higher throughput, lower latency or
The main contribution of this paper is the provision lower duty cycles. All these frequency bands are based
of a comprehensive description of our IEEE on the Direct Sequence Spread Spectrum (DSSS)
802.15.4/ZigBee implementation and demonstrating its spreading technique.
importance in fostering the development of research The Physical Layer also allows dynamic channel
work based on these standard protocols. selection, a channel scan, receiver energy detection,
The rest of the paper is organized as follows: link quality indication and channel switching.
Section 2 highlights some relevant aspects of the IEEE The IEEE 802.15.4 protocol supports two
802.15.4/ZigBee protocols. Some implementation operational modes that may be selected by the PAN
details are presented in Section 3, namely general Coordinator: (1) the non beacon-enabled mode, in
aspects of our development environment, a short which the Medium Access Control (MAC) is simply
overview of TinyOS [16] and nesC [17] programming ruled by Unslotted CSMA/CA, (2) the beacon-enabled
language, the implementation structure and future mode, in which beacons are periodically sent by the
challenges. In Section 4 we outline some research Coordinators to synchronize nodes that are associated
achievements based on our implementation. Finally, in with them, and to identify the PAN.
Section 5, we draw some concluding remarks.
 In beacon-enabled mode, the PAN Coordinator from the device to the Coordinator (transmit) or from
defines a Superframe Structure (Fig. 2), which is the Coordinator to the device (receive).
constructed based on (1) the Beacon Interval (BI), The GTS can be deallocated at any time at the
defining the time between two consecutive beacon discretion of the Coordinator or the device that
frames, (2) the Superframe Duration (SD), defining the originally requested the GTS. A device to which a
active portion of the BI, being divided into 16 equally- GTS has been allocated can also transmit during the
sized time slots, during which frame transmissions are CAP. The Coordinator is responsible for performing
allowed. Optionally, an inactive period can be defined, the GTS management; for each GTS, it stores the
if BI > SD. During the inactive period (if it exists), all starting slot, length, direction, and associated device
nodes may enter in a sleep mode (to save energy). BI address. All these parameters are embedded in the GTS
and SD are determined by two parameters, the Beacon request command. Only one transmit and/or one
Order (BO) and the Superframe Order (SO), receive GTS are allowed for each Superframe.
respectively, as follows:
BI = aBaseSuperframeDuration ⋅ 2
BO ⎫⎪
SO
⎬ for 0 ≤ SO ≤ BO ≤ 14 (1)
SD = aBaseSuperframeDuration ⋅ 2 ⎪⎭
where aBaseSuperframeDuration = 15.36 ms
(assuming 250 kbps in the 2.4 GHz frequency band)
denotes the minimum duration of the Superframe,
corresponding to SO = 0.
During the Superframe duration, nodes compete for
medium access using Slotted CSMA/CA, during the
Contention-Access Period (CAP).

a) Slotted CSMA/CA

Fig. 2. IEEE 802.15.4 Superframe Structure

As depicted in Fig. 2, low duty cycles can be b) Unslotted CSMA/CA
configured by setting small values of SO as compared
to BO, resulting in greater inactive periods. Fig. 3. The CSMA/CA mechanism
Additionally, the IEEE 802.15.4 protocol also provides IEEE 802.15.4 supports two contention-access
real-time guarantees by using the Guaranteed-Time MAC mechanisms (Fig. 3) based on Carrier Sense
Slot (GTS) mechanism. This feature is quite attractive Multiple Access with Collision Avoidance
for time-sensitive WSN applications. In fact, in (CSMA/CA): Slotted CSMA/CA (Fig. 3a) in the
beacon-enabled mode, the IEEE 802.15.4 protocol beacon-enabled mode and Unslotted CSMA/CA (Fig.
allows the allocation/deallocation of GTSs in a 3b) in the non-beacon-enabled mode. The CSMA/CA
Superframe for nodes that require real-time guarantees. mechanism is based on backoff periods (with the
The GTS mechanism allows a device to access the duration of 20 symbols). Three variables are used to
medium without contention, during the Contention- schedule the access to the medium: (1) Number of
Free Period (CFP). The GTS is allocated by the Backoffs (NB), representing the number of failed
Coordinator and is used only for communications attempts to access the medium; (2) Contention
between the Coordinator and a device. A single GTS Window (CW), representing the number of backoff
may extend over one or more time slots. The needed to be clear before starting transmission; (3)
Coordinator may allocate up to seven GTSs at the Backoff Exponent (BE), enabling the computation of
same time, provided that there is sufficient capacity in the number of wait backoffs before attempting to
the Superframe. Each GTS has only one direction: access the medium again.
 The Slotted CSMA/CA algorithm (Fig. 3a) can be networking flexibility, but it induces an additional
summarized in five steps: (1) initialization of the complexity for providing end-to-end connectivity
algorithm variables: NB equal to 0; CW equals to 2 and between all nodes in the network. Basically, the mesh
BE is set to the minimum value between 2 and a MAC topology operates in an ad-hoc fashion and allows
sub-layer constant definition (macMinBE); (2) after multiple hop routing from any node to any other node.
locating a backoff boundary, the algorithm waits for a The mesh topology may be more power-efficient than
random defined number of backoff before attempting the star topology since communications do not rely on
to access the medium; (3) Clear Channel Assessment one particular node.
(CCA) to verify if the medium is idle or not. (4) The
CCA returned a busy channel, the NB is incremented
by 1 and the algorithm must start again in Step 2; (5)
The CCA returned an idle channel, the CW is
decremented by 1 and if it reaches 0 then the message
is transmitted otherwise the algorithm jumps to Step 3.
The unslotted mode of the CSMA/CA is very a) star topology b) mesh topology
similar to the slotted version except the algorithm does
not need to rerun (CW number of times) when the
channel is idle.

2.2. The ZigBee Network Layer

In ZigBee networks there are 3 types of devices: (1)

ZigBee Coordinator (ZC): FFD, one for each ZigBee c) cluster-tree topology
Network, initiates and configures the network Fig. 4. IEEE 802.15.4 network topologies
formation, acts as an IEEE 802.15.4 PAN Coordinator
and also as a ZigBee Router (ZR) once the network is The cluster-tree topology (Fig. 4c) is a special case
formed; (2) ZigBee Router (ZR): FFD, associated with of a mesh network where there is a single routing path
the ZC or with a previously associated ZR, acts a an between any pair of nodes and there is a distributed
IEEE 802.15.4 Coordinator, participates in multi-hop synchronization mechanism (beacon-enabled mode).
routing of messages; (3) ZigBee End-device (ZED): There is only one ZC which identifies the entire
does not allow other devices to associate with it, does network and one ZR (Coordinator per cluster. Any
not participate in routing and may implement a FFD can act as a ZR and provide synchronization
reduced subset of the protocol stack (RFD). services to other devices and ZRs.
Throughout this document the names and acronyms 3. Open-ZB Protocol Stack
of the devices are used interchangeably.
IEEE 802.15.4/ZigBee enable three network
3.1. Mote Platforms
topologies – star, mesh and cluster-tree. In all cases, a
unique node operates as a ZC. The ZC chooses a PAN The Open-ZB [10] implementation was developed
identifier, which must not be used by any other ZigBee under the TinyOS operating system version 1.1.15.
network in the vicinity. In the star topology (Fig.4a), The first version was developed for the MICAz
the communication paradigm is centralized, i.e. each [11] mote platform. The current version also supports
device (FFD or RFD) joining the network and willing the TelosB [11] mote platform. The TelosB
to communicate with other devices must send the data architecture is slightly different from the one of the
to the ZC, which dispatches it to the adequate MICAz, especially due to the 16-bits MSP430
destination. The star topology may not be adequate for microcontroller [18] as compared to the MICAz 8-bits
WSN for two reasons. First, the sensor node selected Atmega128 microcontroller [19]. This triggers the
as a PAN Coordinator will get its battery resources need for a selection of the hardware files (or drivers)
rapidly ruined. Second, the coverage of an IEEE already provided in TinyOS and to an adaptation of the
802.15.4 cluster is very limited leading to a scalability previous version of the implementation to support the
problem. 16-bits memory block of the MSP430. Both platforms
In the mesh topology (Fig. 4b) the communication use the same 2.4 GHz Chipcon CC2420 radio
paradigm is decentralized - each node can directly transceiver [20].
communicate with any other node within its radio The MICAz mote needs an interface to program it
range. The mesh topology enables enhanced (the MIB510), while the TelosB mote features an USB
interface. Both motes provide a debug mechanism by preemption until completion and their execution is
sending data through the serial (COM/USB) port and postponed until they can execute. Hardware events are
reading it in a communication listener (e.g. ListenRaw, asynchronous events that are executed in response to a
provided with the TinyOS distribution, or Windows hardware interrupt and also run to completion.
HyperTerminal). This debugging mechanism raises a
problem concerning the hardware operation because 3.3. Software architecture
the relaying of data through the COM port blocks all
the other mote operations, while this data is being sent. The Open-ZB protocol stack implementation has
This usually causes synchronization problems. three main blocks: (1) the hardware abstraction layer,
In order to overcome the COM debugging including the IEEE 802.15.4 physical layer and the
problems, we have used network/protocol analysers to timer module supporting both MICAz and TelosB
track and display the packets being transmitted, which mote platforms; (2) the IEEE 802.15.4 MAC sub-
provide a better debugging mechanism by transmitting layer; and (3) the ZigBee Network Layer.
debugging data in the packet payloads. The functionalities supported by the IEEE 802.15.4
We have used an IEEE 802.15.4/ZigBee packet implementation include the slotted version of the
sniffer provided by Chipcon - the CC2420 Packet CSMA/CA algorithm, allowing the testing and
Sniffer for IEEE 802.15.4 v1.0 [21] that provides a parameterization of its variables, the different types of
raw list of the packets transmitted. This application transmission scenarios (e.g. direct, indirect and GTS
works in conjunction with a CC2400EB evaluation transmissions), association of the devices, channel
board and a CC2420 radio transceiver. We have also scans (e.g. energy detection and passive scan) and
used the Daintree IEEE 802.15.4/ZigBee beacon management. Other IEEE 802.15.4 features
Network/Protocol Analyser [22] that provides were left out of this implementation version because
additional functionalities, such as graphical topology they were not needed for the works reported in Section
of the network, statistics, message flows, PAN 4. Features that are not currently supported include the
information and association details. unslotted version of the CSMA/CA, the active and
orphan channel scan and the use of extended
3.2. TinyOS and nesC addressing fields in normal data transmissions.
In the ZigBee Network Layer, the currently
TinyOS [16] is an operating system for embedded supported features comprise the data transfer between
systems with an event-driven execution model. the Network Layer and the MAC sub-layer, the
TinyOS is developed in nesC [17], a language for association mechanisms and the network topology
programming structured component-based management (e.g. cluster-tree support by the ZigBee
applications. nesC has a C-like syntax and is designed Addressing schemes) and routing (e.g. neighbour
to express the structuring concepts of TinyOS. This routing and tree-routing). Security is not supported yet.
includes the concurrency model, mechanisms for The Open-ZB implementation has three main
structuring, naming and linking together software TinyOS components: the Phy, the Mac and the NWL
components into embedded system applications. The components (Fig. 5).
component-based application structure provides The organization in components enables an easy
flexibility to the application design and development. and fast development of adaptations/extensions to the
nesC applications are built out of components and current implementation. Each of these components
interfaces. The components define two target areas: (1) makes use of auxiliary files to implement some generic
the specification, a code block that declares the functions (e.g. functions for bit aggregation into
functions it provides (implements), and the functions variable blocks), declaration of protocol constants,
that it uses (calls); (2) the implementation of the enumerations (e.g. data types, frame types, response
functions provided. The interfaces are bidirectional status) and data structure definitions (e.g. frames).
collections of functions provided or used by a The interface files (Fig. 5a right side) are used to
component. The interfaces commands are implemented bind the components and represent one Service Access
by the providing component, and the interface events Point (SAP), providing functions that are called from
are implemented by the component using it. The the higher layer components and are
components are “wired” together by means of executed/implemented in the lower layer module. The
interfaces, forming an application. interfaces also provide functions used by the lower
TinyOS defines a concurrency model based on layer components to signal functions that are
tasks and hardware events handlers/interrupts. TinyOS executed/implemented in the higher layer components.
tasks are synchronous functions that run without For example, the PD_DATA.nc interface is used by the
MacM module to transfer data to the PhyM module, duration with SO = 3 is equal to 122.88 ms, while it is
that is going to be transmitted, and also enables the equal to 133.36 ms using the MICAz motes and the
signalling by the PhyM in the MacM of received data. TinyOS time management of the clock granularity.
Fig. 5b depicts the relations between the different
components of the protocol stack implementation. In
this implementation, there is no direct interaction with
the hardware, since TinyOS already provides hardware
drivers forging a hardware abstraction layer used by
the Phy component. In Fig. 5b, observe that the
components filled in white are hardware components
already provided by the TinyOS operating system (e.g.
the HPL<…>.nc and the MSP430<…>.nc modules).
The Mac and the NWL components are shared by
the two platforms (MICAz and TelosB). However,
there are two different Phy components, one for each
platform. At compilation time, the Phy component is
selected according to the envisaged platform. The need
of two different Phy components is due to the fact that
the TinyOS hardware specific modules are different
for each platform.
In addition, both platforms differ in the hardware
timers they provide, leading to two different timer
modules (the TimerAsync) with the purpose of
managing all asynchronous timer events of the MAC
sub-layer (e.g. Beacon Interval, Superframe Duration,
time slots and backoff periods). For the synchronous
timers, used in non time critical operations (e.g. a) Protocol stack architecture
application layer events), we use the standard TimerC
module already provided by TinyOS. Nevertheless, the
software architecture is the same for both platforms.
The MICAz hardware clock (provides a frequency
of 7.3728 MHz) is implemented in the HPLTimer2C
(as seen in Fig. 5b) component, already provided in
TinyOS, and is defined by two parameters: the SCALE
that defines the scale division of the timer frequency
and the INTERVAL defining the number of ticks per
clock firing.
The clock tick granularity of the MICAz mote that
best fits the implementation requirements is equal to
69.44 µs, which approximately corresponds to four
symbols (configuration with SCALE equal to 4 and
INTERVAL equal to 1), assuming a 250 kbps bit rate.
The 69.44 µs is achieved by dividing the clock
frequency by 256 (SCALE of 4) resulting in a b) TinyOS implementation diagram
frequency of 28.8 kHz (approximately 34.72 µs) and 2
interval counts (INTERVAL of 1) resulting in a clock Fig. 5. Protocol Stack Software Architecture
tick every 69.44 µs. This value corresponds to the The hardware timer available in the TelosB is based
duration of four symbols (16 bits) and is a fair on a 32768 Hz clock that fires approximately every
approximation to the theoretical value of 64 µs. 30.5 µs. Comparing with the MICAz timer, this does
However, it still leads to a cumulative effect on the not allow the set of a scale or interval parameters.
discrepancy with the theoretical values of Beacon Instead, this is a continuous timer that counts from 0 to
Intervals, Superframe Durations and time slot 0xFFFF and when it overflows it triggers an interrupt
durations, especially for high Superframe and Beacon and starts again from 0. The only parameterization
Orders. For instance, the theoretical Superframe allowed is the number of overflow count before
issuing the interrupt. The TelosB hardware clock is related to the TinyOS management of the hardware
implemented in the MSP430TimerC module (as seen in timers provided by the motes, which does not allow
Fig. 5b), already provided in TinyOS. The having the exact values of the Beacon Interval,
HPLCC2420InterruptM module implements the timer Superframe, time slots and backoffs durations as
fired interrupt as well as all the other hardware specified by the IEEE 802.15.4 standard. This
interrupts. The solution that best fits ours requirements discrepancy, however, does not impact the correct
is to trigger the timer on every backoff. The IEEE behaviour of the implemented protocol. If the same
802.15.4 defines that one backoff is 20 symbols, that mote platforms are used in the experiments (at least as
theoretically corresponds to 16 µs. With this timer ZC and ZRs), it is possible to experience a coherent
granularity, the value obtained for each symbol is network behaviour.
approximately 16.775 µs, leading to a backoff period
duration of 335.5 µs instead of the theoretical 320 µs.
Refer to extended technical reports in [23, 24] for a
detailed description of the implementation functions,
variables and protocol mechanisms.

3.4. Implementation challenges

The main challenges encountered while Fig. 6. Asynchronous events

implementing the IEEE 802.15.4/ZigBee protocol
The frequency of the asynchronous software events
stack were related to hardware specificities and
(Fig. 6) together with the hardware events and the
constraints. In that aspect, the MICAz motes revealed
microprocessor processing capacity may lead to an
to be more limited that the TelosB. Nevertheless, none
insufficient remaining processing power to execute
of them provides enough processing power and radio
protocol and high level application tasks as a great
performance for an implementation that fully complies
amount of interrupts have to be processed in short
with the IEEE 802.15.4 standard timing constraints,
periods of time.
especially for small Beacon Orders (BO < 2) and
The IEEE 802.15.4 protocol has no reference
Superframe Orders (SO < 2). Additionally, the
concerning the implementation of the buffer
available memory size is rather scarce. However, it is
mechanisms, which impacts on the correct behaviour
possible to achieve a reasonable operational behaviour
of the protocol. On the one hand, the protocol must
for higher beacon orders.
avoid excessive memory copy operations because they
The timing requirements of the IEEE 802.15.4
may cause synchronization problems and are very time
protocol are very demanding. In the beacon-enabled
consuming. On the other hand, the buffers have to be
mode, all the devices must synchronize with a
small and very well managed due to the devices
Coordinator beacon frame in order to align their
memory constraints.
Superframe. If a device loses synchronization it cannot
Another constraint of the IEEE 802.15.4 Physical
operate in the PAN; and if it is not correctly
Layer is the turnaround time of 12 symbols (192 µs),
synchronized there is a possibility of collisions in the
the time that the CC2420 radio transceiver takes to
GTS slots (if the CAP overlaps the CFP). As
switch from receive mode to transmit mode and
experienced during this implementation, the loss of
vice-versa, to acknowledge messages. Unfortunately,
synchronization can be caused by multiple factors: (1)
this is not possible to achieve in most IEEE 802.15.4-
the processing of the beacon frame for small SO/BO
compliant radio transceivers. For instance, the Chipcon
configurations; (2) the mote stack overflow that results
CC2420 can take up to 192 µs to switch between these
in a block or a hard reset; (3) the unpredictable delay
two modes, leaving no time for data transitions
of the wireless communications; and (4) the low
between the MAC sub-layer, the PHY layer and the
processing power of the microcontroller in conducting
chip transmit memory space.
some of the protocol maintenance tasks (e.g. creating
Also, TinyOS imposes some overhead [25] in the
the beacon frame, the maintenance of GTS expiration
primitive operations (e.g. posting tasks, calling
and the indirect transmissions).
commands) that may be considerable, taking into
The implementation of the CSMA/CA algorithm is
account the need to comply with the most demanding
also very demanding in terms of timers precision, since
operational modes of the IEEE 802.15.4 protocol.
the IEEE 802.15.4 protocol defines that each backoff
In spite of having no comparison between this
corresponds to 20 symbols (320 µs). A first difficulty
TinyOS implementation and others, it is possible to
in the implementation of the beacon-enabled mode was
assume that an implementation without any base 4.1 Evaluation of Slotted CSMA/CA
operating system (OS) could have better performance
results, since TinyOS can introduce some unnecessary The performance of the IEEE 802.15.4 Slotted
processing overhead in its internal operations. There is CSMA/CA mechanism is evaluated with the purpose
an obvious trade-off between the benefits of using an of testing and validating the effectiveness of the
OS, bringing in several functionalities that enable a hardware devices and the implemented CSMA/CA
faster development of high end applications and the mechanism.
processing overhead introduced. Considering that the In order to accomplish this evaluation an OPNET
embedded devices have limited resources, it is [14] simulation model [12,13] for the IEEE 802.15.4
reasonable to assume that a non-OS based supporting the slotted CSMA/CA mechanism was used
implementation can be more optimized but not so as a means to compare experimental and simulation
flexible. results, for the same scenarios. Using this model, it
Nevertheless, this implementation still has space for was possible to analyse the performance limits of the
extensions and improvements, as it it is envisaged to Slotted CSMA/CA mechanism for broadcast
implement the full functionalities of the IEEE 802.15.4 transmissions (without acknowledgements). The
and the ZigBee Network Layer. Also, we aim at the analysis was done for different network settings, in
migration of our protocol stack from TinyOS v1.15 to order to understand the impact of some protocol
v2.0, in collaboration with the TinyOS Network parameters on the network performance, namely in
Protocol Working Group [26]. terms of Network Throughput (S) and Probability of
As a final remark about the evolution between the Successful transmissions (Ps), given a certain Offered
2004 and 2006 ZigBee specification, several issues Load (G). The performance metrics analysed are based
were corrected while others were added introducing on an extensive study of the Slotted CSMA/CA
more complexity but with the advantage of adding presented in [27, 28].
more flexibility. The mesh network topology evolved Recently, we have been using the Open-ZB
with the addition of new functionalities, such as the implementation in the MICAz motes with the purpose
possibility of multicast transmissions and a source of analysing the performance of the Slotted CSMA/CA
route routing protocol, while the cluster-tree mechanism and comparing it with the simulation
synchronized topology was left behind. Hence, there results. In general, both the simulation and
are still many open-issues in the ZigBee standard that experimental scenarios (with 100 seconds duration)
leaves room for improvement, especially for cluster- consisted in 10 nodes (MICAz) generating traffic at
tree networks. pre-programmed inter-arrival times at the application
layer and a packet analyzer capturing all the data for
4. Research Work later processing and analysis. The packet analyzer used
in the experimental evaluation process was the
We have been characterizing and improving the Chipcon CC2420 Packet Sniffer [21]. It generates a
IEEE 802.15.4 behaviour in several research works, text file with all the received packets and the
via analytical simulation and experimental work. In corresponding timestamps, enabling to retrieve all the
this section, we present a brief overview on our necessary data, (embedded in the packets payload),
research work where we have used our Open-ZB with a parser application, in order to avoid serial
implementation to validate our proposals and to assess communications.
some of the current functionalities proposed in the As an example of what has already been achieved,
standards. In Section 4.1, we start by evaluating the Fig.7 presents some elucidative results obtained by
Slotted CSMA/CA mechanism comparing simulation and experimental evaluation for the
experimental and simulation results from the IEEE Network Throughput (S) and Success Probability (Ps)
802.15.4 simulation model [12, 13]. In addition, as a function of the Offered Load (G), considering the
concerning GTS management, we show how we have case of one experiment where SO = BO = 5.
implemented an implicit Guaranteed Time Slot The Network Throughput (S) represents the fraction
allocation mechanism (i-GAME) proposed in [5], and of traffic correctly received by the network analyzer
some general results (Section 4.2). Finally, we outline normalized to the overall capacity of the network (250
how we have implemented and validated a mechanism kbps). The Success Probability (Ps) reflects the degree
to overcome the problem of beacon frame collisions in of reliability achieved by the network for successful
cluster-tree topologies (Section 4.3). transmissions. This metric is computed as the
throughput S divided by G, representing the amount of
 traffic passed to the MAC sub-layer, again normalized to benefit from guaranteed service and also to a wasted
to the overall network capacity. bandwidth, if GTSs are underutilized.
Although Fig. 7 only presents the experiments for The i-GAME approach [5] is based on implicit GTS
S0 = BO = 5, several SO configurations have been allocation requests, taking into account the traffic
analysed. specifications and the delay requirements of the flows,
therefore enabling the use of each GTS by several
100% Experimental S nodes, still guaranteeing that all their requirements
Simulation S
90% (delay, bandwidth) are satisfied. In [5], we have
Throughput (S ) Success Probability (Ps )

Experimental Ps
80% proposed an admission control algorithm that decides
Simulation Ps
70% whether to accept or reject a new GTS allocation based
on its requirement and traffic specifications.
60%
The i-GAME mechanism was implemented in the
50%
MAC and Network Layers, defining a new service
40% access point between these two layers - the MLME-
30% i-GAME. A detailed standard-like description of the
20% interfaces added to the Network layer and the
BO = SO = 5 enhancements to the MAC sub-layer for supporting the
10%
Offered Load (G ) i-GAME mechanism is presented in [29].
0%
Comparing with the standard IEEE 802.15.4, the
0% 50% 100% 150% 200% 250% 300%
i-GAME mechanism just needs to change the
management of the beacon GTS descriptors, which
Fig. 7. Network Throughput function of Offered
have to be included in the beacon in a round robin
Load obtained (simulation & experimentation)
sequence. The implicit GTS descriptors are managed
Simulation and experimental results allowed by the i-GAME Admission Control procedure by
observing similar behaviours, which consolidates the issuing the MLME_iGAME.response, which updates
consistency of the implemented version of the Slotted the GTS descriptors.
CSMA/CA mechanism.
As it could be expected, the simulation results for
Throughput and Probability of Success are higher that
the experimental results. We believe that this is mainly
because the simulation model does not consider some
of the physical constraints of the MICAz mote,
especially the processing power, the internal delays
due to TinyOS overheads and the normal interferences
of a real wireless medium.
One of the reasons for a lower performance with
lower SO is due to an increased probability of
transmission deference (e.g. frames that are deferred to
the next Superframe because the device is not able to
send them in the current one). The transmission
deference problem is more frequent with lower SO,
since the SD is smaller. Another factor for the lower
performance is the overhead of the beacon frame
transmission, which is more significant for lower SO
values. Fig. 8. Number of nodes allocating a GTS with
i-GAME versus the GTS length
4.2. Implicit GTS allocation mechanism The i-GAME mechanism assumes that when a node
wishes to allocate a time slot, it sends an implicit GTS
The IEEE 802.15.4 supports a GTS allocation request command (similar to the IEEE 802.15.4 GTS
mechanism, where a node explicitly allocates a number request command) that includes the desired flow
of time slots in each Superframe for its exclusive use. specification (the burst size, arrival rate and the delay
The limitation of this mechanism is inherent to the requirements) in addition to the standard IEEE
maximum number of seven available GTS that can be 802.15.4 GTS characteristics (direction and type). The
allocated in each Superframe, preventing other nodes PAN Coordinator evaluates the acceptance of the GTS
allocation by running the Admission Control algorithm cluster under its control) and also during the active
with the requested flow specifications. The i-GAME period of its parent.
Admission Control algorithm manages the number of The TDBS approach relies on a negotiation for
necessary GTS time slots in order to comply with the beacon broadcasting. Upon success of the association
requested flow specifications. This is accomplished by to the network, the ZR (behaving as a ZED) sends a
managing the GTS descriptors of the beacon frame negotiation message to the ZC (routed along the tree)
transmitted by the PAN Coordinator allowing the embedding the envisaged (BO, SO) pair requesting a
nodes that allocated a GTS to use them. beacon broadcast permit. Then, in case of a
Fig. 8 [5] depicts an example of the usage of the successfully negotiation, the ZC replies with a
GTS allocated time slots and the optimization of negotiation response message containing a beacon
bandwidth that can be achieved with the i-GAME transmission offset (the instant when the ZR starts
mechanism. To observe the impact of the delay transmitting the beacon). In case of rejection, the ZR
requirement on the improvement of the GTS must disassociate from the network.
efficiency, we have run the experimental scenario with
delay requirements of 900 ms, 700 ms, 500 ms and 300
ms (Fig. 8). Observe that relaxing the delay bound of 7
nodes (to 900 ms) requesting GTS allocation enables
to save up to 5 time slots as compared to explicit
allocation, while still satisfying the delay bounds. This
(saved) time can be used to extend the Contention-
Access Period, thus improving the utilization of the
network.

4.3. Time division beacon scheduling

The current IEEE 802.15.4/ZigBee specifications Fig. 9. TDBS Implementation Architecture

restrict the synchronization in the beacon-enabled
mode to star-based networks, while supporting multi- Fig. 9 depicts the architecture of the TDBS
hop networking using the mesh topology, but with no implementation in the IEEE 802.15.4/ZigBee protocol
synchronization. Even though both specifications stack. The admission control algorithm is implemented
mention the possible use of cluster-tree topologies, in the Application Support Layer, behaving as a
which combine multi-hop and synchronization service module of this layer.
features, the description on how to effectively The TDBS requires minor changes to the Network
construct such a network topology is missing. Layer. Thus, it is necessary to add a StartTime
The Time Division Beacon Scheduling (TDBS) argument in the MLME-START.request primitive, as
mechanism (without coordinator grouping), proposed already proposed in the ZigBee Specification [2], and
in [30], can be implemented in a simple manner, with to the NLME-START-ROUTER.request primitive.
only minor add-ons to the protocol. In our In this example scenario, the cluster-tree network
implementation, the ZigBee Network Layer supports contains 15 clusters that consist of one ZC and 14 ZRs
the network management mechanisms (e.g. association (all TelosB motes). The BO is set to 8 for all
and disassociation) and the tree-routing protocol. The Coordinators, which gives a BI of 245760 symbols
tree-routing relies on a distributed address assignment (≅ 4122.624 ms). Since the, we must have at least 16
mechanism that provides to each potential parent (ZC Beacon/Superframe time windows, each with duration
and ZRs) a finite sub-block of unique network of 15360 symbols (≅ 257.664 ms). This restricts the
addresses based on the maximum number of children, (maximum) SO to 4 (i.e. Superframe Duration (SD) =
depth and the number of routers in the PAN. The ZC is 15360 symbols). In our experimentation, we choose a
the first node in the WSN to come to life and to SO = 4 (SD = 15360 symbols (≅ 257.664 ms)). The
broadcast beacons. Every ZR, after its association to cluster-tree network parameters (for setting up the tree
the network, temporarily acts as a ZED and must be routing mechanism) consist in a maximum depth equal
granted permission by the ZC before assuming ZR to Lm=3, a maximum number of child nodes per
functionality and starting sending beacon frames. All parent router equal to Cm=6, and a maximum number
the ZRs and ZC use the same BI. Each ZR must be of child routers per parent router equal to Rm=4. As
active both during its Superframe Duration (in the shown in Fig. 10, the network comprises the ZC at
depth 0, two ZRs at depth 1, four ZRs at Depth 2 and
eight ZRs at depth 3. The ZED (0x0400) was also permit and a time window (transmission offset). The
considered for performing out a message routing test. negotiation procedure is marked as 3. Until this point,
In Fig 11, marked as 1, is the beacon broadcast of and after the network association, the ZR behaves as a
the ZC containing the network configuration BO and normal ZED. When the negotiation for beacon
SO, as seen in the Packet Type field. Note that the transmission finishes, the ZR starts to broadcast
Time Delta (4150 ms) between beacons represents the beacons in its assigned time window, as seen in Fig 11
Beacon Interval. marked as 4. Note that both the association and
negotiation for beacon transmission took place during
the ZC Superframe.

Fig. 10. Experimental network configuration

The sequence of messages marked as 2 (Fig.11)
represents the association procedure. The ZR with the
extended address of 0x0000000200000002 sends an
association request to the ZC (0x0000), which
acknowledges the reception and informs the ZR of
pending data. Then, the ZR sends a data request Fig. 12. Message Flow and Beacon Frames
command frame requesting the pending data and the The ZED (0x0400) has associated with ZR 0x0003
ZC replies with the association response command with the purpose of periodically transmit data frames
frame containing the status of the association, where through the cluster-tree in order to test the topology
the ZR is assigned the short address 0x0001. and the tree-routing mechanism. In Fig. 12, message
flows are marked with capital characters (e.g. A, B, C)
and the hop count with indexes (e.g. A1, A2, A3). The
first transmission from the ZED (0x0400) to its parent
(ZR 0x0003) is shown in A1. Note that this
transmission is carried out during ZR 0x0003
Superframe. The routing of the data frame from ZR
0x0003 to its parent in the cluster-tree (ZR 0x0002) is
marked as A2. The multi-hop continues with the
routing of the frame from ZR 0x0002 to ZR 0x0001
(A3). In B1, a new message flow is initiated by the
ZED (0x0400). Then, in A4, the message is relayed
Fig. 11. Association and negotiation Example from ZR 0x0001 to ZC (0x0000) and to ZR 0x0020.
Now, the ZigBee Router is associated as a ZigBee This transmission sequence is carried out during the
End Device and can therefore communicate in the ZC Superframe. The multi-hop continues in A5
network, but it still needs to request the ZigBee between ZR 0x0020 and ZR 0x0028. The last hop is
Coordinator for a beacon broadcast transmission carried out in A6 with ZR 0x0028 relaying it to its
final destination, ZR 0x0028.
5. Concluding Remarks [8] L. Hwang, "Grouping Strategy for Solving Hidden Node
Problem in IEEE 802.15.4 LR-WPAN", 1st International
Conference on Wireless Internet (WICON'05), 2005.
The IEEE 802.15.4/ZigBee protocols emerge as [9] A. Koubaa, M. Alves, E. Tovar, "Modeling and Worst-
potential technologies for wireless sensor networks. Case Dimensioning of Cluster-Tree Wireless Sensor
Thus, it is of paramount importance to analyse their Networks", 27th IEEE Real-Time Systems Symposium
adequateness for fulfilling the requirements of large- (RTSS'06), Rio de Janeiro (Brazil), 2006.
scale embedded computing applications. [10] Open-ZB - Open-source Toolset for IEEE 802.15.4 and
In this context, we have triggered the ART-WiSe ZigBee. http://www.open-zb.net
research line [15], which aims at the design of a [11] Crossbow, http://www.xbow.com, 2007
communication architecture for large-scale critical [12] P. Jurčík, A. Koubâa, “The IEEE 802.15.4 OPNET
applications based on COTS technologies, namely Simulation Model: Reference Guide v2.0”, www.open-
zb.net, HURRAY-TR-070509, May 2007.
IEEE 802.15.4/ZigBee. For that purpose, we have
[13] P. Jurcik, A. Koubâa, M. Alves, E. Tovar, Z. Hanzalek,
developed our own implementation of the protocol “A Simulation Model for the IEEE 802.15.4 protocol:
stack [10], which we are making available to the Delay/Throughput Evaluation of the GTS Mechanism”,
community as open-source. This has already triggered to be published in the 15th IEEE International Symposium
several relevant interactions with world-reputed on Modelling, Analysis, and Simulation of Computer and
researchers, companies and normalization bodies. Telecommunication Systems (MASCOTS´07), 2007.
This paper presented an overview of the most [14] OPNET Simulator v11, http://www.opnet.com.
important aspects of the software architecture and [15] The ART-WiSe Research Framework,
implementation challenges, as well as a number of http://www.hurray.isep.ipp.pt/art-wise/
[16] TinyOS, http://www.tinyos.net, 2007.
research works that build on its use.
[17] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer,
D. Culler, "The nesC Language: A Holistic Approach to
Acknowledgment Networked Embedded Systems", Programming Language
Design and Implementation, 2003.
This work was funded by FCT under the CISTER [18] Texas Instruments, “MSP430x21x1 Datasheet”, 2004.
Research Unit (FCT UI 608) and PLURALITY [19] ATmega128L 8-bit AVR Microcontroller Datasheet,
(CONCREEQ/900/2001) projects, and by the Atmel ref: 2467MAVR-11/04, http://www.atmel.com
[20] Chipcon, "CC2420 transceiver datasheet", 2004.
ARTIST2 NoE (IST-2001-34820).
[21] Chipcon Packet Sniffer for IEEE 802.15.4 v1.0, 2006.
[22] Daintree Networks, "Sensor Network Analyser,"
References www.daintree.net, 2006.
[23] A. Cunha, M. Alves, A. Koubaa, "An IEEE 802.15.4
[1] IEEE-TG15.4, "Part 15.4: Wireless Medium Access protocol implementation (in nesC/TinyOS): Reference Guide
Control (MAC) and Physical Layer (PHY) Specifications for v1.2", HURRAY-TR-061106, http://www.open-zb.net 2007.
Low-Rate Wireless Personal Area Networks (LR-WPANs)," [24] A. Cunha, M. Alves, A. Koubâa, “Implementation of the
IEEE standard for Information Technology, 2003. ZigBee Network Layer with Cluster-tree Support”,
[2] A. Koubâa, M. Alves, and E. Tovar, "IEEE 802.15.4: a HURRAY-TR-070510, May 2007.
Federating Communication Protocol for Time-Sensitive [25] J. Hill, R. Szewczyk, A.Woo, S. Hollar, D. Culler, K.
Wireless Sensor Networks", Sensor Networks and Pister, “System Architecture Directions for Networked
Configurations: Fundamentals, Techniques, Platforms, and Sensors”, ASPLOS 2000, Cambridge, November 2000.
Experiments, Springer-Verlag, Germany, pp. 19-49, 2007. [26] TinyOS Network Protocol Working Group,
[3] ZigBee Specification 2006, http://www.zigbee.org/ http:/tinyos.stanford.edu:8000/Net2WG
[4] A. Koubâa, M. Alves, and E. Tovar, "GTS Allocation [27] A. Koubaa, M. Alves, E. Tovar, “A Comprehensive
Analysis in IEEE 802.15.4 for Real-Time Wireless Sensor Simulation Study of Slotted CSMA/CA for IEEE 802.15.4
Networks", 14th International Workshop on Parallel and Wireless Sensor Networks”, IEEE WFCS 2006, Torino
Distributed Real-Time Systems (WPDRTS 2006), 2006. (Italy), June 2006.
[5] A. Koubâa, M. Alves, and E. Tovar, "i-GAME: An [28] A. Koubâa, M. Alves, E. Tovar, "On the Performance
Implicit GTS Allocation Mechanism in IEEE 802.15.4", 18th Limits of Slotted CSMA/CA in IEEE 802.15.4 for Broadcast
Euromicro Conf. on Real-Time Systems (ECRTS’06), 2006. Transmissions in Wireless Sensor Networks", HURRAY-
[6] J. Misic and V. B. Misic, "Access delay for nodes with TR-060202, Feb. 2006.
finite buffers in IEEE 802.15.4 beacon-enabled PAN with [29] A. Cunha, A. Koubâa, and M. Alves, "Implementation
uplink transmissions", Computer Communications, vol. 28, of the i-GAME Mechanism in IEEE 802.15.4 WPANs",
pp. 1152-1166, 2005. TR060702, July 2006.
[7] J. Misic, S. Shafi, V. B. Misic, "Modeling a beacon- [30] A. Koubâa, A. Cunha, M. Alves, “A Time Division
enabled 802.15.4 cluster with bidirectional traffic", Lecture Beacon Scheduling Mechanism for IEEE 802.15.4/ZigBee
Notes in Computer Science, vol. 3462, pp. 228-239, 2005. Cluster-Tree Wireless Sensor Networks”. 19th Euromicro
Conf. on Real-Time Systems (ECRTS 2007), July 2007