A NEW MULTICAST ROUTING ALGORITHM FOR ZIGBEE

NETWORKS

Bilge Kartal, Radosveta Sokullu

Dept. of EEE, Ege University, Izmir, Turkey

Tapio Suihko

Technical Research Centre of Finland

Keywords: Wireless medical sensor networks, ZigBee, multicast routing.

Abstract: In recent years, wireless sensor networks have become widely spread in many areas including medical

applications. Some of these applications outgrow the traditional communication model applied to wireless

sensor networks according to which data is flowing towards a single receiver (sink). In the case of medical

data acquisition systems more then one receiver is a viable model. In this paper we discuss details on data

broadcast algorithms for the 802.15.4 based ZigBee network standard and their applicability to creating

sensor networks for medical data applications, focusing especially on transmitting data to multiple receivers

(multicast concept). The multicast concept is not currently supported by ZigBee. So we have focused on

introducing a multicast communication model and suggested a new algorithm based on ZigBee which is

specifically optimized to support multiple sinks. Further on the paper describes our experiences with

developing M-Bee, a multicast routing algorithm platform, using the open Microchip’s ZigBee software

stack.

1 INTRODUCTION

In recent years wireless sensor networks (WSNs)

have become a very active research area supported

both by recent advances in hardware and pressing

demands for creating ubiquitous sensing

environments for our future world. Simulation and

experimental work is focusing on verifying and

creating suitable application oriented

communication models and protocols for a new

wireless environment. As an example we can

consider the healthcare sector. A number of wireless

medical monitors are currently on the market,

including electrocardiographs (EKGs), pulse

oximeters, blood pressure monitors, fetus heart rate

and maternal uterine monitors. Most of these devices

use Bluetooth or analog Wireless Medical Telemetry

Service (WMTS) bands, and several employ IEEE

802.11. However, these systems are generally

designed only to “cut the cord” between the sensor

worn by the patient and a bedside monitor or another

nearby receiving device. In the future such systems

will be built on wireless sensors and will require to

be incorporated in a network, to provide collection

of data from multiple patients or to transmit data to

multiple receivers (doctors, nurses) in a multi-hop

structure. Similar scenarios exist in fire fighting and

rescuing situations. (Lorincz 2004).

In this paper we propose a new routing protocol,

M-Bee, based on IEEE 802.15.4 and ZigBee, which

is enhanced with multicast features. Presently the

ZigBee standard supports only unicast and broadcast

transmissions. In light of the existing model above

each data packet will be flooded in the network until

it reaches a given receiver or receivers. If multicast

is introduced the flooding will be used only for

establishing a multicast route and then all the

packets will be transmitted over that tree reducing

the amount of traffic.

From here on the paper is organized as follows:

In section 2 a concise description of ZigBee is

presented. In section 3 we examine related work on

multicast protocols. In sections 4 and 5 we discuss

the prototype architecture and the implementation

details of M-Bee, including some assumptions made

for the model and details on the multicast data

146

Kartal B., Sokullu R. and Suihko T. (2007).

A NEW MULTICAST ROUTING ALGORITHM FOR ZIGBEE NETWORKS.

In Proceedings of the Second International Conference on Wireless Information Networks and Systems, pages 146-150

DOI: 10.5220/0002148201460150

 SciTePress

transfer mechanisms. We summarize our

implementation results on Microchip’s PICDEM-Z

hardware in section 6, and draw the conclusions in

section 7.

2 ZIGBEE AND IEEE 802.15.4

ZigBee is a wireless network protocol specifically

designed for low data rate sensors and control

networks. There are a number of applications that

can benefit from the ZigBee protocol like building

automation networks, home security systems,

industrial control networks, patient monitoring,

remote metering etc.

ZigBee uses the IEEE 802.15.4 physical and

MAC layers to provide standard-based, reliable

wireless data transfer. ZigBee adds network

structure, routing, and security to complete the

