Dynamic Routing Framework for Wireless Sensor Networks
Sustainable Wireless Sensor Networks
Numerous routing protocols have been proposed for wireless sensor networks. Each such protocol carries with it a set of assumptions about the traffic type that it caters to, and hence has limited interoperability. Also, most protocols are validated over workloads which only form a fraction of an actual deployment's requirement. Most real world and commercial deployments, however, would generate multiple traffic types simultaneously throughout the lifetime of the network. For example, most
... ments would want all of the following to happen concurrently from the network: periodic reliable sense and disseminate, real time streams, patched updates, network reprogramming, query-response dialogs, mission critical alerts and so on. Naturally, no one routing protocol can completely cater to all of a deployments requirements. This chapter presents a routing framework that captures the communication intent of an application by using just three bits. The traditional routing layer is replaced with a collection of routing components that can cater to various communication patterns. The framework dynamically switches routing component for every packet in question. Data structure requirements of component protocols are regularized, and core protocol features are distilled to build a highly composable collection of routing modules. This creates a framework for developing, testing, integrating, and validating protocols that are highly portable from one deployment to another. Communication patterns can be easily described to lower layer protocols using this framework. One such real world application scenario is also investigated: that of predictive maintenance (PdM). The requirements of a large scale PdM are used to generate a fairly complete and realistic traffic workload to drive an evaluation of such a framework. balanced communication, aggregation centric approaches (19) and so on to name a few. Each such protocol typically optimizes a certain set of chosen parameters in making routing decisions, and is likewise validated over a workload that only generates that type of network traffic. This means that a deployment that adopts any given protocol has to build its entire deployment logic using the traffic type for which the protocol is optimized. To make sensornets a viable solution to real world problems, applications need to be built on top of arbitrary communication patterns, often with conflicting requirements. For example, a meaningful case of habitat monitoring would mostly demand all of the following communication patterns to co-exist: periodic network reports using reliable sense and disseminate, critical real time alerts when anomaly is detected, aggregation to suppress duplicates, network reprogramming to transfer bulk data, patched updates for continuous customization of the sensornet, best effort communication to transfer redundant information, interactivity with the network in the form of request-reply dialogs and so on. Naturally, no one routing protocol can cater to such varied application requirements within a given deployment. In other words, a given deployment can be viewed as a collection of various tasks (applications) which have very different, and often conflicting, communication requirements. The deployment goal is met when the goals of its constituent applications are fulfilled. Secondly, there is little synergy across research efforts. Pressed by scarcity of energy and a need to focus on performance, protocols are developed with little thoughts to modularity and interoperability. Though a new application deployment would have a plethora of routing protocols to choose from, these protocols cannot be readily wired together to form a communicating framework due to compatibility problems. Compatibility problems largely arise because of the assumptions made on interface and data structure requirements. In general, and as Culler et. at. (5) note, a framework for testing, integrating and proposing protocols is largely missing. This chapter presents a routing framework that makes an application's communication requirements visible to the lower layers, and allows activation of application specific processing. The traditional routing layer is replaced by a highly composable collection of routing decisions. Now, the routing logic is dynamically wired as per each packets requirements. The effectiveness of this strategy is demonstrated by gathering requirements and validating a fairly complete deployment scenario: predictive maintenance (PdM) using sensornets (15). Protocol Description Routing Framework Overview Application payload presents a three bit preamble to the framework that describes it communication intent, The framework dynamically switches routing decisions based on the preamble bits. The routing layer is now a composable set of routing components that perform similar functions, but are optimized for different classes of traffic. The routing components carry a similar three bit signature that lets the framework know their applicability for a certain class of traffic. The selection of a routing component is hence a mapping between what the application demands and what the component has to offer. The routing components house core protocol features that cater to a particular application type. This allows components to evolve independently, and owing to their composable nature, allows seamless migration from one deployment experience to another. To unify interface assumptions, the routing components www.intechopen.com Dynamic Routing Framework for Wireless Sensor Networks 255 share a universal neighbor lookup table that houses relevant information about various neighbors which saves storage space and makes way for consistent interface assumptions. Component protocols make ranged queries into the neighbor table to derive the best candidate hop for a given application payload. Designing such a framework requires addressing challenges of composing routing protocols into core components, and regularizing the various interface and data structure requirements. But before that, we begin with the fundamental problem of making visible an applications demands to the stack. Specifying Communication Intent Applications need a way to express their communication requirements in a format that is both completely expressive and minimal. Various approaches have been taken to increase application visibility to the communication framework, and much of the effort has been to prioritize data. For example, the SP architecture (20) argues for a one bit descriptor that describes the urgency of a packet. On the Internet, DiffServ uses a class of service (CoS) field, three bits in length, to specify a priority value between 0 (for best effort traffic) to 7 (real time traffic). ISP's in the present day Internet also use similar tags to differentially route packets from preferred customers and offer them a higher quality of service. However, assigning a priority for any class of traffic is a highly subjective task, and these assignment rules would not be consistent from one deployment to another. Application naming should instead revolve around fundamental communication requirements rather than blatant priorities. This would allow one to construct meaningful and consistent inferences of a packets requirement for virtually any deployment. In effect, the following question is posed: What is the minimum number of bits to let a deployment specify its fundamental communication requirements? To best characterize an application to the communication framework, various possibilities exist: number of recipients (anycast, multicast, broadcast), loss tolerance, delay tolerance, priority, sensitivity to congestion or link losses, soliciting retransmissions, tagging packets for aggregation, tagging packets for load balancing, control information v/s data packets and so on. However, communication patterns can be best described using three fundamental axes: nature of payload, reliability, and time criticality. Nature of payload: Traffic in the network can be broadly classified as data or control traffic. Data traffic is all of the push based traffic generated by a mote. Control traffic is traffic used for control plane management (like beacons, ACK's etc.), and to a certain extent, user generated traffic. Sensor networks are more than just a collection of data gathering elements that autonomously report values. There is a need to accommodate a human element into the network for a variety of reasons. Users would want interact with the network with queries, and would want to receive responses in short turn around times. More importantly, administrators see the need to continuously customize the network with updates or network reprogramming. Interplay of data and control traffic in the network needs to be closely modeled as per a deployments requirements. Reliability: The second axis to consider is tolerance to loss. Since a deployment consists of a host of nodes that are primarily involved in data gathering, some level of redundancy is sensed values is inherent. However, dictated by application requirements, some sensed values might be loss intolerant. For example, a deployment might want to construct a time series plot of sensed values from every mote for statistical purposes. This would require every mote to reliably transfer data periodically with minimum losses. Loss intolerance is also required for network re-programming or bulk reliable transfers, where binary updates need to be transmitted to node(s) reliably over the network.