Electronic Triage Tag and Opportunistic Networks in

Disasters

Abraham Martn-Campillo ,
Ramon Mart

Eiko Yoneki and Jon Crowcroft

Systems Research Group
University of Cambridge
Cambridge, United Kingdom

Dept. of Information and Communications

Engineering
Universitat Autnoma de Barcelona
Bellaterra, Spain

eiko.yoneki@cl.cam.ac.uk,
jon.crowcroft@cl.cam.ac.uk

abraham.martin@uab.cat,
ramon.marti.escale@uab.cat
ABSTRACT

Keywords

The use of electronic devices such as sensors or smartphones

in emergency scenarios has been increasing over the years
with new systems taking advantage of their features: mobility, processing speed, network connection, etc. These devices and systems not only improve victim assistance (faster
and more accurate) but also coordination. One of the problems is that most of these systems rely in the existence of a
network infrastructures, but usually in big disasters, or mass
casualties incidents, these infrastructures become saturated
or destroyed by the very nature of the emergency. In this paper we present MAETT and Haggle-ETT, two applications
that provide electronic triage tags (ETTs), a digital version
of the classics triage tags, based on mobile agents and opportunistic networks, respectively. These systems are able
to work even without network infrastructures using ad-hoc
networks to forward the ETTs to a coordination point where
they will be processed.

Delay Tolerant Networks, Emergencies, Triage Tag, Opportunistic Networks, Disasters

Categories and Subject Descriptors

C.2.1 [Computer-Communication Networks]: Network Architecture and DesignWireless Communication;
C.2.2 [Computer-Communication Networks]: Network ProtocolsRouting protocols

General Terms
Design
corresponding author

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.
ACM SWID 2011, December 6, 2011, Tokyo, Japan.
Copyright 2011 ACM 978-1-4503-1044-4/11/0012 ...$10.00.

1.

INTRODUCTION

With the increase in the usage of the Internet and

smartphones in recent years, their role in the recovery
of emergencies has become essential [22]. One of the
most important elements in emergencies is the information generated during the emergency, e.g. triage data or
location of a victim. Having this information helps the
coordination of the emergency recovery and provides
a fast response. But these data suffer from two problems. Firstly, some data are usually not transmitted,
or transmitted by traditional mechanisms like voice radio or even written annotations, as is the case of paper
triage tags for triage information. Secondly, some systems used in emergency scenarios rely on a network infrastructure that may have been destroyed by the very
nature of the emergency or may be unstable or inaccessible due to its over usage [2]. Because of this, the
use in these scenarios of ad-hoc opportunistic networks,
focused on scenarios with intermittent network connectivity in the absence of end-to-end communication infrastructures, is very appropriate.
In this paper, we present MAETT (Mobile Agent
Electronic Triage Tag) [13][9][21] and Haggle-ETT [14],
that allow the triage data to be collected and represented in an electronic format and to be transmitted,
to a coordination point where they will be processed
and made available for the managers of the disaster recovery, even if no network infrastructures are present.
Thus, these applications provide a collection of additional information for a better coordination and a faster
response.
MAETT and HaggleETT provide the same features
but are based on different paradigms. MAETT uses
Mobile Agents [5] for storing the Electronic Triage Tag

information. Moreover, Mobile Agents are used as the

mechanism for forwarding the information. They can
carry data and jump from platform to platform using
different strategies in their code. Each Mobile Agent
can have its own code, different from others Mobile
Agents (with other algorithms, forwarding mechanisms,
etc), and can carry data generated in different visited
nodes. On the other hand, HaggleETT is based on
Haggle [1] networking architecture for content-centric
opportunistic communication. Haggle allows mobile devices to exchange content directly between themselves
whenever they happen to come in close range without
requiring a network infrastructure.

2.

DISASTERS RECOVERY PROCESS

The two systems presented in this paper are specially