communications suite. On top of this wireless

engine, ZigBee profiles provide target applications

with the interoperability and intercompatibility

required to allow similar products from different

manufacturers to work seamlessly. IEEE 802.15.4

provides three frequency bands for communications.

Based on IEEE 802.15.4, the ZigBee Alliance

specifies the standards for the network layer and the

application layer, the ZigBee device object (ZDO)

and the manufacturer defined application objects.

Two types of devices are defined: Full Function

Device (FFD) and Reduced Function Device (RFD).

An FFD can serve as a coordinator or regulator

device. It can communicate with any other devices

within its transmission range. An RFD is a simple

device that associates and communicates only with

an FFD.

The responsibilities of the ZigBee network layer

include joining/leaving a network, security, routing,

discovering 1 hop neighbours and storing neighbour

information. The network topology can be multi-hop

so that any pair of devices can communicate with

each other through the help of intermediate node.

The responsibilities of the ZigBee network layer

include joining/leaving a network, security, routing,

discovering 1 hop neighbors and storing neighbor

information. The network topology can be multi-hop

so that any pair of devices can communicate with

each other through the help of intermediate nodes.

ZigBee allows multi-hop communications based

on Ad Hoc On Demand Distance Vector (AODV)

routing protocol for general multi- hop ad-hoc

networks (

Ergen 2004). Multicast is not included in

the ZigBee Specification v1.0. (ZigBee Specification

2005). This version assumes only general broadcast,

duplicate packet suppression, and unicast

transmission based on AODV.

3 RELAITED WORK

Multicast routing in ad hoc networks is a very

dynamic research field. Extensions to existing ad

hoc routing protocols have been proposed like

MAODV, based on AODV (

Royer 1999) as well as

new purely multicast oriented protocols have been

suggested like ODMRP and ADMR (

Jetcheva 2001),

(

Perkins 1999). Even though these protocols are

suitable for mobile nodes and wireless links they are

based on the IEEE 802.11 physical layer. They also

include very sophisticated link repair mechanisms as

they consider larger amounts of data being

transferred. To be applicable for WSN, protocols

have to be very light and quickly converging

because of the resource limitations of the nodes both

power-wise and memory-wise. An example in this

respect is AODVjr (

Chakeres 2002). Another new

protocol is a version of ADMR called TinyADMR

which includes also multicast functions and an

implementation is based on TinyOS Mica motes.

(Cheng 2006). To our knowledge there is no similar

work based on ZigBee, specifically on its Microchip

Stack. ZigBee uses a combination of AODV and

Link State Routing protocols for broadcast and

unicast communication only and has no multicast

concept. We believe that benefits like reduction in

delivery delay, less packet overhead and decreasing

network traffic can be provided by introducing

multicast routing in ZigBee. We have carefully

examined the Adaptive Demand Driven Multicast

Routing (ADMR) and TinyADMR, which suggest

some very useful ideas for multicasting. ADMR

allows delivery of packets from senders to receivers

by routing each packet along a set of forwarding

trees that are constructed on demand. Data is

multicast by sending packets to group addresses

rather than individual node addresses. We have also

considered the ODMRP, as it relies on a forwarding

mesh instead of a tree but as its packet format cannot

be reduced significantly it has not been found a good

candidate.

In our work we have focused on creating a

multicast mechanism model which can be

incorporated with the existing ZigBee standard.

A NEW MULTICAST ROUTING ALGORITHM FOR ZIGBEE NETWORKS

147

4 M-BEE AND OUR PROTOTYPE

ARCHITECTURE

M-Bee is a multicast routing framework built on top

of ZigBee that allows multiple patients to relay data

to all receivers that have registered an interest in that

patient. This communication model fits with the

needs of medical applications where a number of

caregivers may be interested in the same patient’s

data.

Our multicast model is based on two major

procedures: Route Discovery (RD) and Receiver

Join (RJ). During the RD phase a sender node

