analysis of the scalability of hierarchical ieee 802.15.4/zigbee networks 1 departamento de...

1

Analysis of the scalability of hierarchical IEEE 802.15.4/Zigbee networks


Departamento de Tecnología Electrónica. University of MálagaETSI de Telecomunicación, Campus de Teatinos, 29071 – Málaga- SpainE-mail: [email protected]

Third International ICST Conference on Scalable Information Systems (Infoscale 2008)

E. Casilari, A. Flórez-Lara, J.M. Cano-García

UNIVERSIDAD DE MÁLAGA, SPAINVico Equense (Italy), 4th June 2008

2


Index

1. Introduction: WPANs and 802.15.4/Zigbee

2. Overview of IEEE 802.15.4

3. Strategies to avoid beacon collision

4. Results

5. 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

2 ; 2BO SOBI a SD a

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):

1 1

2 2C C

i

N NSOBO

ii i

BI a SD a

11


Policies to distribute the Beacon Interval (I)

1. Equidistribution: All Superframe orders are set to the same value

1,i CSO SO i N 2 2

2log log

BO

CC

SO BO NN

2. Fixed Priorization of the superframe order of the coordinator: Superframe order of the coordinator is set to twice the value of the rest

1

2,

2i CSO SO i N

SO SO

1

2

2

1

2 2 2 ( 1) 2C

i

NC

i

NSOBO SO SO

Ci SD

SDi

a a a a N

22log 1 ( 1) 4 2 1BO

C CSO N N

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)

Policy for determining the Superframe Orders

Same SO for all nodesPrioritization of

Zigbee coordinator (ZC)

Topology Based Distribution

SO=6 SO1=6, SO2,3=3 SO1=7, SO2,3=6

ρ Throughput ρ Throughput ρ Throughput

55% 4210 bps 56% 810 bps 56% 6478 bps

47% 3562 bps 45% 648 bps 46% 5371 bps

40% 3077 bps 34% 486 bps 41% 4720 bps


Same SO for all nodes

Prioritization of Zigbee coordinator

(ZC)


SO=5 SO1=6, SO2,3,4,5=3 SO1=7, SO2,3,4,5=5


56% 814 bps 56% 810 bps 56% 3255 bps

45% 651 bps 45% 648 bps 45% 2604 bps

34% 488 bps 34% 486 bps 39% 2278 bps

Scenario 1

Scenario 2

16


Results (II)

Scenario 3


Same SO for all nodesPrioritization of

Zigbee coordinator (ZC)


SO=7 SO1=6, SO2=3 SO1=7, SO2=7


39% 2604 bps

45% 163 bps*

39% 2604 bps

36% 2115 bps 36% 2115 bps

34% 1953 bps 34% 1953 bps

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.

analysis of the scalability of hierarchical ieee 802.15.4/zigbee networks 1 departamento de...

Documents