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

Raphaël Kummer

University of Neuchâtel

http://iiun.unine.ch

33

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

101100

011

010

001

110

111000

4

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).

55

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

66

001

Classical DHTs

◆ 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)

101100

011

010

001

110

111000

000

010

011

100101 110

111

77

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

88

12 11

10

9

8

76

5

43

21 2

Basic protocol

1

5

6

3

7

8

410

11

9

12

⇒ Build minimalist overlay without long-range neighbors⇒Discover logical long-range links in physical neighborhood of nodes

99

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

1010

◆ 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 n j

► Else nj= Next logical hop

► Send to next node according to the ad-hoc routing protocol

Basic protocol - the algorithm

1111

Basic protocol

1212

Basic protocol

Origin Of

The request

Find a physical shortcut

Start of logical path

Logical Path

Better way found:

change of route

End of a logical path

Destination of the

request

1313

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)

1414

Neighbors of neighbors (II)

1515

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

1616

Caching and listening

1717

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)

1818

DHT results

Average use of logical shortcuts

1919

DHT results

20

DHT results

20

21

DHT results

21

2222

DHT - conclusion

◆ Maintain minimalist logical overlay structure

◆ Rely on physical neighborhood

◆ Enhancements are very effective

◆ Scalable

◆ Supports well mobility

Multicast in ad-hoc networks

2424

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

2525

Multicast

Relay node

Tree root

Leaf member

Internal member

2626

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

2727

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

2828

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

2929

Basic algorithm - example

3131

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

3232

Ext.#2 – at multicast time

When sending messages, try to identify common subpaths and reconnect members to better parents

3333

Ext.#3 – at multicast time

Prevent nodes from receiving duplicate messages when acting both as member and relay node in a tree

3434

Ext.#4 – at multicast time

► Observations:1. As communication is broadcast each node can listen.2. Nodes can gather the information.

► Idea:1. The source intermittently allows nodes from a branch to use this

information2. The nodes :

» Determine the worst case (worse physical distance) in the valid listened messages

» Propose to the addressee to become its parent.

3535

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.

3636

Multicast tree results

3737

Multicast tree results

3838

Multicast tree results

3939

Multicast tree results

4040

Multicast tree results

4141

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

FREEMOTE

A lightweight Java-based wireless sensors networks emulation system

43

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)

44

Problems

◆ Specialized, complex programming languages► NesC

◆ Virtual machines for specific applications:► Maté

► SwissQM

◆ WSN with 1000’s nodes► Impracticable for testing

45

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

46

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

47

Freemote: idea

48

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

49

Architecture I

50

Architecture II

51

Architecture III

Java Java Java Java,NesC,or C

Java,NesCor C

52

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

53

Let’s go inside!

◆ Communication:► Real nodes:

► CC2420 radio Chip

► IEEE 802.15.4 standards

► Emulated nodes:► Simulate IEEE 802.15.4

► Promiscuous mode

– (receive every message sent by physical neighbors)

► Simulate radio channel errors

54

Develop for Freemote

◆ Abstract class ch.unine.application.ApplicationPack► Provides an access to send and receive messages at routing and DL&P

layers► Send methods are provided

► Receive methods need an implementation

► An application must register listeners for each message label it should receive

◆ Each emulated node runs in a separated thread► Implements the ApplicationPack's run method with your active code

55

Develop for Freemote

56

Run your application

◆ An XML file contains the setups for every type of nodes and roles.► Layer implementation selection, mobility model, simulation environment and

input & output modalities

◆ User friendly GUI► System and emulation configuration

► Configuration file abstraction

► Edit, save and load configurations

► Start the emulated nodes

◆ Command line also available

57

Run your application

58

Watch your application

◆ Shows► All the emulated nodes

► The communication range (grey circle)

► The topology

► Standard output

► The status LEDs (8 with configurale text)

◆ Slow down execution► Helps to understand the

application behavior

59

Watch your application

60

Reality point of view

61

Conclusions

◆ 10’000 nodes emulation system

◆ Java Mote emulation system

◆ Same code runs on emulated nodes and JMotes (EIA-FR)

◆ ZigBee compatible (e.g., Berkeley motes)

◆ GUI

◆ Run directly from website (Java Web Start)

◆ Free code source:

◆ http://mote.tic.eia-fr.ch/freemote/

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

Joint work with:

Raphael Kummer, Thimothée Maret, Pascal Felber, Jean-Frédéric Wagen

http://iiun.unine.ch