Self-managed Content-based Routing for ...

12th IFIP/IEEE International Symposium on Integrated Network Management 2011

Self-managed Content-based Routing for Opportunistic Networks Javier Baliosian, Jorge Visca, Matias Richart, Guillermo Apollonia, Leonardo Vidal, Martin Giachino and Eduardo Grampin School of Engineering, University of the Republic, Montevideo, Uruguay. Email: {javierba.jvisca.mrichart.lvidal.giachino.grampin}@fing.edu.uy

Abstract-Several countries such as Uruguay and Brazil are implementing the well-known One Laptop Per Child Program (OLPC) by which every child that assists to the primary school obtains in property a laptop with wireless capabilities. They carry their laptops from home to school and back every day and, as seen in the experience, they also carry their laptops to parks, community centers etc. This provides a wide platform for the deployment of Disruption Tolerant network applications. This paper presents a self-managed, opportunistic and content-based routing protocol that supports a network of environmental sensors implemented using consumer-grade wireless routers working together with OLPC laptops. We evaluate the impact of the density, diversity and connectivity of the mobile network on the performance of the protocol and we show how it self-configures it parameters to adapt to changing network conditions.

Fig. 1.

I. INTRODUCTION

The DEMOS Project

networking applications.

While it is true that communication networks have grown

The work presented in this paper has been developed in

in coverage, bandwidth and reliability, reaching unexpected

the context of the DEMOS project (Domestic Environment

domains, places and publics, it is also true that there are

Monitoring with Opportunistic Sensor networks). DEMOS

still some application domains that operate on disconnected

takes advantage of the OLPC-like programs to develop a low­

networks by nature (e.g., sensor networks), and regions of the

cost platform for environmental sensors, such as air-quality

world with little or no communications infrastructure at all.

sensors, that are deployed at the living premises of children in

For these situations the research community has been working

environmentally vulnerable neighborhoods as well as at their

on network protocols that are tolerant to delays or disruptions

schools, parks, etc. The environmental data collected by

storing and forwarding messages when and how it is possible. Variations of this kind of networks have been called Delay

those sensors are

transmitted, using opportunistic networking techniques, to the

Tolerant Networks, Disruption Tolerant Networks (DTN) or

children's laptops as they pass-by during their daily life. Later,

Opportunistic Networks (ON), we will use this one in the

at school, using the same techniques, the data is transmitted

believe that is which better describe the case. The basic concept

into the local school server and from there to an environment

of opportunistic networking is that, in the absence of a fixed

monitoring station using the Internet (see Figure 1). This

connectivity infrastructure, some data of interest is transferred

monitoring station may be operated by governmental or non­

between mobile devices using the "connection opportunity"

governmental, community-based organizations. Some other

that arise whenever mobile devices happens to come into the

details of this project can be seen in previous work: [3] focuses

range of other devices because of the mobility of the users.

on the footprint of the solution and [4] in a mobility model

Developing and vast countries are, typically, places where the

developed to test the idea.

mentioned lack of infrastructure is more evident. Fortunately,

When dealing with an unplanned network of devices, such as

some of those countries are also implementing variations of the

the DEMOS sensor network, to maintain an inventory contain­

One Laptop Per Child Program (OLPC), for example Uruguay

ing addresses and configurations, setups, software updates, etc.

has the "Plan Ceibal" [1] and Brazil the UCA program [2]

of such devices adds an operational cost to the management

(Uruguay has already covered the entire 6-12 y ear-old popu­

of that network that may not worth the effort. Moreover,

lation of the country). The above programs provide a wireless

without such an inventory, configuring and reconfiguring each

capable laptop to every child in a primary school. Besides

sensor to adapt to changes in the interests of the operators and

carrying the laptops to school everyday, children frequently

users of the network or to changes in its design may be an

keep the laptops with them when going to parks, community

impossible task. In this context, content-based routing appears

centers, etc. This provides a wide platform for opportunistic

as an interesting solution. Unfortunately, there are very few

978-1-4244-9221-31111$26.00 ©2011 IEEE

121

works on that kind of networks, most of them by Carzaniga et al. (see for example

[5][6][7]), which we used as some [8] but not

Opportunistic Network

inspiration. There is also some pioneering work in

designed for wireless networks, and some additional work in

