middleware technologies base

8/11/2019 Middleware Technologies base

http://slidepdf.com/reader/full/middleware-technologies-base 1/12

64 PERVASIVE computing Published by the IEEE CS n 1536-1268/12/$31.00 © 2012 IEEE

F E A T U R E : M O B I L E C O M P U T I N G

Middleware for

Differentiated Quality inSpontaneous Networks

P

ushed by the widespread availabil-

ity of resource-rich mobile devices,

academic and industrial research-

ers are increasingly looking into

spontaneous networks (SNs).1–3 Such networks promise to better exploit wire-

less connectivity—for example, via connectiv-

ity sharing among users in a social community,

especially in regions with partial or unreliable

coverage.

However, the definition of SNs is still some-

what blurred in the literature. Sometimes

the term is used as a variant

of wireless mesh networks

(WMNs), which typically have

more stable network topology

and are more oriented to sup-port relatively long paths.4

Some view SNs as closer to the concept of op-

portunistic networks (ONs), which are gener-

ally more dynamic and work according to the

Store, Carry, and Forward (SCF) paradigm.5

We use the term to indicate the dynamic col-

laborative networks (involving heterogeneous

wireless interfaces and relatively short multihop

paths) stemming from the impromptu interac-

tion of mobile or fixed devices, administered

by typically small groups of socially interacting

users. (For a more in-depth discussion on the

placement of SNs in the mobile ad hoc network

literature, see the related sidebar.)

In the near future, SNs will help unify the

emerging trends of anytime, anywhere connec-

tivity; ubiquitous portable devices; and sociallyaware collaboration to exploit all available

resources. However, to accelerate SN adop-

tion, we need flexible and easily deployable

support solutions that fulfill differentiated ap-

plication requirements while coping with het-

erogeneity and dynamicity. Here, we describe

the design and prototype of our Real Ad hoc

Multihop Peer-to-peer (RAMP) middleware

for flexible, dynamic, and application-driven

SN management.

Technical ChallengesTo support the promising SN scenarios, we

claim the need for original solutions based on

novel middleware. Such middleware should in-

tegrate available wireless technologies and eas-

ily deploy over existing networks, with no need

to undergo the long process of layer-2 protocol

acceptance and diffusion. In particular, given

the needs of dynamic adaptability to application-

specific requirements (such as performance ver-

sus overhead or availability versus reliability),

SN middleware should follow novel design

guidelines.

Spontaneous-network management requires application-driven

middleware to address differentiated application-specific requirements

at runtime. Real Ad hoc Multihop Peer-to-peer (RAMP) middleware easily

deploys over existing and heterogeneous wireless networks, supporting

adaptive and per-application strategies even in challenging scenarios,

such as multimedia streaming.

Paolo Bellavista, Antonio Corradi,

and Carlo Giannelli

University of Bologna, Italy



JULY–SEPTEMBER 2012 PERVASIVE computing 65

For example, SNs should exploit

different wireless technologies, man-

aged with local scope, in uncoordi-

nated IP networks with different ad-

dress spaces. Traditional WMN/ONrouting solutions aren’t suitable for

these environments because they as-

sume homogeneous node addressing

and layer-2 technologies. In addition,

SN paths should be discovered in a

mission-oriented way by effectively

looking for nodes and services only

when requested. Proactive solutions

for path determination are inappropri-

ate here, given the ephemeral nature of

SN collaboration opportunities. The

heterogeneous uncoordinated natureof SNs calls for addressing four differ-

ent technical challenges.

The first is the need to exploit off-

the-shelf wireless technologies to be

easily and immediately deployable,

thus leveraging the diffusion of SN ap-

plications. This requires avoiding tech-

nical solutions that impose modifica-

tions at the OS and lower layers, which

would require modifying standards—

thus starting the long process of ac-

cepting and deploying new, relatedimplementations.

Second, we need to support the con-

current usage of multiple heteroge-

neous wireless interfaces within the

same node—for example, by support-

ing applications that effortlessly and

simultaneously exploit both IEEE

802.11 and Bluetooth links. The chal-

lenge will be establishing and manag-

ing multihop paths, comprised of multi-

ple heterogeneous links.

The third challenge deals with nodemobility and connectivity dynamicity.

SNs are based on the impromptu inter-

action of users and their portable de-

vices, which dynamically create, join,

or leave SNs. We thus need efficient

and prompt discovery of newly avail-

able nodes and services with limited

overhead.

Finally, we need to support a wide

spectrum of differentiated peer-to-

peer applications of interest, ranging

from messaging to file sharing and

audio-video streaming. Traditional net-

working solutions that pursue specific

objectives, such as low communica-

tion overhead or high reliability, can’t

support differentiated quality require-ments for different applications, even

concurrently—that is, these solutions

don’t exploit SNs to invoke and offer

different applications with differen-

tiated quality provisioning with per-

application granularity.

Considering these technical chal-

lenges, we focus on how RAMP sup-

ports differentiated mechanisms for

collaborative resource handling over

SNs, suitable for a wide set of applica-

tions. RAMP flexibly and dynamicallyadapts its behavior with per-packet

granularity based on one of three dif-

ferent management strategies.

Although RAMP proposes an ap-

proach partially similar to previous

active networking research,6 it con-

siders additional requirements coming

from packet management on uncoor-

dinated and intermittent SNs, with no

special-purpose equipment (such as ac-

tive routers), and only based on a mid-

dleware-layer approach. Related workeither addresses specific technical

challenges of WSNs/ONs or doesn’t

offer a practical SN support solution,

implemented and available for down-

load.1–3 RAMP aims to provide a use-

ful and practical contribution for the

community of researchers and practi-

tioners in the field and is available for

download at http://lia.deis.unibo.it/

Research/RAMP.

Application ScenariosTo support a wide range of applications,

our primary guideline is to flexibly and

dynamically perform SN management

