Mobile Netw Appl (2007) 12:129–142DOI 10.1007/s11036-007-0015-3

Resource Discovery in Activity-Based Sensor Networks

Doina Bucur · Jakob E. Bardram

Published online: 19 July 2007© Springer Science + Business Media, LLC 2007

Abstract This paper proposes a service discovery pro-tocol for sensor networks that is specifically tailoredfor human-centered pervasive environments and scaleswell to large sensor networks, such as those deployedfor medical care in major incidents and hospitals. Ituses the high-level concept of computational activities(logical bundles of data and resources) to give sensorsin activity-based sensor networks (ABSNs) knowledgeabout their usage even at the network layer. ABSNredesigns classical service discovery protocols to in-clude a logical structuring of the network for a moreapplicable discovery scheme. Noting that in practi-cal settings activity-based sensor patches are localized,ABSN designs a fully distributed, hybrid discovery pro-tocol based on extended zone routing protocol (EZRP),proactive in a neighbourhood zone and reactive out-side, so that any query among the sensors of one activityis routed through the network with minimum overhead,guided by the bounds of that activity. Compared toEZRP, ABSN lowers the network overhead of the dis-covery process, while keeping discovery latency close tooptimal.

Keywords active-based sensor networks ·service discovery protocol · body sensor networks

D. Bucur (B) · J. E. BardramCentre for Pervasive Healthcare,Department of Computer Science,University of Aarhus,Århus, Denmarke-mail: doina@daimi.au.dk

J. E. Bardrame-mail: bardram@daimi.au.dk

1 Introduction

Wireless ad hoc sensor networks for medical pur-poses are playing an increasing role within healthcare.Body sensor networks (BSN) are being designed forprophylactic and follow-up monitoring of patients ine.g. their homes, during hospitalization, and in emer-gencies. For example, a wide range of medical sen-sor networks has been proposed for post-operativemonitoring [1], heart monitoring [7], and follow-upmonitoring of e.g. strokes [11]. In the EuropeanPalCom project [21] and in the Code Blue project inBoston [5], medical sensors are being developed forpatient monitoring in emergencies.

With the arrival of this range of medical sensors,efforts go towards prototyping sensor networks to aidmedical care on a large scale, such as patient care inhospitals or that in the emergency medical service fieldof pre-hospital work in major incidents (e.g. part ofthe PalCom project [21]). In the latter scenario, sensorshelp automate the victims’ identification, registrationof data, medical assessment and reassessment, triageand overview; if performed entirely by the medicalpractitioners, especially in the major incident case, suchtasks are hindered by the sheer number of victims.

Core research questions in such sizable wirelessad-hoc sensor networks include low-level data routingand service discovery protocols, i.e. the most efficientway—in terms of response time, network bandwidthand power consumption—to route data in the networkand to discover and access services within the net-work. Extensive research within efficient data routingin wireless ad-hoc networks has been done already;however, limited research has been done within thefield of resource discovery in such networks, and a

130 Mobile Netw Appl (2007) 12:129–142

majority of this designs service discovery protocols for aheavyweight IP-based network infrastructure. Further-more, most of this work does not take into accountany knowledge about the usage of the network, andhence stays completely general and detached from theapplication domain.

We propose to use the concept of activity-basedcomputing [2] for data routing and service discoveryin wireless ad hoc sensor networks. The core ideain activity-based computing is to help users organizecomputational services, data and resources in logicalbundles that match their work activity. We call thesebundles computational activities, or simply activities.For example, a healthcare activity would be the mon-itoring of a patient, which can take the concrete formof the prophylactic monitoring of Mr. Hansen forcongestive heart failure by monitoring a combinationof parameters like blood pressure, ECG, weight, andpulse. Similarly, at an incident site, a monitoring activ-ity for each victim could be created by bundling sen-sors monitoring respiration, pulse, oxygen saturation,temperature, and blood pressure. On a larger scale, ata major incident site, a care activity would group thebody sensors of all patients classified to be in criticalcondition after triage.

The core idea in activity-based sensor networks(ABSN) is to utilize the clustering of sensors into log-ical activities, and then base data routing and servicediscovery on each sensor’s knowledge of activity mem-bership. Our hypothesis is that data routing and servicelookup are more efficient in this protocol design than ina general uniform scheme, since services and their dataare mostly relevant within the bounds of each patientactivity.

1.1 ABSN requirements and solutions

The trademark usage cases for ABSN are the majorincident and hospital care settings; ABSN answers thecritical challenges put forward when designing emer-gency medical service systems for major incidents (af-ter sociological studies by Kristensen [14] under thePalcom project [21]):

• The process of victim identification and registra-tion of data requires persistent textual informationattached to each patient. During major incidents,these accident cards—which are the tools for theidentification of the person, registering of injuries,symptoms and the progress of care on-site—cannotbe filled in for lack of time, which leads toadministrative overhead and a risk of errors during

care. The larger the incident, the less complete dataregistration tends to be.

• The categorization of victims is done during triageaccording to the patients’ severity of injuries, andconsists of marking the victim with a coloured card.The status of the victim can easily change and thusneeds to be monitored, and more, classification of avictim depends not only on his condition, but alsoof the other victims. In major incidents, the largenumber of victims greatly hinders classificationefforts.

• Particularly in major incidents, communicationabout the status of victims is mostly verbal, result-ing in a lack of crucial information being reportedabout the patient when the patient is handed infrom one care team to another, and over time.Given the lack of recorded textual information, thevictims themselves are the objects upon which thecare work is organized, requiring multiple assess-ments from different practitioners. A situationaloverview of the incident site is also impossible toachieve.

• Technology needs to scale down from major in-cidents to minor ones, rather than the other wayaround; design should take place at the more com-plex end of the spectrum, to insure a functionalstandard and proper familiarity with new technolo-gies in anticipation of the major incidents.

To automate victim identification and data registra-tion, ABSN deploys sensors as patient body monitors,dynamically and explicitly activity-grouped to patientsby nurses. An activity ID on each node groups sensorsin activity clusters. While patients are moved toambulances or other locations in the hospital, theirbody sensors record medical data into memory, anduse the knowledge about belonging to a certain activityin order to efficiently aggregate the data history forindividual patients and make simple diagnoses. Havingpatient body sensors deployed in the field, victim cate-gorization and a situational overview can also be auto-mated. Also, ABSN designs for the complex end of thespectrum, having scalability as important a requirementas functionality.