[9]. ONs -as opposed to infrastructure networks- are built on­ the-fly by mobile, intermittently connected ad-hoc nodes, al­ lowing to run delay tolerant applications. Many ON routing

[10] for a comprehensive

«

review, but the common idea is always to store the message,

....I

algorithms have been proposed, see

'5

EP

PDP

to carry it for some time, and to forward it when a suitable mobile node happens to be in range with the hope that, after some of these store-and-forward steps, the message will eventually arrive to its destination. In these conditions, the throughput and delay induced by the routing protocol depend on the network characteristics (number of nodes, movement patterns), data flow characteristics (load, data patterns) and how the parameter of the routing protocol adapt to such a network environment. Usually, those network attributes are highly dynamic and hard to predict. Some analysis can be done

PIC-18/AVR ·

through models and extensive simulation, but fact remains that to optimize the performance of unplanned sensor networks,

·

r

·r

/

/

r

/ Sensor

Sensor

the configuration parameters should be ideally adapted to the environment at runtime. This makes a strong case for a self­

Fig. 2.

Architecture of

a

DEMOS sensor node

managed ON routing protocol, however none of the content­ based ON protocols mentioned above present self-management

is collected and relayed to a central Management Station

features.

through the Internet.

This paper presents a self-managed, disruption-tolerant and

•

content-based routing protocol to support the DEMOS project,

Carriers. These are the mobile nodes that relay informa­ tion from the Sensors to a Collector in an opportunistic

with special emphasis on its self-managed aspect. We evaluate

fashion. Usually these are XO laptops owned and there­

the impact of the density, diversity and connectivity of the

fore carried around by children.

mobile network on the performance of the protocol and we

•

Management Station. All data is summarized and ana­

show how it self-configures it parameters to adapt to changing

lyzed here. Additionally, the DEMOS management rules

network conditions.

are edited, compiled and deployed from this node.

The structure of the paper is as follows. A high-level de­ scription of the DEMOS system is presented in Section II. The

A. Common Node Architecture

opportunistic protocol RON that supports DEMOS is described

The general architecture of a DEMOS sensor is depicted in

in Section III. Later, in Section IV-E, we shortly motivate the

Figure

need of including self-management capabilities to ON nodes.

in detail in Section III and a general purpose Policy Agent

Finally, in Section IV , the paper presents an evaluation of RON

called LuPA, designed and described in previous work

based on simulations.

are responsible for the opportunistic routing of messages. They

2. RON, a ON routing protocol that will be described [11],

must be available on all edge and mobile nodes participating II. THE DEMOS SYSTEM

in the ON.

To support the DEMOS project we have developed the DEMOS system. The DEMOS system is a policy-based, self­ managed system that consists of a set of services deployed on many network devices or nodes. Depending on which services are deployed on a node it falls under some of the following categories: •

•

RMoon is a programmable,

general purpose monitoring

service developed together with LuPA, that is responsible for collecting and issuing sensor data publishing it via RON. RMoon can be configured to issue notifications under certain conditions. Those conditions can be set on the value of a sensor variable, its rate of change, or the deviation from last reported value.

Additionally, time-based notifications can be set. In

Sensors. These are the nodes that collect environmental

order to support external sensors, RMoon was extended to

data. They are usually fixed to a place, and they have

interface with a microprocessor software framework developed

[12]. USB4ALL is

attached sensing hardware. Different nodes can have dif­

by our research group, called USB4ALL

ferent sensing hardware attached.

a modular firmware that provides a high level communica­

Collectors. These nodes are usually placed at schools, and

tion mechanism. It allows the controller to discover installed

are the recipients of data generated by Sensor nodes. Data

modules, load and unload them at runtime, and query them

122

through an RPC-like mechanism. Originally developed for the Microchip PIC-18 series of microprocessors, it has been also ported to AVR based Arduino platform. To interface with USB4ALL, a library called Lubot (also written in Lua) has been developed. A DEMOS mobile node have only RON and LuPA installed. LuPA is also responsible for the self-management tasks in the DEMOS system. Later, Section I V will describe how LuPA self-configures RON to adapt to the changing network conditions. LuPA also decides what and when sensor data must be collected and issued. A requirement for our solution was the need to be deployable on a diverse set of hardware and software platforms. It ranged Fig. 3.

from Desktop PCs for central data collecting nodes, to embed­

The Sensor Prototype

ded platforms such as wireless routers. The intermediate nodes included different platforms such as OLPC XO laptops and

