Practical 3D Geographic Routing for Wireless Sensor Networks PRATIBHA SUNDAR S A THESIS SUBMITTED FOR THE DEGREE OF MASTER OF SCIENCE DEPARTMENT OF COMPUTER SCIENCE SCHOOL OF COMPUTING NATIONAL UNIVERSITY OF SINGAPORE January 2010 Acknowledgements This research project would not have been possible without the support of many people. I would like to express my gratitude to my supervisor, Dr. Ben Leong who has been patient, helpful and offered invaluable assistance, support and guidance. I also thank all my graduate student friends, especially Jiangwei, Duc and Chen Yu for sharing the literature, time and assistance. My sincere gratitude goes to Padmanabha Venkatagiri who helped me understand certain concepts in the literature. It had been a pleasant learning experience. I thank God for blessing me with such wonderful parents, aunt and uncle for their understanding, unconditional love, infinite faith and support throughout the duration of my studies. I also thank God for giving me the opportunity to study at NUS. It had been a memorable learning experience. i Table of Contents 1 Introduction 1.1 Background . . . . . . . 1.2 Motivation . . . . . . . . 1.3 Research Contributions 1.4 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Related Work 2.1 2D Planar-graph Based . . . . . . . 2.1.1 Planarization . . . . . . . . . 2.1.2 Face routing . . . . . . . . . 2.2 2D topology-based . . . . . . . . . . 2.2.1 Reactive protocols . . . . . . 2.2.2 Pro-active protocols . . . . . 2.3 2D beacon-based . . . . . . . . . . . 2.3.1 Beacon vector routing (BVR) 2.3.2 GLIDER . . . . . . . . . . . . 2.3.3 MGGR . . . . . . . . . . . . . 2.4 3D Geographic Routing . . . . . . . 2.5 3D unit ball graph based routing . 2.6 3D hull based routing . . . . . . . . 2.7 Summary . . . . . . . . . . . . . . . 3 GDSTR-3D 3.1 Routing Algorithm 3.1.1 Illustration 3.2 Tree Building . . . 3.3 limiting Number of 3.4 Discussion . . . . . . . . . . . . . . . . . . . . . . Children . . . . . . . . . . . . . . . . ii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 3 4 5 . . . . . . . . . . . . . . 6 6 7 11 15 15 16 19 19 19 20 21 25 27 27 . . . . . 30 32 36 37 42 46 4 Implementation 4.1 Design considerations . . . . . . . . . . . . . . . 4.1.1 Storage requirement - Data Structures . 4.1.2 Bandwidth requirement - Message Types 4.2 Functional architecture . . . . . . . . . . . . . . 4.2.1 Logical link layer . . . . . . . . . . . . . . 4.2.2 Routing layer (GDSTR) . . . . . . . . . . 4.2.3 Application Layer . . . . . . . . . . . . . . 5 Evaluation 5.1 Evaluation criteria . . . . . . . . . . . 5.2 Success rate . . . . . . . . . . . . . . 5.3 Hop stretch . . . . . . . . . . . . . . . 5.4 Storage cost . . . . . . . . . . . . . . . 5.5 Overhead cost . . . . . . . . . . . . . 5.6 Discussion . . . . . . . . . . . . . . . 5.6.1 Root of the Hull Tree . . . . . . 5.6.2 Geometry of the Hull . . . . . . 5.6.3 Factors affecting Performance 5.6.4 Issues with Face Routing . . . 5.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 47 48 49 52 52 52 54 . . . . . . . . . . . 55 56 57 58 61 66 70 71 72 74 77 80 6 Conclusion 81 6.1 Future research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 iii List of Figures 1.1 Example of communication void . . . . . . . . . . . . . . . . . . . . 2.1 Planarization by GG, RNG and occurrence of pathology in a nonUDG case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Routing failure due to crossing links by obstacles . . . . . . . . 2.3 Identifying critical links removing which will partition the network. As shown, critical links are traversed in both directions by the probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Types of Face Change during a face walk . . . . . . . . . . . . . . 2.5 Cell-based forwarding results in the solid path and positionbased Greedy forwarding in the dotted path . . . . . . . . . . . . 2.6 Planarization effected by two trees . . . . . . . . . . . . . . . . . √ 2.7 Crossing edge in a QUDG with R/r 2 ∗ r >= R (as R/r = 2) This means that the distance(u, v) > R, the maximum transmission radius which is not possible in a QUDG. Hence, planarization on a connected QUDG √ with R/r= 2 will always be planar. Therefore delivery can be guaranteed on such graphs. A 2-local backbone based algorithm is also been proposed by Fabian et al. [22]. Durocher et al. [3] extends this result and proved that a unit ball graph √ √ contained within a slab of thickness 1/ 2 can be converted to a 1/ 2-QUDG and hence delivery is guaranteed by 2-local algorithm as proposed by Fabian et al. [22]. To guarantee delivery using only local information on any arbitrary graph, the case has to be extended to a graph contained within a thickness of √ more than 1/ 2. He gives a transformation of such graphs onto a UBG and prove that if there exists a k-local algorithm then there can be a 1-local algo- 22 rithm that guarantees delivery. Then he proves that such a 1-local algorithm will have a graph G for which it is defeated and extends this proof to k-local case. Let us assume that there exists a 1-local algorithm for arbitrary graph G. Consider the two graphs as shown in Figure 2.8 where s is source and t is the destination. The routing function is self mapping where the packet comes from anyone of the 1-hop neighbours and the next hop is also from the 1-hop neighbours excluding the one which sent the packet to current node. Take all routing possibilities at nodes a and e for that message. It is a set of four functions as shown in Figure 2.9. These four function will fail in either of the two graphs G1 and G2. This means that for any 1-local algorithm, there is a graph which defeats it. The case is the same for a k-local algorithm where the edges in graphs G1 and G2 are replaced by paths of length k. Therefore, there cannot be a k-local routing algorithm that guarantees delivery for any arbitrary three dimensional graphs. 23 Figure 2.8: Any 1-local routing algorithm is defeated by G1/G2 if all routing functions are derangements. Figure 2.9: The four possible combinations of derangements for local routing functions fa′ and fe′ . 24 2.5 3D unit ball graph based routing Unit Ball graph (UBG) is the natural generalization of the UDG of 2D solutions. Even though UBG suffer the same disadvantage as that of UDG, there are approaches based on UBG. Durocher et al. [3] have provided theoretical feasibility of a UBG based routing for three dimensions and explored the relationship between UBG, quasi−UDG and quasi−UBG. From their proofs, there is no local memoryless algorithm to traverse all nodes on a given surface in a deterministic manner. A randomized geographic routing algorithm called Greedy-Random-Greedy (GRG) routing [9] provides a UBG based solution with random walk. They have shown that if d is the length of the optimal path between a given source and destination, then the expected length of the route obtained by any randomized or even deterministic routing algorithm is given by Ω(d3 ). Each node forwards packet by greedy until a void node occurs. A void node performs four different types of random walk (RW) for recovery to greedy forwarding again: • Region Limited Random Walks: The void node performs random walk around 1-hop radius and keeps on incrementing on the random walk radius on failures to find the next hop until a node closer to the destination than the local minimum is reached. • RW on Surface: Similar to face routing in 2D, the RW is limited to the nodes surrounding the void that caused a local minimum. In 2D, planarization is used to capture voids. Here, they assume a simple UBG model. They construct a dual graph and try to RW around threedimensional virtual grids surrounding the void. It is illustrated in the Figure 2.10 • Sparse Subgraph: the idea is to construct a sparse graph out of the given 25 Figure 2.10: Virtual grid formed from dual graphs to border the void (taken from [9]) topology without partitioning the graph. This is achieved by constructing a dual graph • Power of choice for RW: This is just an optimization where a RW will not return to the previous node to improve cover time. The experiments are done on java-based simulation over 2000 to 40,000 nodes. Their results have shown that, GRG incurs high routing overhead compared to flooding on smaller topologies (2000-5000 nodes) and improves closer to flooding only for larger network size. They have inferred that, limiting RW does not improve performance and their fourth option of ’Power of choice’ also doesn’t work. Also there is no other mention of performance of the protocol like packet delivery success rate. 26 2.6 3D hull based routing Greedy-Hull-Greedy (GHG) [31] divides the network into subspaces. The spatial construction into subspaces is as follows: • The entire 3D network space is divided into triangles by Delaunay triangulation. • Any crossing edge or crossing triangles are identified and removed. They use partial unit Delaunay triangulation (PUDT) to remove crossing triangles and edges. • The resulting triangles and single edges are then grouped in the form of 3D convex hulls based on their hull construction algorithm [30]. Routing by GHG is primarily by greedy forwarding until a local minimum is reached. At the local minimum, the void node forwards the packet to an adjacent hull called the target hull which is the hull through which an imaginary line segment mt between the local minimum (m) and the destination (t) passes. i.e. the node will forward to the adjacent hull which is closer to the destination along the line mt. This can be imagined as the counterpart to face traversal where face change occurs along the line segment (SD) containing source (S) and destination (D). Inside each hull, Depth First Search (DFS) is performed. An example of GHG routing is shown in the Figure 2.11 2.7 Summary In this section we provided an overview of existing work related to our thesis. Even though there has been a vast research on geographic routing, it is important to note that very few have been deployed in real environment. Most of the work are done on simulation and theory. One reason is that some 27 Figure 2.11: Example of greedy-hull-greedy (GHG) routing (taken from [31]) existing geographic routing protocols make unrealistic assumptions. For example, in the case of 2D planar based approach, the assumption of UDG is unreal. Some protocols assume perfect link reliability or accurate localization of nodes. Another reason is that real world network issues like obstacles and time-varying wireless channels are not addressed [36]. Hence when these protocols are implemented on real networks, they suffer from performance degradation. Since greedy forwarding is stateless and incurs less overhead in terms of storage cost, the performance of the algorithm greatly depends on the voidhandling algorithm. It is better to increase the success rate of greedy forwarding and minimize use the void-handling as the greedy forwarding always provides optimal hop stretch. wireless sensor networks (WSN)s come with certain constraints like storage and energy and it is important for the programmers to take them into consideration while designing the routing algorithm. The constraints were detailed in Chapter 1. For example, in the case of GRG (3D routing protocol), the amount of information needed to store the dual graphs can be large and the routing overhead for nodes from 2000-5000 is much 28 higher than that of flooding and therefore will be more energy consuming. Even though their performance is better for network size larger than 5000, in real world a network of that size is not yet practical. The future work on routing protocols for WSNs is on the design of algorithms that work on real WSNs. For instance, greedy forwarding can include link characteristics other than position when finding the next hop. Since maximizing greedy forwarding maximizes routing performance, design on maximizing greedy forwarding has been a separate literature by itself. Geographic routing in three dimensions is another interesting problem as real networks are deployed in 3D space. Our work addresses this problem of 3D routing. 29 Chapter 3 GDSTR-3D Greedy Distributed Spanning Tree Routing (GDSTR) is an existing 2D geographic routing algorithm that uses a distributed spanning tree called hull trees. GDSTR [25] has been shown to perform better than other existing algorithms like CLDP+GFR [15], GPSR [12] for two dimensional topologies. Our goal is to evaluate its potential in a more realistic three-dimensional environment. GDSTR forwards a packet using greedy forwarding and when it fails, it switches to tree routing until greedy forwarding can be resumed. Extending greedy forwarding to 3D is straightforward as the distance function can use 3D coordinates instead of 2D coordinates. The tree building part of GDSTR involves constructing 2D convex hulls with for two hull trees. A straightforward extension is to replace the 2D convex hulls with 3D convex hulls. However, it turned out that 3D convex hulls require a significant amount of computations and memory storage and so we had to try other options. The original GDSTR was evaluated in netsim [24], a high-level event-driven simulator. wireless sensor network is an embedded platform and the first step towards practicality is to implement our algorithm in a compatible platform. We implemented both 2D and 3D GDSTR in TinyOS, an open source OS for 30 WSN. The first challenge we faced was the limited memory available on existing wireless sensors. So, care must be taken when choosing the 3D structure as it should not consume too much memory. In GDSTR, for each tree a node has to store the convex hulls of all the children. As the network density grows, the maximum number of children a node have will potentially increase. So, we also had to modify the tree building algorithm from the original GDSTR [25] to limit the maximum number of children a node can have for a tree. This ensures that our algorithm will always comply with the storage limitation of wireless sensors irrespective of the topology. The maximum packet size supported by the IEEE 802.15.4 standard is only 127 bytes [11]. Hence, the next challenge we faced is the limited bandwidth available in the sensor network environment. For tree building, each node has to broadcast tree information including its convex hull points to its parent. Hence, we logically fragmented the information into different packets. This is another consideration in choosing our 3D geometric structure especially for 3D convex hull as the information should fit within the payload. We also found that improving the greedy forwarding success rate significantly improves hop stretch. So, we modified the algorithm to use two-hop neighbour information for greedy forwarding. Though this improved performance of all versions of GDSTR, it does not affect their relative performance. In Section 3.1, we explain our routing algorithm. In Section 3.2, we describe the tree-building phase of the algorithm and discusss the different options avilable for the 3D geometric structure and in Section 3.3, we describe our algorithm to limit the number of children. Finally, in Section 3.4, we provide a summary of the key differences between our implementation of GDSTR and the algorithm described in the original paper [25]. 31 3.1 Routing Algorithm In this section, we provide a detailed description of the GDSTR-3D routing algorithm. GDSTR first forwards packets greedily, i.e. first find the 1-hop or 2-hop neighbour whose coordinates is nearer to the coordinates of the destination node than the current node, which we call as the nearest neighbour. If it is the 1-hop neighbour, then the current node forwards the packet to it directly; if it is the 2-hop neighbour, the current node forwards the packet to the 2-hop neighbour through a 1-hop neighbour using the neighbour table. A tie is broken by always selecting a 1-hop neighbour if a node has more than one nearest neighbours. The greedy part is loop free, which follows from the observation that the distance from the nearest neighbour to the destination for nodes along the path is always non-increasing. a and b are two consecutive neighbours along the path, if b is a’s 1-hop nearest neighbour, then b must either have a nearest neighbour that is closer to the destination than b or b is a local minimum and GDSTR will trigger the tree traversal mode. If b is a’s 2-hop nearest neighbour, then there is no 1-hop/2-hop neighbour for a closer to destination than b. So, if b has a nearest neighbour, it will not be a node from a’s 2-hop neighbourhood; otherwise b will invoke tree forwarding. This ensures the non-increasing property and the packet will not be forwarded back to a prior node which processed it already. The different alternatives of a 3D geometric structure we had tried in place of 2D convex hull will be discussed in the next section. For sake of discussion we shall commonly refer them as hull. The key insight in GDSTR is that the hulls of the nodes determines a routing subtree rooted at that node potentially containing the destination within the subtree. Due to false positives, a packet may find more than one routing subtree. If a packet is not deliverable, then 32 none of the possible routing subtrees contain the destination. In the example shown in Figure 3.1, there are two routing subtrees rooted at nodes v1 and v2 because either of their hulls contain the destination point. The destination must either be a child node of v1 /v2 or the destination does not exists and the packet is undeliverable. root anchor local v1 minimum v2 hull for v1 dest hull for v2 Figure 3.1: Overview of GDSTR tree traversal. Tree forwarding involves finding a routing subtree and if destination node is not on the routing subtree, it forwards the packet up to the parent of the routing subtree. Eventually, the packet will either hit the target subtree actually containing the destination or the packet moves up the tree to reach the root (which is guaranteed to find the target subtree if a packet is deliverable). Once the packet reaches the root of the routing subtree, we mark it as the anchor node. Tree traversal is simply a depth-first search on the routing subtree guided by the hulls containing the destination. When the packet returns to the anchor node exploring all possible paths in the routing subtree, the anchor node forwards the packet to the parent. Note that GDSTR-3D will switch back to greedy forwarding once it finds a 1-hop or 2-hop neighbour closer to the destination than the local minimum that initiated the tree traversal. Each GDSTR-3D data packet contains the following state information: • mode: current forwarding mode (Greedy/Tree), 33 • nmin : the most recent local minimum the packet encountered, • nanchor : anchor node of the tree traversal, and • root: tree identifier for the forwarding tree chosen. mode indicates the currently used forwarding mode for the packet namely greedy or tree. nmin is the node (local minimum) at which the packet switched from greedy to tree mode recently. It is used in the tree mode to determine when to switch back to greedy. nanchor is the first node encountered by the packet in tree mode having a hull that contains the destination node. root is the unique identifier for the tree that is currently being used by the packet for tree forwarding. Algorithm (GDSTR-3D). When a node v receives a packet p to destination t from a neighbour node u: 1. Termination Condition: Packet delivery ends if one of the following conditions are met: • v is the destination t. • v is the root of hull tree and the hull of v does not contain the destination t. Set p as undeliverable. • p.mode is T ree, p.anchor is child of v and v is p.root, the root of chosen tree. If u is the last child of v whose hull contain the destination t. Set p as undeliverable. 2. Check for switch to Greedy mode: If the current p.mode is T ree and there is at least one 1-hop or 2-hop neighbour whose distance to t is less than p.nmin , then: • Set p.mode to Greedy. • Reset p.nanchor and p.root to NULL. 34 If p.mode is Greedy go to step 3, else go to step 5. 3. Greedy Mode: If there exists a 1-hop or 2-hop neighbour w closer to t than v, then forward p to w if w is a 1-hop neighbour, or forward p to the 1-hop neighbour connecting w as per the neighbour table. Else go to step 4. 4. Switch to Tree Forwarding mode: • Set p.mode to T ree. • Set p.nmin to the current node v continue to step 5. 5. Set Tree information on p: If p.root is set and there is no change, continue to step 7. Otherwise, set p.root to the root of the tree closest to t and go to step 6. 6. Find Routing Subtree and Set Anchor: If p.anchor is set, continue to step 7. Otherwise, if v is a leaf node forward p to its parent for tree with root p.root; Else if v’s hull contains the destination t, set p.nanchor to v and forward p to the first child if any, whose hull contains destination t or to its parent if v is a leaf node. Else, forward p to v’s parent node for tree with root p.root. 7. Tree Forwarding: v will choose the next hop based on its relationship with u. • If u is v’s child: – If u is the last child whose hull contain the destination t and p.nanchor is a child of v, reset p.nanchor to v. – Forward p to the parent if u is the last child whose hull contain the destination t. – Otherwise, forward p to the next child whose hull contain the destination. 35 • If u is v’s parent, forward to the first child with a hull containing the destination if such a child exists. Otherwise, forward p back to parent. 3.1.1 Illustration In this section, we would like to explain our algorithm with an example. In the Figure 3.2 node S wants to send a packet to node D. S forwards the packet to node L using greedy forwarding where the packet encounters a local minimum. L switches to tree forwarding mode and identifies the tree having root R1 as its forwarding tree. checks if D is contained within its convex hull or not. As L’s convex hull does not contain D, it forwards the packet to its parent for that forwarding tree. The parent node upon receiving the packet from L checks if its convex hull contain D. Since its convex hull contains D, this node is set as the anchor node. The anchor node then checks whether convex hull of any of its children contains D. When it finds that none of its child nodes contain D, it forwards the packet to its parent node 1. This process repeats itself and the packet reaches node 3. Node 3 upon receiving the packet finds that one of its children’s (node 4) convex hull contain D and the packet is forwarded to node 4. In a similar fashion the packet ascends down the tree and reaches node 6. The subtree under node 6 is the subtree actually containing the destination node D. At each step the current node will check if greedy forwarding can be resumed, i.e. it can find a neighbor node closer to D than the local minimum (node L). The routing mode will switch back to greedy whenever it can be resumed. Node 6 will eventually forward the packet to the destination D either by tree/greedy forwarding mode. In case the packet is not delieverable, each node handling the packet will forward it to its parent node in the tree forwarding mode and the packet will 36 eventually reach the root node R1 as shown in Figure 3.3. The root node has the complete view of the topology by way of hull aggregation. If a packet is undeliverable, it can detect it and the packet will be dropped by the root node. Figure 3.2: Illustration of routing using GDSTR-3D 3.2 Tree Building We use Minimal Depth Spanning Tree algorithm to building our spanning trees. According to the algorithm, a node determines which among its neighbours have the minimal distance in terms of hop count to the root and: • If there is only one node, choose that node as the parent. • If there are multiple nodes, choose the node that have the smallest geo37 Figure 3.3: Illustration of how undeliverable packet is handled in GDSTR-3D metric distance to the root as parent. The building of spanning tree has two phases. The first phase starts by determining the root node for each tree. Our algorithm builds two trees. The root nodes are chosen as the nodes positioned at extreme ends of the topology i.e, having the minimum x/y/z-coordinate and maximum x/y/z-coordinate. In case of a tie, it can be broken by applying additional rules like minimum node identifier. For a node, parent is chosen by the above mentioned algorithm for each tree. Each node periodically broadcasts the information it has about its view of the root node, hop count to the root, parent node and list of children to its neighbours. From the broadcasts, each node will update its tree information. Eventually all the nodes will come to a consensus on the root node and will know its parent node and its hop count to root for each tree. We modified the original GDSTR algorithm for tree building to limit the maximum number of children a node can have. This involves a series of handshake between neighbour nodes to assign parent for each tree. The handshake will be discussed in detail in Section 3.3. 38 The next phase in the tree building is the sphere/convex hull building or simply hull aggregation. Each node based on its children’s information, will build a 3D geometric structure (sphere/3Dconvex-hull in this case) such that the shape encloses all the nodes in the subtree rooted at that node. This hull information will be sent to its parent which computes its own hull. This process continues up the tree starting from the leaf node to the root node for each tree. In GDSTR, the hull (2D/3D convex hull or sphere) helps to identify routing subtrees for a packet. To ensure correctness of routing it is enough for the hull to provide true-positives and to avoid false-negatives. But false-positives affect the performance of the routing algorithm in terms of hop stretch. We tried several alternatives of sphere and 3D convex hull which are explained below to see the performance versus cost trade-off. The alternatives are illustrated in the Figure 3.4. 3D Convex Hulls: The first obvious choice for the 3D geometric structure is 3D convex hull similar to 2D convex hull in the original work [25]. We built our 3D convex hull using incremental algorithm [32]. The size of the convex hull can grow depending on the geometry of the network and the node distribution. Hence, for optimization of storage and scalability, we limit the number of points in the hull. While limiting the number of vertices in a 2D convex hull is straightforward, it is not simple in the case of 3D. The 3D convex hull is built as a set of triangular planes. For a given triangular plane, there will be at least six adjacent triangles: three triangles sharing a common edge and other three sharing only a vertex with this triangle. The algorithm for reducing the number of vertices for a 3D convex hull is as follows: • Take the adjacent triangles with common vertex and find out the point of intersection of those three planes. • These three planes form a tetrahedron with the calculated intersection 39 point. From all such possible tetrahedrons for the convex hull, find the tetrahedron with the minimum volume. • Add the point of intersection with the minimum volume to the given convex hull if it lies outside the hull. The trade off is that the resulting hulls are not minimally-compact which will increase the chances of false-positives. Spheres: Implementing a 3D convex hull is complex than a 2D. Our approach of reducing the number of vertices is computationally exhaustive as it tries all possible tetrahedrons for each reduction until the bound is met. 3D convex hull need to store edge, face information and adjacent face/edge information in addition to the vertices. Then only it can identify whether a point (destination) is inside the hull or not. The number of vertices in a 3D convex hull is greater than that of 2D. Hence, the overhead of exchanging convex hull information between parent and child nodes will also be greater. To overcome these issues, we chose to approximate the convex hull with a sphere. Sphere is a simple three dimensional object and it needs only two information namely the center and the radius. The message overhead for building spheres will be less than 2D. It is also simpler to implement than 3D convex hull. The disadvantage of using a sphere is that, it is less compact than a 3D convex hull which means chances of more false positives due to overlapping adjacent spheres. So, sphere will have a higher hop stretch than 3D convex hull. It can be minimized to an extent by choosing an optimal center to make it compact. Hence for a given set of points, the center of gravity of those points forms the center and the maximum distance between this point to the given set of points forms the radius. Using Spheres with 3D Convex Hulls. 3D convex hull incurs high storage cost and sphere is less compact and affects routing performance. To overcome 40 Figure 3.4: Different 3D hull alternatives these, our third approach is a hybrid of these two solutions. Each node after computing 3D convex hull will store only the vertices. In addition it will store the corresponding sphere for the same set of points. During routing, a node will check its sphere whether it contains the destination or not. If the sphere contains, then the vertices stored will be used to compute 3D convex hull on-demand and check if it contains the destination. This on-demand computation of 3D convex hull reduces the storage requirement of the prior 3D convex hull version. The use of sphere to identify potential routing subtrees is to reduce the number of on-demand computation of 3D convex hull. Since a sphere is an approximation of a 3D convex hull, if a destination is 41 not contained in a sphere, it will not be contained in a 3D convex hull. The performance of this approach is as good as that of prior 3D convex hull approach. Projection of 3D convex hull onto 2D. The hybrid version stores only one convex hull per node at any given point in time. When we tested our hybrid approach on real wireless sensors, the computation of 3D convex hull incurred high usage of run-time memory and the storage cost is still considerably high to ensure performance (given number of vertices in a 3D convex hull). Also the on-demand computation of convex hull is energy inefficient. Hence, we project the coordinates of the given points on two planes (say xy and xz planes) and compute 2D convex hulls from these projected points on each of the planes. This approximates the original 3D convex hull better than the sphere. The approximation comes with a trade off. Substituting 3D convex hull with 2D projections might increase number of false positives affecting the stretch. But the performance of the projected 3D-on-2D convex hulls is better than spheres. We also tried projections on all three planes xy, xz and yz and found that the there is not much improvement in the performance. 3.3 limiting Number of Children While building the minimal path spanning tree, each node chooses the neighbour which is closest to the root in terms of hop count as its parent. So, the average and maximum number of children per node depends on the topology. Since, each node has to store child information for each tree including the convex hull points (vertices), there is no control over the storage cost incurred per node. As sensor networks have smaller memory, there are chances that the maximum storage required for a node exceeds the storage limitation of the sensors. Hence, there is a need to bound the maximum storage incurred by a 42 node irrespective of the topology. We bound the maximum number of children a node can have for a tree to a user defined limit irrespective of topology. Each node maintains status information of its own and that of its neighbours for each tree. The status information describes what type of a parent and a child the node is for that tree. A parent request is a request sent by a node to its neighbour requesting that node to become its parent. The status information is used to process parent requests. The different types of statuses are explained below: • Normal child: A child node having neighbours that are unrelated to it (neither its parent nor its child) and have not rejected its parent request before is called a normal child. This means that those unrelated neighbours are available to the child node as potential parents and so the child node can survive a reject from its current parent. • Critical child: A child node which has been rejected at least once by all potential parent neighbours is called a critical child. This means that the node is desperate for a parent and this node will be given higher priority over a normal child by the parent node when accepting parent requests. • Occupied parent: A parent node which has a mix of both normal and critical child and whose number of children has reached its upper bound is called an occupied parent. Even though such a parent cannot afford additional children, it can accept new parent request from a critical child by abandoning an existing normal child. • Crucial parent: A parent node whose number of children have reached the maximum upper bound and all its children are a critical child is called a crucial parent. This node cannot abandon any of its children and so, cannot accept any further parent requests. 43 The handshake between neighbour nodes to process parent requests and assign parents in such a way that the maximum limit set on number of children is not exceeded is given in the Figure 3.5. Each node will try to update its root and parent from neighbour broadcasts. While updating, it will try to assign the neighbour node which is closest to the root node of the given tree as its parent provided that neighbour has less number of children than the maximum limit. Else, it will try to assign the next available neighbour as parent. When a parent is assigned, a node will update its child status accordingly for that tree. Once the root information and parent is updated properly, all further broadcasts from unrelated (neither as parent nor as child) neighbours will be ignored. A child node waits for the parent to accept it as a child until the parent node reaches the maximum child limit without accepting its request. Then the child node will reset the current parent assignment and look for a new parent. A parent node on the other hand will accept all parent requests from its neighbours until the number of children reaches the maximum child limit. Once it reaches the limit, the node will set its parent status accordingly. If the parent node is a crucial parent, it will ignore all further parent requests. If the node is only an occupied parent, then when a parent request comes from a critical child, the node will remove a normal child and accept the request of this critical child in its record. The abandoned normal child will discover it in the next broadcast and will have to choose another parent. When the userdefined maximum limit on the number of children is not sufficient enough, it might be possible that a node cannot find a suitable parent for its tree and become an orphan. Such scenarios can be avoided by setting sufficient upper limit for the maximum number of children. 44 Figure 3.5: Handshake between neighbour nodes for limiting number of chil45 dren 3.4 Discussion There are quite a few changes to the new GDSTR as compared to that of the original work [25]. Logically in terms of routing algorithm, a major difference between GDSTR-3D and GDSTR [25] is that GDSTR-3D does not implement the conflict hull optimization in order to reduce storage costs. In addition to its convex hull, each node in GDSTR also maintains information about the set of convex hulls that intersect with its own convex hull. These intersecting convex hulls are known as conflict hulls. A node stores conflict hulls from nodes that are not its descendants or ancestors, i.e., for siblings and cousins. The prescribed way to achieve dynamic memory in TinyOS is to have design our own shared dynamic memory pool [28]. It is hard to estimate in advance, the maximum number of conflict hulls a node can have. The drawback of not implementing the conflict hull optimization is that, all undeliverable packets would be forwarded to the root, thereby increasing the load on the root nodes. If such scenarios are not common, there should be little effect on routing performance. Another obvious difference is the convex hull structure. For 3D networks, we tried four different alternatives namely, 3D convex hull, Sphere, hybrid and 3D-on-2D projection whereas in original GDSTR, it is only 2D convex hull. Further, we optimized GDSTR to enable an option of using two-hop neighbour information for greedy forwarding. Due to sensor’s memory constraints, we have modified the tree building algorithm to limit the number of children per node per tree. This bounds the storage cost per node. A tree formed by this will be slightly different than when there is no limit on number of children per tree. But from our experiments, there is no performance degradation. 46 Chapter 4 Implementation In this chapter, we provide an overview of the implementation of the protocols we studied. We implemented GDSTR (2D and 3D) in TinyOS platform version 2.x. TinyOS is an open source, component based operating system for wireless Sensor Networks (WSNs). TinyOS is written in nesC programming language as a set of co-operative tasks and processes. So, all TinyOS applications are written in nesC, a dialect of C programming language tailor-made for the memory limitations of sensor networks. Further details on the implementation platforms can be found in the document by Levis [28] for TinyOS and in the conference paper by Gay et al. [4] for nesC. In the following sections, we explain the design considerations of the implementation and functional specifications of our algorithm. 4.1 Design considerations When we implemented our algorithm, the two major practical challenges we faced are the storage and message bandwidth requirements of GDSTR. Hence in this section, we highlight how we store the data and how we logically fragmented the messages to meet the bandwidth constraints. 47 4.1.1 Storage requirement - Data Structures As with any geographic routing protocol, the basic information required is about the neighbours. This information is needed by the greedy forwarding algorithm. GDSTR uses hull trees to handle greedy forwarding failures and hence need tree information. So, information is stored in two main data structures. The Neighbour table data structure contains neighbour information such as their node id, position information, whether the link shared is symmetric or asymmetric. We can also extend it to contain link quality information in a more practical setting. In GDSTR, we have added an option of using 2-hop neighbour information to enhance greedy forwarding success rate. This 2-hop neighbour information contains only the position information of a node’s 2-hop neighbours. Due to storage constraints, we limit the number of 2-hop neighbour information stored by a node to a user defined value. We can also disable this feature and use only 1-hop information by changing experimental settings. In addition to the neighbour information, GDSTR needs tree information for void-handling. The tree is built during the system convergence phase of the algorithm and each node store its view of the tree in this data structure. Even though only one tree is enough to guarantee successful packet delivery , we can increase the number of trees to improve performance. For each tree, the information includes the root information (node id and position), parent node id, hop count to the root and list of children’s information. Child information is stored in peer information data structure. Peer information includes pointers to the child’s node id and position, its hull information (2D/3D convex hull or sphere) and message sequence number. Hull information data structure contains the number of vertices and coordinates of the vertices in case of convex hulls or coordinate of center and radius in case of sphere. We can configure the number of trees to be built, the maximum num48 ber of vertices a convex hull can have and the number of 2D projections in the case of 3D-on-2D convex hull in our settings. 4.1.2 Bandwidth requirement - Message Types The message type refers to the type of information being communicated between neighbours. Messages can be broadly classified into control packets and data packets. Data packet refers to the message sent by the application from a source to a chosen destination. Control packets are used to exchange routing information that helps in successful delivery of data packets for any valid source and destination pairs. As data packets are purely application specific, in this section we will explain the different types of control packets needed by GDSTR for routing. The routing information exchanged by these control packets will be stored in different data structures mentioned in storage requirements section. Hence, similar to storage requirement, there are two main categories of control packets, the neighbour messages and the tree messages. The classification is shown in Figure 4.1. Figure 4.1: Classification of message exchanged among nodes for GDSTR 49 Neighbour messages Each node broadcasts its neighbour information to all 1-hop neighbours. Broadcasted information will be used by the neighbours to update its neighbour table. Three different types of messages are broadcasted among the neighbours. The basic information sent is the hello packet. It is nothing but keep-alive message letting the neighbours know that the sending node is active. Hence, it will contain very minimal information like message sequence number. The 1-hop neighbour information used by greedy forwarding contains position of the sending node and the list of its 1-hop neighbour information. That list includes node id of neighbour and whether the link shared with it is symmetric. A neighbour node upon receiving the 1-hop neighbour message will check if it is included in the neighbour list and whether the sending node considers the link shared as symmetric or not. If the sending node doesn’t consider the link to be symmetric, then that sending node will be considered unusable by the neighbour node. Thus only symmetric links will be used by our algorithm. If the 2-hop optimization is enabled, then our algorithm needs to send 2-hop neighbour information. This information contains the positions of a node’s 1-hop neighbours. A node upon receiving this from its neighbour will update its 2-hop neighbour table. This in addition to the 1-hop neighbour information is used by 2-hop greedy forwarding. Tree messages GDSTR needs to build its minimum path spanning tree for void-handling. A tree is built using tree messages from neighbours and a node’s neighbour table. Each tree building starts with selection of root, parent and child assignment followed by aggregation of hull information up the tree. 50 In our current setting, GDSTR uses two trees positioned at the extreme ends of the topology and hence roots are selected as the nodes having minimum and maximum x,y,z coordinates. Each node has to broadcast tree information i.e, its view of the root, parent id, hop count to the root, list of children and status to its neighbours. A neighbour node upon receiving the message, will first update its root information if that message has the latest root. This updated root information will now be broadcasted in its tree message to its neighbours and the process continues across the network like a wave. Finally, all nodes will come to a consensus about the root. The information about hop count to the root is used by a node to select its parent node. The parent node will be the neighbour closest to the root in terms of hop count if that neighbour is available. As our algorithm limit the maximum number of children a node can have, it is possible that a neighbour has reached that limit. At the same time, a node has to express how desperate it is to get a parent. These information are contained in the status and is used in parent/child assignment. Details of the message handshake required for limiting children can be found in Section 3.3. All these information are exchanged for each tree built by the algorithm. After building the tree, GDSTR needs to aggregate hull information up the tree starting from leaf nodes till the root. Each node sends its hull information to its parent node. This message contains coordinates of vertices if hull is a 2D/3D convex hull and coordinates of center and the radius if hull is a sphere along with tree identifier. A parent upon receiving this message from all the children, builds its hull and send it to its parent. Thus the information is aggregated to the root for each tree. 51 4.2 Functional architecture We implemented our algorithm in three functional layers namely the Logical Link Component (LLC) layer, routing layer (GDSTR) and application layer. The functional diagram of GDSTR can be seen in Figure 4.2. TinyOS, our implementation platform is in nesC which is a component based C dialect. NesC components can be compared to objects in a Java/C++. There are two types of components namely modules and specifications in nesC. TinyOS applications are programmed into modules which provide the functionality and the configurations provide how these modules interact with each other. We explain the modules we implemented for each layer in this section. 4.2.1 Logical link layer This layer acts as an interface between the physical layer (radio) and the routing layer. We implemented two modules for this layer namely LLCM and EventQueueM. LLCM (Logical Link Component Module) is the interface between radio and routing layer which means that the routing layer sends (receives) packets to (from) the physical layer through this module. It uses send and receive buffer queues and is responsible for reliable packet delivery by acknowledgements and packet retransmissions to handle link level losses. We can also extend this layer to perform link control functions. The next module is the (EventQueueM) and this provides the send and receive buffer queues used by the LLC module. 4.2.2 Routing layer (GDSTR) GDSTR sits on top of the LLC layer and forms the routing layer. This layer has several modules performing different functionality of our algorithm. 52 Figure 4.2: Functional diagram of GDSTR implementation The main function of the module GdstrForwardM is to maintain neighbour information. It doesn’t interact directly with the LLC layer. But, processes all the neighbour messages and updates the neighbour table. If the 2-hop greedy is enabled in GDSTR, it maintains the 2-hop neighbour table. It also provides interfaces to retrieve the neighbour information. Our tree building is implemented in the module GdstrTreeM. This module handles all the control packets through the LLC layer. The neighbour messages will be sent to the GdstrForwardM module to update neighbour table. This module processes tree information and builds trees. It also processes hull information and constructs hulls. It interacts with GdstrForwardM module to access neighbour information for building the trees. Since it maintains all the tree information, it provides interfaces for accessing them. The module GdstrRouterM implements the routing algorithm of GDSTR 53 (please refer Section 3.1 for the algorithm). It handles all the data packets to route. Hence, it acts as an interface between the application layer and the LLC layer for exchanging data packets. It interacts with the GdstrForwardM module to access neighbour information for its greedy forwarding and with the GdstrTreeM module to access all the tree information like parent node, child node, hull for its tree forwarding. It sends only the packets destined to the current node and undeliverable packets to the application layer. Packets for routing are sent to the next hop neighbour through the LLC layer. 4.2.3 Application Layer This is the topmost layer and handles application level data transmissions to different destinations. This is the module which invokes other modules once the node is booted. It provides GdstrTreeM module the location information of the current node and sends data packets to the GdstrRouterM module for routing. As of now, the look-up for position information of all the nodes is contained in a flat file. The application layer uses this file to get position information of the current node and that of the destination nodes. Only when packets destined to it reach this layer, they are considered as successfully delivered in our evaluation. In addition, it also receives undeliverable packets from the router for logging. 54 Chapter 5 Evaluation We implemented our algorithm in TinyOS and ran all the experiments in TOSSIM, a TinyOS event-driven simulator library. Debugging TinyOS applications using TOSSIM is easier than real deployments. Details for TOSSIM are available in the TOSSIM Manual [33] and by Levis et al. [29]. We generated two different sets of topologies, one for different network densities with a fixed network size of 200 and the other for different network sizes with fixed densities (low and high). We randomly generated the 200 nodes in a fixed size 3D cubic space of 2,000 × 2,000 × 2,000 and verified that the topology is connected. By varying the circular radio range we achieved different densities. For the network size we vary the circular radio range in two different cubic spaces, 2,000 × 2,000 × 2,000 for smaller networks ([...]... based routing 2.4 3D Geographic Routing The existing research discussed so far in this literature is based on 2D topology The basic idea of greedy forwarding and void-handling is same for 3D networks The difference lies in the void-handling approach which make use of the third dimensional information 3D geographic routing is relatively new compared to 2D The obvious approach to handle voids in 3D is... All these algorithms address routing on 2D topology But, there are some real world scenarios, like networks within a building, that demand three-dimensional routing Even though greedy forwarding works in 3D topologies, it can also encounter communication voids On 3D geographic routing, Durocher et al [3] showed that there is no deterministic local routing algorithm for 3D networks that guarantees the... and Liu et al [31] have attempted to address the problem of 3D geographic routing While their work extend the ideas of 2D algorithm to 3D, their results are not encouraging in terms of performance and simplicity of solution In this light, we explore the trade-off between performance and cost for geographic routing algorithms in 3D networks in this dissertation 1.3 Research Contributions There are two... Research Contributions There are two main contributions in the thesis: first, we implemented GDSTR [25] in nesC on the TinyOS platform for wireless sensor networks; second, GDSTR was further extended to 3D and evaluated on 3D topologies against two wellknown 2D geographic routing algorithms, GDSTR [25] and CLDP+GFR [15] GDSTR maintains minimal-path spanning tree and each node in the tree 4 maintains... There is growing interest in using sensors in real-life applications like habitat monitoring, traffic monitoring and they are likely to be deployed in large numbers Hence, any routing algorithm for sensor networks should be scalable The memory available on sensors are small For example, a TelosB mote only has 10KB RAM and 1MB flash [2] Under laboratory conditions, wireless sensors are powered by batteries... real networks, they suffer from performance degradation Since greedy forwarding is stateless and incurs less overhead in terms of storage cost, the performance of the algorithm greatly depends on the voidhandling algorithm It is better to increase the success rate of greedy forwarding and minimize use the void-handling as the greedy forwarding always provides optimal hop stretch wireless sensor networks. .. the former case, flooding can be used to reach the destination and in the latter, route will be discovered from the void node and the routing information is maintained in a table 2.2.1 Reactive protocols Reactive protocols handle voids only during routing when a packet gets stuck in a void Some solutions perform limited flooding as in Cartesian Routing [8] and one-hop flooding [37] In Geographic Routing. .. packet forwarding phase where the void node uses already discovered route in its routing table to do source routing 15 2.2.2 Pro-active protocols As the name suggests, proactive protocols try to be prepared for voids before a packet encounters one In this section, we describe two such protocols: Robotic Routing Protocol (RRP) and Greedy Distributed Spanning Tree Routing (GDSTR) RRP Robotic Routing. .. GDSTR on TinyOS and extended it for 3D networks by replacing the 2D convex hull with 3D geometric structures like 3D convex hull and sphere The storage required by GDSTR is proportional to the average number of children per node Storage affects the amount of information to be exchanged between nodes (message overhead) which in turn impact the energy consumed Wireless sensors have small memory So, we... to be planarized for the routing algorithm to work A complete planar-based protocol should have a planarization algorithm and a planar-graph traversal algorithm for routing Complete planar-based void-handling techniques include Greedy Perimeter Stateless Routing (GPSR) [12], by-pass routing in Priority-based Stateless Geo -Routing (PSGR) [6] and RequestResponse (RR) in Beacon-less routing (BLR) [5] ... ad-hoc routing, geographic routing algorithms are attractive for such networks Many existing works on geographic routing are done for two dimensional topologies But in real world, many sensor networks. .. 2.3.3 MGGR 2.4 3D Geographic Routing 2.5 3D unit ball graph based routing 2.6 3D hull based routing 2.7 Summary GDSTR -3D 3.1 Routing Algorithm 3.1.1 Illustration... in nesC on the TinyOS platform for wireless sensor networks; second, GDSTR was further extended to 3D and evaluated on 3D topologies against two wellknown 2D geographic routing algorithms, GDSTR