at the middleware layer (without ex-

ploiting operating system-dependent

routing facilities), depending on the rel-

evance and characteristics of exchangedapplication-level content. To clarify

the most common, differentiated, and

application-specific SN requirements,

we present three practical scenarios:

file sharing in a lecture hall, audio/

video conferencing during a project

meeting, and the delivery of critical

messages in an emergency.

File Sharing

In the first scenario, a group of stu-

dents in a lecture hall interact to sharelesson notes via subgroups of friends,

created in an impromptu way, by pos-

sibly participating in multiple subnets

simultaneously. For example, node A in

Figure 1a accesses shared files on node

E using node C as a gateway between

the Bluetooth piconet and the IEEE

802.11 Independent Basic Service

Set. The primary (noncritical) goal is

to download the desired file, possibly

with low latency and surely with mini-

mal impact on the intermediaries. Incase of failure, students might be in

charge of explicitly restarting their

note-sharing request.

To reduce participants’ overhead,

there’s no strict constraint on ensur-

ing reliability and proactively keep-

ing alternative ready-to-use paths. In

this case, it’s reasonable to use regu-

lar priority packets to provide low-

cost immediate delivery, with no stor-

age duties and limited overhead (high

performance and limited overhead

are traded for lower availability and

reliability).

Proactive solutions for path determination

are inappropriate here, given the ephemeral

nature of spontaneous network collaboration

opportunities.



66 PERVASIVE computing www.computer.org/pervasive

FEATURE: MOBILE COMPUTING

Video Conferencing

In the second scenario, a group of re-

searchers participate in a one-day project

meeting at an airport. The researchers

split into subgroups in different halls but

can monitor each group’s activity with

video conferencing via multihop paths

that comprise ad hoc single-hop links.

For example, node A in Figure 1b

sends audio and video streams to node D

via node C. Here, the main goal should

be to keep stream provisioning, pos-

sibly with temporary quality degra-

dations, even in the case of partial to-

pology modifications. Some limited

quotas of the exchanged packets could

be lost, especially in case of dynamic

path requalification, but provisioning

should continue with acceptable quality

with no user intervention. For example,

the stream should be automatically

migrated from node C to the “node B

to node F to node E” path if node C

leaves the SN, even at the cost of some

additional overhead for alternative path

management. This scenario calls for in-

creased availability support, capable of

reacting to topology variations via the

dynamic determination of alternative

multiple paths (higher availability and

S

pontaneous networks (SNs) are emerging as a research

subfield with specific characteristics, different from the ad-jacent areas of wireless mesh networks (WMNs) and opportunis-

tic networks (ONs), which are evolutions of the older and more

general mobile ad hoc network (manet) area (see Table A).1 Manets

primarily focused on proper routing algorithms to manage node

mobility—for example, while maximizing bandwidth or mini-

mizing energy consumption. Recently WMNs, ONs, and SNs

have gained momentum, differentiating from one another and

from former manets, even if sometimes with blurred borders.

In particular, we propose a clear differentiation and classification

of these research areas by considering three main characterist ics:

network scalability, connectivity quality, and communication re-

liability (other aspects with secondary impact include connectiv-ity dynamicity, node mobility, and role heterogeneity).

By pushing some properties to the extreme for the sake of

presentation clarity, WMNs put the accent on scalability and

quality. WMN scenarios can be formed by many nodes (even

thousands when covering whole cities). One of the crucial goals

is to guarantee sufficient quality to any node—for example, by

fairly sharing bandwidth despite position.2 In addition, WMNs

tend to clearly identify node roles: clients accessing the network

can move, while intermediaries tend to be fixed (such as meshaccess points).3

Instead, ONs stress the aspects related to path unreliabil-

ity caused by node mobility.4 Because of the temporary lack

of a path destination, packet delivery benefits from per-packet

duplication and node mobility, not from path reconfiguration.

One of the main issues is to provide smart heuristics to maximize

the probability of moving packets closer to destinations—for

example, sending them to a vehicle moving in the “right” direc-

tion while avoiding routing inefficiencies due to data replica-

tion.5 However, scalability and quality aren’t primary goals. The

focus is more on single packet delivery rather than on stream

reconfiguration.The main SN goal, instead, is to easily provide connectivity to

users who are interacting socially.6 On the one hand, SNs can

be viewed as a simplified practical version of previous areas: SN

scalability and quality requirements are usually less strict than

in WMNs (for example, there’s a limited number of managed

nodes and throughput). SNs usually interconnect small groups of

people located in the same neighborhood, offering, discovering,

Spontaneous Networks in the Manet Literature

TABLE A

A concise comparison of wireless mesh networks (WMNs), spontaneous networks (SNs),

and opportunistic networks (ONs).

WMNs SNs ONs

Scalability (node number) > 1,000 10 to 100 Not a primary goal

Reliability Per node Per node and per packet,

best effort

Per packet

Quality Primary goal Best effort Not a primary goal

Dynamicity Limited, not aprimary goal

Medium High—for example, also supportscollaborations between unknown vehicles

Node mobility Limited, only clients Medium, also joint mobilityin a social group

High, primary goal

Role heterogeneity Client, router,Internet access

Peers Peers




reliability are traded for management

overhead).

Delivering Critical Messages

In the third case, emergency team mem-

bers must exchange critical messages,

but there might not always be available

paths between the sender and receiver.

Messages thus should be managed

opportunistically and forwarded to a

suitable node as soon as a path becomes

available. In addition, in the case of

abrupt path disruption, intermediaries

should temporarily store messages and

try to deliver them again later, obvi-

ously with the additional costs of local

storage.

The primary goal is to achieve reliable

delivery of typically small messages via

SCF techniques. For example, node A

in Figure 1c might need to deliver a mes-

sage to node G, even when there aren’t

any available paths. Node B could serve

as the mobile deliverer by accepting the

message while connected with node A