in a given moment. For a message to reach its target, it may

Intel's Classmate netbooks, running several flavors of Linux

be necessary that some node keeps it in his own memory until

and Windows Operating Systems. At the same time, sensor

it can deliver it to some other node.

nodes have to interface with the actual sensor hardware. In

There are several methods and algorithms for Opportunistic

addition to all this requirements, the system needed to be tested

Routing, but for the purpose of supporting DEMOS operations

and tuned before its deployment, therefore it was needed to run

we developed RON, a new protocol. The reasons for creating

it also on a simulated platform.

a new protocol were:

To fulfill all those requirements, we developed the prototype

•

with Lua [13 ], a compact virtual-machine based dynamic

Usually, opportunistic routing algorithms are intended for destination targeted routing. On the other hand, Content­

language, with great emphasis on extensibility and a very small

based routing provides us of several advantages: as spec­

footprint, and can be run in an wide spectrum of platforms

ifying a data flow does not rely on having an inventory

down to embedded micro-controllers. Additionally, the small

of the network devices, the deployment is simpler; uni­

footprint of the Lua virtual machine allows us to simulate

cast, multicast and broadcast messaging gets naturally

reasonably large networks.

represented; the messages can be dynamically prioritized,

For the deployment in place of real environmental sensing

assigned destination, etc., based on properties such as type

hardware a general purpose microprocessor board was used,

of sensor represented, its danger level, or geographical

the PICDEM FS USB [14] demoboard. This is a board for

distribution. All this rich behavior can be changed at

prototyping systems based on a Microchip PIC-18 micropro­

runtime without changing configuration of any node on the network, providing greater flexibility.

cessor. This platform was selected on the grounds of low cost and availability on the local market. Nevertheless, our software

•

has been also ported to the AVR family of microprocessors.

Many gossip-based algorithms operate on a Peer-to-peer basis, where each link is considered isolated from the rest.

The sensor hardware is a Figaro T GS sensor, a type of thick

On the other hand, we deal mainly with wireless networks,

film metal oxide semi-conductor which offer low cost, long

were all the nodes in range share the medium and can

life, and good sensitivity to target gases while utilizing a simple

listen to the messages independently of their addressing

electrical circuit. For the embedded platforms of our tests

at the network layer (the "broadcast advantage"). Our

(consumer grade wireless routers such as Linksys WRT54GL

routing algorithm attempts to use this property to reduce

and Asus 520gu), we have used OpenWRT [15], a Linux

the number of retransmits.

distribution for embedded devices. See the sensor prototype

•

The few content-based opportunistic routing algorithms that exist (see Section I) where not designed to be self­

in Figure 3).

managed and we wanted to show the benefits of such a

As a result, we developed a ON-based communications

feature.

platform, a general purpose decision engine, and a monitoring software in a high level scripting language, which can run

Compared

to

a

classical

D TR

algorithm

such

as

unmodified on a PC, a wireless router, or a networking

PRoPHET[16], on which RON was inspired, our protocol has

simulator.

two main differences. First, the destinations are not nodes (as in destination rout­

III. A CONTENT-BASED OPPORTUNISTIC ROUTING

ing) but subscriptions, i.e., just as a packet is targeted to a

PROTOCOL

node if the packet's destination IP address matches the node's

The DEMOS architecture implies the existence of an op­

IP address, a RON notification is targeted to a Subscription if

portunistic network between the sensor devices and the data

it satisfies its filter. This implies a distinction between node's

collection points. In an opportunistic network, there is no

addresses (its subscriptions) and its identifier (its unique id).

guarantee of existence of a path between any pair of nodes

123

Second, RON relies on broadcast messages. When a message

is sent, it is not targeted to some particular node in the network.

SUBSCRIBE subscription_id=sid123 subscriptor_id=collectorl FILTER mib=temperature value > 35 END

All nodes listen to all messages in the medium, and how they react to them depends on their internal state. Technically,

RON is a gossiping algorithm.

Each node

maintains a table of accessible one-hop destinations, and a quality associated to each of those. The quality of a destination represents how good is the node to reach that destination.

(a)

Nodes periodically exchange their destination lists with their associated qualities (this list is known as a "view"), and update that control the behavior of the protocol. While usually those values are fixed at configuration time (as in PRoPHET), we use a rule engine to adjust those parameters at runtime. The subscription is composed of two parts, the header and the filter. The header contains general information, like a unique Subscription identifier and the identifier of the node

