An Effective Broadcast Strategy for Route ... - Semantic Scholar

5 downloads 291 Views 541KB Size Report
as contention and results in improving network performances such as routing overhead and packet delivery ratio. Simulation shows that the proposed algorithm ...
An Effective Broadcast Strategy for Route Discovery in the ZigBee Network Kwang Koog Lee, Seong Hoon Kim and Hong Seong Park Dept. of Electronic and Telecommunication Engineering, Kangwon National University, 192-1 Hyoja 2 Dong, ChunCheon, 200-701, Korea {kwangkooglee, shkim1980}@gmail.com, [email protected]

Abstract ⎯ The route discovery in ZigBee is performed by simple flooding where every node forwards the packet once. The uncontrolled flooding usually is likely to serious contention and collision due to many redundant transmissions. It therefore can lead to decreasing network performances such as routing overhead and packet delivery ratio. To cope with this, this paper proposes an effective broadcast algorithm called ZBARD (ZigBee Broadcasting Algorithm on Route Discovery). As ZBARD sets the broadcast radius to a proper value which can guarantee establishing a shortest path between nodes, it minimizes control packets issued by the route discovery. Due to limitation of redundant transmissions, it reduces collision as well as contention and results in improving network performances such as routing overhead and packet delivery ratio. Simulation shows that the proposed algorithm reduces the number of unnecessary transmissions followed by route discoveries well. Keywords ⎯ ZigBee, IEEE 802.15.4, flooding, broadcast storm, AODV.

1. Introduction The recently ratified ZigBee standard [8] designed for low data rate, low cost, and low power wireless communication technology based on the IEEE 802.15.4 medium access control (MAC) and physical (PHY) layer [7] enables reliable, cost-effective, wirelessly networked monitoring and control applications. Route discovery in ZigBee is analogous to the Ad hoc On-demand Distance Vector (AODV) [9] protocol but slightly different in that the ZigBee routing protocol make the AODV protocol lighter and fuses it with hierarchical routing. In general ad hoc networks, such route discovery is mainly carried out in case there is no route table entry corresponding to the destination address learned through service discovery. In ZigBee networks, the route discovery even more happens due to diverse application characteristics. For example, in order for ZigBee devices to be commercially used in actual environments like building, office, home, and so on, such operations as discovering services required, defining end-to-end relationship and its update owing to mobility, and backup and restoration of all the configuration information are required. And since all the operations above result in learning new destination nodes, they are followed by a number of route discoveries from source nodes wishing to communicate with the destination nodes. And the router discoveries incur large

ISBN 978-89-5519-136-3

-1187-

bandwidth consumption because they are based on broadcasting using probabilistic scheme whereby the timing of rebroadcasting is differentiated via random delay. Furthermore, frequent route discoveries cause a broadcast storm problem [1]. In this respect, now that such route discoveries tend to occur frequently in the ZigBee network, they should be performed efficiently. Generally, typical approaches concentrate on routing algorithms themselves by reducing control packet overhead incurred via the procedure for discovering path to a certain destination. In a different way from the typical approach, this paper pays more attention to alleviating the broadcast overhead on route discovery. This paper proposes a light-weight broadcasting algorithm called ZigBee Broadcasting Algorithm on Route Discovery (ZBARD). When a ZigBee node discovers any route for a destination, it usually sets the upper bound of broadcasting radius to a pre-defined value (i.e. the default value is twice configured depth from the ZigBee specification). In contrast, ZBARD sets the radius to an appropriate value which can guarantee establishing a shortest path between a source and destination node in the ZigBee mesh networks. Since the ZigBee network maintains the hierarchical structure by its addressing scheme, a source node can calculate the depth value of any desiring destination through an algorithm ZBARD provides. As ZBARD computes a secure broadcasting radius instead of the default value, it limits the range of broadcasting and results in minimizing many unnecessary redundant transmissions. Simulation results show that ZBARD helps to effectively reduce routing overhead and improve packet delivery ratio. This paper is organized as follows. Section 2 overviews related works. In Section 3, background of ZigBee and a case study for route discovery in ZigBee networks are introduced as preliminaries. In Section 4, the proposed ZigBee Broadcast Algorithm on Route Discovery is described in detail. The proposed algorithm and notations are also presented. The performance results are evaluated in Section 5. Finally, this paper is concluded in Section 6.

2. Related Works A simple broadcast approach is to flood the whole network by rebroadcasting at every node. But this approach consumes too much communication bandwidth, causing a broadcast

Feb. 17-20, 2008 ICACT 2008

storm problem. Ni et al. [1] first introduced the broadcast storm problem when every node rebroadcasts a packet. In order to reduce the broadcast redundancy and avoid collisions during rebroadcasting, they introduced some simple algorithms such as probabilistic, counter-based, distance-based, location-based, and clustering-based scheme. More sophisticated algorithms with an assumption that network topology is known in order to guarantee network coverage and reduce broadcast redundancy is proposed [2]. Peng and Lu proposed a Scalable Broadcast Algorithm (SBA) which checks whether or not a receiving node’s 1-hop neighbors are all covered by previous transmissions from other nodes [3] and also an efficient Ad Hoc Broadcast Protocol (AHBP) [4] whereby greedily selects forward nodes from a node’s 1-hop neighbors to cover all its 2-hop neighbors. However, ZigBee devices have limited computation and storage capacity, so it cannot afford to conduct complicated algorithms requiring a large memory usage. In addition, since ZigBee devices should be of small size and low cost, it cannot obtain accurate position information using additional hardware like GPS. As a result, such algorithms above can not be employed in ZigBee. Regarding broadcast algorithms for ZigBee, Ding et al. [5] proposed self-pruning and forward node selection algorithms that exploit the hierarchical address space in ZigBee networks under consideration of limited computation complexity and storage space. However, this work is different from ours in that they focus on data broadcast whereas we pay more attention to alleviating broadcast overhead incurred by control message like route discovery.

