A structured overlay for MANETs and the "Freemote" system emulation framework

1. A structured overlay for MANETs and the "Freemote" system emulation framework Raphaël Kummer University of Neuchâtel http://iiun.unine.ch

2. Structured P2P overlay: DHT P2P overlay Hash function provides: Nodes ID Item key Logical neighbors + long-range neighbors Multi-hop lookup (greedy routing) Limited degree/diameter graph 000 111 001 110 010 101 011 100 3

3. On Reliability • DHTs are inherently reliable • No central control, self-stabilizing algorithms • Failed nodes are replaced by live nodes • There are multiple paths from a source to a key • Applications • Service location • Content distribution • File sharing • Multicast in MANETs • ……. See also:Aspnes et al. Greedy routing in peer-to-peer systems (2006).

4. Mobile ad-hoc networks • Ad-Hoc network characteristics: • Direct communication only with physical neighbours (radio range) • Communication between remote nodes must traverse multiple intermediate nodes (expensive) • 1 logical hop = multiple physical steps • Non-member nodes have to relay messages • Limited energy • Participating nodes may move Minimize length of physical paths 5

5. Classical DHTs 000 111 001 110 010 101 011 100 • Why not directly applying CHORD? • Logical neighborhood ≠ physical neighborhood • Total # physical steps grows linearly with # logical hops • High network load to maintain logical long range links (Chord fingers) 000 011 110 101 111 100 010 001 6

6. Considered network • Network assumptions: • Two-dimensional Euclidean space • Nodes with given position • Random mobility scheme: • Moving speed: • Randomly chosen in the interval 0 ≤ S≤ 2 m/s • Random direction during a finite time t. • Network is connected • AODV Routing protocol • Path lifetime = 3 seconds 7

7. Basic protocol 6 11 6 12 11 12 7 7 5 9 9 5 3 3 4 4 1 1 2 2 10 10 8 8 ⇒Discover logical long-range links in physical neighborhood of nodes ⇒ Build minimalist overlay without long-range neighbors 8

8. Basic protocol – main ideas • Always forwards requests towards node closest to the key • Long-range links are cheap (1 physical step) • If a better way exists at some intermediate node • Message sent to remote node might diverge from its original path • The algorithm converges 9

9. Basic protocol - the algorithm • At each node do: • Find the node nj whose ID is closest to key k in • {Self  Logical neighbors  Physical neighbors Next logical hop } • Else if nj physical neighborhood • Send request to physical neighbor nj • long-range link • Else if nj logical neighborhood • Send request to next node on physical path to nj • Else nj= Next logical hop • Send to next node according to the ad-hoc routing protocol 10

10. Basic protocol 11

11. Basic protocol Find a physical shortcut Start of logical path Better way found: change of route End of a logical path Destination of the request Origin Of The request Logical Path 12

12. Neighbors of neighbors (I) • Visibility of nodes limited by communication range • Nodes can exchange information about their physical neighborhood • Extended visibility ⇒ more logical long-range links • Limited cost (message overhead) 13

13. Neighbors of neighbors (II) 14

14. Caching and listening • Exploits knowledge from previous requests • Caches path information on nodes • A node sends a request • All the nodes in its physical neighborhood: • Can listen • Can obtain routing information • (target key, target node, next node) • Negligible communication overhead • Cache entries lifetime = 3 seconds (max 256 entries) • Reactivation if used 15

15. Caching and listening 16

16. Experimental setup • Simulation parameters: • Network size: 1,000 (1K); 5,000(5K) nodes • Average connectivity: 13-16 nodes • Lookup requests: 2,000 randomly generated requests • Mobility: 0 ≤ speed ≤ 2 m/s in random direction during a finite time • Steady state: • 2000 (2K) requests to reach a steady state when using cache • No churn • Algorithm evaluated: • Basic • Neighbors-of-neighbors (NoN) • Cache (C) • Warm-up (Wup) 17

17. DHT results Average use of logical shortcuts 18

18. DHT results 19

19. DHT results 20

20. DHT results 21

21. DHT - conclusion • Maintain minimalist logical overlay structure • Rely on physical neighborhood • Enhancements are very effective • Scalable • Supports well mobility 22

22. Multicast in ad-hoc networks

23. Introduction Why multicast trees in ad-hoc networks? Efficient information distribution to a subset of nodes (group) [Multicast] Efficient use of the network [Multicast and tree] No cycles Avoids redundant and unnecessary communications Minimize the overhead [Multicast and tree] Scale with the network size [Tree] Need to efficiently locate the source to Connect to the tree Multicast messages 24

24. Multicast Relay node Internal member Tree root Leaf member 25

