## 5 IEEE 802.15.4 Technology
### Zigbee and the Tree-Based Topology  
ZigBee defines the network and application layers above the 802.15.4 [32]. Zigbee is being promoted by the Zigbee Alliance and its main contribution is giving mesh network capabilities to 802.15.4 applications. Mesh networking allows reconfiguration around blocked paths by hopping from node to node until the data reaches the destination. Moreover, Zigbee specifications define a beacon-enabled tree-based topology, as a particular case of the IEEE 802.15.4 peer-to-peer networks.  
This topology, depicted in Figure 8 as an example, can be interpreted as a hierarchical tree where nodes at a given level transmit data to nodes at a lower level, to reach the PAN coordinator, which is the root of the tree. Only one device in tree assumes the role of PAN coordinator, that is generally the sink of the scenario. In case of multi-sink scenario more PAN coordinators are present and a forest of disjoint trees, rooted at the PAN coordinators is established.  
Two different types of nodes are present in the tree: the routers, that must be FFDs, which receive data from their children, aggregate them, and transmit the packet obtained to their parents; and the leafs, thatcould be FFDs or RFDs, which have no routing functionalities and have only to transmit their packets to the parent.  
The topology formation procedure is started by the PAN coordinator, which broadcasts beacon packets to neighbour nodes. A candidate node receiving the beacon may request to join the network at the PAN coordinator. If the PAN coordinator allows the node to join, it will begin transmitting periodic beacons so that other candidate nodes may join the network.  
As stated above, nodes must be in beacon-enabled mode: each child node tracks the beacon of its parent (see Figure 9, where the tracking period is outlined as a dashed rectangle). A core concept of this tree topology is that the child node may transmit its own beacon at a predefined offset with respect to the beginning of its parent beacon: the offset must always be larger than the parent superframe duration and smaller than beacon interval (see Figure 9). This implies that the beacon and the active part of child superframe reside in the inactive period of the parent superframe; therefore, there is no overlap at all between the active portions of the superframes of child and parent. This concept can be expanded to cover more than two nodes: the selected offset must not result in beacon collisions with neighbouring nodes. This implies that the node must record the time stamp of all neighbouring nodes and selects a free time slot for its own beacon. Obviously a child will transmit a beacon packet only when it is a router in the tree; if the child is a leaf it has only to transmit the packet to its parent. Each child will transmit its packet to the parent in the active part (CAP or CFP) of the parent superframe. Therefore, each router in the tree, after the reception of the beacon coming from the parent, will select the instant in which transmits its beacon. Beacon scheduling is necessary to prevent the beacon frames of one device from colliding with either the beacon frames or data transmissions of its neighboring devices.  
An example of superframe structure in 3-level tree, having two routers at level one, is shown in Figure 10. Routers at level 1 transmit the beacon and define superframes that are not overlapped and all contained in the inactive part of the PAN coordinator superframe.  
Figure 9: The tracking of the beacon’s parent, performed by a generic child.