(b)

subscribing. The filter specifies a set of conditions. When a

field. If a notification does not contain that field, the given expression is considered satisfied. In other words, a notification fails a filter only if it contains a field which fails some condition of the filter. In the example of Figure

A

Noti fication.

The Messages of the Notification Bus

Fig. 4.

notification matches the conditions of a subscription it must be delivered to the subscriber client. Each condition is of the

Subscription.

NOTIFICATION notification id=notif123 source=sensor nodel message_type=trap watcher_id=watch_temp mib=temperature value=36.5 END

their own qualities in the process. There are several parameters

form attribute-operator-value, where attribute is a notification

A

RON can produce a subscription, then, RON broadcast the subscription in an ad-hoc manner to all the nodes in the vicinity and they register and forward those subscriptions causing a controlled flow that potentially ends with all the nodes having

4, the subscription will registered the subscription. However, the time for which a

match any notification with a payload of a temperature over 35 (whatever sensor node originates it). In this subsection, we describe the design goals of the protocol, the design principles that are behind the realization of the protocol, and we give a description of the protocol, which includes assumptions, the node state, the message types, and the pseudocode.

subscription is stored in a node depends on how often it

is received (the details are described later in Section III-F). When any node issues a notification it broadcast a message containing a list of key/value pairs to the nodes in the vicinity. Those nodes receive the notification and try to match its content against the subscriptions that the node has registered. If the notification matches any subscription, the node stores the message and waits until it is in the vicinity of other nodes.

A. Design Goals

The process repeats until the notification arrives to all the nodes

The functional goal of the RON protocol is to forward

interested on it.

notifications from any node in a network of mobile nodes that may or may not be continuously connected- to all the nodes that have issued those subscriptions that match the

D. Node State

notifications being forwarded. Notifications are typically short text messages such as those shown in Section III that carry sensor-configuration data, policy-rules and sensed data. In terms of performance, the RON protocol is not designed to carry critical information, it tolerates high communication delay, in the order of hours or days. Another RON goal is that the protocol's traffic and computational overhead must scale with both, the number of nodes in the network and the number of messages being forwarded.

Subscriptions Table:

this is the table of received subscrip­

tions. Each entry has the format

(i, J, q, t)

where

32-bits integer that identifies a subscription,

J

i is a random is a variable­

length text field with the subscription filter as described above, q is a Float number in the

[0,1]

range that indicates the current

quality of the subscription (being

1

the best quality), and

t

is

the local time-stamp of the last time that the entry was updated. The Subscriptions Table at node j is represented as

Sj in the

pseudocode.

B. Design Principles

Notifications Table:

The principles driving the RON protocol design were (i) flex­

ibility to carry data with different, even unforeseen, purposes,

this is the table of received notifi­

cations. Each entry has the format where

i

(i,p, t, tlastseen, treceived) p is a

is a 32-bits integer that identifies a notification,

and (ii) self-management to adapt its parameters to a highly

variable-length text field with the notification key/value data as

dynamic network environment.

described above,

C. Protocol Overview

is the number of times that the notification

tlastseen

is the time-stamp

of the last time that the notification was seen by the local

RON is a publish-subscribe protocol with only two types of messages: subscriptions and notifications. Both types are plain-text multi-line strings (see Figure

t

was broadcast by the local node,

4). Any node running

node and

treceived

is the time-stamp of the first time that the

notification was received by the local node. The Notifications

Table at node j is represented as Nj in the pseudocode.

124

E.

Types of Messages

Subscription Message: this message is a tuple sub(id, filter, quality) used to communicate which notifications should be routed to a node, where id is a random 32-bits integer that identifies the subscription, filter is a variable-length text field with the filter described above, and quality is a Float number in the [0,1] range. Notification Message: this message is a tuple n(id, values) used to communicate data, where id is a random 32-bits integer that identifies the notification and values is a set of pairs

Process 1 RON Protocol: Control Cycle 1: IIInitialization 2: 3:

=

=

4: new thread Process 2; IIStarts Process 2 in parallel 6: loop every 7: 8:

q' if

12: 13:

the periodic processing and subscriptions issuing, and another

14:

one for the processing of incoming messages.

15:

RON Process 1 is a loop that is executed every