The trademark scenarios that ABSN expects tocover are thus the typical cases encountered in incidentand hospital settings:

• The sensors often need to be deployed in dense,relatively localized and connected patches follow-ing the location of a patient, contextual object orgroup of patients, either in a hospital or at the siteof an incident. Because of this, there is a logicalstructuring of the sensors based on the activity they

Mobile Netw Appl (2007) 12:129–142 131

are a part of; we call this logical grouping an activitycluster, AC. Depending on their size and topology,ACs can be singlehop and strictly localized (if theyonly group body sensors) or multihop and occupy-ing a large area (if they group entire categories ofpatients).

• Interaction among sensors is, more often than not,bounded inside an activity cluster, but network-wide discovery and data exchange are of no lessimportance.

• There is a high degree of mobility involving entireactivity clusters at a time and sensor unavailabilityis often a problem (in the example above, sensorsmight fall off patients while the patients are beingmoved, and the protocol is required to signal thischange to the application layer).

The ABSN discovery protocol allows low-latencydata aggregation within the bounds of a patient’s sensorbundle, by locally caching on sensors the neighbouringof same-activity routes and services. For the same pur-pose, it uses the knowledge about the patient sensorbundles being relatively connected, in order to limitthe packet broadcast overhead in the network. Thisis different from the majority of the ad hoc protocolsin the literature—which do not differentiate betweennodes in the network—in the fact that ABSN allowsthe application-level logic to be used at the networkinglayer, in order to make the network protocols moreapplicable and efficient in practical scenarios. Also, anABSN is an ad hoc network that has no reliance on anyinfrastructure; this approach allows for the seamlessadaptation of an ABSN network to work both at aninfrastructured site (such as a hospital) and in an ad hocsetting (such as the site of an incident).

To summarize our contribution, ABSN designs acompletely distributed discovery scheme, that relies onno directories, but on limited, individual caching ofroutes and service information on nodes. It employsproactive route and resource discovery within an activ-ity cluster and reactive discovery outside, ensuring lowlatency for all intra-AC communication.

As is the case in sensor networks, separate softwarelayers for routing and resource discovery are redun-dant (as argued by [13, 22]). This has led us to fol-low EZRP [22] in embedding routing and discoveryinto one protocol. We state that it is the binding ofthese low-level protocols to high-level human activityconcepts that makes sensor networks protocols moreapplicable in pervasive healthcare environments thangeneric routing or service discovery protocols.

Our main contribution is thus the porting of ABCconcepts [2] into pervasive sensor networks for the

purpose of redesigning classical networking protocolsto make sensors fit for human-centered pervasive set-tings, with a focus on large-scale networks for use inhospitals and major incidents. Also, to the best of ourknowledge, this is the first attempt to practically employsuch low-resourced embedded systems like sensors inthe field of service discovery in ad hoc environments.

We implemented ABSN on Moteiv’s Tmote Sky,TelosB sensors, and tested the protocol on a real-codesimulator.

The rest of this paper is organized as follows: Sec-tion 2 gives an overview of other service discovery pro-tocols for ad hoc and transient networks, Section 3 givesa detailed description of ABSN, while Section 4 makesan analysis of the performance parameters of discoveryin ABSN. At last, Section 5 gives the evaluation resultsand Section 6 summarizes and concludes.

2 Related work

In general, for any networked environment, devicemobility implies losing connectivity with configuredenvironments. Service discovery software then enablesa mobile user to take advantage of resources at anynew location. For pervasive environments, in whichautonomous computing devices interact to achieve in-telligence, service discovery protocols permit the adap-tation of devices to network composition and context.

“Classical” service discovery protocols for pervasiveenvironments—like Jini, UPnP and others—are tai-lored for resource-rich, stable-network enterprise-likeenvironments, and as such are not always applicable inpervasive computing, yet they do provide basic protocoldesign reference points. They rely on stable, LAN-likenetwork connections, do not need to solve network-layer routing issues (since they use IP), are usuallycentralized—using one or more directories spanningthe network—and can employ sophisticated servicesemantics.

Unlike LAN devices, sensors form unstable adhoc network connections and are used for extremelymobile applications. Such mobile ad hoc networks(MANETs) are autonomous systems of intermittent,energy-bounded nodes collaborating in the absence ofany centralized support. The network diameter is largecompared to a node’s range, any data transport is mul-tihop, and the nodes do not have a priori knowledge ofthe topology of the network. Because of the networkdiameter-to-wireless range ratio, routing and powerefficiency are central issues, and each node has to actas a router.

132 Mobile Netw Appl (2007) 12:129–142

Thus, when trying to port “classical” service dis-covery protocols to MANETs, the problems arisingare that in MANETs mobility and resource limitationsdisallow static directories, the underlying network isnot stable enough to allow centralized, registration-oriented protocols, and the protocols cannot be heavy-weight, with respect to bandwidth and power usage.

Due to the large size of a sensor network, the discov-ery scheme becomes a central issue. Proactive discoveryschemes maintain routes within the network continu-ously refreshed—so that a query is answered withoutlatency; they also constantly add overhead on networkbandwidth and on a node’s cache memory. Reactiveprotocols do not determine routes before an explicitquery, and require a global flood search procedurewith long delays and heavyweight traffic at each query.While reactive schemes do not achieve a large degreeof performance, proactive schemes—otherwise optimalin performance—do not scale well in large networks;hybrid schemes are thus designed to overcome theselimitations.

2.1 Service discovery in ad hoc environments

A review of service discovery protocols for transientenvironments is to be found in Table 1, and only themost relevant ones are discussed below. Most of theseprotocols are intended for resource-rich ad hoc wire-less networks, and the others are general proposals,detached from the application domain; some achievenovel designs by allowing application-level policies todictate discovery schemes.

Allia [16] has participants advertise own services intheir vicinity; the advertisements are forwarded withina certain hop diameter and the devices which hear thesemight passively cache them. The set of devices that acertain node chooses to cache services of forms thisnode’s alliance; a request will go to other alliances onlyif a service is not found in the cache, and a node onlyknows the participants of its own alliance. The intelli-gence of the protocol lies in its set of policies (basedon application preferences) that rule the frequency andcaching of advertisements, and the diameter of thealliance. While still being heavyweight, Allia was a pathto follow in our design, both because it recognizes theoptimal hybrid proactive/reactive approach for discov-ery, and because it employs application-level policiesover the discovery protocol.

