An integrated communication-computing solution in emergency management.

Full text

Page 1

Copyright 2010 ACM 978-1-4503-0062-9/10/06/ ...$10.00.
An Integrated Communication-Computing Solution in
Emergency Management
Carlo Bertolli
Department of Computer
Science
University of Pisa
Pisa, Italy
bertolli@di.unipi.it
Daniele Tarchi
Department of Electronics and
Telecommunications
University of Florence
Firenze, Italy
daniele.tarchi@unifi.it
Marco Vanneschi
Department of Computer
Science
University of Pisa
Pisa, Italy
vannesch@di.unipi.it
Romano Fantacci
Department of Electronics and
Telecommunications
University of Florence
Firenze, Italy
romano.fantacci@unifi.it
Andrea Tassi
Department of Electronics and
Telecommunications
University of Florence
Firenze, Italy
andrea.tassi@gmail.com
ABSTRACT
In the last years an even more attention has been focused on
emergency and crisis management systems. Both communi-
cation and computing aspects are of primary importance
for a fast and reliable response in these particular scenarios.
Differently from other approaches, in this paper we consider
an integrated communication and computing solution, by
proposing a joint approach, where a distributed computing
platform and a heterogeneous meshed communication sys-
tem interoperate in order to enhance the system reliability
and readiness.
Categories and Subject Descriptors
C.1.4 [Processor Architectures]: Parallel Architectures;
C.2.1 [Computer-Communication Networks]: Network
Architecture and Design—wireless communications
General Terms
Algorithms, Design
Keywords
Grid computing, wireless communications
1.INTRODUCTION
Emergency management and disaster recovery systems are
nowadays an issue of paramount importance in communities
throughout the world [4]. Whenever we have to face with the
problem of managing emergency conditions, several aspects
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
IWCMC ’10, June 28-July 2, 2010, Caen, France
need to be considered. In particular, all operators involved
in the management need to be connected among them and
to be supported by a high-performance computing platform
able to forecast the disaster and/or to monitor its evolutions.
In addition, the coordination among different actors work-
ing on the emergency management (institutions, local ad-
ministrators, volunteers, police) is fundamental in order to
optimize the emergency responses and reduce the disaster
consequences on people and things. For these reasons, such
systems are usually comprised of different parts: commu-
nication infrastructures, information management systems,
monitoring networks processing and forecasting structures.
Main aim of this paper is to design an efficient integrated
model to support emergency operations in different scenar-
ios, based on an innovative approach integrating a Pervasive
Grid platform and an efficient wireless communication net-
work [3]. The goal of this integration is to allow a distributed
computing platform to operate on an integrated communi-
cation network characterized by high heterogeneity, mobility
and dynamicity.
Forecasting activities used in Emergency Management ap-
plications are based on very complex mathematical mod-
els, which require high-performance computing to provide
clients with prompt and best-effort services. The classical
solution is to map forecasting models to central process-
ing centers, which support high-performance architectures
(e.g. cluster) and which are geographically far from the
emergency area. An alternative solution is to map high-
performance complex forecasting models to all remotely
available processing and communication resources, which are
even heterogeneous and with limited computational capabil-
ities, but geographically near the disaster area.
This complex mapping problem must be solved dynami-
cally each time the state of the Pervasive Grid changes in
such a way that it affects the application performance. In
this paper we assume that Pervasive Grid applications are
developed in the ASSISTANT programming model (see [2]),
which features the following characteristics:
• application components can be provided in multiple
versions, based on different sequential algorithms and
651

Page 2