(node B1 as the single-hop neighbor of

node A) and by forwarding it to the re-

ceiver when connected to node E (node B2

as the multihop peer of node G). This ap-

plication requires maximum reliability

and invoking peer-to-peer services. This simplifies some

operations—for example, the discovery of shared resources can

be effectively performed with trivial flooding. In addition, mobil-

ity and dynamicity are lower than in ONs: single-hop links usu-

ally last for a relatively long time because of limited relative mo-

bility of socially interacting people, either still or jointly moving.

Reliability support can exploit a best-effort approach: SNs usually

need neither the complex handover management of WMNs nor

the expensive data replication sometimes adopted in ONs.

On the other hand, SNs raise new technical challenges be-

cause they target off-the-shelf devices, such as smartphones and

laptops, with very heterogeneous hardware and communication

capabilities (such as UMTS, IEEE 802.11, and Bluetooth). At the

same time, node roles (offering or requesting services, collabo-

rating or not with the SN, perhaps because of battery availability)

tend to change rapidly. Moreover, single-hop subnets are usu-

ally created in a completely local way. Assigned IP addresses

generally have limited scope validity (they’re possibly incom-

patible when different address spaces are put together for SN

collaborations).

Recent contributions have enabled some forms of node coop-

eration by considering specific deployment environments, often

via effective but nonstandard modifications to layer-2 proto-

cols. For example, the proposals on multihop paths have mainly

focused on either extending cellular coverage via relay stations7

or on client mobility management in heterogeneous network.8

Dynamic path reconfiguration has been addressed mainly for

streaming applications, with the primary goal of audio and videoquality. For instance, SoftMAC9 optimizes bandwidth allocation

in multihop networks via differentiated management of real-time

best-effort transmissions. Delay-tolerant messaging has been

investigated in both mobile ad hoc5 and Internet-like10 environ-

ments, but without focusing on flexible dynamic support of dif-

ferentiated application requirements. Few solutions exploit multi-

ple paths concurrently to improve availabili ty.11 Finally, work

similar to ours recognizes the importance of taking advantage of

device heterogeneity, but considers more infrastructure-oriented

WMNs and doesn’t report any practical experience of prototype

implementation and deployment.12

REFERENCES

1. M. Conti and S. Giordano, “Multihop Ad Hoc Networking: the

Theory,” IEEE Comm., vol. 45, no. 4, 2007, pp. 78–86.

2. V. Gambiroza, B. Sadeghi, and E. Knightly, “End-to-End Performanceand Fairness in Multihop Wireless Backhaul Networks,” Proc. 10th

Ann. Int’l Conf. Mobile Computing and Networking (MobiCom), ACM,

2004, pp. 287–301.

3. J . Camp and E. Knightly, “The IEEE 802.11s Extended Service Set

Mesh Networking Standard,” IEEE Comm., vol. 46, no. 8, 2008,

pp. 120–126.

4. L . Pelusi, S. Passarella, and M. Conti, “Opportunistic Networking:

Data Forwarding in Disconnected Mobile Ad Hoc Networks,” IEEE

Comm., vol. 44, no. 11, 2006, pp. 134–141.

5. M. Musolesi and C. Mascolo, “CAR: Context-Aware Adaptive Rout-

ing for Delay-Tolerant Mobile Networks,” IEEE Trans. Mobile Comput-

ing , vol. 8, no. 2, 2009, pp. 246–260.

6. L.M. Feeney, B. Ahlgren, and A. Westerlund, “Spontaneous Net-

working: An Application Oriented Approach to Ad Hoc Networking,”

IEEE Comm., vol. 39, no. 6, 2001, pp. 176–181.

7. L. Le and E. Hossain, “Multihop Cellular Networks: Potential Gains,

Research Challenges, and a Resource Allocation Framework,” IEEE

Comm., vol. 45, no. 9, 2007, pp. 66–73.

8. S. Pack et al., “Mobility Management in Mobile Hotspots with Het-

erogeneous Multihop Wireless Links,” IEEE Comm., vol. 45, no. 9,

2007, pp. 106–112.

9. H. Wu et al., “SoftMAC: Layer 2.5 Collaborative MAC for Multimedia

Support in Multihop Wireless Networks,” IEEE Trans. Mobile Comput-

ing , vol. 6, no. 1, 2007, pp. 12–25.

10. K. Fall, “A Delay-Tolerant Network Architecture for Challenged

Internets,” Proc. ACM Conf. Applications, Technologies, Architectures,

and Protocols for Computer Comm. (SIGCOMM 03), ACM, 2003,

pp. 27–34.

11. X. Tong, Y. Andreopoulos, and M. van der Schaar, “Distortion-

Driven Video Streaming over Multihop Wireless Networks with

Path Diversity,” IEEE Trans. Mobile Computing , vol. 6, no. 12, 2007,

pp. 1343–1356.

12. L.S. Ferreira et al., “Opportunistic Management of Spontaneous and

Heterogeneous Wireless Mesh Networks,” IEEE Wireless Comm., vol. 17,

no. 2, 2010, pp. 41–46.





to enable packet delivery, even in the

challenging case of a temporary absence

of any available path (with maximum

availability and reliability coming at the

cost of increased storage and path man-

agement overhead).

Solution Guidelines for SN MiddlewareSN application developers can’t di-

rectly handle the complex, application-

specific differentiated management ofintermittent heterogeneous multihop

paths. However, SN middleware solu-

tions based on the following guidelines

can make proper management deci-

sions at runtime, thus supporting easier

application provisioning.

Middleware-Based

Routing Management

Routing management should work

with per-application granularity, and

it should be independent of the under-lying operating system support. Mid-

dleware should adopt differentiated

management strategies that depend

not only on the network’s current sta-

tus but also on different requirements

of currently supported applications.

The technical challenge is to work

at the middleware layer by imposing

limited overhead, notwithstanding

