Analysis of the scalability of hierarchical IEEE 802.15.4/Zigbee networks

1. Third International ICST Conference on Scalable Information Systems (Infoscale 2008) Analysis of the scalability of hierarchical IEEE 802.15.4/Zigbee networks E. Casilari, A. Flórez-Lara, J.M. Cano-García UNIVERSIDAD DE MÁLAGA, SPAIN Vico Equense (Italy), 4th June 2008 Departamento de Tecnología Electrónica. University of Málaga ETSI de Telecomunicación, Campus de Teatinos, 29071 – Málaga- Spain E-mail: ecasilari@uma.es

2. Index • Introduction: WPANs and 802.15.4/Zigbee • Overview of IEEE 802.15.4 • Strategies to avoid beacon collision • Results • Conclusions

3. Introduction: 802.15.4/Zigbee • Standards IEEE 802.15.4 (PHY and MAC) and Zigbee jointly describe a protocol stack for the definition of Wireless Personal Area Networks (WPAN). • Aimed at providing solutions for low-cost wireless embedded devices (transceivers under 1$) with consumption and bandwidth limitations • Low rate (up to 250 Kbps), short range (up to 10 m) communications • In immature state but appealing candidate to support a wide set of services, particularly for low consume domotic sensor networks (although real time services are also contemplated for services such as voice or biosignals) • Main challenge of 802.15.4/Zigbee: potentiality to set up self-organizing (ad hoc) networks capable of adapting to diverse topologies, node connectivity and traffic conditions. • Advantages of 802.15.4 mainly depend on the configuration of MAC sublayer

4. Operation modes of 802.15.4 • The MAC layer of IEEE 802.15.4 enables two alternative operational modes: • 1. Non beacon-enabled (point-to-point) mode: • Access control is governed by non-slotted CSMA/CA • Higher scalability but nodes must be active all time (elevated power consumption) • Real time constraints cannot be guaranteed • 2. Beacon-enabled mode, • A coordinator node periodically sends beacons to define and synchronize a WPAN formed by several nodes • Nodes can wake up just in time to receive the beacon from their coordinator and to keep synchronized (power efficiency) • Synchronization permits to guarantee time slots (resources) to delay sensitive services • Main problem: scalability → Time must be divided between clusters

5. Configuration of beacon enabled networks • Two classes of nodes: the so-called Full-Function Devices (FFD) and the Reduced-Function Devices (RFD). • Star topology: • A FFD performs as the network ‘coordinator’, in charge of the communications of a set (or ‘cluster’) of RFD nodes (the ‘children’ nodes). The coordinator periodically emits a beacon to announce the network and to keep children synchronized • Beacon Interval (BI), divided in an active part and an inactive part. Active part consists of a ‘Superframe’ of 16 equally-spaced time slots. • Contention Free Period (CFP): guaranteed slots for certain nodes • Contention Access Period (CAP): nodes compete for the medium access • All the transmissions take place during the Superframe Duration (SD) • In the inactive period all nodes (including the coordinator) may enter a power saving mode to extend the lifetime of their batteries

6. Structure of a 802.15.4 superframe • Where a= 15.36, 24 or 48 ms when a rate of 250, 40 or 20 kbps is employed • Configuration of BO and SO: trade-off • BO >> SO: almost all BI corresponds to the inactivity period, high power saving, low rate can be achieved • Other case: lower power saving but higher rate

7. Zigbee Cluster-trees • Apart from the tree networks with a single coordinator, the Zigbee standard permits the association of cluster coordinators to form cluster-trees. • One of the coordinator nodes assumes the central role: PAN or Zigbee Coordinator (ZC). The rest of the coordinators are Zigbee Routers (ZRs) • ZRs responsible for retransmitting the data from any ‘child’ node (leaf) within their clusters • Zigbee specification does not impose any protocol nor algorithm to create this type of networks • Existing commercial 802.15.4-compliants modules do not support the formation of cluster-tree topologies • Coexistence of more than one coordinator → possibility that beacons (simultaneously emitted by two adjacent coordinators) get lost due to collisions. • Beacon collision provokes children to desynchronize from the router

8. Strategies to avoid beacon collision (I) • IEEE 802.15.4 Task Group 15.4.b has proposed two generic strategies to cope with beacon collision • 1. Beacon-only period: a time window that is specifically reserved for the transmission of all the beacons in the network. • Advantages: superframe duration of each cluster can be designed with independence of the rest • Problems: -It modifies the superframe structure of the standard - The coexistence of active periods of different clusters augments the possibility of packet collision while it prevents the implementation of Guaranteed Time Slots

9. Strategies to avoid beacon collision (II) • 2. Sequencing of the beacons and Superframes: in non-overlapped periods during the Beacon Interval • Advantages: Standard is respected, GTS can be implemented • Problems: scheduling of beacons within the different Beacon Interval and especially the duration of the superframes must be carefully designed. Otherwise: serious problem of scalability

10. Objective • Assumptions: • Pessimistic case: Any node can interfere the rest, no radio planning (all nodes transmit in the same channel)→ Superframes cannot overlap • Hierarchical cluster-tree, all traffic flowing to the ZC (typical case of a sensor network) • Problem to solve: to define the superframe durations (SOi) of the clusters • Objective: to maximize the utilization of the BI • Condition to be accomplished in any case (for a network of NC coordinators: routers+ZC):

11. Policies to distribute the Beacon Interval (I) • 1. Equidistribution: • All Superframe orders are set to the same value • 2. Fixed Priorization of the superframe order of the coordinator: • Superframe order of the coordinator is set to twice the value of the rest

12. Policies to distribute the Beacon Interval (II) • 3. Topology based distribution: • The order is particularized for each router depending on the number of the leaf nodes • Proposal of an iterative algorithm: • li be the number of leaf nodes ‘depending’ of the i-th coordinator (or supported traffic) • The SO of the coordinator with the highest lj is increased in one unit • If the BI is not exceeded by the sum of the SDs, the increase of SO is admitted & lj is divided by two • The process is repeated while no SO can be increased without exceeding the BI

13. Simulation parameters • Ad hoc simulator in C++ • Packet level results formatted so they can be analyzed with Chipcon CC2420 Packet Sniffer • Three different network topologies: three-layer hierarchy in which leaf nodes (those generating traffic) do not have any children. • Simulations for different traffic loads • Network performance evaluated by means of the throughput: ratio between the number of bytes that are successfully transmitted per leaf node and per superframe and the Beacon Interval.

14. Evaluated scenarios (II) • Scenario 1: routers support different traffic • Scenario 2: Coordinators supports many routers • Scenario 3: the coordinator support the same traffic than router

15. Results (I) • Scenario 1 • Scenario 2

16. Results (II) • Scenario 3 • Results of the topologies in which the Zigbee coordinator concentrates the traffic (e.g.: the scenario 2) evidence that resources cannot be equally distributed among the clusters. • Scenario 3; limit case in which a router has to transport the same traffic of the Zigbee Coordinator. SO order of both clusters must be equal

17. Conclusions & Future Work • Problem of configuring SD is a key aspect for hierarchical 802-15.4/Zigbee cluster-trees • Even in small networks with less than twenty nodes a proper design of the duration of the 802.15.4 superframes is crucial to achieve a reasonable network performance. • An iterative strategy to design the SD of the nodes of a Zigbee network has been proposed. • SD is defined as a function of the topology (traffic) • Simple policies to distribute the beacon interval without taking into account the topology and traffic condition in the PAN leads to an inefficient network design • Future work should investigate the adaptation of this type of algorithms to more complex situations: node mobility, not all the routers interfere, etc.