Among the lightweight protocols, GSD [3] adaptsthe sophistication of [16] to use in actual MANETs, byreplacing policy-based alliances with broadcast vicini-ties of a certain diameter, so that the network is nowuniform, a situation which is not common in networks

for medical care. CARD [10] keeps with the hybridapproach of proactive local and reactive remote dis-covery, but is best-effort and only valid as a routingprotocol for short flows of data, trading off the opti-mality of the shortest path method for heavy savingsin certain settings. It employs contact nodes instead ofZRP’s [8] bordercast, and concentrates on the effort ofelecting and maintaining the contact nodes for globaldiscovery. The network uniformity in [3] and the lim-ited validity of [10] distances both protocols from ourapproach: ABSN is intended to make efficient use of alogical structuring of the network, and to be a generalservice discovery protocol for human-centric pervasiveenvironments.

EZRP [22] recognizes that, in an ad hoc network,service availability is tightly linked to route determina-tion to that service: finding the address of a service isredundantly followed by finding a route to that address.Because of this, the solution employs the piggybackingof service information in routing packets (an idea firstfound in [13]). It extends ZRP [8] to include serviceinformation and has been the basis ABSN was built on,as detailed in Section 3.

3 ABSN design

This section gives a detailed description of both ZoneRouting Protocol (ZRP, [8]) and Extended Zone Rout-ing Protocol (EZRP, [22]), to then discuss the design ofABSN.

3.1 ZRP and EZRP

ZRP is a MANET routing protocol whose guidelinesfit a sensor network’s setting by being flat, fully distrib-uted and only limitedly proactive. It chooses a hybrid,proactive and reactive approach and delimits a zoneof a certain number of hops around each node (sothat, overall, the zones are heavily overlapped), to thenlimit the proactive procedure to this zone. For out-of-zone discovery, instead of plainly broadcasting of thequery throughout the network, the bordercast messagedistribution scheme directs queries from a source nodetowards the edges of the network by only forwardingthe query to the nodes on the border of the sourcenode’s zone. It is important to note that, despite group-ing the nodes into zones, ZRP is not a hierarchicalprotocol, but remains a flat one, since each node hasa zone, so that the grain size of this zoning is one node.

The ZRP and its subprotocols’ IETF drafts do notimpose specific protocols for the proactive and reactivediscovery of routes. We choose to adapt these drafts for

Mobile Netw Appl (2007) 12:129–142 133

Tab

le1

Are

view

over

serv

ice

disc

over

ypr

otoc

ols

inad

hoc

netw

orks

Net

wor

kto

polo

gyan

dtr

ansp

ortp

roto

col

Stor

age

ofse

rvic

ein

foD

isco

very

polic

ySo

ftw

are

laye

rIm

plem

enta

tion

and/

orte

stin

g

DE

AP

spac

eSi

ngle

hop,

shor

tran

ge80

2.11

-lik

eF

ully

dece

ntra

lized

:all

node

sP

roac

tive

:eac

hno

de–

Sim

ulat

ion

(200

1)[1

5]tr

ansi

entn

etw

ork

cach

eal

lthe

serv

ices

avai

labl

ead

vert

sal

lser

vice

sin

the

inth

ene

twor

kne

twor

k(g

ossi

p-lik

e)A

llia

IPne

twor

kov

erB

luet

ooth

Ful

lyde

cent

raliz

ed:e

ach

node

Pro

acti

ve:a

node

adve

r-IP

mid

dlew

are

App

lied

inIP

mob

ile(2

002)

[16]

mig

htca

che

the

serv

ices

init

sti

ses

its

serv

ices

and

isco

mm

erce

onla

ptop

svi

cini

tyba

sed

ona

polic

yin

clud

edin

allia

nces

;an

diP

AQ

s,ov

erB

lue-

reac

tive

for

rem

ote

serv

ices

toot

h(f

ootp

rint

:~60

0k,

heap

:~80

0k)

GSD

As

[16]

As

[16]

As

[16]

w/o

allia

nces

–Si

mul

atio

n(G

lom

osim

)(2

002)

[3]

Che

ng’s

Mul

tica

stIP

netw

ork,

Non

e,di

scov

ery

ison

-dem

and;

Mai

nly

reac

tive

,wit

ha

IPro

utin

g,–

(200

2)[4

]in

depe

nden

ton

only

cach

ing

ofal

read

ydi

scov

-va

rian

tofp

roac

tive

pigg

ybac

ked

low

erla

yers

ered

serv

ices

upda

ted

serv

ices

adve

rts

onO

DM

RP

Kon

ark

Mul

tica

stIP

netw

ork,

Ful

lyde

cent

raliz

ed:a

llno

des

Bot

hpr

oact

ive

(ser

vice

sIP

mid

dlew

are

App

lied

inIP

mob

ile(2

003)

[9]

inde

pend

ento

nth

ene

twor

kla

yer

inth

ene

twor

kca

che

alls

ervi

ces

adve

rtis

eth

emse

lves

)co

mm

erce

,usi

ngH

TT

Pan

dre

acti

vem

icro

-ser

vers

oniP

AQ

san

dph

ones

SAN

DM

AN

Any

,onl

ya

mod

elD

ecen

tral

ized

ifno

des

awak

e;R

eact

ive:

node

sfo

rm–

Sim

ulat

ion

(ns-

2)(2

004)

[18]

cent

raliz

ed,w

ith

clus

ter

head

s,cl

uste

rsw

ith

dyna

mic

ally

ifno

des

slee

pel

ecte

dhe

ads

Sailh

an’s

IPne

twor

k,in

depe

n-C

entr

aliz

ed,d

istr

ibut

ed:

Pro

acti

veam

ong

dire

c-–

Sim

ulat

ion

(200

5)[1

7]de

nton

low

erla

yers

dyna

mic

ally

elec

ted

dire

ctor

ies

tori

esin

side

ano

de’s

form

ane

twor

kba

ckbo

nezo

ne,r

eact

ive

outs

ide

itE

ZR

PM

ulti

hop,

sens

or-l

ike

Ful

lyde

cent

raliz

ed:a

llno

des

Pro

acti

vein

side

ano

de’s

Rou

ting

,em

bedd

edSi

mul

atio

n(Q

ualn

et)

(200

5)[2

2]ne

twor

kca

che

serv

ices

inth

eir

zone

zone

,rea

ctiv

eou

tsid

eit

inZ

RP

CA

RD

Mul

tiho

p,se

nsor

-lik

eF

ully

dece