the uncoordinated and intermittent

nature of multihop heterogeneous

paths.

Reactive and Mission-

Oriented Approach

Applications should find resources

exactly and only when needed. Given

the relatively high dynamicity of SNs,

proactive general-purpose approaches

and distributed caching of monitor-

ing status are uselessly expensive and

inefficient.

Low Overhead

To keep overhead low, middleware

should be able to locally reconfigure

paths at runtime by exploiting only par-

tial localized visibility and by involving

only a limited set of nodes, either in the

neighborhood or along the path.

Stateless Communications

Considering SN dynamicity and het-

erogeneity, it’s either unfeasible or un-

suitable to explicitly create end-to-end

client-to-server channels. Paths should

Figure 1. Examples of spontaneous networks (SNs) with different requirements:

(a) file sharing in a lecture hall, (b) audio/video conferencing during a project

meeting, and (c) delivering critical messages in an emergency.

(a)

C

B

DA

E

Universal MobileTelecommunications System (UMTS)

base station

Interface providingad hoc connectivity

Bluetoothpiconet

IEEE 802.11Independent BasicService Set (IBSS)

(b)

IEEE 802.11IBSS

B1

B2

A

E

G

Bluetoothpiconet

Bluetoothpiconet

F

B

DA

E

G

IEEE 802.11IBSS

Bluetoothpiconet

Bluetoothpiconet

IEEE 802.11IBSS

C

F

(c)

UMTSbase station




be dynamically managed as the

middleware-based combination of in-

dependent single hops, with no state

kept at low-protocol stack layers.

RAMP Architecture andManagement StrategiesRAMP only exploits a scarcely co-

ordinated and local vision of the

network’s status. It effectively man-

ages the needed paths with per-

application grain by enabling differ-

ent management strategies for concur-

rent applications with differentiated

requirements.

RAMP also addresses the issues

of working with statically unknownnetwork topologies and of handling

heterogeneous wireless nodes that

can join, exit, or move dynamically. It

carefully considers the primary goal

of limiting node overhead to encour-

age peer-based resource sharing. Fur-

thermore, it handles heterogeneous

links, effectively manages potentially

conflicting IP address spaces, and en-

ables middleware-managed routing

(without the need of any specific sup-

port at the operating system level).

Architecture

RAMP has a two-layer architecture,

with a higher service layer and a lower

core layer (see Figure 2). The former

supports peer-to-peer services via reg-

istration, advertising, and discovery fa-

cilities; the latter provides abstractions

for end-to-end unicast and broadcast

communication. In particular, the Ser-

vice Manager registers and advertises

local applications (registerLocalService).RAMP Discovery retrieves remote

services (findRemoteServices) by determin-

ing paths in a completely distributed

way and only when required. It’s based

on time to live (TTL)-bound dissemina-

tion of service request messages; remote

nodes offering the requested service

simply reply to the sender via unicast.

Additional discovery protocols can be

easily integrated in RAMP, even at run-

time, given its extensible plug-in archi-

tecture. For example, we’re currently

working on the integration of univer-

sal plug and play (UPnP) discovery

over multihop SNs via the transpar-

ent encapsulation of standard UPnP

messages.

E2EComm offers multihop unicast

and TTL-bound broadcast primitives

(receive, sendUnicast, and sendBroadcast). TheDispatcher interacts with single-hop

neighbors—for example, via UDP/TCP,

depending on dynamic sender decision—

to collaboratively route packets to their

destination (thereby achieving stateless

communication). Heartbeater works to

keep track of single-hop neighbors via

periodic UDP broadcasts.

In addition, RAMP exploits a plug-

in architecture to enable easy modifica-

tion of the packet header and payload at

any traversing node. Middleware com-ponents willing to manage traversing

traffic must implement the Packet Lis-

tener interface and register themselves

to the Dispatcher, in a plug-in way. For

example, the Continuity Manager can

handle temporary path unavailability,

with per-destination granularity, look-

ing for alternative paths and perform-

ing local storage in case there’s a packet-

dispatching failure. In other words,

the Packet Listener in Figure 2 repre-

sents a generic component working

as a listener for traversing packets;

Continuity Manager is an example of

an actual component instance imple-

menting the Packet Listener interface

and registered to Dispatcher.

Application developers can exploit

RAMP APIs to create, deploy, dis-

cover, and invoke new SN services bytaking full advantage of the differen-

tiated packet delivery strategies (de-

scribed next). In addition, RAMP can

support legacy applications in a trans-

parent way via the proper introduction

of RAMP application-specific proxies.

For example, the current RAMP distri-

bution includes a RAMP HTTP proxy

(located at the client nodes) to transpar-

ently integrate traditional Web brows-

ers (and any other HTTP-based clients)

via HTTP requests and responses en-capsulated in RAMP packets.7

A detailed description of RAMP is

out of this article’s scope, so we focus

on our middleware’s ability to adapt

its behavior in a mission-oriented way

by dynamically fitting its management

strategies to currently supported appli-

cations. In particular, using the RAMP

API, applications can exploit the fol-

lowing three strategies, which can be

active simultaneously in the same SN.

In addition, it’s easy to add further

Figure 2. The Real Ad hoc Multihop Peer-to-peer (RAMP) middleware has a two-layer

architecture, with a higher service layer and a lower core layer. The former supportspeer-to-peer services via registration, advertising, and discovery facilities; the latter

provides abstractions for end-to-end unicast and broadcast communication.

Corelayer

Dispatcher Packet

listener

sendBroadcastreceivesendUnicast

Heartbeater

E2E communication

Servicelayer Localservices

ServiceManager Discovery

registerLocalServicefindRemoteServices





management strategies, adequate for

other application classes, by exploiting

the RAMP plug-in architecture.

Nonreliable Bulk Transfer

The NRBT strategy is tailored for high

performance, low overhead, and low

reliability. It’s suitable for transferring