useful on mass casualty incidents (MCIs), whose main
characteristic is the large number of victims. In these
cases, the triage of these injured victims is needed to
sort them into groups based on their need for immediate medical treatment. This triage is done by the first
response personnel arriving at the emergency scene, so
the medical personnel arriving later know those victims
who need more urgent attention. The victims are stabilised in triage colour order (black, red, yellow and red)
before they are evacuated to the hospital or to the advanced medical post where they will be treated widely.
There are a number of triage protocols for emergency
situations, however, the START protocol [7] and the
Triage Sieve and Sort [23] are the most widely used.
Both create four groups of victims based on their condition. The first group, from worst to best condition,
is the black one, that is assigned to those victims that
are dead or in a very bad status, impossible for the
medical team to do something to save their lives. The
second group, red, are victims who need immediate attention. The victims in the third one, yellow, do not
need immediate but urgent medical attention, that can
be delayed for a short period of time. And finally, the
green group, is for victims with minor injuries who do
not need urgent help.
Once the triage is complete, rescue teams extract
those victims who are trapped or cannot move from the
hot spot to a safe place. The incident location is also
known as zone 0. In this area the medical personnel cannot work because of a risk of danger such as explosion or
contamination. Because of this, it is important for everybody to evacuate this area and for the rescue teams
to extract the victims that cannot move. While rescue
teams are doing their job, the medical personnel treat
those victims in the red group that have already been
evacuated and are in the patients waiting for treatment
area, also known as zone 1.
If Advanced Medical Posts (AMPs) or casualties clearing stations are installed, the victims are evacuated to

this place (see Figure 1). An AMP is a mobile hospital

to treat the victims before they can be transferred to
an hospital. In mass casualties, where it is necessary to
treat lots of victims in a serious condition, AMPs are
essential and have to be installed near but in reasonable
distance from the zone 0 to be a safe place.
The main objective of the medical personnel in the
area regarding the victims in the red group is to stabilise them. Once the stabilisation is done, the rescue
vehicle is called to pick up the victims to transfer them
to the hospital. After the red victims, the yellow ones
are treated in the same way. Regarding the green ones,
they are arranged together and then transferred with
low priority to other hospitals or medical institutions
using any available transportation.
The Advanced Command Post (ACP) is where the
coordination team is, and where all the decisions about
actions to be carried out by rescue and medical teams
are taken.
It is necessary to consider that in a big emergency
more than one hot spot or local emergency can exist.
During these local emergencies, for instance in a hurricane, each house devastated or vehicle crashed, can
share the meeting point, AMP and/or ACP or have its
own for each one if they are big enough. Usually, if the
emergency has multiple hot spots or local emergencies,
a crisis committee is created to manage and coordinate
all the emergency in collaboration with different ACPs
installed.

Figure 1: Emergency Scenario

2.1

Communications in the emergency scenario

Previously emergency communications were only a

matter of walkie-talkie communications, but nowadays
they are becoming more and more advanced. This is due
to the greater use of Internet enabled devices or mobile
phones by the emergency personnel, that require mobile
networks such as mobile phone network (3G) or WiFi.
In the great majority of emergency cases, hurricanes,

terrorist attacks, flooding, etc, these networks become

unstable, inaccessible, overused or even destroyed. As
a consequence, emergency personnel cannot rely on the
use of existing network infrastructure and may deploy
and use their own [12][11], or simply use wireless mobile ad-hoc networks (MANETs) [16][20][15][11]. These
networks create routes by request of the nodes that are
maintained as long as they are needed or the link is
available.
Anyway, all these solutions have the same lack: because of the mobility of the devices (or if the area of
emergency is big enough) a continuous end-to-end connection cannot be guaranteed. As a result, an attempt
to communicate from one point of the network, for instance, a first responder, to another point, for example
the AMP, could be unsuccessful as this kind of networks
needs an end to end communication. In these cases, opportunistic networks can be used; even if a message is
required to arrive as soon as possible once it has been
generated, the time to arrive to any part of the disaster area will require less time than deploying all the
nodes necessary to create an infrastructure network or
a fully-connected MANET
Regarding the AMP and ACP, it can be supposed
that they have always Internet connection even if the
network infrastructures are destroyed or unusable. They
use their own deployed network infrastructure, for instance, satellite connections. For the AMP and the
ACP, it is very important to have Internet connection
for coordination or information communications (f.e.
with another coordination point or with hospitals assigned to victims). From this point of the paper we will
talk about AMPs and ACPs as coordination points, the
only points of the emergency scenario where there are
network connection.

3.

ELECTRONIC TRIAGE TAG SYSTEM