3. Preliminaries 3.1 Background of ZigBee The ZigBee specification [8] identifies three kinds of devices that incorporate ZigBee radios, with all three found in a typical ZigBee network: • A ZigBee Coordinator, which organizes the network and has routing capacity. • 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 ZigBee Coordinator, but not to each other. Generally, ZigBee builds a tree topology based on its hierarchical addressing scheme. At any level d of the logical ZigBee tree, the network addresses are separated by Cskip(d) = (1+Cm–Rm–Cm*RmLm-d-1)/(1-Rm), where Cm, Rm, and Lm means the maximum number of children, the maximum number of routers, and the maximum number of depth, respectably. The ZigBee Coordinator sets its address to zero due to the root of the tree. When a new Router then joins a network, the ZigBee Coordinator assigns a finite sub-block of address space using the Cskip equation above. Other the other hand, End devices get only one address that is assigned throughout the following equation; An = Aparent +

ISBN 978-89-5519-136-3

-1188-

Cskip(d)*Rm + n, where n means nth child joining a network and is between 1 and Cm - Rm. Based on this hierarchical addressing, ZigBee supports hierarchical tree routing which can forward data to a desiring destination without any route discovery. The ZigBee mesh routing adopts the well-studied public domain algorithm AODV [9]. 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. 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 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.2 Case study of route discovery on ZigBee networks This subsection helps clarify why route discoveries even more happen comparing to general ad hoc networks. Currently, most of applications deployed using the ZigBee standard fall into three application areas: home automation and monitoring, building automation, and utility meter reading and control [6]. Consider a following example. In commercial buildings using ZigBee as the means for building system control, sensors and actuators have to be not only configured according to usage of each room but also integrated with a building management system. For instance, a number of lights installed over the rooms are bound with switches in certain areas by convenience of tenants. After then, when a room is occupied, sensors and actuators carry out their operations by themselves or by the tenants of the room via a remote controller. Some day, interruption of electric power happens and it returns to normal afterward. The tenants go over configuration of the system. Later on, the tenants go out and new tenants come in. And they change the initial configuration according to their own purposes. And also this cycle may occur when the buildings undergo the

Feb. 17-20, 2008 ICACT 2008

reconfiguration of internal partitioning. Through the example above, the following three phase can be inferred: (Re) configuration, normal phase, and recovery phase. These phases make ZigBee nodes generate plenty of service discoveries causing the corresponding route discoveries when the routing table entries of discovered nodes are not available on the ZigBee nodes. Configuration phase- requests for discovering system servers like primary/backup trust center, primary/backup binding table cache, and primary/backup discovery cache, - requests for discovering proxy cache devices for storing information of sleeping devices, - requests for finding cache devices to look up information of the sleeping devices and - requests for bindings between devices Normal phase- requests for service discovery to find required information and - End Device announcement to notify all networked ZigBee nodes of the changed short address of mobile End Devices. Recovery phase- requests for discovering system servers like backup trust center, backup binding table cache, and backup discovery cache. As can be seen, in the ZigBee networks, there involves a lot of discoveries to find target nodes. And the discoveries result in the needs for the path between two nodes wishing to communicate. In other words, to operate ZigBee in commercial environments, many route discoveries based on broadcast are unavoidable. Motivated by it, we propose an effective broadcast strategy for route discovery, which will be minutely described in the next Section.

4. ZigBee Broadcast Algorithm on Route Discovery (ZBARD) When a ZigBee node discovers any routes for a destination, it usually sets the broadcast radius to a pre-defined value which is two times a network depth configured in ZigBee. If a lower radius for route discovery than the default value can guarantee a shortest path between a source and destination, it can help to degrade routing overhead because of limiting many redundant transmissions. Note that we assume that a path cost metric for routing is based on the number of hops. To cope with this issue, we propose an effective flooding algorithm called ZBARD (ZigBee Broadcasting Algorithm on Route Discovery). ZBARD sets the broadcast radius to hops counted along with hierarchical tree routing between nodes considering hierarchical relationship of both nodes. This is the reason if a path cost computed through route discovery is greater than hierarchical tree routing hops, end-to-end latency increases and more energy is consumed due to increased relay. The ZigBee specification [8] does not explain determining a

ISBN 978-89-5519-136-3

-1189-

minimal radius equivalent to the tree routing, because any source node cannot know the depth of a desiring destination. However, ZBARD can calculate the depth value of the destination through parsing addresses allocated from a ZigBee Coordinator in the position of a source itself. The related notations are given in Fig. 1. The algorithm for computation of the broadcast radius is described in Fig. 2 below. As: hierarchical address of a source node Ds: depth of a source node Ad: hierarchical address of a destination node Dd: depth of a destination node Rb: broadcast radius calculated by algorithm Hd: hierarchy degree between source and destination Cm: the maximum number of children Rm: the maximum number of routers Dm: the maximum number of depth

Fig. 1. Notations Input:: As, Ds, Ad Output: Rb of a source node for establishing a route --------------------------------------------------------------INIT Hd, currentDepth, routerIndex, lowerBound, and upperBound as zero foundDst = false REPEAT INCREMENT lowerBound INCREMENT currentDepth foundDstBlock = false routerIndex = 0 REPEAT INCREMENT routerIndex upperBound = lowerBound + Cskip[currentDepth-1] IF (routerIndex = 0) THEN lowerBound = upperBound END IF IF (lowerBound≤As) and (As