bulk files with low end-to-end latency

and with limited overhead for partici-

pating nodes. But it doesn’t consider re-

liability as a primary goal. In the case of

failure—for example, due to intermedi-

ary node mobility—the user is expected

to restart his or her service request ex-

plicitly, without any automated middle-ware intervention.

When an application sets NRBT,

RAMP transparently splits exchanged

packets (such as shared files) in small

data chunks and sends them from the

sender to the receiver in an orderly and

concurrent manner. The advantage is

twofold.

First, RAMP manages chunks in a

pipeline, thus considerably reducing

end-to-end latency. It passes the first

chunk of a file to the following node

while still waiting for other chunks

of the same packet (see t 1 and t 2 in

Figure 3a, where t stands for time in-

stant). In other words, RAMP performsmiddleware-layer packetization to

avoid the trivial receiving and forward-

ing of single-hop transmission for the

entire message, which would increase

delay linearly with path length (see t 2

in Figure 3b).

Second, peers must allocate small

buffers for traversing traffic, with a

limited impact on resource usage at

collaborating nodes (note how in t 1

and t 2 in Figure 3a, there’s at most one

data chunk in the intermediate nodes).Without NRBT, nonchunked packet

exchange could cause relevant memory

occupation for local applications (see t 2

in Figure 3b, where all four chunks are

within the same node).

Reliable Packet Streaming

The RPS strategy aims to alleviate dis-

connections, even via a l imited exploi-

tation of additional resources by par-

ticipants. Unlike NRBT, RPS works

well for packet streaming: it enables

the dynamic transparent rerouting of

packets and the exploitation of other

(possibly) available sender-to-receiver

paths in case of path disruption, thus

avoiding or reducing interruptions inaudio or video applications. This strat-

egy increases user satisfaction via path

management operations automatically

performed by the middleware in re-

sponse to (moderate) modifications

of the SN topology at provisioning

time.

When an application activates RPS,

RAMP adopts a distributed and light-

weight approach to migrate packets on

new path segments in case of a failure—

such as when an intermediary node hasjust moved out of the SN. In particular,

the intermediate node before the failed

link (see Figure 4, t 0, node X) autono-

mously looks for another segment to the

same destination (reactive approach)

and, if available, starts rerouting its lo-

cally incoming packets via the newly

discovered path. Path management

is localized at the intermediate node

aware of path disruption; if alternative

path segments are available, it involves

only local and partial path redetermi-nation. In parallel, the same intermedi-

ate node informs the sender of the new

path, so that the sender can start us-

ing it as soon as possible (Figure 4, t 1).

Packets are dropped only when there

are no alternative paths.

Compared with NRBT, RPS intro-

duces additional but limited and lo-

calized overhead. Overhead is only

for intermediate nodes close to link

failures and comes up only when fail-

ures occur (noticing path disruption,discovering new path portion, notify-

ing the sender of the new path, and

modifying the header on traversing

packets for rerouting). The first three

steps are performed only once per

path modification, and the last one

is only temporary until the sender re-

ceives the new path notification (then,

it can send packets directly along the

new path, making the packet rerout-

ing operation by intermediate nodes

unnecessary).

Figure 3. RAMP performs middleware-layer packetization to avoid the trivial

receiving and forwarding of single-hop transmission for the entire message, which

would increase delay linearly with path length: (a) with Nonreliable Bulk Transfer

(NRBT) and (b) without it. (Here, t stands for time instant.)

A B

3

4

1

2

A B

134

2

A B

3

4

1

2

A B

23

4

1

A B

3

4

1

2

A B

3

4

1

2

t 2

t 1

t 0

Without NRBT

(a) (b)

With NRBT




Highly Reliable Message Delivery

The HRMD strategy aims at maxi-

mum availability of delay-tolerant ser-

vices. It delivers critical packets by sup-

porting SCF-based transmission evenwhen there’s a (temporary) absence of

a destination path. In particular, when

HRMD is set and there’s no path to

destination, RAMP temporarily stores

packets on intermediaries where there’s

no current possibility for single-hop

transmission (see Figure 5, t 0, node X),

so it can try to deliver them again later.

In this way, if any topology modifica-

tion connects previously partitioned

SN parts in a reasonable time—because

the node with locally stored packetshas moved to another area (Figure 1c,

node B2) or because a new node has

joined the SN (Figure 5, t 1, node N),

RAMP can transparently deliver the

packets anyway via middleware-layer

retransmission.

Compared to RPS, HRMD intro-

duces a limited but higher overhead—

intermediaries must temporarily (and

locally) store packets as well as discover

new paths. HRMD is thus a good fit for

applications with small-sized messagesand for emergency scenarios in which

participants are willing to collaborate

by offering a nonnegligible quota of

their local resources.

RAMP Implementationand EvaluationRAMP exploits the mechanisms devel-

oped within Multihop Multipath Het-

erogeneous Connectivity (MMHC)

for dynamically setting ad hoc subnets

(link creation and network configura-tion by exploiting off-the-shelf mech-

anisms at layer-2 and layer-3, respec-

tively).8 The MMHC goal is to provide

the best multihop connectivity via

proper local configuration based on in-

novative context indicators (for exam-

ple, the probability of joint mobility of

peer nodes).

Each subnet is created in a distrib-

uted way, without a global scope, and

by exploiting every available wireless

interface (such as IEEE 802.11 and

Bluetooth). Nodes assign IP addresses

to the subnets they’ve created with-

out any coordination, thus yielding to

heterogeneous IP address spaces. How-

ever, the former MMHC rerouting

mechanism manages multihop paths

Figure 5. Highly Reliable Message Delivery. HRMD delivers critical packets by

supporting Store, Carry, and Forward (SCF)-based transmission even when there’s

a (temporary) absence of a destination path.

Routing Storing

A X L B

A X L Bt 1

t 0

N