Previously in this paper two applications have already

been introduced: MAETT and Haggle-ETT. Both applications make use of the same core, our Electronic
Triage Tag System, that is in charge of the creation
of the Electronic Triage Tags (ETTs). MAETT and
Haggle-ETT will have different methods for carrying,
storing and forwarding the ETTs to a coordination point
using opportunistic networks but both share the core
system in charge of the creation of the ETTs.
Triage personnel is equipped with handheld devices
with GPS, and a RFID reader units (Figure 2). When
a victim is found, she is labeled with a paper triage tag
containing an RFID tag attached that provides the ability to uniquely identify the victim within the emergency.
The paper triage tag allows a quick visual identification
of the victims injury level. An RFID tag is a good
and fast solution to combine both Electronic and Paper
Triage Tag and identify the victim in both of them in a

Figure 2:
reader

Nokia MAEMO n810 and RFID

Figure 3: RFID reader software, TTR and software settings

uniquely way. Before labelling the victim, the staff shall

approach the electronic triage tag to the RFID reader
that will read their unique ID (Figure 3). After that,
a software assistant is activated to help staff to assess
the state of the victim (Figure 4). This software provides all the steps required to follow the START protocol (breathing, pulse, answers to simple questions, etc.)
to perform the triage.
The software interface of the wizard (Figure 4) is simple, with intuitive icons, short and understandable text,
and large buttons that facilitate the use of the touch
screen. Furthermore, its use is optimal for triage because it does not increase the time devoted to follow the
START protocol (which must be as short as possible)
and benefits from the available data already digitalised.
Once the process has been completed, an injury level
is proposed by the application based on the data provided by the user using the wizard: green for MINOR,
yellow for DELAYED, red for IMMEDIATE, and black
for DECEASED. This status can be accepted or may
be changed to another one that the user considers more
appropriate. The wizard can be turned off if the situa-

to other emergency personnels smartphone in order to

allow the ETTs to get to the emergency coordination
point as fast as possible. Mobile Agents and Haggle accept any existing opportunistic routing protocol but this
is an important part of the application as it has a high
impact on the message delivery performance. Hence,
choosing the appropriate forwarding algorithm is critical. This algorithm will be in charge of making the
decisions of relaying or not an specific ETT to another
emergency personnels smartphone in order to make it
arrive sooner to a coordination point.

3.2
Figure 4: START protocol assistant for the
triage of victims

Figure 5: Electronic Triage Tag

tion requires it to show the selection screen color (state)

just to read the RFID associated with the paper triage
tag.
After estimating the state (colour) of the victim, the
software will read the GPS device position where the
staff, and therefore the victim, is at that time, and an
Electronic Triage Tag with all this information (Figure
5) will be created. Additionally, the staff will assign the
same injury level colour to the paper triage tag of the
victim.

3.1

Electronic Triage Tag

The electronic triage tag (ETT) created after the

triage (Figure 5) will include the status (color of the
triage tag) of the victim, the GPS position, the unique
identifier of the triage tag, and the patients vital data
(pulse, respiration, etc). Other possibilities could include an additional photo of the situation of the victim
or the victim itself.
The ETTs will be stored in the personnel smartphone
for later being transferred to the coordination point.
While the personnel is working in the Zone 0, the system will forward the ETTs stored in their smartphone

Coordination point

The coordination point system is where all ETTs are

delivered. This system may be distributed, i.e., it may
comprise more than one server that will be able to exchange data, since they are connected to each other.
The coordination point has a wireless network access
point to allow communication with the smartphones arriving from the emergency, as well as a wired or wireless
internet connection for coordination outside the emergency area.
Furthermore, the coordination point system keeps all
the information gathered by all the staff. It may know
the position of the victims, their status, and whether
there are special needs for each one. This eases the
task of planning routes for the collection of the victims
by placing higher priority on those that have been selected for such, and helps the emergency organisation
and management staff to have a clearer idea of the distribution of victims.

4.

FORWARDING

Smartphones usually have three network interfaces:

HSPA/GSM, wifi, and Bluetooth. The first one can
not be used for opportunistic networks. Bluetooth has
only a range of 10 m and the transfer speed is very low.
In big scenarios with a low density of nodes, nodes will
not approach each other at these small distances. In
mass casualty incidents there are a lot of victims and
the first responders are fewer in number, hence they are
far from each other. Moreover when two first responders approach each other, the contact time will be small
because they usually run in those scenarios, so the faster
the transfer speed, the more data will be interchanged.
Hence, even though wifi has a high energy consumption, it will be the best option for opportunistic communications in emergency scenarios. Furthermore, the
wifi will be working in opportunistic mode, therefore it
will not be able to enter into low energy mode. That
said, in order to reduce this high energy consumption
(very important in mobile devices running on battery)
and also have a good delivery ratio we should use an
appropriate routing algorithm.
Regarding data, one can think that using an epidemic

method is the best option, but the use of broadcastbased forwarding approaches (where multiple copies of
the same data is spread throughout all the network)
has two problems. The first one is the energy efficiency.
Since data transfer using wifi is the most energy consuming process in a handheld device [18], each data
transfer consumes a lot of energy. For this reason it
is important to select a forwarding algorithm that does
not waste a lot of energy relaying unnecessary data.
The second problem occurs in cases with a high number of messages because due to the short contact times
it is not possible to forward all the data in a node, so it
may also require some kind of data forwarding priority
management.
But choosing the right forwarding method for the application depends also on a number of factors: the number of first responders working in the zone 0, the number of victims, the size of the ETT, the buffer of the
device, and the energy consumption of the device using
the network.
For these reason we created the Time To Return (TTR)
routing method, a simple mechanism to forward data
only once per node (energy efficient) with good delivery
performance thanks to taking advantage of the use of a
time that it is usually used in disasters but never used
in applications.

4.1

Time To Return

Time To Return (TTR) routing protocol is based in

the fact that for coordination issues, each actor in the
emergency knows when she will return to the coordination point. When coordinating an emergency, the staff
dedicated to the rescue must be controlled because there
is a risk of danger. Therefore, protocols to follow and
a time indicating when each staff must return to the
coordination point are defined. This TTR is allocated
by the coordinator of the emergency and set up into the
smartphone rather manually or automatically from the
software in the coordination point.
When a node finds several neighbours around, they
will interchange their TTR. If there is one or more
neighbour with lower TTR, the ETTs in the node will
be forwarded to the device with the lowest TTR, indicating that this is the staff that will return to the
coordination point earlier and therefore will deliver the
ETTs sooner, a priority in emergency scenarios.
It is important to say that the TTR value of a node
can be changed at any time if the schedule of the personnel is changed: if she has to return before than initially planned or if she has authorisation to be in the
emergency scene a longer time. Furthermore, other factors can force decisions to change the TTR value, as
the battery life of the mobile device. The maximum
time of the TTR always has to be the maximum time
of battery left. Otherwise all the data in the device will

Figure 6: TTR protocol

not be forwarded and they will not be communicated

to the coordination point until the battery is recharged,
ending up in a critical medical information delay.

4.1.1

Protocol

The TTR has to be set up at the beginning of the

emergency in each node. Once the node has a valid
TTR value, each time two nodes come into contact they
interchange their TTR. The TTR values are compared
and the ETTs are forwarded, if required, to the node
with the lower TTR.
The TTR of the contacted nodes is stored, so if two
nodes come into contact again in the future they will
not interchange their TTR again except in the cases
when the TTR has been modified.
It is possible that a node does not come into contact
with another node during their way. If this happens,
the time that ETTs would require to arrive to a coordination point would be the TTR left in the node when
the victim was found and triaged. A scheme of this
protocol can be found in figure 6.

4.2

Evaluation

We have tested the performance of the TTR along

with other opportunistic forwarding methods in a simulated emergency scenario. We have to take into account
that the delivery ratio performance will be always 100%