Interface Node
Cluster Architecture
WSN
WSN
Interface Node
Remote terminals
Figure 1: The network level for the Emergency Sce-
nario
parallelization techniques;
• versions are dynamically selected to face with context
events. The programmer can define context events to
be sensed and the adaptivity actions to be performed
whenever such events are dynamically verified.
2.THE FORECASTING SCENARIO
Aim of the proposed model is to enhance the forecast-
ing phase of an emergency situation. During the prevention
phase of an emergency we have to face the problem of mon-
itoring a certain environment with the aim of forecasting
the rising of calamitous events. Wireless Sensor Networks
(WSN) can be used to collect data from the environment
and, hence, to provide input data to forecasting models.
The sensor data can be exploited by resorting to specific
forecasting models (that are out of the scope of this paper)
able to give some notice on the future of a certain environ-
mental phenomenon. In order to run the forecasting model a
suitable processing structure is needed; our aim is to exploit
all the possible processing devices in the network in order
to calculate the forecast. For this reason the WSN needs
to be connected to a certain number of electronic devices
with an on-board processing facility, as well as to“classical”
high-performance remote computing sites.
In Fig. 1 it is represented a scheme of this scenario. In
the selected application scenario a WSN monitors the river
area and it provides input data for a forecasting model. The
WSN is connected to interface nodes, providing connectivity
to the larger set of computing resources of the Pervasive
Grid. The system includes also remote high-performance
computing nodes.
3. THE COMPUTING-COMMUNICATION
INTERACTION MODEL
We can see the integrated computing-communication
model as layered; the two levels collaborate to optimize
the application performance in the face of dynamic con-
text modifications. The main idea is that each level adapts
its structure and semantics based on information received
from the other level. That is, the network level dynami-
APPLICATION LEVEL
Application Information
(e.g. ParMods, nodes,
etc..)
Selected Resources
(e.g. links, latencies,
etc..)
NETWORK LEVEL
1
32
Network Information
(e.g. links, latencies,
etc..)
Figure 2: Interaction protocol between application
and network levels.
cally adapts itself by choosing proper technologies and al-
gorithms/protocols by analyzing the application structure,
properly abstracted at the application level. The applica-
tion level dynamically adapts itself by choosing proper paral-
lelism structures and component mappings by analyzing the
information on the network conditions properly abstracted
by the network level. Fig. 2 shows the proposal of interaction
scheme between the levels.
For the sake of the discussion, suppose that we want to
map an ASSISTANT application, composed of multiple par-
allel modules (or ParMods), on a Pervasive Grid platform.
Each ParMod version is denoted as operation: during the
ParMod execution one operation at time can be active (i.e.
is executed). ASSISTANT operations are parallel programs
characterized by static performance models, which describe
the evolution of computing performance parameters depend-
ing on operation mapping and other factors (e.g. network
latencies).
ParMods are functionally connected between themselves
by means of streams, i.e. possibly unlimited sequences of
typed elements. Moreover, ParMods need to interact be-
tween themselves to globally implement some adaptivity pol-
icy. This is done by means of context interfaces, by which a
ParMod is aware of the environment in which it is executed.
Each ParMod operation can be mapped to a different set
of computing nodes (denoted with nodes). The set of com-
puting nodes is dynamically known and provided by some
deployment sub-system. All the information about the com-
puting layer works as an input for the network level (1), dur-
ing the application execution. The network level selects all
the possible choices of links between ParMod operations: for
each linked operations mapped on each possible nodes the
network level characterizes all the possible networks to link
them. Each network is associated with a communication
latency cost which depends on several factors, such as the
used network technology and the number of hops between
the nodes. These choices are passed to the application level
(2).
At the application level we can now fill up the performance
models with all the possible choices and select the best con-
figuration of ParMods. The best operation for each ParMod
is chosen according to local requirements (e.g. optimal ap-
plication performance) but also by considering other appli-
cations based on the same network infrastructure (e.g. voice
applications, which require network high-performance).
When the application level has selected the networks to
be used, it passes them to the network level (3), possibly
updating the required communication latency. For instance,
652

Page 3