(potentially one which has data to transmit) tries to

locate the receivers interested in this data and forms

a route to them. This route is reinforced during the

RJ phase in which each receiver declares its joining

the route to the data source. After the route is

established data packets are multicast only to the

nodes that have joined. Thus unnecessary broadcast

is much reduced and network traffic is diminished.

In implementing the ROUTE-DSICOVERY and

RECEIVER-JOIN procedures we have utilized the

broadcast and unicast possibilities presented by

ZigBee.

Our prototype realization of M-BEE is a network

design consisting of one coordinator and seven client

devices. We focus on the case of multiple receivers,

in which data from a single node (patient) has to

reach with min latency and min network traffic

multiple receiver nodes (caregivers). We have

implemented the M-Bee design in several layers of

the ZigBee stack including the network and MAC

layer. We use Microchip PICDEM-Z board as

hardware and Microchip ZigBee Stack as software.

5 M-BEE MULTICAST PACKET

FORMAT AND PROTOCOL

OPERATION

The IEEE 802.15.4 maximum MAC frame size is

127 byte with 16 bit CRC. The maximum

application payload size is 97 bytes, calculated as:

127-[MAC Header(11)+NWKHeader(8)+

APSHeader(6)+AF Header (for MSG,3)+

CRC(2)]=97

Each M-Bee multicast packet carries an 8 byte

M-Bee header. The M-Bee Header fields are briefly

described below:

PacketType (1 byte): Indicates whether a packet

is a ROUTE-DISCOVERY, RECEIVER-JOIN or

DATA message.

Group Address (1 byte): The group address of

the packet.

Origin MAC Address (2 byte): According to

IEEE 802.15.4 the MAC address of any node is 8

bytes but for our implementation in order to save

memory space we use only 2 bytes.

Origin NWK Address (2 byte): Network address

of the node.

Hop Count (1 byte): The number of hops the

packet travels (used only for RECEIVER JOIN

packets).

Route Cost (1 byte): Reserved for future

optimization of routing criteria and performance

evaluation.

According to the ZigBee routing mechanism for

a packet to be sent we need a route request packet (6

bytes) and a route reply packet (8 bytes). If we have

more than one receiver then we using the same

mechanism we have to build a route tree for every

receiver separately. So the overhead/payload is

directly proportional to the number of receivers. On

the other hand in the case of M-Bee it is not

necessary to build a separate tree for each sender-

receiver pair and thus the total overhead/payload is

reduced and not directly proportional to the number

of receivers. As an example let us take the case with

1 sender and 3 receivers. According to the ZigBee

routing mechanism a separate process will be

initiated for each of the 3 receivers with (8+6) 14

bytes packet overload, which makes 14*3=42 bytes

route setup only. Additionally the same data will be

sent 3 times, once for each receiver. In M-Bee the

same example will need an 8 byte header Route

Discovery packet and each receiver node will

respond back with a Receiver Join 8 byte packet.

The total for route discovery and set up requires up

to 4*8=32 bytes. The normalized packet overhead is

defined as the total number of all data and control

packets transmitted by a node in the network

(sender), divided by the total number of all data

packets received across all multicast receivers.

Route Discovery Process: Route discovery

process begins with the sender sending out a

ROUTE-DISCOVERY packet via its M-Bee

endpoint and M-Bee output cluster with broadcast

address. Every node receiving this packet

rebroadcasts the packet once allowing the message

to propagate throughout the network. At each

receiver the packet is received via the corresponding

M-Bee endpoint and M-Bee input cluster. At the

application layer, we use the

APSDE_DATA_request primitive and its

parameters for transmitting data, and

APSDE_DATA_indication primitive and its

parameters for receiving data.

Upon receipt of a new ROUTE-DISCOVERY

packet, the node table entries are checked and

refreshed. Instead of carrying the information about

the sender node that originated the discovery, the

WINSYS 2007 - International Conference on Wireless Information Networks and Systems