as eventually all the nodes will come back to the coordination point. Hence, for measurements we will use
the CDF delivery delay and the delivery cost (number
of messages relayed per messages created), two important metrics used to evaluate opportunistic network and
routing protocols performance. The CDF delivery delay represents the difference between the time when a
message is delivered and its creation time.
The traces used for the simulation have been generated by the Bonnmotion tool. BonnMotion [17] is an
application that generates traces of different types of
scenario. One of these scenarios is disasters. They create mobility traces based on the analysis of the disaster
scenario created for the preparation of the FIFA world
cup in Germany [3]. This mobility model for disasters is
useful for defining zones of an emergency. The incident
location where the victims are found (Zone 0); patients
waiting for treatment area (Zone 1, where coordination point is); casualties clearing stations; the ambulance parking point and the coordination, or meeting,
point. The parameters for the generations of traces can
be found in table 1.
Once the traces are generated with the BonnMotion,
we use them as an input of the ONE simulator. The
ONE simulator [10] is a simulation environment specially designed for opportunistic networks simulation.
It supports different routing algorithms in the nodes
and sender and receiver types (with different characteristics in interfaces for example). A link speed of 54
Mbps and a radio range of 60m are the values defined
for all the nodes. The link speed is chosen using the
802.11g standard, the simulator is in charge of changing the speed rate depending of the distance between the
two nodes. As for the maximum radio range, we carried
tests using iPhones 3GS that gave us an average result
of 60 meters. We tested the radio range outdoor with
obstacles (typically for disaster scenarios). The radio
range is a parameter that can change depending of the
device the user is using. We also tested the maximum
data transfer rate for the wifi network (802.11g) of the
iPhone 3GS with a result of 6,4 Mbps. The duration of
the simulation is 6000 seconds.
We have chosen a message size of 225kB. We have
calculate this size for a message containing text and
a small size photo. We have supposed a mass casualty incident hence a total number of 2000 messages are
created during the simulation (100 minutes). The messages can be Electronic Triage Tags or messages with
information about the emergency scenario. A size of 10
MB has been chosen for the buffer size of each node,
so each node will be able to store up to 45 messages
each node before it starts rejecting messages because
the buffer is full. Each node will create an average of 33
messages throughout the simulation, so each node has
buffer space to store more messages, even if it is not

able of deliver any of his created messages.

Using bluetooth v2.1 + EDR included in most of
todays smartphones (with a maximum practical data
transfer rate of approximately 2Mbps) would require 1
second to transmit a message under optimal conditions
(sender and receiver very close one each other). Using
802.11g would require 274 ms based on the maximum
data transfer rate measured. But the best advantage of
using wifi is that the radio range is 8 times larger than
the bluetooth, so more contacts will occur. We also
have to take into account that as larger the distance is
between the sender and the receiver, the lower the data
transfer rate is. Therefore, the average data transfer
speed will usually be much lower than 6,4Mbps.
Table 1 sums up the simulation parameters.
Parameter
Number of nodes
Zone 0
Zone 1
Simulation time
Radio range
Buffer size
Number of messages
Message size

Value
60
1300x250 m
100x40 m
6000 s
60 m
10 MB
2000 messages
225 kB

Table 1: Default parameters

The following routing methods have been tested in

the simulations: Epidemic, First contact, PRoPHET,
MaxProp and TTR. Epidemic method has been chosen
because of its fast message spread but also because it
floods the network due to the replication of each message to the rest of the nodes. Its a reference for other
routing methods. First contact is different from others
methods as it only keeps one copy of the message in all
the network. So, when a node sends the message to another node, it deletes its copy of the message. This in
an interesting routing method for its very low delivery
cost. It is very simple and follows no intelligent algorithm so we cannot expect good results. PRoPHET is a
probabilistic routing method that aims to improve Epidemic routing with lower overhead and higher delivery
ratio due to the use of probabilities. It is interesting to
see how it works in disaster areas. MaxProp does an
estimate delivery likelihood and adds some rules to the
decision as to give forwarding preference to low-hopcount messages, to free up storage of delivery messages
or to not forward the same packet twice to the same
next hope destination. This add-ons are important as
they give a congestion control to MaxProp interesting
to test. This method has very good results applied to
vehicular networks and wed see if they achieve similar results in disaster areas. TTR is a routing method

specific for disaster areas, so it is interesting to see its

performance. It only keeps one copy of the message in
all the network as First contact, hence it is important
to compare its performance in delivery versus cost.

4.2.1

Results

1
0,9
0,8
0,7

CDF

0,6
0,5
0,4
0,3
0,2
0,1
0
0

1000
MaxProp

2000
Epidemic

3000
Delay (sec)
ProPHET