Figure 4. Reliable Packet Streaming. RPS reduces interruptions in audio and video

applications by enabling dynamic, transparent rerouting of packets and exploiting

other available sender-to-receiver paths.

Routing Rerouting

A X L B

A X L Bt 1

t 0





only based on default gateway modi-

fications at the operating system level,

also with negative consequences such as

the impossibility to enable some types

of downstream communications notinitiated by clients.8

RAMP more flexibly dispatches

packets at the middleware layer by ex-

ploiting every available single-hop link

enabled by the underlying MMHC.

Thus, it supports simultaneous exploi-

tation of any available path, despite the

operating-system-level configuration of

routing tables, and adopts the NRBT,

RPS, and HRMD strategies with fine

per-packet granularity.

RAMP identifies a node X at the

middleware layer via the sequence

of addresses that MMHC assignsto the intermediaries composing the

path from local nodes to node X. The

Dispatcher exploits this sequence to

forward packets by possibly split-

ting large packets in chunks (NR BT),

while the Continuity Manager ex-

ploits the destination identifier to re-

route packets in case of path disrup-

tion (RPS) by possibly storing packets

in case of temporary path unavailabil-

ity (HRMD).

Applications can activate one ofthe three SN management strategies

dynamically, for each packet transmis-

sion, via the simple RAMP API by

• specifying the size of each data chunk

the local Dispatcher should split the

packet into (NRBT);

• simply indicating the receiver ID for

the entire sequence of packets com-

posing the stream (RPS); or

• indicating both the receiver ID and

packet expiration deadline (HRMD).

The Dispatcher is the sender or receiver-

side component enforcing NRBT. As

the sender, it splits the packet in chunks

and sends them. As the receiver, it waits

for all chunks, transparently rebuildsthe payload, and delivers the resulting

packet transparently to the receiver.

The Continuity Manager is the

key component that enables RPS and

HRMD:

1. It works as a Packet Listener, wait-

ing for path disruption notifications

by the Dispatcher (notifications

triggered by packet transmis-

sion failures; TCP as the default

transport).

2. It looks for new paths to destination

via simple and broadcast-basedlimited flooding. Other more so-

phisticated and effective algorithms

for path redetermination could be

easily accommodated in RAMP.

3. In the case of new path availability,

it notifies the sender while imme-

diately rerouting incoming packets

along the new destination path (by

modifying the packet header, which

includes destination ID and address

sequence, and by returning the con-

trol to the Dispatcher for packettransmission).

4. In case of HRMD and unavailable

paths, it performs local packet stor-

age. If the specified deadline hasn’t

expired, it waits for a configurable

interval t wait and then restarts from

point 3 by decreasing the possible

retransmission attempts #retry any

time the path is unavailable.

To validate the RAMP approach and

quantitatively evaluate its performance,

we report on different SN applications

deployed with differentiated require-

ments: a file-sharing application using

NRBT, a video conferencing applica-

tion exploiting RPS, and a critical mes-saging application with HRMD. The

nodes of the following tests are Core2

2.6-GHz laptops with 2.0 Gbytes of

RAM, running Microsoft Windows

XP or Linux Debian; single-hop links

are based on IEEE 802.11b (infrastruc-

ture and ad hoc modes) with Cisco

access points and Orinoco cards (set

to 2 Mbit/s for each single-hop link).

All the reported performance figures

in this section are average values over

100 runs. For brevity, here we reporton the most common use cases—for

example, medium-size file transfer

and Web-quality video streaming.

Additional use cases are illustrated

at http://lia.deis.unibo.it/Research/

RAMP.

NRBT Evaluation

Starting with file sharing, we carefully

evaluated transfer time experimental

results when disabling/enabling NRBT.

Figure 6a shows the end-to-end transfertime for a 10-Mbyte file when using tra-

ditional operating system-level routing

(no RAMP, iperf-based measurements,

thus experimentally identifying the

lower bound for this indicator), with

RAMP performing trivial storage and

forwarding, and with NRBT for differ-

ent chunk sizes.

Applications can specify chunk

size with per-packet granularity, but

RAMP bounds the value in the 5

Kbytes to 1 Mbyte range to avoid sizesthat are too large or small and thus

could be harmful for intermediaries—

for example, out-of-memory excep-

tions for excessive buffering. While

trivial storage and forwarding in-

creases transfer time almost linearly

with path length, NRBT performance

is nearly constant and very close to the

lower bound; in particular, for chunk

sizes that are 50 Kbytes. This moti-

vates our default setting for chunk

size.

To validate the RAMP approach and

quantitatively evaluate its performance, we

report on different spontaneous network

applications.




Figure 6. Experimental evaluation: (a) NRBT end-to-end delay, (b) video conferencing testbed, and (c) RPS performance when

reacting to path disruption.

Proactive rediscoveryconnect timeout = 150 ms

100

200

300

400

500

0

600

I n t e r - p a c k e t a r r i v a l

t i m e ( m s )

–0.2

0.0

0.2

0.4

0.6

–0.4

0.8

–9 –6 –3 0 3 6 9 P a c k e t a r r i v a l t i m e f r o m p

a t h

d i s r u p t i o n ( s )

Packet number(0 = last packet before path disruption)

0

100

200

300

400

500

600

–0.6

–0.4

–0.2

0.0

0.2

0.4

0.6

No proactive rediscoveryconnect timeout = 500 ms

–6 –3–9 0 3 6 9

Packet number(0 = last packet before path disruption)(c)

40

50

60

70

80

90

100

110

120

130

1 2 3

E n d - t o - e n d t r a n s f e r t i m e ( s )