T

if teurrent

11:

The pseudocode of RON protocol is shown in Figure 5, and,

seconds

E

Sj

do

Ilif entry not updated during last cycle

10:

as its implementation, it is divided in two processes: one for

T

broadcast(Sj) for all (i,j,q,t)

9:

Pseudocode

{} IISubscriptions Table {} I/Notifications Set

5: IIControl cycle

key/value.

F RON

Sj Nj

=

q

- t 2:

X

T

then

GT

q' 2: minq then replace (i,j,q,t)

by

(i,j,q',te)

else remove

(i,j,q,t)

from

Sj

seconds.

In this process, the data structures, at lines 2 and 3, are a list for subscriptions, and a array with

N

slots for messages.

The subscriptions are broadcast in 7. The subscriptions table associates a "quality" °

:s; q :s; 1

Process 2 RON Protocol: Processing of Incoming Messages I: loop

to each subscription that

changes over time. The older they are, the lower is the quality (lines 11 and 13). When this quality drops bellow

minq

the

which does not have an equivalent in RON.) RON Process 2 is in charge of processing incoming mes­

If it is not, inserts the subscription in the table and time­

stamps it with the current time at the node. If the subscription is already in the Subscriptions table, RON recomputes its quality following the equation in line 8. Because of this, every time a subscription is seen again, its quality improves in a value that depends on the quality of the received copy. When a notification is received (line 17), RON checks if it was received before (line 18). If the notification was not received before and the Notifications Table has an empty space, it is inserted in the table. If the Notifications Table has not an empty space and the notification with the lowest quality

Q(p)

in the table has

also a quality that is lower that the received notification, it is removed and its space used (lines 21 to 23).

Q(p)

is the

accumulated quality from all subscriptions that match a given set of values

G.

Some

p.

RON

m if

6:

exception that PRoPHET has another rule for transitive quality,

4).

if

5:

rules are derived from the PRoPHET algorithm, with the

sages. When a subscription is received (line 3, RON checks

wait for next message

3: 4:

subscription is removed (line 15). (The aging and reinforcing

if the subscription is already in its Subscriptions table (line

2:

m sub(i,j,q) then �t,q' I (i,j,q',t) E Sj if ISjI :s; maxs then put (i,j,q,te) in Sj is

7:

else

8:

q'+(1 - q') x q x P (i,j,q',t) by (i,j,q",te) for all (i,p,r,tis,tr) E Nj do true then if j(p) if r < maxr then broadcast(n(i,p)) replace (i,p,r,tls,tr) by (i,p,r+1,tls,tr)

9: 10: 11: 12: 13: 14:

q"

=

else

16:

replace (i,p,r,tis,tr) by (i,p,r,tis,tr) m is n(i,p) then �r,tls,tr I (i,p,r,tls,tr) E Nj then if INjl :s; maXN then put (i,p,0,te,te) in Nj else if Q(p) > Q(p')I(i,p',r,tl,t2) E Nj then remove (i,p,r,tl,t2) from Nj put (i,p,0,te,te) in Nj

17:

else if

18:

if

19: 20: 21: 22: 23: 24: 25:

=

replace

15:

Implementation Details

then

else replace

Fig. 5.

(i,p,r,tis,tr)

by

(i,p,r,te,tr)

Pseudocode for RON Protocol on Node j

There are several implementations hacks that are not de­ scribed in the pseudocode for the sake of simplicity. For exam­

keep the protocol at the IP layer for flexibility, all the traffic

ple, RON takes the "broadcast advantage". While in traditional

for the opportunistic support is encapsulated in broadcast UDP

gossiping algorithms is the responsibility of the emitter to

packets on a default port.

select the recipients for its messages, in our implementation

Another non-trivial problem is time-stamping of messages.

the only decision that the emitter makes is whether to emit. Is

As sensor and mobile nodes do not have reliable clocks and the

responsibility of the listener to decide whether they accept the

transit time through the network is highly variable, it is difficult

messages, and thus become the receiver. To this effect, and to

to know when exactly the notification was produced. Our

125

solution is to add a

in_transit

=

0 field to the notifications

J...XK m

at the creation moment. Subsequently, each node registers the time it received the notification, and, upon transmission, increments the

in_transit field with the time elapsed in transit. in_transit field stores the total

Upon reaching destination, the

time that the message circulated through the network, and the creation time relative to the local clock can be computed. The

,

,

precision of this method degrades over the number of hops, but it can be enough for our non time-critical purposes. Additionally, special care is taken to reduce the amount

g

c: Q) (f)

of transmissions: nodes are continually listening the network, and will refrain from transmitting data already seen inside a (configurable) time frame. Thus, when a notification is broadcast from one node, the nodes in the vicinity listen to it and refrain from repeating it. To this purpose and to avoid synchronization problems every sending is delayed by a small random time. IV.

J...

EXPERIMENTAL EVALUATION

m

Fig.

In this section we experimentally evaluate some aspects of the DEMOS system. The specific objective of these exper­ iments is to show the self-management capabilities of the DEMOS system, in particular that LuPA can reconfigure the number of message replicas that RON issues in order to keep the message loss and the transmission delay stable. The experiments presented below were performed on a modified version of the ns3 simulator. The modifications were centered on the capacity to execute applications such as the Lua virtual machine, on top of the simulated node without any

through simulations/emulations. The modified ns3 code was integrated into the main ns3 code as a contribution [17]. A.

Synthetic Model and Scenario for the Protocol Evaluation

3) Simulation

