ZigBee Higher Levels Overview

The purpose of the ZigBee Alliance is to univocally describe the ZigBee protocol stan-dard in such a way that interoperability is guaranteed also among devices produced by different companies, provided that each device implements the ZigBee protocol stack.

The ZigBee stack architecture is composed of a set of blocks called layers. Each layer performs a specific set of services for the layer above.

The ZigBee stack architecture is depicted in Fig. 1.9. Given the IEEE 802.15.4 specifications on PHY and MAC layer, the ZigBee Alliance provides the network layer and the framework for the application layer.

The responsibilities of the ZigBee network layer include: mechanisms to join and leave a network, network security, routing, path discovery, one-hop neighbours dis-covery, neighbour information storage.

The ZigBee application layer consists of the application support sublayer, the application framework, the ZigBee device objects and the manufacturer-defined ap-plication objects. The responsibilities of the apap-plication support sublayer include:

maintaining tables for binding (defined as the ability to match two devices together based on their services and their needs), and forwarding messages between bound devices. The responsibilities of the ZigBee device objects include: defining the role of the device within the network (e.g., WPAN coordinator or end device), initiating

Figure 1.9: A detailed overview of ZigBee stack architecture.

and/or responding to binding requests, establishing secure relationships between net-work devices, discovering devices in the netnet-work, and determining which application services they provide.

ZigBee supports three types of devices: ZigBee routers (ZR), able to perform all tasks described in the IEEE 802.15.4, including forwarding of data; ZigBee Coordina-tor (ZC), a particular ZR, in charge also of forming the network ZigBee End Devices (ZED) that do not have routing capabilities. Both ZR and ZC correspond to FFD in the IEEE 802.15.4, while ZED corresponds to RFD. In the Zigbee mesh topology generally more than one path, connecting a couple of devices, could be present and, in case of link failures or changing in the environment, paths could be updated on de-mand. The ZC is responsible for starting the network and collaborates with the ZRs for discovering and maintaining the routes. A ZED cannot perform route discovery and data forwarding.

In order to let nodes compute the link costs to be used during the route discovery process, each node in the network periodically sends Link Status packets in broadcast at one hop. Each node receiving the Link Status packet computes the link cost, being a function of the link quality indicator of the received packet.

1.5.2.1 Zigbee Routing: AODV and Many-to-one

In this section, an overview on Zigbee routing protocols that were evaluated through experimentation (in Chapter 3) is given.

AODV The default routing algorithm of ZigBee is based on Ad hoc on demand distance vector (AODV), which is a pure on-demand route acquisition algorithm.

According to Zigbee, a link, li, connecting a pair of nodes, is characterized by a given

link cost, given by [25]:

Cli = min{7, f loor(P_l⁻⁴_i )}, (1.5.1) where f loor(.) is a function mapping the real number to the largest previous integer, and Pli is the probability of packet delivery on the link li. According to ZigBee specifications Pli may be computed through the link quality indicator (LQI) measure, however no specific methods are defined in the standard for the computation of this metric and its implementation is left to the designer. As an example, in the case of the Freescale MC1322x platform, the cost function is a function of the LQI, where the latter is proportional to the received signal strength indicator (RSSI). Therefore, in Zigbee, link costs depend on the success probability computed at link level.

The protocol selects the path, P , connecting a pair of nodes, characterized by the smallest total cost, C(P ), given by:

C(P ) =

L

X

i=1

Cli, (1.5.2)

being L the number of hops in the path. In case there exists more than one path connecting the same pair of nodes with the same total cost, the path characterized by the lowest value of L, will be selected.

The control packets exchanged in Zigbee networks to find the optimum path are described in the following. The source node broadcasts a route request (RREQ) packet to its neighbors and then intermediate nodes receiving the RREQ rebroadcast it to their neighbors until the RREQ reaches the destination node. During the pro-cess of rebroadcasting the RREQ, intermediate nodes record in their route discovery tables the address of the sender from which the first copy of the broadcast packet was received, and the corresponding link cost, computed according to eq. (1.5.1), where

Pli depends on the LQI with which the RREQ was received. The comparison among path costs of packets with the same RREQ allows choosing the best path and dis-carding anything worse. Once the destination node receives the RREQ, it responds by unicasting a route reply (RREP) packet back through the selected path. As the RREP is routed back along the reverse path, nodes along this path set up forward route entries in their routing tables which point to the node from which the RREP came. These forward route entries indicate that the link between the node and the destination is established. Finally, when the RREP reaches the originator, it can send data packet [26].

Many-to-one MTO routing allows to establish a tree topology, rooted at the co-ordinator. In order to form and maintain the tree, the coordinator periodically sends a MTO Route Request (MTORR) packet in broadcast. Each node receiving a MTO-RR, before retransmitting it, reads the accumulated path cost (i.e., the sum of the costs of the links of the reverse path toward the coordinator) included in the packet, and selects the next hop toward the coordinator. If a node receives several MTO-RRs from different nodes, it elects as a next hop the node characterised by the minimum total path cost to the coordinator. At the end of this MTO-RR transmission, all nodes in the network are aware of the next hop to be used in order to transmit their data to the coordinator. However, if the coordinator wants to know the path to reach a specific node in the network (or a set of nodes, through multi-casting), MTO rout-ing should be combined with Source Routrout-ing (SR). After the MTO-RR transmission, once a node has a data packet to be sent to the coordinator, it first sends a Route Record (RREC) packet through the selected path. Each node in the path receiving the RREC packet adds in the relay list field its own address and forwards the new

RREC packet toward the coordinator. The coordinator analyses the RREC packet and stores that information in the Source Route Table. Each time the coordinator has to send a packet to a node, it reads the relay list from this table and sends the packet through the selected path. Even though MTO-RRs are periodically sent by the coordinator and are not generated on-demand (which would make the protocol pro-active), ZigBee saves the re-active feature through the use of Ad hoc AODV protocol [27], when needed. In particular, in case of link failure, AODV is used for discovering a new path toward the destination.