IN
EC
W
W
U
Forecasting Module
data point
X,Y components
WSN
. . .
S
G
W
WW
W
. . .
. . .
. . .
task farmdata parallel
Clients
Figure 3:
nario: the forecasting module is provided in the task
farm and data parallel versions.
Representation of the Emergency Sce-
suppose that a logical network link supports X latency, but
the application actually requires only Y , (e.g. because of
clients’ requests or performance reasons), where Y < X. In
this case the application level notifies to the network one
that it just needs Y for that link. The network level re-
ceives this information and it applies adaptation algorithms
to guarantee the application level with the requested perfor-
mance.
4.ELEMENTS OF THE SCENARIO: DE-
VICES AND INFORMATION STREAMS
The emergency scenario can be modeled as constituted by
multiple elements. Among others, our attention is focused
on the devices and the information streams: while devices
are more connected to the computing aspects, information
streams are more connected to the communication aspects.
However, as discussed previously, our aim is to propose a
unique vision of the problem by considering both aspects
jointly.
4.1 The Devices
Input data reflect the discretization of the monitored area
in points, each characterized by certain parameters, depend-
ing on the monitored environment, the used forecasting
model and the type of emergency to be foreseen. We as-
sume that a single module IN collects all the sensed data
from the WSN (see Fig. 3). IN sends the input data to a
forecasting module. The forecasting module sends results to
the clients in real-time or by performing some buffering. In
this scenario, results are force components over each input
point.
The forecasting module is expressed as a ParMod. Here,
we consider the case in which we have provided two opera-
tions: the first one is based on a task parallel structure, while
the second one on a data parallel scheme. Broadly, these
parallelism schemes feature different performance character-
istics:
• Task Farm: the input tasks received from the WSN
are scheduled (task emitter E) w.r.t.
cated workers (W) according to a load balancing strat-
egy, each worker executing the sequential algorithm.
An output stream of results is produced, as a collec-
tion (C) of worker results. As known, this parallelism
paradigm does not decrease the processing latency of
a single element of the stream, but it decreases the
service time (increases the throughput), provided that
several repli-
the stream interarrival time is sensibly less than the se-
quential processing time (stream processing situation
in the true meaning).
• Data Parallel: each input task is scattered (S) onto
several replicated workers (W), each one performing
the sequential algorithm for its respective partition.
Depending on the forecasting model, workers may co-
operate during each step according to a proper com-
munication stencil. The whole result is obtained by
gathering (G) the partial results. With respect to the
farm structure, this parallelism paradigm works both
in a stream processing situation, and when only a sin-
gle system has to be processed (i.e. equivalently, when
the stream interarrival time is greater than the sequen-
tial processing time for a single task). Moreover, it is
able to decrease the processing latency of a single task
system and the memory size per node. In a stream sit-
uation, the disadvantage of a stencil-based data paral-
lel structure, w.r.t. the farm paradigm, is a potential
load unbalance and a more critical impact of the com-
munication/computation time ratio, thus in general a
greater service time.
The ParMod adaptivity is based on dynamically selecting
the best possible version depending on the actual situation
in which the application is executed. The dynamic selection
is based by considering the application as a whole: in the
described scenario the forecasting module service time can-
not be lower than the WSN one and it must be optimized to
fulfill the client requests. When a specific performance tar-
get for the ParMod is known, we apply performance models
of the described parallelism schemes to select the best ver-
sion to execute and its implementation (e.g. its parallelism
degree). Performance models must be instantiated to the
actual configuration of the parallel nodes on which an oper-
ation is mapped. We show how to jointly use performance
models of task farm and data parallel with network infor-
mation to provide a network-aware adaptation of parallel
computations.
The devices considered as target nodes for the described
operations are:
• a cluster architecture, modeling a centralized server;
• an interface node, featuring a multicore;
• a network of mobile devices.
4.2The Information Streams
The emergency scenario can be seen as an interconnection
of several different nodes with different link types; if the
difference in the node type has mainly an impact on the
application level, the link type has an effect on the network
level.
Each type of link can be implemented with different com-
munication technologies. Among others, our attention will
focus on the most promising:
• Within the WSN we expect to use an IEEE 802.15.4
compliant network;
• Between WSN and the local area network formed by
interface nodes, users terminals and low-end user de-
vices we expect to use IEEE 802.11a/b/g/n or IEEE
802.16-2009 links, both assuring high data rate with,
respectively, a low or a high coverage area;
653

Page 4