Parameters:

Each

simulation

run

lasts

300000s of simulated time. The system starts with the nodes distributed randomly over a simulated land of 1000xlOOOm. The radio range of all nodes is set to 100m. A subscription is issued by the collector at time 0 and a matching notification is issued by the sensor every 500s. The RON parameters are set as following: P B.

relevant code modification. In this manner, the exact same Lua code developed to run on DEMOS devices is the code tested

6.

=

0.1, q

=

0.99 and

maXN

=

50.

Study on the Message Delay In this study, we show the relationship between the trans­

mission delay of a message and, at the same time, the total number of nodes in the network and the number of message replicas that RON issues

(max,.. in the pseudocode). For

this experiment we run simulations variating the number of

Evaluation Setup

messages replicas max,.. between 5 and 30, and the total 1) Network: The setup common to all the experiments is a number of nodes in the network between 10 and 50.

network of one sensor node a variable number of carriers and one collector (see Figure

Figure 7 shows such a relationship for the specific setup

6). We report on experiments with described above. However, we believe that the conclusions

networks of different sizes and different node densities.

2) Mobility Model: In order to control some of the con­ nectivity characteristics of the network of mobile nodes such as diversity of seen nodes and the number of connected components, we have developed a simple mobility model that divides a square of land in a number of smaller overlapping

l, m2 and the ratio of

squares. The parameters of this model are the square side the number of parts in which it is divided

made based on this figure, can be easily generalized. In Figure 7 we can see how the number of nodes in the network impacts in the transmission delay in the expected manner: as the number of nodes increases, the transmission delay decreases. Similarly, when

max,.. increases, the transmission

delay decreases. C.

overlapping K.

Study on the Message Loss In this study, we show the relationship between the rate of

Inside each of the smaller squares, each node moves follow­

message losses and, at the same time, the total number of

ing the Random Direction Mobility Model, each node pauses

nodes in the network and the number of message replicas that

for a specific delay, chooses a random direction and speed and

RON issues

then travels in the specific direction until it reaches one of

we run simulations variating the number of messages replicas

(max,.. in the pseudocode). For this experiment

the boundaries of the model. W hen it reaches the boundary, it

max,.. between 5 and 30, and the total number of nodes in the

pauses, selects a new direction and speed.

network between 10 and 50. of a node varies

Figure 8 shows such a relationship for the specific setup

randomly with a mean of 1.5mJs and a standard deviation of

described above. As before, we believe that the conclusions

0.5mJs.

made based on this figure, can be easily generalized. In Figure

For all the experiments, the velocity

126

450 ,----,--�--.,--_,_--�-___,

00

� " "

�

� :;;

400

7000 6500 6000 5500 5000 4500 4000 3500 3000

350

300

250 200

150 100

Fig.

7.

__L-_-L__�_�__�_�_� 50 L-_-L 10 15 20 25 30 35 40 45 50

Message Transmission Delay vs. Number of Nodes and Number of

Number of nodes

Message Replicas

Fig.

rate 2 �

� g Ii!

�

T.

9.

Total Number of Nodes vs. Message Frequency

T hus, a more dense neighborhood causes a shorter time