ntra

lized

:all

node

sP

roac

tive

insi

dea

node

’sR

outi

ng(n

ota

Sim

ulat

ion

(ns-

2)(2

005)

[10]

netw

ork

cach

ese

rvic

esin

thei

rvi

cini

tyzo

ne,r

eact

ive

outs

ide

itge

nera

lrou

ting

prot

ocol

)

134 Mobile Netw Appl (2007) 12:129–142

A

D

X

C

B

Unstructured nodes

Figure 1 A view over an EZRP discovery network: the nodesare not logically grouped and each node keeps a zone (NC) of atwo-hop radius (for this example) centered at itself. The NC fornode A is drawn

use in resource-poor sensor networks, as described inSection 3.2.

EZRP extends ZRP for use in service discovery, sim-ply by adding a service ID to the hello messages usedby neighbours to let them know each other. This way,neighbouring nodes find the others’ service IDs, to-gether with their simple presence. Furthermore, nodesperiodically broadcast their set of neighbours and theirservice IDs throughout their zones, so that intra-zoneroutes are extended with service information.

A view over an EZRP network is given in Fig. 1. Wewill denote the ZRP zones by the term network cluster,NC, to differentiate them from the activity clusters,ACs. In Fig. 1, if a link-state protocol is used intra-NC(for example, a simplified OSPF), node A will receivehello packets from its direct neighbours (also contain-ing a service ID field) and will periodically transmitadvertisements throughout the NC, announcing its listof neighbours and their services. When node A’s NCconverges (all nodes have a consistent view upon thenetwork, from a routing point of view), A will have inits local cache a complete view over its NC, route- andservice-wise. In order for A to discover services androutes for nodes D or X, bordercast is employed.

3.2 ABSN discovery design

As stated in Section 1, the reflection of high-levelactivities into the sensor network is the logical groupingof the sensors into activity clusters, ACs, which aredeployed in multihop, overlapping patches throughoutthe network. Since data communication is more oftenthan not bound inside an AC, we call for a proactivediscovery scheme for intra-AC routes and services anda reactive discovery scheme inter-AC.

Although this might immediately recall EZRP(Section 3.1) as a solution, there is no possibility ofidentifying ACs with the network clusters in ZRP ina one-to-one fashion. In ZRP, NCs are sets of nodesreachable within a certain radius (number of hops)from any central node and are flatly distributed acrossthe network (for every node in the network there isa NC, and nodes are logically homogeneous). On theother hand, ACs are unique sets of nodes (for example,there is only one AC with patient Hansen’s ID) and aredeployed in irregular, possibly overlapping and densegeometric patterns around the network.

A view over a basic activity-based network is givenin Fig. 2. Activity clusters are deployed in a relativelylocalized, connected fashion throughout the network;they might overlap in the same area, so that any nodemight have in its range other nodes belonging to activi-ties different than its own.

The main requirements imposed over the ABSNdesign are protocol scalability in the large networksrequired in major incidents and low latency at intra-AC discovery: service and route discovery is expectedto work throughout the network, yet optimized in sucha way that discovery latency is low if the requestor andthe service belong to the same activity.

ABSN superimposes the logical AC grouping overthe flat EZRP network topology, as in Fig. 3. Toachieve scalability, every node in the network stillkeeps a NC zone centered at itself, in order to limit theproactiveness of the protocol. Since the nodes withinthis NC belong to different ACs, and since the logicalgrouping of sensors in ACs implies a lower probabilitythat a service be requested from a node of a differ-ent colour, ABSN has a node only cache the service

A

D

X

C

B

"Gray" AC

"White" AC

"Black" ACM

Figure 2 The logical view over an activity-based network: eachactivity is colour-coded and the intra-AC connections are drawn;connectivity also exists among neighbouring nodes of the differ-ent, overlapping ACs (not drawn in the figure)

Mobile Netw Appl (2007) 12:129–142 135

A

D

X

C

B

"Gray" AC

"White" AC

"Black" ACM

N

Figure 3 A view over a sample ABSN network: in the EZRPfashion, every node, regardless of its AC, keeps a zone (NC) ofa two-hop radius (for this example) centered at itself. The NCfor node A is drawn, and it gathers nodes from different ACs,including node A’s own AC

information of same-AC nodes that lie within thisnode’s NC. Furthermore, a node will proactively cacherouting information for all the nodes within its NC.

3.3 Intra-NC discovery

A lightweight link-state proactive protocol is employedintra-NC. This protocol sends periodic one-hop broad-cast hello packets from each node, so that—at alltimes, and with a maximum latency equal to the helloperiod—every node knows the addresses of its neigh-bours and, as a metric, the link quality to each ofthem. Also, a node that detects a drastic change in themetric to at least one of its direct neighbours (includ-ing a neighbour’s arrival or disappearance) triggers alimited-range link-state advertisement (LSA), announc-ing the change within the radius of its own NC. LSAsare forwarded in a broadcast manner for only a numberof hops equal to the radius of the NC. This way, everynode keeps a routing map of the NC as a weightedgraph of nodes that can be reached in a number of hopsequal to or less than the NC diameter.

In order to allow nodes to build a service map of thenear AC, both hello and LSA packets carry, besidesaddresses, AC and metric information, the service IDsof the nodes these packets advertise: they will bothstate the service ID of the source of the packet, and—inaddition—a LSA will list the neighbours which changedstate and, if available, their service information.

At a “black” node (see Fig. 3), only such incomingpackets bearing service IDs for other “black” nodeshave their service information cached. In Fig. 3, thisleads to the “black” node A having a service table with

the service information of all the “black” nodes in itsNC: a hello packet originated at node B advertised theservice ID of B, and a LSA triggered by node C (andforwarded over one “white” hop) advertised the serviceID of C. To save computation time and memory, noservice information is cached about nodes of othercolours.

3.4 Route and service query solving

With a routing map and a service map in place at eachnode, the solving of a service query depends on theparameters of the query. A service of the same colourmight be needed, as in the case of the aggregation ofdata from sensors belonging to the same patient, forautomatic diagnosis of the patient. If the gateways tothe wired network form an activity cluster with a well-known colour, then the downloading of sensor datafrom any patient sensor to the wired network will haveto be preceded by the (different-AC) discovery of thegateway location.

Given these two cases, if a certain service of the samecolour is needed, then

• The local service table is tried; if there is a match,the address is returned;