4000

5000

FirstContact

6000
TTR

tasks. Mobile agents technology [24] has its origin on

two different disciplines: artificial intelligence (intelligent agent) [25] and distributed systems (code mobility)
[6]. The main characteristics are: Autonomy, reactivity,
proactivity, sociability and mobility. Mobile agents can
give the application the following advantages: task delegation, asynchronous processing, dynamic environment
adaptation, flexible interfaces, fault tolerance, parallelism and local data processing.
The ETTs are created in the form of a mobile agent.
The mobile agent includes all the information of the
ETT: the status (color of the triage tag) of the victim,
the GPS position, the unique identifier of the triage tag,
and the patients vital data (pulse, respiration, and so
on).
This mobile agent will be stored in the personnel
smartphone. If a mobile agent finds a neighbour with a
lower TTR, it will jump to this platform. This decision
is taken by the application level routing protocol used
by the mobile agent, the TTR, as explained before on
section 4.1.

Figure 7: Delivery Delay CDF

Routing
MaxProp
PRoPHET
Epidemic
FirstContact
TTR

Delivery cost
382
121
100
9
2

Table 2: Delivery cost

The results from the tests that can be seen in the

figure 7 and the table 2 show that MaxProp is clearly
the forwarding method with better delivery delay but
also with a very high delivery cost. The TTR have
a good delivery delay and the best delivery cost from
the forwarding methods compared. Hence, it will be the
method with less energy consumption as it interchanges
less data than others.

5.

MOBILE AGENT ELECTRONIC TRIAGE

TAG

Mobile Agent Electronic Triage Tag is the version

of the Electronic Triage Tag System based on mobile
agents. Mobile agents are software entities that can
suspend their execution on a host, move to a different
location and resume their execution. The agents use
platforms as an run-time environment. These platforms
can be distributed in different hosts or in the same.
The agents will move, or jump, from platform to platform, if needed, until they have accomplished all their

Figure 8: Electronic Triage Tag based on Mobile

Agents
Routing, from the viewpoint of the mobile agent, is a
decision algorithm, at application level, to decide which
platform to jump from a set of platforms or devices, or
whether it is better to stay on the current platform.
In the same way that the routing algorithms at network level, the initial step is to exchange information
between nodes, in the case of mobile agents exchange is
done through ACL messages. The platform is the agent
that is responsible for providing a service for reporting
information and the mobile agent to carry out a request
to obtain this service.
It is worth mentioning that mobile agents can move
through more than one device without having to jump
one by one to all platforms agent devices from location
to destination. Using the coverage of the smartphones
of the staff a network can be created able to reach the

Figure 10: Android Version

Triage
Application

Triage
Application

(1)

(1)

(2)
HAGGLE
TTR
manager

Device

Figure 9: Android Version

HAGGLE
TTR
manager

Device

Figure 11: Haggle-ETT scheme. (1) Communications intra device between Haggle application
and Haggle platform (2) Communications inter
devices between Haggle platforms

coordination point.

5.1

Implementation

There are two implementations of the MAETT. Both

implementations use JADE [8] platforms for the agents
creation and management and JIPMS [4] for the mobility of the agents. JADE and JIMPS are written in
JAVA.
The first implementation is for MAEMO devices (such
as Nokia n810 in figure 2). The figures 3, 4 and 5 are
screen captures from the MAEMO version of MAETT.
The software is distributed under a GPL license and
can be downloaded from its webpage[9].
The second implementation is for Android devices.
The figures 9 and 10 show screen captures of the Android version of MAETT. It is also distributed under a
GPL license and can also be downloaded from its webpage [21].

6.

HAGGLE-ETT

Haggle Electronic Triage Tag (Haggle-ETT) [14] is

the version of the Electronic Triage Tag System based
on Haggle. Haggle [19] is an autonomic networking architecture designed to enable opportunistic communications. Haggle provides underlying functionality for
neighbour discovery, resource management and resolu-

tion, thus removing the need to implement such features