148

previous hop and the hop count in the packet header

in M-Bee we get this information using the

MCPS_DATA_indication primitive parameters and

then record it in the necessary node table.

Receiver Join Process: When a receiver of a

group of receivers gets a ROUTE-DISCOVERY

packet, it sends a RECEIVER-JOIN packet back to

the original sender as a unicast message using path

reversal. Election of forward path is made using the

ZigBee broadcast algorithm. Path reversal unicast

address is obtained at every node from the previous

hop address field in the node table which was

recorded during the ROUTE-DISCOVERY process.

Each intermediate node receiving a RECEIVER-

JOIN packet configures itself as a forwarder for the

corresponding (sender, group) pair. Once a sender

receives even a single RECEIVER-JOIN, it can start

broadcasting data packets for the given receiver

group.

Data Delivery Process: Forwarding the data

along the forwarder tree, a different broadcast

mechanism is needed. To create it we use a decision

mechanism on top of the ZigBee broadcast

communication. In the existing ZigBee broadcast

communication realization a node sends the data to

the upper layer only after retransmitting it. This is

necessary because of the passive acknowledgement

mechanism. So, on top of this existing broadcast

mechanism we add a subroutine in the ZigBee

network layer for multicast communication. When

forwarding packets to interested receivers M-Bee

multicast algorithm has to check if a node is

configured as a “forwarder node” before

retransmitting the packet. Non forwarding nodes,

receiving a broadcast packet will drop it and won’t

retransmit it. Only forwarding nodes will keep

retransmitting the packet. So the packet will travel

only via the route reinforced by forwarder nodes

until it reaches the receivers.

When a source node and a forwarder are no

longer effective at delivering packets to downstream

receivers, they should stop re-broadcasting messages

to avoid wasting bandwidth. For this we have

suggested quite a simple routine utilizing the

nwkPassiveAckTimeout and the nwkMaxBroadcast

Retries value.

6 EXPERIMENTAL SETUP AND

RESULTS

In order to test the multicast communication model

and algorithm suggested we designed several

experiments to observe its performance. Once the

network was set up, packets were injected for

periods of 5 seconds, at a constant data rate of 20

packet per second, followed by variable random

intervals of silence. A max of 75 bytes packet

payload is used. We evaluate the time for setting up

a multicast tree for networks with different number

of nodes and the packet delivery ratio (PDR).

Testing ROUTE-DISCOVERY process is done

by observing the time spent for route establishment.

This time is calculated from the moment a ROUTE-

DISCOVERY packet is sent until the reception of

first RECEIVER JOIN packet. As for the PDR it has

been calculated in accordance with (Cheng 2006) –

total number of packets received to the number of

expected packets by all receivers. We test networks

with different number of nodes and different

numbers of receivers.

According to our results the ROUTE-

DISCOVERY time for the suggested M-Bee

multicast routing is short enough to allow DATA

trassmission of low sample rate medical data.

The results given below show the route

establishing times averages for a network of 1,2,..n

hops (where n

max

= number of nodes in the network -

1) in a 5 and 8 node network respectively. (Figure. 1

and Figure.2)

5 Node

50 0

10 0 0

15 0 0

012345

Hop C ount

1h o p

2hop

3hop

4hop

Figure 1: Average Route establishment times in a 5 node

network.

Further on we especially focused on investigating

the PDR as defined in the previous section. The

results prove that the proposed M-Bee multicast

algorithm has high reliability.

8 Node

50 00

10000

15 0 0 0

0 1234567

Hop Count

1hop(Avg7)

2hop(10)

3hop(Avg8)

4hop(Avg5)

5ho p(A vg 0)

6hop(Avg1)

Figure 2: Average route establishment times in an 8 node

network.

A NEW MULTICAST ROUTING ALGORITHM FOR ZIGBEE NETWORKS

149

Figure 3 shows packet delivery ratios taken after