• If there is no match, the query is bordercast onlyto the border nodes (or, if none exists, the closestnodes to the border) of the same colour, exploitingthe fact that ACs are relatively connected, and thuslimiting the network overhead.

If, on the other hand, a service of another colour isneeded, then

• The local routing table is checked for the closestnode of the searched colour; if such a node (whichwe call a gateway for the entire searched AC) isfound, the query is relayed to it, and it will proceedas in the same-colour case above; if more thanone gateway is found, ABSN chooses the closestgateway to the query source node;

• If no gateway exists, the query for the gateway isbordercast.

A routing query will be solved exactly as in ZRP,regardless of activity IDs. Routes for all the nodes thatcan be reached within a number of hops equal to theNC diameter are read from the proactively built net-work map. Routes for any other nodes are discoveredon-demand, through bordercasting.

This design makes discovery either proactive orreactive, depending on whether the unknown is a routeor a service, and on the relation between the AC of

136 Mobile Netw Appl (2007) 12:129–142

the requestor and that of the destination. Thus, routediscovery is always proactive within the limits of a NC,and reactive outside, regardless of the relation betweenthe colours of the nodes involved. On the other hand,service discovery for same-colour nodes sharing a NCis fully proactive; in all other colour and distance condi-tions, service discovery is always a mix of proactivenessand reactiveness: the query is initially forwarded forcertain other nodes to solve, but will eventually reacha node that has discovered the required service infor-mation in advance.

4 Discoverability, optimality and overhead analysis

This section analyzes the performance of ABSN com-pared to the relevant related work protocols. It definesand uses parameters such as the discoverability of thatservice, the optimality and latency of the solving of aquery and the network overhead added by a query toassess ABSN’s characteristics. Furthermore, this sec-tion analyzes the set of network topologies that ABSNserves better than other protocols.

The ability of ABSN to discover any service (includ-ing a route), if present in the network, is hence calledthe discoverability of that service. ABSN guaranteesdiscoverability in all network settings, provided thatany activity cluster is only disconnected by a numberof hops less than the NC radius; this is like [22] and [3],and unlike [10].

We denote by the optimality of a query that querytaking the shortest, lowest-latency route in the network.The optimality of ABSN depends on the NC radiusand on the network topology of the searched AC.While having low discovery latency in a large numberof network and activity topologies, ABSN only hassuboptimal latency in few badly-formed activity clustertopologies.

As a routing protocol, ABSN is optimal and guar-antees route discoverability, in the fashion of ZRP.The ABSN routing and discovery design following log-ical activity grouping greatly limits the network andcomputational overhead that a general-purpose EZRPwould imply, if deployed in the pervasive environmentsABSN is applicable to.

These statements will be substantiated by the dis-cussion over local and global discovery in Sections 4.1and 4.2.

4.1 Neighbourhood discovery

In regard to route discovery within a node’s NC, it isto note that the proactiveness of the link-state protocol

that ABSN uses ensures that changes in the networkor in the service provision are propagated in a timelyfashion, with a maximum latency directly proportionalto the NC radius. Since link-state protocols keep adynamically updated view over the entire NC and areimmune to routing loops, optimality and route discov-erability at intra-NC route discovery are ensured. Onthe other hand, link-state protocols broadcast any LSAthroughout the NC. This implies that the radius ofeach node’s NC must be dynamically updated given thenode density in the area, in order to keep network andcomputation overhead down.

In regard to service discovery, any node willannounce throughout the NC any change in the statesof its direct neighbours by only mentioning known ser-vice information: for example, in Fig. 3, when “black”node C enters the network, “white” node N will notcache C’s service information provided by C’s hellos.Thus, a LSA originated from N and announcing thenew “black” node will not provide to A the serviceinformation that A could use (since A and C are ofthe same colour). We call the situation in which theforwarding of service information towards a node isstopped by interposing nodes of another colour by theterm “colour shadowing”.

However, within a NC, ABSN is resilient to suchapparent “colour shadowing”: even if the “black” ACweren’t connected, the new node C will also trigger aLSA, announcing its new link to node N. Since LSAsare forwarded regardless of the colour of their sourceand contain the complete service information of theirsource node, node A will receive a first-hand updateabout the services provided by C from C itself. Ingeneral, within an NC, every node will have a completeimage of the same-colour services in the neighbour-hood. This resilience is even independent of AC con-nectivity. Furthermore, still in the example in Fig. 3,if the “black” AC is connected, LSAs with the serviceinformation of the new node will redundantly reachnode A on all fully “black” paths from C to A. This way,discoverability of same-colour services within an NC isguaranteed and is optimal - this adds to the optimalityof the routing of packets intra-NC.

In the case of different-colour service discovery, onthe other hand, while it is ensured that a service will bediscovered if present (the service discoverability is alsofully guaranteed), the optimality of the query dependson the choice of gateway for the searched AC. Yet, inthe worst-case scenario in which a gateway is blindlychosen in the exactly opposite direction from the ac-tual service searched, a maximum of 1 bordercast stepwill have the query solved (as shown in the examplein Fig. 4).

Mobile Netw Appl (2007) 12:129–142 137

node M’s NC

node A’s NC

node N’s NC "White" AC

"Black" AC

M

PN

Q

"Gray" AC

A

X

Figure 4 For “white” node A to discover the services of “black”node X, A needs to choose a gateway for the “black” AC. TheABSN solution is to choose the best metric (closest) “black” nodeas a gateway (in this figure’s case, node M). Yet, for M to discoverX it needs to do one bordercast step (forwarding the query to N,P and Q). An optimal choice for a “black” gateway would benode N, which can immediately answer it without latency, sinceX lies in N’s NC

4.2 Global discovery

At a global level, route discoverability and optimalityare secured, by the design of ZRP. An average maxi-mum number of D

R bordercast steps are employed forthe route discovery towards a node which is D hops

"White" AC

"Black" AC

"Gray" AC

A

X

Figure 5 For node A to discover the services of “black” X, aservice query will be bordercast repeatedly. Unlike EZRP, whichwould bordercast the query symmetrically around A, ABSNlimits the traffic to the bounds of the “black” AC

away, if the average NC radius of the nodes on thepath is R.

ABSN greatly reduces network overhead by onlyforwarding service queries for a “black” service withinthe bounds of the “black” AC. In the case of symmet-rical, radially deployed ACs (as in Fig. 5), the networkoverhead is reduced to a percentage of black network area