• Between monitoring area, Cluster and remote termi-
nals we expect to use IEEE 802.16d/e or GPRS/UMTS
links, both assuring medium to high data rate within
a high coverage area;
At this level several adaptation strategies can be defined
depending on the targeted network technology: in emer-
gency scenarios we are mostly interested in wireless network
technologies. Their intended use is to support mobile com-
puting nodes, which in the emergency scenario can corre-
spond to mobile users near the emergency area. As hinted,
if for several reasons we cannot map the forecasting activi-
ties in centralized computing areas, we can use decentralized
mobile nodes. This mapping rises performance issues, as we
must guarantee a minimum level of Quality of Service on
unconventional performance-critical platforms.
In our vision, we can think to define a wireless routing
protocol enabling resource selection based on both link per-
formance (e.g. transmission latencies) and computing node
one. For computing nodes, we can keep updated comput-
ing information, e.g. related to current computing load, on
each node running the routing protocol. This information,
along with communication latency information, will be used
to solve the mapping problem of ASSISTANT components
to available resources.
We consider the notable case of a set of mobile nodes in-
terconnected by a wireless network. At the level of routing
protocols, we can think to logically organize mobile com-
puting nodes in clusters characterized by increasing network
ranges (e.g. from 1-hop to N-hops clusters). On one hand,
lower range clusters provide higher communication latency
performance, but they usually aggragate a lower number of
computing nodes, which influences the computing perfor-
mance. On the other hand, larger range clusters provide
higher parallelism degrees, but at the cost of a higher com-
munication latency.
4.3The joint vision
Depending on the computational model to be used we can
map the application over the network by using two differ-
ent classes: centralized cluster architecture or distributed
architecture (i.e. interface node or mobile devices).
As represented in Fig. 1, we can model the network in
different areas. A local area network near the source (i.e.
the WSN), a cluster area, a remote control area; some other
areas may exists (e.g. an intermediate supervision area, or
network setup by other organizations as, civil emergencies,
fire departments), but they have not been reported here to
keep clearer the scheme. The interaction among the com-
puting and communication layers works by selecting for each
elaboration the most favorable area, choosing each time dif-
ferent areas or groups of devices within the same area.
As hinted, ParMod operations are designed to be mapped
to a central cluster architecture or to decentralized dis-
tributed devices. Aim of the interaction between applica-
tion and network level is to select the best mapping at two
different levels:
• at the level of operations: in this case we want to se-
lect the operation (task farm or data parallel) and its
mapping (cluster, interface node or mobile devices).
As described above, this choice depends on ParMod
boundary conditions, such as the WSN service time
and the clients’ requests. In the joint vision, we have
to consider also network latencies between the WSN,
the nodes on which an operation is mapped and the
clients. For instance, if we select to map the task
farm operation to the cluster architecture, we need to
guarantee that the network latencies WSN/cluster and
cluster/clients do not overwhelm the module service
times. If this happens, we may modify the operation
mapping to a parallel node nearer the emergency area;
• at the level of implementation of operations: when
an operation is mapped to distributed possibly mobile
nodes we can optimize process mapping and worker
scheduling by considering also the latencies between
the used computing devices.
consider process service times and network latencies
between interacting processes: in the task farm this
means that we adapt the load balancing strategy by
considering also network latencies; in the data paral-
lel scheme we have also to consider possibly existing
communication stencil between workers.
For instance, we can
In details, by using parallelism performance models we
can set up a specific coordination protocol between the ap-
plication and network levels to support mutual adaptivity.
In our vision, there are at least two different instants of time
at which the coordination protocol should be applied:
• when we need to select the best operation to be ap-
plied: this decision is based on information which may
not be necessarily updated. For instance, sequential
computing times can be estimated for unloaded nodes;
• when we have selected and mapped an operation, we
can dynamically modify its implementation (e.g. its
mapping and parallelism degree) by considering up-
dated information from the used resources.
As described above, the second point can be efficiently sup-
ported by the routing algorithm, by using automatically up-
dated information. In practical terms, if we consider the
cluster-based scheme described above, the solution to the
performance optimization problem can be reduced to select
the most appropriate PDA cluster. The ASSISTANT per-
formance models can be used to guide the selection of the
best solution by considering the trade-off between cluster
range, in terms of number of hops, and parallelism degree.
5.DISTRIBUTED ELABORATION MAN-
AGEMENT AND PRELIMINARY RE-
SULTS
In this section we will introduce the proposed elabora-
tion management and some preliminary results. We may
consider three different situations within the complex emer-
gency scenario represented in Fig. 1.
The three scenarios differ in terms of network availability.
The first scenario considers that the remote cluster can be
reached and so it is selected as the processing structure. The
second one consider the case when, due to some disruptive
situations, the local area are disconnected among them. In
that sense the forecasting model can be executed only on the
devices near each WSN. The third scenario, an intermediate
one, consider the presence of some multicores near the mon-
itoring area in order to realize a local centralized processing.
654

Page 5

