(SpringerBriefs in Electrical and Computer Engineering) Stefano Tennina, Anis Koubâa, Roberta Daidone, Mário Alves, Petr Jurčík, Ricardo Severin

SPRINGER BRIEFS IN ELEC TRIC AL AND
COMPUTER ENGINEERING  COOPERATING OBJECTS
Stefano Tennina · Anis Koubâa · Roberta Daidone

Mário Alves · Petr Jurčík · Ricardo Severino
Marco Tiloca · Jan-Hinrich Hauer · Nuno Pereira
Gianluca Dini · Mélanie Bouroche · Eduardo Tovar
IEEE 802.15.4 and

ZigBee as Enabling
Technologies for
Low-Power Wireless
Systems with
Quality-of-Service
Constraints
SpringerBriefs in Electrical and Computer
Engineering
Cooperating Objects
Series Editor
Pedro José Marron
For further volumes:

http://www.springer.com/series/10208
Stefano Tennina Anis Koubâa
•
Roberta Daidone Mário Alves

•
Petr Jurčík Ricardo Severino

•
Marco Tiloca Jan-Hinrich Hauer

•
Nuno Pereira Gianluca Dini

•
Mélanie Bouroche Eduardo Tovar

•
IEEE 802.15.4 and ZigBee

as Enabling Technologies
for Low-Power Wireless
Systems with Quality-
of-Service Constraints
123
Stefano Tennina Petr Jurčík
Anis Koubâa Instituto Superior de CISTER
Mário Alves Research Centre
Ricardo Severino Porto
Nuno Pereira Portugal
Eduardo Tovar
CISTER/INESC-TEC Research Centre Jan-Hinrich Hauer
Politécnico do Porto (ISEP/IPP) Telecommunication Networks Group
Porto Technische Universität Berlin
Portugal Berlin
Germany
Roberta Daidone
Marco Tiloca Mélanie Bouroche
Gianluca Dini School of Computer Science and Statistics
Department of Information Engineering Trinity College Dublin
University of Pisa Dublin
Pisa Ireland
Italy
ISSN 2191-8112 ISSN 2191-8120 (electronic)

ISBN 978-3-642-37367-1 ISBN 978-3-642-37368-8 (eBook)
DOI 10.1007/978-3-642-37368-8
Springer Heidelberg New York Dordrecht London
Library of Congress Control Number: 2013936525
Ó The Author(s) 2013

This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of
the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations,
recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or
information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar
methodology now known or hereafter developed. Exempted from this legal reservation are brief
excerpts in connection with reviews or scholarly analysis or material supplied specifically for the
purpose of being entered and executed on a computer system, for exclusive use by the purchaser of the
work. Duplication of this publication or parts thereof is permitted only under the provisions of
the Copyright Law of the Publisher’s location, in its current version, and permission for use must
always be obtained from Springer. Permissions for use may be obtained through RightsLink at the
Copyright Clearance Center. Violations are liable to prosecution under the respective Copyright Law.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this
publication does not imply, even in the absence of a specific statement, that such names are exempt
from the relevant protective laws and regulations and therefore free for general use.
While the advice and information in this book are believed to be true and accurate at the date of
publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for
any errors or omissions that may be made. The publisher makes no warranty, express or implied, with
respect to the material contained herein.
Printed on acid-free paper
Springer is part of Springer Science+Business Media (www.springer.com)

Preface
IEEE 802.15.4 (15.4, for short) and ZigBee are among the most prominent
communication technologies for low-power wireless networking such as wireless
sensor/actuator networks (WSANs). These technologies have been widely used
both in academia and industry in a variety of wireless sensing/actuation applica-
tions. Also, they have been used as a baseline for other standard communication
protocols/models such as WirelessHART and 6LoWPAN.
This book outlines the most important characteristics of 15.4 and ZigBee and
how they can be used to engineer WSN systems and applications, with a particular
focus on Quality-of-Service (QoS) aspects. It starts by providing a snapshot of the
most relevant features of these two protocols, identifying some gaps in the stan-
dard specifications. Then it describes several state-of-the-art open-source imple-
mentations, models, and tools that have been designed by the authors and have
been widely used by the international community. The book also outlines the
fundamental performance limits of 15.4/ZigBee networks, based on well-sustained
analytical, simulation, and experimental models, including how to dimension such
networks to optimize delay/energy trade-offs.
The Part II of the book illustrates several add-ons to the baseline 15.4 and
ZigBee protocols that improve their QoS properties, including security, reliability,
timeliness, and energy-efficiency. Finally, the Part III of the book aims at pro-
viding a flavor of some real-world applications and system architectures based on
these technologies.
The book builds on a solid critical mass and original contributions from the
authors, resulting from extensive analytical, simulation, and experimental work
carried out over more than 6 years. To the best of our knowledge, this is the first
book tackling engineering aspects of 15.4 and ZigBee for low-power wireless
networks (such as wireless sensor/actuator networks). Thus, we believe it will
serve as baseline reading material for students and as a reference to orient
researchers and system designers in this area.
Porto, May 2013 Mário Alves
v
Contents
Part I IEEE 802.15.4 and ZigBee Protocols and Implementations
1 Snapshot of the IEEE 802.15.4 and ZigBee Protocols . . . . . . . . . . 3

1.1 General Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Physical Layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.2 Medium Access Control Sub-Layer . . . . . . . . . . . . . . . 9
1.3 ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.1 Short Address Assignment . . . . . . . . . . . . . . . . . . . . . 20
1.3.2 ZigBee Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3.3 Routing Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4 Problems, Gaps and Open Issues . . . . . . . . . . . . . . . . . . . . . . 23
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2 Protocol Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1 IEEE 802.15.4 MAC Implementation in TinyOS 2. . . . . . . . . . 27
2.1.1 TinyOS 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.2 MAC Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.3 Radio Arbitration in Beacon-Enabled PANs . . . . . . . . . 31
2.1.4 Interface Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2 ZigBee Cluster-Tree Network Layer Implementation
in TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.2.1 Software Architecture. . . . . . . . . . . . . . . . . . . . . . . . . 38
2.2.2 Joining a ZigBee Network . . . . . . . . . . . . . . . . . . . . . 38
2.2.3 Tree Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3 Models and Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.1 Worst-Case Analysis and Dimensioning . . . . . . . . . . . . . . . . . 45
3.1.1 Guaranteed Bandwidth of a GTS . . . . . . . . . . . . . . . . . 46
3.1.2 Characterization of the Service Curve . . . . . . . . . . . . . 47
3.1.3 IEEE 802.15.4/ZigBee Cluster-Tree WSN Setup . . . . . . 49
vii
viii Contents
3.2 Simulation Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.2.1 OPNET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.2 CASTALIA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.3 Network/Protocol Analyzer (Z-Monitor) . . . . . . . . . . . . . . . . . 60
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4 Performance Analysis and Network Dimensioning . . . . . ....... 65

4.1 Performance Analysis of the IEEE 802.15.4 GTS
Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.1.1 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.1.2 Simulation Versus Analytical Models . . . . . . . . . . . . . . 66
4.1.3 Performance Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.2 Performance Analysis of the IEEE 802.15.4
CSMA/CA Mechanism . . . . . . . . . . . . . . . . . . . . . . ....... 71
4.2.1 Experimental and Simulation Testbeds . . . . . . ....... 72
4.2.2 Performance Analysis . . . . . . . . . . . . . . . . . . ....... 74
4.3 Performance Analysis and Worst-Case Dimensioning
of ZigBee Cluster-Tree Networks. . . . . . . . . . . . . . . . . . . . . . 77
4.3.1 Network Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.3.2 Network Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Part II Quality of Service Amendments
5 Amendments to the IEEE 802.15.4 Protocol . . . . . . . . . . . . . . . . 85

5.1 Implicit GTS Allocation Mechanism . . . . . . . . . . . . . . . . . . . 85
5.1.1 i-GAME Implementation Guidelines . . . . . . . . . . . . . . 87
5.1.2 Experimental Evaluation . . . . . . . . . . . . . . . . . . . . . . . 88
5.2 Hidden Node Avoidance Mechanism . . . . . . . . . . . . . . . . . . . 90
5.2.1 H-NAMe in IEEE 802.15.4/ZigBee . . . . . . . . . . . . . . . 92
5.3 Traffic Differentiation Mechanism for CSMA/CA . . . . . . . . . . 96
5.3.1 Traffic Differentiation Strategy . . . . . . . . . . . . . . . . . . 96
5.3.2 Implementation Approach . . . . . . . . . . . . . . . . . . . . . . 98
5.4 Security Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.4.1 Security Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.4.2 Security-Related PAN Information . . . . . . . . . . . . . . . . 105
5.4.3 Key Identifier Modes . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.4.4 Security Functional Description . . . . . . . . . . . . . . . . . . 106
5.4.5 Impact of Security on Performance . . . . . . . . . . . . . . . 110
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Contents ix
6 Amendments to the ZigBee Protocol . . . . . . . . . . . . . . . . . . . . .. 113

6.1 Time Division Cluster Scheduling for ZigBee Cluster-Tree
Networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6.1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6.1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6.1.3 Implementation Details of the TDCS Approach . . . . . . . 115
6.2 Geographical and Multicast Routing for ZigBee Cluster-Tree
Networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
6.2.1 Z-Cast: ZigBee Multicast Routing . . . . . . . . . . . . . . . . 118
6.2.2 Geographical Routing . . . . . . . . . . . . . . . . . . . . . . . . . 122
6.3 Security Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.3.1 ZigBee NWK Frames Protection . . . . . . . . . . . . . . . . . 127
6.3.2 ZigBee APS Frames Protection . . . . . . . . . . . . . . . . . . 127
6.3.3 ZigBee Security Modes . . . . . . . . . . . . . . . . . . . . . . . 128
6.3.4 ZigBee Application Profiles . . . . . . . . . . . . . . . . . . . . 128
6.3.5 Deficiencies in ZigBee Security. . . . . . . . . . . . . . . . . . 131
6.3.6 Key Revocation and Renewal . . . . . . . . . . . . . . . . . . . 131
6.3.7 Certificates Management. . . . . . . . . . . . . . . . . . . . . . . 132
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Part III System Architectures and Applications
7 Structural Health Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

7.1 System Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
7.2 Network Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
7.3 Synchronization Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 139
7.4 Theoretical Analysis of the Scalability . . . . . . . . . . . . . . . . . . 140
7.5 Experimental Analysis of the Scalability . . . . . . . . . . . . . . . . . 141
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
8 Environmental Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

8.1 Design Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
8.2 EMMON System Architecture . . . . . . . . . . . . . . . . . . . . . . . . 144
8.3 Communication Protocol Architecture. . . . . . . . . . . . . . . . . . . 146
8.3.1 Design Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
8.3.2 Multi-Tiered Architecture . . . . . . . . . . . . . . . . . . . . . . 147
8.4 EMW: EMMON Middleware . . . . . . . . . . . . . . . . . . . . . . . . 148
8.4.1 High-Level API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
8.4.2 EMW Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . 148
8.4.3 Spatial Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . 150
8.5 Command and Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
8.6 System Planning, Simulation, Analysis Toolset . . . . . . . . . . . . 152
8.7 EMMON Demonstrator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
x Contents
9 Energy-Efficiency in Data Centers. . . . . . . . . . . . . . . . . . . . . . . . 159

9.1 Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
9.1.1 Environment and Power Data Collection . . . . . . . . . . . 160
9.2 Data Center Radio Environment. . . . . . . . . . . . . . . . . . . . . . . 162
9.2.1 Background Noise . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
9.2.2 WSN Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
9.3 Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
10 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
About the Authors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Part I
IEEE 802.15.4 and ZigBee Protocols and
Implementations
The first part of this book describes the features of the standard IEEE 802.15.4 and
ZigBee communication protocols and an open source implementation. Then, a set
of modeling and design tools is presented.
Chapter 1
Snapshot of the IEEE 802.15.4 and ZigBee
Protocols
Abstract This chapter presents the most important features of the IEEE 802.15.4
and ZigBee protocols. It particularly focuses on the Data Link and Network
Layers, which are the most relevant in the context of this book. Finally, a brief
discussion on the issues that the standards still leave open is presented. A possible
set of solutions to those problems will be formulated as amendments in the second
part of the book.
1.1 General Aspects
ZigBee defines two layers of the Open Systems Interconnection (OSI) model: The
Application Layer (APL) and the Network Layer (NWL), as depicted in Fig. 1.1.
Each layer performs a specific set of services for the layer above. The different
layers communicate through Service Access Points (SAP’s). These SAPs enclose
two types of entities: (1) a data entity (NLDE-SAP) to provide data transmission
service and (2) a management entity (NLME-SAP) providing all the management
services between layers.
The ZigBee Device Object (ZDO) in Fig. 1.1 is responsible for communicating
information about itself and its provided services. The ZDO is located in EndPoint
0. The Application Objects are the manufacturer’s applications running on top of
the ZigBee protocol stack. These objects, located between Endpoints 1 to 240,
adhere to a given profile approved by the ZigBee Alliance. The address of the
device and the EndPoints available provide a uniform way of addressing individual
application objects in the ZigBee network. The set of ZDOs, their configuration
and functionalities form a ZigBee profile. The ZigBee profiles intent to be a
uniform representation of common application scenarios. Currently, the ZigBee
available profiles include the Network Specific (stack identifier 0); Home Controls
(stack identifier 1); Building Automation (stack identifier 2) and Plant Control
(stack identifier 3).
S. Tennina et al., IEEE 802.15.4 and ZigBee as Enabling Technologies 3

for Low-Power Wireless Systems with Quality-of-Service Constraints, SpringerBriefs
in Cooperating Objects, DOI: 10.1007/978-3-642-37368-8_1, The Author(s) 2013
4 1 Snapshot of the IEEE 802.15.4 and ZigBee Protocols
Fig. 1.1 ZigBee architecture [1]
The ZigBee Network Layer (NWK) is responsible for Network management

procedures (e.g., nodes joining and leaving the network), security and routing. It
also encloses the neighbor tables and the storage of related information. The NWK
Layer provides one set of interfaces, the Network Layer Data Entity Service
Access Point (NLDE-SAP) used to exchange data with the APS.
IEEE 802.15.4/ZigBee devices can be classified according to their functional-
ities: Full Function Devices (FFD) implement the full IEEE 802.15.4/ZigBee
protocol stack; Reduced Function Devices (RFD) implement a subset of the
protocol stack. Regarding the devices role in the network, ZigBee defines 3 types
of devices:
• ZigBee Coordinator (ZC) or Gateway (GW): one for each ZigBee Network;
initiates and configures network formation; acts as an IEEE 802.15.4 Personal
Area Network (PAN) Coordinator; acts as ZigBee Router (ZR) once the network
is formed; is a Full Functional Device (FFD) implements the full protocol stack;
if the network is operating in beacon-enabled mode, the ZC will send periodic
beacon frames that will serve to synchronize the rest of the nodes. In a cluster-
tree network all ZR will receive beacon from their parents and send their own
beacons to synchronize nodes belonging to their clusters.
• ZigBee Router (ZR): participates in multi-hop routing of messages in mesh and
cluster-tree networks (in the latter case they are also called Cluster Heads
(CHs)); associates with ZC or with previously associated ZR in cluster-tree
topologies; acts as a local IEEE 802.15.4 PAN Coordinator; is a Full Functional
Device (FFD) implements the full protocol stack.
1.1 General Aspects 5
Fig. 1.2 ZigBee network topologies. a Star topology. b Mesh topology. c Cluster Tree topology
• ZigBee End Device (ZED) or simply Sensor Node (SN): does not allow other
devices to associate with it; does not participate in routing; it is just a sensor/
actuator node; can be a Reduced Function Device (RFD) implementing a
reduced subset of the protocol stack.
Throughout this book, the names of the devices and their acronyms are used
interchangeably. ZigBee/IEEE 802.15.4 enables three network topologies star,
mesh and cluster-tree (Fig. 1.2).
In the star topology (Fig. 1.2a), a unique node operates as a ZC. The ZC
chooses a PAN identifier, which must not be used by any other ZigBee network in
the vicinity. The communication paradigm of the star topology is centralized, i.e.,
each device (FFD or RFD) joining the network and willing to communicate with
other devices must send its data to the ZC, which dispatches it to the adequate
destination. The star topology may not be adequate for traditional Wireless Sensor
Networks (WSN) for two reasons. First, the sensor node selected as a ZC will get
its battery resources rapidly ruined. Second, the coverage of an IEEE 802.15.4/
ZigBee cluster is very limited while addressing a large-scale WSN, leading to a
scalability problem.
The mesh topology (Fig. 1.2b) also includes a ZC that identifies the entire
network. However, the communication paradigm in this topology is decentralized,
i.e., each node can directly communicate with any other node within its radio
Table 1.1 Major features of the star, mesh and cluster-tree network topologies
Star Mesh Cluster-Tree
Scalability No Yes Yes
Synchronization Yes (no) No Yes
Inactive period All nodes ZEDs All nodes
Guaranteed bandwidth Yes (GTS) No Yes (GTS)
Redundant paths N/A Yes No
Routing protocol overhead N/A Yes No
Commercially available Yes Yes No
range. The mesh topology enables enhanced networking flexibility, but it induces
additional complexity for providing end-to-end connectivity between all nodes in
the network. Basically, the mesh topology operates in an ad-hoc fashion and
allows multiple hops to route data from any node to any other node. In contrast
with the star topology, the mesh topology may be more power-efficient and the
battery resource usage is fairer, since the communication process does not rely on
one particular node.
The cluster-tree network topology (Fig. 1.2c) is a special case of a mesh net-
work where there is a single routing path between any pair of nodes and there is a
distributed synchronization mechanism (IEEE 802.15.4 beacon-enabled mode).
There is only one ZC which identifies the entire network and one ZR per cluster.
Any of the FFD can act as a ZR providing synchronization services to other
devices and ZRs.
Table 1.1 summarizes some of the differences between ZigBee mesh and
cluster-tree topologies.
The synchronization (beacon-enabled mode) feature of the cluster-tree model
may be seen both as an advantage and as a disadvantage, as reasoned next.
On one hand, synchronization enables dynamic duty-cycle management in a per
cluster basis, allowing nodes (ZEDs and ZRs) to save their energy by entering the
sleep mode. In contrast, in the mesh topology as defined in the IEEE 802.15.4
standard specification, only the ZEDs can have inactive periods. These energy
saving periods enable the extension of the network lifetime, which is one of the
most important requirements of WSNs. In addition, synchronization allows
the dynamic reservation of guaranteed bandwidth in a per-cluster basis, through
the allocation of Guaranteed Time Slots in the Superframe Contention Free Period
(CFP). This enables the worst-case dimensioning of cluster-tree ZigBee networks,
namely it is possible to compute worst-case message end-to-end delays and
ZigBee Router buffer requirements. On the other hand, managing the synchroni-
zation mechanism throughout the cluster-tree networks is a very challenging task.
Even if we can cope with minor synchronization drifts between ZRs, this problem
can grow for larger cluster-tree networks (higher depths). As previously men-
tioned, the de-synchronization of a cluster-tree network leads to collision problems
due to overlapping Beacons and Superframes. For instance, the CAP of one cluster
can overlap the CFP of another cluster, which is not admissible.
1.1 General Aspects 7
Regarding the routing protocols, the tree routing protocol in the cluster-tree is
lighter than the mesh routing protocol (AODV) in terms of memory and processing
requirements. The routing overhead, as compared with the AODV [2] in the mesh
topology, is reduced. Note that the tree routing protocol considers just one path
from any source to any destination, thus it does not consider redundant paths, in
contrast to AODV. Therefore, the tree routing protocol is prone to the single point
of failure problem, while that can be avoided in mesh networks if alternative
routing paths are available (more than one ZigBee Router within radio coverage).
Note that if there is a fault in a ZigBee Router, network inaccessibility times
may be inadmissible for applications with critical timing and reliability require-
ments. Therefore, designing and engineering energy and time-efficient fault-
tolerance mechanisms to avoid or at least minimize the single point of failure
problem in ZigBee Cluster-Tree networks is of crucial importance. Besides the
Beacon/Superframe scheduling and the single-point-of-failure problems, there are
other implementation-related obstacles that makes the use of the cluster-tree
topology a challenging task, such as: (1) the dynamic network resynchronization,
for instance in case of a new cluster joining or leaving the network; (2) the
dynamic rearrangement of the all the duty cycles in the case of a router failure;
(3) a new router association or even rearranging the superframe duration of some
routers to adapt the bandwidth allocated to that branch of the tree; (4) the rear-
rangement of the addressing space allocated to each router; and (5) supporting
mobility of nodes, routers or even hole clusters.
From a general perspective, all these impairments have lead to the lack of com-
mercial or academic solutions based on the ZigBee Cluster-Tree model. Neverthe-
less, we consider this model as a promising and adequate solution for WSN
applications with multiple Quality of Service (QoS) requirements, such as timeliness
and energy-efficiency, which triggered us to implement it and explore its potential.
1.2 IEEE 802.15.4
The IEEE 802.15.4 Full Function Devices (FFD) have three different operation
modes:
• The Personal Area Network (PAN) Coordinator: The principal controller of the
PAN. This device identifies its own network as well as its configurations, to
which other devices may be associated. In ZigBee, this device is referred to as
the ZigBee Coordinator (ZC).
• The local Coordinator: Provides synchronization services through the trans-
mission of beacons. This device should be associated to a PAN Coordinator or a
previously associated local Coordinator and does not create its own network. In
ZigBee, this device is referred to as the ZigBee Router (ZR).
• The End Device: A device which does not implement the previous functional-
ities and should associate with a ZC or ZR before interacting with the network.
In ZigBee, this device is referred to as the ZigBee End Device (ZED).
The Reduced Function Device (RFD) is an end device operating with the
minimal implementation of the IEEE 802.15.4. An RFD is intended for applica-
tions that are extremely simple, such as command a light switch or read from a
passive infrared sensor; they do not have the need to send large amounts of data
and may only associate with a single FFD at a time.
Throughout this book the IEEE 802.14.5 operational modes and the ZigBee
device names are used interchangeably (e.g., PAN Coordinator ¼ ZigBee Coor-
dinator, local Coordinator ¼ ZigBee Router (or Cluster Head) and End Device ¼
ZigBee End Device). The designation of Coordinator represents both ZC and ZRs.
1.2.1 Physical Layer
The IEEE 802.15.4 physical layer is responsible for data transmission and
reception using a certain radio channel and according to a specific modulation and
spreading technique.
The IEEE 802.15.4 offers three operational frequency bands: 2.4 GHz, 915 and
868 MHz (Fig. 1.3). There is a single channel between 868 and 868.6 MHz
(20 kbit/s), 10 channels between 902 and 928 MHz (40 kbit/s), and 16 channels
between 2.4 and 2.4835 GHz (250 kbit/s). The protocol also allows dynamic
channel selection, a channel scan function in search of a beacon, receiver energy
detection, link quality indication and channel switching. All of these frequency
bands are based on the Direct Sequence Spread Spectrum (DSSS) spreading
technique.
The physical layer of IEEE 802.15.4 is in charge of the following tasks:
• Activation and Deactivation of the Radio Transceiver. The radio transceiver
may operate in one of three states: transmitting, receiving or sleeping. Upon
request of the MAC sub-layer, the radio is turned ON or OFF. The turnaround
time from transmitting to receiving and vice versa should be no more than 12
symbol periods, according to the standard (each symbol corresponds to 4 bits).
Fig. 1.3 Operating frequencies and bands

1.2 IEEE 802.15.4 9
• Energy Detection (ED). Estimation of the received signal power within the
bandwidth of an IEEE 802.15.4 channel. This task does not make any signal
identification or decoding on the channel. The energy detection time should be
equal to 8 symbol periods. This measurement is typically used by the Network
Layer as a part of channel selection algorithm or for the purpose of Clear
Channel Assessment (CCA), to determine if the channel is busy or idle.
• Link Quality Indication (LQI). Measurement of the Strength/Quality of a
received packet. It measures the quality of a received signal. This measurement
may be implemented using receiver ED, a signal to noise estimation or a
combination of both techniques.
• Clear Channel Assessment (CCA). Evaluation of the medium activity state: busy
or idle. The CCA is performed in three operational modes: (1) Energy Detection
mode: The CCA reports a busy medium if the detected energy is above the ED
threshold. (2) Carrier Sense mode: The CCA reports a busy medium only is it
detects a signal with the modulation and the spreading characteristics of IEEE
802.15.4 and which may be higher or lower than the ED threshold. (3) Carrier
Sense with Energy Detection mode: This is a combination of the aforemen-
tioned techniques. The CCA reports that the medium is busy only if it detects a
signal with the modulation and the spreading characteristics of IEEE 802.15.4
and with energy above the ED threshold.
• Channel Frequency Selection. The IEEE 802.15.4 defines 27 different wireless
channels. Each network can support only part of the channel set. Hence, the
physical layer should be able to tune its transceiver into a specific channel when
requested by a higher layer.
1.2.2 Medium Access Control Sub-Layer
The Medium Access Control (MAC) protocol supports two operational modes
(Fig. 1.4):
• The non beacon-enabled mode. When the ZC selects the non-beacon enabled
mode, there are neither beacons nor superframes. Medium access is ruled by an
unslotted CSMA/CA mechanism.
• The beacon-enabled mode. In this mode, beacons are periodically sent by the
ZC or ZR to synchronize nodes that are associated with it, and to identify
Fig. 1.4 IEEE 802.15.4

operational modes
the PAN. A beacon frame delimits the beginning of a superframe defining a time
interval during which frames are exchanged between different nodes in the
PAN. Medium access is basically ruled by Slotted CSMA/CA. However,
the beacon-enabled mode also enables the allocation of contention free time
slots, called Guaranteed Time Slots (GTSs) for nodes requiring guaranteed
bandwidth.
1.2.2.1 Superframe Structure
The superframe is defined between two beacon frames and has an active period
and an inactive period. Figure 1.5 depicts the IEEE 802.15.4 superframe structure.
The active portion of the superframe structure is composed of three parts, the
Beacon, the Contention Access Period (CAP) and the Contention Free Period
(CFP):
• Beacon (BCN). The beacon frame is transmitted at the start of slot 0. It contains
the information on the addressing fields, the superframe specification, the GTS
fields, the pending address fields and other PAN related data.
• Contention Access Period (CAP). The CAP starts immediately after the beacon
frame and ends before the beginning of the CFP, if it exists. Otherwise, the CAP
ends at the end of the active part of the superframe. The minimum length of the
CAP is fixed to aMinCAPLength ¼ 440 symbols. This minimum length ensures
that MAC commands can still be transmitted when GTSs are being used.
A temporary violation of this minimum may be allowed if additional space is
needed to temporarily accommodate an increase in the beacon frame length,
needed to perform GTS management. All transmissions during the CAP are
Fig. 1.5 IEEE 802.15.4 superframe structure [3]

1.2 IEEE 802.15.4 11
made using the Slotted CSMA/CA mechanism. However, the acknowledgement

frames and any data that immediately follows the acknowledgement of a data
request command are transmitted without contention. If a transmission cannot
be completed before the end of the CAP, it must be deferred until the next
superframe.
• Contention Free Period (CFP). The CFP starts immediately after the end of the
CAP and must complete before the start of the next beacon frame (if BO equals
SO) or the end of the superframe. Transmissions are contention-free since they
use reserved time slots (GTS) that must be previously allocated by the ZC or the
Cluster Heads (i.e., the ZRs of each cluster). All the GTSs that may be allocated
by the Coordinator are located in the CFP and must occupy contiguous slots.
The CFP may therefore grow or shrink depending on the total length of all
GTSs.
In beacon-enabled mode, each Coordinator defines a superframe structure