total network areaof the network overhead in EZRP (here, we denote bythe area of an AC or a network a qualitative measurethat is proportional to the number of nodes in that AC,the nodes’ degree and to the number of hops this ACoccupies).

Service discoverability in ABSN relies on the activityclusters only being disconnected by a number of hopsless than the NC radius. Given this, ABSN guaran-tees the discoverability and optimality of a different-AC gateway node search, but only the discoverabilityof a service is guaranteed: the optimality of the paththe query takes towards the service depends on thetopology of the searched AC: at a global level, “colourshadowing” is in effect, routing a query according toAC topology. For example, in Fig. 6, a service querytakes a sub-optimal path through the overall network.ABSN argues that this is a small price to pay for thereduction in network traffic. It is to note that thissub-optimality is only true for service requests: ser-vice replies are treated as regular data packets and,since routing is optimal, the replies take the optimalpath back.

Furthermore, as shown in Section 4.1, within thelimits of a NC, “colour shadowing” does not limit dis-coverability. This indicates that global “shadows” ordisconnections less than the NC radius in width will beovercome by the protocol. It follows that the preferred

"White" AC

"Black" AC

"Gray" AC

X

A

optimal path

Figure 6 The bordercasting of the “black” query will follow thedeployed shape of the “black” AC, instead of taking an optimalpath across other ACs

138 Mobile Netw Appl (2007) 12:129–142

AC topologies only exclude disconnections wider thanthe NC radius.

5 Evaluation

This section gives an overview of the means of evaluat-ing ABSN. A few typical, trademark real-world ABSNapplication cases are characterized in some detail; real-code simulated tests are performed to test the increasein optimality and scalability of ABSN versus EZRPin a number of basic scenarios, and finally discussionsare had upon the degree to which the test scenariosestimate the compared performance of ABSN in real-world deployments.

As stated in Section 1.1, the trademark usage casesof ABSN are encountered in major incident and hos-pital settings. To what concerns the sensor population,in both settings—when designing at the complex endof the spectrum—it is expected a number of patientsupper bounded by a number on the order of a fewhundreds, each patient having potentially associated upto five sensors. Furthermore, in a hospital setting, aset of contextual sensors monitor hospital objects (likemedicine trays, doors and beds). Due to the size of sucha network, in the following, tests are performed uponthe improvement in network overhead in an ABSNnetwork compared to EZRP, when one service queryis multiplied throughout the network in search of thedestination node. Figures 7 and 8 show the comparednetwork traffic by EZRP and by ABSN, in the samenetwork.

The results in Fig. 7 fit a scenario in which a major in-cident triage field is divided into areas in which patientshave been moved according to their status; roughly, a

0

20

40

60

80

100

120

140

160

180

2 2.5 3 3.5 4 4.5 5 5.5 6

Ser

vice

req

uest

mul

tiplic

atio

n fa

ctor

Network hop count radius

Network-wide forwarding of one service request

EZRP, disc topologyABSN, 60 deg pie slice in EZRP’s disc

Figure 7 Additional network traffic due to the multiplication ofa single service query, in number of packets by the radius of theoverall network. The network is a 3-degree extended star withvarying radius; all nodes keep NCs of two-hop radius; the queryis intra-AC: it starts at the central node and is destined to a same-colour border node. The searched AC is a non-overlapping, 60◦pie slice in the network

0

20

40

60

80

100

120

140

160

180

2 2.5 3 3.5 4 4.5 5 5.5 6

Ser

vice

req

uest

mul

tiplic

atio

n fa

ctor

Network hop count radius

Network-wide forwarding of one service request

EZRP, disc topologyABSN, radial chain in EZRP’s disc

Figure 8 Additional network traffic due to the multiplicationof a single service query, in number of packets by the radius ofthe overall network. The network is made up by 3-degree nodesand is an extended star with varying radius; all nodes keep NCsof two-hop radius; the query is intra-AC: it starts at the centralnode and is destined to a same-colour border node linked by achain AC

radial third of the area is reserved to critical patients,which make up one activity cluster for the purposeof getting overviews of the area and of estimating theworst cases at the site. Thus, for this test two ACsoccupy the network: the “critical” AC (including thesource and the destination of the query) occupies a non-overlapping 60◦ pie slice in the overall network. Theresults show that ABSN uses only a fraction (approx-imately equal to the pie slice fraction) of the trafficgenerated by EZRP in order to find the service, andhence scales to large networks better than EZRP in adirect proportion to the size of the ACs relative to theoverall network.

Figure 8 fits the scenario in which an improvisedsensor infrastructure is deployed at the triage site ina radial, linear topology. In this extreme case, only anumber of packets that is linear to the distance fromsource to service is forwarded on the ABSN network,compared to EZRP’s storm of LSAs.

In both above cases, discovery latency is equal forboth EZRP and ABSN, yet ABSN shows a great im-provement in network bandwidth usage, by guiding thequery along the path of an AC, instead of unconditionalbordercasting.

The above tested network scenarios do not make fora complete usage test upon efficiency in traffic overheadin all topologies and AC scenarios, yet they allow forextrapolating the overhead in other topologies, by com-posing the results above. For example, the more generalcase of queries originated in one AC and destined toanother has a network usage efficiency that is a com-bination of the performance of EZRP and intra-ACABSN: the discovery of a gateway for the searched ACperforms like EZRP, while the discovery of the servicestarting at the already found gateway performs like thetests above.

Mobile Netw Appl (2007) 12:129–142 139

One other important test relates to the scalabilityof the protocol; as stated above, the size of an ABSNnetwork, when designing for the most complex majorincident scenario, reaches hundreds of nodes; also, asstated in Section 4.1, since ABSN is a flat protocol, themain measure of scalability is the node size of the net-work clusters, and not the overall network size or theAC size. While a large network cluster would improveresponse times by adding more proactiveness to theoverall network, a limit over the NC size is imposed byresource bounds on the nodes and by limited networkbandwidth.

To test the scalability of the protocol against the NCsize, we take a scenario in which at a major incident sitepatients’ conditions have been assessed by practitionerson the spot; the patients have been associated to threeactivity clusters depending on the severity of their sta-tus, but have not yet been moved into separate triageareas. The three ACs thus spread uniformly over thenetwork, and overlap in all NCs.

For this scenario, Fig. 9 shows the network trafficgenerated by the intra-NC protocol: the figure showsboth the maintenance traffic (hello packets are sent byeach node even in the absence of change) and networkboot traffic (LSA packets are sent at every networkchange). The large number of LSA packets is due to theprocess of building up the network, one node at a time;this amount of LSA traffic will only be repeated duringnormal running of the network in the extraordinaryevent in which node mobility and network interrup-tions will make so that no two nodes will continu-ously find themselves in the same NC they started in