Table 1: Forecasting module service time with dif-
ferent operations by varying the system size.
System Size Data Parallel
1MB0.012351
2MB0.028971
4MB 0.063581
8MB 0.276229
16MB0.609525
32MB1.318157
Farm
0.013232
0.029764
0.063721
0.133913
0.270212
0.558197
We have performed numerical results to validate the perfor-
mance of the second and third scenario, which in our vision
are the most innovative, and hence, critical ones related to
the relationship between application and network level.
The local area has a number of PDA equal to 2, 3 or 4;
each PDA can move within the area; the mobility model
is the Random Waypoint Model with a maximum speed of
3 km/h. The PDA within the local area are connected by
using an IEEE 802.11g network, and the WSN is modeled
as a source able to generate one point for each time interval
that is uniformly distributed between 5 s and 300 s. In all
cases, we tested the network latencies for result size of the
order of 1 MB. The preliminary numerical results obtained
by using the Omnet++ simulation framework [1], where the
above described scenario has been modeled.
The performance parameter in which we are interested in
the client service time, i.e. the time passing between two
successive deliveries of results from the forecasting model.
This depends on both processing times and network laten-
cies, according to performance models of used structured
parallel programs.Broadly, the network latencies should
not be higher than the service times of the application bot-
tleneck, which in our application is the forecasting module.
We performed experiments on a forecasting model based
on mass and momentum equations to describe the evolution
in time of a 2-dimensional river basin [5]. The main compu-
tation consists in solving streams of tridiagonal systems. We
tested different sizes for the systems (see Tab. 1) on a task
farm and a data parallel versions mapped to an interface
node featuring a multicore processor. The interface node
supports an Intel E5420 Dual Quad Core multicore proces-
sor, featuring 8 cores of 2.50 GHz, 12 MB L2 Cache and 8
GB of main memory.
Tab. 1 shows the service times of the forecasting in dif-
ferent situations, by using the maximum parallelism degree
available. For comparison, we provide experimental results
of the latencies between the multicore and the PDAs (see
Fig. 4). In the figure we show the End-to-End delay for
trasferring messages from the multicore to the PDAs.
As it can be noted, in the worst case we have to pay a com-
munication latency below 0.005 seconds. In contrast, the
minimum service time which can be obtained with proper
forecasting configuration is 0.012351. Thus, we can conclude
that the mapping of forecasting module to decentralized pro-
cessing nodes can achieve desired performance by choosing
proper configurations of the forecasting models.
6.CONCLUSION
The focus of the paper is on the proposal of a novel inte-
grated scheme among a communication infrastructure and
a distributed computing platform for enhancing the system
0.003
0.0035
0.004
0.0045
0.005
200 400 600 800 1000 1200 1400 1600 1800
client service time(sec.)
time (sec.)
S0
S1
S2
S3
Figure 4: E2E delay in seconds with a different num-
ber of local areas and PDAs for local centralized
processing.
reliability and readiness in calculating complex mathemati-
cal models. To show the our approach is effective we have
described a possible instantiation of the integration between
application and network levels to support ASSISTANT ap-
plications. The core idea of the presented instantiation re-
sides in using performance models of ASSISTANT parallel
applications to guide the selection of the best available com-
munication and computing resources.
formed experiments to show that also in a performance-
critical situation our approach can find a solution, in terms
of resource selection, providing the user requested perfor-
mance.
We have also per-
7.ACKNOWLEDGMENTS
This work was supported in part by MIUR-FIRB In-
tegrated System for Emergency (InSyEme) under Grant
RBIP063BPH.
8.
[1] OMNeT++ community site.
http://www.omnetpp.org/.
[2] C. Bertolli, D. Buono, G. Mencagli, and M. Vanneschi.
Expressing adaptivity and context awareness in the
ASSISTANT programming model. In Autonomic
Computing and Communications Systems, volume 23 of
LNICS, pages 32–47. Springer, 2010.
[3] R. Fantacci, M. Vanneschi, C. Bertolli, G. Mencagli,
and D. Tarchi. Next generation grids and wireless
communication networks: towards a novel integrated
approach. Wirel. Commun. Mob. Comput.,
9(4):445–467, 2009.
[4] I. Habib and F. Mazzenga. Wireless technologies
advances for emergency and rural communications.
IEEE Wireless Communications Magazine, 15(3):6–7,
June 2008.
[5] J. Thompson, H. R. Sorensen, H. Gavin, and
A. Refsgaard. Application of the coupled MIKE
SHE/MIKE 11 modelling system to a lowland wet
grassland in southeast England. J. of Hydrology,
293(1-4):151–179, 2004.
REFERENCES
655