Self-Organization in Autonomous Sensor/Actuator Networks [SelfOrg] PD Dr.-Ing. Falko Dressler Computer Networks and Communication Systems Department of Computer Science University of Erlangen http://www7.informatik.uni-erlangen.de/~dressler/ dressler@informatik.uni-erlangen.de [SelfOrg], SS 2010 2-3.1
Overview Self-Organization Introduction; system management and control; principles and characteristics; natural self-organization; methods and techniques Networking Aspects: Ad Hoc and Sensor Networks Ad hoc and sensor networks; self-organization in sensor networks; evaluation criteria; medium access control; ad hoc routing; data-centric networking; clustering Coordination and Control: Sensor and Actor Networks Sensor and actor networks; coordination and synchronization; innetwork operation and control; task and resource allocation Bio-inspired Networking and Nano-Communiation Swarm intelligence; synchronization, artificial immune system; nanonetworking and nano-machines [SelfOrg], SS 2010 2-3.2
Ad Hoc Routing Overview routing protocols Proactive and reactive routing Geographical / energy-aware routing Route stability [SelfOrg], SS 2010 2-3.3
Characteristics of an Ideal Routing Protocol Requirements Fully distributed (scalability) Adaptive (topology changes) Minimum number of nodes involved for route computation Localized state (reduced global state) Loop-free, free from stale routes Limited number of broadcasts (collision avoidance) Quick and stable convergence Optimal resource utilization (bandwidth, processing, memory, battery) Localized updates Provision of QoS as demanded by the applications Typical problems (wireless networking) Node mobility Unreliable radio communication Limited energy resources [SelfOrg], SS 2010 2-3.4
Address-based routing vs. data-centric forwarding Address-based routing Directed towards a well-specified particular destination (sink) Support for unicast, multicast, and broadcast messages Topic of this chapter 7 TO:2 Data 11 1 TO:2 Data Source 15 TO:2 Data 10 2 Sink [SelfOrg], SS 2010 2-3.5
Address-based routing vs. data-centric forwarding Data-centric forwarding Forwarding of messages to all / some appropriate nodes Routing decisions according to the data, i.e. encoding rules are needed Topic of the next chapter ID: B Data ID: B ID: B Data Data Waiting for B B Source ID: B Data B Waiting for B [SelfOrg], SS 2010 2-3.6
Address-based routing vs. data-centric forwarding Routing approach Prerequisites Routing techniques Advantages Disadvantages Address-based routing Identification of a path according to the destination address of the data message Network-wide unique addresses Proactive routing (continuous state maintenance) or reactive routing (on-demand path finding) Usually low delays in connection setup and data dissemination Network-wide unique address identifiers required Data-centric forwarding Determination of the destination of a data message according to the content of the packet Pre-defined message types and semantics (probabilistic) flooding schemes or interest-based reverse routing No address information required and simplified selfmanagement and redundancy Increased overhead for single transmissions [SelfOrg], SS 2010 2-3.7
Classification of Ad Hoc Routing Protocols Routing protocols for ad hoc wireless networks Based on routing information update mechanism Based on topology information Proactive (table-driven or link-state) Reactive (table-driven) Hybrid Flat routing Hierarchical routing DSDV OLSR HSR DSR AODV DYMO ZRP Based on the use of temporal information for routing DSDV DSR AODV DYMO HSR Based on utilization of specific resources Path selection using past history Path selection using prediction Energy-aware routing Geographical routing DSDV FORP PAR GPSR DSR AODV DYMO [SelfOrg], SS 2010 2-3.8
Classification of Ad Hoc Routing Protocols Routing information update mechanism Proactive or table-driven routing protocols Reactive or on-demand routing protocols Hybrid routing protocols Use of temporal information for routing Routing protocols using past temporal information Routing protocols that use future temporal information Routing topology Flat topology routing protocols Hierarchical topology routing protocols Utilization of specific resources Power-aware routing Geographical information assisted routing [SelfOrg], SS 2010 2-3.9
Proactive Protocols DSDV Idea: Start from a +/- standard routing protocol, adapt it Adapted distance vector: Destination Sequence Distance Vector (DSDV) Based on distributed Bellman Ford procedure Add aging information to route information propagated by distance vector exchanges; helps to avoid routing loops Periodically send full route updates On topology change, send incremental route updates Unstable route updates are delayed + some smaller changes [SelfOrg], SS 2010 2-3.10
DSDV Setup: exchange of routing tables Dest Next Dist Seq 7 7 1 12 1 7 2 26 5 I am next to 5 1 7 I am 1 to 5 I am 1 to 5 I am 2 to 5 11 5 7 3 26 Routing table at node 15 I am next to 5 10 I am 1 to 5 15 I am 2 to 5 2 I am 3 to 5 Errors: update messages are created by the end of the broken link with the broken link s weight assigned to infinity () and with a new sequence number greater than the stored number for this destination [SelfOrg], SS 2010 2-3.11
DSDV Advantages Availability of routes to all destinations at all times implies much less delay in route setup Incremental updates with sequence number tags allows to adapt existing wired network protocols Disadvantages Updates due to broken links lead to a heavy control overhead during high mobility Even a small network with high mobility or a large network with low mobility can completely choke the available bandwidth exhaustive control overhead proportional to the number of nodes not scalable in ad hoc wireless networks To obtain information about a particular destination node, a node has to wait for a table update message initiated by the same destination node delayed updates could result in stale routing information [SelfOrg], SS 2010 2-3.12
Reactive Protocols DSR In a reactive protocol, how to forward a packet to destination? Initially, no information about next hop is available at all One (and only?) possible recourse: Send packet to all neighbors flood the network Hope: At some point, packet will reach destination and an answer is sent back use this answer for backward learning the route from destination to source Practically: Dynamic Source Routing (DSR) Use separate route request/route reply packets to discover route Data packets only sent once route has been established Discovery packets smaller than data packets Store routing information in the discovery packets [SelfOrg], SS 2010 2-3.13
DSR Route Discovery Procedure [1] 7 11 1 [1] 15 10 2 1 7 [1,7] [1,7] 11 15 10 [1,10] 2 [SelfOrg], SS 2010 2-3.14
DSR Route Discovery Procedure 7 11 1 10 15 [1,7,15] [1,7,11] [1,7,15] 2 [1,7,11] [2,15,7,1] 7 11 1 [2,15,7,1] Node 2 uses route information recorded in RREQ to send back, via source routing, a route reply 10 15 [2,15,7,1] 2 [SelfOrg], SS 2010 2-3.15
DSR Route cache Used to store all possible information extracted from the source route contained in a data packet Used to optimized the route construction phase Problem: stale route caches Optimizations Many nodes might know an answer reply storms Exponential backoff to avoid frequent RouteRequest packets Piggy-backing data packets on the RouteRequest Route maintenance If a link breaks, a RouteError message is sent towards the source Route construction is re-initiated [SelfOrg], SS 2010 2-3.16
DSR Advantages Reactive approach eliminating the need to periodically flood the network with table update messages Less storage and maintenance requirements Connection performs well in static and low-mobility environments Disadvantages Connection setup delay is higher than in table-driven approaches Does not locally repair broken links Stale route information may result in inconsistencies Performance degrades with increasing mobility Routing overhead is directly proportional to the path length [SelfOrg], SS 2010 2-3.17
Reactive protocols AODV Ad hoc On Demand Distance Vector routing (AODV) Very popular routing protocol Essentially same basic idea as DSR for discovery procedure Nodes maintain routing tables instead of source routing Sequence numbers added to handle stale caches Nodes remember from where a packet came and populate routing tables with that information Protocol behavior RouteRequests are flooded though the network Flooding is stopped at the destination or if an intermediate node has a valid route to the destination If a RouteRequest is received multiple times, the duplicates are discarded RouteReplies are sent back to update the path information [SelfOrg], SS 2010 2-3.18
AODV route setup RouteRequests (RREQ) are flooded through the entire network (limited by a TTL describing the maximum network diameter) 1 10 7 RREQ [1 to 2] RREQ [1 to 2] RREQ [1 to 2] RREQ [1 to 2] 15 RREQ [1 to 2] RREQ [1 to 2] 2 11 RREQ [1 to 2] RREQ [1 to 2] Node Dest Next Dist 7 1 1 1 11 1 7 2 15 1 7 2 2 1 15 3 Routing tables after flooding the RREQ [1 to 2] [SelfOrg], SS 2010 2-3.19
AODV route setup The RouteReply (REP) is unicasted towards the source RREP [2 to 1] 7 11 Node Dest Next Dist 7 1 1 1 7 2 15 2 1 RREP [2 to 1] 11 1 7 2 15 1 7 2 15 RREP [2 to 1] 15 2 2 1 10 2 2 1 15 3 Routing tables after sending the RREP [2 to 1] [SelfOrg], SS 2010 2-3.20
AODV route setup Abbreviated route setup intermediate nodes are allows to answer to a RREQ on behalf of the final destination RREP [7 to 1] 1 RREQ [1 to 15] 7 11 RREQ [1 to 15] 10 15 RREQ [1 to 15] 2 Node Dest Next Dist 7 15 1 1 Routing tables before flooding the RREQ [1 to 15] [SelfOrg], SS 2010 2-3.21
AODV route maintenance Broken links are announced by RouteError (RERR) messages with the hop count set to infinity RRER [15 to 1] 7 11 1 RRER [15 to 1] 15 10 2 [SelfOrg], SS 2010 2-3.22
AODV Advantages On-demand route establishment Destination sequence numbers to find the latest route to the destination Less connection setup delay (compared to DSR) Disadvantages Intermediate nodes can lead to inconsistent routes if the source sequence number is very old and the intermediate nodes have higher but not the latest destination sequence number Control overhead due to multiple RouteReply packets in response to a single RouteRequest Periodic beaconing leads to unnecessary bandwidth consumption [SelfOrg], SS 2010 2-3.23
Reactive protocols DYMO Dynamic MANET On Demand (DYMO) routing protocol Successor of AODV Reduced overhead in route setup and route maintenance From: A From: A From: A AODV A B C D From: D From: D From: D Path: A Path: A-B Path: A-B-C DYMO A B C D Path: D-C-B Path: D-C Path: D [SelfOrg], SS 2010 2-3.24
Geographic Routing Routing tables contain information to which next hop a packet should be forwarded Explicitly constructed Alternative: Implicitly infer this information from physical placement of nodes Position of current node, current neighbors, destination known send to a neighbor in the right direction as next hop Geographic routing Options Send to any node in a given area geocasting Use position information to aid in routing position-based routing Might need a location service to map node ID to node position [SelfOrg], SS 2010 2-3.25
Basics of Position-based Routing Most forward progress within range r strategy Send to that neighbor that realizes the most forward progress towards destination NOT: farthest away from sender! Also known as greedy routing Nearest node with (any) forward progress Idea: Minimize transmission power Directional routing Choose next hop that is angularly closest to destination Choose next hop that is closest to the connecting line to destination Problem: Might result in loops! [SelfOrg], SS 2010 2-3.26
Problem: Dead Ends Simple strategies might send a packet into a dead end [SelfOrg], SS 2010 2-3.27
Right Hand Rule to Leave Dead Ends GPSR Basic idea to get out of a dead end: Put right hand to the wall, follow the wall Does not work if on some inner wall will walk in circles Need some additional rules to detect such circles Geometric Perimeter State Routing (GPSR) Earlier versions: Compass Routing II, face-2 routing Use greedy, most forward progress routing as long as possible If no progress possible: Switch to face routing Face: largest possible region of the plane that is not cut by any edge of the graph; can be exterior or interior Send packet around the face using right-hand rule Use position where face was entered and destination position to determine when face can be left again, switch back to greedy routing Requires: planar graph! (topology control can ensure that) [SelfOrg], SS 2010 2-3.28
GPSR Example Route packet from node A to node Z Leave face routing E I B F H K A D Z Enter face routing C G J L [SelfOrg], SS 2010 2-3.29
Using virtual coordinates in WSNs Virtual ring routing (VRR) [SIGCOMM 2006] Combined overlay + underlay routing Virtual addressing Small routing tables Problems Does not ensure shortest path routing Problems with system dynamics, e.g. frequent node failures Overlay addressing does not take the physical network structure into account [SelfOrg], SS 2010 2-3.30
VCP Virtual Cord Protocol Cord setup Assignment of virtual coordinates (or positions) Initial start node S and the range [S, E] are pre-defined Local hello s are used to exchange neighborhood information Routing Greedy along the cord Exploiting neighborhood information Data storage Using application-specific hash functions to uniformly distribute data over the cord Replication either on the cord or within the local neighborhood [SelfOrg], SS 2010 2-3.31
VCP Join Requirements One node must be pre-programmed to initiate the process, i.e. its virtual address is S = 0.0 All nodes periodically (every T h ) broadcast hello messages to maintain neighborhood information and to join new nodes [SelfOrg], SS 2010 2-3.32
VCP Join [SelfOrg], SS 2010 2-3.33
VCP Join [SelfOrg], SS 2010 2-3.34
VCP Join [SelfOrg], SS 2010 2-3.35
VCP Join [SelfOrg], SS 2010 2-3.36
VCP Join [SelfOrg], SS 2010 2-3.37
VCP Routing Greedy forwarding along the Cord Always guarantees reachability for any destination Speedup by exploiting local short-cuts Node 0.25 Neighbors Successor 0.4 0.0 Predecessor 0.13 0.13 0.4 0.5 (0.55) [SelfOrg], SS 2010 2-3.38
Parameters regulating the Join Parameter, Default value Start S = 0.0 End E = 1.0 Description Lowest position on the cord Highest position on the cord Position P = -1.0 Current position on the cord (uninitialized: P = -1.0) HelloPeriod T h = 1s SetPosDelay T ps = 1s SetVPosDelay T vps = 1s BlockDelay T b = 1s Interval I = 0.1 VirtInterval I v = 0.9 Interval for the hello messages Time before re-requesting a new position Time before requesting a virtual position Blocking period to prevent assigning the same position twice Interval for calculating regular cord positions Interval for calculating virtual node positions [SelfOrg], SS 2010 2-3.39
Data Management Data storage (or push ) Using an application-dependent hash function to evenly distribute the workload among all the nodes on the Cord Storage at the node with a virtual coordinate closest to the hash value Data retrieval (or pull ) Identification of the location using the same hash function Replication Neighbors on the Cord: simplified replication mechanism Within the vicinity of the node: improved reliability [SelfOrg], SS 2010 2-3.40
Failure Management 1. Routing from 0.0 to 0.51 2. At 0.41, a route error is discovered 3. Node 0.41 knows that the destination 0.51 was a direct neighbor of 0.47, thus, it generates a NPB (no path back) message 4. The NPB message travels backwards until another possible path to 0.51 is available 5. Node 0.3 selects the second best path (via node 0.24) and forwards the NPB message 6. Node 0.24 forwards the message (again) to 0.41, which detects that there is no alternative path to 0.51 and generates a NP (no path) message 7. The NP message arrives at 0.24, which in turn forwards it as a NPB message along its second choice path to 0.69 8. Node 0.69 has an available path to 0.51, transforms the NP message back into a normal data message and forwards it via 0.61 to 0.51 [SelfOrg], SS 2010 2-3.41
Performance Evaluation Simulation using OMNeT++ Comparison to VRR According to the similar concepts, the primary competitor [SelfOrg], SS 2010 2-3.42
Path Length Grid scenario, no node failures Stretch ratio: VCP path vs. shortest path Path length: VCP vs. VRR [SelfOrg], SS 2010 2-3.43
Transmission Latency Grid scenario, no node failures Per-hop-delay in ms [SelfOrg], SS 2010 2-3.44
Transmission Latency Grid scenario, CBR, frequent node failures Per-hop-delay in ms [SelfOrg], SS 2010 2-3.45
Success Rate Grid scenario, CBR, frequent node failures Ratio of successful transmissions [SelfOrg], SS 2010 2-3.46
Ongoing Research / Project Work Optimized hash functions Even distribution of data load over the entire cord Minimized communication overhead, i.e. hashing to close neighbors Optimized data replication Neighbors on the cord Nodes in the physical vicinity Using multiple hash functions 0.0 0.25 0.5 0.75 1.0 [SelfOrg], SS 2010 2-3.47
Ongoing Research / Project Work Inter-Domain MANET Routing [MobiArch 2008, WONS 2009] Exploiting the DHT mechanism! GW VCP ID=1023 GW VCP ID=334 [SelfOrg], SS 2010 2-3.48
Energy-Aware Routing Protocols Particularly interesting performance metric: Energy efficiency Goals Minimize energy/bit Example: A-B-E-H Maximize network lifetime Time until first node failure, loss of coverage, partitioning D 3 3 A 1 B 1 4 2 2 C 2 1 Seems trivial use proper link/path metrics (not hop count) and standard routing 3 E 1 2 2 2 G 2 F 4 H 4 2 Example: Send data from node A to node H [SelfOrg], SS 2010 2-3.49
Basic Options for Path Metrics Maximum total available battery capacity Path metric: Sum of battery levels Example: A-C-F-H Minimum battery cost routing Path metric: Sum of reciprocal battery levels Example: A-D-H D 3 3 A 1 B 1 4 2 2 C 2 1 Conditional max-min battery capacity routing 3 Only take battery level into account when below a given level Minimize variance in power levels Minimum total transmission power E H 1 2 4 2 2 G 2 2 F 4 [SelfOrg], SS 2010 2-3.50
A Non-trivial Path Metric Previous path metrics do not perform particularly well One non-trivial link weight: w ij weight for link node i to node j e ij required energy, some constant, i fraction of battery of node i already used up Path metric: Sum of link weights Use path with smallest metric Properties: Many messages can be send, high network lifetime With admission control, even a competitive ratio logarithmic in network size can be shown [SelfOrg], SS 2010 2-3.51
Optimized route stability Route-Lifetime Assessment Based Routing (RABR) Frequent link failures due to node mobility reduced throughput Or, improved stability of routes reduced overhead for retransmissions Based on a new measure link affinity a nm (please note: a nm is a time!) a nm high Sthresh S Snm nm( current) ( avg ) if S nm( avg ) otherwise 0 S nm(current) S thresh δs nm(avg) current signal strength given threshold for the signal strength average of the rate of change of signal strength Optimized path according to the weakest link path affinity p x0, x1, xl min( xi, xi 1) px0, x1,..., xl a 0il [SelfOrg], SS 2010 2-3.52
Optimized route stability Dynamic power adjustment based on the link affinity Periodic exchange of Hello packets with constant power (measured S H ) Calculation of the signal strength of the transmitter (S t,t+τ ) S t, t S S S H H ( S thresh H S thresh ) a if moving farther and a if moving closer and a otherwise Calculation of the adjusted transmission power (P t,t+τ ) Sthresh Pt, t PT * St, t [SelfOrg], SS 2010 2-3.53
Summary (what do I need to know) Address-based ad hoc routing vs. data-centric forwarding Main ideas and differences Address-based path determination vs. geographical routing Proactive and reactive ad hoc routing Main ideas, commonalities, and differences Working behavior of selected routing protocols (DSDV, DSR, AODV, DYMO) Applicability in sensor networks Primary measures: scalability and performance Optimized route stability Link and path affinity Transmission power approximation according to estimated node mobility [SelfOrg], SS 2010 2-3.54
References S. Agarwal, A. Ahuja, J. P. Singh, and R. Shorey, "Route-Lifetime Assessment Based Routing (RABR) Protocol for Mobile Ad- Hoc Networks," Proceedings of IEEE International Conference on Communications (ICC 2000), vol. 3, New Orleans, LA, USA, June 2000, pp. 1697-1701 K. Akkaya and M. Younis, "A Survey of Routing Protocols in Wireless Sensor Networks," Elsevier Ad Hoc Network Journal, vol. 3 (3), pp. 325-349, 2005 A. Awad, C. Sommer, R. German, and F. Dressler, "Virtual Cord Protocol (VCP): A Flexible DHT-like Routing Service for Sensor Networks," Proceedings of 5th IEEE International Conference on Mobile Ad-hoc and Sensor Systems (IEEE MASS 2008), Atlanta, GA, September 2008, pp. 133-142 M. Caesar, M. Castro, E. B. Nightingale, G. O'Shea, and A. Rowstron, "Virtual Ring Routing: Network routing inspired by DHTs," Proceedings of ACM SIGCOMM 2006, Pisa, Italy, September 2006 G. Di Caro, F. Ducatelle, and L. M. Gambardella, "AntHocNet: An adaptive nature-inspired algorithm for routing in mobile ad hoc networks," European Transactions on Telecommunications, Special Issue on Self-organization in Mobile Networking, vol. 16, pp. 443-455, 2005 D. B. Johnson and D. A. Maltz, "Dynamic Source Routing in Ad Hoc Wireless Networks," in Mobile Computing, vol. 353, Imielinski and Korth, Eds.: Kluwer Academic Publishers, 1996, pp. 152-181 B. Karp and H. T. Kung, "GPSR: Greedy Perimeter Stateless Routing for Wireless Networks," Proceedings of 6th ACM International Conference on Mobile Computing and Networking (ACM MobiCom 2000), Boston, MA, 2000, pp. 243-254 M. Mauve and J. Widmer, "A Survey on Position-Based Routing in Mobile Ad-Hoc Networks," IEEE Network, vol. 15 (6), pp. 30-39, 2001 K. Paul, S. Bandyopadhyay, A. Mukherjee, and D. Saha, "Communication-Aware Mobile Hosts in Ad-hoc Wireless Network," Proceedings of IEEE International Conference on Personal Wireless Communication (ICPWC 1999), Jaipur, India, February 1999, pp. 83-87 C. E. Perkins and P. Bhagwat, "Highly Dynamic Destination-Sequenced Distance-Vector Routing (DSDV) for Mobile Computers," Computer Communications Review, pp. 234-244, 1994 C. Perkins and E. Royer, "Ad hoc On-Demand Distance Vector Routing," Proceedings of 2nd IEEE Workshop on Mobile Computing Systems and Applications, New Orleans, LA, February 1999, pp. 90-100 C. Sommer, I. Dietrich, and F. Dressler, "Simulation of Ad Hoc Routing Protocols using OMNeT++: A Case Study for the DYMO Protocol," ACM/Springer Mobile Networks and Applications (MONET), Special Issue on Simulation Techniques & Tools for Mobile Networking, 2009 (to appear) [SelfOrg], SS 2010 2-3.55