each packet injection for the cases of 1 sender and 1,

2, 3 receivers accordingly. We can observe values as

high as 0.975. Increasing the number of nodes, we

still observed high reliability (average above 0.9)

with only few occasions of more than 10% of the

packets lost.

5 Node (20 packet/second, 1-4 hops)

0,8

0,85

0,9

0,95

1,05

1 2 3 4 5 6 7 8 9 101112131415161718192021222324252627282930

Test Count

R e c e iv e d /T r a ns m itte d

1 Receiver

2 Receivers

3 Receivers

Figure 3: Effect of increasing number of receivers on

packet delivery ratio.

We compare our results with those in (Cheng

2004) because those are the only published results

for multicast routing in WSN known to the authors

so far. The report similar values for the case with 20

packet per second and 1 sender 1 receiver and 1

sender 3 receivers. The horizontal axis in our

graphics is an example run of tests where after each

injection of packets in the network we wait for a

random period of time before the next one.

We believe that the results from our

experimental work support the thesis that ZigBee

can be used for multicast routing as for example M-

Bee. They also provided us with a better

understanding of the implications created by real

wireless communications as well as helped us define

and communicate to MicroChip several problems

with their software stack.

7 CONCLUSIONS

In this paper we have presented the design and

implementation of a multicast communication

protocol called M-Bee. We have extended the

unicast and broadcast routing mechanisms provided

by ZigBee with multicast features.

Our major goal is to demonstrate with a practical

implementation that ZigBee can be augmented with

modifications for multicast routing. Our results

demonstrate that such an approach is possible but

there is still significant work to be done if M-Bee

multicast is to scale for larger networks. Present

problems are in a great extend due to some

inconsistencies with the addressing scheme in

Microchip stack.

In conclusion, this paper has presented an initial

exploration into the challenges of software design

for some specific application scenarios for WSNs..

ACKNOWLEDGEMENTS

This work has been partially supported by CRUSIE

NoE 4-027738 which is funded by the European

Commission.

REFERENCES

Lorincz K., Malan D., Fulford-Jones T.R.F., Nawoj A.,

Clavel A., Schnayder V., Mainland G., Moulton S. and

Welsh M., 2004, Sensor Networks for Emergency

Response: Challenges and Opportunities, In IEEE

Pervasive Computing.

Ergen S.C., 2004, ZigBee / IEEE Summary Report,

csinem@eecs.berkley.edu.

Royer E.M., Perkins C.E., 1999, Multicast Operation of

the Ad Hoc On-Demand Distance Vector Routing

Protocol, In Proc. Of the 5th Annual ACM/IEEE

International Conference on Mobile Computing and

Networking (MobiCom’99) Seattle, USA.

Jetcheva J., Johnson D., 2001, Adaptive demand Driven

Multicast Routing in Multi-hop Witeless Ad Hoc

Networks, 2001, In Proceedings of the 2001 ACM

International Symposium on Mobile Ad hoc

Networking and Computing (MobiHoc 2001), pp. 33-

44.

Perkins C.E., and Royer E.M., 1999 Ad hoc On-Demand

Distance Vector Routing, In Proc. Of the 2nd IEEE

workshop on mobile computing systems and

applications, pp.90-100.

Chakeres, L.D., Klein-Berndt L., 2002, AODVjr, AODV

simplified, In ACM SIGMOBILE Mobile Computing

and Comm.Reviw, Vol.6, Number 3.

Cheng B., Kumar K., Reddy M., Welsh M., 2006, Ad-Hoc

Multicast routing on Ressource Limited Sensor Nodes,

In Proc. Of the International Symp. On Mobile and

Ad-Hoc Networking and Computing, pp.87-94.

ZigBee Specification, 2005, ZigBee Document

053474r06, Version 1.0, sponsored by ZigBee

Alliance.

WINSYS 2007 - International Conference on Wireless Information Networks and Systems

150