in applications. When some data wants to be sent by
an application, it is not required a direct connection to
the receiver or receivers and even it is possible that the
identities of the receivers be unknown.
The representation of data in Haggle are the DataObjects. Hence, the Electronic Triage Tags are created in
form of Triage DataObjects using the Haggle API. A
Triage DataObject contains all the information of an
ETT: injury level information, GPS position, etc. Once
the ETT is created, it is sent to Haggle. Inside Haggle,
the message is forwarded from one device to another following the TTR forwarding method. The destination of
the Triage DataObject is the Coordination Point (CP)
of the emergency.
The TTR forwarding method (section 4.1) is used
in Haggle. Haggle is structured in managers that are
in charge of carrying different tasks. The forwarding
manager in charge of applying the TTR routing method
is called TTR Manager.
This scheme can be seen in figure 11, where communications between the application and Haggle are presented as (1) and communication between Haggle platforms of different devices are represented as (2).

6.1

Implementation

The implementation of the proposal has been done as

a proof of concept. All the functionalities of the TTR
manager have been implemented and they are working
within Haggle. Also the Haggle-ETT application has
been implemented to proof the performance of the TTR
manager and Haggle.
The Haggle platform is written in C++ and it is available for Windows, Mac OS X, Android, Windows Mobile and iPhone OS.
The Haggle-ETT application is written in C++ and
uses the libhaggle library. It has been successfully tested
on laptops running Mac OS X. This computers can communicate either using Bluetooth or WiFi. The implementation have also been tested on iPhones running iOS
3.0. All the devices were set up to work on Wifi network, even thought they can work on Bluetooth network
in the same way. The tests confirmed the interoperation between the laptops and the smartphones and the
proper use of the TTR forwarding method.

7.

CONCLUSIONS

Having all the information about the victims in a digital format is essential for the prioritisation in the rescue
process. However, due to the nature of the emergency
scenarios, communications cannot rely in existing infrastructures because they can become unusable for different reasons. Hence, the forwarding of this data may
become difficult and the data may arrive to a coordination point with an excessive delay.
In this paper, we have presented MAETT and HaggleETT, two applications that create Electronic Triage
Tags with triage information of the victims in the emergency scene, and forward them to a coordination point
using ad-hoc networking. The triage is done using an
application with a GUI that follows the START protocol. This process creates an ETT which is forwarded,
using the Time To Return (TTR) forwarding method,
to a coordination point using opportunistic networks
without relying in any communications infrastructure.
The time to return to a coordination point, that is commonly used in emergencies, is assigned to each person
working in the disaster in order to have a periodic security check. The TTR forwarding method uses this time
as a forwarding decision: the ETTs will be forwarded to
the node with the lower TTR, meaning that they will
arrive earlier to a coordination point.
These applications are not only limited to scenarios
without available network infrastructure, they can also
be used in scenarios where end to end connections are
available. In these cases, a node could communicate
directly with a coordination point. If the network infrastructure becomes unavailable, or if there are delays
and disruptions the applications will continue working.
This fact makes the applications useful in any situation.

7.1

Future work

As future work, an extensive research about performance of opportunistic forwarding methods in emergencies scenarios is planned. Having a good method of
forwarding data in disasters scenarios is critical. The
characteristics of an emergency scenario cannot be predicted (density of nodes, number of messages, etc) and
those elements have a big impact in the performance of
the forwarding methods. Furthermore, other applications for disasters, different from ETTs, can be developed based on our research in Mobile Agents or Haggle
in order to be able to use them even in worst cases scenarios where infraestructured networks are unusable.

8.

ACKNOWLEDGEMENT

This research has been partially funded by the Spanish Ministerio de Educacion (FPU AP2008-03149), by
the Catalan DURSI (2009SGR1224) and by the Spanish
Ministerio de Ciencia e Innovacion (TIN2010-15764).

9.

REFERENCES

[1] Haggle, http://code.google.com/p/haggle/.