25. Goals • Goals • Tree structure close to the “physical topology” • Small degree tree • Minimize: • The number of non-members implicated • The relative physical distance between nodes • Maximize the number of member relays [Tree nodes] • Efficiently: • Locate a tree root [DHT] • Connect to an existing tree [DHT] • Consider ad-hoc networks characteristics 26

26. The connection algorithm (I)‏ • Lookup in the DHT a key associated with a multicast group (group name) • When a node receives a request: • If the node is a member of the group: • Proposes itself as potential parent to the connecting node and • Forwards the request to next node on lookup path • Otherwise (it is not a member): • Forwards the request to next node on lookup path • At least one node (the source) answers 27

27. The connection algorithm (II) • The requester accepts the first connection proposal • When receiving a subsequent proposal • Accept if: • No multicast messages already received • And • New distance to parent < old distance to parent and new distance to source ≤ twice old distance to source • Or • New distance to parent = old distance to parent and new distance to source < old distance to source • Decline otherwise 28

28. Basic algorithm - example 29

29. Ext.#1 – at lookup time Situation is better but the tree could be closer to the “physical topology” During join, members listen and propose themselves as parent 31

30. Ext.#2 – at multicast time When sending messages, try to identify common subpaths and reconnect members to better parents 32

31. Ext.#3 – at multicast time Prevent nodes from receiving duplicate messages when acting both as member and relay node in a tree 33

32. Ext.#4 – at multicast time • Observations: • As communication is broadcast each node can listen. • Nodes can gather the information. • Idea: • The source intermittently allows nodes from a branch to use this information • The nodes : • Determine the worst case (worse physical distance) in the valid listened messages • Propose to the addressee to become its parent. 34

33. Experimental setup • Simulation parameters: • Network size: 1,000 (1K); 5,000(5K) nodes • Average connectivity: 13-16 nodes • Multicast member: 10% of all the nodes • Mobility: 0 ≤ speed ≤ 2 m/s in random direction during a finite time • DHT steady state: • 100 requests to reach a steady state when using cache • No churn • Algorithm evaluated: • Basic • Ext #1: During join, members propose themselves as parent when applicable • Ext #2: Common sub-paths identification • Ext #3: Avoid nodes acting both as member and relay node. • Ext #4: Multicast message listening to propose new connections. 35

34. Multicast tree results 36

35. Multicast tree results 37

36. Multicast tree results 38

37. Multicast tree results 39

38. Multicast tree results 40

39. Conclusion • Minimize the number of non-member implicated • Short inter-node paths • Multicast load balanced between member nodes • Scalable approach – results close in different network sizes. • DHT benefits the tree structure. • No flooding, no centralization • Able to maintain a good tree structure with mobile nodes 41

40. FREEMOTE A lightweight Java-based wireless sensors networks emulation system

41. Wireless Sensor Networks A few to 1000’s of MOTES MOTE: Base system CPU RadioIC Operating System Sensors Operating Systems TinyOS (NesC or C)‏ Contiki JavaVM Examples of MOTES: Berkeley Motes MICAz (Crossbow)‏ TMotes (Moteiv/Sentilla)‏ Other “custom” motes: e.g., JMotes (EIA-FR)‏ 43

42. Problems Specialized, complex programming languages NesC Virtual machines for specific applications: Maté SwissQM WSN with 1000’s nodes Impracticable for testing 44

43. Solution approach and requirements Emulation Based on well-known high level programming languages Decrease development time Decrease complexity To verify implementations Simulation Better control the environment Testing large scale deployments Testing different scenarios Compatible with standards Fully configurable infrastructure 45

44. Existing tools Motelab Fixed network of Berkley motes Close to reality Small number of nodes (<190)‏ Avrora – ATEMU AVR processors, MICA2 platform NesC, assembly Gdb-like debugging Interface TOSSIM TinyOS mote simulator Mobile / static complex scenarios NesC SENS C++ development – application can be ported to Berkeley Motes No communication between real and emulated nodes. MEADOWS Distributed emulation No real nodes included Focus on behaviour analysis 46

45. Freemote: idea 47

46. Features Real and emulated nodes at same times Bridge connects emulated and real nodes Distributed emulation system Layered architecture Topology manager Intuitive GUI Fully configurable system Simulation of network topologies Run directly from website 48

47. Architecture I 49

48. Architecture II 50

49. Architecture III Java Java Java Java, NesC, or C Java, NesC or C 51

50. Let’s go inside! Three layers (Appl. - Routing - DL&PHY)‏ Dynamically loaded (XML configuration file)‏ Interfaces between layers (Multiplexer/demultiplexer)‏ Topology manager: Client-server design Manages emulated nodes Mobility Physical topology Churn 52