between message receptions. Based on the model suggested

0.45 0.4 0.35 0.3 0.25 0.2 0.15 0.1 0.05

by this experiment, any node can estimate the density of its neighborhood (global, information) based on the frequency of received subscription messages (local information). Of course, the precision of the estimation depends on the accuracy of the model and this one has been based on simulations of a particular network setup. However, a more realistic model 50

Fig.

8.

could be developed based on real traces.

E. Self-Managing RON Message Loss VS. Number of Nodes and Number of Message Replicas

In this set of experiments we use the finding of the exper­

8 we can see how the number of nodes in the network impacts

iments above to create the policy-rules needed to keep the

in the loss of messages in a non obvious manner. As the

RON transmission-delay and loss-rate stable in front of a node­

number of nodes increases, the loss rate increases. Similarly,

density change.

when

maxr

increases, the loss rate increases. T his behavior

has its cause in the fact that the Notifications Table in each

Following the empiric models given by the results above, we designed a set of rules:

node is not infinite. As the number of replicas increases, it is

Rule

more probable that RON drops a low quality notification from

1: If estimated_loss_high then reduce_max_r estimated loss rate low then increase max r

Rule2:If

the Notifications Table in order to accommodate an increasing number of received notifications. Something similar occurs

estimated_delay_high then increase max r

Rule3:If

when the number of nodes, and therefore its density, increases. T his, creates a situation in which is not always beneficial to

Rule4.If

increase the number of message replicas.

estimated_delay_low then reduce max r

To try these rules we run two scenarios with a simulation

D. Estimating Node Density from Local Information

setup as the one described above with

As seen in the previous experiments, there exists a rela­ tionship between the density of nodes in the network, the

o to time Tl and

10

nodes

(40

50

nodes from time

are killed) from time Tl to

the end of the simulation. In the first scenario ("managed"

number of RON message replicas and the transmission delay

in the figures), we activated the rules at time T2. In the

and message loss. Our objective is to create some LuPA policy­

second scenario ("not managed" in the figures) the rules are

rules to reconfigure the number of message replicas that RON

not activated at all.

issues in order to keep the message loss and the transmission

Figures 10 and 11 show the behavior of the delay and the loss

delay stable. Since the number of nodes in the network is a

rate during the experiments. Both metrics, delay and loss, are

dynamic global variable not known by a node, this experiment

measured over a sliding window of

tries to find an indirect manner to measure the global number

in the graphs is the average of five runs of the experiment.

30

messages. Each point

From those figures we conclude that the DEMOS self­

of nodes from a locally-mensurable variable. Figure 9 shows the relation between the number of nodes

management deals with the abrupt change in the network

and the average time between two consecutive receptions of

conditions keeping the delay reasonably stable in relation with

subscription messages. As seen above, in the description of

the unmanaged option while the loss rate is not affected , again,

the protocol, subscription messages are issued at a constant

in comparison with the unmanaged option.

127

T2

9000