End-to-end path length (#hops)Routing Rerouting

A X B

A X B

A X Bt 2

t 1

t 0

(b)(a)

s&f1 MB

500 KB100 KB50 KBOS





RPS Evaluation

In the second scenario, our video con-

ferencing application exploits VLC-

MediaPlayer to capture (sender) and

play (receiver) the video stream froma regular webcam (25 frames/s, with

a 320 × 240 resolution). The data is

MPEG2-encoded and transmitted via

RTP/MPEG-TS. To evaluate RPS per-

formance in a challenging situation, we

report on a case of abrupt connectiv-

ity interruption (node X to node B in

Figure 6b). With RPS disabled, applica-

tions are in charge of perceiving and re-

acting to communication interruptions,

because RAMP doesn’t recover it au-

tonomously. The receiver must identifythe fault, look for an alternative path,

and notify the sender of the new path.

When using RPS, applications can

achieve a twofold benefit. First, RAMP

autonomously recovers the path to des-

tination, without any explicit manage-

ment at the application layer. Interme-

diaries close to the disrupted single-hop

link perceive path disruption and rees-

tablish connectivity. Second, path dis-

ruption is perceived more promptly (via

TCP connect error, directly perceivedby node X), and path reestablishment

is performed faster (it involves only the

“node X to node B” path segment). In

this case, stream interruption lasts the

time needed to perceive path disruption

and discover an alternative path.

The RPS default behavior (suitable

for most applications) is to set the TCP

connect time-out to 500 ms and to dis-

cover alternative paths only reactively,

after a connectivity fault. Packets are

delayed only 515 + 75 × #hopR ms,where #hopR is the node X receiver

distance in the new path segment (usu-

ally smaller than whole sender-to-

receiver path). The left term perceives

link disruption at node X (plus local

processing), and the right term finds an

alternative node X receiver path. After

determining the new path, node X can

immediately reroute packets.

Applications with strict performance

requirements, such as VoIP, can decide to

specify lower TCP connection time-outs

and enable proactive path discovery on

intermediaries. For instance, packets

are delayed by only 165 ms if the con-

nect time-out is set to 150 ms, with pro-

active rediscovery enabled on interme-diaries. The possible drawbacks are the

possibility of erroneously assessing an

active link as lost because of relatively

high link delays, and the additional

overhead due to periodic determination

of alternative paths.

Figure 6c clearly shows that RPS

avoids packet dropping by only delay-

ing packets in case of path disruption

(at packet 0 reception time). After path

requalification, delayed packets accu-

mulated at node X are immediately re-routed and rapidly reach the receiver,

thus reducing perceivable quality deg-

radation (interpacket arrival time rap-

idly returns to the usual fluctuating pat-

tern). The number of delayed packets

depends mainly on the RPS parameters

(the connect time-out and enabled or

disabled proactive rediscovery) and the

average packet interval.

For example, in Figure 6c, only

7/2 packets are delayed by exploiting

500/150ms TCP time-out without/with proactive path determination. Note

that our video conferencing application

is extremely challenging because it im-

poses frequent transmission (every 73 ms)

of small packets (about 1,440 bytes per

packet, of which 1,328 for payload).

When frequency is minor and payloads

are larger, RAMP can achieve signifi-

cantly better performance in terms of

both the number of delayed packets and

per-packet overhead.

HRMD Evaluation

In the third application case, HRMD

exploits some of the mechanisms de-

scribed for RPS—for example, fault

identification and new path segment

determination, with similar perfor-

mance. For brevity, we point out

only two notable differences. First, in

HRMD, each service request relates

to a single, small-sized packet, so the

node affected by link failure performs

rerouting only once.

Second, node overhead due to packet

retransmission is limited and mainly

depends on packet size and dead-

line. RAMP sets t wait to deadline/

#retry, where #retry is the numberof retransmissions. RAMP sets #retry

to 15/8 in case of packets smaller than

100/500 Kbytes, thus demonstrating

that it addresses common delay-tolerant

cases, with a proper tradeoff between

limited overhead and aggressive path

searching. However, you could recon-

figure our middleware by dynamically

varying #retry to achieve different over-

head and availability tradeoffs.

RAMP offers the SN com-

munity a middleware pro-

totype for the effective,

dynamic, and application-

driven management of heterogeneous

multihop SNs. RAMP’s management

flexibility addresses the sporadic inter-

mittent nature of collaborations over

SNs and largely counterbalances the

limited overhead imposed by work-

ing at the middleware layer. Our re-

sults have already stimulated furtherresearch activities. We’re now working

on lightweight techniques to dynami-

cally influence path determination

based on the visibility of social relation-

ships and on trust considerations based

on past interactions (stability of collab-

orations, previous mobility patterns,

willingness to offer local resources, and

so on).

REFERENCES 1. P. Antoniadis et al., “Community Build-

ing over Neighborhood Wireless MeshNetworks,” IEEE Technology and Soc.Magazine, vol. 27, no. 1, 2008, pp. 48–56.

2. L.S. Ferreira et al., “Opportunistic Man-agement of Spontaneous and Heteroge-neous Wireless Mesh Networks,” IEEEWireless Comm., vol. 17, no. 2, 2010,pp. 41–46.

3. L.M. Feeney, B. Ahlgren, and A. West-erlund, “Spontaneous Networking: AnApplication Oriented Approach to Ad

Hoc Networking,” IEEE Comm., vol. 39,no. 6, 2001, pp. 176–181.



4. J. Camp and E. Knightly, “The IEEE802.11s Extended Service Set MeshNetworking Standard,” IEEE Comm.,vol. 46, no. 8, 2008, pp. 120–126.

5. L. Pelusi, S. Passarella, and M. Conti,

“Opportunistic Networking: Data For-warding in Disconnected Mobile Ad HocNetworks,” IEEE Comm., vol. 44, no. 11,2006, pp. 134–141.

6. K. Psounis, “Active Networks: Applica-tions, Security, Safety, and Architectures,”IEEE Comm. Surveys & Tutorials, vol. 2,no. 1, 1999, pp. 2–16.

7. P. Bellavista and C. Giannelli, “Internet Con-nectivity Sharing in Multi-Path SpontaneousNetworks: Comparing and Integrating Net-work- and Application-Layer Approaches,”Proc. Int’l Conf. Mobile Wireless Middle-ware, Operating Systems, and Applications (Mobilware 10), Springer, 2010, pp. 84–99.

8. P. Bellavista, A. Corradi, and C. Giannelli,“Mobility-Aware Middleware for Self-Organizing Heterogeneous Networkswith Multi-Hop Multi-Path Connectiv-ity,” IEEE Wireless Comm., vol. 15, no. 6,2008, pp. 22–30.

the AUTHORS

Paolo Bellavista is an associate professor of computer engineering at the

University of Bologna, Italy. His research activities span middleware for mobile

computing to location/context-aware services, adaptive multimedia in wired/

wireless integrated networks to smart space management, and opportunistic

vehicular sensing to mobile agent technologies. Bellavista received his PhD incomputer science engineering from the University of Bologna. He’s a senior

member of IEEE and the ACM. Contact him at [email protected].

Antonio Corradi is a full professor of computer engineering at the Univer-

sity of Bologna, Italy. His research interests include distributed and parallel

systems and solutions, middleware for pervasive and heterogeneous comput-

ing, infrastructure support for context-aware multimodal services, network

management, and mobile agent platforms. Corradi received his MS in electri-

cal engineering from Cornel l University. He’s a member of IEEE, the ACM, and

Associazione Italiana per l’Informatica ed il Calcolo Numerico (AICA). Contact

him at [email protected].

Carlo Giannelli is a postdoctoral researcher in computer engineering at the

University of Bologna, Italy. His research interests include positioning systemsmanagement and heterogeneous wireless interface integration—in particular,

hybrid infrastructure/ad hoc and spontaneous multi-hop networking environ-

ments. Giannelli received his PhD in computer science engineering from the

University of Bologna. He’s a member of IEEE and the Institute for Computer

Sciences, Social Informatics, and Telecommunications (ICST). Contact him at

[email protected].

PURPOSE: The IEEE Computer Society is the world’s largestassociation of computing professionals and is the leading providerof technical information in the field.MEMBERSHIP: Members receive the monthly magazine Computer ,discounts, and opportunities to serve (all activities are led byvolunteer members). Membership is open to all IEEE members,affiliate society members, and others interested in the computer field.COMPUTER SOCIETY WEBSITE: www.computer.org

Next Board Meeting: 5–6 Nov., New Brunswick, NJ, USA

EXECUTIVE COMMITTEEPresident: John W. Walz*

President-Elect: David Alan Grier;* Past President: Sorel Reisman;* VP,

Standards Activities: Charlene (Chuck) Walrad;† Secretary: Andre Ivanov

(2nd VP);* VP, Educational Activities: Elizabeth L. Burd;* VP, Member &Geographic Activities: Sattupathuv Sankaran;† VP, Publications: Tom M.

Conte (1st VP);* VP, Professional Activities: Paul K. Joannou;* VP, Technical

& Conference Activities: Paul R. Croll;† Treasurer: James W. Moore, CSDP;*

2011–2012 IEEE Division VIII Director: Susan K. (Kathy) Land, CSDP;† 2012–

2013 IEEE Division V Director: James W. Moore, CSDP;† 2012 IEEE Division

Director VIII Director-Elect: Roger U. Fujii† *voting member of the Board of Governors †nonvoting member of the Board of Governors

BOARD OF GOVERNORSTerm Expiring 2012: Elizabeth L. Burd, Thomas M. Conte, Frank E.

Ferrante, Jean-Luc Gaudiot, Paul K. Joannou, Luis Kun, James W. Moore,

William (Bill ) Pitts

Term Expiring 2013: Pierre Bourque, Dennis J. Frailey, Atsuhiro Goto,

André Ivanov, Dejan S. Milojicic, Paolo Montuschi, Jane Chu Prey, Charlene

(Chuck) Walrad

EXECUTIVE STAFFExecutive Director: Angela R. Burgess; Associate Executive Director,

Director, Governance: Anne Marie Kelly; Director, Finance & Accounting:

John Miller; Director, Information Technology & Services: Ray Kahn;Director, Membership Development: Violet S. Doan; Director, Products

& Services: Evan Butterfield; Director, Sales & Marketing: Chris Jensen

COMPUTER SOCIETY OFFICESWashington, D.C.: 2001 L St., Ste. 700, Washington, D.C. 20036-4928

Phone: +1 202 371 0101 • Fax: +1 202 728 9614

Email: [email protected]

Los Alamitos: 10662 Los Vaqueros Circ le, Los Alamitos, CA 90720-1314

Phone: +1 714 821 8380 • Email: [email protected]

MEMBERSHIP & PUBLICATION ORDERS

Phone: +1 800 272 6657 • Fax: +1 714 821 4641 • Email: [email protected]

Asia/Pacific: Watanabe Building, 1-4-2 Minami-Aoyama, Minato-ku, Tokyo

107-0062, Japan

Phone: +81 3 3408 3118 •

Fax: +81 3 3408 3553Email: [email protected]

IEEE OFFICERSPresident: Gordon W. Day; President-Elect: Peter W. Staecker; Past

President: Moshe Kam; Secretary: Celia L. Desmond; Treasurer: Harold

L. Flescher; President, Standards Association Board of Governors: Steven

M. Mills; VP, Educational Activities: Michael R. Lightner ; VP, Membership

& Geographic Activities: Howard E. Michel; VP, Publication Services &

Products: David A. Hodges; VP, Technical Activities: Frederick C. Mintzer;

IEEE Division V Director: James W. Moore, CSDP; IEEE Division VIII

Director: Susan K. (Kathy) Land, CSDP; IEEE Division VIII Director-Elect:

Roger U. Fujii; President, IEEE-USA: James M. Howard

revised 22 May 2012

middleware technologies base

Documents