0

500

1000

1500

2000

2500

3000

3500

4000

4500

10 15 20 25 30 35 40 45

num

ber

of H

ELL

Os

and

LSA

s se

nt

size(NC)

Network overhead within one NC [number of packets sent/size(NC)]

LSAsHELLOs

Figure 9 Network traffic, in number of packets by number ofnodes composing the NC. The hello packets have been sent outwithin the bounds of one NC by the link-state proactive intra-NC protocol during a period of time equal to 10 times the helloperiod. The LSA packets have been sent in the initial processof setting up the same network. The NC radius is constant attwo hops, while the NC size varies. The degree of all nodes isproportional to the NC size. Three ACs overlap in this NC, and,at every network change, each node sensing the change triggers,on average, 2

3 of a LSA packet

0

10000

20000

30000

40000

50000

60000

10 15 20 25 30 35 40 45

num

ber

of H

ELL

Os

and

LSA

s re

ceiv

ed

size(NC)

Computation overhead within one NC [number of packets processed/size(NC)]

LSAsHELLOs

Figure 10 Number of receive packet events, summed up forall the nodes in the NC. The hello packets have been sent outwithin the bounds of one NC by the link-state proactive intra-NC protocol during a period of time equal to 10 times the helloperiod. The LSA packets have been sent in the initial process ofsetting up the same network

(a phenomenon which could be called “complete en-tropy” of the network).

The number of hello packets that are sent on thenetwork only varies slightly below 10 times the sizeof the NC, while the number of LSAs varies signifi-cantly with the NC size. This LSA overhead variationis recognizable as being proportional to the square ofthe NC size, which follows the theory: the forwarding ofLSAs (a constant number of them originate from eachnode) would trigger their multiplication by a factorproportional to N ∗ E, where N is the number of nodesand E is the number of edges in the network graph(equal to ρ∗N

2 , where ρ is the average degree of thenodes). This gives a multiplication factor proportionalto N2. Any variation in the test parameters would onlychange the multiplication factor of forwarded LSAs bya constant.

In the same scenario, Fig. 10 shows the total com-putational overhead added to the nodes in the networkbecause of the network traffic in Fig. 9, summed up forall the nodes in the network. Only those received LSAsthat announce a change to a node for the first time willactually be processed (a number equal to the numberof unique LSAs triggered on the network, as in Fig. 9),all the others being duplicates.

ABSN was implemented on Moteiv’s IEEE 802.15.4-compatible Tmote skies, as a set of TinyOS [20] NesC[6] components. NesC and TinyOS (the de facto stan-dard for programming low-resource sensor networks)were used in order to ground ABSN in practice. Forsimulation results that would be a correct reflection ofthe running of the code on sensors, we chose a real-code simulator composed of two pieces of software:OMNeT++ [19], a general networking discrete-eventsimulation environment, and NesCT [12], a languagetranslator from the embedded sensor language NesC

140 Mobile Netw Appl (2007) 12:129–142

into OMNeT++’s C++ classes. NesCT already comeswith the translation for OMNeT++ of the basic TinyOScomponents. Thus, the simulations take into considera-tion all of TinyOS’s features and limitations.

Another measure of the scalability of the protocolis the size of the data structures needed for each nodeto act as a service router. An overview of the RAMconsumption on a TinyOS sensor node is given inFig. 11. The adding of service discovery capabilities tonodes running a link-state routing protocol is done at aninsignificant memory cost. Thus, such proactive servicediscovery schemes can be a natural, low-cost extensionto link-state routing protocols in practice. A Tmote skymodule with 10kB RAM and 48kB programming flashrunning ABSN will take 17.750 kB of ROM and willaccommodate NCs of as many as 62 nodes, while thesizing down of a NC to a more than sufficient 50 nodeswill occupy 7.077 kB of RAM.

Finally, the current primary disadvantage of ABSNis the lack of design for managing activity clustersdisconnected by a number of hops greater than the NCsize. Devising a solution for this greatly depends on thepolicies dictated by the usage scenario: in the case ofan AC composed of body sensors on a patient, the acci-dental loss of a sensor would immediately invalidate thedata read by that sensor; hence, an energy-consumingscheme for keeping the sensor strictly accounted for isnot desirable.

On the other hand, a scenario in which a large ACis accidentally split apart, such as part of a linear sensorinfrastructure deployed at an incident site being put outof order, two solutions can be employed. First, the NCsize of the nodes composing the AC can be increaseduntil the NC radius becomes greater than the hop sizeof the gap. Second, an additional join mechanism can

0

1

2

3

4

5

6

7

8

9

10 20 30 40 50 60

Cac

he c

onsu

mpt

ion,

in K

byte

s

NC size

Total cache consumption by NC and AC size (in number of nodes)

Cache w service table, size(AC)=1.00 x size(NC)Cache w service table, size(AC)=0.50 x size(NC)Cache w/o service table

Figure 11 An overview over RAM consumption on a sensornode running ABSN. Memory consumption is static in TinyOS(there is no dynamic allocation), so that total occupied size canbe found at build time. The graphic leaves out the footprint ofthe application (which is constant with the NC size) and onlyconsiders the size of all data structures involved in routing andservice discovery

be designed, following the example of that employedby multicast ad hoc routing protocols for nodes toannounce their registration to a multicast group. Inthe first case, overhead in traffic and resources is onlyadded to the nodes composing that AC; in the second,the added overhead is network-wide.

6 Conclusions

To summarize our contribution, ABSN is part of aneffort to redesign classical network protocols for abetter applicability in pervasive computing: it uses thehigh-level concept of computational activities (as logicalbundles of data and resources) to give sensors knowl-edge about their usage even at the network layer andit makes use of this logical structuring of the networkfor a more effective service discovery scheme. Notingthat in practical settings activity-based sensor patchesare localized, ABSN designs a completely distributed,hybrid discovery protocol which is proactive in a neigh-bourhood zone and reactive outside, tailored so thatany query among the sensors of one activity is routedthrough the network with minimum overhead, guidedby the bounds of that activity. ABSN enhances thegeneral-purpose extended zone routing protocol withlogical sensor grouping and greatly lowers networkoverhead during the process of discovery, while keep-ing discovery latency close to optimal. Future workincludes generalizing ABSN for use in networks witharbitrarily disconnected activity clusters.