[2] The-day-after networks: A first-response
edge-network architecture for disaster relief,
http://mobius.cs.uiuc.edu/research/phoenix/.
[3] N. Aschenbruck, M. Frank, P. Martini, and
J. Tolle. Human mobility in manet disaster area
simulation - a realistic approach. In in 29th
Annual IEEE International Conference on Local
Computer Networks (LCN 04, 2004.
[4] J. Cucurull. Jade inter-platform mobility service,
2008. http://jipms.sourceforge.net.
[5] J. Cucurull, R. Mart, S. Robles, J. Borrell, and
G. Navarro-Arribas. Fipa-based interoperable
agent mobility. In CEEMAS07, volume 4696 of
LNAI, pages 319321. Springer Verlag, September
2007.
[6] A. Fuggetta, G. P. Picco, and G. Vigna.
Understanding code mobility. IEEE Trans. Softw.
Eng., 24(5):342361, 1998.
[7] M. E. Gebhart and R. Pence. Start triage: Does it
work? Disaster Management and Response,,
5(3):6873, 0 2007.
[8] T. Italia. Jade, 2004. http://jade.tilab.com/.
[9] X. Jurado. Mobile agent based eletronic triage tag
- maemo version,
https://www.assembla.com/spaces/triagetag/.
[10] A. Keranen, J. Ott, and T. Karkkainen. The ONE
Simulator for DTN Protocol Evaluation. In
SIMUTools 09: Proceedings of the 2nd
International Conference on Simulation Tools and
Techniques, New York, NY, USA, 2009. ICST.
[11] J. P. Killeen, T. C. Chan, C. Buono, W. G.
Griswold, and L. A. Lenert. A wireless first
responder handheld device for rapid triage,

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

patient assessment and documentation during

mass casualty incidents. AMIA Annu Symp Proc,
pages 42933, 2006.
K. Luyten, F. Winters, K. Coninx, D. Naudts,
and I. Moerman. A situation-aware mobile system
to support fire brigades in emergency situations.
pages 19661975, 2006.
R. Mart, S. Robles, A. Martn-Campillo, and
J. Cucurull. Providing early resource allocation
during emergencies: The mobile triage tag. J.
Netw. Comput. Appl., 32:11671182, November
2009.
A. Martn-Campillo, J. Crowcroft, E. Yoneki,
R. Mart, and C. Martnez. Using haggle to create
an electronic triage tag. In The Second
International Workshop on Mobile Opportunistic
Networking - ACM/SIGMOBILE MobiOpp 2010,
pages . ACM Press, February 2010.
T. Massey, T. Gao, M. Welsh, J. H. Sharp, and
M. Sarrafzadeh. The design of a decentralized
electronic triage system. In AMIA Annual
Symposium Proceedings, pages 544548, 2006.
S. McGrath, E. Grigg, S. Wendelken, G. Blike,
M. D. Rosa, A. Fiske, and R. Gray. Artemis: A
vision for remote triage and emergency
management information integration. In
Dartmouth University, pages . Dartmouth
University, November 2003.
U. of Bonn. Bonnmotion: A mobility scenario
generation and analysis tool, http://net.cs.unibonn.de/wg/cs/applications/bonnmotion/,
2009.
A. Rice and S. Hay. Measuring mobile phone
energy consumption for 802.11 wireless
networking. Pervasive and Mobile Computing,
6(6):593 606, 2010. <ce:title>Special Issue
PerCom 2010</ce:title>.
P. C. J. D. C. Scott, J; Hui. haggle: a networking
architecture designed around mobile users. In
The Third Annual IFIP Conference on Wireless
On-demand Network Systems and Services
(WONS 2006), January 2006.
V. Shnayder, B. rong Chen, K. Lorincz, T. R.
F. F. Jones, and M. Welsh. Sensor networks for
medical care. In SenSys 05: Proceedings of the
3rd international conference on Embedded
networked sensor systems, pages 314314, New
York, NY, USA, 2005. ACM.
S. Solsona. Mobile agent based eletronic triage tag
- android version,
http://deic.uab.cat/amartin/amaett.zip.
H. Sun. Chopper crews saved by google maps
during queensland floods,
http://www.heraldsun.com.au/technology/choppercrews-saved-by-google-maps-durig-queensland-

floods/story-fn7celvh-1226046611966.
[23] L. Wallis. START is not the best triage stategy.
Br J Sports Med, 36(6):473, 2002.
[24] J. E. White. Telescript technology: Mobile agents.
In J. Bradshaw, editor, Software Agents. AAAI
Press/MIT Press, Menlo Park, CA, 1996.
[25] M. Wooldridge and N. R. Jennings. Intelligent
agents: Theory and practice. Knowledge
Engineering Review, 10(2):115152, 1995.