Managed Not managed ---)(---

8000 0.8 7000 0.6 0

:;:

1'! � 3

� 0.4

6000

5000

4000 0.2 3000

o L-____�____�______�_____L______L_____� o 50000 100000 150000 200000 250000 300000 Time(s)

Fig. 10.

2000

Managed Not managed ---)(--0

50000

Fig. 11.

Message Loss vs. Time

V. CONCLUSIONS AND FU T URE WORK

100000

150000 Time(s)

200000

250000

300000

Transmission Delay vs. Time

the Comisi6n Sectorial de Investigaci6n Cientffica and the

In this paper we have presented RON a self-managed oppor­

Agencia Nacional de Innovaci6n e Investigaci6n of Uruguay.

tunistic networks protocol for in-house environmental sensors

REFERENCES

and a myriad of mobile devices that act as the carriers of the

Section IV-E are extremely simple, yet powerful, and a whole

[1] "Plan Ceibal project." [Online]. Available: http://www.ceibal.org.uy/ [2] "Urn Computador por Aluno - UCA." [Online]. Available: http: //wiki.laptop.orgigo/OLPC_Brasil/Porto_Alegre [3] Jorge Visca, Guillermo Apollonia, Matias Richart, Javier Baliosian, and Eduardo Grampin, "Embedded Rule-based Management for Content­ based DTNs," in 1st International Workshop on Network Embedded Man­ agement and Applications, 2010. NEMA 2010., Niagara Falls, Canada, Oct. 2010. [4] M. Giachino, J. Baliosian, E. Grampin, and J. Visca, "Demos mobility model," in The Sixth International Conference on Wireless and Mobile Communications, Valencia, Spain, Sept. 2010. [5] c. P. Hall, A. Carzaniga, and A. L. Wolf, "DV/DRP: A content-based networking protocol for sensor networks," Faculty of Informatics, University of Lugano, Tech. Rep. 2006/04, Sept. 2006. [Online]. Available: http://www.inf.usi.ch/carzaniga/papers/ [6] A. Carzaniga and A. L. Wolf, "Forwarding in a content-based network," in Proceedings of ACM SIGCOMM 2003, Karlsruhe, Germany, Aug. 2003, pp. 163-174. [7] c. P. Hall, A. Carzaniga, J. Rose, and A. L. Wolf, "A content-based networking protocol for sensor networks," Department of Computer Science, University of Colorado, Tech. Rep. CU-CS-979-04, Aug. 2004. [Online]. Available: http://www.inf.usi.ch/carzaniga/papers/ [8] G. Banavar, T. Chandra, B. Mukherjee, J. Nagarajarao, R. Strom, and D. Sturman, "An efficient multicast protocol for content-based publish­ subscribe systems," 1999, pp. 262-272. [9] J. Haillot and F. Guidec, "A protocol for content-based communication in disconnected mobile ad hoc networks," in Advanced Information

set of management rules and scenarios are being experimented

Networking and Applications, 2008. A1NA 2008. 22nd International

collected data. Our work shows that a content-based, oppor­ tunistic routing protocol benefits from some self-configuration features, such as the dynamic adaptation of the message replication maximum of the protocol to the density of the network. We conclude that it is feasible to deploy rule-based self-management capabilities inside very-constrained devices such as the prototype sensor presented in Section II-A, and that those capabilities have a strong impact on the performance of opportunistic protocol RON. Globally, the innovative contribution of this project is the use of opportunistic networking and mobile mesh networks technologies as a cheap strategy to collect and aggregate the environmental information surveyed by a infrastructure-less network of sensors. The system presented in this paper is in its developing stage, therefore, much work remains to be made. The routing protocol presented has many aspects to be improved. Regarding the self­ management functionality of the system, besides its feasibility, its correctness must be tested extensively. The rules proposed in

on the ns3 simulator. All the models used in this paper are based on empirical data collected from simulations. Proper models based on real data must be developed, however, we believe that the results shown in this paper encourage that kind of future work. Finally, despite the fact that DEMOS project takes advantage of the Uruguayan and Brazilian particularities, and proposes to use the platform of low-cost laptops of the OLPC program, the project idea is easily translatable to other communication platforms that are becoming ubiquitous in developing countries such as cellular phones with Bluetooth or other wireless capabilities. ACKN OW LEDGMENTS

This work was partially funded by the Latin American and Caribbean Collaborative ICT Research Federation (LACCIR),

Conference on, 2008, pp. 188 -195. [10] A. Balasubramanian, B. Levine, and A. Venkataramani, "Dtn routing as a resource allocation problem," New York, NY, USA, pp. 373-384, 2007. [Online]. Available: http://dx.doi.orgllO.1145!l282427.1282422 [11] 1. Baliosian, J. Visca, E. Grampin, L. Vidal, and M. Giachino, "A rule­ based distributed system for self-optimization of constrained devices," in IFIPlIEEE International Symposium on Integrated Network Manage­ ment, 2009. 1M '09., 1-5 2009, pp. 41-48. [12] "usb4all." [Online]. Available: http://www.fing.edu.uy/inco/grupos/mina/ pGrado/pgusb/material.html [13] "Lua, the programming language." [Online]. Available: http://www.lua. org [14] "PICDEM Full Speed USB." [Online]. Available: http://www.microchip. com! [15] "The OpenWrt Project." [Online]. Available: http://openwrt.org/ [16] A. Lindgren, A. Doria, and O. Schelen, "Probabilistic routing in intermit­ tently connected networks," SIGMOBILE Mob. Comput. Commun. Rev., vol. 7, no. 3, pp. 19-20, 2003. [17] "ns-3-dce." [Online]. Available: http://code.nsnam.org/mathieu/ns-3-dce/ rev/S04423977908

128