Furthermore, sensor networks are characterized bya need to carefully integrate functionalities in orderto achieve maximum efficiency (especially with respectto energy consumption). ABSN follows this idea andintroduces a close interaction of research from ad hocnetworking and human-centered pervasive computing.

Even though our design for ABSN data rout-ing and service discovery emerged from the medicaldomain, we think that the approach is more generallyapplicable—there exists a range of other applicationdomains where it is practical to model human activitiesand use this modeling for data routing and servicediscovery in a sensor network: fields of application likesmart homes or office spaces and ad hoc peer-to-peerconnectivity in public places could benefit by the ideaof moving some application features into the lowerrouting layer.

Acknowledgements The authors would like to thank the ed-itors and the anonymous reviewers for helping improve thepaper’s grounding in practice and clarity.

Mobile Netw Appl (2007) 12:129–142 141

References

1. Aziz O, Lo B, Yang G-Z, King R, Darzi A (2006) Pervasivebody sensor network: an approach to monitoring the post-operative surgical patient. In: Proceedings of the interna-tional workshop on wearable and implantable body sensornetworks, 2006 (BSN 2006), pp 13–18. IEEE Press

2. Bardram JE (July 2005) Activity-based computing: supportfor mobility and collaboration in ubiquitous computing. Per-sonal Ubiquitous Computing 9(5):312–322

3. Chakraborty D, Joshi A, Yesha Y, Finin T (2002) GSD: anovel group-based service discovery protocol for MANETS.Mobile and Wireless Communication Networks

4. Cheng L (2002) Service advertisement and discovery inmobile ad hoc networks. Computer supported cooperativework workshop on ad hoc communications and collaborationin ubiquitous computing environments

5. Division of Engineering and Applied Sciences of HarvardUniversity (2006) CodeBlue: wireless sensor networks formedical care. Available at http://www.eecs.harvard.edu/mdw/proj/codeblue/

6. Gay D, Levis P, von Behren R (2003) The nesC language: aholistic approach to networked embedded systems. In: Pro-ceedings of the ACM SIGPLAN 2003 conference on pro-gramming language design and implementation (PLDI)

7. Grajales L, Nicolaescu IV (2006) Wearable multisensor heartrate monitor. In: Proceedings of the International Workshopon Wearable and Implantable Body Sensor Networks, 2006(BSN 2006), pp 154–157. IEEE Press

8. Haas ZJ, Pearlm MR, Samar P (2002) The zone routing pro-tocol (ZRP) for ad hoc networks. IETF MANET InternetDraft

9. Helal S, Desai N, Verma V, Lee C (2003) Konark—a servicediscovery and delivery protocol for ad-hoc networks. Wire-less Communications and Networking Conference

10. Helmy A, Garg S, Nahata N, Pamu P (2005) CARD: acontact-based architecture for resource discovery in wirelessad hoc networks. J Spec Top Mob Netw Appl 10:99–113

11. Hester T, Hughes R, Sherrill D, Knorr B, Akay M, Bonato P(2006) Using wearable sensors to measure motor abilities fol-lowing stroke. In: Proceedings of the International Workshopon Wearable and Implantable Body Sensor Networks, 2006(BSN 2006), pp 5–8. IEEE Press

12. Kaya OS (1999) NesCT: a language translator. Available athttp://nesct.sourceforge.net/.

13. Koodli R, Perkins CE (2002) Service discovery in on-demandad hoc networks. IETF MANET Internet Draft

14. Kristensen M, Kyng M, Palen L (2006) Participatory designin emergency medical service: designing for future practice.In: CHI, pp 161–170

15. Nidd M (2000) Timeliness of service discovery inDEAPspace. In: ICPP Workshops, p 73

16. Ratsimor O, Chakraborty D, Joshi A, Finin T (2002) Allia:alliance-based service discovery for ad-hoc environments. In:Proceedings of the second ACM international workshop onmobile commerce (WMC-02), pp 1–9, New York, September28, 2002. ACM Press

17. Sailhan F, Issarny V (2005) Scalable service discovery forMANET. In PerCom, pp 235–244. IEEE Computer Society

18. Schiele G, Becker C, Rothermel K (2004) Energy-efficientcluster-based service discovery. In: Proceedings of the11th ACM SIGOPS European Workshop (SIGOPSEW04);Leuven, Belgium, September 20–22, 2004, Artikel inTagungsband, pp 75–79. ACM SIGOPS

19. The Open TinyOS community (2007) OMNeT++: dis-crete event simulation system. Available at http://www.omnetpp.org/

20. The Open TinyOS Community (2004) TinyOS. Available athttp://www.tinyos.net/

21. The PalCom Consortium (2007) Palpable computing. Avail-able at http://www.ist-palcom.org/application-areas/major-incidents/

22. Ververidis CN, Polyzos GC (2005) Extended ZRP: arouting layer based service discovery protocol for mobile adhoc networks. In: MobiQuitous, pp 65–72. IEEE ComputerSociety

Doina Bucur is a PhD student in computer science at theUniversity of Aarhus, Denmark. Her research interests includetopics on ubiquitous computing, such as context-aware network-ing middleware in ad hoc networks, and modelling and reasoningformally upon context awareness, safety and performance issuesin mobile networks. She has a MSc in computer science fromPolitehnica University of Bucharest, Romania and is a studentmember of IEEE. Email: doina@daimi.au.dk

Jakob E. Bardram is a professor at the IT University ofCopenhagen (ITU). His research interests are Perva-sive Computer Systems, Object Oriented Software Architecture,Computer Supported Cooperative Work (CSCW); and Human-Computer Interaction (HCI). The main application area of thisresearch is within healthcare, especially Pervasive Healthcare.

Jakob E. Bardram has previously held positions as projectmanager and IT architect at IBM Denmark, where he archi-tected and managed several e-business projects. And he has

142 Mobile Netw Appl (2007) 12:129–142

been an industrial research fellow at CSC Scandihealth, wherehe worked with software architectures for cooperative systemsin hospitals.

Jakob E. Bardram received his PhD in computer science in1998 from the University of Aarhus, Denmark. Since returning

to academia in 2001, he has been involved in several research anddevelopment projects with industry. He has just finished editinga book on Pervasive Healthcare and has edited a special issue ofPervasive Healthcare in the IEEE Transactions on InformationTechnology in Biomedicine.