Cluster Label-based ZigBee Routing Protocol with High Scalability Kwang Koog Lee, Seong Hoon Kim and Hong Seong Park Dept. of Electronic Communication Engineering, Kangwon National University, 192-1 Hyoja 2 Dong, ChunCheon, 200-701, South Korea {21thbomb, bs99018}@control.kangwon.ac.kr,
[email protected]
Abstract Since the ZigBee mesh routing algorithm is similar to AODV based on flooding, the networks suffer from the scalability problem as the number of nodes or the data traffic increases. Thus, for low-rate ZigBee mesh networks it is necessary to design an effective routing protocol to take the scalability into account. In this paper, we propose a ZigBee mesh routing protocol based on Cluster Label (ZiCL). As ZiCL hierarchically divides a ZigBee-enabled network into one or more logical clusters, when a node starts route discovery procedure, it encourages nodes with the same Cluster Label to share the routing information. This results in fewer route discoveries, and hence effectively relieves the number of potential control traffic required to establish a shortest path between nodes. Simulation results show that ZiCL helps to reduce routing overhead and improve performance of ZigBee mesh networks.
1. Introduction As recent wireless technologies have advanced, a new wireless technology which is called WMN has emerged to provide better services [1, 2]. The WMNs generally can be composed of hundreds or thousands of nodes to support a variety of applications the network. However, the WMNs suffer from scalability problem, which network performance decreases sharply as more nodes join a network or traffic intensity increases. Consequently, it is necessary to consider a scalability issue for supporting network performance for various applications. To improve scalability in WMNs, we consider the ZigBee [3] mesh networks similar to Mobile Ad hoc NETwork (MANET). As ZigBee built on IEEE 802.15.4 [4] is designed for wireless networks for such
applications as low-rate wireless monitoring and controlling, it is characterized as building WMN. For supporting mesh networks, ZigBee uses the routing algorithm similar to Ad hoc On-demand Distance Vector (AODV) [11] used in MANET, which is called Z-AODV in this paper. Even though AODV is a well-known routing protocol for mobile wireless environment, it does not still support enough scalability as researchers mentioned [7-10]. This is why AODV-based routing protocol performs based on flooding for discovering any route. Flooding is very costly and results in serious redundancy, contention and collision. K. Jain et al. [8] show that wireless interference between neighboring nodes caused from flooding sensitively affects the maximum throughput of a multi-hop network. S. J. Lee et al. [9] evaluate the scaling potential of on-demand ad hoc routing protocols such as AODV routing by comparing various modified protocols and show AODV is weak of scalability. Finally, V. Naumov et al. [10] offer a comparative study of both AODV routing and Dynamic Source Routing (DSR) [12] with an investigation of the main factors that affect scalability and mention that a strategy such as cache is needed to complement scalability problem of AODV. In low-rate environment on which ZigBee focuses, network performance can be highly sensitive to routing packets. For example, network performance such as routing overhead in the network of low data rate can be dramatically increased by numerous routing packets emerged from immediate route discovery. If considering a ZigBee mesh network connected with numerous devices which ZigBee can support, the scalability issue is more crucial. As researchers above mention, the existing routing protocol in ZigBee faces the challenging task to route data packets without high routing overhead due of influence of route discovery based on plain flooding. Furthermore, considering limited memory capacity of ZigBee devices, the
protocol can go through an additional problem related memory capacity. Because AODV-based routing protocol does not consider memory capacity as the number of nodes increases in a network. Even though V. Naumov et al. [10] said that ARP approaches are used to simplify communication between hosts, it is not practical due to limited resource of tiny ZigBee device. Consequently, it is necessary that an effective routing protocol which considers scalability and limited resource for ZigBee mesh networks is designed. In general, cluster approaches such as Zone Routing Protocol (ZRP) [13] or Cluster Based Routing Protocol (CBRP) [14] in MANET can be useful to reduce routing overhead. If ZRP or CBRP considers ZigBee network layer, it is not difficult to adjust in ZigBee. However, ZRP requires management to maintain routes between nodes place in a zone. Moreover, it is not easy for ZRP to determine a zone radius. Meanwhile, CBRP has overhead to form clusters because of routing packets to elect an appropriate clusterhead. Therefore, it is not suitable for these protocols to adjust in ZigBee due to expected routing overhead to generate and to maintain clusters. In this paper, we propose a mesh routing protocol that helps to enhance scalability for ZigBee mesh networks, which is called ZiCL (ZigBee Cluster Label). ZiCL was inspired by cluster approach studied for mobile ad hoc routing of V. Li et al. [5]. ZiCL uses hierarchical address structure of ZigBee to statically divide a network into one or more logical clusters. And, then ZiCL assigns a unique Cluster Label to each cluster where the Cluster Label represents addresses of all nodes in a logical cluster. Unlike the existing mesh routing, ZiCL performs route discovery based on Cluster Label and maintains Cluster Label information in routing table. After a node performs route discovery, it obtains not only a route for a desiring destination but also a route for corresponding cluster of the destination. Moreover, the fresh Cluster Label information is shared with cluster members grouped into the same cluster by Cluster Label Broadcasting, where Cluster Label Broadcasting means that a clusterhead node enables broadcast packets to be limited within its Cluster Label. In ZiCL, a Cluster Label presents a group of addresses. Thus, if a node has corresponding Cluster Label information for a destination in routing table, the node can immediately send data to the destination without any route discovery. In ZiCL, since clusters are created statically by formation rules of cluster, it is possible for a node to calculate a Cluster Label of a node through an algorithm provided. This results in fewer route discovery procedures, and hence reduces the number of potential control messages required to establish the routes. Subsequently, ZiCL
reduces routing overhead and contributes on improving scalability on large-scale ZigBee networks. In addition, as ZiCL needs only Cluster Label information instead of network addresses in routing table, it reduces memory usage significantly. Simulation results show that ZiCL helps to effectively reduce routing overhead and memory usage in ZigBee mesh networks. This paper is organized as follows. In the following Section, we review the existing ZigBee mesh routing algorithm. We then present our proposed ZiCL in Section 3. In Section 4, we discuss various simulation results of ZiCL. Conclusions are drawn in the last section.
2. Background of ZigBee The ZigBee specification identifies three kinds of devices that incorporate ZigBee radios, with all three found in a typical ZigBee network: A coordinator, which organizes the network and maintains routing table. Routers, which can also have the routing capacity for maintaining routes and talk to all kinds of devices. End devices, which can talk to routers and the coordinator, but not to each other. The ZigBee mesh routing adopts the well-studied public domain algorithm AODV [11]. As AODV is a pure on-demand protocol, route discovery is based on a route request and route reply query cycle. Route discovery begins when a source node desires to send data to some destination. As shown in Figure 1, the source node first broadcasts a route request (RREQ) packet to its neighbors. When a node receives the RREQ, it then checks whether it has an unexpired route to the destination node. If not, it creates a route entry and a route discovery entry. The information stored in the route entry includes destination address, status, and next-hop address. Next, the route discovery entry contains Route Request ID, Source Address, Sender Address, Forward Cost, Residual Cost, and Expiration Time. The Route Request ID is incremented for every RREQ the node initiates, and together with the source address, uniquely identifies a RREQ. Along with its
Figure 1. Basic routing discovery
own sequence number and the Route Request ID, the source node includes in the RREQ the most recent sequence number it has for the destination. In order to respond to the RREQ, the node must be the destination itself. If neither of this condition is met, the node rebroadcasts the RREQ. Once the destination node receives the RREQ, it responds by unicasting a route reply (RREP) packet back to its neighbor from which it received the RREQ. 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 as the active status. Finally, when the RREP reaches to the originator, it starts to send the data packets buffered during the route discovery procedure.
3. ZigBee Cluster Label (ZiCL) Routing Protocol To simplify our study, we make the following assumptions in this paper. A Coordinator and Routers are constantly turned on for relaying data packets. End devices do not have routing capacity. Hence, they cannot relay data packets. A link between neighbor nodes is symmetry. Network topology is static without any movement.
3.1 Formation of clusters ZiCL uses hierarchical addresses assigned from ZigBee network stack. To make cluster, ZiCL divides a ZigBee mesh network into one or more hierarchical clusters. A cluster consists of a clusterhead, which forms the cluster and cluster members, which are grouped into the cluster. To hierarchically make such a cluster, following rules have to be satisfied. ▪ First, a Coordinator or Routers have the qualification for generating a logical cluster. Hence, End Devices cannot make any cluster. ▪ Second, a Coordinator generates the first cluster and acts as a clusterhead. ▪ Third, Routers which are two hops away from any clusterhead statically forms a logical cluster and acts as a clusterhead. That is to simplify formation of clusters and to maintain hierarchical topology even within the clusters. ▪ Fourth, End devices are only grouped into their parent’s Cluster Label.
Figure 2. Illustration of ZiCL
To identify each cluster, each cluster has a unique Cluster Label. Each Cluster Label is assigned by each clusterhead where the Cluster Label directly uses the network address of each clusterhead. Based on these rules, every node is associated with a Cluster Label and clusterheads are connected with each other via gateway nodes, which are used to communicate with an adjacent cluster. According to one hop neighbor information, nodes which are connected with other clusters can identify own role as a gateway. Figure 2 above shows a Cluster Labeled network.
3.2 Calculation of Cluster Label In order to effectively exploit hierarchical cluster on routing, ZiCL provides an algorithm that a node can compute the Cluster Label of a node. To calculate a Cluster Label, ZiCL uses the hierarchical address allocation scheme ZigBee defines and three main network parameters such as Cm, Rm, and Lm, where Cm means the maximum number of children, Rm means the maximum number of router a node can have, and Lm means the maximum number of depth. Since each Cluster Label depends on the value of node’s depth, a Cluster Label can be calculated through parsing a target address allocated from a Coordinator or each Router. As ZigBee uses CSkip for address block allocated to Routers, variables, LowerBound and UpperBound for a CSkip area, are used to find a destination node. The algorithm performs loop in compliance with Rm and Lm. Finally, if the destination node is found in an area on looping, the algorithm calculates corresponding Cluster Label. Since Cluster Labels are statically allocated according to node’s depth, Cluster Label is determined from corresponding depth of the destination node. Figure 3 below shows the detailed algorithm for computation of a Cluster Label for a destination node.
Figure 4. Basic routing procedure of ZiCL
Figure 3. Algorithm of Cluster Label Calculation
3.3 Routing Procedure ZiCL routing consists of intra routing and inter routing as shown Figure 4. In case of former, a node uses hierarchical routing scheme in ZigBee [3]. ZiCL maintains hierarchical topology even within a cluster owing to static formation of clusters. Thus, a node can immediately send a data packet to a destination without any route discovery. Since a node can calculate a Cluster Label of a destination by an algorithm introduced in the previous Section, it is possible for the node to know performing either intra routing or inter routing. In case of latter, a node transmits data packets depending on routing information in its routing table. ZiCL maintains only Cluster Label information instead of network address of nodes in routing table. When a destination node is located in different Cluster Label, if it does not have corresponding Cluster Label information in routing table, it initiates a route discovery. ZiCL performs on-demand route discovery procedure similar to Z-AODV. According to procedure based on Cluster Label, a source node maintains only
Cluster Label information for a destination node’s cluster in routing table after discovery. Moreover, the fresh information is shared with cluster members grouped into the same Cluster Label by Cluster Label Broadcasting (CLB), where CLB is said that a clusterhead node enables broadcast packets to be limited within its Cluster Label. Since ZiCL creates clusters statically by formation rules of cluster mentioned above, it is possible for a node to calculate a Cluster Label of a destination node through the algorithm introduced in the previous Section. In ZiCL, a Cluster Label presents a group of addresses. Thus, a source node can know several destination addresses through only a route discovery. If a node has corresponding Cluster Label information for a destination in routing table, the node can immediately send data to the destination without any route discovery. This results in fewer route discovery procedures, and hence reduces the number of potential control messages required to establish the routes. Subsequently, ZiCL reduces routing overhead over the existing protocol. In addition, as ZiCL needs only Cluster Label information instead of network addresses in routing table, it reduces memory usage significantly.
3.4 Route Discovery When a node needs to communicate with some destination for which it has no routing information in its table, the route discovery procedure is initiated. In the same manner as AODV, RREQ packets are broadcasted until the packets arrive at the desiring destination. However, it is different from the existing algorithm that the ZigBee specification defines because route discovery is performed based on Cluster Label. At first, the source node creates a RREQ packet which contains the desiring destination address. Then, the source node broadcasts the RREQ. If neighbor nodes initially receive the RREQ, it obtains a Cluster
Figure 5. Receipt of route request
Label of a designated destination in RREQ by calculating it based on the algorithm of previous Section and adds a routing entry with inactivated state to the Cluster Label of its routing table (RT) and also creates a route discovery entry for the destination address equivalent with the ZigBee specification in its route discovery table (RDT). Then, the corresponding information such as the source address, sequence number, and routing cost are appended in its RDT. The pair, which is a source address and a sequence number, uniquely identifies a RREQ. When an intermediate node receives a RREQ packet, if the packet’s pair equals to one contained in its RDT, it compares the path cost contained in the RREQ with one in its RDT. If the received packet has maintained the better routing cost than in RDT of the intermediate node, the node updates corresponding cost field in its RDT and then rebroadcasts the RREQ. Note that the procedure for obtaining Cluster Labels is proceeded in all intermediate nodes which receive a new RREQ. Figure 5 above shows the detailed procedure on receiving a RREQ packet. If the desiring destination node receives the RREQ, the node creates a RREP packet and sends it back along the reverse route. ZiCL does not allow any neighboring node to send a RREP packet except that the destination is an End device of a node received the RREP packet. When an intermediate node receives a RREP packet, it first checks whether there exists a RDT entry for the RREQ originator. If so, the node activates the corresponding entry contained in its RT. Finally, if the RREQ originator receives the RREP, it also checks the existence of its RT and RDT entries. If the path cost in the RREP is higher than existing one, the originator updates its RDT and activates its RT entry. After route discovery process, the originator node sends a route notify (RNOT) packet created from the Cluster Label Notification function for notifying the newly added routing information to its clusterhead. And then the clusterhead receiving the RNOT sends a
Figure 6. Receipt of route response
route update (RUPT) packet created from the Cluster Label Update function to its cluster members for sharing the new routing information. Figure 6 above shows the detailed procedure on receiving a RREP packet. In Figure 7, node Q wants to send a data packet to node J. To perform route discovery, node Q sends out an RREQ, with the destination address field set to the node J’s address 0x002C. As we have described route discovery process in earlier section, the RREQ is broadcasted in the network until the RREQ reaches to node J. Intermediate nodes receiving the RREQ add an entry for the Cluster Label 0x02A1 in its RT and then add an entry for the destination address 0x002C in its RDT. If the destination node J receives the RREQ, it forwards a RREP packet along with the reverse path. An intermediate node H does not activate its entry for the Cluster Label 0x002C and discard it. That is because its Cluster Label equals to the destination node’s one. Although node H do not maintain the routing entry, it can send data packets through the intra-routing. Then, if intermediate nodes B and A receive the RREP, they activate their routing entries, which have been created by the RREQ packet. In case of node F, since node F has adjacent node Q information, it directly sends the RREP to node Q after receiving the one. Finally, node Q establishes a route for the remote Cluster Label
Figure 7. An example of route discovery
0x0002. In addition, node Q sends a RNOT packet to notify the Cluster Label 0x0002 information to its clusterhead node G. Subsequently, node G receives the RNOT and then broadcasts a RUPT packet to share the routing information by Cluster Label Broadcasting. Hence, node S and T also maintain a routing entry for the Cluster Label 0x0002.
4. Performance Evaluation We used NS-2 Ver.2.28 [6] as a simulator for performance evaluation of the proposed ZiCL. NS-2 provides IEEE802.15.4 networks source codes but not Z-AODV. For that reason, we implemented both ZAODV routing protocol considering node types (i.e., Router and End Device) and our ZiCL in NS-2. Parameters used in simulations are as following. We used constant bit rate (CBR) as traffic sources. The packet size is 80 bytes and the average packet rate is 0.70 packets/sec. We defined a terrain of 150m by 150m and placed the nodes randomly except for a coordinator located at the center of the terrain. For simulations, the communication patterns were peer-topeer. In our simulation scenarios, we assumed that all nodes do not support mobility. We increased the number of nodes (e.g., n = 20, 40, 60, 80, 100, 120, and 140) to evaluate scalability of routing protocol. For each step, we simulated both ZigBee AODV and the proposed ZiCL for 150 simulation seconds while increasing the number of sources from 20 to 60. Note that the proportion of end devices to routers is 3:1 to simulate both routing protocols evenly. For a comparison of both routing protocols, we measured end-to-end delay, routing overhead ratio, packet delivery ratio, and memory capacity used in routing table.
4.1 Routing Overhead Routing overhead ratio is defined as the ratio of
Figure 9. Packet delivery ratio for node numbers
routing packets to data packets. As shown in Figure 8 below, the routing overhead ratios of both Z-AODV and ZiCL were increased according to increasing number of nodes. Especially, in case that the number of node was 140, both routing overhead ratios became higher as the number of traffic sources decreased. Because routing packets in low rate environment obviously affected data traffic as data traffic sources increased. Through the simulation result, we could know that ZiCL had lower overhead than Z-AODV. Especially, in case of 140 nodes, the average overhead ratio of Z-AODV was about twice over ZiCL. This resulted from the characteristics of ZiCL. In other words, every node in ZiCL can discover more than one destination through only one route discovery and End devices in a cluster can discover destinations in the same cluster using tree routing instead of route discovery. The average routing overhead is decreased down to about 20 percent.
4.2 Packet Delivery Ratio Packet delivery ratio is defined as the ratio of the data packets delivered to the destination to those generated by the sources. In Figure 9, packet delivery ratios of both were decreased as the number of nodes increased. This is due to an increase in probability of packet collisions as the network traffic (i.e., route discovery broadcast packets) increased. In particular, in case of 60 sources, the packet delivery ratios were significantly reduced. Note that ZiCL had better packet delivery ratios than Z-AODV in all cases.
4.3Packet Delivery Ratio
Figure 8. Routing overhead of node numbers
The end-to-end delay is an average delay between the time a packet is transmitted from a source node and the time the packet is arrived at a destination. This
Figure 10. Average end-to-end delay of data packet
procedure includes all possible delays caused by propagation, buffering during route discovery process, and retransmission by the failure of link. As shown in Figure 10, end-to-end delays of both were increased according to increasing number of nodes. This results from increasing number of intermediate nodes from sources to destinations. In view of sources, ZiCL was comparable to but slightly better performance than ZAODV. This is because ZiCL reduces the number of route discovery over Z-AODV. The average end-toend delay of ZiCL was reduced down to about 2ms over Z-AODV.
4.4 Memory Usage The memory usage is measured for comparing used memory between Z-AODV and ZiCL. In ZiCL, the information stored in a routing entry includes Cluster Label (2 bytes), Next Hop Address (2 bytes), and Status (3 bits). The simulation was only measured in case of 40 sources. As shown in Figure 11, Z-AODV needed more memory capacity than ZiCL. The average memory usage of Z-AODV was reduced down about three times over ZiCL. This is why ZiCL maintains only Cluster Label information in routing table.
5. Conclusion Scalability in large-scale mesh networks is inherently difficult due to the excessive routing overhead. In this paper, we approached to ZigBee mesh networks. Like earlier study, the existing routing protocol sharply suffered from network performance degradation as the size of ZigBee network is extended. As shown earlier Section, simulation results demonstrated that ZigBee mesh networks have limited scalability. To solve the scalability problem limited in
Figure. 11. Average memory usage
large ZigBee mesh networks, we proposed ZiCL. ZiCL performs Cluster Label-based route discovery by hierarchically dividing a ZigBee network into logical clusters and when it comes to routing, ZiCL can know destinations by not transmitting some control packets but rather calculating its Cluster Label. As shown simulation results, ZiCL helps to improve network performances and contributes on relieving the number of control traffic in large ZigBee mesh networks.
6. References [1] I. F. Akyildiz and X. Wang, “A Survey on Wireless Mesh Networks”, IEEE Communications Magazine, 43(9):23-30, Sep. 2005. [2] M. J. Lee, J. Zheng, Y. B. Ko, and D. M. Shrestha, “Emerging Standards for Wireless Mesh Technology”, IEEE Communications Magazine, April. 2006. [3] Zigbee Alliance, "ZigBee specification: ZigBee Document 053474r06 Version 1.0", 14 Dec. 2004. [4] IEEE Computer Society, "Part 5.4: Wireless Medium Access Control and Physical Layer Specifications for LowRate Wireless Personal Area Networks (LR-WPANs)", 1 Oct. 2003. [5] V. Li, H. S. Park, and H. Oh, “A Cluster-Label-Based Mechanism for Backbone on Mobile Ad Hoc Networks”, The 4th Wired/Wireless Internet Communications (WWIC 2006), pp.26-36, May. 2006 [6] The Network Simulator-2, http://www.isi.edu/nsnam/ns/ [7] C. A. Santuvabez, B. McDonald, I. Starvrakakis and R. Ramanathan, “On the Scalability of Ad Hoc Routing Protocol”, The 21st Annual Joint Conference of the IEEE Computer and Communications Societies ( INFOCOM 2002), Jun. 2002. [8] K. Jain, J. Padhye, V. Padmanabhan, and L. Qiu, “Impact of Interference on Multi-Hop Wireless Network Performance”, ACM Annual International Conference on Mobile Computing and Networking (MOBICOM) pp. 66-80. Sep. 2003. [9] S. J. Lee, E. M. Belding-Royer, and C. E. Perkins, “Scalability study of the ad hoc on-demand distance vector routing Protocol”, In International Journal on Network Management (IJNM), to appear, 2003.
[10] V. Naumov and T. Gross, “Scalability of Routing Methods in Ad Hoc Networks”, ELSEVIER Performance Evaluation 62, pp.193-209. Aug. 2005. [11] C. E Perkins and E. M. Belding-Royer and S. R. Das, "Ad hoc On-demand Distance-Vector (AODV) Routing Protocol", Internet-Draft, IETF, March, 2002, Work in progress. [12] I. D. Chakeres, E. M. Belding-Royer, and C. E. Perkins, "Dynamic MANET On-demand Routing Protocol", InternetDraft, IETF, October, 2005. Work in Progress. [13] Z. Haas and M. Pearlman, “The Performance of Query Control Schemes for the Zone Routing Protocol”, in ACM SIGCOMM, 1998. [14] M. Jiang, J. Li, and Y. C. Tay, “Cluster Based Routing Protocol (CBRP)”, Internet-Draft, IETF, Jul. 1999, Work in progress.