(Fig. 1.5) which is constructed based on:
• The Beacon Interval (BI), which defines the time between two consecutive
beacon frames.
• The Superframe Duration (SD), which defines the active portion in the BI, and
is divided into 16 equally-sized time slots, during which frame transmissions are
allowed.
Optionally, an inactive period is defined if BI [ SD. During the inactive period

(if it exists), all nodes may enter in a sleep mode to save energy. BI and SD are
determined by two parameters, the Beacon Order (BO) and the Superframe Order
(SO), respectively, as follows:

BI ¼ aBaseSuperframeDuration 2BO
for 0 SO BO 14 ð1:1Þ
SD ¼ aBaseSuperframeDuration 2SO
aBaseSuperframeDuration ¼ 15:36 ms (assuming 250 kbps in the 2.4 GHz fre-
quency band) denotes the minimum duration of the superframe, corresponding to
SO ¼ 0.
As depicted in Fig. 1.5, low duty cycles can be configured by setting small
values of the SO as compared to BO, resulting in greater sleep (inactive) periods.
In ZigBee Cluster-Tree networks, each cluster can have different and dynamically
adaptable duty-cycles. This feature is particularly interesting for WSN applica-
tions, where energy consumption and network lifetime are main concerns.
Additionally, the Guaranteed Time Slot (GTS) mechanism is quite attractive for
time-sensitive WSNs, since it is possible to guarantee end-to-end message delay
bounds both in Star and Cluster-Tree topologies.
1.2.2.2 Association and Channel Scan Mechanisms
The association procedure takes place when a device wants to associate with a
Coordinator. This mechanism can be divided into three separate phases: (1)
channel scan procedure; (2) selection of a possible parent; (3) association with the
parent.
IEEE 802.15.4 enables four types of channel scan procedures: (1) the energy
detection scan, where the device obtains a measure of the peak energy in each
channel; (2) the active scan, where the device locates all Coordinators transmitting
beacon frames; this scan is performed on each channel by first transmitting a
beacon request command; (3) the passive scan, where similarly to the active scan,
the device locates all Coordinator transmitting beacon frames with the difference
that the scan is performed only in a receive mode, without transmitting beacon
requests; and (4) the orphan scan, used to locate the Coordinator with which the
scanning device had previously associated.
After the channel scan procedure is completed, the NWK layer receives a list of
all detected PAN descriptors (containing information about the potential parents).
Based on the information collected during the scan, the device can choose the most
suitable parent (that permits associations). The IEEE 802.15.4 protocol standard
leaves the way to take the association decision to the system designer. Never-
theless one of the most relevant parameters to be considered is the Link Quality
Indicator (LQI).
For a device to associate to a Coordinator, it must send an association com-
mand frame. Then, if the Coordinator accepts the device, it adds it to its neighbor
table as its child. An association response command frame is, in the case of a
successful association, sent to the device (through a mechanism called indirect
transmission, explained later in this chapter), embedding its short address.
Otherwise, in the case of an unsuccessful association, the association response
embeds the problem status information. The Coordinator replies to the association
command frame with an acknowledgment embedding the pending data control
flag active, meaning that it has data ready to be transmitted to the device. The
association procedure is completed when the device sends a data request com-
mand frame to the Coordinator requesting the pending data (the association
response command). After a successful association, the device stores all the
information about the new PAN by updating its MAC PAN Information Base
(MAC PIB) and can start transmissions.
The disassociation from a Coordinator is done via a disassociation request
command. The disassociation can be initiated either by the device or by the
Coordinator. After the disassociation procedure, the device loses its short address
and is not able to communicate. The Coordinator updates the list of associated
devices, but it can still keep the device information for a future re-association.
1.2 IEEE 802.15.4 13
1.2.2.3 Guaranteed Time Slot Mechanism
The Guaranteed Time Slot (GTS) mechanism allows devices to access the medium
without contention, in the CFP. GTSs are allocated by the Coordinator and are
used only for communications between the Coordinator and a device. Each GTS
may contain one or more time slots. The Coordinator may allocate up to seven
GTSs in the same superframe, provided that there is sufficient capacity in the
superframe. Each GTS has only one direction: From the device to the Coordinator
(transmit) or from the Coordinator to the device (receive). Figure 1.6 illustrates
message sequence diagram for a GTS allocation.
The GTS can be deallocated at any time at the discretion of the Coordinator or
the device that originally requested the GTS allocation. A device to which a GTS
has been allocated can also transmit during the CAP. The Coordinator is the
responsible for performing the GTS management; for each GTS, it stores the
starting slot, length, direction, and associated device address. All these parameters
are embedded in the GTS request command. Only one transmit and/or one receive
GTS are allowed for each device. Upon the reception of the deallocation request
the Coordinator updates the GTS descriptor list by removing the previous allocated
slot and rearranging the remaining allocation starting slots. The arrangement of the
CFP consists in shifting right the allocated GTS descriptors with starting slot
before the recent deallocated GTS descriptor and consequently the final CAP slot
variable is updated. Figure 1.7 illustrates an example of this procedure.
In Fig. 1.7, the 1st timeline represents the three allocated GTS. The 2nd
timeline shows the deallocation of GTS 2 that starts on the 10th time slot and has
duration of 4 time slots. The final timeline show GTS 3 shifted right by 4 time
slots. The first CTF time slot shifted right from slot 8 (in timeline 1) to slot 12 (in
timeline 3).
The Coordinators monitor GTS activity and if there are no transmissions during
a defined number of time slots the GTS allocation expires. The expiration occurs if
no data or no acknowledgement frames are received by the device or by the
Coordinator, on every 2n superframes, where n is defined as:
Fig. 1.6 GTS allocation message sequence diagram [3]

Fig. 1.7 CFP defragmentation upon a GTS deallocation [3]
(
n ¼ 2ð8macBeaconOrderÞ ; if 0 macBeaconOrder 8
ð1:2Þ
n ¼ 1; if 9 macBeaconOrder 14
1.2.2.4 CSMA/CA Mechanism
In IEEE 802.15.4, contention-based Medium Access Control (MAC) can be either

slotted or unslotted CSMA/CA, depending on the network operation behavior:
beacon-enabled or non beacon-enabled modes, respectively.
The CSMA/CA mechanism is based on backoff periods (with the duration of 20
symbols). Three variables are used to schedule medium access:
1.2 IEEE 802.15.4 15
Fig. 1.8 The slotted CSMA/CA mechanism [3]
• Number of Backoffs (NB), representing the number of failed attempts to access

the medium;
• Contention Window (CW), representing the number of backoff periods that must
be clear before starting transmission;
• Backoff Exponent (BE), enabling the computation of the number of wait
backoffs before attempting to access the medium again.
Figure 1.8 depicts a flowchart describing the slotted version of the CSMA/CA
mechanism. It can be summarized in five steps:
1. Initialization of the algorithm variables: NB equal to 0; CW equals to 2 and BE
is set to the minimum value between 2 and a MAC sub-layer constant
(macMinBE).
2. After locating a backoff boundary, the algorithm waits for a random defined
number of backoff periods before attempting to access the medium.
3. Clear Channel Assessment (CCA) to verify if the medium is idle or not.
4. The CCA returned a busy channel, thus NB is incremented by 1 and the
algorithm must start again in Step 2.
5. The CCA returned an idle channel, CW is decremented by 1 and when it
reaches 0 the message is transmitted, otherwise the algorithm jumps to Step 3.
In the slotted CSMA/CA, when the battery life extension is set to 0, the CSMA/
CA must ensure that, after the random backoff (step 2), the remaining operations
Fig. 1.9 The un-slotted CSMA/CA mechanism [3]
can be undertaken and the frame can be transmitted before the end of the CAP. If
the number of backoff periods is greater than the remaining in the CAP, the MAC
sub-layer pause the backoff countdown at the end of the CAP and defers it to the
start of the next superframe. If the number of backoff periods is less or equal than
the remaining number of backoff periods in the CAP, the MAC sub-layer applies
the backoff delay and re-evaluate whether it can proceed with the frame trans-
mission. If the MAC sub-layer do not have enough time, it defers until the start of
the next superframe, continuing with the two CCA evaluations (step 3). If the
battery life extension set to 1, the backoff countdown must only occur during the
first six full backoff periods, after the reception of the beacon, as the frame
transmission must start in one of these backoff periods.
The non slotted mode of the CSMA/CA (Fig. 1.9) is very similar to the slotted
version except the algorithm does not need to rerun (CW number of times) when
the channel is idle.
1.2.2.5 Inter-Frame Spacing
The Inter-Frame Spacing (IFS) is an idle communication period that is needed for
supporting the MAC sub-layer needs to process data received by the physical
layer. To allow this, all transmitted frames are followed by an IFS period. If the
transmission requires an acknowledgment, the IFS will follow the acknowledge-
ment frame. The length of the IFS period depends on the size of the transmitted
frame: A Long Inter-Frame Spacing (LIFS) or Short Inter-Frame Spacing (SIFS).
The selection of the IFS is based on the IEEE 802.15.4 aMaxSIFSFrameSize
parameter, defining the maximum allowed frame size to use the SIFS. The CSMA/
CA algorithm takes the IFS value into account for transmissions in the CAP. These
concepts are illustrated in Fig. 1.10.
1.2 IEEE 802.15.4 17
Fig. 1.10 Inter-frame spacing [3]
Fig. 1.11 Indirect transmission example. In the first beacon the coordinator informs the device of
the presence of a data packet. The device decodes this information and issues a data request. The
data packet is then sent by the coordinator to the device and the information of pending data is
removed from the beacon frames
1.2.2.6 Transmission Scenarios and Reception Conditions
The IEEE 802.15.4 protocol standard enables three different types of

transmissions:
1. Direct transmissions. The frames are transmitted to the medium without any
channel assessment i.e., the beacon frames, the acknowledgment frames and the
frames in the GTS time slots.
2. Indirect transmissions. The frames are stored in the Coordinator to which the
destination device is associated. Then, the information about the stored frames
(or pending transmissions) is included in the pending addresses descriptors
fields of the beacon frame. If a device has pending data in the Coordinator it can
request it by sending a data request command frame. An example of this
mechanism is depicted in Fig. 1.11 where the Coordinator beacon contains the
short address 0 0004 in the pending address list. In the Coordinator neighbor
table, the short address 0 0004 is associated to the extended address
0 0000000400000004. Then, the device 0 0004 requests the data with a
data request message embedding its extended address. The Coordinator sear-
ches in its neighbor tables for the short address corresponding to the extended
address received in the command frame and transmit the corresponding pending
data. In the next Coordinator beacon the pending address list is updated.
3. Normal transmissions. The frames are transmitted to the medium with con-
tention, by applying the CSMA/CA algorithm, i.e., data frames and command
frames transmitted during the CAP. Depending of the operation mode (beacon-
enabled or non beacon-enabled) the CSMA/CA algorithm has two versions, the
slotted or the unslotted respectively.
The IEEE 802.15.4 protocol standard identifies three different transmissions
scenarios during the CAP:
• Successful data transmission. The sender successfully transmits the frame to the
intended recipient. The recipient receives the frame and sends an acknowl-
edgment if required. If it is an acknowledged request, the sender starts a timer
that expires after macAckWaitDuration symbols. Upon the reception of the
acknowledge frame (before the timer expires), the sender disables and reset the
timer. The data transfer is completed successfully.
• Loss of frame. The sender successfully transmits the frame to the medium, but it
never reaches the destination, so that an acknowledgement frame is not trans-
mitted. The sender timer expires (after macAckWaitDuration) and the sender
retransmits the frame again. This procedure is repeated up to a maximum of
aMaxFrameRetries times after which the transmission aborts.
• Loss of acknowledgment. The sender successfully transmits the frame to the
intended recipient that upon reception replies with an acknowledgement frame.
The sender never receives the acknowledgment and retries the transmission.
The MAC sub-layer will only accept frames from the PHY layer if it satisfies
the following requirements:
• The frame type subfield of the frame control field does not contain an illegal
frame type.
• If the frame type indicates that the frame is a beacon frame, the source PAN
identifier must match macPANId, unless macPANId is equal to 0 FFFF, in
which case the beacon frame must be accepted regardless of the source PAN
identifier.
• If a destination PAN identifier is included in the frame, it must match
macPANId or the broadcast PAN identifier (0 FFFF).
• If a short destination address is included in the frame, it must match either
macShortAddress or the broadcast address (0 FFFF). Otherwise, if an extended
destination address is included in the frame, it must match aExtendedAddress.
• If only source addressing fields are included in a data or MAC command frame,
the frame is accepted only if the device is a Coordinator and the source PAN
identifier matches macPANId.
1.3 ZigBee 19
1.3 ZigBee
The ZigBee Network Layer is responsible for network management (e.g., asso-
ciation/disassociation, starting the network, addressing, device configuration and
the maintenance of the NIB-NWK Information Base) and formation, message
routing and security-related services.
The ZigBee Network Layer supports two service entities. The Network Layer
Data Entity (NLDE) provides a data service, allowing the transmission of data
frames and topology specific routing. Figure 1.12 depicts the Network Layer
reference model.
Joining and leaving a network must be supported by all ZigBee Devices. Both
ZigBee Coordinators and Routers must support the following additional
functionalities:
• Permit devices to join the network using the following:
– Association indications from the MAC sub-layer.
– Explicit join requests from the application.
• Permit devices to leave the network using the following:
– Network Leave command frames.
– Explicit leave requests from the application.
• Participate in assignment of logical network addresses.
• Maintain a list of neighboring devices.
The ZigBee Coordinator also defines some important additional network
parameters. It determines the maximum number of children (Cm ) any device is
allowed to have. From this set of children, a maximum number (Rm ) of devices can
be router-capable devices. The remaining are ZEDs (Cm Rm ). Every device has
an associated depth, representing the number of hops a transmitted frame must
travel, using only a parent-child links, to reach the ZigBee Coordinator. By
default, the ZC is assumed to have a depth of 0, while its direct children have a
Fig. 1.12 Network layer

reference model [1]
depth of 1. The ZC also determines the maximum depth (Lm ) of the network. The
maximum number of children, routers and network depth are used for calculating
the addresses of the devices in the network, in a fully distributed addressing
scheme.
1.3.1 Short Address Assignment
A parent device uses the Cm , Rm and Lm values to compute a Cskip function

defining the size of the address sub-block that is distributed by each parent
depending on its depth (d) in the network. For a given network depth d, CskipðdÞ is
calculated as follows:
(
1 þ Cm ðLm d 1Þ if Rm ¼ 1;
CskipðdÞ ¼ Lm d1
1þCm Rm Cm Rm ð1:3Þ
1Rm Otherwise.
A parent device that has a CskipðdÞ value of zero is not capable of accepting
children and must be treated as an end device. A parent device that has a CskipðdÞ
value greater than zero must accept devices and assigns addresses, if possible.
A parent device assigns an address that is one greater than its own to the first router
that associated. The next associated router receives an address that is separated
according to the return value of the Cskipðparent0 s depthÞ function. The maximum
number of associated routers is defined in the network parameter nwkMaxRouters.
Considering a parent node with a depth d and an address of Aparent , the number
of child devices n is between 1 and Cm Rm .
1 n ðCm Rm Þ: ð1:4Þ
The Achild address of the n-th child router is calculated according to Eq. (1.5a,
b) (n is the number of child routers):
Achild ¼ Aparent þ ðn 1Þ CskipðdÞ þ 1; n¼1 ð1:5aÞ
Achild ¼ Aparent þ ðn 1Þ CskipðdÞ; n [ 1: ð1:5bÞ

The Achild address of the n-th child end device is calculated according to
Eq. (1.6) (n is the number of child end devices):
Achild ¼ Aparent þ Rm CskipðdÞ þ n: ð1:6Þ

Figure 1.13 depicts an example of an address assignment scheme. The
parameters used in the address assignment are the following: maximum depth
ðLm Þ ¼ 3, maximum children ðCm Þ ¼ 6 and maximum routers ðRm Þ ¼ 4.
1.3 ZigBee 21
Fig. 1.13 Cskip-based address assignment scheme example
1.3.2 ZigBee Routing
ZigBee Coordinators and Routers must provide the following functionalities:

(i) relay data frames on behalf of higher layers; (ii) relay data frames on behalf of
other ZR; (iii) participate in route discovery in order to establish routes for
subsequent data frames; (iv) participate in route discovery on behalf of end
devices; (v) participate in end-to-end route repair; (vi) participate in local route
repair, and (vii) employ the ZigBee path cost metric as specified in route discovery
and route repair.
Additionally, ZigBee Coordinators and Routers may provide the following
functionalities: (i) maintain routing tables in order to remember best available
routes; (ii) initiate route discovery on behalf of higher layers; (iii) initiate route
discovery on behalf of other ZR; (iv) initiate end-to-end route repair, and
(v) initiate local route repair on behalf of other ZR.
1.3.3 Routing Schemes
ZigBee Coordinators and Routers support three types of routing:

• Neighbor Routing based on a neighbor tables that contains the information of all
the devices within radio coverage. If the target device is physically in range the
message can be sent directly. Note that ZEDs cannot do this.
• Table Routing—Ad-hoc On Demand Distance Vector (AODV) [2], based on
routing and route discovery tables with the path cost metrics.
• Tree-Routing—based on the address assignment schemes; messages are hier-
archically routed upstream/downstream the tree.
Neighbor Routing. This type of routing uses the neighbor tables. If the target
device is physically in range it is possible to send messages directly to the des-
tination. Physically in range means that the source ZC or ZR has a neighbor table
entry for the destination. This routing mechanism is mostly used as addition to
other routing mechanisms and for the ZigBee Routers to route messages to its
children devices, when they are the destination.
Table Routing—Ad-hoc On-Demand Distance Vector (AODV). ZigBee
Table Routing is based on the AODV routing algorithms. Each ZigBee Coordi-
nator and Router that supports this Table Routing must maintain two tables: (1) the
routing table, a long-lived and persistent table with the information of routes, and
(2) a route discovery table with the information of the route discovery procedures
where each entry only lasts the duration of the discovery.
The Ad-hoc On Demand Distance Vector (AODV) [2] routing protocol was
designed for ad hoc mobile networks. AODV is capable of both unicast and
multicast routing. AODV allows mobile nodes to obtain routes quickly for new
destinations, and does not require nodes to maintain routes to destinations that are
not in active communication. AODV allows mobile nodes to respond to link
breakages and changes in network topology in a timely manner. The operation of
AODV is loop-free, and by avoiding the Bellman-Ford counting to infinity prob-
lem offers quick convergence when the ad-hoc network topology changes (typi-
cally, when a node moves in the network). When the link breaks, AODV causes
the affected set of nodes to be notified so that they are able to invalidate the routes
using the lost link. It is an on demand algorithm, meaning that it builds routes
between nodes only if requested by source nodes. It maintains these routes as long
as they are needed by the sources. Additionally, AODV can form trees, connecting
multicast groups, composed of the group members and the nodes needed to con-
nect. AODV uses sequence numbers to ensure the freshness of routes. It is loop-
free, self-starting, and scales to larger numbers of nodes.
In ZigBee Networks, the routing management is done by the means of NWK
command frames. The available commands are the following:
• Route request Command send to search for a route to a specified device, can also
be used to repair a route.
• Route reply Command send in response of a route request, also used to request
state information.
• Route Error notification of a source device of the data frame about the failure in
forwarding the frame.
• Leave notification of a device leaving the network.
• Route Record notification of a list of nodes used in relaying a data frame.
• Rejoin request notification of a device rejoining the network.
• Rejoin response rejoin response of a rejoin request.
The route choice for a communication flow is based on the total link cost
represented by C, meaning that the path with the lowest cost is chosen. The total
link cost is the sum of individual point-to-point link cost. The calculation of C is as
follows: for a defined path P, where L defines the length of a set of devices
[D1 ; D2 ; DL ] and a link [Di ; Diþ1 ] the path cost C is defined as:
1.3 ZigBee 23
X
L1
C fP g ¼ C f½D1 ; Diþ1 g: ð1:7Þ
i¼1
Each C f½D1 ; Diþ1 g is the individual point-to-point link cost, calculated by the
following formulation:
(
7
Cð1Þ ¼ ð1:8Þ
min 7; round p14
l
where pl is defined as the probability of packet delivery through link l.

The link probability estimation factors are implementation specific, but generally
they are based on the counting of the received beacons and data frames in order to
detect packet loss and in the estimation of the Link Quality Indicator (LQI).
Tree-Routing. This routing mechanism is based on the short addressing
scheme and was initially proposed by MOTOROLA [4]. Each device, upon the
reception of a data frame, reads the routing information fields and checks the
destination address. If the destination is a child of the device (neighbor table
check), the device relays the packet to the appropriate address. If the destination
address is not a child, the device must check if the address is a descendant using
the condition in Eq. (1.9), where A is device network address, D the destination
address and d the device depth in the network.
A\D\A þ Cskipðd 1Þ: ð1:9Þ
The next hop (N) address when routing down is given by:

D ðA þ 1Þ
N ¼Aþ1þ CskipðdÞ: ð1:10Þ
CskipðdÞ
If the destination address is not a descendant, the device relays the packet to its
parent.
1.4 Problems, Gaps and Open Issues
The current IEEE 802.15.4/ZigBee specifications restrict the synchronization in

the beacon-enabled mode to star-based networks, while it supports multi-hop
networking using the peer-to-peer mesh topology, but with no synchronization.
Even though both specifications mention the possible use of cluster-tree topolo-
gies, which combine multihop and synchronization features, the description on
how to effectively construct such a network topology is missing.
The beacon-enabled mode of the IEEE 802.15.4/ZigBee protocol standards
suffer from lack of scalability since, inherently to its operational behavior, it is
limited to star based networks. In the star topology the ZigBee Coordinator is a
central node that periodically transmits beacons for synchronizing the nodes in its
vicinity and centralizes all the communication (data exchange between nodes must
be relayed by the ZigBee Coordinator). As a consequence, the network coverage is
limited to the transmission range of the ZigBee Coordinator, which restricts the
geographical region under monitoring/control and thus maybe particularly
unsuitable for WSNs. Therefore, there is a tradeoff between supporting scalability
(at the cost of more energy consumption and less delay guarantees, like mesh-
based networks offer) and achieve real-time and energy-efficient communications
(like star-based networks offer). It would be more appropriate if both features
(synchronization and scalability) could be simultaneously supported into the same
network.
The Cluster-Tree network concept is outlined in the ZigBee specification.
However, in the IEEE 802.15.4/ZigBee standards there is not a clear description
on how the cluster-tree model can be implemented. The available information
regarding this topology gives a broad overview on how the cluster-tree network
should operate. More specifically, the cluster-tree model includes more than one
ZigBee Router that periodically generate beacons to synchronize nodes (or clusters
of nodes) in their neighborhood. If these periodic beacon frames are sent in an
unorganized fashion, without any particular schedule, they will collide with each
other or with other frames. These collisions results in the loss of synchronization
between a parent ZigBee Router and their child devices, which prevents them to
communicate. Therefore, beacon frame scheduling mechanisms must be defined to
avoid beacon frame collisions in ZigBee cluster-tree networks.
Only some basic approaches dealing with this problem were proposed for
discussion by the Task Group 15.4b [5], which is a group aiming to improve some
inconsistencies of the original specification. However, no algorithms for providing
collision-free beacon frame generation have been proposed in the standard so far.
In this book, the goal is to show first an implementation of the IEEE
802.15.4/ZigBee standard in nesC/TinyOS [6], whose code is publicly available for
download [7], especially focusing on the cluster tree model at the NWK layer on top
of the Beacon Enabled mode at the MAC layer. Then, this baseline enables WSN
networking with Quality of Service and scalability, achieved by mean of amend-
ments to the standard, proposed in previous work and described in the second part of
this book along with some tools to help engineering these networks and forecast
performance estimations. Finally, an overview of some example application
domains where the solutions proposed are in place is given at the end of this book.
References
1. ZigBee Alliance, ZigBee document 053474r17, ZigBee specification, http://www.zigbee.org.

Accessed January 2008
2. C.E. Perkins, E.M. Royer, Ad-hoc on-demand distance vector routing, in IEEE Workshop on
Mobile Computing Systems and Applications (1999), p. 90
3. Institute of Electrical and Electronics Engineers, Inc., IEEE Std. 802.15.4-2006, in IEEE
Standard for Information Technology: Telecommunications and Information Exchange
References 25
Between Systems—Local and Metropolitan Area Networks—Specific Requirements Part15.4:

Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-
Rate Wireless Personal Area Networks (WPANs), New York, September 2006
4. E. Callaway, Mac proposal for the low rate 802.15.4 standard. Technical report, Motorola
(2001)
5. IEEE 802.15 wpan task group 4 (tg4) (2012), http://grouper.ieee.org/groups/802/15/pub/
TG4.html. Accessed August 2012
6. Tinyos working group (2010), http://www.tinyos.net.
7. Main development repository for TinyOS May (2013), https://github.com/tinyos/tinyos-main
Chapter 2
Protocol Implementations
Abstract The first part of this chapter provides an overview of an open source
IEEE 802.15.4-2006 MAC implementation for the TinyOS 2 operating system.
It discusses the design challenges, describes the functional decomposition of the
implementation and explains what steps were necessary for the implementation to
meet TinyOS 2 requirements. In the second part of the chapter a similar overview
of the ZigBee Cluster Tree Network Layer implementation in TinyOS 2 is given.
Particular emphasis is put on describing how a tree-based network is formed
through the available child-parent association mechanisms, and the routing of
data packets which exploits the addressing scheme to achieve routing in a single-
line-of-code.
2.1 IEEE 802.15.4 MAC Implementation in TinyOS 2
This section gives an overview of an open source IEEE 802.15.4-2006 MAC

implementation for the TinyOS 2 operating system. The implementation is part of
the TinyOS 2 operating system core and can be accessed via the project source
code [1, $TOSROOT/tos/lib/mac]. It covers the MAC functions and includes the
interfaces towards the layer above (e.g. network layer) and below (radio driver).
The design and implementation of the radio driver (PHY), however, is platform/
chip specific and thus not part of the implementation. Although the functional
decomposition is independent of a specific operating system, in this section we use
nesC [2] syntax and refer to existing TinyOS 2 library components. The following
description is based on a technical report [3], additional information on the
implementation can be found in [4].

in Cooperating Objects, DOI: 10.1007/978-3-642-37368-8_2, Ó The Author(s) 2013
28 2 Protocol Implementations
2.1.1 TinyOS 2
TinyOS [5] is an operating system for wireless embedded sensor networks. It

consists of a set of components and the nesC language [2] allows to combine these
components to create an application. TinyOS 2 [6] is the second generation of the
operating system that keeps many of the basic ideas of its popular predecessor
while pushing the design in several key areas.
TinyOS 2 improves system reliability and robustness by redefining some of the
basic TinyOS 1.x abstractions and policies such as initialization, the task queue,
resource arbitration and power management. For example, in TinyOS 2, every task
has its own reserved slot in the task queue and can be posted only once. These
semantics lead to greatly simplified code (no need for task reposting on error) and
more robust components. The same principle of compile-time allocation and
binding is applied to many other aspects of the system: components allocate all of
the state they might possibly need; and the invariants are explicitly reflected by the
components and their interfaces, rather then being checked at runtime. This design
principle limits the flexibility, but makes many OS behaviors deterministic.
TinyOS 2 supports code reusability and portability in several ways. It is based
on a nesC version that uses the concept of generic components, which, similar to
object-oriented programming, can be used to create multiple component instances,
but instantiated at compile-time. It also supports network types at the language
level: programs can declare data structures and primitive types that follow a cross-
platform (1-byte aligned, big- or little-endian) layout and encoding. This allows
services to specify platform independent packet formats without resorting to
macros or explicit serialization. Finally, it uses a three-layer Hardware Abstraction
Architecture (HAA) [7] that decomposes the functionality of an individual sub-
system, for example timers, into three distinct layers. The HAA achieves code
portability through platform independent interfaces at the top layer, but at the same
time allows the applications to access a subsystem’s full capabilities through the
chip-specific second layer, if performance requirements outweigh the need for
portability.
There are two main TinyOS-specific challenges for a platform independent
802.15.4 MAC implementation: first, TinyOS is not a real-time operating system,
yet in beacon-enabled mode some operations need to be accurately timed.
TKN15.4 solves this problem by pushing most time-critical operations from the
MAC to the chip-specific radio drivers, because the drivers typically operate in a
asynchronous (interrupt) context and may better exploit the particular hardware
characteristics, for example hardware-generated acknowledgements.
Second, TinyOS 2 MAC protocols are traditionally implemented for a partic-
ular radio chip. TinyOS provides the Active Message layer to multiplex access to
the radio above the link layer, but there exist no hardware abstractions for the
lower layers. Since there are no established interfaces or guidelines in TinyOS 2 on
how the radio hardware should be exposed or how MAC protocols are to be
structured, one contribution of this work is the proposal of a set of platform
2.1 IEEE 802.15.4 MAC Implementation in TinyOS 2 29
independent radio interfaces to be provided by a 802.15.4-compliant radio chip

abstraction in TinyOS 2 (Sect. 2.1.4).
2.1.2 MAC Decomposition
Figure 2.1 shows an architectural overview of the implementation, its main

components and the interfaces that are used to exchange MAC frames between
components. While this figure abstracts from the majority of interfaces and some
configuration components, it illustrates one important aspect, namely how access
to the platform specific radio driver (PHY) is structured. For the purpose of
explanation, the MAC can be subdivided into three sub-layers.
On the lowest level (dark gray boxes), the RadioControlP component manages
the access to the radio: with the help of an extended TinyOS 2 arbiter component it
controls which of the components on the level above is allowed to access the radio
at what point in time.
The use of a TinyOS resource arbiter avoids inconsistencies in the radio driver
state machine and is in line with the standard TinyOS 2 resource usage model:
before a component may access a resource it must first issue a request; once it is
MLME-SAP MCPS-SAP
TKN154[Non]BeaconEnabledP
Coord-
DataP AssociateP DisassociateP IndirectTxP PollP PibP
RealignmentP
FrameTx
FrameRx
Coord-
Dispatch- BroadcastP
QueueP
Beacon- Beacon- Dispatch[Un] Coord/ Inactive-

ScanP RxEnableP
TransmitP SynchronizeP SlottedCsmaP DeviceCfpP PeriodP
Resource Promiscuous-
Radio[Tx/Rx/Off] ModeP
SimpleTransfer-
RadioControlP
ArbiterP
RadioTx RadioRx RadioOff EnergyDetection

Alarm / Timer
Radio Driver / PHY Symbol Clock
Fig. 2.1 The MAC architecture: Components are represented by rounded boxes, interfaces by
connection lines. The radio driver and symbol clock components are external to this architecture
signaled the granted() event by the arbiter the component can use the resource
exclusively; and after usage the resource must be released.1 The implementation
extends this model by allowing a component that owns the radio resource to
dynamically transfer the ownership to a specific other component. This is
explained in Sect. 2.1.3.
Most of the components on the second level (medium gray boxes) represent the
different time intervals in an 802.15.4 superframe: the BeaconTransmitP and
BeaconSynchronizeP components are responsible for transmission/reception of the
beacon frame, the DispatchSlottedCsmaP component manages frame transmission
and reception during the CAP and the CoordCfpP and DeviceCfpP components are
responsible for the CFP. In nonbeacon-enabled mode a superframe structure is not
used and these components are replaced by the DispatchUnslottedCsmaP com-
ponent, which is then responsible for frame transmission and reception in non-
beacon-enabled mode.
The CSMA-CA algorithm requires one (unslotted) or two (slotted) clear
channel assessments (CCA) to be performed one/two back-off slot boundaries
before the actual transmission. Moreover, in case of a CCA failure the transmis-
sion has to be delayed for a random time period of 0–255 back-off periods (equals
0–5100 ls in the 2.4 GHz band). The transmission of an acknowledgements must
start between 12 symbols (equals 192 ls in the 2.4 GHz band) and 32 symbols
(512 ls in the 2.4 GHz band) after the reception of the last symbol of the previous
data or MAC command frame. Since on a typical mote platform, these require-
ments can practically not be met by a platform independent MAC protocol [8],
rather they should be pushed from the MAC to the PHY, ideally to hardware. For
these reasons, the implementation does not include the (un)slotted CSMA-CA
algorithm: the DispatchSlottedCsmaP and DispatchUnslottedCsmaP components
are responsible for the initialization of the CSMA-CA parameters, but the algo-
rithm is implemented and executed in the platform specific radio driver
(Sect. 2.1.4.2). In either beacon- or non-beacon-enabled mode the ScanP and
PromiscuousModeP components are providing services for channel scanning and
enabling/disabling promiscuous mode, respectively. The radio arbitration mecha-
nism is used to coordinate the activities of the components on this level so that
they do not overlap in time: typically a component is active only while it has
exclusive access to the radio resource. It then performs a certain task (e.g.,
transmission of a beacon or performing a channel scan) and afterward either
releases the resource or passes it on to some other component. This mechanism
avoids race conditions when accessing the radio hardware and is detailed in
Sect. 2.1.3.
The components on the top level (white boxes) implement the remaining MAC
data and management services, for example, PAN association or requesting
(polling) data from a coordinator. These services typically utilize data and command
frame transmission/reception based on the (un)slotted CSMA-CA algorithm and
1
https://github.com/tinyos/tinyos-main/blob/master/doc/txt/tep108.txt.
consequently the components are wired via a send queue, DispatchQueueP, to either
DispatchSlottedCsmaP (in beacon-enabled PANs) or DispatchUnslottedCsmaP
(in nonbeacon-enabled PANs). A component on this level typically provides a
certain MAC MLME/MCPS primitive to the next higher layer, it is responsible for
assembling the particular data or command frame and it accepts and processes
incoming frames of the same type. For example, the DataP component provides the
MCPS-DATA primitive to the next higher layer to send a frame to a peer device. On
receipt of the MCPS-DATA.request primitive DataP will assemble the data frame
and enqueue it in the send queue DispatchQueueP. The Dispatch[Un]SlottedCsmaP
component will eventually dequeue the frame, and manage its transmission, e.g.
whenever the CAP has become active. Afterwards, it will signal a completion event
to the DataP component, which in turn propagates a MCPS-DATA.confirm event
back to the next higher layer including an appropriate status code that denotes
whether the transmission was successful or not.
The next higher layer accesses all MAC services either via the TKN154Beac-
onEnabledP component (in beacon-enabled PANs) or via the TKN154NonBeac-
onEnabledP component (in non-beacon-enabled PANs). These configuration
components are nesC facades [2] responsible for wiring the MAC components
together, respectively. They allow to disable/remove certain MAC functionality by
specifying empty placeholder [2] components. Table 2.1 lists all MAC compo-
nents together with the provided MCPS/MLME primitives.
2.1.3 Radio Arbitration in Beacon-Enabled PANs
The implementation includes a radio arbitration component (SimpleTransferAr-

biterP). With the help of this arbiter the RadioControlP component decides which
component may access the radio at what time. Resource arbiters are part of the
TinyOS 2 library and explained in TEP 108.2
Two properties make the standard arbiters suboptimal for the implementation
when used in beacon-enabled PANs: (1) the transition of the resource ownership
from one component to another may take an arbitrary time, because it typically
involves posting a task (the Resource.granted() event is signaled in a separate task)
and (2) the resource arbitration model is based on the assumption that clients are
relatively independent of each other and arbitration is based on a fixed queuing
policy (e.g., round robin or first-come-first-serve).
The first is suboptimal, because a superframe is represented by multiple com-
ponents and as there is a continuous transition between the different parts of a
superframe in time the access to the radio should be transferred immediately
between the involved components. For example, on a coordinator node immedi-
ately after a beacon has been transmitted the radio should be switched to receive
2
Table 2.1 The components of the MAC implementation and the provided interfaces
Component Name function [Provided IEEE 802.15.4 Interface]
AssociateP PAN association
[MLME-ASSOCIATE,MLME-COMM-STATUS]
DisassociateP PAN disassociation
[MLME-DISASSOCIATE,MLME-COMM-STATUS]
BeaconTransmitP periodic beacon transmission
[MLME-START]
BeaconSynchronizeP periodic beacon tracking
[MLME-SYNC(-LOSS), MLME-BEACON-NOTIFY]
CoordBroadcastP transmission of coordinator broadcast frames
CoordCfpP GTS management on coordinator
[MLME-GTS]
CoordRealignmentP management of realignment commands
[MLME-ORPHAN, MLME-COMM-STATUS]
DataP assembling/dispatching data frames
[MCPS-DATA, MCPS-PURGE]
DeviceCfpP GTS management on device
[MLME-GTS]
DisassociateP PAN disassociation
[MLME-DISASSOCIATE]
DispatchQueueP send queue for data/command frames
DispatchSlottedCsmaP frame transmission/reception during CAP
(excluding the CSMA-CA algorithm)
DispatchUnslottedCsmaP frame transmission/reception in nonbeacon-enabled PANs
(excluding the CSMA-CA algorithm)
IndirectTxP managing indirect transmissions
PibP maintaining the PAN Information Base
[MLME-RESET, MLME-GET, MLME-SET]
PollP requesting data from a coordinator
[MLME-POLL]
PromiscuousModeP enabling/disabling promiscuous mode
RadioClientC virtualizing access to RadioControlP
RadioControlImplP access control to the radio
RadioControlP configuration for RadioControlImplP
RxEnableP enabling the receiver during idle time
[MLME-RX-ENABLE]
ScanP channel scanning
[MLME-SCAN]
SimpleTransferArbiterP radio resource arbitration
TKN154BeaconEnabledP MAC configuration when used
in a beacon-enabled PAN
TKN154NonBeaconEnabledP MAC configuration when used
in a non-beacon-enabled PAN
mode. If the component responsible for managing the CAP is granted the access to
the radio too late (because there are other tasks served before), then incoming
frames may be lost.
The second is suboptimal, because a superframe is dynamic and some parts of it
are dependent on others. For example, a beacon defines whether the following CFP
is present and missing an incoming beacon means that the entire superframe
cannot be used. Consequently the components that represent the superframe should
be able to decide cooperatively at what time which of them should be active.
Instead of treating them as independent clients that compete for access to the radio,
it is more natural to let them coordinate when and in what order they access the
radio. Therefore we extend the standard Resource interface by a single command
and a single event that enables immediate transfer of the resource from one client
to another. The transfer does not involve posting a separate task and may override
the default queuing policy. This extended interface is called TransferableRe-
source, it is shown in Fig. 2.2.
In the following we call the radio resource the radio token, because a token
better matches the notion of transferability. Figure 2.3 shows an example of how
the radio token is shared between the components responsible for an incoming
superframe: as long as the next higher layer has requested synchronization with the
coordinator, the BeaconSynchronizeP component will always have a request
pending for the radio token (1). After it has been granted the radio token (2) it will
try to track the beacon from the coordinator. Once the beacon has been received,
the radio token will immediately be transferred to the DispatchSlottedCsmaP
component (3), which is then responsible for managing the CAP. When the CAP
has finished the radio token is transferred to the component responsible for the
CFP (4). Finally, at the end of the CFP the token is passed back to BeaconSyn-
chronizeP (5) to be able to receive the next beacon. Afterward, as long as no other
components request the radio token, the steps (3)–(5) repeat indefinitely.
Only the component that owns the radio token may access the radio and
whenever a component does not own the token, it is typically inactive: it may
accept requests from the next higher layer, but it will typically have to wait until it
is transferred/granted the token before it can serve the requests. A component
owning the radio token must make sure that it gives up the token at latest when the
interface TransferableResource {
async command error t request();
async command error t immediateRequest();
event void granted();
async command error t release();
async command bool isOwner();
async command error t transferTo(uint8 t dstClient);
async event void transferredFrom(uint8 t srcClient);
}
Fig. 2.2 The TransferableResource interface extends the standard Resource interface
by an additional command transferTo() and an event transferredFrom() to transfer the
ownership of the resource from one client to another
5. transferTo()
3. transferTo() 4. transferTo()
Beacon- Dispatch
DeviceCfpP
SynchronizeP SlottedCsmaP
1. request()
Radio[Tx/Rx/Off]
2. granted()
[Un]SlottedCsmaCa
SimpleTransfer-
RadioControlP
ArbiterP
Fig. 2.3 Transferring the radio token between the components responsible for an incoming
superframe. The commands request(), transferTo() and the granted() event are part of the
TransferableResource interface
corresponding part of the superframe has finished (cf. Fig. 1.5). For example,
whenever the DispatchSlottedCsmaP component is given the token from the Be-
aconSynchronizeP component, it will first set an Alarm to expire at the end of the
CAP (less a platform specific guard time). And when this Alarm expires, it will
transfer the token to the component responsible for the CFP.
As shown in Figure 2.4 other components can also request the radio token from
the arbiter. Through interfaces not shown here a client of the arbiter can always
check, whether other clients have requested the token and then release it. For
example, whenever the PipB component requests the token to serve a MLME-
RESET request from the next higher layer, then the components responsible for the
superframe will always give up the token via the TransferableResource.release()
command. When a token is released the arbiter will allocate it to the next client
based on a round-robin policy. Figure 2.4 shows all possible transitions of the
radio token from one component to another.
In a nonbeacon-enabled PAN a superframe structure is not used and the radio
token is never transferred between components. Instead components request it
(via TransferableResource.request()) and release it (via TransferableResource.
release()) according to the standard TinyOS resource arbitration policy.3
3
Coord- Dispatch Dispatch

BroadcastP SlottedCsmaP SlottedCsmaP
Beacon- Beacon- Promiscuous-

CoordCfpP DeviceCfpP ScanP
TransmitP SynchronizeP ModeP
SimpleTransfer-
RadioControlP
ArbiterP
request() and granted() release() transferTo()
Fig. 2.4 Resource arbitration in a beacon-enabled PAN: Components that never actively request
the radio token are shown in white boxes; components that may request the token are shown in
medium gray color. The commands request(), transferTo(), release() and the granted() event are
part of the TransferableResource interface
2.1.4 Interface Definitions
The 802.15.4-2006 standard specifies 17 MAC and 6 PHY primitives. The

implementation slightly adapts the MAC primitives to better match TinyOS 2
design principles; this is explained in Sect. 2.1.4.1. To better meet the tight timing
constraints in the beacon-enabled mode (c.f. Sect. 2.1.2) the PHY (radio driver)
interfaces are modified; these modifications are explained in Sect. 2.1.4.2.
2.1.4.1 Interfaces Towards the Next Higher Layer
TinyOS 2 does not support dynamic memory allocation, instead most allocation
and binding is pushed to compile time, which makes code more robust and pre-
dictable. This also holds for the allocation of message buffers: a component that
wants to send a packet is responsible for allocating a message_t buffer, which is
the TinyOS 2.x message buffer abstraction that is used by protocols on network
layer and above (cf. TEP 111).4 Consequently the implementation adapts the MAC
primitives to support message_t and the TinyOS buffer swapping semantics. This
is relevant for two MAC primitives, MCPS-DATA and MLME-BEACON-NOTIFY;
Fig. 2.5 shows the revised interface definitions.
In contrast to the primitives specified in the 802.15.4 standard, these interfaces
do not transport control information (source/destination address of the frame, etc.)
explicitly. Rather, this information is already contained in a message_t and can be
4
interface MCPS DATA {

commandieee154 status trequest (message t *frame,uint8 tpayloadLen,
uint8 tmsduHandle,uint8 ttxOptions);
eventvoidconfirm(message t *frame,uint8 t msduHandle,
ieee154 status tstatus,uint32 t timestamp);
eventmessage t* indication(message t* frame );
}
interface MLME BEACON NOTIFY {
eventmessage t* indication(message t *beaconFrame);
}
Fig. 2.5 The MCPS_DATA and MLME_BEACON_NOTIFY primitives are adapted to support
message_t and buffer swapping
configured/retrieved via suitable accessory functions (via the IEEE154Frame

interface, not shown here), which is in line with the TinyOS 2 concept of treating
message_t as abstract data type. A drawback of using message_t, however, is that a
message buffer always consumes the maximum MAC payload plus header size,
which frequently results in suboptimal memory usage. It is part of a future work to
design a more flexible message buffer abstraction for TinyOS 2.
All other MLME/MCPS primitives are adopted one-to-one from the 802.15.4
specification, with one exception: because it is usually more convenient for the
caller the MLME GET/SET primitives consist of single commands (are non-split-
phase), and the beacon payload for an outgoing superframe on a coordinator is
accessed not via PIB, but through a separate interface (IEEE154TxBeaconPayload
interface, not shown here).
2.1.4.2 Interfaces Towards the Radio Driver
The MAC requires the radio driver to provide the six interfaces shown in Fig. 2.6.
These interfaces push many time-critical operations from the MAC to the radio
driver, because the latter can include platform- and chip-specific code and is thus
in a better position to meet the tight timing constraints in beacon-enabled PANs
(cf. Sect. 2.1.2).
The RadioRx, RadioTx interfaces enable receive mode and allow the MAC to
transmit a frame at a specific point in time, respectively. The RadioOff interface
allows to disable the transceiver and the SlottedCsmaCa, UnslottedCsmaCa
interfaces transmit a frame based on the (un)slotted CSMA-CA algorithm. The
MAC specifies the initial CSMA-CA parameters but the algorithm itself is
implemented and executed in the radio driver. Also, the radio driver is responsible
for performing any random back-offs and for the transmission of acknowledge-
ments. The EnergyDetection interface is similar to the one defined in the standard.
It allows to obtain the maximum energy on a given channel over a certain time
period.
interface RadioRx {
async command error t enableRx(uint32 t t0, uint32 t dt);
async event void enableRxDone();
async command bool isReceiving();
event message t* received(message t *frame);
}
interface RadioTx {
async command error t transmit(ieee154 txframe t *frame, uint32 t t0, uint32 t dt));
async event void transmitDone(ieee154 txframe t *frame, error t result);
}
interface RadioOff {
async command error t off();
async event void offDone();
async command bool isOff();
}
interface UnslottedCsmaCa{
async command error t transmit(ieee154 txframe t *frame, ieee154 csma t *csma);
async event void transmitDone(ieee154 txframe t *frame, ieee154 csma t *csma, bool ackPendingFlag,
error t result);
}
interface SlottedCsmaCa{
async command error t transmit(ieee154 txframe t *frame, ieee154 csma t *csma,
const ieee154 timestamp t *slot0Time, uint32 t dtMax, bool resume, uint16 t remainingBackoff);
async event void transmitDone(ieee154 txframe t *frame, ieee154 csma t *csma,
bool ackPendingFlag, uint16 t remainingBackoff, error t result);
}
interface EnergyDetection {
command error t start(uint32 t duration);
event void done(error t status, int8 t maxEnergyLevel);
}
Fig. 2.6 The interfaces that a radio driver must provide to the MAC implementation
2.1.4.3 Platform Requirements
The currently supported platforms are: telosb, shimmer2(r) and micaz. To make
the MAC available on a new TinyOS 2 mote platform essentially the following
three requirements have to be met:
1. The platform must include a radio driver that provides the interfaces listed in
Sect. 2.1.4.2. When a platform supports only the non-beacon-enabled mode
then the radio driver does not have to provide the SlottedCsmaCa interface, if it
supports only the beacon-enabled mode, then the UnslottedCsmaCa interface is
not required. In addition, the radio driver must use the TinyOS 2 Notify
interface to be updated about changes in the PHY PIB, and provide a set of
PHY-specific constants.5
2. The MAC implementation uses Alarm and Timer interfaces with a precision of
an 802.15.4 symbol (62.5 kHz for the 2.4 GHz band) and an accuracy of 40
ppm. The Alarm and Timer interfaces are standard TinyOS 2 interfaces that are
provided by a platform’s timer subsystem.6 However, a TinyOS 2 platform
typically does not provide these interfaces with the required precision/accuracy.
In this case the platform’s timer subsystem must be extended accordingly
(possibly including the use of additional hardware).7
5
for an example see $TOSDIR/chips/cc2420_tkn154/CC2420TKN154C.nc and TKN154_PHY.h
6
7
For an example see https://github.com/tinyos/tinyos-main/tree/master/tos/platforms/telosb/mac/
tkn154/timer.
3. The platform must provide a TinyOS configuration component that connects

(wires) the platform independent TKN15.4 MAC implementation TKN154Be-
aconEnabledP or TKN154NonBeaconEnabledP to the platform specific timer
subsystem and radio driver. In addition, the platform has to define a set of guard
time constants.8
Since the currently supported platforms do not have a clock that satisfies the
precision/accuracy requirements of the IEEE 802.15.4 standard—62.500 Hz, +-
40 ppm in the 2.4 GHz band—the timing in beacon-enabled mode is not fully
standard compliant.
2.2 ZigBee Cluster-Tree Network Layer Implementation

in TinyOS
This section focuses on the implementation of the ZigBee network layer (NWK) in
TinyOS 2 [9], built on top of the IEEE 802.15.4 MAC primitives (Sect. 2.1.4.1). In
particular, the goal is to detail how to form a network and how to route packets.
Whenever not specified differently, the process described is referred to a Cluster
Tree network model.
2.2.1 Software Architecture
The software of the network layer and its interfaces is sketched in Fig. 2.7. The
main components are the NLDE and NLME service access points. The former
exposes to the upper layer (in this scenario, a generic application layer) the
NLDE_DATA interface to send and receive packets. The latter is composed by a
list of APIs for network management, including network formation and discovery,
nodes’ join, network synchronization and leave. These interfaces take advantage of
the APIs provided by the underlying MAC layer to achieve their task.
In the following, network formation and transmission/reception of packets are
described in more details.
2.2.2 Joining a ZigBee Network
The join procedure is necessary for every ZigBee Router and ZigBee End Device
to join the network. Only the ZC and ZRs are allowed to associate devices. It is
8
for an example see $TOSDIR/platforms/telosb/mac/tkn154/Ieee802154BeaconEnabledC.nc and
$TOSDIR/platforms/telosb/mac/tkn154/TKN154platform.h
2.2 ZigBee Cluster-Tree Network Layer Implementation in TinyOS 39
Fig. 2.7 NWK Layer Software Architecture with the list of interfaces
implemented in the network layer and is based on a distributed addressing scheme,

as described in Sect. 1.3.1. In this section we’ll focus on the construction of a
cluster-tree topology based on the support offered by the MAC sublayer associa-
tion mechanism [10].
When a device receives an association request command frame the MAC sub-
layer issues the MLME_ASSOCIATE.indication primitive to the network layer.
Figure 2.8 depicts a flow chart showing the association procedure of a parent device.
In the MLME_ASSOCIATE.indication primitive, the parent will first check for the
associating device address in the neighbor table, verifying if it is a re-association
and, in that case, the association is successful and the parent generates an association
response command frame with the already stored information. If the device does not
exist, the parent must verify what type of device (ZR or ZED) is trying the asso-
ciation. The type of device defines the address that must be assigned. Nevertheless,
for a successful association, the variable nwk_IB.nwkAvailableAddresses in the
NWK PAN Information Base (NWK PIB) must be greater than zero.
If the associating device is a ZR, the parent adds its information to the neighbor
table and sends the association response command with the short address previ-
ously calculated in the next_child_router_address variable. Then, the parent
updates the future child router address according to Eq. 2.1 followed by an
increment of the number of associated child routers (number_child_router).
next child router address ¼ networkaddressþ

ððnumber child router 1Þ CskipÞ þ 1 ð2:1Þ
Note that the Cskip parameter is calculated in the initialization of the node and the
networkaddress variable is the parent’s device 16-bit short address.
If the associating device is a ZED, the parent also adds its information to the
neighbor table and generate the association response command with the short
address previously calculated in the nwk_IB.nwkNextAddress variable. After the
Fig. 2.8 MLME_ASSOCIATE.indication flow chart
response generation, the nwk_IB.nwkNextAddress variable is incremented by

nwk_IB.nwkAddressIncrement followed by an increment of the number of asso-
ciated child end devices.
2.2 ZigBee Cluster-Tree Network Layer Implementation in TinyOS 41
There is a need to differentiate the type of associating device (ZR or ZED) and
separately count them and their assigned addresses in order to comply with the
address scheme (refer to Sect. 1.3.1). This address distribution enables the con-
struction of the cluster-tree topology
2.2.3 Tree Routing
The Tree Routing procedure, as briefly explained in Sect. 1.3.2, is based on the
addresses of the devices. When the MAC sub-layer of a device receives a data
frame it issues the MCPS_DATA.indication primitive to the NWK layer.
Figure 2.9 depicts a flow chart showing the procedures when the NWK receives
a data frame. The NWK layer, upon reception of a data frame, will first verify if
the routing destination field equals its own short address and, if true, it transfers the
data payload to the upper layer, by issuing the NLDE_DATA.indication primitive.
If the routing destination address is not for itself, the device must calculate the next
hop destination address.
Fig. 2.9 MCPS_DATA.indication flow chart

In case of a ZigBee Coordinator, if the destination of the data frame is its own
child, after checking in the neighbor table, it assigns the next hop with the short
address of the respective child, present in its neighbor table. Otherwise, it needs to
calculate the next hop by applying the Tree Routing formula for that effect (refer to
Sect. 1.3.3). Note that routing is always downstream, since the ZC has no parent.
In case of a ZigBee Routers there is an initial verification if the destination is
upstream or downstream. This verification is done by applying the conditions of
Eq. 2.2:
networkaddress\routing fields ptr ! destination address
and
routing fields ptr ! destination address\ðnetworkaddress þ cskip routingÞ
ð2:2Þ
If the conditions of Eq. 2.2 are true, then routing is downstream. The device
checks if the destination is a child device (by consulting its neighbor table) and if
not it calculate the next hop by applying the Tree Routing formula for that effect
(Sect. 1.3.3). If the conditions are false, the device just routes up to its parent.
After the next hop decision, the message is transmitted by issuing the
MCPS_DATA.request primitive to the MAC sub-layer.
The data frame transmission procedure is similar to the routing mechanism.
After the creation of the frame, the device must assign a destination address to the
routing fields. If the device is a ZED, the only option is to route to its parent
(upstream). Otherwise, if the device is the ZigBee Coordinator or a ZigBee Router,
it must check if the destination is a child device or must calculate the next hop
address.
References

2. D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, D. Culler, The nesc language:
A holistic approach to networked embedded systems. SIGPLAN Not. 38(5), 1–11 (2003)
3. J.-H. Hauer, Tkn15.4: An IEEE 802.15.4 mac—implementation for tinyos 2. TKN Technical
Report TKN-08-003, Technical University Berlin, Telecommunication Networks Group,
Department Telecommunication Networks (TKN), Einsteinufer 25, FT 5, 10587 Berlin,
Germany, 2009
4. J.-H. Hauer, R. Daidone, R. Severino, J. Büsch, M. Tiloca, S. Tennina, Poster abstract:
An open-source IEEE 802.15.4 mac implementation for tinyos 2.1. in Proceedings of 8th
European Conference on Wireless Sensor Networks (EWSN), Bonn, Germany, 2011
5. J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, K. Pister, System architecture directions
for networked sensors. in Proceedings of the Ninth International Conference on Architectural
Support for Programming Languages and Operating Systems (ASPL 2000), 2000
6. P. Levis, D. Gay, V. Handziski, J.-H. Hauer, B. Greenstein, M. Turon, J. Hui, K. Klues, C.
Sharp, R. Szewczyk, J. Polastre, P. Buonadonna, L. Nachman, G. Tolle, D. Culler, A. Wolisz,
T2: A Second Generation OS For Embedded Sensor Networks. Technical Report TKN-05-
007, Telecommunication Networks Group, Technische Universität Berlin, Nov. 2005.
References 43
7. V. Handziski, J. Polastre, J.-H. Hauer, C. Sharp, A. Wolisz, D. Culler, Flexible Hardware

Abstraction, for Wireless Sensor Networks. in Proceedings of 2nd European Workshop on
Wireless Sensor Networks (EWSN, Istanbul (Turkey, 2005)
8. J. Flora, P. Bonnet, Never mind the standard here is the tinyos 802.15.4 stack. Technical
Report 06–10, University of Copenhagen, 2006
9. Tinyos working group, 2010. www.tinyos.net.
10. Institute of Electrical and Electronics Engineers, Inc., New York. IEEE Std. 802.15.4-2006,
IEEE Standard for Information technology—Telecommunications and Information Exchange
Between Systems—Local and Metropolitan Area Networks—Specific Requirements Part
15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for
Low-Rate Wireless Personal Area Networks (WPANs), 2006
Chapter 3
Models and Tools
Abstract An accurate planning and dimensioning of the network parameters and

resources is paramount for the overall system to behave as expected. This is
particularly important when there are more demanding quality-of-service
requirements to be met, namely related to the correct and timely execution of the
tasks and transmission of messages. This chapter outlines a set of analytical and
simulation models and tools to help the system designer to setup and fine tune all
relevant settings and parameters, as well as to anticipate hardware problems and
identify the network behavior and its performance limits.
3.1 Worst-Case Analysis and Dimensioning
The evaluation of the performance limits of WSNs is of paramount importance to

understand their behavior under the worst-case conditions [1] and to make the
appropriate design choices. This is particular relevant for time-sensitive WSN
applications. Supporting time-sensitive WSN applications implies to predict and
guarantee bounded end-to-end communication delays. To ensure bounded end-to-
end delays and to avoid buffer overflow, network resources must be known in
advance, and dimensioned along the path from a source to a sink. In that direction,
this chapter aims at proposing a comprehensive methodology that provides a
scientific approach for quick and efficient worst-case dimensioning of network
resources (e.g., bandwidth and nodes’ buffer size) to avoid their overflows and to
minimize clusters’ duty-cycle (reducing energy consumption of the nodes) in static
or even dynamically changing WSNs with a cluster-tree topology, assuming
bounded communication errors. Consequently, the worst-case performance bounds
(e.g., the worst-case end-to-end delay) can be derived for a cluster-tree WSN with
bounded resources. The analytical methodology is based on Network Calculus as a
trade-off between complexity and accuracy. The main benefit of using Network
Calculus is its generality and simplicity.

46 3 Models and Tools
More details about the methodology, as well as its application to evaluate the
impact of the sink’s mobility on the worst-case performance of the cluster-tree
network, can be found in [2], while here our goal is to show the application of the
methodology to the ZigBee-based Cluster-Tree topology.
The general cluster-tree topology can be represented by the particular ZigBee
cluster-tree topology where ZigBee coordinator corresponds to the root, ZigBee
router to the router and ZigBee end device to the end-node. The beacon-enabled
mode is considered, since it supports cluster-tree topology and enables the provision
of guaranteed bandwidth through the GTS mechanism. Each GTS can be used to
transfer time-sensitive data either in transmit direction, i.e., from child node to its
parent router (upstream data link), or receive direction, i.e., from parent router to its
child node (downstream data link). There can be allocated a maximum of 7 GTSs in
each superframe. Hence, using this explicit GTS allocation, the maximum numbers
of child routers and end-nodes (that require guaranteed bandwidth) associated to
MAX MAX
each router are constrained as follows Nrouter þ Nendnode 7. According to the IEEE
802.15.4 [3] standard, all clusters have the same duty-cycle. Hence, the WC-TDCS
(Worst-Case - Time Division Cluster Scheduling) is given by the non-overlapping
sequence of equally sized SDs, and the period of WC-TDCS is equal to BI.
3.1.1 Guaranteed Bandwidth of a GTS
Each GTS includes effective data transmission and overheads (i.e., inter-frame
spacing (IFS) and eventual acknowledgement and retransmissions [3]). In practice,
most WSN applications are likely to use frames that are smaller than the maximum
allowed size of a MAC frame (MPDU), which is equal to aMaxPHYPacketSize
(1016 bits) [3]. Thus, in order to achieve more accurate results the parameter
MPDUmax representing the user-defined maximum size of MAC frames is
introduced.
Next, the expression for the effective bandwidth guaranteed by one time slot,
which is related to the worst-case data transmission, is derived. The worst-case
time required for the overall successful transmission of a frame (i.e., the last
retransmission succeeded—see Fig. 3.1) is then expressed as:

ðmacMaxFrameRetries X þ 1Þ
Tframe ¼ ð3:1Þ
ðfrm size=rate þ ack XÞ þ IFS
where frm size is the user-defined maximum size of transmitted frame including
the data payload, MAC and PHY headers (i.e., PPDU), rate is the data rate
(assuming 250 kbps), IFS is equal to SIFS or LIFS depending on the MPDUmax ,
ack stands for macAckWaitDuration, X ¼ 1 for an acknowledged transmission or
X ¼ 0 for an unacknowledged transmission.
The worst-case number of frames with user-defined maximum size that can be
transmitted during one time slot is expressed as:
3.1 Worst-Case Analysis and Dimensioning 47
Fig. 3.1 The worst-case time required for an overall successful transmission of frame1
(macMaxFrameRetries ¼ 2)
$ %
TS
Nframe ¼ ð3:2Þ
Tframe
where TS is the duration of a time slot and is equal to SD=16. In the remaining time
(i.e. TS Nframe Tframe ), a MAC frame smaller than MPDUmax can only be
transmitted if the whole transmission can be completed before the end of the GTS.
The size of the last frame (PPDU), which can be transmitted within a given GTS,
is then expressed as:

TS Nframe Tframe IFS
last frm size ¼ ack X rate ð3:3Þ
macMaxFrameRetries þ 1
If the size of the last frame is smaller than the minimum size of frame,
PPDUmin , then last frm size ¼ 0.
Finally, assuming a full duty-cycle (i.e., SO ¼ BO) the bandwidth guaranteed
by one GTS time slot in a given superframe is expressed as:
Nframe frm size þ last frm size
R100%
TS ¼ ð3:4Þ
SD
3.1.2 Characterization of the Service Curve
Each parent router must reserve a GTS with enough time slots for each of its child
nodes. For upstream data links, the resulting bandwidth of GTS, guaranteed by a
TS
parent router at depth i and given by NiU time slots in transmit direction, must be
greater than or equal to the total incoming arrival rate rðiþ1ÞU of a child node at
depth i þ 1. On the contrary, for downstream data links, a parent router at depth i
TS
must reserve a GTS with NiD time slots in receive direction to its child router at
depth i þ 1 such that the resulting link bandwidth is greater than or equal to its
total incoming arrival rate riD . It results that:

TS rðiþ1ÞU TS riD TS rdata
NiU ¼ NiD ¼ Nendnode ¼ ð3:5Þ
RTS RTS RTS
TS
Note that Nendnode is the number of GTS time slots guaranteed to each end-node
by its parent router. Hence, a GTS with NiTS time slots provides rate-latency service
bRi Ti , where Ri ¼ NiTS RTS is the guaranteed bandwidth and Ti is the maximum
latency that the data must wait to be served.
The service latencies Ti depend on the TDCS such that their worst-case values
are achieved for the non-overlapping WC-TDCS (i.e., a TDCS of a data flow along
the longest routing path in a WSN). Since the proposed methodology is based on
the balanced properties of the cluster-tree topology model, the same service
latency, equal to the worst-case one at a given depth, is provided to all data links at
a given depth in upstream/downstream direction. The worst-case service latencies
at each depth, except depth 0, are given by the distance between the active portions
of consecutive clusters on the longest routing path to the sink. The period of
WC-TDCS is equal to the time which spans between two consecutive active
portions of the same cluster (i.e., BI).
Note that the service latencies of any application-specific or overlapping TDCS
will be equal or shorter than the latencies of non-overlapping WC-TDCS. In these
cases, the worst-case latency at a given depth is equal to the longest latency in
upstream/downstream direction at this depth, which does not to be equal to the one
along the longest routing path in a WSN.
The worst-case service latency guaranteed to a flow over an upstream data link
at a given depth is expressed as:
– the latency guaranteed by a router to its end-node:
TS
Tendnode ¼ BI Nendnode TS
– the latency guaranteed by a router at depth i to a child router at depth i þ 1, for
8i, 0 \ i \ H:
TS TS

TiU ¼ BI SD NiU Nðiþ1ÞU TS
– the latency guaranteed by the router at depth 0 to the child router at depth 1:
MAX TS
TS TS
T0U ¼ BI SD N0D þ Nrouter 1 N0U N1U TS
On the other hand, the worst-case service latency guaranteed to a flow over a
downstream data link at a given depth is expressed as:
– the latency guaranteed by a router at depth 0 to the child router at depth 1:

MAX TS
T0D ¼ Nrouter 1 N0U TS
– the latency guaranteed by a router at depth i to the child router at depth i þ 1, for
8i, 0\i\Hsink :
TS TS

TiD ¼ BI SD NiD Nði1ÞD TS
3.1 Worst-Case Analysis and Dimensioning 49
3.1.3 IEEE 802.15.4/ZigBee Cluster–Tree WSN Setup
The experimental scenario considers a simple cluster-tree WSN corresponding to

MAX MAX
the configuration where H ¼ 2, Nendnode ¼ 1, Nrouter ¼ 2. For the sake of sim-
plicity, only end-nodes are equipped with sensing capability (i.e., x ¼ 0) and
generate sensory data bounded by the arrival curve adata . The SO is assumed to be
equal to 4, which is the minimum value that is possible to use without resulting into
synchronization problem [4], using open-ZB protocol stack [5] over TinyOS [6]
and MICAz/TelosB motes. This constraint results from the lack of task prioriti-
zation and non-preemptive behavior of the TinyOS operating system. The total
number of routers is equal to 7. Hence, BO must be set such that at least seven SDs
with SO ¼ 4 can fit inside the BI without overlapping. In general, it results that:
MAX
BI XHD ðH; Nrouter Þ SD ,

MAX
ð3:6Þ
BOmin ¼ log2 XHD ðH; Nrouter Þ 2SO
As a result for SO ¼ 4, the minimum BO is equal to 7, such that a maximum of

27 =24 ¼ 8 SDs can fit in one BI. The maximum duty-cycle of each cluster is then
equal to 2SO =2BO ¼ 1=8 ¼ 12:5 %. Note that to maximize the lifetime of a WSN,
the lowest duty-cycles must be chosen (IEEE 802.15.4 supports duty-cycles under
1 %). As a result, the inactive portion is extended, and the nodes may stay in low
power mode longer to save energy resources. On the other hand, low duty-cycles
enlarge end-to-end delays. Hence, long lifetime is in contrast to the fast timing
response of a WSN, so a trade-off must be found. In the example with SO ¼ 4, the
following duty-cycles can be achieved: 12:5 % ðBO ¼ 7Þ, 6:25 % ðBO ¼ 8Þ,
3:125 % ðBO ¼ 9Þ, and so on.
According to [3], the minimum CAP (i.e., aMinCAPLength parameter), which
ensures that commands and best-effort data can still be transferred when GTSs are
being used, is equal to 7.04 ms, assuming the 2.4 GHz ISM band, which corre-
sponds to 1 time slot with SO ¼ 4. Note that the CAP requires minimum 8, 4, 2 or
1 time slots with SO ¼ 0; 1; 2 or 3, respectively. The remaining slots can be
allocated for GTSs. Hence, the maximum CFP length is equal to LCFP ¼ 15 time
slots. With this constraint, a router cannot reserve more than LCFP time slots for 7
MAX MAX
GTSs maximum, i.e., for its Nendnode end-nodes and Nrouter child routers.
TS
Assuming that each end-node requires allocation of a GTS with Nendnode time
TS
slots (i.e., rdata Nendnode RTS ) from its parent router. Then, each child router can
allocate a TSGTS with MAX
the maximum
MAX
number of time slots equal to
ðLCFP Nendnode Nendnode Þ=Nrouter . The arrival rate rdata must be limited in
order not to exceed the maximum bandwidth that a parent router can reserve.
Obviously, due to the cumulative flow effect, the maximum bandwidth will be
required either by the child routers of the root, in case the sink is associated to the
root (i.e., Hsink ¼ 0), or by the sink router, in other cases (i.e., 1 Hsink H).
Thus, for Hsink ¼ 0, the bandwidth guaranteed by the root to its child routers at
depth 1 is expressed as:
TS MAX

LCFP Nendnode Nendnode
R0 ¼ MAX
RTS
Nrouter
As a result, the maximum arrival rate of the sensory data is:
TS MAX

MAX LCFP Nendnode Nendnode
rdata ¼ MAX

Nrouter
RTS
P
H1 MAX j MAX
j¼0 ðNrouter Þ Nendnode þ x
ð3:7Þ
for Hsink ¼ 0.
On the other hand, for 1 Hsink H, the corresponding link bandwidth
guaranteed by the parent router at depth ðHsink 1Þ to the sink router at depth Hsink
is equal to:
TS MAX

LCFP Nendnode Nendnode
RðHsink 1Þ ¼ MAX
RTS
Nrouter
As a result, the maximum arrival rate of the sensory data is:
TS MAX

MAX LCFP Nendnode Nendnode
rdata ¼ MAX

Nrouter
RTS
P
Hsink 1 MAX Þ Hj MAX
j¼0 ðNrouter Nendnode þx
ð3:8Þ
for 8Hsink , 1 Hsink H.
MAX
The average arrival rate rdata of sensory data must be lower than rdata in any
case. The value of burst bdata is selected according to the burstiness of sensory data.
Finally, the analytical model briefly sketched here has been implemented into a
Matlab tool [7], which can run in Command Line Interface (CLI) mode or
Graphical User Interface (GUI) mode. Figure 3.2 shows the GUI of such tool. On
its left hand side, the network setting and parameters of sensory data are entered.
After the computation, the results and, optionally, several charts are shown on the
right hand side.
3.2 Simulation Models
Simulation and modeling are important approaches to developing and evaluating

thesystems in terms of time and cost. A simulation shows the expected behavior of
asystem based on its simulation model under different conditions. To study
3.2 Simulation Models 51
Fig. 3.2 The GUI of the Matlab analytical model
systembehavior and performance by means of real deployment or setting up a test-

bed mayrequire much effort, time and financial costs. However, the simulation
results arenot necessarily accurate or representative. Hence, the goal for any
simulation modelis to accurately model and predict the behavior of a real system.
Recently, several analytical and simulation models of the IEEE 802.15.4 [8]
protocolhave been proposed. Nevertheless, currently available simulation models
[9]for this protocol are both inaccurate and incomplete, and in particular they do
notsupport the Guaranteed Time Slot (GTS) mechanism, which is required for
timesensitivewireless sensor applications.
This section presents an accurate IEEE 802.15.4/ZigBee simulation model
developedin the Opnet Modeler simulator [10]. Opnet Modeler was chosen due
toits accuracy and to its sophisticated graphical user interface. The idea behind this
simulation model was triggered by the need to build a very reliable model of
theIEEE 802.15.4 and ZigBee protocols for Wireless Sensor Networks (WSNs).
The simulation model is validated with focus on the GTS mechanism using the
NetworkCalculus based analytical model [11].
3.2.1 OPNET
This section presents the structure of the IEEE 802.15.4/ZigBee simulation model
[12] that was implemented in the Opnet Modeler simulator.
3.2.1.1 Simulation Model Structure
The Opnet Modeler [10] is a commercial discrete-event network modeling and

simulation environment, which provides tools for all phases of a system analysis
and testing cycle including model design, simulation, data collection and data
analysis. Both behavior and performance of modeled systems can be analyzed and
visualized in a rich integrated graphical environment. Opnet’s Standard Model
Library supports hundreds of generic or vendor-specific protocols and technologies
that can be use to build the networks. In addition, Opnet Modeler simulator
includes a hierarchical development environment to enable modeling of any type
of custom protocol and device. The development environment consists of three
hierarchical modeling domains (Fig. 3.3). Network domain describes network
topology in terms of nodes and links. Internal architecture of a node is described in
the node domain. Within the process domain, the behavior of a node is defined
using state transition diagrams. Operations performed in each state or transition are
described in embedded C/C++ code blocks. The IEEE 802.15.4/ZigBee simulation
model builds on the wireless module, an add-on that extends the functionality of
the Opnet Modeler with accurate modeling, simulation and analysis of wireless
networks.
Fig. 3.3 The structure of the IEEE 802.15.4/ZigBee Opnet simulation model
The IEEE 802.15.4/ZigBee Opnet simulation model implements physical layer

and medium access control sub-layer defined in IEEE 802.15.4 [3] standard, and
network layer defined in ZigBee [13] specification. The latest version of simulation
model [12] supports the following features:
• beacon-enabled mode (beacon frame generation);
• star and cluster-tree topologies;
• computation of the power consumption (MICAz and TelosB motes are
supported);
• physical layer characteristics;
• slotted CSMA/CA MAC protocol;
• Guaranteed Time Slot (GTS) mechanism (GTS allocation, deallocation and
reallocation functions);
• generation of the acknowledged or unacknowledged best-effort application data
(MSDU) transmitted during the CAP;
• generation of the acknowledged or unacknowledged real-time application data
transmitted during the CFP;
• ZigBee hierarchical tree routing;
• verification of node’s address that must correspond to the ZigBee hierarchical
addressing scheme.
In accordance to the ZigBee [13] specification, three types of nodes in the

simulation model are implemented, namely a ZigBee coordinator, a ZigBee router
and a ZigBee end device. All types of nodes have the same internal architecture
(node domain), but they differ in the available user-defined attributes
(Sect. 3.2.1.2).
The structure of the IEEE 802.15.4/ZigBee simulation model is presented in
Fig. 3.3. The physical layer consists of a wireless radio transmitter and receiver
compliant to the IEEE 802.15.4 [3] standard running at 2.4 GHz frequency band
with 250 kbps data rate. Default settings are used for the physical characteristics of
the radio channel such as background noise and interference, propagation delay,
antenna gain, and bit error rate.
The data link layer supports the beacon-enabled mode (non beacon-enabled
mode is not supported yet) and implements two medium access control protocols
according to the IEEE 802.15.4 standard, namely the contention-based slotted
CSMA/CA and contention-free GTS. MAC payload (MSDU) incoming from the
network layer is wrapped in MAC header and MAC footer and stored into two
separate FIFO buffers, namely a buffer for best-effort data frames and another
buffer for real-time data frames. The frames are dispatched to the network when
the corresponding CAP or CFP is active. On the other hand, the frame (MPDU)
incoming from the physical layer is unwrapped and passed to the network layer for
further processing. The data link layer also generates required commands
(e.g., GTS allocation, deallocation and reallocation commands) and beacon frames
when a node acts as PAN coordinator or router.
The network layer implements address-based tree routing (a mesh routing is not
supported yet) according to the ZigBee [13] specification. The frames are routed
upward or downward along the cluster-tree topology according to the destination
address by exploiting the hierarchical addressing scheme provided by ZigBee [13].
This addressing scheme assigns an unique address to each node using the sym-
metric hierarchical addressing tree given by three parameters, namely the maxi-
mum number of children (i.e., routers and end devices) that a router or a coordinator
may have (Cm ), the maximum depth in the topology (Lm ), and the maximum
number of routers that a router or a coordinator may have as children (Rm ).
The application layer can generate unacknowledged and/or acknowledged best-
effort and/or real-time data frames transmitted during CAP or CFP, respectively.
There is also a battery module that computes the consumed and remaining energy
levels. The energy consumption is estimated as U I t based on the execution
time (t), the voltage (U), and current draw (I). The particular current draws can be
set for a node operating in receive mode, transmit mode, idle mode or sleep mode.
A node in sleep mode can neither transmit nor receive data; a node must be woken
up to idle mode first. The default values are set to those of the widely-used MICAz
[14] or TelosB [15] motes.
3.2.1.2 User-Defined Attributes
This section depicts some important user-defined attributes relating to the GTS
mechanism and the real-time data traffic. All attributes are described in the
reference guide [16] in deeper details.
A coordinator and each router may accept or reject the GTS allocation request
from its children according to the value of the attribute GTS Permit. Each node
(except the coordinator) can specify the time when the GTS allocation request
(GTS Start Time attribute) and deallocation request (GTS Stop Time attribute) are
dispatched to its parent. The allocation request includes the number of required
time slots (Length attribute) and the transmit or receive direction.
Each node can generate data frames inside the time interval given by Start Time
and Stop Time attributes. The size of frame payload (MSDU) is defined by the
Packet Size attribute. The Packet Inter-arrival Time attribute defines the inter-
arrival time between two consecutive frames. The frames are stored in a buffer.
The frames exceeding the buffer capacity (Buffer Capacity attribute) are dropped.
When the requested GTS is active, a frame (MPDU) is removed from the buffer,
prefixed with the headers (SHR and PHR), and it is dispatched to the network with
an outgoing data rate equal to physical data rate (250 kbps).
In Sect. 4.1 the simulation model described here will be applied to assess the
performance of the GTS mechanism and to compare the results against the the-
oretical model of Sect. 3.1.
3.2.2 CASTALIA
Overview
Castalia is a discrete event simulator for Wireless Sensor Networks (WSNs)
and Body Area Networks (BANs) [17]. It is written in the C++ language and based
on the popular simulation platform OMNeT++ [18]. Castalia has been developed
by the National ICT Australia, and is released under the Academic Public License.
Also, users and developers can receive support from a dedicated forum [19].
Castalia allows users to test and validate algorithms, protocols, and applications
for WSNs. In order to do that, it provides realistic models for the radio and the
wireless channel [20].
In particular, the radio model is based on real radios for low-power commu-
nication, including the CC2420 chipset [21]. Also, it models RSSI and carrier
sensing in a realistic way, and considers different modulation types and trans-
mission power levels. As to the wireless channel, Castalia takes into account nodes
mobility, and relies on the lognormal shadowing model, which has been shown to
provide accurate estimates for average path loss [22]. Finally, Castalia considers
also node clock drift, allows for modeling physical processes, and provides
implementations of routing and MAC protocols, including IEEE 802.15.4 [3].
Furthermore, Castalia is highly parametric, and is tailored to evaluate different
platform characteristics for specific applications. It is worth remarking that Cas-
talia is not sensor-platform specific. Instead, it is a generic framework aimed to be
used for preliminary evaluations, before implementing applications and algorithms
for specific platforms. This is what mainly distinguishes Castalia from other WSNs
simulator as Avrora [23].
Finally, Castalia has been designed to be highly adaptable and extendable, thus
allowing the user to enhance its functionalities, and create and import new mod-
ules. This is possible thanks to the modular organization and other tools provided
by OMNeT++, upon which Castalia has been built. Also, since events are managed
by the OMNeT++ simulation engine, Castalia makes it possible to easily focus on
designing and modelling WSNs.
Castalia Architecture
As stated above, Castalia is built upon the OMNeT++ platform. However, the
user is not required to have a deep knowledge of OMNeT++, in case she wants to
use Castalia in a basic way. On the other hand, a fair understanding of OMNeT++
basic concepts is required in order to enhance or develop applications and
protocols within Castalia. In such a case, messages and modules provided by
OMNeT++ become fundamental concepts to deal with.
In short, an OMNeT++ simple module represents the basic unit of execution.
More specifically, it receives messages sent by other modules or itself, and per-
forms some actions according to the message kind and content. Also, the received
message can alter the module execution state, and can schedule new messages to
Fig. 3.4 Overview of a

Castalia sensor network
be sent. Simple modules can be combined together as part of a common composite

module, while different composite modules can be nested one inside the other.
As shown in Fig. 3.4, Castalia conceives the sensor network as a collection of
nodes. Each node relies on a number of sensing devices that interact with some
physical processes in order to retrieve data from the environment. It is worth
remarking that each sensing device can be associated with a single physical pro-
cess. Then, sensor nodes communicate with each other through a commonly
shared wireless channel. In the following, we briefly overview the physical pro-
cesses and wireless channel available in Castalia.
Physical Processes
In order to feed sensor nodes with data, Castalia allows for either setting static
sensing values or relying on physical process models. In particular, two physical
process models are provided, i.e. the Customizable Physical Process and the Cars
Physical Process.
The former one considers an arbitrary number of sources that influence the
environment, and possibly change their position and value over time. In particular,
the value of the physical process at a specific location and time is given by the
following equation.
X Vi ðtÞ
Vðp; tÞ ¼ a þ Nð0; rÞ ð3:9Þ
all sources i
ðK d i ðp; tÞ þ 1Þ
Vðp; tÞ stands for the value of the physical process at point p and time t. Vi ðtÞ
represents the value of the i-th source at time t, while di ðp; tÞ denotes the distance
of point p from the i-th source at time t. The K and a parameters determine in
which way the value is diffused from a source. Finally, Nð0; rÞ is a zero-mean
gaussian random variable, with standard deviation r.
As an alternative, Castalia provides the Cars Physical Process. Such model
reproduces the behavior of a number of cars moving along a path in a linear way.
Basically, cars are moving sources available for sensor nodes readings. The actual
values read from cars are dispersed in space according to the Customizable
Physical Process formula (see Eq. 3.9), with K ¼ 0:1 and a ¼ 1. The user is
allowed to set both the speed and the interarrival time of considered cars.
Wireless Channel Modeling

Castalia results to be a realistic simulator, since it makes an effort to capture
various important features of a real wireless channel. Also, parameters related to
the wireless channel are set at reasonable values, in order to reflect real situations.
The main aspect of wireless channel modeling is the estimation of the average
path loss between any two nodes. To this end, the lognormal shadowing model is
used, since it has been shown to provide accurate estimations of the average path
loss [22]. The path loss in dB is computed according to the following equation.
d
PLðdÞ ¼ PLðd0 Þ þ 10 g logð Þ þ Xr ð3:10Þ
d0
PLðdÞ represents the path loss at distance d, while PLðd0 Þ is the known path
loss at a reference distance d0 . Finally, g stands for the path loss exponent, whereas
Xr is a gaussian zero-mean random variable, with standard deviation r.
Although the two traffic directions are typically treated as independent links, the
wireless channel model returns an average path loss for both directions. This is the
reason why Castalia adds and subtracts a separate Gaussian zero-mean random
variable with a specified standard deviation, whose value is supposed to be small
(e.g. 1:0). By doing so, it is possible to control the correlation between the two
traffic directions.
Furthermore, the wireless channel model provided by Castalia takes into
account the presence of mobile sensor nodes within the network. Thus, informa-
tion about path losses between points in space must be kept, rather than between
actual nodes. In order to do that, Castalia organizes the simulated space as a
collection of discrete cells. Then, path losses from each cell to each other cell are
computed. If only static nodes are considered, each one of them is treated as a
special cell.
More details about temporal variation modeling, and interaction between the
wireless channel and nodes’ radio can be found in the Castalia user’s manual [20].
Sensor Nodes Architecture
Each Castalia sensor node is composed by a number of different submodules.
Figure 3.5 shows the overall architecture of a single node, and how its submodules
are connected with each other.
The Sensors manager module implements the actual sensing devices on the
node, and is responsible for collecting data from the environment through the
available physical processes. Then, it alters sensed data in order to introduce
distortion due to realistic sensing devices. Finally, data can be provided to the
application running on the sensor node.
The Resource manager module monitors the energy spent by the sensor node.
In order to do that, modules that implement hardware devices (i.e the radio and the
Sensors manager modules) notifies how much power they have drawn to the
Resource manager. Then, the consumed energy is calculated both periodically and
each time a variation of power occurs. Also, the Resource manager module owns
Fig. 3.5 Architecture of

Castalia sensor nodes
node-specific information as the clock drift and the baseline power consumption,
i.e. the minimum power that the node consumes.
The Mobility manager module deals with how sensor nodes move through the
simulated space. It keeps track of the node location over time, and makes such
information available to other modules of the same node through a function call.
Also, it is responsible for periodically notifying the current node position to the
wireless channel.
The Application module represents the applicative software running on the
sensor node. This layer is responsible for receiving sensed data from the Sensors
manager module, processing data according to the application specifications, and
dealing with packets forwarding and reception. Castalia provides a number of
simple although effective implemented applications, aimed at testing its main
features, and making the user familiar with the simulation framework.
The Routing, MAC, and Radio modules constitutes the actual communication
stack of sensor nodes. As to the network layer, Castalia provides two routing
protocols, i.e. bypassRouting and multipathRingsRouting. As the name suggests,
the former one does not implement any actual routing policy. Instead, the multi-
pathRingsRouting protocol defines a sink node, and organizes network nodes in
different levels, but no one of them has a specific parent. Each node receives a
level number (or ring number) during the setup phase. More specifically, the sink
node starts the setup phase by sending a setup packet with level 0. Upon receiving
such packet, a node adds 1 to the level and broadcasts it to other nodes. This
process goes on until all connected nodes have a level number. In order to send a
packet to the sink, a network node actually broadcasts the packet, including its
own level number. Then, any node with smaller level number rebroadcasts the
packet. This process ends when the sink receives the packet. This routing protocol
results to be quite robust. However, in case of high transmission rates, the network
might be easily congested, and performance can be seriously affected.
As to the MAC layer, Castalia provides four MAC modules, i.e. TunableMAC,
TMAC, IEEE 802.15.4, and BaselineBANMac. TunableMAC is a duty-cycled
MAC, which reflects the behavior of a simple CSMA/CA MAC protocol, and does
not support acknowledgments and RTS/CTS control packets. T-MAC aims at
keeping performance high by adapting its duty cycle according to traffic
requirements. IEEE 802.15.4 focus on the MAC layer of the IEEE communication
standard [3], and includes CSMA-CA functionalities (slotted and unslotted),
beacon-enabled networks with association, direct data transfer mode, and Guar-
anteed time slots (GTS). BaselineBANMac implements the IEEE 802.15.6 draft
proposal for BAN [8].
The Radio module makes an effort to reproduce the behavior and features of
real low-power radios. Its main features include multiple states, multiple trans-
mission power levels, different power consumpion levels, multiple modes of
operation and modulation schemes, Channel Clear Assessment (CCA) capability,
and fine grained interference calculation.
Castalia Usage
Castalia provides the user with three different scripts, namely Castalia, Cas-
taliaResults, and CastaliaPlot. Basically, Castalia is used to actually simulate
WSN scenarios. On the other hand, CastaliaResults allows users to visualize and
interpret simulation results. Finally, CastaliaPlot is used to create graphs of the
obtained simulation results.
The Castalia script takes an .ini configuration file as input. Such file includes a
list of parameters to be considered and their values, and provides a description of
the WSN scenario to be simulated. Parameters values specified within the .ini file
overwrite potential default values provided in other Castalia configuration files.
Also, parameters can be organized into sections, namely configurations. This
allows the user to simulate specific configurations, and potentially combine them.
More information about available parameters can be found in Castalia user’s
manual [20].
The Castalia script parses the .ini file, retrieves simulation parameters to be
considered, and then runs the actual simulation for the specified application sce-
nario. Also, the user can specify how many repetitions must be performed. Finally,
it is possible to produce an additional output file, containing a trace of all events
occured during the simulation.
The output produced by the Castalia script is a text file containing simulation
results. Although such file is human readable, the user can rely on the Castali-
aResults script to visualize and interpret it more easily. Specifically, CastaliaRe-
sults takes as input the simulation output file produced by the Castalia script.
Then, it parses such file in order to find out what output has been recorded by
different modules (e.g. Application, Sensors Manager, Wireless Channel) during
the simulation. By means of specific options, it is possible to focus on different
outputs, and properly visualize data in a comfortable tabular form.
Finally, the CastaliaPlot script allows for automatically drawing graphs straight
from the output of CastaliaResults. More specifically, CastaliaPlot takes the
output of CastaliaResults as input. Then, the table produced by CastaliaResults is
drawn by CastaliaPlot according to the set of options specified by the user.
CastaliaPlot supports different image formats and graph styles, and relies on the
gnuplot program [24] to produce graphs.
3.3 Network/Protocol Analyzer (Z-Monitor)
Monitoring of WSNs is a fundamental task to track the network behavior and

measure its performance in real-world deployments. Commercially-available
products for monitoring and testing IEEE 802.15.4-compliant Low Power WPANs
(LoWPANs) are mainly too expensive, and typically require special sniffing
hardware.
LoWPANs are typically composed of devices that conform to the IEEE
802.15.4-2006 standard. While IEEE standard 802.15.4 specifies the Physical and
Medium Access Control (MAC) layers and underlying services for LoWPANs,
upper layers like Network and Application layers are defined by other standards
like ZigBee [13], 6LowPAN [25] and RPL [26]. Despite the fact that ZigBee and
6LoWPAN/RPL are arguably the most important WSN technologies today, very
little is available on network monitoring and debugging of these networks.
In [27] and in the following, a tool called Z-Monitor is presented. It is a
modular application for monitoring and controlling IEEE 802.15.4-compliant
LoWPANs. Z-Monitor provides a convenient solution for researchers and students
for developing, debugging and deploying wireless sensor network applications
based on IEEE 802.15.4 standard protocol and underlying network protocols (i.e.,
6LoWPAN, ZigBee, RPL). Z-Monitor is compatible with the open-source official
TinyOS implementation of the IEEE 802.15.4 recently released by the TinyOS
15.4 Working Group [6]. It also provides support for both ZigBee and 6LoW-
PAN [25], the two mostly used protocols deployed over LoWPANs. Moreover, it
does not require special sniffing hardware, and provides comparable services to
proprietary and commercial products.
Z-Monitor provides an open source, extensible, modular and user-friendly
solution for LoWPAN monitoring. It allows for passive monitoring of IEEE
802.15.4-based networks and for analyzing the network behavior through statis-
tical data analysis. It relies on a particular sensor node acting as a passive sniffer
that captures network traffic and redirects it to a user-friendly Graphical User
Interface (GUI). The fundamental advantage of Z-Monitor as compared to com-
mercially available products such as CC2420 Sniffer [28], Daintree Network
Analyzer [29] and Zena [30] is that it is independent of any special hardware, it
relies on a simple mote to capture traffic and it is open source.
A component-based approach has been used to design Z-Monitor. The block
diagram of the main components is shown in Fig. 3.6.
3.3 Network/Protocol Analyzer (Z-Monitor) 61
Z-Monitor Software Architecture
Sniffer Buffering Parsing Data Manipulation

Component Component Component Component
Sniffer
Hardware
Storage
Component
Fig. 3.6 The block diagram of Z-Monitor
Fig. 3.7 Z-Monitor frame decoding interface
On the hardware side, the sniffer hardware is simply an IEEE 802.15.4-compliant

sensor mote, which passively captures the network traffic. Each received packet is
redirected to the serial interface through which the sniffer is attached to forward that
packet to the software sniffing threads. The sniffer hardware used is a TelosB
mote [15] which runs the packetsniffer application available under TinyOS.1
This application switches the radio chip of the node into promiscuous mode and
subsequently sniffs all packets that come along. Z-Monitor collects packets arriving
from the USB port, stores them in a buffer, performs parsing and packet decoding and
finally displays parsed frames and outputs network statistics as depicted in Fig. 3.7.
Currently, Z-Monitor is compatible with all open-source implementations of
COTS WPANs technologies, namely IEEE 802.15.4, ZigBee, 6LoWPANs, and
RPL protocols provided by TinyOS and Contiki operating systems.
However, Z-Monitor can be extended to support more advanced features
including (i) support of multi-hop topologies through the use of multiple sniffers
1
On [31], $TOSROOT/apps/tests/tkn154/packetsniffer.
Fig. 3.8 Z-Monitor distributed sniffers concept: The Z-Monitor instances collect data to a central
database, where the full network without duplicated packets is available to external clients for
monitoring/debugging
so that it will be easier and practical to analyze the behavior of large scale
networks (for which a first implementation is already on-going as sketched in
Fig. 3.8), (ii) extending parsing component to support new COTS protocols
implementations such as TinyRPL, which has recently been released (see,
e.g., [32]), and (iii) integrating advanced filtering and statistical analysis features.
References
1. Z. Hu, B. Li, Fundamental performance limits of wireless sensor networks. in Ad Hoc and
Sensor Networks, ed. by Y. Xian, Y. Pan (Nova Science Publishers, New York, USA, 2004)
2. P. Jurčík, Real-time Communication over Cluster-tree Wireless Sensor Networks
(Department of Control Engineering, Faculty of Electrical Engineering, Czech Technical
University in Prague, Czech Republic in collaboration with CISTER-ISEP Research Unit,
Polytechnic Institute of Porto, Portugal, Prague, Ph.d. Programme on Electrical Engineering
and Information Technology, 2010)
IEEE Standard for Information Technology—Telecommunications and Information
Exchange between Systems—Local and Metropolitan Area Networks—Specific
Requirements Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer
(PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs), 2006
4. A. Cunha, R. Severino, N. Pereira, A. Koubâa, M. Alves, Zigbee over tinyos: Implementation
and experimental challenges. in Proceedings of the 8th Portuguese Conference on Automatic
Control (CONTROLO), 2008, pp. 911–916
References 63
5. A. Cunha, A. Koubâa, R. Severino, M. Alves, Open-zb: An open source implementation of

the IEEE 802.15.4/zigbee protocol stack on tinyos. in Proceedings of the 4th IEEE
International Conference on Mobile Ad-hoc and Sensor Systems (MASS), 2007
6. Tinyos working group, 2010. http://www.tinyos.net
7. P. Jurčík, Matlab tool for the worst-case dimensioning of IEEE 802.15.4/zigbee cluster-tree
WSNs, 2009. http://www.open-zb.net
8. IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs). IEEE
P802.15 Wireless Personal Area Networks—MAC and Security Baseline Proposal—
Normative Text, 2010. [Online]. Available. https://mentor.ieee.org/802.15/dcn/10/15-10-
0196-02-0006-mac-and-security-b aseline-proposal-c-normative-text-doc.doc
9. C.P. Singh, O.P. Vyas, M.K. Tiwari, A survey of simulation in sensor networks. In
Proceedings of the 4th International Conference on Computational Intelligence for
Modelling Control and Automation (CIMCA), (2008), pp. 867–872
10. I. OPNET Technologies. The opnet modeler network simulator version 15.0.a, 2009
11. A. Koubâa, M. Alves, E. Tovar, Gts allocation analysis in IEEE 802.15.4 for real time
wireless sensor networks. in Proceedings of the 14th Workshop on Parallel and Distributed
Real Time Systems (WPDRTS), (2006)
12. P. Jurčík, A. Koubâa, IEEE 802.15.4/zigbee opnet simulation model v3.0, 2009. http://www.
open-zb.net
13. ZigBee Alliance, ZigBee Document 053474r17, ZigBee Specification, 2008. http://www.
zigbee.org
14. MEMSIC MPR2400CB, 2.4GHz MICAz Processor Board, datasheet (2013), http://www.
memsic.com/wireless-sensor-networks
15. Memsic, TPR2420CA TelosB Mote May (2013), www.memsic.com/wireless-sensor-networks
16. P. Jurčík, A. Koubâa, The IEEE 802.15.4 opnet simulation model: Reference guide v2.0.
Technical Report TR-070509, IPP-HURRAY Research Group, CISTER/ISEP, Polytechnic
Institute of Porto, Portugal, 2009
17. National ict australia—castalia. [Online]. Available: http://castalia.npc.nicta.com.au/
18. Omnet++ network simulation framework. [Online]. Available: http://www.omnetpp.org
19. Castalia simulator—google groups. [Online]. Available:http://groups.google.com/group/
castalia-simulator?pli=1
20. Castalia—a simulator for wireless sensor networks and body area networks, version 3.2
user’s manual. [Online]. Available: http://castalia.npc.nicta.com.au/pdfs/Castalia%E2%80%
94UserManual.pdf
21. Texas instruments cc2420 2.4 ghz IEEE 802.15.4 / zigbee-ready rf transceiver. [Online].
Available: http://www.ti.com/lit/ds/symlink/cc2420.pdf
22. M. Zuniga, B. Krishnamachari, Analyzing the transitional region in low power wireless links.
in First IEEE International Conference on Sensor and Ad hoc Communications and Networks
(SECON), (Santa Clara, USA, 2004), pp. 517–526
23. Avrora—the avr simulation and analysis framework. [Online]. Available: http://compilers.cs.
ucla.edu/avrora/
24. gnuplot homepage. [Online]. Available: http://www.gnuplot.info/
25. G. Montenegro, N. Kushalnagar, J. Hui, D. Culler, Transmission of IPv6 Packets Over IEEE
802.15.4 Networks. Internet proposed standard RFC 4944, 2007
26. T. Winter, P. Thubert, Rpl: Ipv6 routing protocol for low power and lossy networks. IETF
Internet-Draft draft-dt-roll-rpl.txt., 3, 2010
27. A. Koubâa, S. Chaudhry, O. Gaddour, R. Chaari, N. Al-Elaiwi, H. Al-Soli, H. Boujelben,
Z-monitor: Monitoring and analyzing IEEE 802.15.4-based wireless sensor networks. in 6th
IEEE LCN Workshop on Network Measurements, in Conjunction with 36th IEEE
Conference on Local Computer Networks (LCN 2011), 2011
28. Texas Instruments, SmartRF Protocol Packet Sniffer, http://www.ti.com/tool/packet-sniffer
29. D. Networks, Daintree sensor network analyzer (sna), 2009. http://www.daintree.net
30. Zena network analyzer. http://www.microchip.com

32. J. Ko, J. Eriksson, N. Tsiftes, S. Dawson-haggerty, A. Terzis, A. Dunkels, D. Culler,
Contikirpl and tinyrpl: Happy together. in Proceedings of the workshop on Extending the
Internet to Low power and Lossy, Networks IP+SN 2011, 2011
Chapter 4
Performance Analysis and Network
Dimensioning
Abstract This Chapter provides an overview of the performance limits of the 15.4
and ZigBee custer-tree protocols, building on the models and tools that have been
presented in Chap. 3. A thorough performance analysis permitted to identify some
limitations in the standard protocols, some of which we resolve with the add-ons
that are presented in the second part of the book (Chaps. 5 and 6).
4.1 Performance Analysis of the IEEE 802.15.4 GTS

Mechanism
This section presents the performance assessment of the GTS mechanism defined
by the IEEE 802.15.4 standard [1]. This is done using the simulation tool presented
in Sect. 3.2.1.1 and the results compared against the analytical framework
described in Sect. 3.1.
4.1.1 Simulation Setup
Since there is no medium access contention inside the GTS, a simple star network
containing a coordinator and one associated end device is sufficient for perfor-
mance evaluation. Thus, having additional nodes would have no influence on the
simulation results. For the sake of simplicity, and without loss of generality, we
assume the allocation of only one time slot GTS in transmit direction and a 100 %
duty-cycle (i.e., SO ¼ BO). In what follows, the change of the SO means that the
BO also changes, while keep satisfying SO ¼ BO. This means that the optional
inactive portion is not included in the superframe. Small frame sizes are used in
the simulation and the results (e.g., average, maximum, minimum delays) are
computed from a set of 1000 transmissions. Hence, the simulation time of one run
is equal to the duration of 1000 superframe periods.

66 4 Performance Analysis and Network Dimensioning
4.1.2 Simulation Versus Analytical Models
In Sect. 4.1.3, the performance of the GTS mechanism from the Opnet simulation
model is evaluated against the analytical model of the GTS mechanism proposed
in [2], which is based on the Network Calculus formalism.
The Network Calculus-based analytical model relies on the affine arrival curve
and rate-latency service curve [3]. This means that each generated application data
flow has a cumulative arrival function RðtÞ upper bounded by the affine arrival
curve ab;r ðtÞ ¼ b þ r t, where b denotes the burst tolerance and r denotes the
average arrival rate. The analytical model is bit-oriented, which means that
the application data are generated as a continuous bit stream with data rate r. On
the other side, the simulation model has a more realistic frame-oriented basis,
where the frames with a specified size are generated with a given period. Con-
sequently, the burst tolerance b and arrival rate r, as defined in the analytical
model, should be implemented in the simulation model in the following way.
A FIFO buffer with a specified capacity substitutes a data burst with a given size,
and the arrival data rate is defined as follows:
Packet size
r¼ ½bps ð4:1Þ
Packet Interarrival Time
The smallest data unit in the analytical model is a bit, while in the simulation
model it is a frame with a bounded size.
4.1.3 Performance Analysis
This section shows how the Superframe Order, the arrival data rate and the size of
the frame payload impact the throughput of the allocated GTS and the media
access delay of the transmitted frames.
4.1.3.1 GTS Throughput
Throughput as a function of the SO and arrival data rate. The purpose of this
section is to evaluate and compare the data throughput during one time slot GTS,
for different values of the Superframe Order and for different arrival rates. For a
given SO, the data throughput is related to the time effectively used for data
transmission inside the GTS. Since the frames are transmitted without acknowl-
edgement, the wasted bandwidth can only result from IFS or waiting for a new
frame if the buffer is empty.
The frames can be dispatched at the physical data rate (250 Kbps) if the buffer
does not become empty before the end of GTS. Otherwise, if the buffer becomes
empty, the frames are not stored in the buffer but they are directly dispatched to the
4.1 Performance Analysis of the IEEE 802.15.4 GTS Mechanism 67
network according to their arrival data rate Eq. 4.1, which is often lower than the
physical data rate.
Figure 4.1 plots the average throughput of one GTS time slot allocated for
different SOs (with a duty-cycle equal to 1) as a function of the arrival data rate,
for two sizes of frame payload (40 and 41 bits). To identify the impact of the
arrival data rate on the throughput, the buffer capacity is fixed to 2 mKbits.
To show the impact of the IFS on the GTS throughput, the size of the frame
payload is set to 40 and 41 bits. When the frame payload size is smaller or equal to
40 bits (MPDU is equal to 144 bits assuming MHR of 88-bit size), the SIFS
(48 bits) is used. Otherwise, if the frame payload size is greater or equal to 41 bits,
then the LIFS (160 bits) is used. Note that, one additional bit in the frame payload
causes 112 additional bits in the IFS. It can be easily observed in Fig. 4.1 that the
impact of the IFS on the wasted bandwidth is more significant for low SO values.
When the size of the frame payload (Packet Size) is fixed, the inter-arrival time
(Packet Inter-arrival Time) has to be changed according to Eq. 4.1 in order to reach
the required arrival data rates. For instance, to achieve 5 Kbps arrival data rate, it
can be computed that the frame payload with 40 bits size has to be generated every
28.8 ms. We use the same settings as in the analytical model [2] and the Packet Size
and Packet Inter-arrival Time attributes have been configured as constant values
that correspond to the required data rates during each simulation run.
The behavior of the throughput for low SO values and the lowest arrival data
rate (5 Kbps) is quite different from the rest of the experiments. This occurs since
the Superframe Duration for SO ¼ 0 is equal to 15.36 ms, but for 5 Kbps arrival
data rate the frame payload is generated every 28.8 ms. Thus, in every two su-
perframes, one of them has no available frame in the buffer, and therefore the
throughput is roughly the half of the ones resulting from other arrival data rates,
where at least one frame is available in the buffer every superframe.
Fig. 4.1 GTS throughput as a function of the arrival data rate

If the size of the frame payload is equal to 41 bits, it results that for SO ¼ 0 the
throughput is zero for all arrival data rates, since the whole transmission (including
the frame and LIFS) cannot be completed before the end of the GTS.
For low SO values, the throughput grows since the buffer does not become
empty during a GTS duration, and a significant amount of bandwidth is wasted by
the IFS. On the other hand, the throughput for high SO values falls, since the buffer
becomes empty before the end of the GTS. For a large GTS, a significant amount of
bandwidth is wasted when waiting for the incoming frame payload from the
application layer. The throughput for high SO increases with the arrival data rate
(i.e., lower Packet Inter-arrival Time), since the waiting time for the incoming
frame payload decreases. It can be easily observed that the throughput performance
for high SO values is identical and independent of the size of the frame payload.
Analytical results versus simulation results. In Fig. 4.2, the analytical and the
simulation models have a very similar behavior in terms of the GTS throughput as
a function of the arrival data rate. The throughput performance for high SO values
has identical values and shape for both models. The simulation results are influ-
enced by the frame-oriented approach of the simulation model, which is more
significant for low SO values. The analytical model is bit-oriented, therefore it
saturates available transmission bandwidth and therefore the throughput perfor-
mance of the simulation model is upper bounded by the maximum throughput of
the analytical model (analytical results are drawn with dashed lines).
4.1.3.2 Impact of the Superframe Order on the Medium Access Delay
In time-sensitive applications, it is necessary to upper bounds the media access

delay of the frame. The media access delay is defined as the time between the
instant when the frame payload is generated at the application layer and the instant
when the frame is dispatched to the network. In what follows, this section presents
Fig. 4.2 GTS throughput as a function of the arrival data rate: simulation versus analytical model
the impact of the SO values on the media access delay of the frame for 100 %
duty-cycle. The most suitable SO values for providing the lowest delay bound are
also determined. Two initial states of the buffer, namely empty or full, are
consider.
Figure 4.3a presents the media access delay as a function of the arrival data
rate, for a frame payload size and a buffer capacity equal to 40 bits and 4 Kbits,
respectively. Observe that the media access delay depends neither on the arrival
data rate nor on the initial size of the buffer for higher values of arrival data rate
(20–120 Kbps). In this case the behavior is almost identical to each other and the
lowest delay bound is achieved for SO values equal to 2–3. This occurs since for
low SO values (SO\5) the maximum delay is achieved for full buffer. For
increased values of the arrival data rate, only the time for filling the buffer grows.
This explains also the identical behavior for initially full or empty buffer. For SO
values higher or equal to 5, all frames stored in the buffer (with capacity equal to
4 Kbits) can be transmitted during a GTS and the media access delay grows with
SO. The value of this breakpoint depends on the buffer capacity (Fig. 4.3b).
The delay behavior for the lowest arrival data rate is a monotonic function with
the minimum for SO ¼ 0. The arrival data rate is too slow and the buffer becomes
always empty during a GTS for all SO values. Thus, the value of media access
delay grows with SO and does not depend on the buffer capacity. When the buffer
is initially full, the maximum delay is achieved at the beginning, and then the
buffer becomes gradually empty. For SO 6, the buffer is filled up during a
Superframe Duration and the behaviours of initially full and empty buffers are met.
The specific delay behaviour, for an arrival data rate equal to 10 kbps, is explained
in more details, with the support of the results shown in Fig. 4.3b.
Figure 4.3b shows the media access delay of the frame as a function of the
buffer capacity, for a frame payload size and an inter-arrival time equal to 40 bits
and 14.4 ms (i.e., r = 10 Kbps), respectively. For the low SO values (0 and 1), the
number of generated frames during a Superframe Duration is higher than
the maximal number of potentially transmitted frames during the GTS so that the
number of stored frames in the buffer grows. The maximum delay of the frame is
reached when the buffer is full. Therefore, the media access delay depends only on
the buffer capacity and grows with it. For increasing SO values, only the time when
the buffer will be full grows. The delays are roughly constant since when the SD is
doubled, (i.e., SO value is incremented by one) the GTS duration has to be doubled
too. In what follows, the number of generated and transmitted frames is also
doubled, thus their ratio stays constant.
When the buffer is initially empty and SO values are higher than 2, the media
access delay depends only on the SO values instead of the buffer capacity, and it is
roughly equal to the SD minus one time slot GTS duration. This occurs since the
number of generated frames is lower than the maximum number of potentially
transmitted frames so that no frame is stored in the buffer between two consecutive
GTSs. When the buffer is initially full, the media access delay still depends on the
buffer capacity until the value of SO causes that the full buffer becomes empty
Fig. 4.3 The media access delay. a The media access delay as a function of the arrival data rate.
b The media access delay as a function of the buffer capacity
during a GTS. Afterward, the delay depends only on the value of SO. The max-
imum delay is reached at the beginning, before the buffer becomes empty.
In this special case, for the lowest buffer capacity (500 bits), the media access
delay function is monotonic and grows with SO values, which makes SO ¼ 0 the
most suitable for providing the lowest delay. For higher buffer capacities, the most
suitable value of SO in terms of the lowest delay is definitely 2 and does not
depend on the buffer capacity, when the buffer is initially empty.
Analytical results versus simulation results. The simulation and analytical
results of the media access delay as a function of the buffer capacity or burst size b
are compared in Fig. 4.4. The analytical results are obtained for the arrival data
rate equal to 5 Kbps. The same arrival data rate cannot be used for the simulation
model, because the delay for arrival data rate equal to 5 Kbps does not depend on
the buffer capacity (Fig. 4.3a). According to the results shown in Fig. 4.3a, the
arrival data rate equal to 20 Kbps has been selected as the closest one. Hence, we
Fig. 4.4 The media access delay as a function of the buffer capacity/burst size: simulation versus
analytical model
cannot compare the values, but only the behavior of the models in terms of media
access delay. This behavior is roughly similar for both models, and the lowest
delay is achieved for SO ¼ 2 in higher buffer capacity (2–10 Kbits), or for SO ¼ 0
in case of lower buffer capacity (0.5 and 1 Kbits). The difference between frame-
oriented and bit-oriented approaches of the simulation and analytical models,
respectively, can be observed for the higher SO values. In case of the analytical
model, the delay curves converge slowly into a single one (analytical results are
drawn with dashed lines).
In summary, WSN applications with low data rates and low buffer capacities
achieve the lowest delay bound for SO ¼ 0. However, for higher buffer capacities
(more than 1 Kbits) and higher arrival data rates (more than 10 Kbps) the most
suitable value of SO for providing real-time guarantees is 2. The simulation and
analytical results are roughly identical in terms of the media access delay, and the
simulation results are upper bounded by the analytical results.
4.2 Performance Analysis of the IEEE 802.15.4 CSMA/CA

Mechanism
This section addresses the performance evaluation of the Slotted CSMA/CA

mechanism, both through an experimental testbed and through simulation. The
analysis tries to assess the impact of the choice of Beacon Order (BO) and Backoff
Exponent (BE), in the network performance, based on known metrics like the
Probability of Successful Transmissions and Network Throughput as a function of
the Offered Load.
The IEEE 802.15.4 Slotted CSMA/CA mechanism was evaluated with the
purpose of measuring its performance and the effectiveness of the available
hardware platforms. Moreover, this analysis permits to identify the mechanism

limitations and may trigger the proposal of improved schemes for specific pur-
poses (e.g., reducing average delays, improving the throughput). The analysis was
done for different network settings, in order to understand the impact of some
protocol parameters on the network performance, namely in terms of Network
Throughput (S) and Probability of Successful transmissions (Ps ), given a certain
Offered Load (G). These performance metrics are based on an extensive study of
the Slotted CSMA/CA presented in [4]. The performance metrics analyzed here
are: (i) Network Throughput (S), as the fraction of traffic correctly received by the
Network Analyzer, normalized by the network capacity of the IEEE 802.14.5
Physical Layer (250 kbps); and (ii) Success probability (Ps ) computed as S divided
by GMAC , i.e., Ps ¼ S=GMAC and reflecting the degree of reliability achieved by the
network for successful transmissions. Ps ðGÞ will denote the success probability as
a function of the offered load G.
4.2.1 Experimental and Simulation Testbeds
The OPNET [5] simulation model [6] for the IEEE 802.15.4 supporting the slotted
CSMA/CA mechanism was used as a means to compare experimental and simu-
lation results, for the same scenarios. In general, both the simulation and experi-
mental scenarios consist of 1 PAN Coordinator and 10 End Devices generating
traffic (data frames with 63 bytes of length) at pre-programmed inter-arrival times
(at the Application Layer) and a network/protocol analyzer capturing all the data
for later processing and analysis. The generated data frames have a constant size
and are equal in all nodes.
The global offered load (denoted as G) generated by all node’s application
layers depends on the inter-arrival times, which are exponentially distributed
(Poisson arrivals). Basically, the performance of the slotted CSMA/CA mechanism
will be evaluated as a function of the offered load G in the network. The simulation
and the experimental scenarios are depicted in Figs. 4.5 and 4.6, respectively.
In Fig. 4.5, it is possible to observe the network layout and the attributes of each
End Device node (wpan_sensor_node model).
Figure 4.6 depicts the experimental testbed, using MICAz motes. In general,
the hardware testbed consists of one Coordinator, 10 End Devices, one packet
sniffer and one configuration node.
The configuration node consists of a MICAz mote attached through a serial
board to a computer. This node is used to setup the message inter-arrival times,
frame size or any other network parameter of the traffic generating nodes thus
providing a way of changing the nodes configuration without the need of repro-
gramming. This setting is done by simply sending a packet with all the network
parameters values embedded in the payload at the beginning of each run, thus
enabling the traffic generation of the end devices. In order to do this, a command is
typed in the terminal window of the computer. At that point, the end-devices
4.2 Performance Analysis of the IEEE 802.15.4 CSMA/CA Mechanism 73
Fig. 4.5 Simulation model setup
already synchronized with the coordinator’s beacon, start transmitting data frames.
The data frames were embedded with the necessary data in their payload to enable
the analysis.
The packet analyzer used to capture all the generated packets was the Chipcon
CC2420 Packet Analyser [7]. It generates a text file with all the received packets
and the corresponding timestamps. A parser application was developed to retrieve
the necessary data from the packet’s payload (by parsing the sniffer’s capture file)
and export it to a spreadsheet for processing and result analysis.
Fig. 4.6 The CSMA/CA

performance evaluation
testbed
Both the simulation and experimentation scenarios conditions are considered

identical. Nevertheless, it is reasonable to admit that the experimental results suffer
from uncontrollable factors, such as RF interferences, processing limitations and
memory constraints. Moreover, TinyOS also imposes some limitations that may
impact in the network behavior since it is not a real-time operating system.
4.2.2 Performance Analysis
4.2.2.1 BO and SO Effect
In this section the simulation and the experimental results are presented and briefly
analyzed. Setting BO and SO is one of the most important tasks of the PAN
Coordinator. By changing the inter-arrival times, it was possible to achieve dif-
ferent traffic loads (G values). Figure 4.7 presents the results concerning Network
Throughput (S) obtained through simulation (Fig. 4.7a) and from the hardware
testbed (Fig. 4.7b), for different BO=SO settings.
As expected, with low SO settings lower Network Throughput levels are
achieved. This is due to two factors. First, with lower SO settings the overhead of
the beacon frame is much more significant since beacons are more frequent.
Second, CCA deference is more frequent, which leads to more collisions at the start
of each superframe. Increasing the superframe order above SO = 5 has very little
effect in the Network Throughput, since the probability of deference is much lower,
thus reducing the amount of collisions and leading to a higher S around 68 %.
If greater superframe durations are considered, some node can start its trans-
mission before other nodes wake up. These latter nodes will then sense the channel
busy, and thus go to backoff with higher backoff delay value (after increasing BE).
Therefore, the transmission deference problem is going to be more frequent with
lower superframe orders, as the interval between superframes is lower. The
probability of transmission deference is minimized with higher SO and when the
nodes have different SO enabling the transmissions with less challengers trying to
access the medium. As presented in Fig. 4.7b, the same behavior was observed
Fig. 4.7 Network throughput for different BO. a Simulation results. b Experimental results
Fig. 4.8 Probability of success for different BO. a Simulation results. b Experimental results
with the experimental testbed, however the maximum S achieved was lower than
in the simulation results (around 58 %).
Figure 4.8 compares the transmission Success Probability (Ps ) and the offered
load, for a given superframe order (SO). The results show that the probability of a
successful transmission is quite low when offered load increases, and particularly
lower for low SO due to the multiple collisions caused by deference as already
explained.
The comparison between simulation and experimental results for two SO
settings ( SO ¼ 7 and SO ¼ 1) is presented in Fig. 4.9.
Notice, that although the results are similar (the behavior predicted by the
simulation results holds), there is a difference of approx 10 % between simulation
and experimental throughput results. This might be mainly because the simulation
model does not consider the physical constraints of the MICAz mote, especially
the processing power, the TinyOS constraints and overheads and the normal
interferences of a real wireless medium.
4.2.2.2 Backoff Exponent
The backoff exponent (BE) is an important parameter in the backoff algorithm of

slotted CSMA/CA. It enables the computation of the random backoff delay before
trying to access the channel. The initial value of macMinBE is 3 but can be set in
the range of [0, 5]. Setting this value to 0 disables collision avoidance during the
first iteration of the algorithm.
The purpose of this section is to study the impact of the initialization value
macMinBE on network performance. The experiments (both in the simulator and
in the hardware deployment) run for different values of macMinBE—from 0 to 5.
For each configuration, the inter-arrival times of the packet generation in each
node was varied to have different offered loads with a constant packet size. Each
curve corresponding to a given macMinBE is obtained for thirteen or more dif-
ferent inter-arrival times.
As presented in Fig. 4.10 the network throughput depends on the initialization
value macMinBE, but, contrarily to what is expected, the network saturation
Fig. 4.9 Experimental versus simulation (BO ¼ SO ¼ 7 and BO ¼ SO ¼ 1)
Fig. 4.10 Impact of macMinBE value in the network throughput

throughput decreases when increasing the macMinBE. However, this does not mean
a worse behavior for higher macMinBE. In fact, the macMinBE has an important
influence on the amount of traffic sent to the network by the MAC sublayer (GMAC ).
In a small-scale network with only ten nodes, the increase of macMinBE reduces
the load effectively transmitted in the network. This is because high backoff delays
will cause more wasted backoff periods not used by any of the competing nodes.
This is explained by the small number of competing nodes in the network. As it is
expected, increasing the backoff delay interval (starting with high macMinBE)
results in a better success probability, while avoiding collisions in small scale
WSNs. Most of the traffic sent is correctly received for high macMinBEs.
4.3 Performance Analysis and Worst-Case Dimensioning

of ZigBee Cluster-Tree Networks
This section compares the analytical results based on the Network Calculus model
(briefly summarized in Sect. 3.1 and further detailed in [8]) with the experimental
results obtained through the use of IEEE 802.15.4/ZigBee technologies. The ana-
lytical results are computed using the Matlab tool presented in Sect. 3.1, and the
experimental results are obtained using a test-bed based on the TelosB motes [9].
4.3.1 Network Setup
The experimental test-bed (illustrated in Fig. 4.11a) consists of 7 clusters and 14

TelosB motes running the TinyOS [10] operating system with open source
implementation of the IEEE 802.15.4/ZigBee protocol stack [11]. For debugging
purposes, it has been used the Chipcon CC2420 packet sniffer [12] that provides a
Fig. 4.11 The test-bed deployment and sensory data traffic upper bounded by arrival curve adata .
a The test-bed deployment for Hsink ¼ 1. b The sensory data traffic
raw list of the transmitted packets, and the Daintree Sensor Network Analyzer
(SNA) [13] that provides additional functionalities, such as displaying the
graphical topology of the network.
The application running on the sensor nodes are configured to generate 5 bytes
at the data payload of every message. Hence, the maximum size of the MAC frame
is equal to MPDUmax ¼ 208 bits (i.e., MHR = 72 bits, MFR = 16 bits, NHR =
64 bits, and Data Payload = 56 bits) assuming only destination PAN identifier and
both source and destination addresses are present. Note that the maximum size of
frame is then equal to 256 bits (i.e., SHR + PHR + MPDUmax ). The minimum size
of frame is equal to PPDUmin ¼ 200 bits (i.e., SHR + PHR = 48 bits, MHR =
72 bits, MFR = 16 bits, NHR = 64 bits).
According to Eq. (3.4), the bandwidth guaranteed by one time slot for SO ¼ 4
is equal to 3.125 kbps with 100 % duty-cycle. Hence, in the experimental scenario
with a 12.5 % duty-cycle (i.e., BO ¼ BOmin ¼ 7), the guaranteed bandwidth of one
time slot is equal to RTS ¼ 3:125 0:125 ¼ 0:3906 Kbps. Let’s assume
TS
Nendnode ¼ 1. Then, according to Eqs. (3.7) and (3.8), the maximum arrival rates
of the sensory data are obtained as follows:
MAX
– rdata ¼ 455 bps for Hsink ¼ 2
MAX
– rdata ¼ 683 bps for Hsink ¼ 1
MAX
– rdata ¼ 911 bps for Hsink ¼ 0 (root)
MAX

As a result of rdata min rdata and rdata RTS , an average arrival rate equal to
rdata ¼ 390 bps, which corresponds to 3 frames (256-bit each) generated during
one Beacon Interval (BI = 1.96608 s), is considered. The burst tolerance is
assumed to be equal to bdata = 576 bits. Hence, each sensor node transmits sensory
data bounded by the arrival curve adata ¼ 576 þ 390 t.
Finally, let us summarize the complete network setting:
MAX rdata ¼ 390 bps

Nrouter ¼2
MAX bdata ¼ 576 bits
Nendnode ¼1
H¼2 IFS = 3.07 ms
SO ¼ 4 (SD = 245.76 ms) LCFP ¼ 15
BO ¼ 7 (BI = 1966.08 ms) x¼0
MPDUmax ¼ 208 bits macMaxFrameRetries ¼ 0
4.3.2 Network Planning
Interestingly, the proposed analytical methodology can be used for the planning of
the cluster-tree topology as well. Let us consider the example of a convergecast
application gathering sensory data at the root (i.e., Hsink ¼ 0) and using the net-
work settings as mentioned in Sect. 4.3.1. However, in this case, the largest
4.3 Performance Analysis and Worst-Case 79
feasible configuration of the worst-case cluster-tree topology is achieved for

MAX
Nrouter ¼ 2 and H ¼ 2. This means that a feasible worst-case cluster-tree topology
MAX
given by the parameters Nrouter and H satisfies the network constraints given by the
other parameters, namely rdata , bdata , SO, BO, MPDUmax , IFS, LCFP , x,
MAX
macMaxFrameRetries and Nendnode .
To obtain more illustrative results, the length of the IFS is reduced to the
minimum value defined by the 802.15.4 standard (see Sect. 3.1.1, rdata ¼ 25 bps,
SO ¼ 2, LCFP ¼ 14, and keep the other settings. Figure 4.12a presents the worst-
case end-to-end delay and Fig. 4.12b buffer requirement of the sink router as a
function of the height of the tree H and the maximum number of child routers
MAX
Nrouter . In other words, Fig. 4.12 presents all feasible configurations of the worst-
case cluster-tree topology, which satisfy a given network constraints. The
TOTAL
numerical values at the columns represent the total number of routers (Nrouter ) in
the network. It can be observed that there can be more feasible configurations for
the same number of routers. For instance, the total number of 31 routers can be
MAX
achieved with two configurations, namely H ¼ 2 and Nrouter ¼ 5 or H ¼ 4 and
MAX
Nrouter ¼ 2. The buffer requirements at the sink router are almost the same for both
configurations (22 kbits and 24.1 kbits, respectively), but the first configuration
provides around half of the worst-case end-to-end delay (De2e ¼ 22:76 s) com-
pared with the second configuration (De2e ¼ 44:56 s). On the other side, the
cluster-topology using the second configuration can spread out over a larger area
due to the higher height H. So the system designer must find a trade-off for a given
application-specific implementation.
4.3.2.1 Evaluation
Buffer requirements. Figure 4.13a presents the theoretical worst-case buffer

requirement of the routers at given depths and as a function of the sink position.
MAX
Fig. 4.12 The worst-case delay and buffer requirement as a function of Nrouter and H. a The
worst-case end-to-end delay. b The buffer requirement of the sink router
It can be observed that end-nodes have the smallest buffer requirement as they are
the leaves of the tree, and that the buffer requirement grows in the direction of the
sink router. Since the sink can be associate to any router in a WSN and in order to
avoid buffer overflow, all routers at depth i should allocate a buffer of capacity
equal at least to the maximum buffer requirement at a given depth i (e.g., all routers
at depth 0 allocate a buffer of capacity equal to 15.995 Kbits), which effectively
demonstrates how these analytical results can be used by a system designer.
Figure 4.13b shows the theoretical worst-case buffer requirements compared
with the maximum values obtained through real experimentation, for Hsink ¼ 2.
First, the theoretical buffer requirements are divided into three portions according
their origin. Observe that the cumulative effect of the burst is more important than
the cumulative effect of the service latencies. The effect of the service latencies
may be more important for other settings of bdata and rdata . So, the different settings
of the sensory arrival curve affect the buffer requirements. The minor effect of the
upstream service latency at depth 0 is given by priority rules, such that the data
arriving during the transmit GTS (i.e., over the upstream link) are stored in the root
until the receive GTS (i.e., downstream link), at the end of the same SD, is active
and data is dispatched.
Delay bounds. Figure 4.14 compares the worst-case, maximum and average
values of per-hop delays bound in each router, and the end-to-end delay bounds for
Hsink ¼ 2. A first observation confirms that theoretical results upper bound the
experimental results. The difference in theoretical worst-case (DTH max ) and experi-
mental maximum (DEXP max ) delays is given by the aforementioned continuous
and stepwise behaviors of the analytical model and test-bed, respectively.
The experimental delays comprise mainly the service latencies decreasing in the
direction of the sink. Hence, the maximum per-hop delays also decrease in the
direction of the sink, as can be observed in Fig. 4.14. The end-to-end delays
bounds are quite high, even though the bdata and rdata are low. This is mainly due to
high value of SO ¼ 4 (i.e., BI = 1.966 s). Hence, the end-to-end delay bounds can
be reduced using lower values of SO or higher bandwidth guarantees, using lower
IFS, for example. Observe also that the worst-case end-to-end delay obtained by
Fig. 4.13 The worst-case buffer requirement. a Buffer requirement as a function of the depth and
sink position. b Theoretical versus experimental
4.3 Performance Analysis and Worst-Case 81
Fig. 4.14 The theoretical versus experimental delay bounds
the per-flow approach introduces less pessimism than the delay from the per-hop
approach (roughly by 50 % smaller).
Duty-cycle versus timing performance. In Sect. 3.1.3 was mentioned that to
maximize the lifetime of a WSN, low duty-cycles are required. On the other hand,
low duty-cycles enlarge the timing performance of a WSN. These assumptions
were confirmed in Fig. 4.15, where the theoretical worst-case and experimental
maximum end-to-end delays are shown as a function of duty-cycle for Hsink ¼ 0.
Fig. 4.15 The theoretical worst-case and experimental maximum end-to-end delays as a function
of duty-cycle for Hsink ¼ 0
The value of SO is set to 4 and the decreasing duty-cycles are obtained by

increasing BO. Note that for SO ¼ 4, the minimum BO is equal to 7. To avoid the
lack of bandwidth for smaller duty-cycles, the average arrival rate must be reduce
MAX
to rdata ¼ 0:190 Kbps (note that rdata ¼ 0:195 Kbps for the smallest duty-cycle
equal to 3.125 %). The other network settings are the same as in previous
experiments. The theoretical worst-case end-to-end delays are obtained by per-hop
and per-flow approaches. The observation again confirms that the theoretical
results upper bound the experimental results, and the worst-case delay obtained by
the per-flow approach offers less pessimism than the delay from the per-hop
approach.
References
IEEE Standard for Information technology—telecommunications and information exchange
between systems—local and metropolitan area networks—specific requirements Part 15.4:
Wireless medium access control (MAC) and physical layer (PHY) specifications for low-rate
wireless personal area networks (WPANs), September 2006
2. A. Koubâa, M. Alves, E. Tovar, Gts allocation analysis in IEEE 802.15.4 for real time
wireless sensor networks, in Proceedings of the 14th Workshop on Parallel and Distributed
Real Time Systems (WPDRTS), Apr 2006
3. J.-Y. Le Boudec, P. Thiran, Network Calculus: A Theory of Deterministic Queuing Systems
for the Internet (Springer-Verlag, Berlin, 2001)
4. A. Koubâa, M. Alves, E.Tovar, A comprehensive simulation study of slotted csma/ca for
IEEE 802.15.4 wireless sensor networks, in Proceedings of the 5th Workshop on Factory
Communication Systems (WFCS), pp. 183–192, June 2006
5. I. OPNET Technologies, The opnet modeler network simulator version 15.0.a (2009)
6. P. Jurčík, A. Koubâa, IEEE 802.15.4/zigbee opnet simulation model v3.0 (2009). http://
www.open-zb.net
7. Texas Instruments, SmartRF Protocol Packet Sniffer, www.ti.com/tool/packet-sniffer
8. P. Jurčík, Real-time communication over cluster-tree wireless sensor networks. Ph.D.
programme on electrical engineering and information technology, Department of Control
Engineering, Faculty of Electrical Engineering, Czech Technical University in Prague, Czech
Republic in collaboration with CISTER-ISEP Research Unit, Polytechnic Institute of Porto,
Portugal, Prague, January 2010
9. Memsic, TPR2420CA TelosB Mote May (2013), http://www.memsic.com/wireless-sensor-
networks
10. Tinyos working group (2010). http://www.tinyos.net
11. A. Cunha, A. Koubâa, R. Severino, M. Alves, Open-zb: an open source implementation of the
IEEE 802.15.4/zigbee protocol stack on tinyos, in Proceedings of the 4th IEEE International
Conference on Mobile Ad-hoc and Sensor Systems (MASS), Oct 2007
12. Chipcon. C2420dk development kit datasheet (2009). http://www.ti.com
13. D. Networks, Daintree sensor network analyzer (sna) (2009). http://www.daintree.net
Part II
Quality of Service Amendments
The second part of this book presents some modifications to the 15.4 and ZigBee
protocols that make them perform better, particularly when scalability and quality-
of-service are at stake. Most of this add-ons are backward compatible with the
standard specifications, i.e. nodes supporting the new add-ons can still cooperate
with the ones implementing the ‘‘default’’ protocols. In the last part of the book, we
will see that some of these amendments are actually used in real-world applications.
Chapter 5
Amendments to the IEEE 802.15.4
Protocol
Abstract This chapter presents specific amendments to the IEEE 802.15.4, so that
some of the open issues that have been previously identified. In particular, a new
implicit GTS allocation mechanism (i-GAME) is proposed that over performs the
default one. Then, a node grouping mechanism (H-NAMe) is proposed so that the
hidden nodes problem is mitigated and consequently energy-efficiency, throughput
and latency are improved. Also, we present a very simple mechanism to exploit
differentiate the traffic based on multiple priority. Finally, an overview of several
improvements affecting the security and privacy of the messages against external
attacks and spoofing is presented. Importantly, all these mechanisms have been
implemented and integrated in the 15.4 protocol stack and experimentally
validated.
5.1 Implicit GTS Allocation Mechanism
The IEEE 802.15.4 Medium Access Control (MAC) protocol has the ability to
provide very low duty cycles (down to 0.006 %) as well as real-time guarantees by
using the Guaranteed-Time Slot (GTS) mechanism. This feature is quite attractive
for time-sensitive WSNs. In fact, when operating in beacon-enabled mode, the
IEEE 802.15.4 protocol allows the allocation/deallocation of GTSs in a superframe
for nodes that require real-time guarantees. Hence, the GTS mechanism provides a
minimum service guarantee for the corresponding nodes and enables the prediction
of the worst-case performance for each node’s application.
However, the GTS mechanism, as proposed in the standard [1], presents some
limitations in terms of efficiency and deployment in WSNs with a large number of
nodes. In fact, during each superframe (divided into sixteen time slots) only up to
seven GTSs (1 up to 15 time slots per GTS) can be allocated, forming the
Contention-Free Period (CFP) (see Fig. 1.5). The remaining time slots in the
superframe compose the Contention Access Period (CAP) using Carrier Sense

86 5 Amendments to the IEEE 802.15.4 Protocol
Multiple Access with Collision Avoidance (CSMA/CA) as a MAC protocol. Since

each GTS is exclusively assigned to one node, the number of nodes involved in the
CFP is limited to seven or less. This is because the IEEE 802.15.4 standard
assumes that a node performs an explicit GTS allocation request by asking the
PAN coordinator for a certain number of time slots. A node is allowed to transmit
during the CFP, if the number of available time slots in the superframe is higher
than requested, and the minimum CAP length is not violated due to the allocation.
Two negative impacts may result from this explicit allocation scheme: (i) the
GTSs can be quickly consumed by a few number of nodes, preventing the others
from having a guaranteed service; and (ii) a node with a low arrival rate that has
been allocated a GTS, may use it only partially (when the amount of guaranteed
bandwidth is higher than its arrival rate). This leads to underutilization of the GTS
bandwidth resources. Due to the prefixed time slot duration in a superframe, it is
practically impossible to balance the arrival rate of a node and its guaranteed GTS
bandwidth. The amount of wasted bandwidth increases with the variance between
the guaranteed bandwidth and the arrival rate. Note that this wasted bandwidth can
be used by the CAP.
Moving from what has been recently proposed in [2], in this section a simple
and effective solution to overcome the previously described limitations of the
explicit GTS allocation in the IEEE 802.15.4 protocol is summarized.1 Basically,
the idea consists in sharing the same GTS between multiple nodes, instead of being
exclusively dedicated to one node, if a certain schedule that satisfies the
requirements of all requesting nodes exists. Sharing a GTS by several nodes means
that the time slots of this GTS are dynamically allocated to different nodes in each
superframe, according to a given schedule. In contrast, an explicit allocation
statically devotes a GTS to only one node in all subsequent superframes. Hence,
the GTS allocation mechanism proposed is based on the traffic specification of the
requesting nodes, their delay requirements, and the available GTS resources.
Instead of asking for a fixed number of time slots, a node that wants to have a
guaranteed service sends its traffic specification and delay requirement to the PAN
coordinator. Then, the latter runs an admission control algorithm based on this
information and the amount of available GTS resources. The new allocation
request will be accepted if there is a schedule that satisfies its requirements and
those of all other previously accepted allocation requests; otherwise, the new
allocation request is rejected. This mechanism is referred as the implicit GTS
allocation mechanism (i-GAME). The ability of i-GAME to accept multiple flows
sharing the same GTS, while still meeting their delay requirements is clearly
shown in [2] and summarized in what follows. It also improves the utilization of
the CFP by reducing the amount of wasted bandwidth of GTSs and maximizes the
duration of the CAP, since the CFP length is reduced to a minimum.
1
Here the focus is on the implementation of the mechanism, while the theory behind it, which is
based on the Network Calculus analysis, is not reported. Interested reader can refer to [2].
5.1 Implicit GTS Allocation Mechanism 87
5.1.1 i-GAME Implementation Guidelines
Besides the details of the mechanism for which the reader is redirected to [2], in
this section the focus is on presenting some practical considerations for the
implementation of the i-GAME mechanism in IEEE 802.15.4. An interesting
feature of i-GAME is that its implementation only requires minor add-ons to the
standard protocol, i.e., it does not impose any changes to the existing protocol.
The idea consists in using the reserved 6th bit in the GTS characteristics frame,
embedded in a GTS allocation request command field (compare Fig. 5.1 and
Fig. 1.5). This bit is referred to as Allocation Type.
The Allocation Type bit set to 0 corresponds to an explicit GTS allocation. In
this case, the allocation process will follow the standard recommendations. If it is
set to 1, it refers to the i-GAME implicit allocation mechanism detailed in [2]. In
this case, to keep the IEEE 802.15.4 with no changes, the flow specification
information Fspec ¼ ðb; r; DÞ2 should be embedded in the higher layer packets, as
presented in Fig. 5.2.
An admission control algorithm, such as the one presented in [2], should be
implemented at a higher layer (e.g., Network Layer) and should return the decision
to the MAC sublayer (Fig. 5.3). Hence, upon reception of an implicit GTS allo-
cation request (Allocation Type = 1), the MAC sublayer of the PAN coordinator
should forward the Flow Specification Field (shown in Fig. 5.2) to the higher layer
for processing by the admission control module. The burst size and the arrival rate
fields should be expressed by four bits each (16 classes for each field). The Delay
Requirement field is expressed by five bits (32 classes). Using this frame format,
the PAN coordinator should define a fixed range for each value (class) of the
corresponding field. These patterns should be known in advance by all nodes
associated to the PAN before initiating an implicit allocation.
Fig. 5.1 The GTS characteristics extension field format for implicit request allocation
Fig. 5.2 The flow specification field format for i-GAME
2
b is the burst size, r is the arrival rate and D the maximum delay requirement.
Fig. 5.3 The protocol layer

architecture for i-GAME
The specification of these classes and ranges is out of the scope of this work and
are generally application dependent. When the flow specification is received by the
admission control module, it evaluates the acceptance of the new flow based on
the [2, Algorithm 2]. The decision should then be notified to the MAC sublayer
through the service access point. In case of acceptance, the MAC sublayer allo-
cates the time slots in the CFP in round robin order to all accepted nodes. For that
purpose, the MAC sublayer should establish a certain order to allocate the time
slots according to round robin scheduling. Each beacon frame of a new beacon
interval should indicate which nodes are allowed to use the GTS in the current
superframe, with respect to the established order.
5.1.2 Experimental Evaluation
A complete implementation of the IEEE 802.15.4 protocol has been formerly done
under TinyOS operating system [3] and running in MICAz motes [4]. The explicit
GTS allocation mechanism has been implemented in the MAC layer module as an
interface between the MAC and the Network layers, according to the IEEE
802.15.4 standard specification [1]. We have also implemented the i-GAME
admission control mechanism in the Network layer of a PAN Coordinator, based
on the implementation guidelines provided in Sect. 5.1.1 with only few add-ons to
the MAC layer. The i-GAME mechanism implementation does not affect the non-
coordinator nodes since they only require setting the Allocation Type bit in the
GTS request to the appropriate value: 1—implicit, 0—explicit.
5.1 Implicit GTS Allocation Mechanism 89
To demonstrate the performance of the proposed amendment, we set up an IEEE

802.15.4 WPAN in a beacon-enabled mode with one PAN Coordinator and 7 nodes
distributed within the transmission range of the PAN Coordinator. The superframe
structure is configured with a beacon order BO ¼ 3 and a superframe order SO ¼ 3.
Each node runs an application that generates periodic traffic with a period
P ¼ 200 ms and a frame size L ¼ 120 bits (104 bits of MAC header + 16 bits of
data payload). The arrival curve aðtÞ ¼ b þ r t corresponding to this periodic data
flow is defined by the average rate r ¼ L/P ¼ 0:6 kbps and the burst size
b ¼ L ¼ 120 bits [5]. In this scenario, we have experimentally evaluated the
bandwidth guaranteed by one time slot, which was found to be equal to
RTS ¼ 2:70 kbps. This small value is due to the acknowledgment overhead in each
data frame transmission.
Since in Sect. 5.1.1 16 classes to map the burst size and the average rate, and 32
classes to map the delay bound were defined, we have configured the mapping
table in the PAN Coordinator and in the nodes as presented in Table 5.1.
Hence, based on the Flow Specification frame format (Fig. 5.2), a node using the
i-GAME mechanism for requesting an implicit GTS allocation should configure his
request by choosing the corresponding classes. Thus, assuming for instance a delay
bound of 300 ms, nodes that send implicit GTS allocations configure their Flow
Specification Field to the value (0 9 1, 0 9 0, 0 9 0), which will be interpreted by
the PAN Coordinator as the following flow specification Fspec;i ¼ ðbi ¼ 120 bit;
ri ¼ 0:6 kbps; Di ¼ 300 msÞ. Note that the configuration mapping table will
depend on the application requirements and should be adapted either manually by
the designer or automatically according to a user-defined specification. Neverthe-
less, note that this table will apply to all nodes in the WPAN.
To observe the impact of the delay requirement on the improvement of the GTS
efficiency, we have run the experimental test bed for three scenarios, in which
nodes choose the delay classes (0 9 1, 0 9 2, and 0 9 3) for their delay
requirements according to Table 5.1. The results are plotted in Fig. 5.4 and per-
fectly confirmed by the analytical formulations. Observe that relaxing the delay
bound of 7 nodes requesting GTS enables to save, in the case of 900 ms of delay
requirement, up to 5 time slots ( 42 ms) as compared to explicit allocation, while
still satisfying the delay bounds. This (saved) time can be used by the contention-
access period, thus improving the utilization of the network.
Table 5.1 Class mapping configuration

Class Burst size (bits) Arrival rate (kbps) Delay bound (ms)
090 80 0.6 300
091 120 1.2 500
092 160 2.4 700
093 200 4.8 900
Default 1016 9.6 2000
Fig. 5.4 Number of nodes allocating a GTS with i-GAME versus the GTS length
5.2 Hidden Node Avoidance Mechanism
In wireless contention-based Medium Access Control protocols, if two nodes that

are not visible to each other transmit to a third node that is visible to the formers,
there will be a collision as illustrated in Fig. 5.5—usually called hidden-node or
blind collision. Due to factors such as the limited communication range of sensor
nodes, link asymmetry and the characteristics of the physical environment, the
hidden-node problem has been shown to be a major source of QoS degradation in
WSNs. In particular, the following three performance metrics are affected:
(i) throughput, which denotes the amount of traffic successfully received by a
destination node and that decreases due to additional blind collisions; (ii) energy-
efficiency that decreases since each collision causes a new retransmission;
(iii) transfer latency, which represents the time duration from the generation of a
message until its correct reception by the destination node, and that becomes larger
due to the multiple retransmissions of a collided message.
Figure 5.6 presents an example obtained with our OPNET simulation model for
the IEEE 802.15.4 protocol (Sect. 3.2), just to highlight the negative impact of the
hidden-node problem. We considered a star network spanning on a square surface
(100 9 100 m2 ) with 100 nodes, where traffic generation followed a Poisson
distribution. The throughput is shown for different transmission ranges of the
nodes. The transmission range of the nodes has been changed by setting different
receiver sensitivity levels. The degradation of the throughput performance due to
hidden-node collisions is clearly noticeable. This is due to the increase of the
hidden-node collision probability when decreasing the transmission range.
In the literature, several mechanisms have been proposed to solve or mitigate
the impact of the hidden-node problem in wireless networks. A thorough enu-
meration of these techniques is available in [6].
5.2 Hidden Node Avoidance Mechanism 91
Fig. 5.5 A hidden-node collision
Fig. 5.6 Hidden-node impact on network throughput
However, to our best knowledge, no effective solution to this problem in WSNs

was proposed so far.
In [7], an efficient solution to the hidden-node problem in synchronized cluster-
based WSNs is presented. The proposed approach is called H-NAMe and is based
on a grouping strategy that splits each cluster of a WSN into disjoint groups of
non-hidden nodes (where all nodes have bi-directional connectivity) and assigns a
different time window to each group during the CAP. The set of time windows
assigned to node group transmissions is defined as Group Access Period (GAP). In
this way, nodes belonging to groups can transmit without the risk of hidden-node
collisions. It then scales to multiple clusters via a cluster grouping strategy that
guarantees no transmission interference between overlapping clusters. Details of
this mechanism are not reported here due to space constraints, but interested
readers can refer to [7].
5.2.1 H-NAMe in IEEE 802.15.4/ZigBee
In this section, we explain how to instantiate the H-NAMe mechanism to the IEEE
802.15.4 protocol, namely addressing beacon-enabled cluster-tree networks. This
topology is scalable and enables energy-efficient (dynamically adaptable duty-
cycles per cluster) and real-time communications. In addition, the cluster-tree
topology fits into the H-NAMe network model [7].
Basically, the idea is that using the H-NAMe algorithm, groups of nodes can be
defined in terms of their mutual collision domain to each of them a time window in
each superframe duration will be allocated. The idea is to use part of the CAP for
the GAP, as illustrated in Fig. 5.7. Note that a minimum duration of 440 symbols
must be guaranteed for the CAP in each superframe [8].
In the intra-cluster grouping strategy, a node that has been assigned a group will
track the beacon frame for information related to the time window allocated to its
group, and will contend for medium access during that period with the other nodes
of the same group. The GAP Specification field is depicted in Fig. 5.8 to be
embedded in the beacon frame.
The GAP is specified by the Group ID field that identifies the node group. Up to
8 groups per cluster can be defined. The time window in the superframe is specified
by a given number of Backoff Periods (BP). A group is then characterized by its
start time slot and end time slot (between 0 and 15) and the corresponding backoff
period offsets, which are computed by an empirical formula such as:
Fig. 5.7 CAP, GAP and CFP in the Superframe
Fig. 5.8 GAP specification field of a beacon frame

RelativeOffset ¼ ðStart=EndÞBackoffPeriodOffset 2SO

This GAP implementation approach only requires two bytes of overhead per
group. The maximum number of groups depends on the SO values, since lower
superframe orders cannot support many overhead in the beacon frame due their
short superframe durations. Also, it allows a flexible and dynamic allocation of the
groups, since all nodes continuously update their information about their group
start and end times when receiving a beacon frame, at the beginning of each
superframe.
5.2.2.1 Setup
The H-NAMe mechanism has been implemented in nesC/TinyOS [9], over the
first Open-ZB implementation [3] of the IEEE 802.15.4/ZigBee protocols, to
demonstrate its feasibility and efficiency using commercial-off-the-shelf (COTS)
technologies.
For that purpose, a thorough experimental analysis was carried out to under-
stand the impact of the H-NAMe mechanism on the network performance, namely
in terms of network throughput (S) and probability of successful transmissions
(Ps ), for different offered loads (G), in one cluster with a star-based topology. Both
metrics have been also used to evaluate the performance of the Slotted CSMA/CA
MAC protocol. S represents the fraction of traffic correctly received normalized to
the overall capacity of the network (250 kbps). Ps reflects the degree of reliability
achieved by the network for successful transmissions. This metric is computed as
the throughput S divided by G, representing the amount of traffic sent from the
application layer to the MAC sub-layer, also normalized to the overall network
capacity.
To have a clearer idea on the impact of the hidden-node phenomenon inde-
pendently from other parameters, a superframe order sufficiently high (SO ¼ 8)
has been chosen to avoid the collisions related to the CCA deference problem
encountered for low SO, in the slotted CSMA-CA mechanism, as presented
in [10]. The CCA deference problem occurs when it is not possible for a frame to
be transmitted in the remaining space of the superframe and its transmission must
be deferred to the next one.
The experimental test-bed consisted of 18 MICAz motes [4] scattered in three
groups hidden from each other, a ZC and a protocol analyzer Chipcon
CC2420 [11], capturing the traffic for processing and analysis (Fig. 5.9).
The protocol analyzer generates a log file containing all the received packets
and the corresponding timestamps, enabling to retrieve all the necessary data
embedded in the packets payload. The 18 nodes have been programmed to
Fig. 5.9 Experimental testbed
Fig. 5.10 Groups allocation in the superframe
generate traffic at the application layer with preset inter-arrival times. The three
node groups were placed at ground level near walls, in order to reinforce the
hidden-node effect (Fig. 5.9).
Figure 5.10 presents the GAP created by the H-NAMe mechanism.
Each node group was assigned with four time slots for transmission, which
represents a theoretical duration of 983.04 ms per group (SO ¼ 8). This allocation
was made according to the principle of equal group access duration for an equal
number of nodes per group.
5.2.2.2 Results
The performance evaluation of the H-NAMe mechanism has been carried out
using BO ¼ SO ¼ 8 (100 % duty cycle), with a constant frame size of 904 bits.
Several runs were performed (one for each packet inter-arrival time), to evaluate
the network performance at different offered loads (G).
Fig. 5.11 Experimental performance results
Figure 5.11 presents the throughput (S) and the success probability (Ps )
obtained from three experimental scenarios: a network with hidden-nodes without
using the H-NAMe mechanism (triangle markers curve); the previous network
using the H-NAMe mechanism (circle markers curve) and a network without
hidden-nodes (square markers curve). The depicted average values for the
throughput and probability of success were computed with a 95% confidence
interval for a sample size of 3000 packets at each offered load. The respective
variance is displayed at each sample point by a vertical bar in black. From these
results, we can observe that even at low offered loads H-NAMe leads to a con-
siderable performance improvement. For instance, for an offered load (G) of 30 %,
the success probability (Ps ) using H-NAMe is roughly 50 % greater than without
H-NAMe.
Considering higher loads, it is clear that the H-NAMe doubled the throughput
of the conventional network with hidden-nodes. At 90 % of offered load (G), the
throughput of the network using H-NAMe reached 67 % and is increasing, while
without using H-NAMe a saturation throughput of 32 % is achieved, representing
an improvement of more than 100 %.
In conclusion, the H-NAMe mechanism presents a significant improvement of
the network performance in terms of throughput and success probability, at the
small cost of some additional overhead to setup the different groups in the
networks.
5.3 Traffic Differentiation Mechanism for CSMA/CA
It was already stressed that the IEEE 802.15.4 standard [1] supports timeliness
QoS through the mechanism of the GTS, which enables a deterministic access to
the medium, but it has several limitations, in particular for higher traffic loads
conditions.
Therefore, while GTS is considered a good solution for the QoS requirement of
the low-rate WPAN applications (for which IEEE 802.15.4 was originally
designed), the requirements of dense sensor networks demand a more flexible
mechanism where QoS support be extended to the CAP.
5.3.1 Traffic Differentiation Strategy
As shown in [12, 13], the behavior of slotted CSMA/CA is mostly affected by four
initialization parameters, which are: (i) the minimum back-off exponent (mac-
MinBE), (ii) the maximum back-off exponent (aMaxBE), (iii) the initial value of
the CW (CWinit) and (iv) the maximum number of back-offs (macMaxCSMA-
Backoffs). Changing the value of any of these parameters will have an impact on
the performance. For instance, a performance valuation study in [10] has shown
that the average delay of broadcast frames increases with macMinBE, whereas the
probability of success remains independent of macMinBE in large-scale WSNs.
However, the probability of success increases for high macMinBE values, in small-
scale WSNs. Based on those observations, we propose to offer differentiated
services for time-critical messages. In this section, the service differentiation
mechanisms are particularly based on the macMinBE, aMaxBE and CWinit
parameters.
Note that IEEE 802.15.4 defines two frame types: (i) data traffic, which typ-
ically represents sensory data broadcast to the network (without using acknowl-
edgments), and (ii) command traffic, which comprises critical messages (such as
alarm reports, PAN management messages and GTS allocation requests) sent by
5.3 Traffic Differentiation Mechanism for CSMA/CA 97
Fig. 5.12 Differentiated

service strategies
sensor nodes to the PAN Coordinator. Due to their importance, command frames
are sent using acknowledged transmissions and require a particular QoS support to
be delivered to their destination in a bounded time interval. We consider command
frames as the high priority service class and data frames as the low priority service
class. The differentiated service strategies are presented in Fig. 5.12. The idea is
simple. Instead of having the same CSMA/CA parameters for both traffic types,
each class is assigned to its own attributes.
Let’s assume (i) [macMinBEHP , aMaxBEHP ] and CWHP as the back-off interval
and the contention window initial values for high priority traffic, related to com-
mand frames, and (ii) [macMinBELP , aMaxBELP ] and CWLP the initial values for
low priority traffic, related to data frames. While, the slotted CSMA/CA described
in Sect. 1.2.2.4 remains unchanged, the adequate initial parameters that corre-
spond to each service class must be applied. In addition to the specification of
different CSMA/CA parameters, Priority Queuing can be applied to reduce
queuing delays of high priority traffic (Fig. 5.12). In this case, slotted CSMA/CA
uses priority scheduling to select frames from queues, and then applies the ade-
quate parameters corresponding to each service class. Note that if a low priority
frame is selected, i.e., the high priority queue is empty, then the back-off process
corresponding to this frame will not be preempted by a high priority frame arriving
during that service time. It will have to wait until the low priority frame is sent, or
rejected if the maximum number of back-off is reached.
The heuristics for adequately setting the CSMA/CA parameters are the fol-
lowing. Intuitively, a first differentiation consists in setting CWHP lower than
CWLP . It results that low priority traffic has to assess the channel to be idle for a
longer time before transmission. A second differentiation is related to the back-off
interval. Providing lower back-off delay values for high priority traffic by setting
macMinBEHP lower than macMinBELP would improve its responsiveness without
degrading its throughput, as it has been observed in [12], where these intuitive
heuristics were previously evaluated.
5.3.2 Implementation Approach
The mechanism was implemented over the open-ZB [3] IEEE 802.15.4 stack
implementation in ERIKA [14] Real-Time Operating System (RTOS). ERIKA is a
multiprocessor RTOS kernel for embedded devices, which implements a set of
Application Programming Interfaces (APIs). That version of the open-ZB protocol
stack implementation was specially designed to cope with the stringent timing
requirements imposed by the IEEE 802.15.4 operating in beacon-enabled mode.
As shown in [15], fulfilling these requirements can become quite challenging at
high duty-cycles or if the network traffic considerably increases, when relying on
other operating systems like TinyOS, which do not provide any kind of real-time
guarantees. Because of this fact and since the performance assessment of the
proposed mechanism involves a significant stress on the network, and conse-
quently in the OS and protocol stack, this platform was chosen to assess and
validate the traffic differentiation strategies.
Implementing the mechanisms of traffic differentiation imposed few minor
modifications to a those MAC functions in charge of queuing/dequeuing messages
and initializing the slotted CSMA/CA parameters. Everything else remained
unchanged. A thorough description of the implementation is carried out in [16].
In order to keep the system backward compatible, a new mode of operation
(TRADIF) was implemented in addition to the standard IEEE 802.15.4 imple-
mentation, in such a way that it could be enabled or disabled. In TRADIF mode,
support was provided for the two queuing strategies: FIFO and PQ. Since in the
proposed mechanism only two priority levels are assumed, Priority Queuing mode
support has been provided by maintaining two transmission queues: High Priority
(HP) queue and Low Priority (LP) queue.
In the standard mode, when a message is to be sent, it is enqueued in the send
buffer and its transmission is triggered. This is unchanged for the FIFO mode of
TRADIF. In Priority Queuing mode, when a message is to be sent, it is enqueued
in the High Priority (HP) or Low Priority (LP) Queue, depending on the priority of
the message.
We carried out a thorough experimental analysis of TRADIF to understand the

impact of these mechanisms on the network performance, namely in terms of net-
work throughput (S) and probability of successful transmissions (Ps ), for different
offered loads (G), in one cluster with a star-based topology. Both metrics (S, Ps )
have been also used to evaluate the performance of the Slotted CSMA/CA MAC
protocol in Sect. 4.2 and in [10]. The network throughput (S) represents the fraction
of traffic correctly received normalized to the overall capacity of the network
(250 kbps). The success probability (Ps ) reflects the degree of reliability achieved
by the network for successful transmissions. This metric is computed as the
throughput S divided by G, representing the amount of traffic sent from the appli-
cation layer to the MAC sub-layer, also normalized to the overall network capacity.
5.3.3.1 Testbed Setup
The experimental setup consisted of five FLEX boards [17] programmed with the
open-ZB [3] IEEE 802.15.4 implementation over the ERIKA operating system
with the traffic differentiation add-on.
One of these devices was programmed as Coordinator and the others as End
Devices. The End Devices were used to generate traffic, both high and low pri-
ority, while the Coordinator, apart from synchronizing the devices through beacon
transmission, was also used to manage the experiment by transmitting control
information included in its beacon payload.
The payload included information about the amount and type of traffic to be
generated by the end devices and signals to start and end the experiment.
This information was sent to the Coordinator device through a serial port
connection. The end devices, upon receiving the beacon, would set the traffic
generator alarms (of both high and low priority), with intervals as specified in the
beacon payload.
To measure output parameters such as throughput, delays and queue overflows,
the same strategy was used. Different counters were inserted at various stages of
the transmission procedure, starting from the traffic generation at application layer
to transmission from the physical layer.
Finally, a Chipcon CC2420 packet sniffer [11] was used to capture the traffic
for processing and analysis. The packet analyzer generates a log file containing all
the received packets and the corresponding timestamps, enabling to retrieve all the
necessary data embedded in the packets payload. A parser application was
developed to carry out that task.
5.3.3.2 Experimental Evaluation
The set of experiments consisted of varying low priority traffic while keeping high
priority traffic constant, and measuring the throughput of the high priority traffic
for the different scenarios. The values of CSMA parameters used for each of these
scenarios are listed in Table 5.2.
Table 5.2 Test scenarios

Scenario ½macMinBEHP ; aMaxBEHP ½macMinBELP ; aMaxBELP CWHP CWLP
Sc1 [2,5] [2,5] 2 2
Sc2 [2,5] [2,5] 2 3
Sc3 [0,5] [2,5] 2 2
Sc4 [0,5] [2,5] 2 3
Although, the IEEE 802.15.4 standard [1] allows for a higher setting of aMaxBE,
(up to 8), we used the same scenarios to enable a fair comparison with the simulation
results in [12]. Each case was examined for FIFO as well as Priority Queuing
scheduling policies.
The network was set to work in full duty cycle with BO ¼ SO ¼ 6, with
no-hidden nodes, and the traffic generation was controlled using timers, generating
high priority frames at a rate of 40 frames/second and low priority frames ranging
from 3 frames/second up to 600 frames/second.
Several runs were carried out for each traffic interval stopping the experiment
every time the number of high priority packets received reached 1000. In the
following discussions, Application layer traffic is denoted by Gapp and the MAC
layer traffic by Gmac. Similarly, Gapphp and Gapplp are used to denote Application
layer high priority and low priority traffics, and Gmachp , Gmaclp used for MAC layer
high and low priority traffic, respectively.
Figure 5.13 shows the comparison of the success rates of the high priority
application traffic of the four scenarios of Table 5.2, for both FIFO and Priority
Queuing mode. These results are analogous to the ones obtained through simulation
in [12].
The contention window size for high priority frames is kept equal to 2 (standard
value) in all cases, while it is increased to 3 for low priority frames in Sc2 and Sc4. On
the other hand, the value of macMinBE is kept constant (2, standard value) for low
priority traffic in all cases, whereas it is set to 0 for high priority traffic in Sc3 and Sc4.
Concerning the FIFO mechanism, it can be observed that all three scenarios of
parameter tuning (Sc2, Sc3, Sc4) result in higher success rates compared to the
standard case (Sc1). Sc1, presents the lowest success probability. Sc3, in which
macMinBEHP is decreased to 0, results in improved success rates, but it is still very
close to the standard case (change of 0–5 %). This is so because setting
macMinBEHP lower than macMinBELP means lower back-off delays for high
Fig. 5.13 Probability of Success for FIFO and PQ mode

priority traffic (refer to slotted CSMA/CA algorithm, Fig. 1.8), but the number of
back-offs and contention window size, which are directly related to the contention
success probability, are unchanged. On the other hand, setting CWLP greater than
CWHP means that high priority traffic need the channel to remain idle for shorter
time before transmitting, which means higher probability of success in every
sensing attempt. The comparatively higher success rates in Sc2 and Sc4
(improvement of 20–25 %) reflect this, showing greater improvement in perfor-
mance by setting CWLP [ CWHP , compared to changing macMinBEHP .
A similar behavior is observed for PQ mode. For both queuing strategies,
results were very alike concerning scenarios 2 and 4, showing that the correct
setting of the CW has the greatest effect in the throughput of both queuing modes.
One of the noticeable changes from the FIFO cases is the fall of success proba-
bility of Sc3. Again, the effect of changing macMinBEHP , which would decrease
the back-off delay of high priority packet, does not make much difference on
contention success. Therefore, Sc1 and Sc3 have approximately the same success
rates for Priority Queuing at higher traffic loads.
Sc2 and Sc4, again have better success rates since setting having CWHP lesser
than CWLP means that high priority traffic need the channel to remain idle for
shorter time before transmitting and hence has more chances of success. In this
case again, changing CWLP to 3 improves the success rate of high probability
packets by 20–25 %. As shown, the priority queuing mechanism slightly improves
the probability of success when compared to FIFO. However, its main contribution
is in reducing the queuing delay as shown in [12], since the high priority queue
will always take precedence over low priority queue, thus reducing queuing delay
for high priority packets.
To separately evaluate the effect of the priority queuing mechanism, a single
sender was used to generate equal amount of high and low priority frames.
The queue size for both high and low priority queues was set to hold 15 messages.
The Application layer traffic generation rate was increased at equal rate. The
number of packets enqueued of both types was calculated by parsing the output file
of the sniffer used to receive packets.
Figure 5.14 shows the packets enqueued against the packets generated by the
application of both high and low priority. It is visible that beyond 20 % of channel
Fig. 5.14 Comparing

queuing success in Priority
Queuing
Fig. 5.15 Probability of Success for HP in Priority Queuing
capacity, while the low priority frames are dropped due to queue overflow, the
high priority frames are unaffected. Moreover, it indicates that at high traffic load,
priority queuing plays an important role in ensuring the precedence of high priority
frames. This will result in a lower queuing delay for high priority packets.
However, the improvement of this differentiation scheme to the throughput of high
priority command frames is more significant than the degradation of the
throughput of low priority data frames (Fig. 5.15), which further demonstrates the
efficiency of this differentiation mechanism. As shown, the Probability of Success
of low priority frames for PQ Sc2 and Sc4 is just slightly lower (5 %) at high
offered loads than with the default MAC, taking advantage of lower CW at lower
loads, thus increasing throughput.
5.4 Security Services
IEEE 802.15.4 provides a number of security services and makes them available to
the higher layers [1]. In particular, data confidentiality, data authenticity and replay
protection are supported on a per-frame basis. The standard includes a security
suite based on the Advanced Encryption Standard (AES) 128 bits symmetric-key
cryptography [18]. The security suite relies on three main elements: an Auxiliary
Security Header (ASH), security modes and settings, and security procedures.
In a generic MAC frame the MAC payload is prefixed with the MAC Header
(MHR) and appended with the MAC Footer (MFR). If communications are
secured, security information is included in the Auxiliary Security Header (ASH).
The IEEE 802.15.4 standard does not support security for ACK frames, other
frame types can optionally support encryption, authentication or both. To transmit
a secured frame, a node builds the ASH, inserts it next to the standard MAC
header, and secures frames before transmitting them (see Fig. 5.16).
5.4 Security Services 103
Fig. 5.16 Auxiliary Security Header Structure
The ASH carries all the information needed for security processing, including
(i) the Security control header containing security options, (ii) the Frame counter
for the anti-replay service, and (iii) the Key Identifier Field containing information
for key retrieval. According to the information carried within the ASH, recipients
retrieve the right cryptographic key and correctly unsecure MAC frames. The
Security Control field contains two relevant subfields: the Security Level subfield,
which indicates the actual frame protection provided, and the KeyIdMode, which
indicates whether the cryptographic key has to be obtained implicitly or explicitly.
5.4.1 Security Modes
IEEE 802.15.4 provides different ways to protect MAC frames:

• NO-SEC: no security;
• CTR: encryption only;
• CBC-MAC: authentication only;
• CCM: both encryption and authentication.
Each mode that supports authentication comes in three variants depending on the
size of the Message Integrity Code (MIC) it provides. The longer is the MIC, the
lower is the chance an adversary has to blind forgery by guessing an appropriate
code. In particular, each variant is considered a different security mode and has its
own name. Table 5.3 provides an overview of the security modes we deeply
explain in the following.
Table 5.3 Security level Name Data confidentiality Data authenticity

values and options
NO-SEC OFF NO
CBC-MAC-4 OFF 4 bytes MIC
CCBC-MAC-8 OFF 8 bytes MIC
CBC-MAC-16 OFF 16 bytes MIC
CTR ON NO
CCM-4 ON 4 bytes MIC
NO-SEC is the simplest security suite. Its inclusion is mandatory in all radio
chips. It does not manage any security material and does not provide any security
guarantee.
CTR provides confidentiality by using the AES block cipher with counter
mode. To encrypt frames, the sender splits the cleartext payload into blocks of 16
bytes each. Each block relies on a nonce, a varying fresh quantity aimed at
avoiding replay attacks. The sender includes the ASH in the clear and the
encrypted payload into the data payload field of the packet. Figure 5.17 shows the
format of a CTR encrypted frame.
CBC-MAC provides authentication by using either a 4, 8, or 16 bytes MIC. The
MIC can only be computed by parties with the symmetric key and protects the
frame header as well as the data payload. The sender appends the MIC to the plain
payload. The recipient recomputes the MIC and compares the result to the value
appended to the frame payload, so infering whether the frame is authentic or not.
Figure 5.18 shows the format of a CBC-MAC authenticated frame.
The CCM security mode allows for both encryption and authentication.
Broadly, CCM performs authentication as CBC-MAC does, but then it encrypts
both payload and MIC. Also CCM has three variants depending on the MIC size.
Figure 5.19 shows the format of an IEEE 802.15.4 frame when CCM is used.
Fig. 5.17 CTR Frame Format
Fig. 5.18 CBC-MAC Frame Format

Fig. 5.19 CCM Frame Format
5.4.2 Security-Related PAN Information
Security is provided according to information located in the security-related PAN

Information Base (PIB). The security-related PIB are presented in the following.
• The Key Table is a list of Key Descriptors. The Key Descriptor contains keys
and related key-specific information required for security processing;
• The Device Table is a list of Device Descriptors. The Device Descriptor
contains device-specific addressing and security-related information, which,
combined with key-specific information from Key Descriptors, provides all the
keying material needed to secure/unsecure frames;
• The Minimum Security Level Table contains information about the minimum
security level the specific device expects for a certain frame, depending on the
frame type and, if it concerns a MAC command frame, the command frame
identifier;
• The Frame Counter is 4 bytes counter incremented every time an outgoing
frame is secured. When the frame counter reaches its maximum value 09ffffffff,
the associated keying material can no longer be used, thus requiring the to be
updated. Also, the frame counter is involved in the nonce building to guarantee
protection against replay attacks.
• Automatic Request Attributes hold all information needed to secure outgoing
frames generated automatically rather than by a higher layer primitive, (e.g.:
automatic data requests);
• The Default Key Source is commonly shared between the originator and the
recipient(s) of a secured frame. It is used when the key retrieval procedure does
not involve a Key Source explicitly In these cases, the default key source is
combined with additional information explicitly contained in the requesting
primitive or in the received frame to retrieve the key required for securing or
unsecuring the frame;
• The PAN Coordinator Address is commonly shared between all devices in the
PAN.
5.4.3 Key Identifier Modes
The IEEE 802.15.4 standard provides four different Key Identifier Modes
(KeyIdModes), that is, four different ways to retrieve cryptographic keys. Namely:
KeyIdMode0, KeyIdMode1, KeyIdMode2 and KeyIdMode3. Ideally, the higher the
index is, the more complex is the key retrieval procedure. The KeyIdMode0 allows
nodes only to secure communications by means of a static, wide shared, single
key. KeyIdMode1 allows for using more keys, selected from the KeyTable by
means of the Default Key Source and the KeyIndex subfield of the ASH. The
KeyIdMode2 and the KeyIdMode3 allows for selecting keys from the Key Table
by means of the KeyIndex and the KeySource subfields of the ASH. The Key
Identifier field of the Auxiliary Security Header is present only if this subfield has a
value not equal to KeyIdMode0.
In KeyIdMode0, the key is determined implicitly by the originator and the
recipients of the frame. Figure 5.20 shows the structure of the ASH for this
KeyIdMode.
In KeyIdMode1, the key is determined from the Key Index subfield of the Key
Identifier field of the ASH, in conjunction with the Default Key Source from the
PIB. Figure 5.21 shows the structure of the ASH for this KeyIdMode.
In KeyIdMode2, the key is determined explicitly from the Key Source subfield
and the Key Index specified in the ASH. Figure 5.22 shows the structure of the
ASH for this KeyIdMode.
Similarly, in KeyIdMode3 the key is determined explicitly from the Key Source
subfield and the Key Index subfield of the Key Identifier field. As shown in
Fig. 5.23, it differs from KeyIdMode2 only for the Key Source subfield size.
5.4.4 Security Functional Description
If communications are secured, frames are transmitted according to the Outgoing

frame security procedure, and received according to the Incoming frame security
procedure. Figure 5.24 shows the main phases of the Outgoing frame security
procedure performed by a node to transmit a secured frame. Table 5.4 lists the
main features of the Outgoing frame security procedure and subprocedures it
invokes.
Fig. 5.20 KeyIdMode 0

Security Subheader Format
Fig. 5.21 KeyIdMode1

Security Subheader Format
Fig. 5.22 KeyIdMode2 Security Subheader Format
Fig. 5.23 KeyIdMode3 Security Subheader Format
Fig. 5.24 Outgoing frame security procedure schema
Table 5.4 Overview of procedures invoked when securing a frame

Name Input Output
Outgoing frame security procedure Frame to be Status of the procedure unsecured
secured frame
SecurityLevel
KeyIdMode
KeySource
KeyIndex
Outgoing frame key retrieval Frame to be Status of the procedure cryptographic
procedure secured key
SecurityLevel
KeyIdMode
KeySource
KeyIndex
KeyDescriptor lookup procedure Key lookup data Status of the procedure KeyDescriptor
Key lookup size
Fig. 5.25 Outgoing frame consistency checks
5.4.4.1 Outgoing Frame Security Procedure
Firstly, the Outgoing frame security procedure performs some consistency checks.
Figure 5.25 shows the sequence chart of these checks and the error codes reported
in case of failure. If the consistency checks succeed, the key is retrieved by using the
Outgoing frame key retrieval procedure. In case of failure, the procedure returns
with a status of UNAVAILABLE_KEY. Otherwise, it proceeds with the ASH
insertion and the encryption/authentication process. Finally, the procedure updates
the frame counter to the macFrameCounter attribute. If the frame counter reaches
the 09ffffffff value, the procedure returns with a status of COUNTER_ERROR.
In case of success, the procedure returns the secured frame.
5.4.4.2 Incoming Frame Security Procedure
Figure 5.26 shows the main phases of the Incoming frame security procedure
performed by a node when it receives a secured frame. Table 5.5 lists the main
features of the Incoming frame security procedure and of subprocedures it invokes.
Similarly to the outgoing frame procedure, the first step is performing some
consistency checks. Figure 5.27 shows the sequence chart of these checks and the
Fig. 5.26 Incoming frame security procedure schema
Table 5.5 Overview of procedures invoked when unsecuring a frame

Name Input Output
Incoming frame security Frame to be unsecured The unsecured frame
procedure SecurityLevel
KeyIdMode
KeySource
KeyIndex
Incoming security level checking SecurityLevel Status of the
procedure FrameType procedure
CommandFrameIdentifier
Incoming frame security Frame to be unsecured Status of the
material retrieval procedure procedure
KeyDescriptor
DeviceDescriptor
KeyDeviceDescriptor
Incoming key usage policy KeyDescriptor Status of the
checking procedure procedure
Frame type SecurityLevel
First octet of the MAC payload (only KeyIdMode
MAC command frames) KeySource
KeyIndex
KeyDescriptor lookup procedure Key lookup data Status of the
procedure
Key lookup size KeyDescriptor
Blacklist checking procedure KeyDescriptor Status of the
Device lookup data procedure
Device lookup size
error codes reported in case of failure. If the consistency checks succeed, the nodes
proceeds doing the Incoming security level checking procedure, the Incoming
frame security material retrieval procedure, and the Incoming key usage policy
checking procedure to retrieve the key and unsecure the frame.
Finally, the procedure increments the frame counter and sets the FrameCounter
element of the DeviceDescriptor to the resulting value. If the FrameCounter ele-
ment reaches the 09ffffffff value, it sets the Blacklisted element of the
KeyDeviceDescriptor.
5.4.5 Impact of Security on Performance
The IEEE 802.15.4 security mechanisms described above require a not negligible
amount of resources, in terms of both memory and power supply. Furthermore,
when communication is secured, a performance decrease is experienced. In par-
ticular, this is due to the communication overhead and the processing overhead
introduced by security (Fig. 5.27).
IEEE 802.15.4 security implementation requires a not negligible amount of
memory to contain three main components: (i) security data structures, such as the
Key Table or the Device Table, (ii) operations to manage them, and (iii) security
procedures. This should be seriously taken into account while implementing IEEE
Fig. 5.27 Incoming frame

consistency checks
802.15.4 security services, especially on devices provided with a short amount of

memory [19, 20].
Power saving is one of the most important aspects to consider while dealing
with sensor nodes. Typically, sensors are battery powered devices and are sup-
posed to operate without human intervention for months. Thus, the introduction of
security has a cost in terms of power consumption. When using security, IEEE
802.15.4 sensors require some further energy not only to perform security oper-
ations, but also to transmit secured frames. This is due to the presence of the ASH,
and potentially of the MIC, which results in frames that are larger in size.
As to the overhead introduced by the security services, it consists in two ele-
ments, i.e. a communication overhead and a processing overhead. The commu-
nication overhead is due to the extra bits that is necessary to transmit in the
presence of security, that is the ASH and the MIC field. The processing overhead is
due to the extra processing time needed to analyze the ASH, compute the MIC and
encrypt and/or authenticate MAC frames.
References
IEEE Standard for Information Technology—Telecommunications and Information Exchange
Between Systems— Local and Metropolitan Area Networks—Specific Requirements Part
15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for
Low-Rate Wireless Personal Area Networks (WPANs), September 2006
2. A. Koubâa, M. Alves, E. Tovar, A. Cunha, An implicit gts allocation mechanism in IEEE
802.15.4 for time-sensitive wireless sensor networks: theory and practice. Real-Time Syst. J.
39(1–3), 169–204 (2008)
3. A. Cunha, A. Koubâa, R. Severino, M. Alves, Open-zb: an open source implementation of the
IEEE 802.15.4/zigbee protocol stack on tinyos. In Proceedings of the 4th IEEE International
Conference on Mobile Ad-hoc and Sensor Systems (MASS), Oct 2007
4. MEMSIC MPR2400CB, 2.4GHz MICAz Processor Board, datasheet (2013), http://
www.memsic.com/wireless-sensor-networks
5. A. Koubâa, Y.-Q. Song, Evaluation and improvement of response time bounds for real-time
applications under non-pre-emptive fixed priority scheduling. Int. J. Prod. Res. 42(14),
2899–2913 (2004)
6. L.-J. Hwang, S.-T. Sheu, Y.-Y. Shih, Y.-C. Cheng, Grouping strategy for solving hidden node
problem in IEEE 802.15.4 lr-wpan. In Wireless Internet, 2005. Proceedings. First
International Conference on, pp. 26–32, July 2005
7. A. Koubâa, R. Severino, M. Alves, E. Tovar, Improving Quality-of-Service in Wireless
Sensor Networks by mitigating hidden-node collisions, IEEE. Trans. Ind. Info. 5(3),
299–313, August 2009
8. IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs). IEEE
P802.15 Wireless Personal Area Networks—MAC and Security Baseline Proposal—
Normative Text, March 2010. https://mentor.ieee.org/802.15/dcn/10/15-10-0196-02-0006-
mac-and-security-b
9. Tinyos working group, 2010. www.tinyos.net
10. A. Koubâa, M. Alves, E.Tovar, A comprehensive simulation study of slotted csma/ca for
IEEE 802.15.4 wireless sensor networks. In Proceedings of the 5th Workshop on Factory
Communication Systems (WFCS), pp. 183–192, June 2006
11. Texas Instruments, SmartRF Protocol Packet Sniffer, http://www.ti.com/tool/packet-sniffer

12. A. Koubâa, M. Alves, B. Nefzi, Y. Song, Improving the IEEE 802.15.4 slotted csma/ca mac
for time-critical events in wireless sensor networks. In Proceedings of the 5th Workshop on
Real Time Networks (RTN), July 2006
13. R. Severino, M. Batsa, M. Alves, A. Koubaa, A traffic differentiation add-on to the IEEE
802.15.4 protocol: Implementation and experimental validation over a real-time operating
system. In Proceedings of the 2010 13th Euromicro Conference on Digital System Design:
Architectures, Methods and Tools, DSD ’10, pp. 501–508, IEEE Computer Society,
Washington, DC, USA, 2010
14. Erika enterprise and rt-druid, 2012. http://erika.tuxfamily.org
15. A. Cunha, R. Severino, N. Pereira, A. Koubâa, M. Alves, Zigbee over tinyos: implementation
and experimental challenges. In Proceedings of the 8th Portuguese Conference on Automatic
Control (CONTROLO), pp. 911–916, July 2008
16. M. Batsa, Supporting different qos levels in multiple-cluster wireless sensor networks.
Master’s thesis, Computer Science and Engineering, Department of Electronics and
Computer Engineering, Indian Institute of Technology (IIT) Roorkee, September 2009.
defended Jan 2010
17. Evidence Srl, Via Carducci 56, Ghezzano, 56010 S.Giuliano Terme, Pisa - Italy. FLEX -
Modular soultion for embedded applications, September 2011. version: 1.0.2
18. National Institute of Standards and Technology. Federal Information Processing Standards
Publication 197, Specification for the ADVANCED ENCRYPTION STANDARD (AES),
November 2001
19. R. Daidone, G. Dini, M. Tiloca. On experimentally evaluating the impact of security on IEEE
802.15.4 networks. In International Conference on Distributed Computing in Sensor Systems
and Workshops (DCOSS), pp. 1–6, June 2011
20. R. Daidone, Experimental evaluations of security impact on ieee 802.15.4 networks. In PhD
Forum at IEEE International Symposium on a World of Wireless, Mobile and Multimedia
Networks (WoWMoM 2011), June 2011
Chapter 6
Amendments to the ZigBee Protocol
Abstract Similarly to the previous one, this chapter focuses on several amend-
ments to the ZigBee network layer, as proposed by the standard. In particular, a
cluster scheduling solution is proposed and paramount to achieve networking at
larger scales, while still be able to meet the quality of service requirements. Then
new routing algorithms are proposed based on the possibility to group several
nodes based on some common property, such as, e.g., their geographical position.
Finally, using the mechanisms defined at the Data Link layer, new security and
privacy mechanisms are available at the higher layers of the protocol stack.
6.1 Time Division Cluster Scheduling for ZigBee

Cluster-Tree Networks
This section presents the problem of how to schedule the activity portions of the
clusters in a cluster-tree ZigBee-like network [1, Sect. 1.4.2].
6.1.1 Motivation
Synchronization is a challenging and important issue for time-sensitive WSNs

since it requires a mutual spatio-temporal coordination between the nodes. The
IEEE 802.15.4/ZigBee protocols embody promising technologies for WSNs, but
are still ambiguous on how to efficiently build synchronized multiple-cluster
networks, specifically for the case of cluster-tree topologies.
In fact, the current IEEE 802.15.4/ZigBee specifications [2, 3] restrict the
synchronization to beacon-enabled (by the generation of periodic beacon frames)
star networks, while they support multi-hop networking in mesh topologies, but
with no synchronization. Even though both specifications mention the possible use

114 6 Amendments to the ZigBee Protocol
of cluster-tree topologies, which combine multi-hop and synchronization features,

the description on how to effectively construct such a network topology is missing.
In [4], this issue was tackled by unveiling the ambiguities regarding the use of the
cluster-tree topology and proposing a synchronization mechanism based on Time
Division Cluster Scheduling (TDCS) to build cluster-tree WSNs.
6.1.2 Problem Statement
As exemplified early in this book in Fig. 1.2c, a Cluster-Tree network is identified

by the ZigBee Coordinator (ZC), which is unique. The ZigBee Coordinator and the
ZigBee Routers send periodic beacon frames to synchronize the nodes in their
clusters. It is easy to notice that sending periodic beacon frames without special
care on timing issues may result in beacon frame collisions in some nodes that are
in the range of more than one coordinator. The Task Group 15.4b has identified
two types of collisions: (i) direct beacon frame collisions and (ii) indirect beacon
frame collisions. Both types are briefly explained next.
Direct beacon frame collisions occur when two or more coordinators are in the
transmission range of each other (direct neighbors or parent-to-child relation) and
send their beacon frames at approximately the same time, as illustrated in
Fig. 6.1a. In that example, assuming that node N1 is a child of ZR1, which sends
its beacon frame at approximately the same time as ZR2, node N1 loses its syn-
chronization with its parent ZR1 due to the collision of beacon frames from ZR1
and ZR2.
Fig. 6.1 The beacon frame collision problem. a Direct beacon frame collision. b Indirect beacon
frame collision
6.1 Time Division Cluster Scheduling for ZigBee Cluster-Tree Networks 115
Indirect beacon frame collisions occur when two or more coordinators cannot
hear each other, but have overlapped transmission ranges (indirect neighbors) and
send their beacon frames at approximately the same time (hidden-node problem),
as shown in Fig. 6.1b. Two undesirable situations may occur. The first is when a
child node N1, already associated to a parent coordinator ZR1, and the coordinator
ZR2 start both sending their beacon frames at almost the same time, therefore
resulting in the loss of the child node synchronization with its parent. The second
case is when two coordinators (in the example ZR1 and ZR2) belonging to the
same PAN cannot hear each other and send their beacon frames at the same time.
In this case, any node in the overlapping transmission range of both coordinators
will be prevented from joining the network. Note that collisions between data and
beacon frames may also happen, for example when a coordinator sends its periodic
beacon frame during the active period of an adjacent cluster. Hence, this problem
must also be dealt with.
The most intuitive idea is to organize beacon frame transmissions in a non-
overlapping way such that no beacon frame will collide with another even if
coordinators are in direct or indirect neighborhood. In addition, to avoid collisions
with data frames, a beacon frame must not be sent during the superframe duration
of another coordinator. Thus, the beacon frame scheduling problem comes back to
a superframe scheduling problem, since each superframe starts with a beacon
frame.
In [4], a Superframe Duration Scheduling (SDS) algorithm has been proposed,
while in [5] an optimization problem has been formulated and illustrated. In this
book, our goal is to give the intuition of how the mechanism can be implemented
to build Cluster-Tree networks. Any interested reader can refer to the above
mentioned references for more details.
6.1.3 Implementation Details of the TDCS Approach
The TDCS mechanism can be implemented in a simple manner, with only minor
add-ons to the protocol. The implementation of this mechanism assumes that: (i)
the ZigBee Network Layer supports the tree-routing mechanism (see Sects. 1.3.3
and 2.2.3), thus the network addresses of the devices are assigned accordingly; (ii)
the ZigBee Coordinator is the first node broadcasting beacons in the network; (iii)
the ZigBee Routers start to send beacons only after a successful negotiation; and
(iv) the same Beacon Interval (BI) is used by every ZigBee Router.
The TDCS approach relies on a negotiation prior to beacon transmission. Upon
success of the association to the network, a ZR (initially behaving as a ZED) sends
a negotiation message to the ZC (routed along the tree) embedding the envisaged
(BO, SO) pair, requesting a beacon broadcast permit. Then, in the case of a
successfully negotiation, the ZC replies with a negotiation response message
containing a beacon transmission offset (the instant when the ZR must start
transmitting the beacon, which is translated to the StartTime parameter of the
primitive MLME_START.request, i.e., the offset after the reception of the parent’s
beacons). In case of rejection, the ZR must disassociate from the network. Fig-
ure 6.2 depicts the architecture of the TDCS implementation in the IEEE 802.15.4/
ZigBee protocol stack.
The admission control algorithm which determines the schedulability is
implemented in the Application Support Layer, behaving as a service module of this
layer. The TDCS requires minor changes to the Network Layer. Thus, to assign a
value of the StartTime argument when calling the MLME_START.request primitive,
a new NLME_START_ROUTER.request primitive is needed. As mentioned before,
the StartTime parameter will be used as a transmission offset referring to the parent
ZigBee Router (ZR). In the ZC, the value of this parameter is 0.
After a successful negotiation of the beacon transmission, the ZR will have two
active periods: its own (the superframe duration) and the parent’s superframe
duration. In its own active period, the ZR is allowed to transmit frames to its
associated devices or relay frames to the descendant devices in the tree. The
frames destined upstream are sent during its parent’s active period.
During the ZR superframe, all the frames that need to be transmitted to its parent
are stored in the upstream buffer. When the device enters the parent superframe,
ittries to transmit the messages. Guaranteeing the synchronization of all devices is
the major challenge achieved by the MAC in its implementation (Sect. 2.1). The
devices must be always synchronized with their respective parents.
The negotiation of the beacon transmission is performed through a simple
protocol that uses the data frames payload with a predefined format.
Figure 6.3 depicts the Time Division Cluster Scheduling negotiation frame
format, which includes the following fields:
• Negotiation type Indicates the type of the negotiation command. This field can
have the following values: 1 for a negotiation request, 2 for a negotiation accept
and 3 for a negotiation deny.
• Beacon Order Indicates the beacon order of the ZR device.
Fig. 6.2 Time Division

Cluster Scheduling:
implementation architecture
6.1 Time Division Cluster Scheduling for ZigBee Cluster-Tree Networks 117
Fig. 6.3 Time Division Cluster Scheduling: negotiation field
• Superframe Order Indicates the superframe order of the ZR device.

• Transmission Offset Indicates the transmission offset schedule by the ZC in a
negotiation accept command.
In the negotiation request, the Beacon Order and Superframe Order fields indicate
the intended ZR superframe configuration. In the negotiation response, the con-
figuration may not be the same as the requested. Instead, the ZC can assign a
different BO, SO configuration according to its scheduling.
Figure 6.4 depicts a diagram with the sequence of Network Layer events from
the association of the ZR (Part A) until the beacon transmission after a successful
negotiation (Part B).
Finally, more illustrative examples and further implementation details of the
TDCS scheduling algorithm are available in [5, 6].
6.2 Geographical and Multicast Routing for ZigBee

Cluster-Tree Networks
Although the IEEE 802.15.4/ZigBee [2, 3] standard protocols have been shown as
prominent technologies for WSNs, this stack presents some gaps and limitations
that were addressed and amended in previous sections. In this section, the general
Fig. 6.4 Time Division Cluster Scheduling: negotiation diagram

problem of group communication in ZigBee cluster-tree networks is tackled, as it

has not been defined in the standard specification. In fact, the ZigBee Network
Layer does not define any of such a mechanism, neither in terms of routing nor in
terms of addressing. In particular, moving from our previous work [7, 8], multicast
and geographical routing will be described next.
6.2.1 Z-Cast: ZigBee Multicast Routing
In this section, the Z-Cast mechanism is proposed as detailed in [7]. It represents a

solution to support multicast in ZigBee-based WSNs. The objective of Z-Cast is to
provide an efficient data routing among all group members. We consider a ZigBee
cluster-tree WSN with different groups, where members of each group share the
same sensory information as defined in [9]. For instance, Fig. 6.5 illustrates the
grouping concepts and shows a group of four nodes A, F, H and K. It is clear that
simple communication between group members through simple broadcast is not
effective and may degrade the performance of the WSN. The use of multicast
routing is thus more efficient to improve throughput and reduce energy con-
sumption. It is therefore necessary that a message sent from a group member only
reaches the tree leaves that contain the group members. To achieve this objective,
a Multicast Routing Table (MRT) is created in the ZigBee Coordinator and in each
ZigBee Router, to store membership information of all the groups.
The proposed mechanism takes into consideration the number of the child
routers being members of a certain group to decide about the way that the packet
will be forwarded through the rest of the tree. In what follows, first the main
features of the multicast routing table are presented, then the multicast routing
algorithm for ZigBee cluster-tree WSNs is detailed.
Fig. 6.5 An example of a multicast group in the ZigBee cluster-tree network

6.2 Geographical and Multicast Routing for ZigBee Cluster-Tree Networks 119
6.2.1.1 The Multicast Routing Table
The Z-Cast Multicast mechanism relies on the creation of multicast routing tables
inside each ZigBee Router, to store the membership information of all nodes
belonging to a certain group in the network. The multicast routing table contains
two fields: Multicast_group_address and GMs_address. The Multicast_group_
address field is a 16 bit address; it contains the group Multicast_address that
identifies a certain group. The GMs_address field contains the list of the addresses
of the child nodes being members of the group all along the cluster-tree network.
Table 6.1 illustrates an example of the Multicast routing table in a ZigBee Router.
Routing Table Update. The MRT table entries must be updated for every join
and leave operations in the network. When a node joins a certain group, all ZigBee
Routers between the joining node and the ZigBee Coordinator must add the
multicast address of the group—if it does not exist—to the Multicast_group_
address field and the address of the joining node to the GMs_address field of their
MRT tables because the multicast message will be forwarded to the ZigBee
Coordinator before reaching the group members. Thus, a ZigBee Router must
know not only the membership information of its directly associated nodes, but
also all the membership information of the child Routers of its tree. By reaching a
ZigBee Router, Updating the MRT is very important as the proposed mechanism
relies on this table to decide if the multicast data will be forwarded by unicast or
broadcast, or instead it will be discarded.
When a node leaves a multicast group, all ZigBee Routers that are between the
leaving node and the ZigBee Coordinator (ZC) must delete the node address from
the GMs address. In the case when all the members have left the group, the
corresponding multicast group address entry must also be deleted from the MRT
table. Figure 6.6 illustrates an example of a joining operation where the ZigBee
Routers G and I update their multicast routing table accordingly, after nodes H and
K join the existing group. In this example, a network where Cm ¼ 4, Rm ¼ 4, and
Lm ¼ 3 is considered.
6.2.1.2 The Z-Cast Tree Routing Mechanism
In this section, the Z-Cast routing mechanism for ZigBee cluster-tree WSNs is
detailed. The Z-Cast routing mechanism comprises two main operations depending
where it is implemented: (i) an algorithm to be implemented in the ZC to decide on
Table 6.1 The multicast Multicast_group_address GMs_address

routing table
multicast_Addr1 node_address1, node_address2
multicast_Addr2 node_address2, node_address3
multicast_Addr3 0
Fig. 6.6 An example of updating the multicast table
how to route packets and (ii) an algorithm to be implemented in each ZigBee

Router to route multicast data efficiently in the network.
Routing in ZigBee Coordinator. A ZigBee Router can only check its child
routers by checking its MRT table, and it cannot check the other ZigBee Routers in
the network. It is then necessary to send the multicast message to the ZigBee
Coordinator before sending it to the group members because the ZigBee Coordinator
is the only node in the network that can send messages to any device in the network
and thus, the message will surely reach all the leaves and will be treated by all the
ZigBee Routers. Then the ZC adds a flag to the multicast message to indicate it has
already dealt with such a multicast message.
When a frame is received by the ZigBee Coordinator, it analyzes the frame and
checks if the destination address is a multicast or a unicast address. If it is a
multicast address, the ZC will add a flag to the frame and sends it to all its directly
connected child Routers. The flag is necessary to indicate that the frame is sent
from the ZigBee Coordinator. If a multicast frame comes to the ZigBee Router
without the flag, the packet must be sent to the parent device until reaching the
ZigBee Coordinator. By adding this flag, Z-Cast guarantees that the frame will
reach all ZigBee Routers in the network because the ZigBee Coordinator is the
only node that has the ability to send frames to all nodes in the ZigBee wireless
sensor network as ZigBee Routers are limited to their direct parents and children.
If the destination address of the frame contains a unicast address, the default
cluster-tree routing will be applied. When a group member wants to send a mul-
ticast packet to the other members belonging to its group, the request will be sent
by unicast to the ZigBee Coordinator passing through all the routers. Then, the
multicast packet is sent to the ZC and then to all the multicast group members
according to the entries of the multicast routing table and the cluster-tree routing
mechanism.
Routing in ZigBee Routers. When a multicast packet reaches a ZigBee

Router, there are different possibilities:
• If the multicast group address is not found in the MRT, then the multicast packet
will be discarded.
• If the multicast group address is found in the MRT, two different cases may
occur:
– If the field GMs_address contains only one member address of the corre-
sponding group, the packet will be transmitted by unicast to the group
member by applying the default ZigBee cluster-tree routing algorithm. The
unicast here is necessary because there is only one member in the leaf.
– If the field GMs_address contains two or more than two addresses of the
corresponding group members, the packet will be transmitted to all its direct
child nodes (ZigBee Routers and ZigBee End-Devices). Thus, the ZigBee
router does not need to know the complete membership information of all its
direct child nodes. This will considerably reduce the memory size of the
Z-Cast mechanism.
For more details, an illustrative example of the mechanism and further improve-
ments, reader is referred to [7, 10].
6.2.1.3 Implementation Guidelines
This section presents some practical considerations for the implementation of the
Z-Cast mechanism in IEEE 802.15.4/ZigBee. An important feature of Z-Cast is
that its implementation requires minor add-ons to the existing protocol.
The idea consists in classifying the 16-bit ZigBee address into two classes:
unicast addresses and multicast addresses. They are distinguished by the value of
the high-order 4 bits of the addresses: a value of 0xF (binary 1111) identifies an
address as a multicast address; any other value identifies an address as a unicast
address. Each device, upon the reception of a frame, reads the routing information
fields (Fig. 6.7) and checks the destination address.
If the destination address is a unicast address, the four high-order bits are
different from 1111 and the ZigBee tree routing algorithm will be applied. If these
four bits are set to 1111, it refers to the Z-Cast multicast mechanism. The multicast
routing algorithm should be implemented at the network layer like the cluster-tree
routing implementation and should return decision to the MAC layer.
Fig. 6.7 Network layer frame format [3]

If the routing destination address is a multicast address, the device must check
its multicast Routing Table to decide if the multicast packet will be routed to the
child devices or will be discarded. The fifth bit of the multicast address is reserved
to the ZigBee Coordinator ZC flag. If the ZC has received the multicast packet, it
sets the fifth bit to 1. Otherwise, this bit remains equal to 0. The multicast message
must be processed by the ZRs only if it comes from the ZC. Hence, upon reception
of a multicast packet, the ZR should check the origin of the multicast frame. If the
packet is coming from the ZC, the packet is processed. Otherwise, it will be routed
to the parent device until reaching the ZC.
6.2.2 Geographical Routing
In WSNs, while at the MAC and PHY levels of the classical ISO/OSI stack, the
protocols and algorithms are now well standardized, at the upper tiers of the
protocol stack there are still open issues and only recommendations from alliances
exist, like the ZigBee alliance [3, 11, 12].
However, in the ZigBee-like Cluster-Tree network architecture for real world
applications (see e.g., [8] and Chap. 8), it is often assumed that the flow of the
messages is only a point-to-multipoint downlink flow from the gateway (GW, or
the ZigBee Coordinator) to the rest of the nodes (e.g., for asking the nodes for
sensor readings or even propagate a new firmware for reprogramming purposes)
and a multipoint-to-point uplink flow backward (e.g., for sensor readings report).
Thus, only parent-child communication is really necessary1 and simple solutions
for routing can be applied, like the classical convergecast solution proposed for
ZigBee cluster tree (see Tree Routing in Sect. 1.3.3 or the Z-Cast solution in
Sect. 6.2.1). In this section a possible enhancement dealing with geographic
awareness is described.
In this case, a network like the one depicted in Fig. 6.82 is proposed. Assuming
the GW is the root of the tree, in general this device may also act as a special
cluster head (CH), having its own end devices (WSN Nodes) associated with it. In
Fig. 6.8, a two hop tree is considered, where each vertex of the tree is a Cluster
Head/ZigBee Router (CH, a.k.a. ZR) node. As a consequence, each vertex is
composed by a cluster of WSN Nodes, each of them having its own CH.
In Fig. 6.8, the connections among the nodes are represented using for the edges
of the graph two different line types: (i) the continuous lines indicate the final
cluster tree topology, where a node is associated to its parent, while (ii) the dashed
lines indicate that the nodes are in the communication range of each other, but they
1
If a node wishes to communicate with another node in the same Cluster Tree, the message will
follow the rigid structure of parent-child only communications, so reaching the appropriate level
in the tree before being forwarded to the correct branch toward its final destination.
2
The role of the Queried Area in Fig. 6.8 will be clarified later in this section.
Fig. 6.8 Position based routing over a cluster tree topology within a WSN
currently are not associated to each other, i.e., the link is inactive. The presence of
such redundancy in the links among the nodes constitutes the basis to implement
any form of robustness for communication protocols against link and node failures.
As a consequence, some CH are in the communication range with more than
one CH and the same applies to the WSN Nodes. As a matter of fact, the final tree,
where each node must choose only one parent among the alternatives it might
have, would be formed assuming some convenient metrics, like the link quality
[13] and the energy available on the nodes. Nevertheless, the cluster tree network
architecture is flexible enough to allow for mechanisms to dynamically rebuild the
tree topology by periodically checking the status of nodes and links.
The association of WSN Nodes within a cluster and among the CH with each
other up to the gateway is performed following the standard procedures defined for
the IEEE 802.15.4 protocol [2], where a cluster head is elected as a local WSN
Cluster coordinator and starts transmitting beacon signals to keep its child nodes
synchronized.
Assuming that each node knows its own position3 and communicates it within a
DATA packet, as soon as its association with a cluster-head is successfully
accomplished. Given these assumptions, a simple, efficient and scalable position
aware tree-based routing algorithm can be implemented in the cluster-tree archi-
tecture, as follows.
For the sake of simplicity in the exposition, let us suppose using coordinates in a
bi-dimensional reference system, i.e., each node has its own position expressed as:
Pi ¼ ðxi ; yi Þ; i ¼ 1; . . .; N
3
This can be done in several ways, either by pre-programming the nodes with their own position
or by configuring them at the deployment time (as done, e.g., in [14]) or by implementing a kind
of position discovery algorithm [15, 16]. In any case how each node would get its own position
estimation is out of scope of the present document.
where N is the number of nodes in the network and xi ; yi are the coordinates of the
node i, which can be either absolute (e.g., GPS coordinates) or relative (e.g., to the
position of the gateway).
When a WSN Node tries to associate to a CH in a WSN Cluster, it commu-
nicates its own position Pi to the CH, so that the CH can compute its served area,
by simply computing the rough area as a box B, such that:
B ¼ ½ðxs ; ys Þ; ðxe ; ye Þ
where:
ðx; yÞs ¼ minfðx; yÞi g

i2Nc
ðx; yÞe ¼ maxfðx; yÞi g

i2Nc
and Nc is the number of nodes in the WSN Cluster.

This mechanism can be iterated up to the gateway, i.e., when a Cluster Head
tries to associate to its parent, or as soon as it has computed its served area B, it
communicates the coordinates of B to its parent which can determine its served
area A as follows (Fig. 6.9):
ðx; yÞsA ¼ minfðx; yÞs g

s2Nr
ðx; yÞeA ¼ maxfðx; yÞe g

e2Nr
and Nr is the number of child router nodes.

As a consequence, each node of the WSN Patch is aware of its own served area
B and in particular, the gateway can communicate the coordinates of A to the
remote Command and Control station (C&C).
When the C&C queries the network for sensor readings, it uses high level APIs
which include the position information of the interested or queried area as a
parameter for querying the network for specific readings or for instructing the
nodes about the alarm or report generation conditions. In Fig. 6.8, an example of
the queried area from the C&C is presented.
Assuming a large scale WSN network divided into smaller WSN Patches, each
of them organized in a Cluster-Tree model and rooted at the GW, by knowing the
served area of each of those WSN Patches and the IP addresses of their gateways,
the C&C sends the query message Q to the appropriate gateway (or gateways, if
the queried area overlaps, even partially, with the served area of more than a
WSN Patch). As soon as the gateway receives the message Q, it checks if the
queried area is overlapping with its served area and, if so, it broadcasts the
message to its direct child nodes in the tree, otherwise it simply discard Q. Each
child router receiving Q will forward it down to its sub-tree only if the queried
area is overlapping, even partially, to its served area, and this mechanism will be
repeated at each step along the tree, until all the nodes in the interested area will
be reached.
Fig. 6.9 Position based routing—nodes association and served area
The collection of the sensor readings, i.e., the flow back from the WSN Nodes
up to the sink gateway, can be implemented in the usual way along the tree, by
simply recognizing that each node communicates only with its parent. This
mechanism easily allows also for implementing data aggregation or even sensor
fusion at each vertex in the tree.
This mechanism is granted to reach all the nodes in a given queried area,
provided that there is enough network connectivity and with no or little topology
changes. It is scalable, provided that it doesn’t require any storage of neighbor
tables for routing, but only updated the local served areas on each CH. Its func-
tionality has been proved in a real-world environment in the frame of the EMMON
project, dealing with large scale WSNs (see Chap. 8 for an overview and [17] for
more details).
6.3 Security Services
ZigBee security mechanisms fit very well with the security services provided by
the MAC layer of IEEE 802.15.4 [2]. Communications can be protected by means
of symmetric key encryption, in an end-to-end fashion. In particular, ZigBee
security relies on the Advanced Encryption Standard (AES) [18] and the CCM*
Mode (i.e. encryption and authentication). Also, two distinct security modes are
available, that is the Standard Security Mode and the High Security Mode. They
are discussed in more details, later in this section.
Security is provided on an end-to-end basis in a cross-layer fashion, that is both
from the Network (NWK) and the Application Support sub-layer (APS).
Specifically, the layer that originates a ZigBee frame is responsible for initially
securing it. ZigBee frames can be both encrypted and authenticated. In case
authentication is requested, an additional Message Integrity Code (MIC) is
appended next to the frame payload. Note that only data frames and command
frames can be secured, that is ACK frames are always sent in the clear.
Protected frames include an additional Auxiliary Security Header (ASH) just
before the payload. The structure of the ASH is shown in Table 6.2. The Security
control field indicates by means of which key an outgoing (incoming) ZigBee
frame has to be (is) secured, the MIC size in bytes (i.e. 0, 4, 8, 16) and whether or
not the payload is encrypted. The Frame counter field is used to verify frame
freshness and prevent processing of duplicate frames (anti-replay). When present,
the Source address field indicates the extended 64-bit address of the device
responsible for securing the frame. Finally, the Key sequence number field indi-
cates the key sequence number of the Network Key potentially used to secure the
current frame.
In order to activate security, the nwkSecurityLevel parameter must be set to a
value greater than zero. ZigBee security is based on the reuse of cryptographic
keys by different layers, in order to reduce storage costs. More specifically, in
certain cases APS frames can be secured by means of security material maintained
by the NWK layer. The APS layer deals also with key management (i.e. key
establishment and key transport) and provides device management services.
A Trust Center node, which typically coincides with the ZigBee Coordinator,
handles key management and other security services.
In order to protect communications within a ZigBee network, up to five dif-
ferent kinds of cryptographic keys are supposed to be used.
• The Network Key is used to protect NWK frames. It is the same within the whole
ZigBee network, and is typically generated by the Trust Center. It is supposed to
be periodically renewed.
• A Data Link Key can be shared between any two peers to protect APS frames.
• A Key-Transport Key is derived from a Data Link Key. It is used to protect
messages carrying a Network Key, in case of Network Key distribution or
renewal.
• The Master Key is a long term secret used during the Symmetric Key Key
Establishment (SKKE) protocol. However, it is present only in High Security
Mode.
• A Key-Load Key is derived from a Data Link Key. It is used to protect messages
carrying a Master Key. As Master Keys, Key-Load Keys are present only in
High Security Mode.
Table 6.2 ZigBee Auxiliary Security Header

Octets: 1 4 0/8 0/1
Security control Frame counter Source address Key sequence number
6.3.1 ZigBee NWK Frames Protection
If the nwkSecureAllFrames parameter is set to TRUE, security is applied to every

incoming and outgoing NWK data frame. NWK frames are protected by means of
the current Network Key. In particular, for NWK data frames, securityEnabled
must be specified as TRUE before starting a transmission. Figure 6.10 shows an
example of protected ZigBee NWK data frame.
6.3.2 ZigBee APS Frames Protection
ZigBee frames generated at the APL layer are protected according to their specific
type. Figure 6.11 shows an example of protected ZigBee APS data frame.
• APS data frames are protected using either the Network Key or the Link Key
shared with the recipient node. More specifically, the actual key to be used
depends on the specific application profile which the particular data frame refers
to.
• Transport Key commands are used to carry cryptographic keys. The key used to
protect them must be selected according to the key to be transported and pro-
tected. For instance, Key-Transport Keys are used to protect Network Keys.
• Other APS commands are supposed to be protected by means of the Data Link
Key shared with the recipient node. In case such a key could not be retrieved,
the Network Key can be used. In the latter case, if the NWK layer is already
applying security (i.e. the nwkSecureAllFrames parameter is set to TRUE), then
the APS layer must not have to.
Fig. 6.10 A protected ZigBee NWK frame
Fig. 6.11 A protected ZigBee APS frame

6.3.3 ZigBee Security Modes
As stated before, ZigBee provides two distinct security modes. The Standard
Security Mode is designed for lower-security residential applications (e.g. Home
Automation scenarios). The Trust Center device is supposed to maintain a Net-
work Key and control network admittance policies. Besides, the Network Key is
either pre-installed on devices, or obtained unsecurely before joining the network.
Finally, potential Data Link Keys must be pre-installed, and almost no key
management functionalities are provided.
On the other hand, the High Security Mode is designed for high security com-
mercial applications. The Trust Center is supposed to maintain a list of devices,
Master Keys, Data Link Keys and Network Keys. In addition, the High Security
Mode mandates devices authentication and Link Keys establishment with the Trust
Center, by means of the Symmetric Key Key Establishment (SKKE) protocol, based
on Elliptic Curve Cryptography [19]. According to the SKKE, two peers agree on a
Master Key and exchange ephemeral quantities. Then they generate a common
Data Link Key by means of a Key Derivation Function, and confirm with each other
that the new key has been correctly established. Figure 6.12 summarizes the rela-
tionships among cryptographic keys in High Security Mode.
6.3.4 ZigBee Application Profiles
ZigBee provides some application profiles that specify possible collections of

devices, and a set of messages used by devices to communicate with one another.
Fig. 6.12 Keys relationships in High Security Mode

Each application profile describes also some clusters, i.e. sets of parameters and
commands (some mandatory) that devices have to use in order to interoperate
within the network. Nowadays, the most important and promising ZigBee appli-
cation profiles are Home Automation [11] and Smart Energy [12].
The ZigBee Home Automation profile [11] defines device descriptions and
standard practices for applications needed in a residential or light commercial
environment. In particular, it provides standard interfaces and device definitions to
allow interoperability among ZigBee devices produced by various manufacturers
of home automation products. Installation scenarios range from a single room to an
entire home. The key application domains included so far are lighting, HVAC,
window shades and security. Also, this profile primarily focuses on sporadic real
time control of devices. Other applications will be added in future versions. The
Home Automation profile refers to the ZigBee Standard Security Mode, and tends
to limit the key material only to the Network Key, discouraging auto key updates.
The ZigBee Smart Energy Profile (SEP) [12] provides device descriptions and
standard practices for Demand Response and Load Management Smart Energy
applications, and is tailored for residential or light commercial environment.
Possible scenarios include single homes or even an entire apartment complex.
Currently, key application domains are metering, pricing, and demand response
and load control applications.
SEP considers security as a major issue and includes precise mechanisms to
secure communications, as well as a proper Key Establishment Cluster [12].
Besides, it refers to the ZigBee Standard Security Mode, but provides several
improvements and enhancements. Each device has a pre-installed Trust Center
Link Key (TCLK), which must be provided to the Trust Center through out-of-band
means during device’s commissioning. Also, the Key-Transport Key TK is
obtained from TCLK. Finally, the Trust Center is supposed to provide a newly
joined device with the Network Key NK, protecting it by means of the associated
Key-Transport Key TK.
Once the new device has joined the network, the Trust Center must update the
pre-installed TCLK, that is a new Link Key LK must be established, in order to
protect data communications. The key establishment process is supposed to follow
the Certificate-Based Key Establishment (CBKE) method. Every device, including
the Trust Center, holds a certificate issued by a trusted Certification Authority
(CA). Specifically, devices hold implicit certificates, which do not include an
explicit signature by a CA, nor any public key. Thereby, implicit certificates are
supposed to be smaller than conventional certificates, as well as more efficient to
handle, since there is no signature to verify. Also, they make it possible to compute
the certified public key, which is retrieved by means of the CA public key. Note
that it depends on the specific implementation whether computing the certified
public key is more efficient than verifying a signature.
According to the CBKE method, two peers exchange their respective certifi-
cates as well as some ephemeral quantities. Then, they authenticate themselves
Fig. 6.13 Keys relationships in ZigBee Smart Energy Profile
with each other, generate a common Data Link Key by means of a Key Derivation
Function, and confirm with each other that the new key has been correctly
established. Figure 6.13 summarizes the relationships among cryptographic keys
in ZigBee Smart Energy Profile.
Finally, SEP allows any two peers to establish a Data Link Key with each other.
In particular, since they both trust the Trust Center device, they do not need to
perform an actual key establishment. That is, they request a Data Link Key with
each other to the Trust Center. Figure 6.14 depicts two ZigBee devices receiving a
pairwise Data Link Key from the Trust Center. Note that devices which are not the
Trust Center would not be allowed to initiate key establishment with another
device that is not the Trust Center.
Fig. 6.14 Pairwise Data Link Key establishment

6.3.5 Deficiencies in ZigBee Security
In the following, we point out some deficiencies and inefficiencies regarding the
ZigBee security mechanisms. In particular, we refer to the security features
described by the ZigBee Smart Energy profile [12], since it seems bound to become
the reference security model for most of ZigBee applications. First, we take into
account some issues regarding the key revocation and renewal upon devices’
leaving. Second, we discuss possible inefficiencies regarding the management of
devices’ certificates during the authentication process. More details about these two
issues as well as possible solutions are thoroughly discussed in [20].
6.3.6 Key Revocation and Renewal
Let us suppose a ZigBee device leaves the network. This could happen in case it
explicitly requests to leave the network, or it has been compromised and has to be
evicted. However, after being removed from the network, a former ZigBee device
still retains some security material. That is, it still owns the current Network Key,
the Trust Center Link Key, and potential Data Link Keys it has previously
established with other ZigBee devices. By exploiting these cryptographic keys, an
adversary would be able to overhear and actively take part in network commu-
nications. In addition, she might even perform severe routing attacks, as the
sinkhole or the selective forwarding attack [21]. As a consequence, it is vital to
revoke and potentially renew compromised security material, i.e. perform a net-
work rekeying, in order to keep on assuring secure communications.
Revoking the Trust Center Link Key and the Key-Transport Key the evicted
device shares with the Trust Center is a very simple operation, which does not
result in any particular issues. On the contrary, as to Data Link Keys shared among
a number of peer devices, neither the ZigBee Specification [3] nor the Smart
Energy Profile [12] specify what to do in case one of them leaves the network.
However, it would be wise to invalidate also all the Data Link Keys a leaving node
has established with other peer devices which are still members of the ZigBee
network. Unfortunately, ZigBee provides no mechanisms to explicitly inform a
device that another one has left.
As to the Network Key, ZigBee provides two ways to refresh it: broadcast-
based refresh and unicast-based refresh. In the broadcast-based refreshing, the new
Network Key is protected by means of the current one, and broadcast to all devices
with a single rekeying message. This is certainly an acceptable solution for pro-
tecting the Network Key periodic refreshing against an external adversary.
However, this approach is not acceptable for refreshing the Network Key upon a
device’s leaving from the network. In fact, in this case the current Network Key is
definitely compromised and cannot be trusted anymore. The unicast-based
refreshing can be used instead. In the unicast-based refreshing, the new Network
Key is delivered separately to each device in a one-to-one fashion, and protected

by means of the respective device’s Key-Transport Key. This solution is secure,
but it clearly suffers from scalability limitations, due to the number of performed
encryptions and sent rekeying messages that grows according to OðnÞ, where n is
the number of devices in the network [22]. Note that the Trust Center is obliged to
periodically refresh the Network Key NK, but it is not clarified how to determine
the refresh period, and no events that asynchronously trigger the Network Key
refresh are specified.
In addition, it should be better to revoke and renew the Network Key every time a
device leaves the ZigBee network, in order to assure forward security. Also,
remaining devices should receive a secure notification, in order to invalidate
potential compromised Data Link Keys they presently share with former devices.
Furthermore, it is better to renew the Network Key also before any new device joins
the network, in order to assure backward security as well. This very operation is
supposed to be easier and more efficient than a rekeying upon a device’s leaving.
In fact, it may consist in a single broadcast rekeying message carrying the new
Network Key, protected by means of the current one. Of course, such a rekeying
operation is supposed to take place before the new device actually joins the network.
Finally, it would be convenient to manage key revocation and renewal at the
application level, thus avoiding security features provided by ZigBee [20].
However, ZigBee Specifications claim that application level messages require
proper identifiers for the considered application profile, cluster and command, each
one of which has its specific payload. Thus, introducing an application level
protocol may require to extend existing clusters with new commands, or even
define a new manufacturer-specific cluster.
6.3.7 Certificates Management
As stated above, SEP provides a key establishment process which follows the
Certificate-Based Key Establishment (CBKE) scheme, based on implicit public
certificates. Specifically, every ZigBee device holds a certificate issued by a
Certification Authority (CA), and uses it during the key establishment process. In
particular, the Trust Center and every newly joined device must authenticate
themselves with each other, by verifying their respective certificates.
Each device is provided with an implicit certificate and the public key of the
CA releasing the certificate, also called CA root key. As already explained, implicit
certificates include neither the subject public key nor a traditional CA’s signature.
In fact, the certified public key is computed from the implicit certificate by means
of the CA root key. As a consequence, each device is supposed to store the root
key of every possible certification authority releasing implicit certificates. We can
reasonably assume that a Trust Center has no storage limitations, and thus can
keep a large set of CA root keys. On the other hand, keeping a large set of CA root
keys could be a problem for ZigBee end devices, due to storage resources shortage.
In order to overcome this problem, a possible solution consists in introducing a

Home Certification Authority (HCA), that is a further level of certification [20].
More specifically, the HCA can verify original devices’ certificates, and then issue
new ones to be installed on ZigBee devices. By doing so, every device needs to
store only the HCA’s public key, in order to verify the new certificate. That is, the
home-certification mechanism makes it possible to drastically reduce the storage
requirements and avoid any scalability issues, without endangering security within
the network. On the other hand, the final user must be capable of managing a
security core component, as well as issuing new certificates and installing them on
ZigBee devices.
References
1. A. Koubâa, Promoting Quality of Service in Wireless Sensor Networks, Habilitation

Qualification in Computer Science, National School of Engineering in Sfax, Tunisia, Apr.
2011
2. Institute of Electrical and Electronics Engineers, Inc., New York, IEEE Std. 802.15.4-2006,
IEEE Standard for Information technology—Telecommunications and information exchange
between systems—Local and metropolitan area networks—Specific requirements Part 15.4:
Rate Wireless Personal Area Networks (WPANs), Sept. 2006
3. ZigBee Alliance, ZigBee Document 053474r17, ZigBee Specification, Jan. 2008,
www.zigbee.org
4. A. Koubâa, A. Cunha, M. Alves, A time division beacon scheduling mechanism for IEEE
802.15.4/zigbee cluster-tree wireless sensor networks, in Proceedings of the 19th Euromicro
Conference on Real-Time Systems (ECRTS), pp. 125–135, July 2007
5. P. Jurčík, Real-Time Communication over Cluster-tree Wireless Sensor Networks. Ph.D.
Programme on Electrical Engineering and Information Technology, Department of Control
Engineering, Faculty of Electrical Engineering, Czech Technical University in Prague, Czech
Republic in Collaboration with CISTER-ISEP Research Unit, Polytechnic Institute of Porto,
Portugal, Prague, Jan. 2010
6. A. Koubâa, M. Alves, E. Tovar, A. Cunha, An implicit GTS allocation mechanism in IEEE
802.15.4 for time-sensitive wireless sensor networks: theory and practice. Real-Time Syst. J.
39(1–3), 169–204 (2008)
7. O. Gaddour, A. Koubâa, O. Cheikhrouhou, M. Abid, Z-cast: a multicast routing mechanism
in zigbee cluster-tree wireless sensor networks, in Distributed Computing Systems Workshops
(ICDCSW), 2010 IEEE 30th International Conference on, pp. 171–179, June 2010
8. S. Tennina, M. Bouroche, P. Braga, R. Gomes, M. Alves, F. Mirza, V. Ciriello, G. Carrozza,
P. Oliveira, V. Cahill, Emmon: a WSN system architecture for large scale and dense real-time
embedded monitoring, in Embedded and Ubiquitous Computing (EUC), 2011 IFIP 9th
International Conference on, pp. 150–157, Oct. 2011
9. O. Gaddour, A. Koubâa, M. Abid, Segcom: a secure group communication mechanism in
cluster-tree wireless sensor networks, in Communications and Networking, 2009. ComNet
2009. First International Conference on, pp. 1–7, Nov. 2009
10. H. Boujelben, Improvement and implementation of a multicast routing mechanism in zigbee
cluster-tree wireless sensor networks, Master in automatic and industrial software, National
School of Engineers of Sfax, Sept. 2010
11. ZigBee Alliance, ZigBee Home Automation Public Application Profile, Febr. 2010, www.
zigbee.org
12. ZigBee Alliance, ZigBee Smart Energy Profile Specification, March 2011, www.zigbee.org
13. N. Baccour, A. Koubâa, L. Mottola, M. Zuniga, H. Youssef, C. Boano, M. Alves, Radio link
quality estimation in wireless sensor networks: a survey. ACM Trans. Sens. Netw. 8(4), 34:
1–33 (2012)
14. T. He, S. Krishnamurthy, L. Luo, T. Yan, L. Gu, R. Stoleru, G. Zhou, Q. Cao, P. Vicaire, J.A.
Stankovic, T.F. Abdelzaher, J. Hui, B. Krogh, Vigilnet: an integrated sensor network system
for energy-efficient surveillance. ACM Trans. Sen. Netw. 2(1), 1–38 (2006)
15. S. Tennina, M. Di Renzo, F. Graziosi, F. Santucci (2011). Distributed Localization
Algorithms for Wireless Sensor Networks: From Design Methodology to Experimental
Validation, Wireless Sensor Networks, (Ed.), ISBN: 978-953-307-325–5, InTech,
doi:10.5772/38731. Available from: http://www.intechopen.com/books/wireless-sensor-
networks/distributed-localization-algorithms-for-wireless-
16. S. Tennina, M.Di. Renzo, F. Graziosi, F. Santucci, ESD: a novel optimisation algorithm for
positioning estimation of WSNs in GPS-denied environments—from simulation to
experimentation. Int. J. Sen. Netw. 6(3/4), 131–156 (2009)
17. Emmon—Embedded monitoring, May 2012, www.artemis-emmon.eu
18. National Institute of Standards and Technology, Federal Information Processing Standards
Publication 197, Specification for the ADVANCED ENCRYPTION STANDARD (AES), Nov.
2001
19. Certicom Research, Standards for Efficient Cryptography: SEC 1 (Working Draft) Ver. 1.7:
Elliptic Curve Cryptography, Nov. 2006
20. G. Dini, M. Tiloca. Considerations on security in zigbee networks, in Proceedings of the
IEEE International Conference on Sensor Networks, Ubiquitous, and Trustworthy Computing
(SUTC), pp. 58–65, June 2010
21. C. Karlof, D. Wagner, Secure routing in wireless sensor networks: attacks and
countermeasures, in Sensor Network Protocols and Applications, 2003. Proceedings of the
First IEEE. 2003 IEEE International Workshop on, pp. 113–127, May 2003
22. A. Rafaeli, D. Hutchison, A survey of key management for secure group communication.
ACM Comput. Surv. 35(3), 309–329 (2003)
Part III
System Architectures and Applications
The reader is now ready to use the principles, tools and methodologies presented in
the previous parts to the design and implementation of efficient WSN-based
monitoring systems for real world applications. In this third and final part of the
book, few examples from our own experiences are reported.
The first one presents advances in Structural Health Monitoring (SHM) using
WSNs. SHM and damage identification at the earliest possible stage have been
receiving increasing attention from the scientific community and public author-
ities, since service loads, accidental actions and material deterioration may cause
damage to the structural systems, resulting in high administrative costs for
governments and private owners and, in some situations, loss of lives. As such,
there is an enormous eagerness to add sensing/actuating capabilities to physical
infrastructures like bridges, tunnels and buildings, turning them into smart
structures able to detect and respond to abnormal situations. The fact that
conventional sensor platforms use wires increases the cost of the monitoring
systems and creates huge difficulties in their installation and maintenance. In some
situations, it is actually not possible or not admissible to deploy wired SHM
systems, e.g., due to visual impact. Consequently, despite the challenges imposed
by SHM applications in terms of highly reliable and timely measurements
particularly for larger structures, WSNs have been emerging as a natural
alternative technology.
The second example focuses on engineering a end-to-end WSN-based system
for environmental monitoring. WSNs have attracted growing interest in the last
decade as an infrastructure to support a diversity of ubiquitous computing and
cyberphysical systems. However, most research work has focused on protocols or
on specific applications. As a result, there remains a clear lack of effective, feasible
and usable system architectures that address both functional and non-functional
requirements in an integrated fashion. In particular, our experience within the
EMMON [1, 2] project is reported and a system architecture for large-scale, dense,
real-time embedded monitoring is outlined.
136 System Architectures and Applications
The third and last example overviews the deployment considerations of a WSN
to monitor Data Center environmental conditions and power consumptions. Data
centers are a central piece of today’s Internet infrastructure and have become
critical for many medium and large organizations. A data center is a facility (one
or more rooms, floors or buildings) custom built to house large computing systems,
including networking, storage systems and also power distribution and cooling.
The operation of a data center is an instantiation of a Cyber-Physical System (CPS)
in the sense that it requires managing physical parameters, such as power and
environmental variables of the data center (e.g., temperature, humidity, pressure),
that are coupled with computations. This is especially true in future data centers,
where management of cloud-related workload will be performed more aggres-
sively. This workload management includes distributing or consolidating work-
loads throughout data center machines, and this impacts physical parameters
(power and environmental) of the data center in a very dynamic manner.
References
1. Emmon—embedded monitoring, May 2012. www.artemis-emmon.eu.

2. S. Tennina, M. Bouroche, P. Braga, R. Gomes, M. Alves, F. Mirza, V. Ciriello,
G. Carrozza, P. Oliveira, V. Cahill, Emmon: A wsn system architecture for large
scale and dense realtime embedded monitoring. in Embedded and Ubiquitous
Computing (EUC), IFIP 9th International Conference, Melbourne, pp. 150–157,
October 2011
Chapter 7
Structural Health Monitoring
Abstract This chapter proposes an extension of our preliminary work [1] to

address COTS-based accurate and scalable Structural Health Monitoring (SHM)
systems by means of WSN, trying to overcome most if not all of the limitations
identified in this field, namely by: (i) using adequate synchronization between all
nodes in the network; (ii) relying on standard communications protocols, while
most proposals use IEEE 802.15.4-compliant devices that neither implement the
IEEE 802.15.4 medium access control (MAC) nor ZigBee protocols; (iii) building
upon a standard de facto operating system (OS) for WSNs platforms (TinyOS);
(iv) relying on COTS technologies (more cost-effective); and (v) providing ade-
quate scalability to monitor large infrastructures in an effective way, i.e., with a
consistent time correlation of samples.
7.1 System Scalability
The aim of any SHM system is to sample in a synchronized fashion multiple

accelerometers placed at different locations in a structure and forward the data to a
central station for later processing. Therefore, ensuring the correct synchronization
of the sensing operation of the distributed nodes is of major importance for this
kind of monitoring applications. This means that samples from all sensors must be
acquired in a synchronized way in order for the data analysis algorithms to provide
consistent results.
As previously mentioned, our small-scale prototype was based on a single
cluster approach, using a star topology. Although theoretically the IEEE 802.15.4
standard can support up to 21 6 devices, this is usually not true in practice. Due to
the small coverage area of a star topology, the deployment will be limited to a few
Sensing Nodes (SN), since connectivity of all sensors with the Coordinator node
must be guaranteed. Moreover, in many scenarios such as long span bridges or
tunnels, hundreds or even thousands of devices may be needed to assess the

138 7 Structural Health Monitoring
integrity of the structure. Hence, to scale the system, there is a need for a routing
mechanism that can cope with the tight synchronization requirements this appli-
cation imposes.
In particular, according to [2], the maximum drift between samples should be
computed as presented in Eq. 7.1:

Csi Csj 1 8i ¼ 1. . .N 6¼ j ð7:1Þ
fs
where Csi is the clock of the i-th sensor, N is the total number of sensors and f s is
the sampling frequency. Then, assuming the TelosB platforms [3] whose crystal
features a drift of 20 ppm in relation to its nominal frequency, for keeping the
drift below 5 ms, according to the application requirements, it would be necessary
to synchronize a node every 250 s at most. This result imposes the existence of a
synchronization mechanism in the WSN, so that all nodes have the same time
reference.
7.2 Network Model
We rely on a cluster-tree network model (ZigBee-based) with a distributed syn-

chronization mechanism. This a special case of a mesh network where there is a
single routing path between any pair of nodes and a distributed synchronization
mechanism (IEEE 802.15.4 beacon-enabled mode). There is only one ZigBee
Coordinator (ZC) (i.e., the Coordinator Node plays this role in our application),
which identifies the entire network, and one ZigBee Router (ZR) per cluster, which
we denote as Cluster Head (CH) in our application. Figure 7.1 presents the net-
work topology.
Scaling to multiple-cluster networks involves greater complexity due to inter-
cluster interference. Hence there is the need to schedule the active period of each
cluster, as described in Sect. 6.1. The TDCS proposal does this and a possible
schedule to the network depicted in Fig. 7.1 is illustrated. Notice how each cluster
active portion and beacon transmission is scheduled at a different instant from the
neighbor clusters (we assume all clusters can interfere with each other).
Another problem that arises as the system scales up is the increased volume of
data. As the number of sensing nodes in our application increases, it may no longer
be valid the assumption of being able to configure each node independently
through a message from the Coordinator Node, since the volume of data at net-
work setup time is significantly higher. Instead, it makes sense to setup the Sensing
Nodes in a per-cluster basis and group all information concerning each Sensing
Node at the corresponding Cluster-Head (i.e., ZR), also assuming a management
role in the monitoring application.
With all these particularities in mind, a larger cluster tree network architecture
is implemented where synchronization is of the topmost importance. The strategy
7.2 Network Model 139
Fig. 7.1 Network tree topology showing 15 clusters and respective TDBS cluster scheduling
to cope with the new Cluster-Tree topology while carrying out the simultaneous
data acquisition is described next.
7.3 Synchronization Mechanism
An instant in the superframe is chosen as the synchronization point at which every

node will re-synchronize (tsync ). Notice that all nodes must get this information
before the data acquisition begins, i.e. tsync must be larger than the time at which
the last Cluster is scheduled to begin (Fig. 7.1). The Coordinator will announce in
its beacon payload, the number of symbols from the transmission of its beacon up
C0
until this instant at which the sampling will begin (Tsync ) and the sensor nodes will
synchronize. Each Cluster-Head computes the relative time offset from its beacon
Cparent
to tsync based on its parent beacon information (Ttsync ) and announces it on its own
beacon so that the Sensing Nodes in the Cluster know when to begin data
acquisition and in order to propagate the tsync information throughout the network.
Here we denote by Cx the devices at cluster x, where x represents the order at
which the cluster is active in the TDCS schedule (Fig. 7.1). For instance,
C2 represents the second cluster active in the cycle. The offset from the beacon of
Cluster-Head x to tsync is computed as follows:
Cx C
parent
Ttsync ¼ Ttsync TTDBSoffset
From its parent’s beacon, each Cluster Head will compute its offset using the
TDCS offset to its parent (TTDBSoffset , check Fig. 7.1). Each Sensing Node
belonging to the cluster will read the tsync information from the beacon of its
Cluster Head and set a timer to generate an interrupt at tsync at which time the
sensor node will be signaled for synchronization.
7.4 Theoretical Analysis of the Scalability
Using this approach, we can theoretically scale the system up to hundreds or

thousands of clusters, even when assuming a worst-case TDCS scheduling where
all clusters cannot overlap. For instance, assuming a BO = 14 (maximum value for
BO [4]), we could theoretically schedule 16.384 clusters with SO = 0, or, 512
clusters with SO = 5.
However, because each cluster will have to wait for a finite amount of time
Cx
(Ttsync ) using a Timer hardware, which relies on clocks of finite precision, each
Sensing Node will present a different clock drift during this period, and by the time
tsync is reached, each clock will have a different notion of when this really happens.
This drift is represented by:
dCtsync
x
¼ TtCsync
x
dclock ;
where Ttsync ¼ nclusters Tsframe þ pTsframe xTsframe , being Tsframe the period of a
cluster’s superframe, equal to aBaseSuperframeDuration 2SO , dclock the expected
clock drift for the quartz clock in the device, nclusters the total number of clusters in
the network, and p the portion of superframe after the last cluster until tsync . Notice
this expression is only valid for this non-overlaping kind of cluster scheduling.
Since, the drift at each superframe is given by dsframe ¼ dclock Tsframe , we can
write: dCTsync
x
¼ ðnclusters þ p xÞdsframe
For cluster 12, for instance, assuming the example in Fig. 7.1, dCTsync 12
¼
15 dsframe þ p dsframe 12 dsframe ¼ ð3 þ pÞ dsframe
Since synchronization must be tight in this kind of applications, we must take
this drift into account at network setup time. Moreover, each Router throughout the
Cluster-Tree, will also present a drift while waiting for its time to transmit its
own beacon (after the parent’s beacon), defined by the parent to child drift
dCPCx ¼ xdsframe and will also impact our synchronization strategy.
On top of this, we should not neglect that since the arrival of each beacon, there
is a processing delay, defined by dCBPx Dd ¼ ddbeaconproc , being d the depth of the
7.4 Theoretical Analysis of the Scalability 141
Table 7.1 Maximum drift nclusters SO/BO Depth Max. d (ls)

for different network
scenarios 5 5/8 2 85
15 4/8 3 141
25 4/9 4 220
device in the three and dbeaconproc the processing delay upon beacon reception,
which we assume as a finite constant value and was found experimentally. This
delay is even more significant for these kinds of devices with low processing
power. According to our reasoning, assuming a worst-case where all drifts will
sum, the drift for a device at cluster Cx at depth d is given by:
dCsync
x Dd
¼ dCTsync
x
þ dCPCx þ dCBPx Dd ð7:2Þ
As observed, the drift is independent of the position of the cluster in the TDCS
cycle. It only depends of the total number of clusters, and the cluster’s depth in the
tree. Table 7.1 shows some results obtained from Eq. 7.2, considering different
network scenarios and assuming p ¼ 0:67:
7.5 Experimental Analysis of the Scalability
We have implemented the proposed synchronization mechanism in nesC/TinyOS,

over the official TinyOS Working Groups implementation [5] of the IEEE
802.15.4 and ZigBee protocols. A testbed with 15 clusters was setup to test the
Fig. 7.2 Oscilloscope screen-shot of a drift measurement

synchronization mechanism proposed here. The cluster schedule was chosen so

that there would be no overlapping clusters, BO and SO network parameters were
set to 8 and 4 respectively, and network maximum depth was set to 3. The scenario
is identical to the one presented in Fig. 7.1.
The devices were setup to toggle an external pin upon reaching tsync and a
digital oscilloscope was used to measure the maximum clock drift between the
devices. Fig. 7.2 shows the testbed along with a screenshot from the digital
oscilloscope.
From the theoretical calculations, we would expect a maximum worst-case
error of 141 ls between clocks. Experimentally, we verified that the maximum
error was of 100 ls with an average of 39 ls, which is acceptable for our appli-
cation. We believe that part of this error is related to fluctuations in the beacon
transmission timing that may not be strictly related to clock drift.
References
1. R. Severino, R. Gomes, M. Alves, P. Sousa, E. Tovar, L. Ramos, R. Aguilar, P. Lourenco,

A wireless sensor network platform for structural health monitoring: Enabling accurate and
synchronized measurements through cots+custom-based design (2010)
2. M. Cinque, D. Cotroneo, G. De Caro, M. Pelella, Reliability requirements of wireless sensor
networks for dynamic structural monitoring, in Proceedings of the International Workshop on
Applied Software Reliability (WASR), 2006, WASR ’06, USA, Philadelphia, June 2006
3. Memsic, TPR2420CA TelosB Mote (2013), www.memsic.com/wireless-sensor-networks
IEEE Standard for Information Technology—Telecommunications and Information Exchange
between Systems—Local and Metropolitan Area Networks—Specific Requirements Part 15.4:
Rate Wireless Personal Area Networks (WPANs), Sept 2006
5. Tinyos working group (2010). www.tinyos.net
Chapter 8
Environmental Monitoring
Abstract In this chapter, EMMON [1, 2], a system architecture for large-scale,
dense, real-time embedded monitoring is outlined. EMMON provides a hierar-
chical communication architecture together with integrated middleware (MW) and
command and control (C&C) software. It has been designed to use standard
commercially-available technologies, while maintaining as much flexibility as
possible to meet specific applications requirements. The EMMON architecture has
been validated through extensive simulation and experimental evaluation,
including a 400+ node test-bed in a real end-user environment, which is, to the best
of our knowledge, the largest single-site WSN deployment in Europe to date.
8.1 Design Guidelines
Moving from the exhaustive analysis of existing technologies and related work
available in [3] and from our own experience, the best practices to be applied to a
large scale and dense real-time system architecture’s design, such as EMMON’s
one, are as follows. (i) Keep it simple: simple solutions are easier to handle and
debug. Interacting with end-users helps identifying the appropriate requirements,
often leading to a reduction of the complexity. Example, it is useless to design
complex congestion control algorithms if the congestion probability is negligible.
Nevertheless, it is worthwhile to stress that ‘‘simple’’ doesn’t mean ‘‘trivial’’:
finding the simplest solution to achieve a goal might be a complex task itself!
(ii) Modular design: proceeding by steps in a modular design approach is of
paramount importance. Only the most basic system’s features should be included
in the first phase of the design cycle and their correctness evaluated through
analytical and simulation models, as well as experimental validation. (iii) Embed
tests in the design cycles: extensive tests using a test-bed should be included in the
design refinement cycles (test-it-fix-it). Many properties and problems appear only
in real-world deployments; therefore, it is paramount to deploy the test-bed in an
environment that exhibits similar conditions as the final deployment, as well as

144 8 Environmental Monitoring
tuning consistent simulation models. (iv) Interoperability matters: for example, the
best Medium Access Control (MAC) protocol may not fit with the best routing
protocol; therefore, assessing the interoperability between technologies is funda-
mental to evaluate the adequacy of each of them in the system frame. (v) Technical
maturity: in engineering projects, choosing mature technologies, extensively used
by the community, is the key for the success. (vi) Availability of expertise:
achieving interoperability among components requires a huge effort. Hence, it is
often preferred to use technologies for which knowledge is available within the
design team. (vii) QoS provision: predictable resource guarantees are achieved
through network models such as cluster-tree, rather than mesh-like. These network
models rely on the use of contention-free MAC (e.g., TDMA or token passing) and
tree-routing protocols as well as the possibility to reserve end-to-end resources.
8.2 EMMON System Architecture
The main goal of EMMON is to provide an architecture for WSN systems that is
scalable. The term ‘‘scale’’ applies to the number (fewer or more nodes in the
overall system), the spatial density (number of nodes in a restricted region), or the
size of the geographical region covered. The ability of a WSN system to easily/
transparently adapt itself with no or negligible degradation of overall system
performance1 to dynamic changes in scale is named ‘‘scalability’’.
By applying the best practices described in Sect. 8.1, building on the alterna-
tives identified in [3] and to cope with scalability issues while addressing QoS
requirements, the design approach is to ‘‘divide and conquer’’, i.e., to adopt a
hierarchical, multi-tier network architecture as sketched in Fig. 8.1.2 Furthermore,
following extensive consultation with experts from a wide number of fields [4],
EMMON adopts a fully geographical approach3: users specify the area from which
they want data, as opposed to the nodes that should be queried. EMMON’s main
characteristics are summarized in what follows and further detailed in Sects. 8.3,
8.4 and 8.5.
(i) The synchronized version of the IEEE 802.15.4 MAC is used at the lowest
tiers. By dividing the time into active and sleep periods, this MAC helps to
achieve the goals of timeliness, time synchronization and lifetime. Nodes are
synchronously active or sleeping, with a dynamically adaptable duty-cycle.
This enables to find the best delay/throughput vs. energy trade-off. Both best-
effort (CSMA/CA, during the CAP) and real-time (GTS, during the CFP)
traffic classes are supported.
1
End-to-end delay, throughput, security, reliability and lifetime.
2
Details on the Portable Device as an optional element at Tier-2.b are out of scope of this work.
3
The geo-routing has been already described in Sect. 6.2.2 as an amendment of the ZigBee
protocol stack.
8.2 EMMON System Architecture 145
Fig. 8.1 EMMON high level multi-tiered hierarchical system architecture
(ii) WSN nodes are organized into a ZigBee-based Cluster-Tree network model
(Sect. 6.1), rooted at a gateway playing the role of the sink. A cluster-tree is a
hierarchical architecture per-se. However, to avoid collisions between
clusters, while meeting end-to-end deadlines of time-bounded data flows,
clusters’ active portions are scheduled in a non-overlapping fashion using the
Time Division Cluster Scheduling (TDCS) [5].
(iii) Assuming the Cskip-based Distributed Address Assignment Mechanism
(DAAM) (Sect. 1.3.1), for the upstream flows the tree-based convergecast
model is adopted: this means that routing has negligible memory footprint
and processing delay, since it does not need large neighbor tables. For the
downstream flows, tables are not needed either, since an efficient geograph-
ical-based routing has been devised (Sect. 6.2.2).
(iv) Data aggregation, sensor and data fusion mechanisms are implemented at all
levels of the architecture: (a) on the sensor nodes (SNs), by aggregating
multiple readings taken over time (temporal aggregation); (b) on the cluster
heads (CHs), by aggregating multiple readings coming from different sensors
or children CHs (spatial aggregation); (c) on the gateway (GW), where sensor
fusion is done by considering multiple reports coming from the CHs; (d) on
the C&C, where correlation of the incoming sensor reports with other
available data (e.g., current car traffic conditions in air-quality monitoring) are
enabled.
(v) A novel EMMON-specific middleware (Sect. 8.4) runs on all the elements of
the system: it glues all the components together, from the C&C clients to the
SNs, leading them to work properly over heterogeneous communication
technologies (Fig. 8.1). It also greatly helps in networking and system
management operations, thanks to its distribution of the intelligence as low as
possible in the network’s tiers.
(vi) The EMMON C&C subsystem is the interface for end-users (Sect. 8.5). It is
composed by a Server which leverages on the middleware to bridge the WSN
with a user-friendly graphical interface on the Clients.
8.3 Communication Protocol Architecture
The extensive analysis conducted in [3], constituted the starting point for the design
of an appropriate network architecture that achieves efficiency in large scale and
dense WSNs. In particular, according to the guidelines listed in Sect. 8.1, a number
of alternative technologies were evaluated, and the output was that such efficiency
is achievable if: (i) the network architecture is multi-tier and (ii) the widely used
IEEE 802.15.4 standard is adopted as short-range communication protocol.
While the adoption of the IEEE 802.15.4 standard is a natural choice, the use of
a multi-tier architecture raises a number of challenges. In particular, although
considered by far the best network design approach for the purpose, thanks to the
flexibility it offers, two issues must be tackled: (i) how many tiers and how many
communication technologies should be used, and (ii) what kind of nodes are the
most appropriate for each tier (e.g., in terms of energy and computation resources).
8.3.1 Design Choices
In order to achieve scalability and QoS, while maintaining a low level of com-
plexity in the network, several design decisions were made. At the higher tiers, the
Internet Protocol (IP) is used as the base networking protocol and the EMMON
architecture supports the case where gateways, equipped with, e.g., WiFi or 3G
radios, constitute a backbone (ad hoc) network or can communicate directly with a
remote C&C server over Internet (Fig. 8.1). At the lowest tiers, a clustered WSN
architecture is assumed, since clusters: (i) help localize routes and reduce the size
of the routing table, (ii) conserve bandwidth and prolong battery life through duty
cycling, and (iii) result in a reduction in coverage redundancy, medium access
collisions, transmission range and/or number of hops required to reach the sink [6].
While the random node deployment paradigm is appealing for large-scale
WSNs due to its inherent low deployment costs, if nodes are randomly scattered
some of them might be unreachable or have to use a very high transmission power
to maintain network connectivity, resulting in faster battery exhaustion. Hence,
8.3 Communication Protocol Architecture 147
EMMON assumes some control over node deployment; in particular CHs are
assumed to be placed in order to maximize the network connectivity. The system
also relies on nodes being position-aware: either they know their own position pre-
run-time (e.g., as a parameter configured at deployment time, as in [7]), or they can
estimate it [8].
Finally, given the type of applications targeted by EMMON and since no end-
user typically expressed requirements for peer-to-peer communication [4], hori-
zontal data flows are not supported. Therefore, EMMON only supports commu-
nication from nodes to the C&C (i.e., upward flow), to send measurements reports
and alarms notifications, and from the C&C to nodes (i.e., downward flow), for
disseminating user-defined operations, network management commands or to
reconfigure/reprogram at run-time group of nodes. Downstream control (i.e., for
actuation) or network management traffic may also be supported, if required.
8.3.2 Multi-Tiered Architecture
Given the above design choices, the resulting EMMON architecture is as sketched
in Fig. 8.1. Tier-0 consists of simple wireless sensor nodes, performing sensing
tasks and delivering data to the devices at the upper tier in the hierarchy using the
IEEE 802.15.4 protocol. They are cheap enough to be deployed in large quantities,
therefore, we assume they have very limited computational, memory and energy
capabilities. Several SNs are grouped to form a WSN Cluster at Tier-1 in a star
topology, where a Cluster Head is responsible for cluster management and data
aggregation. CHs may be slightly more powerful than ordinary sensor nodes in
terms of computational and storage capabilities, and might have lesser energy
constraints (e.g., longer lasting batteries). Multiple CHs are grouped to form a WSN
Patch at Tier-2, where a fixed gateway is present. GWs have the highest compu-
tational capabilities in the WSN and have IP-based communication capabilities to
reach a remote C&C Server at Tier-N, as well as unlimited energy supply.
A WSN Patch adopts a Cluster-Tree model, with the GW as root and the SNs as
leaves. As discussed in Sect. 8.2, the synchronous version of the IEEE 802.15.4
protocol was chosen and the TDCS algorithm is used to preserve the coordination.
Recalling from Sect. 6.1, this mechanism involves the definition of the Start Time
values of the MAC protocol, such that the active portions of each cluster are
interleaved during the inactive portion of all the others sharing the same collision
domain, as in Fig. 7.1.
Finally, saying that inter-clusters collisions are avoided using time-division
means that we have implicitly assumed that every node belonging to a WSN Patch
operates on the same radio channel. A frequency-division approach is then
exploited to minimize inter-patches collision probability. Similarly to [9],
EMMON assumes that neighbor (or even overlapping) WSN Patches use distinct
radio channels, while channel re-use is allowed for any pairs of WSN Patches
distant enough from each other [10].
8.4 EMW: EMMON Middleware
The EMMON architecture provides a middleware layer (EMW) to facilitate the

development of our target class of applications. Due to the very-constrained nature
of WSN end devices, the choice and implementation of the services that it provides
must be highly optimised. This section first presents EMW’s high-level API, then
introduces its architecture and, finally, discusses our approach to aggregation of
geographically-specified data.
8.4.1 High-Level API
The middleware API was careful designed after consultation with environmental
monitoring experts from different fields [4] to capture the functionalities that are
required by them, thereby enabling the middleware to optimise its internal mech-
anisms’ non-functional properties. In particular, EMW provides a fully geograph-
ical data service, i.e., users specify the area from which they want data, as opposed
to the nodes that should be queried. Users can make use of three types of operations:
queries, reports and alarms, which provide data respectively once-off, periodically,
and when a user-specified condition is met. Figure 8.2 shows the API used to define
a report on street1, that will measure the CO2 levels every 2 min and report (via the
handler provided) the average of these values every 30 min. The optional QoS class
specifier allows users to specify QoS parameters, and the spatial aggregation
threshold is used to specify the amount of aggregation performed (c.f. Sect. 8.4.3).
Figure 8.2 also shows how an alarm is defined over a park, that will be triggered
when the temperature is above 50 for more than 2 min continuously. The
parameters normalTolerance and alarmTolerance specify the minimum
sensing period respectively when the alarm condition is not met and when it is.
Figure 8.3 illustrates these parameters: at time 0:00, the condition is not sat-
isfied, so the temperature is sensed normalTolerance later (1 min). At time
1:00, the condition is satisfied, so temperature is sensed again every alarm-
Tolerance (20 s), until 2:00, where the alarm condition is not met and the
period reverts to normalTolerance. At 3:00, the condition is met again, so
temperature is sensed every 20 s until time 5:00, when the condition has been
satisfied for 2 min and therefore an alarm is triggered (via the handler).
8.4.2 EMW Architecture
The middleware spans all the tiers of the architecture defined in Sect. 8.2. The
functionalities differ in every tier, with many of them being implemented on
several tiers, as can be seen in the overall architecture (see Fig. 8.4).
8.4 EMW: EMMON Middleware 149
Fig. 8.2 EMW API for setting reports and alarms
Fig. 8.3 SetAlarm temporal parameters
Functionality placement is a challenging design decision due to two conflicting

principles. On the one hand, since higher tiers are composed of less resource-
constrained nodes, most computation should be perform at this level. On the other
hand, placing intelligence as low as possible in the network architecture decreases
the traffic volume, allows faster reaction to failures, and enables their containment
hence decreasing overall complexity—all characteristics that enhance scalability.
The consequences of both these principles need to be weighted carefully. For
example, data aggregation is performed at every tier (and even within tiers, for
example at every hop in the cluster head tree), because of its potential to signif-
icantly reduce traffic volumes (provided that the middleware knows exactly what
Fig. 8.4 EMW architecture: the light blue boxes are components from other software layers.
White boxes were implemented for the first EMMON demonstrator [1]
data users are interested in, as discussed in the previous section, and that it is
possible to choose a suitable aggregation process that is simple enough to be
performed on even the most limited platforms as discussed in the next section).
8.4.3 Spatial Aggregation
To facilitate spatial aggregation, every reading is tagged with the area to which it
corresponds.4 As the devices at tiers 0 and 1 (sensor nodes and cluster heads) have
very low computational power, memory and energy storage, data aggregation
requires a process that can be performed iteratively, and runs even on the most
constrained nodes. An aggregation component that aggregates two readings only
when the subarea of the aggregated reading for which no data is available is
smaller than a user-defined threshold, spatialAggregationThreshold.
has been implemented.
Figure 8.5 illustrates this process. Cluster heads apply spatial aggregation (in
this case Minimum) first to the readings from the sensor nodes in their cluster, and
then aggregate the outcome with the values coming from their child cluster heads
(if they have any), provided that the area of the combined reading for which no
4
In the first instantiation, positions are statically defined, and the area associated with a reading
is the bounding box around the sensors it comes from.
8.4 EMW: EMMON Middleware 151
Fig. 8.5 Recursive spatial aggregation process: two readings are aggregated when the subarea of
their combined area for which no data is available is smaller than a user-defined threshold
data is available is smaller than spatialAggregationThreshold. For

example the outcome of this process is 8 for CH1 and 7 for CH2 (minimum value
of their sensor nodes). They both transmit their value to their parent cluster head,
CH4 . CH4 first aggregates the value from its children sensors (outcome: 8).
CH4 then considers the area, A1 , associated to the reading resulting from the
aggregation of the values it has received. Assuming that the sub-area of A1 for which
it has no reading (light gray in the figure) is smaller than the spatial aggregation
threshold, it forward the aggregated reading to CH5 . The same process occurs on
the other side of the cluster tree, yielding a value of 10 transmitted to CH5 .
A reading aggregating the values from CH3 and CH4 corresponds to area A2 . If the
subarea of A2 for which no reading is available (white) is bigger than the spatial
aggregation threshold, then the two readings are not aggregated, and CH5 forward
both readings to its parent.
This process was used as proof of concept for low-complexity recursive spatial
aggregation. It could be further extended, for example by also considering how
similar the reading values are when deciding whether to aggregate.
8.5 Command and Control
The EMMON C&C is the most visible part of the system. It aims at enabling the
monitoring of a (large) number of sensors and provide all the functionalities
available in the WSN to end-users. For that, it is composed of two main com-
ponents: the Server and the Clients.
Fig. 8.6 C&C Graphical User Interface: it allows to define the monitoring areas for querying
real-time sensor measurements and see the historical data
The C&C Server is responsible for interacting with the WSN, storing the
measurements into a local repository and making them available to the C&C
Clients. It is a central repository which contains a module responsible for receiving
the data from the sensors, storing it in a database and notifying the clients of new
values. It also includes a middleware component that implements the middleware
API used to interact with the WSN. C&C Clients are the end points of the system,
showing (visually) the WSN data and providing functionality to interact with the
WSN. Unlike traditional software, the EMMON C&C Clients do not interact with
each sensor individually, but with monitoring objects (e.g., a room), which can
group several sensors (Fig. 8.6).
In the implementation of the C&C Client, the user can define simple monitoring
objects by drawing rectangles over a geo-referenced map querying the desired
information. This allows the visualization of real-time readings from the moni-
toring objects and corresponding historical data through a chart and in a table.
Actually, the EMMON C&C encompasses more features and services such as: (i)
Web services, to make the data received from the WSN available to external
systems and to allow external systems to provide data; (ii) the use of polygons
instead of rectangles to define monitoring objects and (iii) the possibility to specify
sensor class or tagging aggregation types.
8.6 System Planning, Simulation, Analysis Toolset
This section provides a snapshot of EM-Set, the EMMON toolset, used to plan,
simulate and analyze the performance of the EMMON network. More details are
in [10].
8.6 System Planning, Simulation, Analysis Toolset 153
Figure 8.7 provides an overall perspective of the EMMON toolset. It is

worthwhile stressing that the integration between the different components (inputs/
outputs) into a single framework enables to speedup system design. In fact, the
ultimate goal of this toolset is to thoroughly allow functional and non-functional
performance indices evaluation under several aspects. For instance, this tool-
set allows to assess the scalability limits of the EMMON network through an
evaluation of e.g., the end-to-end delays derived from analytical and simulation
models as well as from experimental trials. The results presented in Sect. 8.7
derive from the use of these tools.
Starting from the field area and the sensing coverage of each SN and assuming the
structure of a basic WSN Patch, i.e., a GW and N CHs surrounding it, the Network
Deployment Planning outputs the number of WSN Patches and SNs needed to cover
that area, as well as their optimal positions. These outputs feed the TDCS scheduler
(described in Sect. 6.1), the Worst-Case analyzer (Sect. 3.1) and the Network
Protocol simulator (Sect. 3.2.1). These three tools enable network dimensioning and
a performance evaluation. Upper bounds on the end-to-end delays of real-time traffic
and end-to-end delays for both best-effort and real-time traffic classes, packet losses
and network lifetime (as per node energy consumptions) are computed. The TDCS
scheduler outputs the topology of the WSN Patch and the clusters’ scheduling that
are used to feed the Remote Programming and Testing tools (to program/test the
WSN nodes via a USB tree) and to evaluate the network performance through
Network Protocol Analyzers, i.e., a sniffer tool to capture the packets (Sect. 3.3) and
a customized parser to extract the most useful statistics from the logs.
Fig. 8.7 EMMON toolset for network planning, dimensioning simulation analysis and test/
programming
8.7 EMMON Demonstrator
This section illustrates DEMMON, the demonstrator of the EMMON architecture,

involving not only the simulation and analytical results but also an experimental
campaign within a real end user environment. A comparison between simulation,
analytical and experimental results finally validates the EMMON architecture
(in terms of the interoperability among its architectural components), characterizes
its performance and scalability limits and shows the usefulness of the integrated
framework of tools proposed.
To validate the system architecture, a network has been deployed. More than
400 TelosB nodes were connected across three floors of an office building. The
network was composed of 4 WSN Patches, two of them deployed in the garage of
the building thereby enabling to define different topologies by programming the
nodes over USB trees using our toolset.The GWs communicated via wireless LAN
to a host PC running the C&C server. The WSN Patches simultaneously operated
in distinct frequency channels, chosen to minimize the actual external interference
[11]. In order to do so, a pre-deployment Electro-Magnetic Interference (EMI)
analysis in the deployment site has been performed using HeatMapper [12], a free
Wi-Fi coverage mapping site survey tool made by Ekahau. As expected [11], we
found that the pre-existent WiFi access points around the deployment sites were
using standard IEEE 802.11 channels (namely, ch.1, ch.6 and ch.11) allowing us
to assign IEEE 802.15.4 ch.15, ch. 20, ch.25 and ch.26 channels to our patches.
Moreover, we also found that between the garage environment and the upper two
floors of the building no signal was present, so that two distinct RF environments
could be set.
Each WSN Patch was composed of around 100 nodes organized into a Cluster
Tree model having the GW as root and a total of 10–12 clusters, each of them with
8–10 SNs. Although some nodes were far apart from the others, we made the
conservative assumption that all nodes in a WSN Patch were sharing the same
collision domain, i.e., nodes were able to hear/interfere each other. The TDCS tool
(Sect. 6.1) was used to define an appropriate scheduling among the clusters. As
already mentioned, frequency division guaranteed that there was no interference
among the nodes of different WSN Patches.
Performance limits of the communication protocol have been evaluated by
focusing on the WSN Patch level, i.e., the portion of the EMMON network below
the gateway. In particular, using EM-Set, several scenarios were identified based
on all the combinations of the input parameters in Table 8.1. This setup generated
different network topologies with maximum depth5 (Lm ) ranging from 2 to 5 and
total number of nodes in one WSN Patch ranging from 25 to 501 (see Table 8.2).
In the simulated scenarios, the nodes’ application layer generates and sends
upstream a packet every T seconds. Packets have a fixed size of P bytes. Both best-
effort (BE) and real-time (RT) traffic classes are generated with the same packet
5
Maximum number of hops between a SN and the GW.
8.7 EMMON Demonstrator 155
Table 8.1 WSN patch Parameter Range Meaning

validation setup
Rm {2;3;4;5} Number of children
CH per parent
C {5;17;21} Number of
Clusters
R {5;10;15;20;24} Number of children
SNs per parent
SO 4 Superframe order
P 137 B NPDU size
T 2s Packet generation ratio
generation ratio (nodes use the contention-based access period and the contention
free period of the IEEE 802.15.4 superframe, respectively). BE traffic is intended
to simulate periodic sensor reports, while RT traffic accounts for alarm notifica-
tions. As a consequence, only CHs generate RT traffic: this reflects that only CHs
should reliably trigger alarm notifications toward the GW, by filtering out noisy
SNs readings.
The value of SO has been fixed to 4, which means an active portion of 960
symbols, while BO has been computed for each scenario by the TDCS tool, as well
as the set of CHs start times, in order to fit with the number of clusters (). Every
cluster in a WSN Patch is assumed to have the same value of the couple (BO, SO),
as in Fig. 7.1. Therefore, in the setup of Table 8.1, BO ranges between 7 and 9,
corresponding to beacon interval (BI) values of 2 and 8 s, respectively, and
duty cycles of 12.5 and 3.125 %, respectively.
As performance indices, the end-to-end (e2e) delay for BE (e2e-BE) and RT
(e2e-RT) traffic classes and the packet loss ratio are considered here, while other
available figures (e.g., per-node energy consumptions) are not shown, due to space
constraints.
The same experiments were run live into the test-bed. However, only best effort
traffic was generated, using the CAP portion of the IEEE 802.15.4 MAC. The
traffic was monitored through protocol analyzers with the help of sniffer tools
(Sect. 3.3) to compute the statistics for the e2e delay.
Table 8.2 shows an excerpt of the results related to network performance. In
particular, a subset of all the scenarios is presented with an increasing level of
network complexity, enabling the comparison between simulation and experi-
mental results for the e2e-BE delay, as well as between simulation and theoretical
worst case analysis for the e2e-RT. For the sake of comparison, since GTS slots
are allocated only to CHs, both e2e-BE and e2e-RT delays are computed as sum of
per-hop delays of messages sent from child to parent in the tree, recursively up to
the GW. The packet loss ratio for BE traffic only is also shown: these values
account for the number of packets whose sending failed after three retransmis-
sions. On the contrary, due to the design and setup choices (i.e., to assign GTS
slots to CH children only), RT traffic experienced no packet loss.
156
Table 8.2 Excerpt of results from the campaign defined in Table 8.1: simulation, worst-case and experimental results
Tot nodes r (clusters) R (SNs per CH) Rm Lm BO BI(s) CAP-best effort CEP-real time
Pkt loss (%) End-to-end delay (s) End-to-end delay (s)
Simulation Simulation Experimental Simulation Analytical
avg std max avg std max avg std max worstCase
25 5 5 4 2 7 2.048 0.56 1.73 1.12 3.73 1.32 0.36 2.06 1.95 1.13 3.92 5.82
45 5 10 4 2 7 2.048 2.39 1.80 1.12 3.80 1.59 0.40 1.99 1.97 1.13 3.91 5.82
65 5 15 4 2 7 2.048 5.53 1.81 1.12 3.82 1.67 0.38 2.14 1.97 1.14 3.91 5.82
85 5 20 4 2 7 2.048 8.48 1.82 1.13 3.83 1.68 0.56 2.19 2.00 1.15 3.91 5.82
101 5 24 4 2 7 2.048 10.20 1.83 1.15 3.84 1.71 0.53 2.35 2.04 1.14 3.90 5.82
97 17 5 5 3 9 8.192 2.47 13.96 5.52 36.03 12.99 5.16 45.70 14.65 5.35 34.02 41.86
257 17 15 5 3 9 8.192 10.29 16.28 6.58 47.02 14.45 5.30 23.53 41.86
401 17 24 5 3 9 8.192 13.08 16.38 7.49 44.20 14.61 5.36 23.53 41.86
97 17 5 3 4 9 8.192 2.75 22.56 12.89 109.90 18.84 5.89 23.85 23.63 12.89 68.73 69.87
257 17 15 3 4 9 8.192 10.84 23.86 12.53 116.30 22.15 10.70 62.82 69.84
401 17 24 3 4 9 8.192 13.32 20.97 9.67 54.85 19.17 8.14 55.62 69.84
97 17 5 2 5 9 8.192 2.14 23.18 9.03 38.97 25.14 7.87 95.38 24.44 9.00 57.97 94.76
257 17 15 2 5 9 8.192 10.49 27.11 11.47 75.04 24.79 9.17 52.78 94.76
401 17 24 2 5 9 8.192 13.16 28.22 13.02 78.44 24.17 9.44 54.93 94.76
121 21 5 2 5 9 8.192 2.23 23.08 9.04 39.13 24.29 8.91 57.34 94.76
321 21 15 2 5 9 8.192 10.28 26.30 11.58 76.18 23.95 9.49 54.08 94.76
501 21 24 2 5 9 8.192 12.84 27.15 12.35 67.63 23.92 9.39 38.89 94.76
8 Environmental Monitoring
8.7 EMMON Demonstrator 157
Although experimental results are available only for scenarios with up to 100
nodes, i.e., the maximum dimension of a single WSN Patch in the testbed, the
following conclusions can be drawn: (i) the statistics of the e2e-BE delay match
the experimental ones; (ii) the analytical tool for worst case dimensioning gives an
upper bound of the maximum e2e-RT delay; (iii) as expected, while the statistics
of e2e-RT delay are not influenced by the clusters’ size (R), for e2e-BE delay the
impact of a more crowded network becomes not negligible; and (iv) by looking at
the scenarios with C ¼ 17 and by averaging among the 5 values of R, a topology
with a wider ðRm ¼ 5; Lm ¼ 3Þ rather than a deeper ðRm ¼ 2; Lm ¼ 5Þ tree shows
gains in the e2e-BE and e2e-RT delays of almost 68.2 and 66.2 %, respectively.
Additionally, the difference in terms of packet loss for the same scenarios is
negligible. Finally, these results highlight that the EMMON network architecture
scales well with the number of nodes in a WSN Patch.
References
1. Emmon—embedded monitoring (2012), www.artemis-emmon.eu

2. S. Tennina, M. Bouroche, P. Braga, R. Gomes, M. Alves, F. Mirza, V. Ciriello, G. Carrozza,
P. Oliveira, V. Cahill, Emmon: a wsn system architecture for large scale and dense real-time
embedded monitoring, in 2011 IFIP 9th International Conference on Embedded and
Ubiquitous Computing (EUC), Oct 2011, pp. 150–157
3. S. Tennina, M. Alves, P.G. Sousa, M. Santos, P. Braga, M. Bouroche, G. Carrozza, R.
Monica, F. Pacheco, R. Gomes, A. Garg, R. Severino, Evaluation report: evaluation of
possible solutions, concepts for new communication methods. Deliverable D4.2, EMMON
Project, ARTEMIS Joint Undertaking Call for proposals ARTEMIS-2008-1, Grant agreement
no. 100036, 2010
4. R. Monica, P. Braga, Operational requirements consolidated from end-users input and
opinions. Deliverable D3.1, EMMON Project, ARTEMIS Joint Undertaking Call for
proposals ARTEMIS-2008-1, Grant agreement no. 100036, Feb 2010
5. A. Koubâa, A. Cunha, M. Alves, A time division beacon scheduling mechanism for IEEE
802.15.4/zigbee cluster-tree wireless sensor networks, in Proceedings of the 19th Euromicro
Conference on Real-Time Systems (ECRTS), July 2007, pp. 125–135
6. A.A. Abbasi, M. Younis, A survey on clustering algorithms for wireless sensor networks.
Comput. Commun. Spec. Issue Netw. Cover. Routing Schemes Wirel. Sens. Netw. 30,
2626–2841 (2007)
7. T. He, S. Krishnamurthy, L. Luo, T. Yan, L. Gu, R. Stoleru, G. Zhou, Q. Cao, P. Vicaire, J.A.
Stankovic, T.F. Abdelzaher, J. Hui, B. Krogh, Vigilnet: an integrated sensor network system
for energy-efficient surveillance. ACM Trans. Sens. Netw. 2(1), 1–38 (2006)
8. S. Tennina, M. Di Renzo, F. Graziosi, F. Santucci (2011) Distributed Localization
Algorithms for Wireless Sensor Networks: From Design Methodology to Experimental
Validation, Wireless Sensor Networks, (Ed.), ISBN:978-953-307-325–5, InTech,
DOI:10.5772/38731. Available from: http://www.intechopen.com/books/wireless-sensor-
networks/distributed-localization-algorithms-for-wireless-sensor-networks-from-design-
methodology-to-experime
9. C.-J.M. Liang, J. Liu, L. Luo, A. Terzis, F. Zhao, Racnet: a high-fidelity data center sensing
network, in Proceedings of the 7th ACM Conference on Embedded Networked Sensor
Systems, SenSys ’09, pp. 15–28, ACM, New York, 2009
10. S. Tennina, R. Gomes, M. Alves, V. Ciriello, G. Carrozza, The dark side of demmon: what is
behind the scene in engineering large-scale wireless sensor networks, in Proceedings of the
14th ACM International Conference on Modeling, Analysis and Simulation of Wireless and
Mobile Systems, MSWiM ’11, pp. 41–50, ACM, New York, 2011
11. C.-J.M. Liang, N.B. Priyantha, J. Liu, A. Terzis, Surviving wi-fi interference in low power
zigbee networks, in Proceedings of the 8th ACM Conference on Embedded Networked Sensor
Systems, SenSys ’10, pp. 309–322, ACM, New York, 2010
12. Ekahau heatmapper—the free wi-fi coverage mapping site survey tool (2011),
www.ekahau.com
Chapter 9
Energy-Efficiency in Data Centers
Abstract Moving from a still on-going work [1], this section reports the progress
being developed towards energy-efficient operations and the integrated manage-
ment of cyber and physical aspects of data centers. In particular, an integrated
system composed by wired and wireless sensors is presented: it monitors power
consumptions of the servers and environmental conditions, with the goal of
achieving an overall reduction of data centers’ energy consumptions. As like as the
EMMON system (Chap. 8), the architecture proposed is intended to be hierar-
chical, modular and flexible enough to achieve high temporal and spatial resolu-
tion of the sensor measurements, with negligible latencies of sensors’ reports to the
data center management control station.Overall, the advantage of having fine-
grained power and environmental measurements in this application scenario is
twofold: (i) measuring the power consumption at the single server level has
enormous benefits for the business logic of data centers’ owners, since they can
offer services and billing to their customers based on the actual consumption, and
(ii) although there are in literature models to predict heat-flows used in com-
mercial Computer Room Air Cooling (CRAC) systems, those models often lack of
spatial resolution, so the availability of micro-climate conditions would help
improving those models as well as continue feeding them with real data will
improve the reliability and accuracy of their forecasts. Fine-grained measurements
are also the basis to provide different views of the system, each of them cus-
tomized to different users. The proposed architecture allows to set the desired
resolution of the readings upon user’s requests, for example to investigate some
problems in a specific area (row, room or floor) of the data center building. Every
single sensor can be configured by setting user defined alarms and trigger mea-
surements reports adaptively, by changing or (re-)configuring specific thresholds at
run-time.

160 9 Energy-Efficiency in Data Centers
9.1 Architecture Overview
The system architecture is divided into three main sections. (i) The data-producing
entities, such as the sensor networks, which gather environmental data, IT
equipment or building equipment, which gather the data from the environment,
and also power consumption data. The data from these sensor networks is deliv-
ered to a (ii) data distribution system that acts as a broker between the (iii) data
producing entities and the consuming applications (e.g., logger applications, alarm
monitor, user interface applications).
At the core of the architecture depicted in Fig. 9.1 there is a data distribution
middleware, which takes care of handling the data coming from different sources
such as the environmental and power sensors and deliver this data to the appli-
cations interested in them. The applications can be a data logger that gathers
historical information, visualization tools, alarms monitors or any other application
that can be developed in the future.
In the following subsections, the proposed system architecture is described in
more detail, highlighting each component of the data gathering, while for the data
distribution system interested reader can refer to [1].
9.1.1 Environment and Power Data Collection
In order to trade-off among (i) fine-grained sensors’ measurement (spatial) reso-

lution, (ii) system flexibility and modularity and (iii) low-latency reporting of the
Fig. 9.1 Architecture overview

9.1 Architecture Overview 161
measurements, the proposed architecture for the data collection is a mix of wired
and wireless technologies.
The WSN is a stacked multi-tier architecture, where each level represents a
network tier with the corresponding devices and communication technology used.
The lower level, Level-0 consists of sensor nodes, i.e., computational units with
several physical sensors attached, which perform sensing tasks and deliver data to
the devices at the next level in the hierarchy through a wired bus. At level-1,
cluster heads are responsible for querying the sensor nodes within their respective
cluster. A cluster is composed by one cluster head (bus master) and several sensor
nodes (bus slaves) attached to the wired bus. Then, these cluster heads are
responsible for data aggregation and sensor fusion. They communicate using IEEE
802.15.4/ZigBee with devices at the next level in the hierarchy. At the level-2 of
the network hierarchy, (environment) gateways are present. These devices have
the highest computational capabilities among the devices present in the sensor
network field. Gateways provide the data gathered from the sensor network to the
data distribution system in a standard format. Finally, in level-3, the data distri-
bution provides means to deliver the data gathered from the sensor network to the
applications. The data distribution system supports any number of gateways and
applications in a distributed and transparent way.
Sensor Nodes: starting from the bottom of the network architecture, a Sensor
Node is a communication/computation enabled device physically linked (e.g., over
a I2C bus) to a given number of sensors. These sensors are responsible for mea-
suring different physical parameters like, e.g., temperature, humidity, pressure, as
well as several power sensors to monitor the power consumption of each server in
the rack.
To keep the complexity low, at this tier of the Network Architecture, the Sensor
Nodes communicate with one Cluster Head over a bus, e.g., using a RS485/
MODBUS technology [2]. In particular, the Cluster Head node acts as a local
coordinator and master of the bus. The sensor nodes are deployed one each rack
and their sensors get measurements from all the elements of the rack.
Cluster Heads: the Clusters are connected with each other in a ZigBee/IEEE
802.15.4 mesh topology to form a WSN Patch, where a common Gateway is in
charge of gathering data and sending them over long range communication
technology (e.g., WiFi). In terms of HW platforms, the Cluster Head node is the
same platform as a generic Sensor Node, with an on-board ZigBee modem [3].
Gateways: The sensor network can have one or more Gateways. Gateways
maintain representations of the data flows from the sensor network to the data
distribution system. They perform the necessary adaptation of the data received
from the WSN. The gateways can be deployed as one per room serving all the
rows of racks in that room more gateways can also be deployed to improve radio
coverage, for load-balancing or for redundancy.
9.2 Data Center Radio Environment
This section presents a first step toward enabling a large installation of wireless
communicating devices. It is often assumed that the presence of lots of metallic
surfaces (such as racks) and power cables suspended on the ceiling, makes a data
center room a harsh environment in terms of radio signal propagation. Therefore,
an analysis of the radio conditions of a typical data center has been conducted to
assess the validity of that assumption and evaluate its impact. The measurements
were performed in a data center (located in Lisbon, Portugal) owned by the largest
Portuguese telecommunications operator, Portugal Telecom (PT), which also
provides hosting and cloud-based services. The objective of such measurement
campaign has been twofold: (i) evaluate the available IEEE 802.15.4 channels for
the monitoring network to be deployed in the data center, and (ii) test the con-
nectivity among IEEE 802.15.4 radios in the field, in order to identify the
requirements for the formation of the network topology.
9.2.1 Background Noise
Firstly the background noise level, i.e., the possible interference on the monitoring
network due to external IEEE 802.11/WLANs has been monitored. To do this, a
frequency spectrum analyzer [4] has been used. As expected, there are only few
IEEE 802.15.4 channels in the 2.4 GHz band available. Channel 26, as it shown a
negligible interference from 802.11, was the preferred channel for the WSN
connectivity measurements. In general, these background noise measurements
show that the number of available channels in a typical data center might be low.
9.2.2 WSN Connectivity
For the connectivity measurements, in this scenario 9 TelosB [5] nodes (a GW and
8 routers) running on batteries and 3 TelosB powered by USB, acting as sniffers
were used. The routers were placed at the top of the center rack of 9 rows on a data
center.
First, the connectivity between routers was checked. For this, the GW was
placed on a corner of the data center and the routers (R1 –R8 ) were left on the center
of the rows. This experiment tested that the chain among the GW and all the
routers was working, i.e., the GW started emitting beacons, R1 gets these beacons,
associates to the GW and start emitting its own beacons. Then R2 gets R1 ’s
beacons, associates with R1 and starts emitting its own beacons, and so on until R8 .
At run time, all routers were able to emit non-interfering beacons, on a time-
division fashion.
9.2 Data Center Radio Environment 163
Fig. 9.2 Data center room radio measurements.

Then, the 3 sniffer nodes were used to take measurements, as follows. First, the
3 nodes were placed on one half of the row and then on the other half of the same
row (being the 3 nodes spaced about 1.5 m apart from each other, where the one
furthest from the middle was 5 m from the center), then packets for 5 min were
collected in each half section of the row and repeated this procedure for 9 rows.
The measurements were performed by looking at a counter in the beacon
payload that was incremented each time a beacon was transmitted. By extracting
the source address and the counter in the beacons from the sniffers’ logs, the
packet loss probability on each measurement point and with respect to each router
was measured, as well as information about the Received Signal Strength (RSS) of
each received packet. By combining these data, it was possible to build maps of
the coverage for each beacon emitter. Figure 9.2 shows an example of such results
for the GW and the cluster head R1 . The packet loss is better than what one could
have expected: in general the majority of the routers was able to cover half of the
room with negligible losses (i.e., packet loss ratio \ 2 %). Only spots of con-
nectivity loss areas were evidenced, e.g., in proximity of a pillar in the room: these
conditions can be resolved by planning accurately the position of the cluster heads.
9.3 Remarks
This study enables to understand better the radio conditions. These findings are in
line with those of previous work [6, 7]: even in a data center room of reasonable
dimensions, each wireless node could interfere with up to 65 % of the nodes.
Then, having too many nodes interfering with each other is an obstacle toward
gathering sensor readings with high temporal resolution, and this needs to be
considered in the design.
Overall, this architecture, which mixes wired and wireless technologies in a
modular and flexible fashion, enables interesting trade-offs between fine-grained
monitoring and low-latency.
References
1. N. Pereira, S. Tennina, E. Tovar, Building a microscope for the data center, in 7th
International Conference on Wireless Algorithms, Systems, and Applications (WASA 2012),
Yellow Mountains, Aug 2012
2. Modbus over serial line—specification and implementation guide-v1.0 (2002), http://
www.modbus.org/docs/Modbus_over_serial_line_V1.pdf Feb 2002
3. Zigbee modules and mesh modules (2012), www.digi.com/products/wireless-wired-
embedded-solutions/zigbee-rf-modules/zigbee-mesh-module
4. Metageek’s wispy, www.metageek.net/products/wi-spy
5. Memsic, TPR2420CA TelosB Mote May (2013), www.memsic.com/wireless-sensor-networks
References 165
6. C.-J.M. Liang, J. Liu, L. Luo, A. Terzis, F. Zhao, Racnet a high-fidelity data center sensing
network, in Proceedings of the 7th ACM Conference on Embedded Networked Sensor Systems,
SenSys ’09, (ACM, New York, 2009), pp. 15–28
7. B. Weiss, H.L. Truong, W. Schott, T. Scherer, C. Lombriser, P. Chevillat, Wireless sensor
network for continuously monitoring temperatures in data centers. IBM RZ 3807 (2011)
Chapter 10
Conclusions
Abstract Designing, deploying and operating a large-scale wireless sensor net-

work is a challenging task per se. When the applications impose stringent quality-
of-service requirements, such as in what concerns reliability, timeliness and
security, this problem is even more acute, forcing system/network designers to
develop and use rigorous methodologies and reliable tools. Starting from the
assumption that IEEE 802.15.4 and ZigBee cluster-tree are prominent baseline
protocols for WSN applications with QoS requirements, this book gathers best
practices in the engineering of such networks.
Designing a large scale wireless sensor network is already a challenging task.
When application requirements includes also certain Quality of Service guaran-
tees, such as data reported in a timely and reliable manner, system and network
designers really need to develop rigorous methodologies and reliable tools.
Starting from the assumption that the ZigBee Cluster Tree and IEEE 802.15.4 are
one of the best baseline protocols for wireless sensor networks to provide quality
of service guarantees, this book gathers best practices in the engineering of such
networks.
In the first part of this book, we started with an overview of the communication
standards in Chap. 1 and stressed the gaps and issues that the standards still leave
open. Chap. 2 described an implementation of IEEE 802.15.4 and ZigBee Cluster
Tree network layer that we released and made available as open source to the TinyOS
community. The choice of implementing our solution over TinyOS is that it is a
worldwide recognized de-facto standard operating system for wireless sensor
networks; moreover it actually supports an ever growing number of hardware
platforms. In Chap. 3 we presented several tools including analytical models, sim-
ulation software, sniffers and protocol analyzers. These tools were used to thor-
oughly assess performance limits of such system, and results are detailed in Chap. 4.
The second part is dedicated to a detailed analysis of how several open issues of
the standards can be addressed. Then, specific amendments to IEEE 802.15.4
(Chap. 5) and ZigBee (Chap. 6) are presented. They include solutions (i) to
improve the security performance of the system (Sects. 5.4 and 6.3), (ii) to
improve the scalability by overcoming some drawbacks in the GTS slots

168 10 Conclusions
assignment methods (Sect. 5.1), or (iii) by avoiding the impact of hidden terminals
in wireless communications (Sect. 5.2), (iii) to classify the network traffic into
several priority levels rather than only two (Sect. 5.3), (iv) to minimize the energy
consumption while achieving QoS requirements through an appropriate scheduling
of the nodes activity periods (Sect. 6.1), and (v) to address the nodes based on
some common property (Sect. 6.2).
Finally, the third part of the book takes advantage of all the lessons learnt in the
previous chapters to show the reader several examples from our own experience in
real-world network design and deployment. The application domains range from
structural health (Chap. 7) to environmental (Chap. 8) and data center (Chap. 9)
monitoring. The heterogeneity of these case studies clearly demonstrates how the
solutions offered by the chosen technology as well as the developed methodologies
and tools are flexible to adapt with a minimal fine tuning of the parameters to
several application domains.
Overall, once again, we believe this book will serve as a baseline reading
material for students and researchers as well as a reference to orient system
designers in this area.
About the Authors
S. Tennina (corresponding author) is with WEST Aquila srl, University of

L’Aquila, Italy and CISTER/INESC-TEC, ISEP, Polytechnic Institute of Porto,
Portugal
e-mail: tennina@westquila.com
A. Koubâa is with CISTER/INESC-TEC, ISEP, Polytechnic Institute of Porto,
Portugal and COINS Research Group, Prince Sultan University, Saudi Arabia
e-mail: aska@isep.ipp.pt
M. Alves, R. Severino, N. Pereira, E. Tovar are with CISTER/INESC-TEC,
ISEP, Polytechnic Institute of Porto, Portugal
e-mail: mjf@isep.ipp.pt; rars@isep.ipp.pt; nap@isep.ipp.pt; emt@isep.ipp.pt
P. Jurčík is with CISTER/INESC-TEC, ISEP, Polytechnic Institute of Porto,
Portugal and Department of Control Engineering, Faculty of Electrical
Engineering, Czech Technical University in Prague, Czech Republic
e-mail: petr@isep.ipp.pt
R. Daidone, M. Tiloca, G. Dini are with Department of Information Engineering,
University of Pisa, Italy
e-mail: roberta.daidone@iet.unipi.it; marco.tiloca@iet.unipi.it; gianluca.dini@iet.
unipi.it
J.-H. Hauer is with Telecommunication Networks Group, Technical University
Berlin, Germany
e-mail: hauer@tu-berlin.de
M. Bouroche is with Distributed System Group, Trinity College Dublin, Ireland
e-mail: melanie.bouroche@scss.tcd.ie

in Cooperating Objects, DOI: 10.1007/978-3-642-37368-8, Ó The Author(s) 2013

(SpringerBriefs in Electrical and Computer Engineering) Stefano Tennina, Anis Koubâa, Roberta Daidone, Mário Alves, Petr Jurčík, Ricardo Severin

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

(SpringerBriefs in Electrical and Computer Engineering) Stefano Tennina, Anis Koubâa, Roberta Daidone, Mário Alves, Petr Jurčík, Ricardo Severin

Hochgeladen von

Copyright:

Verfügbare Formate

SPRINGER BRIEFS IN ELEC TRIC AL AND

COMPUTER ENGINEERING  COOPERATING OBJECTS

Stefano Tennina · Anis Koubâa · Roberta Daidone

IEEE 802.15.4 and

For further volumes:

Roberta Daidone Mário Alves

Petr Jurčík Ricardo Severino

Marco Tiloca Jan-Hinrich Hauer

Nuno Pereira Gianluca Dini

Mélanie Bouroche Eduardo Tovar

IEEE 802.15.4 and ZigBee

ISSN 2191-8112 ISSN 2191-8120 (electronic)

Library of Congress Control Number: 2013936525

Ó The Author(s) 2013

Printed on acid-free paper

Springer is part of Springer Science+Business Media (www.springer.com)

Porto, May 2013 Mário Alves

Part I IEEE 802.15.4 and ZigBee Protocols and Implementations

1 Snapshot of the IEEE 802.15.4 and ZigBee Protocols . . . . . . . . . . 3

3 Models and Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2 Simulation Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4 Performance Analysis and Network Dimensioning . . . . . ....... 65

Part II Quality of Service Amendments

5 Amendments to the IEEE 802.15.4 Protocol . . . . . . . . . . . . . . . . 85

6 Amendments to the ZigBee Protocol . . . . . . . . . . . . . . . . . . . . .. 113

Part III System Architectures and Applications

7 Structural Health Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

8 Environmental Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

9 Energy-Efficiency in Data Centers. . . . . . . . . . . . . . . . . . . . . . . . 159

About the Authors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

1.1 General Aspects

S. Tennina et al., IEEE 802.15.4 and ZigBee as Enabling Technologies 3

Fig. 1.1 ZigBee architecture [1]

The ZigBee Network Layer (NWK) is responsible for Network management

1.2 IEEE 802.15.4

1.2.1 Physical Layer

Fig. 1.3 Operating frequencies and bands

1.2.2 Medium Access Control Sub-Layer

Fig. 1.4 IEEE 802.15.4

1.2.2.1 Superframe Structure

Fig. 1.5 IEEE 802.15.4 superframe structure [3]

made using the Slotted CSMA/CA mechanism. However, the acknowledgement

In beacon-enabled mode, each Coordinator defines a superframe structure

Optionally, an inactive period is defined if BI [ SD. During the inactive period

1.2.2.2 Association and Channel Scan Mechanisms

1.2.2.3 Guaranteed Time Slot Mechanism

Fig. 1.6 GTS allocation message sequence diagram [3]

Fig. 1.7 CFP defragmentation upon a GTS deallocation [3]

1.2.2.4 CSMA/CA Mechanism

In IEEE 802.15.4, contention-based Medium Access Control (MAC) can be either

Fig. 1.8 The slotted CSMA/CA mechanism [3]

• Number of Backoffs (NB), representing the number of failed attempts to access

Fig. 1.9 The un-slotted CSMA/CA mechanism [3]

1.2.2.5 Inter-Frame Spacing

Fig. 1.10 Inter-frame spacing [3]

1.2.2.6 Transmission Scenarios and Reception Conditions

The IEEE 802.15.4 protocol standard enables three different types of

Fig. 1.12 Network layer

1.3.1 Short Address Assignment

A parent device uses the Cm , Rm and Lm values to compute a Cskip function

Achild ¼ Aparent þ ðn 1Þ CskipðdÞ þ 1; n¼1 ð1:5aÞ

Achild ¼ Aparent þ ðn 1Þ CskipðdÞ; n [ 1: ð1:5bÞ

Achild ¼ Aparent þ Rm CskipðdÞ þ n: ð1:6Þ

Fig. 1.13 Cskip-based address assignment scheme example