Vehicle to Vehicle Services

Service oriented architecture for pervasive computing systems

with emphasis on vehicle to vehicle applications

Jeppe Brønsted

PhD Dissertation

Department of Computer Science

University of Aarhus
Denmark
 Vehicle to Vehicle Services
Service oriented architecture for pervasive computing systems
with emphasis on vehicle to vehicle applications

A Dissertation
Presented to the Faculty of Science
of the University of Aarhus
in Partial Fulfillment of the Requirements for the
PhD Degree

by
Jeppe Brønsted
August, 
 A

As computing devices, sensors, and actuators pervade our surroundings, new ap-
plications emerge with accompanying research challenges. In the transportation
domain vehicles are being linked by wireless communication and equipped with
an array of sensors and actuators that make is possible to provide location aware
infotainment, increase safety, and lessen environmental strain.
is dissertation is about service oriented architecture for pervasive computing
with an emphasis on vehicle to vehicle applications. If devices are exposed as ser-
vices, applications can be created by composing a set of services and governing the
flow of data among them. In pervasive computing, composing services is, however,
not the whole story. To fully realize their potential, applications must also deal
with challenges such as device heterogeneity, context awareness, openendedness,
and resilience to dynamism in network connectivity, mobility, and availability of
services.
e dissertation consists of two parts. Part I gives an overview of service ori-
ented architecture for pervasive computing systems and describes the contributions
of the publications listed in part II. We investigate architecture for vehicular tech-
nology applications by looking at network architecture, middleware architecture,
and the interplay between the architecture and the business model. Data dissem-
ination in vehicular networks is investigated by looking at different dissemination
models and protocols, and by describing how data dissemination protocols can be
evaluated. Service composition mechanisms for pervasive computing are catego-
rized and we discuss how the characteristics of pervasive computing can be sup-
ported by service composition mechanisms. Finally, we investigate how to make
pervasive computing systems capable of being noticed and understood by letting
the user open up the system for inspection in breakdown situations.

i
 A

I wish to thank all the people that in some way or another have contributed to the
creation of this dissertation. Most importantly, I wish to thank my advisor, Klaus
Marius Hansen, for insightful and engaged guidance and for keeping me on track
while at the same time giving me freedom and peace to work.
In addition, I also thank the people I have worked professionally with to create
papers and software: Mads Ingstrup, David Fors, Erik Grönvall, Lars Kristensen,
Toke Eskildsen, and Rolf orup. I thank Boris Magnusson for a interesting stay
at Lunds Tekniska Högskola. I thank Daimi for being a great place to study and
work and Secale for giving me food for thought.
My thanks also goes to LIWAS ApS, ISIS Katrinebjerg Software, the PalCom
project, and BRICS International PhD School for sponsoring my PhD studies.

Finally, a I thank Clara, Linus, and especially Solveig for making it possible to
complete a PhD while living a wonderful family life.

Jeppe Brønsted
Århus, August .

iii
 C

Abstract i

Acknowledgements iii

Contents v

List of Figures ix

List of Tables xi

I Overview 
 Introduction 
. Pervasive Computing . . . . . . . . . . . . . . . . . . . . . . . . . 
. Vehicle to Vehicle Applications . . . . . . . . . . . . . . . . . . . 
. Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 
. Service Oriented Architecture . . . . . . . . . . . . . . . . . . . . 
. Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Research Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Research Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

 Architecture in Vehicular Technology Applications 

. Vehicular Technology Applications . . . . . . . . . . . . . . . . . 
. Architectural Choices . . . . . . . . . . . . . . . . . . . . . . . . . 

 Data Dissemination in Vehicle to Vehicle Networks 

. Delivery Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Protocol Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

 Service Composition 
. A Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Service Composition Model . . . . . . . . . . . . . . . . . . . . . 
. Categorization Framework . . . . . . . . . . . . . . . . . . . . . . 

v
Contents

. Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

 Palpability in Pervasive Computing 

. Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

 Conclusion 
. Summary of Contributions . . . . . . . . . . . . . . . . . . . . . . 
. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

II Publications 

 An Infrastructure for a Traffic Warning System 

. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Main Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 
. System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 
. Prototype : Basic Wireless Inter-Unit Communication . . . . . . 
. Prototype : e OSVM Platform and Application Level Features 
. Prototype : Initial Deployment . . . . . . . . . . . . . . . . . . . 
. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . 

 Two Zone Dissemination Protocols for Vehicular Ad-hoc Networks 

. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Zone Dissemination Protocols . . . . . . . . . . . . . . . . . . . . 
. Simulation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . 
. Conclusions and Future Work . . . . . . . . . . . . . . . . . . . . 
. Algorithm Primitives . . . . . . . . . . . . . . . . . . . . . . . . . 

 A Uniform Publish-Subscribe Infrastructure 

. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. PSI - a Publish-Subscribe Infrastructure . . . . . . . . . . . . . . . 
. PSI in the LIWAS System . . . . . . . . . . . . . . . . . . . . . . 
. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

 Palpability support demonstrated 

. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Active Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Conclusions and Future Work . . . . . . . . . . . . . . . . . . . . 

vi
 Contents

 Handling membership dynamicity in service composition 

. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. e PalCom Open Architecture . . . . . . . . . . . . . . . . . . . 
. e Site Sticks Scenarios . . . . . . . . . . . . . . . . . . . . . . . 
. Handling Membership Dynamicity . . . . . . . . . . . . . . . . . 
. Decentralized Interpretation . . . . . . . . . . . . . . . . . . . . . 
. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

 Issues in Service Composition for Pervasive Computing 

. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Indicators for Characteristics . . . . . . . . . . . . . . . . . . . . . 
. Characteristic/Indicator Dependencies . . . . . . . . . . . . . . . . 
. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

 Service Oriented Architecture for Inter-vehicle Applications 

. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. VANET Characteristics . . . . . . . . . . . . . . . . . . . . . . . 
. Why Use VANETs? . . . . . . . . . . . . . . . . . . . . . . . . . 
. Service Oriented Architecture . . . . . . . . . . . . . . . . . . . . 
. A Business Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Requirements on SOA Infrastructure . . . . . . . . . . . . . . . . 

Bibliography 

vii
 L  F

. Contribution Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. Conceptual Architecture Overview . . . . . . . . . . . . . . . . . . . 

. Delivery Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Service composition model . . . . . . . . . . . . . . . . . . . . . . . . 
. GasPrices script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. Tiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. Deployment diagram for the abstract LIWAS system architecture. . . . 

. Environment for prototype  experiments. . . . . . . . . . . . . . . . . 
. Stationary - Mobile Communication at  km/h. . . . . . . . . . . . . 
. Mobile - Mobile Communication at  km/h. . . . . . . . . . . . . . 
. Relative speed of  km/h. . . . . . . . . . . . . . . . . . . . . . . . 
. Stationary - Mobile at  km/h. . . . . . . . . . . . . . . . . . . . . . 
. Platform and user interface for prototype . . . . . . . . . . . . . . . . 

. e Zone Flooding Protocol. . . . . . . . . . . . . . . . . . . . . . . . 

. e Zone Diffusion Protocol. . . . . . . . . . . . . . . . . . . . . . . 
. e simulation scenario. . . . . . . . . . . . . . . . . . . . . . . . . . 
. e Information Distance metric. . . . . . . . . . . . . . . . . . . . . 
. Medium velocity,  nodes. . . . . . . . . . . . . . . . . . . . . . . . 
. Medium velocity,  nodes. . . . . . . . . . . . . . . . . . . . . . . . 
. Low velocity,  nodes. . . . . . . . . . . . . . . . . . . . . . . . . . 
. High velocity,  nodes. . . . . . . . . . . . . . . . . . . . . . . . . . 
. Low velocity,  nodes. . . . . . . . . . . . . . . . . . . . . . . . . . 
. Low velocity,  nodes. . . . . . . . . . . . . . . . . . . . . . . . . . 
. Low velocity,  nodes. . . . . . . . . . . . . . . . . . . . . . . . . . 
. High velocity,  nodes. . . . . . . . . . . . . . . . . . . . . . . . . . 
. Pareto optimal solutions. High velocity,  nodes. . . . . . . . . . . . 

. LIWAS operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. Infrastructure deployment diagram . . . . . . . . . . . . . . . . . . . 

ix
List of Figures

. Topic hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. Publish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Subscribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Gateway example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. LIWAS deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. Tiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Catch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Scrabble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Puzzle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. PalCom layered runtime system . . . . . . . . . . . . . . . . . . . . . 
. Simulation framework . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Services in the puzzle game . . . . . . . . . . . . . . . . . . . . . . . . 
. Puzzle assembly script . . . . . . . . . . . . . . . . . . . . . . . . . . 

. Geotagger script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. Site Sticks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. SiteSticks script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Mean command propagation time . . . . . . . . . . . . . . . . . . . . 

. A general model of the elements in service composition. . . . . . . . . 

. Value chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. Example operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

x
 L  T

. Research approaches used . . . . . . . . . . . . . . . . . . . . . . . . 

. Vehicle technology applications . . . . . . . . . . . . . . . . . . . . . 

. Network architecture characteristics . . . . . . . . . . . . . . . . . . . 

. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Methods and Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. Characteristic/Category Dependencies . . . . . . . . . . . . . . . . . 

. Categorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Categorization of Service Composition Mechanisms . . . . . . . . . . 

. Stationary-mobile communication. . . . . . . . . . . . . . . . . . . . 

. Mobile-mobile communication. . . . . . . . . . . . . . . . . . . . . . 
. Feasible update sizes in different scenarios. . . . . . . . . . . . . . . . 

. Mobility classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

. Simulation parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . 
. Lowest Awareness Percentage requirement to choose Zone Flooding. . 
. Maximum packets sent allowance requiring Zone Diffusion to be chosen.

. Experimental user study . . . . . . . . . . . . . . . . . . . . . . . . . 

. Characteristic/Indicator Dependencies . . . . . . . . . . . . . . . . . 

. Categorization of Service Composition Mechanisms . . . . . . . . . . 

xi
 P I

O


C Ո 

I

As computing devices, sensors, and actuators pervade our surroundings, new ap-
plications emerge with accompanying research challenges. In the transportation
domain vehicles are being linked by wireless communication and equipped with
an array of sensors and actuators that make is possible to provide location aware
infotainment, increase safety, and lessen environmental strain.
e highly dynamic vehicular environment, however, poses significant chal-
lenges to application developers. Vehicles driving in opposite directions are only
in communication range for a few seconds. Furthermore, in sparse traffic, there is
poor network connectivity and dense traffic challenges the scalability of algorithms.
Enabling communication among vehicles requires optimized protocols that exploit
properties of the communicated data and the mobility of vehicles.
Each vehicle can contain a plethora of devices, sensors, and actuators that are
provided by a multitude of manufacturers and connecting them in applications is
no simple task. Each device can possibly be part of multiple applications and some
applications might place requirement on the quality of the service provided by a
device.
is dissertation is about service oriented architecture for pervasive computing
with an emphasis on vehicle to vehicle applications. If devices are exposed as ser-
vices, applications can be created by composing a set of services and governing the
flow of data among them. In pervasive computing, composing services is, however,
not the whole story. To fully realize their potential, applications must also deal
with challenges such as device heterogeneity, context awareness, openendedness,
and resilience to dynamism in network connectivity, mobility, and availability of
services.
e research question we seek to explore in this dissertation is the following
reformulation of the above:

How can service oriented architecture be used to structure applications in a

way that alleviates the challenges of pervasive computing and in particular
vehicle to vehicle applications?

e papers presented in part II documents our efforts in illuminating various

aspects of how to use services in vehicular applications.


Chapter . Introduction

In the following sections, we describe the background for the research con-
ducted (section .–.). Following that, in section . we shortly describe the
contributions of the papers in part II. In section ., we describe the research
approach used in this dissertation and in section ., we describe the context the
research has been conducted in. Finally, in section . we give an outline of the rest
of the dissertation.

. P C

As formulated by Weiser in  [] ubiquitous computing is about integrat-

ing computers seamlessly into the world in such a way that they disappear in use.
When everyday objects are enhanced with computing and communication capabil-
ities, new applications are made possible that will enhance peoples’ lives with in-
creased productivity, comfort, and security. From a technical perspective, pervasive
computing challenges the way we build systems by significantly changing the basic
assumptions that can be made, and by setting new requirements. Here we divide
the challenges into heterogeneity, dynamicity, context awareness, and openendedness

Heterogeneity Applications of pervasive computing often consist of heterogeneous

devices ranging from embedded sensor nodes to servers on the Internet. e de-
vices can have varying resources with respect to computational capacity, available
memory, power, communication bandwidth, and latency. Not only is it a challenge
to construct middleware that can run on resource constrained devices, it is also a
challenge to take full benefit from the resource rich nodes. Pervasive computing
middleware should not be limited by the least common denominator with respect
to resources, but should take advantage of all devices in the system.
Devices can also be based on heterogeneous system architectures and operating
systems and this complicates the process of maintaining a deployment.

Dynamicity A system designer can not always assume that a device is connected
to the network, that it has a particular location, or that nearby devices are available.
In pervasive computing environments, there is not always a fixed network that de-
vices can use for communication. If wireless communication such as infrared light
or radio is used, links are unreliable. If devices are also mobile, they can move
in and out of communication range. Mobility can also cause the network topol-
ogy to change, forcing network protocols to be adaptive. Ad-hoc communication
protocols such as Ad hoc On-Demand Distance Vector Routing (AODV) [],
Dynamic Source Routing Protocol (DSR) [], and Optimized Link State Rout-
ing Protocol (OLSR) [] go a long way in maintaining network connectivity in
spite of unreliable links and changing topology, but developers have to take into
account that situations with no connectivity will most likely occur.

¹In this dissertation, we use the terms ubiquitous computing and pervasive computing inter-
changeably.


 .. Vehicle to Vehicle Applications

Context awareness A pervasive computing application should be sensitive to the

users context in a way that hides details when possible but exposes them when
necessary. If, e.g., a device with a required functionality disappears, it should be
replaced with a similar device or, in case no such device exists, the user should be
notified. Schilit et al. [] categorizes context awareness according to whether
the task at hand is getting information or carrying out a command, and whether it is
effected manually or automatically. For example, automatic-command corresponds
to the automatic execution of an action due to changes in the context, whereas the
manual-information category is about providing context information on request -
e.g. by delimiting a list of printers by using information about the users location.

Openendedness One particular instance of context sensitivity is to adapt applica-

tion functionality to new purposes due to changes in the user context. For example,
a navigation system could be altered to be part of a fleet management system by
adding a device with a General Packet Radio Service (GPRS) [] connection to
the vehicle. With respect to openendedness, the user plays a central role because it
can be hard for the system to automatically detect changes in what the user wants
to do. In the above example, the user could, e.g., also use the GPRS connection to
receive tourist information about the area he is driving in. If the user is involved in
specifying what he wants to do, it is necessary that he has a basic understanding of
which devices can be connected and how to do it. Whether it is done by download-
ing an application matching his requirements from the Internet or by connecting
boxes in a Graphical User Interface (GUI), it is important that the user not only
understands what is happening under normal operation, but also that he is able to
resolve the contingencies that might occur.

. V  V A

In recent years the adoption of distributed systems in vehicles have increased sig-
nificantly by the introduction of Global Positioning System (GPS) [] navigation,
fleet management systems, speed camera notification systems [], TMC [] traf-
fic information notification systems, etc. One example is the OnStar system [] in
which a cell phone and a GPS system are connected to the vehicle bus to provide
a wide range of services ranging from remote engine diagnostics to automatic geo-
tagged emergency calls. e system has currently over  million subscribers and
processes more than  calls every month. A common point of commercial
systems is that most use wide-range radio technology for communication. Only a
few, if any, rely on vehicular ad-hoc networks (VANETs) using short-range com-
munication. In research however, VANETs have been studied extensively [] and
is one of the main application areas for mobile ad-hoc networks (MANETs) in
general.
Vehicular ad-hoc networks consisting of nodes communicating by using short-
range wireless radios are characterized by having a high degree of variability in node


Chapter . Introduction

mobility and node density. e mobility pattern of vehicles is heavily influenced

by the layout of roads and the current traffic situation. Normally, on highways
approaching vehicles will only be within transmission range for a few seconds de-
pending on antenna and propagation conditions. However, if traffic congestion
occurs, vehicles driving in the same direction can be within range for hours. In
addition, traffic congestion also imposes a dense network topology with a lot of
nodes simultaneously in transmission range. In contrary, sparse traffic conditions
are typical in rural areas.
While these characteristics make it complicated to implement applications that
utilize VANETs for communication, VANETs are nevertheless necessary because
the alternative, wide range cellular communication, has a set of disadvantages that
may negatively influence an applications ability to provide its services. First of all,
currently cellular technology provides significantly lower bandwidth on node-to-
node communication. Wireless communication has the property that the nodes
in range share the communication capacity of the medium, and the larger range
a signal has, the more nodes have to share the bandwidth. is is not necessarily
a problem if the node density is low (e.g. in rural areas), but in areas where the
node density is high, severe constraints are put on the communication bandwidth.
Secondly, the coverage provided by cellular systems is limited in some regions. Note
however that this may change in time. ird, cellular communication links typically
have high latency. Finally, using cellular communication usually entails some form
of paid subscription.  
ese disadvantages have the effect that some applications cannot be realized
using cellular communication. e literature provides a wealth of examples. E.g.
systems that warns about hazardous driving conditions such as ice (cf. chap. ),
roadwork, traffic congestion [], vehicle collision avoidance systems [], etc. To
realize the full potential of these applications, short-range wireless communication
must be used.
In spite of the reasons for using short-range communication mentioned above,
we are not aware of any commercial applications employing it. One factor is that
systems relying on short-range wireless communication are typically more complex
in design, implementation, evaluation, and deployment. If the application can be
realized without short-range communication, it is most likely a cheaper solution,
but as we argued above, this is not always possible.
Another factor is that a lot of the applications mentioned above require a crit-
ical mass to work optimally. One example could be a system providing warnings
about icy roads. Vehicles equipped with the system disseminate warning messages
to approaching vehicles. If not enough nodes are equipped with the system, there
is a high probability that messages will not reach the approaching vehicles. Fur-
thermore, only vehicles equipped with the system will receive warnings.
In this dissertation, we mainly focus on protocols and architectures for applica-
tions employing vehicle to vehicle networks.


 .. Software Architecture

. S A

An important concern in realizing large computing systems is the software archi-

tecture of the system. Bass et al. [, p. ] defines software architecture as follows:
e software architecture of a program or computing system is the structure
or structures of the system, which comprise software elements, the externally
visible properties of those elements, and the relationships among them.
When a software architecture is created for a system, it is important to ensure
that a set of concerns are balanced. Besides the functional requirements that de-
scribe what the system is supposed to do, a set of orthogonal quality requirements
restricts the systems behavior with respect to properties such as availability, modi-
fiability, performance, security, testability, and usability. Some of these properties
are inversely connected in the sense that improving support for one adversely af-
fects the other. For example, one way to improve protocol performance is to make
cross-layer optimizations, which is bad for modifiability because it makes the code
less modular.
Bass et al. [] presents a set of tactics that can be used to enhance support for
specific quality requirements. E.g., heartbeats can be used to monitor a service to
enhance availability by detecting faults early and thus making it possible to resolve
the fault before it becomes a failure.
At a level higher, an architectural style [] is a set of rules that governs the
design of the architecture. Having an architectural style makes it easier to con-
sistently maintain a system because it enhances the systems conceptual integrity.
Some styles are better suited for particular purposes than other. Since the choice
of selecting an architectural style is made before an application or system is imple-
mented, clues to what style to choose are useful. Architectural decisions made at
this point are highly influential on the resulting system and the process of creat-
ing it. If a bad decision is made at an early stage it can prove to be the difference
between success and failure. e choice of a particular architectural style is no guar-
antee for success in itself and therefore details on how the style should be applied
are at least as important as clues to what style to use.

. S O A

In this dissertation, we investigate the use of a particular architectural style, Service

Oriented Architecture. In Oasis’ Reference Model for Service Oriented Architec-
ture [] it is stated that:
Service Oriented Architecture (SOA) is a paradigm for organizing and uti-
lizing distributed capabilities that may be under the control of different
ownership domains.
In SOA, the needs of entities are met by capabilities provided by other entities.
At the most abstract level, a capability can be seen as the ability to affect the world in


Chapter . Introduction

some way. In a software system this usually amounts to performing a computation,

doing a transaction, reading a sensor, activating an actuator, etc. - all the things
that can be performed or initialized from software. Correspondingly, a need is the
desire to affect the world in some way. To match needs and capabilities in a software
system, the needing entity must, directly or indirectly, be able to communicate with
the entity providing the capability. e software counterpart of a capability is a
service, which we define as follows:

A service is a unit of runtime software accessible by others.

A service encapsulates a piece of functionality and offers it to the world in such

a way that the user of a service not necessarily has to be in control of the service.
In other words, the entity using a service does not have to belong to the same
company or organization as the entity providing the service. is property makes
SOA suited for pervasive computing because making a wealth of different devices
cooperate is a prerequisite for pervasive applications. SOA makes it possible to
cleanly organize the devices in a pervasive computing application in a consistent
and structured manner.
To enable service oriented architecture in a system, a service infrastructure is
needed. e complexity of such an infrastructure can range from protocols en-
abling primitive service invocation to advanced frameworks with semantic service
descriptions and error handling. Furthermore, the act of using a set of services to
form an application can be supported at multiple levels. Perhaps, the simplest ap-
proach is to invoke services directly from source code in the application. A better
option is to use a service composition mechanism to compose the service into an
application. In chapter , we discuss issues in service composition for pervasive
computing.

. C

In the following, we shortly describe the contributions of the papers in Part II in

chronological order. Figure . maps the papers into each of the previous back-
ground topics.

An Infrastructure for a Traffic Warning System (Chap. ) is paper presents our
results on requirements identification, design, and prototyping of an Infrastruc-
ture for a traffic warning system. e infrastructure combines communication via
mobile phones with communication based on the principles of ad-hoc network-
ing, and it supports units in being updated during operation. A set of prototypes
realizing various aspects of the infrastructure is presented along with associated ex-
perimental results that demonstrate the main functionalities of the communication
infrastructure, and have led to the initial deployment of LIWAS units.


 .. Contributions

Pervasive Computing

Software Architecture

Service Oriented Architecture

Service Composition Vehicle to vehicle applications

Handling membership
dynamicity in service An Infrastructure for a
composition for ubiquitous Traffic Warning System
computing Specification and
Service oriented
Performance Evaluation of
architecture for inter-
two zone dissemination
vehicle applications A Uniform publish
A survey of service protocols
subscribe infrastructure for
composition mechanisms
communication in wireless
in pervasive computing
mobile environments

Palpability support
demonstrated

Figure .: Contribution Map

Two Zone Dissemination Protocols for Vehicular Ad-hoc Networks (Chap. ) Here,
we present two candidates for data dissemination protocols: a zone flooding pro-
tocol and a zone diffusion protocol. e two protocols combine ideas from sensor
networks and geocasting to ensure that data is aggregated and distributed only in a
bounded geographical area. We present a comparative simulation study of the two
protocols evaluating their relative performance using conventional metrics (such
as network load) as well as application-specific metrics (such as awareness). e
simulation study has been conducted using the Network Simulator  (NS-) and
has highlighted key properties of the two protocols that can be used as a basis for
selecting the most appropriate protocol.

A Uniform Publish-Subscribe Infrastructure (Chap. ) In this paper, we present

PSI, a uniform publish-subscribe based infrastructure, for communication in wire-
less mobile environments. In PSI the application is divided into software compo-
nents that each handles a well defined part of the functionality and communicates
with other components using the publish-subscribe paradigm. From a components
perspective it makes no difference where the receivers of a message are located - in
the same process, in another process on the same node, or in a process on a remote
node. All communication is handled uniformly. By showing how the infrastruc-
ture is used in a concrete instance, we argue that it hides the complexity of low level
network programming and presents a clean and understandable abstraction over
communication to the application programmer.

Palpability support demonstrated (Chap. ) In this paper, we demonstrate how

palpability can be supported in a prototype of the rehabilitation concept Active
Surfaces in which children assemble floating tiles into meaningful configurations.
Services on the tiles have been developed using a framework that allows them to be
combined into assemblies. e support for palpability is shown by examples of use


Chapter . Introduction

scenarios from the work of the therapist who can inspect and alter the runtime state
of the tiles to change their configuration and cope with breakdown situations. e
prototype implementation runs on a standard PC simulating the network layer and
a first reference implementation has been made on the target embedded platform.

Handling membership dynamicity in service composition (Chap. ) In this paper,

we show how the PalCom service composition language can be extended to support
service composites with dynamic membership and present a decentralized imple-
mentation. Preliminary user studies indicate that the extensions are easily under-
standable and simulations of application scenarios show that the performance of
the implementation is appropriate for ubiquitous computing applications.

Issues in Service Composition for Pervasive Computing (Chap. ) Composition of

services, i.e. providing new services by combining existing ones, is an idea pervading
and thus important to pervasive computing. However, compared to other areas of
computer science, pervasive computing technologies are more openended, context
aware, dynamic, heterogeneous, often use networked sensors and actuators, and
present new challenges to usability. ese six characteristics pose requirements to
the design of service composition mechanisms that are unique to pervasive com-
puting. We catalogued the technologies that in one form or another can be said to
support service composition for pervasive computing, and describe their variation
points. ese variation points in the design of existing composition mechanisms
are important indicators for how well the resulting composites are able to cope with
and exhibit the six key characteristics of pervasive computing. Our assessment of
the selected technologies indicate that there is a need for more research into pro-
viding appropriate security for composites; into managing the contingencies which
arise naturally in a pervasive computing environments; and for doing more thor-
ough evaluation of the technologies, both with respect to utility and performance.

Service Oriented Architecture for Inter-vehicle Applications (Chap. ) In this paper,
we claim that to maximize the number of nodes participating in vehicle to vehicle
applications, it is important that corporations and organizations cooperate to merge
their user bases so that they each reach the critical mass of participating nodes
required to realize the full potential of the systems. We show how service oriented
architecture can be used to by split applications up in services and sharing them
across different ownership domains in a way that provides value for all stakeholders.
From a business case for a set of applications, we deduce technical requirements for
a service infrastructure for VANETs.

. R A

We use March and Smiths framework for research in information technology []
to describe our research approach. In the paper, the terms information technology


 .. Research Approach

research and computer science are used interchangeably. First, we briefly describe the
framework.
One perspective on computer science is that is a combination of the approaches
used in natural and design sciences. According to March and Smith “natural science
aims at understanding and explaining phenomena”, whereas “design sciences aims
at developing ways to achieve human goals”. e basic activities in design science
is to build and evaluate, whereas natural science is often viewed as consisting of
making theories and justifying them.
In computer science, the objects investigated are typically artifacts created or
built by man as opposed to, e.g., in physics where natural phenomena are studied.
To determine the performance of an artifact it is evaluated by using appropriate
metrics. To explain the performance observed, theories are developed that describe
the artifact and its relation to the environment. Finally, the theories must be justi-
fied by using analytical or experimental approaches, depending on the nature of the
artifact. March and Smith states that these four research activities - building, eval-
uating, theorizing, and justifying - can be applied to four kinds of research outputs:
constructs, models, methods, and instances. Constructs or concepts are used to de-
scribe a domain, models express relationships among concepts, methods describe
processes (e.g. algorithms), and instances are realizations of artifacts.
For example, consider the paper describing two zone dissemination protocols
in chapter . e research behind the paper consisted of building two method s
(protocols) for data dissemination in vehicular ad-hoc networks and evaluating their
performance using metrics such as, e.g., network load. It was conjectured that the
protocols were robust to changing conditions in the network environment and this
theory was justified by analyzing simulation results for a range of different network
environments.
e research documented in part II have been conducted using several of the
activities and outputs described above. In the matrix formed by crossing the activity
and output axes (table .) we have inserted the contributions according to what
have been used. e numbers in the table correspond to chapters in part II.

Build Evaluate eorize Justify

Construct 
Model    
Method , ,  , ,   
Instantiation ,, , , ,   

Table .: Research approaches used

As can be seen from the table, most of the research effort has been on build-
ing and evaluating instances and methods ( papers). is indicates that the re-
search have been mainly engineering oriented using methods from design science.
Although theories have been developed and justified, most of these theories are


Chapter . Introduction

about artifacts created by the author ( papers). e only exception is the survey
(Chap. ), which investigates work by other authors.
e lack of “Construct” research outputs indicates that focus primarily has been
on dealing with more practical issues and only secondly on forming constructs and
concepts.

. R C

e research presented in this dissertation has been conducted as part of the LIWAS
and PalCom research projects. Although the foci of the projects are somewhat dif-
ferent, both deal with pervasive computing challenges such as mobility, dynamicity,
and context awareness by using service oriented architecture.
e LIfe WArning System (LIWAS) is a traffic warning system being devel-
oped in a research collaboration between ISIS Katrinebjerg at University of []
and LIWAS ApS []. e LIWAS system is based on sensors that are capable
of determining whether the surface of the road is dry or covered with water, snow,
or ice. A LIWAS sensor consists of a collection of sensors that are collectively used
to classify the state of the road. e concrete sensor configuration can be adapted
to match requirements to classification accuracy and manufacturing cost. A vehi-
cle equipped with a LIWAS sensor can inform the driver about the state of the
road being passed and hereby help the driver take precautions according to the cur-
rent road conditions. In addition to intra-vehicle communication, the vision is to
use wireless communication to disseminate information to other vehicles and road
authorities.
In the EU funded IST project PalCom [] a conceptual framework and an
open architecture have been developed for ‘palpable computing’. Palpable comput-
ing is a new perspective on pervasive computing in which some of the traditional
pervasive computing tenets such as invisibility and composition have been com-
plemented with visibility and decomposition. e concept has been formed based
on the observation that when applied in real settings, pervasive computing systems
tend to become hard to understand for users. For example, in normal use the sys-
tem should be invisible and not interfere with the present task. However, when a
breakdown occurs the user should be able to inspect the system to determine the
reason and, if possible, resolve the situation. A collection of tools to be used in pal-
pable computing application have also been developed and used in real life scenarios
developed in cooperation with end users.

. O

e rest of part I is structured as follows. In the next chapter, we analyze archi-

tecture for vehicular technology applications by analyzing the variability in appli-
cations and discuss important architectural choices. Following that, we describe
data dissemination in vehicle to vehicle networks in chapter . In chapter , we
look at service composition for the realization of service oriented architecture. In


 .. Outline

chapter , we discuss palpability in pervasive computing and, finally, in chapter 

we conclude the dissertation by summarizing the contributions made and give di-
rections for future work.


C Ո 

A  V T A

In the domain of vehicular technology applications, there is a great variation in

requirements for applications. Consider, e.g., a system for automatically notifying
the emergency dispatch centre in case of an airbag deployment and a system for
allowing vehicles to automatically drive in a platoon. While loss of life can be a
consequence in the case of a system failure for both applications, the requirements
for communication latency, bandwidth, and coverage differ significantly. A latency
of  seconds is inconsequential for the automatic emergency notification system,
whereas a latency of two seconds in a platooning system can easily cause a crash.
e communication channel of the automatic notification system only has to carry
a few kilobytes of information in the event of a crash, whereas in the platooning
system each vehicle potentially sends and receives position and direction updates
continuously. Finally, while the automatic notification system has to be able to
contact an emergency dispatch centre no matter where the vehicles is located, the
platooning system can easily operate disconnected from the Internet and other wide
area networks.
e requirements for a system guide the architect in making choices in the de-
sign of the architecture. For example, the low latency requirement in the platooning
system tells the architect that he should not rely on cellular communication, because
with cellular communication there is typically a high latency. In this chapter, we
look at the architects choices with respect to network architecture, middleware ar-
chitecture, and business model interplay.
e network architecture has a major impact on which communication require-
ments can be satisfied. e selection of one network architecture over another can
easily make it impossible to realize the system in a way that satisfies the require-
ments for communication. For example, if communication is based on GPRS con-
nections, position updates cannot be sent multiple times per second as required in a
platooning application. Network architecture is described in detail in section ...
e middleware architecture affects how complicated a system will be to imple-
ment and maintain. Vehicular technology applications often consist of a wide range
of sensors, actuators, and communication interfaces that use different protocols for
communication making it hard to maintain a consistent view on the middleware
architecture. Furthermore, since some of these protocols employ information only


Chapter . Architecture in Vehicular Technology Applications

available in the application layer for routing, a strict layered architecture is infeasi-
ble. We will elaborate further on this in section ...
Finally, there is a strong connection between the choice of architecture and the
choice of business model. Some architectures rule out some business models and
vice versa. For example, applications based on ad-hoc networks depend on a large
user base, which, in turn, depends on the business model. is will be further
described in section ...
As mentioned above, the architectural choices are guided by system require-
ments. To get a clear understanding of what is required for a vehicular technology
application, we first taxonomize a representative range of applications (section .).
Following that, we describe each of the architectural choices in detail and how they
have been investigated in the contributions in part II.

. V T A

In this section, a range of vehicular technology applications are taxonomized ac-

cording to a set of criteria relevant for the design of the architecture and com-
munication protocols supporting such applications. e criterion for selecting the
applications is that they should involve multiple communicating vehicles. e ve-
hicles can communicate among themselves and/or with one or more servers on the
Internet. We do not consider vehicle-local systems such as adaptive headlights,
smart airbags, adaptive cruise control [], anti-lock braking systems, radar based
collision detection, etc. Each of the applications below should be seen as a repre-
sentative of a class of applications with similar properties.

Infotainment Infotainment systems provide information and/or entertainment to

the driver possibly depending on his current location and context. e driver could,
e.g., request information about nearby restaurants or tourist information. Google
maps [] is an example of a service providing location dependent information.

Neighborhood notification One example of a neighborhood notification system could

be a system for notifying a driver about gas prices in the area he is driving in. e
information provided should depend on the vehicles location, destination, and the
amount of gas left. Finally, the driver should be able to specify preferences with re-
spect to particular gas station chains. In [] such an application is described
along with a proposed architecture, implementation, and evaluation. While in
some ways similar to infotainment systems, neighborhood notification systems dis-
tinguish themselves by delivering more dynamic data concerning phenomena in the
general neighborhood of the driver. For example, gas prices usually change several
times over a day. Other applications with similar properties include systems for
notification about speed traps [] and available parking spots [].


 .. Vehicular Technology Applications

Context sensitive navigation Navigation systems have been in common use for sev-
eral years but only recently have information about the users context been used for
navigation. In several commercial systems [, ], the route calculated to the
destination is depending on the current traffic situation in the environment. In-
formation about the current traffic is usually obtained from the Traffic Message
Channel (TMC) [] over the FM band. Not only information about traffic con-
gestion or roadwork is useful but also the configuration of the vehicles. If, e.g.,
a vehicle is equipped with snow tires it can safely use routes that include slippery
sections.

Fleet management systems are typically used by a companies with large fleets of
vehicles to optimize logistics by, e.g., dispatching the nearest vehicle to a customer
or by distributing vehicles evenly over a region to minimize dispatch time. Ex-
amples including taxi companies [], package delivery services, law enforcement
authorities. Fleet management systems are typically also used to gather statistics
about the fleet operation for billing and productivity analysis.

Platooning A suggested solution to the problem of ever-increasing traffic den-

sity in cities is to let vehicles move together in a platoon with only a few meters
apart [, ]. When a vehicle brakes, the following vehicles automatically adjust
their velocities. It has been suggested that the capacity of roads can increased by
– by using this technique and that traffic safety can be improved because
data suggests that human error accounts for up to  of all accidents []. Fur-
thermore, significant fuels savings due to draught effects can be achieved - especially
for large vehicles [].

Collision detection applications [] try to avoid accidents by alerting the driver
before hazardous situations occur. Vehicles exchange data about velocity and direc-
tion and continuously try to predict dangerous situations. While similar to platoon-
ing, the focus of collision detection systems is to alert the driver but not necessarily
to control the vehicle. Collision detection systems based on inter vehicle commu-
nication have the advantage over vehicle-local systems (using radars, ultrasound,
etc.) that they can monitor traffic outside the range of sensors which can be neces-
sary to avoid pile-up accidents on highways. Some systems provide an audible alert
seconds before a crash while more advanced systems visualize the traffic ahead is a
display in the vehicle [].

Road state notification Collision detection systems communicate information about

vehicle location. In contrast, road state notification systems inform the driver about
properties of driving environment. It can be information about relatively static phe-
nomena such road work or potholes in the road [] but can also concern more
dynamic properties such as traffic congestion [] or whether the road is wet or
icy (see chapter ). Information about the state of the road can be used to increase


Chapter . Architecture in Vehicular Technology Applications

safety but can also be used for input to context sensitive navigation systems. In some
cases not only notifications about the occurrence of a phenomenon is of interest but
also notifications about the absence of the phenomenon. If, for example, a driver
has received no notification about ice on the road ahead, it can mean either that the
road is safe or that no vehicle with an ice sensor has traversed the area recently.

Automatic emergency notification One of the features of the OnStar system []
is to automatically alert the emergency centre when an accident occurs. When the
airbags are deployed, information about the vehicles location (using input from a
GPS device) and the force of the impact (using accelerometers) are sent to a call
centre which in turn tries to contact the vehicle and possibly dispatches emergency
vehicles. Other systems in the same category include remote door unlocking and
remote engine diagnostics.

.. Taxonomy

In table ., we have classified the applications with respect to a set of categories
of architectural importance that have been selected by looking at the variability of
the applications described in the previous section. Below we introduce each of the
categories and give examples for each of the possible values. In section ., we
describe how the categories affect architectural choices. Note that the values in
table . are independent of choice of architecture and protocols.

Relevance decrease Communication

Scenario/Application Criticality Penetration sensitivity Temporal Spatial Pattern Data exchanged
Infotainment Convenience Data sources Days/None 1 km + Sporadic
Neighborhood notification Convenience Data sources Hours 100 m Sporadic ~100 bytes
Context sensitive navigation Convenience Data sources Hours 100 m Sporadic ~1 KB
Fleet management Convenience Included vehicles Minutes km Periodic ~100 bytes
Platooning Safety of Life Included vehicles Milliseconds m Periodic ~100 bytes
Collision detection Safety of Life All vehicles Milliseconds 100 m Periodic ~100 bytes
Road state notification Safety Sensing vehicles Hours 100 m Periodic ~100 bytes
Automatic emergeny notification Safety of Life Single vehicle Seconds 100 m Sporadic ~100 bytes

Table .: Vehicle technology applications

Criticality A strong determinant for the design of architecture and protocols is the
consequence of a system failure. In some applications, such as, e.g., infotainment
or navigation systems, failure only amounts to inconvenience, whereas in road state
notification systems the safety of drivers can be at stake. Even worse, a failure in a
platooning system can be life threatening.

Penetration sensitivity Some applications are sensitive to user adoption in the sense
that they will only achieve optimal functionality when a large user base reached.
Until then, the application will be only partially functional. We classify the appli-
cations according to how many users will have to adopt the system before it is fully


 .. Vehicular Technology Applications

functional. For example, a gas price notification service is only useful if the major-
ity of gas stations provide price information for the system. Likewise, a collision
detection system base on inter-vehicle communication can only be trusted if the
majority of drivers have the system installed. For a fleet management system to be
functional, vehicles in the fleet have to have the system installed.
To some degree, the penetration sensitivity of a system will also depend on
the chosen architecture and protocols. An ad-hoc network supported system will
need more users than a system relying on an infrastructured network. In table .,
we only account for the penetration sensitivity inherent to the application. For
example, regardless of architecture and protocols, a platooning system requires that
all vehicles in the platoon have the system installed.

Spatial and temporal relevance decrease Inspired by Xu et al. [] we classify the
data communicated in vehicular applications according to the spatial and tempo-
ral properties of the object they describe. Xu et al. observed [] that for most
vehicular technology applications, the relevance of information about an object in
the environment decreases with the distance, in time and space, to the object. If,
e.g., a vehicle is located in Århus, the location of a gas station in Copenhagen is
less important than the location of a gas station in Århus. Similarly, the date for
the effectuation of a new traffic law is more important if it is tomorrow than if it
were forty years ago. To some degree this is dependent on the actual application,
but for the applications listed here, the observation holds.
For the applications mentioned here, there is a lot of variability in the how fast
the relevance decreases with time and distance to the origin of the data. Xu et al.
expresses this in a relevance function, which is a linear combination of the distance
in time and space to the object weighed by two parameters, α and β . In table .,
we only estimate the magnitude of how long it takes for data to go from maximum
relevance to negligible relevance. For example, the relevancy of a gas price at a
particular gas station decreases to almost nothing in hours - because most likely the
price will change in that time interval. Similarly, in a collision detection system,
information about other vehicles is uninteresting outside a range of a few hundred
meters.

Communication pattern e pattern of communication in an application details

when communication is done. Some applications, e.g. collision detection systems,
periodically send information to other parties in the system, whereas other applica-
tions only sporadically send information on the occurrence of events. For example,
in a gas price notification system, prices are only requested in the event of low fuel.
If the fuel tank is full there is no need to request information.
Since the temporal relevance decrease describes approximately how long it takes
for data to become irrelevant, the temporal relevance decrease figure is a good es-
timate for a required communication frequency for the applications that rely on
periodic communication.


Chapter . Architecture in Vehicular Technology Applications

Data exchanged Every time communication is performed in the network, an amount

of data is exchanged. For example, when a vehicle in a fleet management systems
updates its position on the server it does so by sending the server its GPS coordi-
nates along with auxiliary information. e exact amount of data exchanged de-
pends on the choice of data representation. e amounts listed in table . are
approximate upper bounds.

. A C

In the following, we describe in detail architectural choices with respect to network

architecture, middleware architecture, and business model interplay. Additionally,
we describe how they have been investigated in the contributions in part II. In fig-
ure ., a conceptual overview of architecture for vehicular technology applications
inspired by [] can be seen. Arrows in the figure denote influences. e network
architecture determines the structure of the network that is used for communication
in the system. e middleware architecture structures how the developer can access
the network when implementing the application logic. e business model influ-
ences the architect that designs the architecture and the network and middleware
architectures affect the choice of business model.

Architect(s)

Architecture
Architects's Influences
Application Layer
Business Model
...
Middleware Architecture

Network Architecture

System

Figure .: Conceptual Architecture Overview

.. Network Architecture

In vehicular technology applications, vehicles can communicate with each other by

using long range wireless communication such as, e.g., GPRS, by using a vehicular
ad-hoc network, or by using a combination of the two. e choice of network
architecture is important because it affects almost all aspects of the application.
Most likely, if a wrong decision is made, everything has to be reimplemented. In
the following, we describe the network architectures and in table ., we summarize


 .. Architectural Choices

their characteristics.
Long range infrastructure-based wireless communication, such as e.g. GPRS,
typically relies on a cellular infrastructure in which a geographic area is divided
into regions called cells [, chap. ]. In each cell, a transceiver, called a base-
station, is responsible for connecting the nodes (such as, e.g., handsets) in the cell
to the network. Since all nodes in a cell share the bandwidth of the communi-
cation medium, the scalability of a cellular system is limited. e larger the cells
are, the more nodes will be in range and the lower the bandwidth will be. e
base-stations typically communicate with other base-stations and network services
by using wired technology. When a node, A, communicates with another node, B,
inside the network, the information exchanged has to travel first to the base-station
in A s cell, then to a server, then to the base-station in Bs cell, and then finally to B.
e physical distance traveled can be hundreds of kilometers and since the signal
is limited by the speed of light, high latency can occur. A cell network is admin-
istered by a network operator that controls who have access to its services which
usually involves some kind of paid subscription. e coverage of cell networks is
usually good. Currently, Global System for Mobile Communications (GSM) is
usable in most of Europe []. e complexity of implementing a vehicular tech-
nology application using infrastructure-based communication is low because the
communication form resembles traditional TCP/IP style communication. An ex-
ample of use of infrastructure-based communication in a vehicular setting is the
OnStar system [] mentioned in the introduction.
In vehicular ad-hoc networks, there is no static infrastructure. Instead, vehicles
communicate directly using short range radio. For communication with nodes out-
side transmission, range intermediate nodes act as routers and forwards messages.
Since the transmission range of the signals is short, typically only a few nodes have
to compete for the available capacity and therefore bandwidth can be high. e
physical distance traveled by messages is typically short which means that the la-
tency can be very low. Since no infrastructure has to be maintained, communication
in VANETs can in principle be free, however there is only network coverage when
other nodes are close by. VANET protocols are often very complex compared with
traditional TCP/IP communication because the protocols have to cope with a very
dynamic environment. In chapter  the different types of VANET protocols are
described in detail. While only a few commercial systems [] use VANETs for
communication, a lot of research has been done in the area [].
Finally, for some applications it can be necessary to choose a hybrid solution
where both cellular networks and VANETs are used [, , ]. For example,
if it is decided that a VANET should be used, there can be a bootstrapping prob-
lem. Early on, there will only be a few nodes and therefore very poor coverage.
Coverage will only increase with the number of users, but the number of users will
only increase if the coverage is suitable. erefore, it can be necessary to include
infrastructure-based communication to bootstrap the process. In table . we sum-
marize the characteristics of the two forms of wireless communication.
Looking at the taxonomy presented in section .., all of the categories are


Chapter . Architecture in Vehicular Technology Applications

Bandwidth Latency Cost Coverage Complexity

Cellular networks Low High Subscription Good Low
Vehicular ad-hoc networks High Low None Limited High

Table .: Network architecture characteristics

relevant for the choice of network architecture except the penetration sensitivity.
Although the penetration sensitivity is affected by which network architecture is
chosen, the opposite is not the case. If a disconnection in the application amounts to
a failure, the criticality of the application determines the requirement for coverage.
If the consequence of a disconnection is loss of safety or loss of life, an infrastructure
based or a hybrid network should be used since they provide the best coverage.
Temporal and spatial relevance decrease determine the latency requirement of the
application. If data become irrelevant after a short period of time, the latency has
to be low. Similarly, if the data become irrelevant outside a small range of the
origin of the data, latency should be low because it can be expected that vehicles
will move outside the range quickly. e communication pattern and the amount
of data exchanged together with temporal and spatial relevance decrease determine
the bandwidth requirement. If the pattern is periodic and the temporal and/or
spatial relevance decrease are low, the bandwidth requirement is high. Similarly, if
data is only exchanged sporadically and the temporal and spatial relevance decrease
are high, there is only a low requirement on bandwidth.

Contributions In chapter , the paper An Infrastructure for a Traffic Warning System

analyses the LIWAS application described in section . and identifies functional
and architectural requirements. e functional requirements amounts to collecting
measurements from the sensor, converting sensor values into road classifications,
and disseminating classification to other nodes in the system. Since measurements
arrive at a rate of  times per second and consist of data about temperature, hu-
midity, dew point, light reflection, etc. there is a significant load on the system.
e classifications have to be delivered to nearby vehicles and to a backend server.
From an architectural perspective, the system should be scalable, modifiable, and
available. e vision behind the system is that, over time, it should be installed in
the majority of vehicles and therefore it is crucial that the network infrastructure
scales from a few vehicles to thousands of vehicles. Since the system enhances the
safety of drivers, the availability of the system should be high - even when there are
only a few units in operation. Finally, we observed that for a distributed system of
this magnitude it is important to be able to modify the system after deployment.
e requirements led to the design of an architecture for the system that uses
a hybrid network architecture. e rationale behind this decision is that with the
amount of data to be distributed, using only infrastructure-based communication is
infeasible. Conversely, a requirement for making the system work with only a few
nodes requires that a VANET cannot be used alone. To make the infrastructure-


 .. Architectural Choices

based communication cope with the amount of data, a policy for when to dissemi-
nate messages was developed.
e architecture was evaluated by experimenting with three prototypes, each
realizing key aspects of the architecture. e first prototype investigated the fea-
sibility of transmitting the required amount of data from vehicle to vehicle using
wireless LAN. e second prototype implemented classification, communication,
and maintenance on top of a embedded virtual machine running SmallTalk byte
code. To ensure that the platform provided suitable performance, the communica-
tion experiments were repeated. A protocol for distributing software updates in the
VANET was developed and evaluated. e first two prototypes only experimented
with vehicle to vehicle communication, but the third prototype also included an
SMS connection for uploading classifications to a back end server.

.. Middleware Architecture

In vehicular technology applications, multiple communication protocols are often

used simultaneously. Sensors and actuators are typically connected via a serial con-
nection such as e.g. CAN-bus [], RS-, Universal Serial Bus (USB), or the
Bluetooth serial profile []. Vehicles can be connected to servers through the
GSM network by using GPRS or SMS, or by using other long range wireless net-
working technologies such as WiMAX, UMTS, or CDMA. Unidirectional con-
nections from servers to vehicles are possible via TMC. Vehicles are connected
to each other using VANET protocols, which come in a wide range of flavors
(cf. chapter ). Some VANET protocols can be used for general purposes (e.g.
AODV [], DSR [], and OLSR []), but in some cases it is necessary to use
protocols optimized for specific applications (e.g. [, , ]).
As a consequence of the wide range of protocols, it is important that the mid-
dleware architecture makes the protocol functionality available to the developer in a
consistent and understandable manner, and that the protocol suite is easy to main-
tain. Here, we consider middleware to be the software that act as a bridge between
the operating system and applications to hide the complexity of network and dis-
tributed systems programming to the programmer.
Understandability can be achieved by using clean middleware abstractions that
hide complexity when possible and expose it when needed. It is not merely a ques-
tion of designing a suitable API because the selected abstractions should reflect how
things work instead of just presenting an interface. Otherwise, the consequence can
be that abstractions break down when faults occur.
If, for example, the middleware offers a socket to the programmer for commu-
nication in a wireless ad-hoc network, it can be problematic if some of the links,
due to interference or differences in transmission power, are asymmetrical. is
can cause the underlying protocol not work as expected or maybe even not at all.
Here, a better fit would be an abstraction that better matches the properties of the
network.
With respect to maintainability, connections to sensors and servers can use tra-


Chapter . Architecture in Vehicular Technology Applications

ditional layered middleware architectures, but protocols for inter-vehicle commu-

nication should not use a strictly layered architecture for at least two reasons. First,
inter-vehicular communication protocols are often position based (cf. chapter )
implying that they use location information for routing. Hereby, the network layer
(cf. the ISO/OSI model []) has to have access to information not available from
its surrounding layers and thus have to break the layering principle. Secondly, when
aggregation is used in dissemination of data, application level information is used
for routing information. In [], it is suggested to a staircase approach in which all
protocol layers can interact via a publish/subscribe based Information Connector.
In connection with the taxonomy in table ., one factor influencing the mid-
dleware architecture is criticality. If the criticality of the application is high, it is
important that the system can be maintained without first shutting it down. An-
other factor is the communication pattern and the amount of data exchanged. For
applications where large amounts of data are exchanged, it is important that the
performance of the middleware is suitable.
One of the lessons learned in implementing the three prototypes (cf. chapter )
was that for the simultaneous operation of the various protocols, another protocol
architecture was needed. Since information about the road should be disseminated
though multiple communication media, it might be a good idea to decouple the
part of the system producing data and the parts of the system consuming data.

Contributions In the paper A Uniform Publish-Subscribe Infrastructure for Com-

munication in Wireless Mobile Environments in chapter , decoupling is achieved by
separating the system into loosely coupled components that communicate using a
set of publish-subscribe [] based busses that are linked via gateway components.
Each bus encapsulates a communication scope. For example, in LIWAS, there
would be three busses: a bus for local host communication, a bus for WiFi commu-
nication, and a bus for GPRS communication. e gateway components linking
the busses are controlled by publishing gateway commands that specify which mes-
sages should be relayed and in what direction. All inter-component communication
is handled uniformly regardless of whether components reside on the same host or
not. Hereby, it is transparent for a sensor component whether the information it
produces is used locally or on a remote host or both. In the paper, we demon-
strate how a fleet management system can be implemented using the architecture
without deploying code on the vehicles. e architecture was used in a set of pro-
totype deployments in Aarhus Airport and at Abildskou rutebiler - a local coach
company. e protocols described in chapter  can be simultaneously deployed by
implementing them in separate components.
While the applications described all reside in the vehicular domain, the archi-
tecture can also be used in other domains. e basic communication abstraction
provided, sending messages, can be used as a building block in more complex pro-
tocols. However, the gateways and busses have currently no support for prioritiza-
tion of messages, which makes the infrastructure unsuitable for applications with


 .. Architectural Choices

hard realtime requirements such as platooning and collision avoidance systems.

Understandability is supported by using the same communication mechanism
consistently throughout the system. When the busses have been implemented, the
developer can express protocols in terms of publishing and subscribing.
A challenge in developing VANET protocols is that testing and evaluating pro-
tocols in real life is very expensive and time consuming. An alternative is to use a
network simulator such as e.g. NS- []. However, the use of simulation has
some drawbacks. First of all, it is hard to simulate the physical properties of the
communication medium and the OS protocol stack. Secondly, the protocols typi-
cally have to be developed specifically to the simulation framework. is means that
the implementation evaluated will be another than the one deployed. e publish-
subscribe infrastructure can be used to help alleviate the second problem. If a bus
is developed for the network simulator, a real protocol implementation can interact
with a simulated network and thus the confidence in the conformance between the
simulator implementation and the real implementations can be enhanced.
Maintainability is supported mainly in the decoupling provided by separating
the system into components and letting them communicate via publish-subscribe.
Each component is deployed as a separate binary library and can be added an re-
moved at runtime without the system has to be restarted. Hereby, the deployment
of software updates does not necessarily affect system availability. e loose cou-
pling also means that changes to the system in many cases can be isolated to spe-
cific components which increases maintainability. Since all communication goes
through a bus it is easy to monitor the communication among the components in
the running system to locate errors quickly.
Before a component can publish events with a particular topic, it first has to
notify the bus by advertising the topic. Similarly, a component has to ask the bus
to subscribe to a topic before any messages are received. Hereby publishing and
subscribing are explicit actions and this makes it possible to deduce communica-
tion dependencies among components at runtime by inspecting advertising and
subscription actions. is can be used to predict which components that will po-
tentially malfunction if a particular component is stopped.

.. Business Model Implications

In this context, we use the term business model to denote a model for conduct-
ing business. Chesbrough and Rosenbloom [] define the functions of a business
model to be to identify and articulate value proposition, market segment, value chain,
cost structure, profit potential, value network, and competitive strategy. Here, we pri-
marily look at value proposition and value network.
e value proposition is the value created for the user by the application. It can,
e.g, be in the form of cost reductions or in the form of new possibilities and solu-
tions. An example could be the cost reduction due to optimized vehicle routing in a
fleet management solution, or the increased safety for a user of a collision warning
system. e value network consists of the company behind the application, suppli-


Chapter . Architecture in Vehicular Technology Applications

ers, customers, and third parties, and describes how value flows in the application
domain. For some applications, the value proposition for customers increase when
considered as part of a value network as opposed to viewing it in isolation. For
example, a significant part of the value provided by a phone network operator to a
user originates from the users ability to contact customers of competing operators.
For some vehicular applications, there is an intricate interplay between the busi-
ness model of the application and the software architecture. A chosen architecture
can place limitations on the choice of business model and a selected business model
can have implications on the design of the architecture (see figure .).
If only infrastructure-based communication is used, there are only few con-
straints on the business model. However, when a VANET is used, there can be
several problems that stem from the fact that the VANET will only function op-
timally with a significant user base. e first problem to overcome is the boot-
strapping problem mentioned in section ... Initially, the value proposition of
the application to the vehicle owner is limited because the system is not yet fully
functional. is implies that there has to be some extra motivational factor if the
vehicle owner is to buy the system. Secondly, there is a risk of fragmentation in
the sense that, as competing companies introduce new applications, no single ap-
plication will reach the critical mass of users reachequired for optimal functionality.
erefore, it is essential that the role played by the application in the value network
is so that there is a value proposition even if the application does not dominate the
market. It should be noted that if all vehicles are controlled by the same organi-
zation, such as e.g. fleet management and platooning systems, bootstrapping and
fragmentation are not necessarily problematic because the organization can simply
install the system in the required amount of vehicles.
If the chosen business model assumes that the company providing the appli-
cation has complete control over the system, it might not be a good idea to use a
solution based solely on VANET communication because the vehicles may be un-
reachable from the Internet most of the time. is makes it complicated to control
access to the system and monitor usage for billing purposes.
With respect to the taxonomy presented in table ., the business model is
highly dependent on the penetration sensitivity. If the sensitivity is high, it is crucial
that market dominance can be achieved or that competing companies can partake
in the application to provide the required penetration ratio.

Contributions In chapter  the paper Service Oriented Architecture for Inter-vehicle

Applications presents a business model for the provision of information about the
environment to drivers. Four categories of players in a value network with associ-
ated value propositions are identified. e four categories are: Sensor manufacturers
that manufacture and sell hardware and software for sensing information about the
environment. Data providers use the sensor hardware and software to gather data
that is sold to presentation providers. Presentation providers sell software for pre-
senting the data to drivers and subscriptions for getting access to the data. Data


 .. Architectural Choices

consumers subscribe to information from the presentation providers that enhance

comfort and security.
Bootstrapping in the business model is handled by letting both drivers and in-
dependent parties provide data for the system using both infrastructure based and
VANET communication. Besides having access to information about the environ-
ment, the data providers are also motivated by selling access to the information to
the presentation providers - that in turn resells the information to data consumers.
To avoid fragmentation of the market, we suggest that the exchange of infor-
mation in the network should be based on standards. Since the business model is
not based on a single company trying to dominate the market, individual players are
motivated to expand the network. e players agree by contract to relay information
from other players.


C Ո 

D D  V  V N

In the previous chapter, we gave a range of examples of vehicular technology ap-

plications with varying requirements for communication. We discussed different
designs of network and middleware architecture. In this chapter we look into dif-
ferent types of protocols for realizing communication.
A first consideration is what type of communication is needed for a given ap-
plication. Some applications require point-to-point communication whereas geo-
graphic broadcast is necessary in other applications. In section ., we describe the
different delivery models relevant for vehicular technology applications. For each
of these models, we motivate their use in vehicular technology applications and give
examples of implementing protocols.
In designing a protocol for a vehicular environment, it is important to be able
to evaluate the protocol. is can however be difficult because it is a costly and
slow process to set up a real network consisting of vehicles driving in a realistic
environment. Alternately, emulation or simulation can be used. In section ., we
described different methods and metrics for evaluation of protocols for vehicular
environments.
Finally, in section ., we describe our contributions with respect to data dis-
semination in vehicular networks.

. D M

For the range of applications described in section ., the requirements for commu-
nication vary. Not only in terms of quality parameters such as bandwidth, latency,
coverage, etc., but also in the basic mode of operation. Some applications only
require traditional point to point communication, while others require group com-
munication. In this section we will describe five basic delivery models. e four of
them, unicast, multicast, geocast, and publish-subscribe, are traditional in that they
deliver a message from a sender to a set of receivers. In the last delivery model, data-
centric delivery, there is no explicit receiver and the information communicated can
be modified over time.
In figure ., an overview of the delivery models can be seen. e interpretation
of the relative vertical alignment of the delivery models in the figure is that a model,


Chapter . Data Dissemination in Vehicle to Vehicle Networks

A, is above a model, B , if A is a more general delivery model than B . For example,

the multicast model can be considered more general than the unicast model because,
in the multicast model, messages are delivered to a set of nodes (instead of just a
single node). In the following, we describe each of the delivery models and give
examples of implementing protocols.

Content-based publish-subscribe

Data-centric delivery
Topic-based
publish-subscribe
Generality

Multicast Geocast

Unicast

Figure .: Delivery Models

.. Unicast

Unicast is the most basic delivery model in which a message is sent from a sender
and delivered to a single receiver. is communication form is used widely in the
Internet and other places and is generic in the sense that a protocol implement-
ing unicast can be used to implement other protocols that provide more advanced
features such as reliability, congestion control, stream abstractions, etc.
For vehicular applications, unicast protocols are useful when there is only a sin-
gle receiver of a message and the identity of the receiver is known. is is, for
example, the case in a fleet management system where the addresses of the partic-
ipating vehicles and the server are all known. If no explicit address of the receiver
is known, a name service, such as e.g. Domain Name System (DNS) [], has to
be available.
To realize a unicast protocol in a vehicular ad-hoc network, all vehicles have
to act as routers and forward messages hop by hop. Routes in the network are
volatile because vehicles constantly move in and out of range of each other, and
therefore the strategy for finding and maintaining routes is important. Some pro-
tocols proactively find routes to other nodes before communication is initiated (e.g.,
Destination-Sequenced Distance-Vector routing DSDV [] and Optimized Link


 .. Delivery Models

State routing OLSR []) while others reactively find them when needed (e.g.,
Ad hoc On-Demand Distance Vector routing AODV [] and Dynamic Source
Routing DSR []). Finally, some protocols use geographic information to route
messages (Greedy Perimeter Stateless Routing GPSR []). A prerequisite for this
is that vehicles can determine their own position and that the location of the receiver
of a message can be determined by querying a location service.
In infrastructure-based networks, routes are easier to maintain because the in-
frastructure is static and thus it is easier to provide unicast protocols.

.. Multicast

In the multicast delivery model, a message is sent to a set of receivers instead of just
a single receiver. Since the set containing a single node is also a set, the multicast
delivery model can be seen as a generalization of the unicast delivery model. Broad-
cast can be considered a special case of multicast in which messages are delivered
to the set of all nodes. Typically, the set of receivers are specified by means of a
multicast group address. is is the case in the Internet where a subset of the ad-
dress space is reserved for multicast addresses. Here, nodes can state their interest
in receiving messages sent to the group by joining the group by using the Inter-
net Group Management Protocol (IGMP) [] for IPv or the Internet Control
Message Protocol (ICMP) for IPv [].
In vehicular applications, multicast protocols can, e.g., be used to find routes in
unicast protocols (e.g. AODV []) and to implement a service discovery service.
Another use could be to dispatch emergency information to other vehicles in a road
state notification system.
A simple way of realizing a multicast protocol in a VANET is first to implement
a broadcasting protocol and then let nodes ignore messages to addresses they have
no interest in.
One way to implement a broadcasting protocol is to use a technique known
as flooding. In flooding, a node initializes a broadcast by sending out a message
to all of its one hop neighbors. ese nodes, in turn, forward the message to all
of their neighbors and eventually all nodes in the network will receive the message.
Flooding has the disadvantage that it potentially generates a lot of redundant traffic.
In [], Ni et al. present several techniques to resolve this problem ranging from
using back-off schemes based on counters, distance, location, and clusters, to using
probabilistic forwarding.
Broadcasting can also be implemented by using epidemic protocols []. Epi-
demic protocols emulate the spread of an infectious disease in a population. Every
time a node receives a packet, it makes a probabilistic decision about which neigh-
bors the node should forward the packet to. Epidemic protocols are, like the spread
of diseases, robust to poor network conditions.
An alternative to using broadcast is to form a multicast distribution tree [,
pp. ]. is approach is well suited for infrastructure-based networks, but less
suited for VANETs because if a link breaks, the tree has to be reformed. e mul-


Chapter . Data Dissemination in Vehicle to Vehicle Networks

ticast tree can be made more robust by adding redundant links and thus converting
it to a mesh [].

.. Geocast

In the geocast delivery model, messages can be sent to a location and whoever is
present at that location will receive the message. A location can be either a specific
point or an area. As mentioned in section .., if a location service is available,
a geocasting protocol can be used to implement the unicast delivery model by first
looking up the location of the destination node and then geocasting to that location.
A geocasting protocol can, for example, be used to disseminate information
about the state of the road at a particular location to the vehicles approaching that
location. It can be sent either from nodes inside the destination region, but also
from remote locations, e.g. a server.
e realization of a geocasting protocol for a VANET can be divided into two
steps. First, the message has to reach a node inside the destination area, and sec-
ond, the message has to be distributed to all other nodes in the destination area.
If a location service is a available that maps a location to a node identifier, a uni-
cast protocol can be used to reach the destination area. Otherwise, a geographic
routing protocol, such as e.g. GPSR [], can be used. Once inside the destination
area a localized flooding protocol, where messages are only forwarded inside the
destination area, can be used [].
To provide geocasting in an infrastructure-based network, a location service is
needed to provide information about the location of base stations, cell towers, etc.
is information can be used to reach the base-station closest to the destination
area and from here the message can be broadcasted directly to the receivers in if
the transmission range is sufficient or flooding can be used as above. e location
service can easily be maintained because the infrastructure is static.

.. Publish-Subscribe

In the publish-subscribe delivery model [], nodes can express interest in messages
by subscribing to them. When a message matching the subscription is published,
the subscribing node(s) will receive it. Here we consider two kinds of publish-
subscribe: topic-based and content-based . In topic-based publish-subscribe, top-
ics are semantic labels that are attached to messages when they are published. Mes-
sages are delivered to all nodes subscribing to the topic. In some variants, topics
are arranged in a hierarchy, so that a subscription to a topic is automatically also a
subscription to all sub-topics.
In content-based publish-subscribe, nodes subscribe by providing a message
predicate. For example, the predicate:

¹In [], a third kind, type-based publish-subscribe, is also described, but in this context we
consider it a special case of content-based publish-subscribe.


 .. Delivery Models

resource = 'gas' & price < 12.0 & provider = 'Shell'

matches all messages where the resource field is gas, the price is less than twelve,
and the provider is Shell. When a message is published, it is evaluated against all
predicates and delivered to the nodes with matching predicates. Since a subscrip-
tion to a topic can be seen as a predicate, topic-based publish-subscribe can be seen
as a special case of content-based publish-subscribe.
Expressing the subscription in a predicate allows the subscriber to tailor the
subscription precisely to his needs and hereby potentially save resources. Topic-
based publish-subscribe has the benefit that the node(s) handling the distribution
of messages do not have to be able to interpret the contents of messages as long as
the topic can be read.
One example of applicability in vehicular applications is the gas price notifica-
tion system described in section .. Using content-based publish-subscribe, the
driver could subscribe to gas prices below a certain threshold at gas stations along
the route to his destination. e predicate would contain the threshold and a spec-
ification of a region close to the route.
A simple way to implement a publish-subscribe system on top of a infrastructure-
based network is to let a server manage subscriptions, publications, and event dis-
semination. When a node subscribes, it notifies a server that stores subscription
information for all nodes in the system. When a message is published, it is sent to
the server that determines who the message should be delivered to. e scalability
of this centralized implementation is, however, limited because the server has to
communicate directly with each of the subscribers for any given message. One op-
timization option for topic-based publish-subscribe is to create a multicast group
for each topic by using the techniques described in section ...
In a content-based publish-subscribe system, a subscription forwarding scheme []
can be used. First, the network graph is overlaid with a spanning tree. en, when
a node subscribes by giving a predicate, the predicate is stored in all nodes on the
path to the root of the tree. When a message is published, it is first forwarded to
the root, and from there to the subtrees with matching predicates.
In a VANET, it is not feasible to use a centralized solution because it cannot
be assumed that vehicles are connected to the server at all times. Nor is a tree-
based solution optimal because the tree has to be reformed every time a link breaks.
In [], Leontiadis and Mascolo present a decentralized alternative. e solution
exploits the mobility pattern of vehicles and the observation that roads leading to
the location a message concerns will most likely contain vehicles interested in the
message. When a message is published, a number of replicas are created and dis-
tributed to a set of carrier vehicles, which are responsible for relaying the message
to interested vehicles. e main idea of the contribution lies in the selection of car-
riers. e carriers are selected so that there is a carrier on each road leading to the
location the message is about. Furthermore, the carriers are as far as possible from
the location, within a maximum radius. Simulations show that after approximately
five minutes, almost  of the subscribing vehicles within a  km radius receive


Chapter . Data Dissemination in Vehicle to Vehicle Networks

a published message.
In [], Costa and Picco use a combination of subscription forwarding and
probabilistic techniques for realizing a content-based publish-subscribe system for
mobile ad-hoc networks. When a node subscribes by giving a predicate, the sub-
scription is forwarded to all other nodes within a limited radius ϕ. When a message
is published, it is propagated by using the subscription information stored and by
selecting random neighbors. Every time a published message is received by a node,
the message is forwarded to a percentage, τ , of its neighbors. e neighbors to
forward to are selected by primarily looking at the stored subscription information
and secondly, if the τ ratio has not been reached, by selecting random neighbors.
Loops are avoided by using sequence numbers as in AODV [].

.. Delivery Model Addressing

Common to the first four delivery models is that, from an abstract point of view,
they all use addressing for determining who should receive a message. e form of
addressing distinguishes the delivery models and can therefore be used to classify
them. In table ., we divide addressing along two axes.

Identifier Location Topic Predicate

Point Unicast Geocast Topic-based pub-sub N/A
Set Multicast Geocast Hierarchical Topic-based pub-sub Content-based pub-sub

Table .: Addressing

e first axis concerns the nature of what is being addressed. An identifier is

simply a name for the entity that should receive a message. If the address is a
location, entities present at the location should receive the message. If the address
is a topic, the message should be delivered to whoever have expressed interest in
that topic. And, finally, for content-based publish-subscribe it can be said that
messages are implicitly addressed to the predicates over them that evaluates to true.
e second axis denotes the multiplicity of what is being addressed. A point is a
single value and a set is a collection of values in the domain of addresses.
Models where addresses are sets are more general than models addressing points,
and this is also reflected in figure .. Note that in content-based publish-subscribe,
it makes no sense to address a single predicate because there exists no message for
which only a single true predicate exists.

.. Data-centric Delivery

For some applications, it is not possible to honor the communication requirements

by only using general purpose protocols. Sometimes, it is necessary to specialize the
communication protocols to a specific application and exploit characteristics of the
data to optimize performance. In the data-centric delivery model, focus is not on


 .. Protocol Evaluation

providing generic end-to-end delivery of messages as in the previous node-centric

models, but rather on disseminating data among a set of hosts in the most efficient
manner relative to the specific application requirements.
Data-centric protocols are often used to disseminate information about phe-
nomena in a geographic area. Since often the relevance of data about a phenomenon
decreases with the distance to the phenomenon (cf. section ..), dissemination
can be optimized by aggregating data about remote areas.
In [], Nadeem et al. describes the TrafficView system where in-vehicle dis-
plays present drivers with a view of the traffic in front of the vehicle. In each vehicle,
information about other vehicles is stored in records. e records are broadcasted
periodically to other vehicles. To optimize performance, multiple records can be
aggregated into a single record containing average values. e paper presents two
algorithms for choosing which records to aggregate.

. P E

In developing protocols for vehicular technology applications, it is crucial that de-

signers and developers can evaluate design decisions. If communication is based
on infrastructure-based networks, it is relatively simple to run tests and measure
performance because the infrastructure is static. In VANETs, however, it can be
costly and time consuming to conduct experiments with hundreds of thousands of
vehicles moving around. An alternative is to use analytic methods or to simulate
parts of the system. In section .., we describe different methods for evaluation
of VANET protocols. Orthogonal to the method of evaluation is the choice of
metric. A wide range of performance parameters can be of interest ranging from
general purpose metrics such as throughput, latency, and medium utilization, to
application specific metrics such as awareness percentage and warning distance. In
section .., we discuss the choice of metric. Finally, in section .., we present
an overview of the different types of methods and metrics.

.. Method

In this section, we describe four types of evaluation. Real life experiments, experi-
ments with emulation, simulation, and analytical methods. e methods differ in
the amount of resources required to perform them, and the confidence in the results
obtained. Although we describe the methods in separation, they are often used in
conjunction. We round the section off with a discussion about mobility models.

Real life experiments e problem with evaluation of VANET protocols is that the
most realistic results are very expensive to obtain in terms of time and money. For
complete confidence in the evaluation results, one would have to orchestrate hun-
dreds or thousands of vehicles to move around in a realistic pattern. Furthermore,
if the protocol is changed in any way, the experiments have to be repeated to deter-


Chapter . Data Dissemination in Vehicle to Vehicle Networks

mine the effect of the change. In most situations, this kind of full scale evaluation
is simply infeasible.
An alternative is to setup a simplified scenario and only evaluate a subset of
the system. is could for example be done by limiting the number of nodes as
in [] where the DSR [] unicast routing protocol is evaluated in a network
consisting of five vehicles and two stationary nodes. e mobility of the nodes is
controlled manually, guided by differential GPS receivers. Another example is the
MiNT-m testbed [] for mobile ad-hoc networks where a set of mobile robots can
be programmed to move around in a predetermined pattern. Although this method
of evaluation is resource consuming, the results obtained have a high likelihood of
being in correspondence with reality.

Emulation e goal of emulation is to construct a piece of software that behaves

exactly as what is being emulated. Often a physical entity is emulated, giving the
benefits of working with software instead of hardware. For evaluation of VANET
protocols it can be useful to emulate at least two parts of the system: the mobility
of the nodes and the hardware platform.
In the ORBIT testbed [],  nodes are laid out in a  by  grid. e nodes
are all connected through ethernet and each have a WLAN interface. Mobility is
emulated by means of virtual nodes that migrate from hardware node to hardware
node. is form of virtual mobility has the benefit that the rest of the system is very
close to the real system. For example, the physical aspects of the wireless interface
are preserved.
By emulating the hardware platform, it is possible to run multiple network
nodes on a single computer. is greatly reduces the work of installing software, re-
placing batteries, checking hardware, etc. Another motivation for emulating hard-
ware is that the software evaluated is the same as the software that will be deployed.
In TOSSIM [], applications built on top of the TinyOS operating system can
be simulated with a high level of detail. TinyOS is a operating system for sensor
networks where each hardware resource is encapsulated in a fine grained compo-
nent. In TOSSIM most of these components, e.g. Analog-to-Digital converters,
the clock, the EEPROM, etc., are emulated. e only exception is the radio hard-
ware, which is not emulated to increase the scalability of the simulator. Hereby,
thousands of nodes can be emulated on s single PC.

Simulation While emulation provides reliable results and can evaluate protocols
in large networks, it can be an unattractive solution in some situations. First of all,
an emulator might not always be available for the type of network or platform a
protocol is being developed for and it is a very complex task to implement a good
emulator. Secondly, running large experiments on an emulated platform can be very
time consuming due to the amount of details that has to be simulated in software.
is is not necessarily a problem for the final evaluation of a protocol, but during
development it prohibits iterative incremental protocol development.


 .. Protocol Evaluation

An alternative is to make a simplified model of some parts of the system. For

example, it can be useful to make a graph abstraction of the network. Instead of
simulating physical radio propagation effects, the network can be modeled as a
graph where nodes are either connected or not connected. is makes it impossible
to estimate factors such as e.g. packet collision, but it is still possible to evaluate the
functionality of algorithms. In the Sinalgo simulation framework [], routing
protocols can be developed in Java and simulated with thousands of nodes. In-
stead of implementing the full network stack, Sinalgo provides the developer with
a message passing view of the network and focuses on fast prototype development.
e widely used network simulator NS- [] provides a more detailed im-
plementation of the network stack and allows for simulation of a wide array of
protocols ranging from satellite networks to mobile ad-hoc networks.

Analytical methods In the earliest phases of protocol development, it can be useful

to rely on analytical methods for determining protocol properties. Formal argu-
ments typically require an abstract view of the network which can introduce uncer-
tainties. On the other hand, results obtained by formal methods will not depend
on any particular implementation and is thus not susceptible to bugs in protocol
or simulation code. Furthermore, formal methods can be used to prove properties
about protocols while experimentation can only observe them.
For example, in [] different techniques for limiting the amount of redun-
dant transmissions in a flooding protocol are evaluated. e authors analyze the
schemes by looking at the geographic area each node’s transmission covers and how
much these areas overlap. e arguments are based on a simplified model of radio
transmission: if a node a transmits a message then a node b will receive it if, and
only if, the distance from a to b is less than the transmission range. is implies
that the area covered area by a’s transmission is a disc with a radius equal to the
transmission range. In reality, the shape of the area depends on the radio hard-
ware, and there is not an exact boundary for when the message will be received and
when it will not be received.

Mobility models If mobility is simulated in the evaluation of a VANET protocol, it

is important to consider the choice of mobility model that will determine how vehi-
cles move throughout the evaluation. It has been shown that evaluation results can
be highly dependent on the chosen mobility model []. Traditionally, mobile ad-
hoc network protocols have been evaluated using simplified mobility models such
random direction and random waypoint []. However, a defining characteristic of
vehicular environments is the particular kind of constrained mobility and therefore
more accurate models are needed for the evaluation of VANET protocols.
e optimal solution would be to use traces of real traffic situations, but unfor-
tunately, no such traces for large scale networks are currently available. A common
approach is to let a traffic simulator generate vehicle movement and feed the re-
sult into the network simulator. Traffic simulators can be divided into macroscopic


Chapter . Data Dissemination in Vehicle to Vehicle Networks

and microscopic simulators. Macroscopic simulators consider aggregate proper-

ties of the traffic such as traffic density and flow, whereas microscopic simulators
model each vehicle in separation taking into account the vehicles destination and
the movement of nearby vehicles. For example, in [], a microscopic traffic sim-
ulator was used to generate a mobility trace for a road map of part of Switzerland.
e AODV [] and GPSR [] routing protocols were evaluated using the trace
and a random way-point mobility model and significant differences were observed.
For some types of protocols, it is not enough to generate movement traces be-
fore evaluation. If, e.g., a protocol for a collision warning system is evaluated, it is
possible that the communication in the network will affect the mobility of vehicles.
If a driver receives a collision warning, it is reasonable to assume that he will hit
the brakes causing vehicles driving behind him to brake as well. In [] this is
addressed by integrating the traffic simulator with the network simulator providing
two-way interaction at runtime.

.. Metrics

Here we divide metrics into general purpose metrics that apply to a wide range
of protocols and application specific metrics that measure properties relevant to a
particular application or a family of applications.
When developing general purpose protocols, such e.g. unicast or multicast pro-
tocols, it is relevant to evaluate them using general purpose metrics such as through-
put, latency, and medium utilization. is illuminates important properties of the
protocols and enables easy comparison with other protocols implementing the same
delivery model. It can, however, be harder to estimate how well a particular proto-
col is suited for a concrete application.
When the suitability of a protocol is evaluated for a particular application, it is
relevant to look at application specific metrics. For example, for a collision warning
system, an important parameter is how long in advance the driver gets notified
about a potential collision. e results obtained using application specific metrics
show, with a high degree of confidence, how suited a protocol is for at particular
application, but provides no insight to how other protocols would perform for that
particular application or how usable the protocol would be for other applications.
For data-centric protocols, it is often necessary to use application specific met-
rics because the protocol is application specific.

.. Evaluation Classification

In table . an overview of the methods and metrics for evaluation of VANET pro-
tocols can be seen. Each entry in the table corresponds to a approach to protocol
evaluation. Methods are ordered according to the amount of resources required to
perform them and according how realistic the evaluation is. e metrics are ordered
according to general applicability of the results and to the closeness to a concrete
application. Consider for example, the lower right corner: analytical methods us-


 .. Contributions

ing general purpose metrics. is type of evaluation requires few resources, but
has low realism because it relies on a simplified model. e results are of general
applicability, but are relatively far from a concrete application.

Method Real life Analytical

Emulation Simulation
Metric experiments methods

Application
specific

General
purpose

Table .: Methods and Metrics

Protocols should be evaluated using multiple types of evaluation because each

type has its strengths and weaknesses. Early on in the development process when
the design space is open, it is important with many iterations and therefore the
evaluation method should not require a lot of resources. But as the design gets
more detailed, more realistic evaluation is required.
e selection of metrics depends to some degree on the purpose of developing
the protocol. For business oriented protocol development, it is important to reach
the upper left corner in table . at some stage because the successful operation
of the application is crucial for financial success. For basic research, it is more
important that the results have general applicability. An exception is the data-
centric protocols for which application specific metrics should be used.

. C

In chapter , the paper Two Zone Dissemination Protocols for Vehicular Ad-hoc Networks
presents a comparative simulation study of two protocols for dissemination of data
in a traffic warning system. In the traffic warning system, each vehicle continuously
senses the condition of the road at its current location and forwards the informa-
tion to other nodes. e protocols were designed to be light-weight and robust to
changes in network density and node mobility.
e first protocol, zone flooding, implements the geocast delivery model de-
scribed in section .., with the limitation that the sender node has to be inside the
geocast destination area. e protocol is a variant of simple flooding where message
forwarding is limited by three rules. Firstly, each message will only be forwarded at
maximum n times. Messages contain a hop-count field that is decremented every
time the message is forwarded. When the hop-count reaches zero, the message
will no longer be forwarded. Secondly, sequence lists (as used in AODV [])
ensure that all nodes will forward any particular message at most once. Finally,
each message contains a destination region outside which the message will never be
forwarded. To realize the traffic warning system, each node periodically initiates a
flooding with information about the road at its current location.


Chapter . Data Dissemination in Vehicle to Vehicle Networks

e second protocol, zone diffusion, is a data-centric dissemination protocol

(cf. section ..) in which each node maintains an environment representation (ER)
containing the state the road in the neighborhood of the node. e ER is periodi-
cally broadcasted to other nodes. When a node receives an ER from another node,
the received ER is merged into the local one. If the ERs contain contradicting
values, a policy determines which value will be used.
e protocols were evaluated by simulating traffic scenarios based on the mi-
croscopic Freeway [] mobility model. Traffic traces were generated for a straight
section of road,  meters long and  meters wide, with vehicles moving in both
directions. To evaluate the protocols robustness to changing network mobility and
density, three classes of mobility were simulated: low velocity, medium, and high
velocity. In addition, the node count of the traces varied from  to .
e simulations were conducted using the network simulator NS- [] with
varying broadcasting intervals. Performance was measured using general purpose
and application specific metrics (cf. section ..). We measured the amount of
packets sent, received, and dropped to estimate network load. In addition, we
measured the awareness percentage - the fraction of vehicles receiving information
about a particular area before entering the area.
e protocols proved both to have suitable performance for the traffic warning
system. e zone flooding protocol generally achieves better awareness percentage
than the zone diffusion protocol, but the zone diffusion protocol achieves reason-
able awareness percentage at a much lower network utilization. To identify the best
protocol with respect to network load and awareness percentage over all combina-
tions of mobility and network densities, we analyzed the simulation results using
multi-objective optimization. It was found that if an awareness percentage of .
was acceptable then the zone diffusion protocol should always be used. e fact
that an awareness percentage of at least . was achieved in all the simulated sce-
narios using the zone diffusion protocol indicates that the protocol is robust with
respect to varying traffic mobility and density.

²cf. section ..


C Ո 

S C

While the previous chapter focused on enabling communication in vehicular net-

works, we now take a broader perspective and consider using service composition
for realizing service oriented architecture. As described in the introduction in chap-
ter , we consider the goal of service oriented architecture to be to match needs with
capabilities. While this can be done in a number of ways, we here focus on using
service composition mechanisms.
In the next section, we motivate the use of service composition by presenting an
application scenario. Following that, we present a general model of service compo-
sition. Based on the model, we present a framework for categorization of service
composition mechanisms in section ., and finally in section ., we describe our
contributions relating to service composition for pervasive computing.

. A S

e following scenario motivates the use of service composition in pervasive com-

puting. An overview of the scenario is presented in figure .
Consider a driver on his way to a faraway destination. He knows that before
reaching his target, he has to stop for gas somewhere along the way. To minimize
the total cost of his journey, he is interested in knowing which gas station in the
neighborhood of his route provides the cheapest gas. A server on the Internet
provides information about gas prices at different gas stations in the area, but has
no knowledge about the location of the gas stations. However, a location service
can, given a specification of an area, return the names of the gas stations in that area.
An example of a location service could, e.g., by the Google Maps service [].
If he were to complete the task manually, he would have to go through the
following steps:
. Enter his destination into the navigation system in his vehicle and in return
get some specification of the neighborhood of his route.
. Query the location service for the names of gas stations near his route.
. Query the gas price server for prices at the gas stations returned by the loca-
tion service


Chapter . Service Composition

92:10.12
95:10.52
98:11.02
92:10.12
95:10.52
98:11.02
GAS

4. Get gas

1. Enter destination
3. Get gas prices
2. Get gas stations
near route

Internet

Navigation System
Location service Gas price server

Figure .: Scenario

. Select the gas station with the lowest price and go to the station to refuel his
car.

Finding the lowest gas prices along the route to a destination is an attractive
service for many users and therefore it makes sense to implement a system providing
the service. Such a system can be realized in at least two ways.
A simple solution would be to implement the steps described above in an appli-
cation running on the navigation system. e application would invoke each of the
entailed services and use the results returned as input for the service in the next step.
is solution has, however, at least two drawbacks. Firstly, the system is bound to
a particular set of services, and if a service has to be replaced, the application has
to be reimplemented. Secondly, it could be that the application could be used as
part of another application. For example, if the driver has to take a detour to reach
the gas station, he might be interested in notifying people at his destination of his
delayed arrival. If this new application is to be realized, the application would have
to be rewritten.
A more flexible solution would be to use a service composition framework to
compose the application from the services in the scenario. From a conceptual point
of view, it makes sense to consider the application as a composition of services and
using a service composition framework can significantly reduce the effort required
to implement the application. Instead of hardcoding the logic of the system, a spec-
ification describes how the service composition is constructed. Depending on the
composition framework used, there can be support for replacing services at runtime
and to expose the service composition as a service in itself making it possible for it


 .. Service Composition Model

to be part of other applications.

. S C M

In this section, we describe a model for composition of services in pervasive com-

puting. e purpose of the model is to identify a set of central concepts and their
mutual relation to provide a vocabulary for the discussion of service composition in
the following sections.
e model consists of services, the specifying actor, the composite specification,
and the composite, which will each be described in the following. In figure ., an
overview of the model can be seen.

Composite

Service
Specifies Specification Instatiated Service

Specifying Service
Actor
Optionals

Figure .: Service composition model

Services A service is the basic means of providing a programmatic interface to a

capability. While the capability might be anything ranging from a temperature
sensor to a banking system, the service is a piece of software that makes it possible
to access that capability. In the introduction in section ., we defined a service as
follows:

A service is a unit of runtime software accessible by others.

Note that a prerequisite for being able to access a service is that the address of
the service is known. If the address it not to be hardcoded into the composite, a
service discovery mechanism has to be available [].
In the scenario in section ., the navigation system, the location service, and
the gas price server are all services. e capability provided by the navigation system
is the ability to return a route from the current location to a destination. e loca-
tion service has the capability to return a list of identities and matching locations of
all entities of a particular type within a specified area, and the gas price server has
the capability to return the gas prices at a specified gas station.


Chapter . Service Composition

Specifying actor e specifying actor is the entity that specifies the composite. is
can, e.g., involve constructing code, interacting with a user interface, or physically
connecting hardware. e specifying actor takes the initiative to create the com-
posite for the first time. It might not be the same entity that eventually will end up
using the composite. e motive behind initiating the creation of the composite
can vary from convenience to profit.
In the scenario above, there are several options for specifying actors. One can-
didate could be the navigation system provider. By creating the composite, the
navigation system provider adds value to his product. Another option is the driver
that creates the composite to solve his concrete problem. In addition, the loca-
tion service provider, the gas server provider, and the gas station owner could have
interest in creating the composite.

Specification e composite specification describes how the composite should look

and behave at runtime. e specification can take on different forms, but typically
contains information about which services should be part of the composite and how
they should interact. e specification can also contain additional information such
as, e.g., procedures for handling unexpected situations, requirements for quality of
service, etc.
A specification for a composite realizing the scenario above could, e.g., contain
a list of identities if the services involved in the scenario, and a script detailing the
logic in the application.

Composite e composite is the instantiation of the composite specification and

therefore consists of a set of services matching the services in the specification and
some running management code handling the functionality in the composite that
is not part of the services. e tasks of the management code include governing the
interaction among the services, handling unexpected situations, ensuring quality of
service requirements are satisfied, etc.
In the scenario above, the composite would contain all the necessary services
and the management code. e management code could, e.g., run on a server on
the Internet or on the navigation system.

. C F

In this section, we describe a categorization framework for service composition

mechanisms for pervasive computing based on the work in the paper presented in
chapter  and its previous version []. Here, we use the framework to describe
the variability in service composition mechanisms in the literature and as a frame
for the description of the contributions in the following section.
e categorization framework consists on nine categories that illuminate dif-
ferent aspects of service composition mechanisms. e categories were selected by
surveying a set of service composition mechanism and identifying their variation


 .. Categorization Framework

points. Below, we describe each of the categories by using the model introduced
in the previous section and give examples of the possible values by referring to the
literature. In table . in chapter , an overview of how a range of service com-
position mechanisms from the literature relate to the framework is presented. For
convenience, the table is also listed at the end of this chapter as table ..

Specified by denotes the type of specifying actor. e mechanism used for spec-
ifying the composite can be aimed at developers as a tool for constructing general
applications, or it can be aimed at the user to let him tailor an application for his
particular needs. If a developer specifies the composite he can only try to anticipate
what services will be available at runtime, whereas if the user specifies the composite
he can design the composite from the available services and compose services and
devices in new unanticipated ways as in [, ]. Since a developer can be seen as
a particular kind of user, technologies that support user specified composites also
support developer specified composites.
For example, consider the scenario in figure .. If the driver specifies the
composite, naturally, the composition mechanism should support user specified
composites, whereas if the navigation system provider specifies the composite, it is
enough that the composition mechanism supports developer specified composites.
In Service Composition for Mobile Environments (SCfME) [], which en-
compasses protocols for service composition in mobile ad hoc network environ-
ments, the composition is specified by application developers through a DAML
description [] of a “Description-level Service Flow” (DSF) in which sequences of
services may be described.
Another example is ICrafter [] in which users, operating through a GUI,
may combine services from different devices and have an aggregated user interface
generated.
With UbiDev [], an application developer supplies an ontology, classifiers,
and user interfaces for services in an application. e classifiers map resources on
devices into concepts in the ontology. A service is then defined as an atomic action
that transforms an input resource yielding a new resource as output. Services are
constrained by the concept (from the ontology) that it accepts as argument, and the
concept it produces as output.

Specified at e specifying actor can specify the composite at development time,

before the composition framework is up and running, or at runtime. Note that if
the composite is specified before runtime, it implies that it is done by a developer
since the user, at that time, has no way of interacting with the system. If the com-
posite can be specified at runtime, there is no need for restarting the composition
framework.
If the driver in the scenario in figure . is the specifying actor, then the compo-
sition mechanism has to support runtime specified composites. In contrast, if the
composite is specified by the navigation system provider, the composition mecha-


Chapter . Service Composition

nism only has to support development time specification.

Both ICrafter and SCfME provide for runtime composition specification. In
ICrafter, users may explore services available at runtime through the GUI of a gen-
eral purpose Interface Manager (IM) service. With the interface of the IM the
available services can be explored and a subset selected. An aggregate interface is
then requested for the selected set of services. In SCfME an application devel-
oper may supply new DSFs at runtime and have these bound dynamically to an
“Execution-Level Service Flow” (ESF) containing references to actual services.
UbiDev is more static in the sense that an ontology and corresponding classi-
fiers need to be provided prior to deploying the application. To change the possi-
ble service compositions, either the ontology or the classifiers need to be changed,
something that appears only to be possible at development time.

Specified in e specification can be specified by providing source code, configura-

tions, or interacting with a tool. If the composite is specified by user interaction, an
underlying representation has to be available to make the specification persistent.
Since the driver in the scenario in figure . cannot be expected to be able to
create source code or configuration files, the composition mechanism used has to
provide a graphical user interface if the driver specifies the composite. A navigation
system provider specifying the composite might not be interested in letting other
parties modify the composite and could therefore be motivated to use a composition
mechanism where composites are specified in source code. Finally, a motivation for
using a composition mechanism where composites are specified in a configuration,
could be that it is clear to see which services are used and how. If, e.g., the composite
is specified by the location service provider and downloaded by the driver from the
Internet, the driver could be assured that the composite behaves as specified and
has no malicious behavior just by looking at the configuration.
In ICrafter, the composition is specified by interacting with a tool in which
services are rendered. Services are described with a SDL (Service Description Lan-
guage) that includes a simple type system oriented towards UI generation.
In SCfME, the service composition is described via a configuration (a DAML
XML document) and in UbiDev the specification is partly programmatic since
application developers need to supply classifiers.

Level e services in the composite specification can be represented as instances,

types, or implicitly. In the case of instances, a particular service is bound to the
composite by e.g. an URN []. If the services are specified by types there can be
several candidates for each service specified. Finally, if the user instead of specifying
how services are connected, requests a task from the framework that has to be
resolved into a composition of services, we regard the services as being specified
implicitly.
If the driver in the scenario in figure . specifies the composite using a GUI,
conceptually, there can be at least two ways to do this. Firstly, the GUI can let the


 .. Categorization Framework

him construct the composite taking as outset the currently available services in a
prototype-based programming [] approach. Hereby, the services are specified at
the level of instances. Secondly, the GUI can let the driver specify what his goal is,
e.g. by using concepts in an ontology. An example could be some visual represen-
tation of the statement: “Get lowest gas price near route to Bob”. e statement
would then be parsed and matched against the available services. Finally, an exam-
ple of type-level composite specification could be the navigation system provider
using source code to include the any available location service in the composite.
With respect to the level of description, SCfME is characteristic of an approach
in which the composition is described at a type level and resolved at runtime by the
service composition implementation to an instance level. ICrafter, on the other
hand, operates only on an instance level in that it is specific services that users
select for inclusion in the composite. Finally, UbiDev operates on an implicit level
based on the ontology and classifiers specified. One example is a generic messaging
service, document_to_display that can be adapted to the context by UbiDev. If the
user context is a personal phone, UbiDev will compose the services ascii_to_wav,
wav_to_adpcm, and adpcm_to_voice to provide the document_to_display service.

Quality of Service (QoS) requirements Some composition mechanisms support spec-

ifying quality of service requirements in the composite specification. If, for instance,
the services are specified as types the selection of the actual instances can be guided
by the quality of service requirement specification.
One example of a quality of service requirements in the composite in the sce-
nario in figure ., could be that the driver, for protection of privacy, might not
want the location service to store his location, but if no such location service is
available, he is ready to settle for a normal location service.
In the Amigo service composition mechanism [], services are described as
semantic Web services (using OWL-S []) in which atomic processes have QoS
attributes with values obtained from runtime measurements. An example of a QoS
requirement would be that latency should be less than a threshold. At runtime, an
abstract specification of a composite service is matched against possible realizations,
the latencies for the realizations are calculated, and the best composition is chosen
(also subject to other constraints) [].

Contingencies Unforeseen conditions can be handled at different levels. e trivial

option is to have no support for contingencies at all. A slightly more advanced
solution is to detect the contingency and alert the user, and a natural extension of
this approach is to resolve the contingency automatically. It should be noted that
in some cases, it is impossible to resolve contingencies automatically and in these
situations, the user should be in the loop.
An example on a contingency in the scenario in figure . could be that an ac-
cident occurs somewhere on the route from the driver to his destination forcing the
navigation system to recalculate the route. Since the gas price information is no


Chapter . Service Composition

longer valid for the new route, something should be done to correct the situation.
If the composition mechanism has no support for detection of contingencies, the
driver will potentially miss the gas station and run out of gas. If the composition
mechanism detects the contingency, it can either notify the driver about the prob-
lem or try to resolve the situation by recalculating the cheapest gas station along his
new route.
As an example, in SCfME the state of the execution of a composition is check-
pointed by sending partial results back to the service requester. If the Composition
Manager fails, the service requester is notified and may create a new concrete ESF
based on the original abstract DSF and its latest checkpoint and finds a new com-
position manager.
In UbiDev, since the composition is implicit and dynamic, contingencies such
as partial failures will be handled automatically as classifiers find new ways of real-
izing compositions.

Resource use Since many devices for pervasive computing have limited resources,
it is relevant to look at resource use. We divide composition mechanisms into what
kind of system the composition mechanism requires. One type is a server platform
and another is a typical PDA. A third category would be a smaller sensor/actuator
platform such as Motes (http://www.tinyos.net/).
If the navigation system in the scenario in figure . is comparable with a PDA
platform, the composition mechanism should be able to run on PDA-type systems.
For the scenario, it is not a problem if the composite is coordinated from a server
on the Internet.
A number of solutions apply semantic Web technology (e.g., SCfME and Amigo),
which means that at least parts of the middleware will not scale to low-end devices.
Other than that, most service composition mechanisms seem to aim at PDA-type
devices and only DSCiPC [] integrates sensor/actuator platforms.

Infrastructure In pervasive computing environments, services might not be con-

nected at all times. Devices may enter and leave a given network and therefore it is
important whether the composite has to have a fixed connection during operation
or whether devices can enter and leave on an ad hoc basis.
When the vehicle in the scenario in figure . queries the Internet servers for
information about locations and gas prices it is necessary that the navigation sys-
tem in online and thus connected to an infrastructured network and hereby the
scenario places no requirements on which infrastructures the composition mecha-
nism should support. On the other hand, if the location information and gas prices
where provided by other vehicles instead of Internet servers, it would be a prereq-
uisite that the composition mechanism supported ad-hoc networks.
In SCfME, devices are peers and communicate via ad hoc protocols. In par-
ticular, a Group-based Service Routing (GSR) on-demand protocol in which the
route is constructed during service discovery is used for routing service invocations.


 .. Contributions

In contrast, ICrafter assumes a fixed infrastructure in which a global commu-

nication infrastructure resembling a tuplespace may be constructed.

Topology Some of the mechanisms require a central node to act as a coordinator

for the composite and thereby impose a centralized structure on that composite,
whereas other mechanisms allows for a decentralized structure.
SCfME is decentralized in that after an ESF is created, any node in the system
can be used as a Composition Manager that handles the execution of the compo-
sition. e Composition Manager may be dynamically changed during the execu-
tion.
Based on finite state automata for individual OWL-S processes, the Amigo
service composition mechanism builds a global finite state automaton for all ser-
vices. In this sense, the Amigo service composition mechanism relies on a central
component.

. C

In this section, we describe our contributions relating to service composition for

pervasive computing.

.. Service Composition for Pervasive Computing

e paper Issues in Service Composition for Pervasive Computing in chapter  an-

alyzes the use of service composition for pervasive computing applications. With
the goal of investigating what is required for a service composition mechanism for
pervasive computing, we identified a set of characteristics of pervasive computing
technologies. As described in the introduction in chapter , pervasive computing
technologies are characterized by being openended, context aware, dynamic, and het-
erogeneous. Furthermore, they may incorporate networked sensors and actuators and
present new challenges to usability. For a service composition mechanism to be
usable in a pervasive computing setting, the composites created by the mechanism
should be able to exhibit these characteristics. If, for example, the composition
mechanism only runs on PC scale systems, the mechanism is not suited for per-
vasive computing. While some of these characteristics can be supported from the
level of services, in the paper we only consider the support provided by the compo-
sition mechanism. In the following, we shortly summarize the conclusions of the
paper with respect to each of the characteristics.

Openendedness It is often the case that applications of pervasive computing need

to be repurposed to match new user requirements or changes in the context. To
some degree, changes in the context can be resolved automatically, but if the users
requirements change, it can be hard for the system adapt. To take changes in user
requirements into consideration, we claim that the user should be in the loop. It


Chapter . Service Composition

should thus be possible for the user to (re)specify the composite at runtime.

Context awareness e support for context awareness can be divided according to

when it is provided. Before the composite is instantiated, support can be provided
by selecting the services to participate in the composite based on context informa-
tion. For this to be possible, there should be room for selection in the declaration of
the services in the composite specification. If types are used to declare the services
in the specification or if the services are declared implicitly, there can be several
choices for each role in the composite. But if the services are declared by specifying
instances, multiple choices has to be available for each role in the composite. e
selection of which services should be part of the composite at runtime can e.g. be
guided by quality of service specifications.
At runtime, context awareness can be supported by providing support for con-
tingency handling. If the composition mechanism only support the detection of
contingencies, it should be possible for the user to resolve the contingency manu-
ally by, e.g., respecifying the composite at runtime.

Dynamicity Dynamicity in which services are available can be supported by pro-

viding contingency handling. In case of a fault, a replacement service should be
found and/or the user should be notified. In some applications, any node can enter
or leave the network at any time. Under these circumstances, the topology should
be decentralized in case the contingency handling node leaves.
Dynamicity in the quality of service provided can be supported by allowing
for quality of service requirements in the composite specification. If, for example,
the communication bandwidth to a service drops below a certain level because of
noise in the communication channel, the composite mechanism could try to find a
replacement service.

Heterogeneous devices Since it can be expected that pervasive computing applica-

tions will consists of heterogeneous devices, the composition mechanism should
be designed to distribute the responsibility of managing the composite based on
device capabilities. Nodes can be heterogeneous in terms of computation capa-
bility, memory availability, communication capability, power availability, mobility,
user interface, etc. and therefore it is important that the composite is instantiated
considering the available context. Optimally, the responsibility of managing the
composite should be distributed among the most capable nodes, considering the
concrete requirements a particular management task has. If, e.g., service descrip-
tions are stored in a central registry, the node hosting the registry should have high
availability and should be able to handle a high number of requests. Similarly, if
the user can interact with a composite management interface, the interface should
be located in close proximity to the user and on a device with suitable IO capability.


 .. Contributions

Networked embedded sensors and actuators A prerequisite for including embedded

nodes in a composite is that the composition mechanism is designed so that the
resource requirements for the embedded nodes are suitable. Typically, this implies
that not all nodes are equal in the composite with respect to monitoring connec-
tions, forwarding service invocations, etc., and therefore a centralized, or at least
not completely decentralized, topology is preferable. If the topology is completely
decentralized, all devices must have a representation (or at least a part of ) the com-
posite specification, which makes it important that the composite is specified in a
compact form. An xml configuration is typically more cumbersome than compiled
source.

Usability e usability of a composite is to a large degree determined by how the

user interacts with the composite. An important parameter here is the design of
the user interface, but here we do not consider the user interface of the service
composite to be part of the composition mechanism and will therefore not discuss
this further.
One aspect of usability is that if the user specifies the composite, he can adapt
the application to his concrete needs. If a tool is available for specification of the
composite, he is better of than if the composite has to be specified in a configuration
file or in source code. It can be argued that it is easier for the user if he only has
to express his intention and let the composition mechanism translate his intentions
to a concrete composite. By using this approach there is, however, gap between
the users understanding of the composite and the concrete layout of the compos-
ite. During normal operation, this is not a problem, but if contingencies arise and
the user has to resolve the situation, the composition mechanism has to be able to
express the problem in terms understandable by the user - and here the gap might
be a problem.

Relation to the categorization framework By using the categorization framework

presented in section . as an outset, we analyzed the relation between the char-
acteristics and the categories in the framework. In table ., an overview of the
dependencies can be seen.
As can be seen in the table, there is not a one to one relation ship between
the characteristics of pervasive computing and the categories in the framework.
Table . can be used together with table . to get an overview of how pervasive
computing characteristics are supported in current service composition mechanisms
in table ..

.. Dynamic Membership Composites

e paper Handling membership dynamicity in service composition in chapter , in-

vestigates the problem of handling composites where the set of participating services
in the composite varies over time. An example could be a chat application that dy-


Chapter . Service Composition

QoS requirements
Contingencies

Infrastructure
Resource use
Specified by

Specified in
Specified at

Topology
Level
Context Awareness x x x x
Networked Embedded Sensors and Actuators x x x
Heterogeneous Devices x x
Dynamicity x x x x
Openendedness x x x
Usability x x x

Table .: Characteristic/Category Dependencies

namically expands as users arrive. A set of users could be carrying mobile devices
and when a group of users meet, they can use the application to chat. It can be
problematic to realize this application using traditional composition mechanisms,
because it is unknown when the composite is created which services will eventually
be part of the composite. Furthermore, the nature of the application is that users
leave and join on an ad-hoc basis implying that none of the mobile devices should
host the composite by itself. It is trivial to express the application in source code
using programming abstractions such as collections, etc., but if the user should be
able to compose the application, using source code is not an option.
In the paper, we present an extension of the PalCom assembly script language []
that makes it possible to specify composites with varying member sets. In the fol-
lowing, we first describe the PalCom assembly script language and following that,
we describe our extensions.

e PalCom assembly script language In the PalCom architecture, device function-

ality is encapsulated in services that can be remotely discovered and invoked. Each
service has a set of commands that can be either in-going or out-going. In-going
commands are similar to asynchronous methods with an optional number of pa-
rameters. ey can be invoked from other services or by the user. Out-going com-
mands make it possible for the services to provide output. e output can be used
as input for in-going commands or can be presented directly to the user. e out-
put has an optional number of parameters. An example could be a service acting
as an interface for a lamp. e service could have two in-going commands on and
off and an out-going command state that is invoked every time the state of the
lamp is changed. Services and commands are composed in assemblies described by
assembly scripts where services and devices are declared along with a description of
which commands are connected. Variables that can hold state can also be declared.
e gas price scenario in figure . can be implemented by the assembly script
listed in figure .. Lines – declare which devices take part in the assem-
bly. Note that a unique name (URN) is given for each of the devices. Similarly,


 .. Contributions

 assembly GasPrices {
 devices {
 nav_system = urn:palcom://garmin-street-pilot-c580-AE3C;
 lshost = urn:palcom://location.service.com;
 gphost = urn:palcom://gas.prices.com;
 }
 services {
 ui on nav_system = /navigavtion_ui;
 gas_price_display on nav_system = /gas_price_display;
 location_service on lshost = /location_service;
 gas_prices on gphost = /gas_prices;
 }
 connections {
 ...
 }
 script {
 variables {}
 eventhandler {
 when destination_entered from ui on nav_system {
 send get_route(thisevent.destination) to ui on nav_system;
 }
 when route_found from ui on nav_system {
 send lookup("gas station", thisevent.route) to location_service on lshost;
 }
 when found from location_service on lshost {
 send get_prices(thisevent.entities_found) to gas_prices on gphost;
 }
 when return_prices from gas_prices on gphost {
 send display_cheapest(thisevent.prices) to gas_price_display on nav_system;
 }
 }
 }
 }

Figure .: GasPrices script

lines – declare the services in the assembly. In line –, the flow of events
through the assembly is described. E.g., lines – specify that when the out-
going route_found command from the navigation systems’ ui service is invoked,
the location_servive’s lookup command on the location server (lshost) is in-
voked. e script in figure . can be created by using a text editor or by the user
by interacting with a tool.

Extensions e extensions of the assembly script language we propose can be di-

vided into two parts: selection is about selecting which devices should participate in
the assembly and naming deals with how to represent the services and devices in
the specification of the flow of events. We describe selection in the next paragraph
and naming in the following paragraph.
Given a set of nodes we need a method for selecting those that should be part
of the assembly. In the unextended version of the scripts, this is done using URNs
but for assemblies with dynamic membership this is, as mentioned previously, not
enough. Instead, we propose to use a simple wildcard pattern on the device URN so
that a single line in the device declaration part of the script (lines – in figure .)


Chapter . Service Composition

can declare multiple devices. Lines not including a wildcard character (‘*’) will be
interpreted as before. As an example, the line:

chat_device = urn:palcom://pda*

matches all devices with a URN with the prefix urn:palcom://pda. Hereby, all the
chat clients in a chat application can be declared in a single line.
With the extension mentioned above, each line in the device and service decla-
ration parts of the script potentially declares multiple devices/services and associates
a name. is name is used in the eventhandler part of the script to specify the flow
of events. We extend the semantics of the eventhandler part so that the line:

when message_typed from chat on chat_device {

is used when the out-going command message_typed is invoked on any chat_device.

In the case that chat_device only denotes a single device, the interpretation is unal-
tered. Similarly, the interpretation of the invoke part of the eventhandler is changed
so that the line:

send display_message(thisevent.message) to chat on chat_device;

will invoke the display_message in-going command on all the devices denoted by
chat_device. Again, if chat_device only denotes a single device, the interpretation
is unaltered.
To allow for local flow of events on devices declared with a wildcard, the key-
word ‘local’ can be inserted into the send statement to denote that only services
on the same device are invoked. Assume for example that chat_device is declared
using a wildcard and the eventhandler includes the following lines:

when message_typed from chat on chat_device {

send local display_message(thisevent.message) to chat on chat_device;
}

en, when the message_typed command is invoked on a device, the display_message

command will only be invoked on the same device.
e modifications above all have the property that if no device is declared using
a wildcard, then there are no modifications of the interpretation of the assembly
scripts. is implies that the changes are backwards compatible.
In the paper, we argue that the extended script language is expressive enough for
realistic applications by demonstrating its use in an application scenario developed
in cooperation with end-users. A preliminary user study indicates that the language
is suited for pervasive computing applications, that it is not hard to understand, and
that it is only mildly complicated to use.
In addition to the script language extensions, we have implemented a decen-
tralized interpretation engine for the language. Experiments showed that the per-
formance of the engine is appropriate for pervasive computing applications.


 .. Contributions

Using the framework described in section ., we have categorized the standard
PalCom service composition mechanism and the extended script language running
on the decentralized implementation. In table ., the result can be seen.

Category Standard Extended

Specified by End-user End-user
Specified at Runtime Runtime
Specified in Configuration Configuration
Level Instances Types
QoS reqs. No No
Contingencies Automatic No
Resource use PDA PDA
Infrastructure Ad Hoc Ad Hoc
Topology Centralized Decentralized

Table .: Categorization

e two mechanisms differ in the following ways. In the standard composition

mechanism, services are specified at the level of instances whereas in the extended
composition mechanism services are specified by declaring sets of URNs. Since a
wildcard expression do not denote a single instance but rather a set of instances, we
have classified the extended composition mechanism as specifying services at the
level of types.
e standard PalCom composition mechanism has automatic contingency man-
agement whereas the extended composition mechanism currently has no support
for contingencies.
Finally, the standard PalCom composition mechanism relies on a centralized
topology whereas the extended composition mechanism runs decentralized.


 Composite Specification Runtime Deployment
System Specified by Specified at Specified in Level QoS req. Contingencies Resource use Infrastructure Topology Evaluation
Amigo [109, 148] End-users Runtime End-User int. Implicit Yes Automatic PDA+Server Fixed Centralized Sce. perf.
Aura [56, 141] End-users Runtime End-User int. Types Yes Automatic PDA+Server Ad Hoc Centralized Example
Daidalos [160] Unknown Runtime Configuration Types Yes Runtime Unknown Unknown Centralized Example
DSCiPC [79] App. Devs Runtime Configuration Implicit Yes Automatic PDA+Mote Ad Hoc Decentralized Ex., Perf.
DSD [8] App. Devs Dev. time Configuration Instances, Implicit Yes Automatic J2SE Ad Hoc Decentralized Example
GAIA [135] App. Devs Dev. time Configuration Types No Automatic PDA+Server Fixed Centralized Example
ICrafter [130] End-users Runtime End-User int. Instances No None PDA Fixed Centralized Example
Obje [41] End-users Runtime End-User int. Instances No Detection PDA Ad Hoc Decentralized Example
one.world [62,63] App. Devs Runtime Source Code Instances No Detection J2SE Ad Hoc Decentralized Sce., Usab., Perf.


Ozone (WSAMI) [75] App. Devs Dev. time Source Code Types Yes None PDA Ad Hoc Decentralized Ex., Perf.
PalCom [145] End-users Runtime Configuration Instances No Automatic PDA Ad hoc Centralized Scenario
Paths [86] App. Devs Runtime Configuration Implicit No None PDA Fixed Centralized Scenario
QuAMobile [2] App. Devs Runtime Configuration Types Yes Automatic PDA+Server Ad Hoc Unknown Scenario, Perf.
SCfME [32] App. Devs Runtime Configuration Types No Detection PDA Ad hoc Decentralized Performance
SpeakEasy [40, 42, 115] End-users Runtime End-User int. Instances No Detection PDA Ad Hoc Decentralized Ex., Usab.
TCE [100, 101] End-users Runtime End-User int. Instances No None PDA Ad Hoc Centralized Example
UbiDev [94] App. Devs Dev. time Source Code Implicit No Automatic PDA+Server Ad Hoc Centralized Example
Chapter . Service Composition

Table .: Categorization of Service Composition Mechanisms

C Ո 

P  P C

Palpable computing is a new perspective on pervasive computing, in which tradi-

tional pervasive computing challenges such as invisibility and composition are com-
plemented with visibility and deconstruction []. e concept has been formed
based on the observation that when applied in real settings, pervasive computing
systems tend to become hard to understand for users. For example, in normal use
the system should be invisible and not interfere with the present task. However,
when a breakdown occurs the user should be able to inspect the system to determine
the reason and, if possible, resolve the situation.
Consider the gas price notification application described in section .. As-
sume that the application is part of the navigation system. When first started, the
navigation system queries the driver for his fuel preferences and subsequently uses
the information in the selection of gas stations. A problem might occur when the
driver installs the navigation system in a new car. Since the navigation system has
no knowledge of it being transferred, it will still select gas stations based on the
old cars fuel preferences. e driver can have a hard time detecting that the system
leads him to gas stations with suboptimal prices, but if he does so it can be even
harder for him to determine the reason. If he was able to inspect the system to
discover the logic in the application and the current state, it would be much easier
for him find the reason behind the malfunction and correct it.
Techniques such as self-reconfiguration, error detection, and fault tolerance
should also be used, but they will never be perfect and therefore, as a supplement,
there has to be a way for the user to take over control of the system.
Palpable computing is a product of the PalCom project described in section ..

. C

e paper Palpability support demonstrated in chapter  describes how palpability

can be achieved in a rehabilitation scenario by using service composition to com-
pose applications and expose the structure of applications to the user on demand.
In the following, we describe the rehabilitation scenario and the associated appli-
cations. Following that in section .., we summarize how palpability is achieved
and finally, in section .., we describe how the scenario can be realized by using


Chapter . Palpability in Pervasive Computing

the extended script language described in the previous chapter (section ..).

.. e Active Surfaces Scenario

e Active Surfaces [] concept provides support for physical-functional and cog-
nitive rehabilitation in a swimming pool setting. e concept has been developed
using participatory design techniques in corporation with therapists and patients.
rough analysis of the rehabilitation practice a number of different games have
been developed in which children assemble floating tiles into meaningful configu-
rations (see figure .).

Figure .: Tiles

Each of the tiles is a resource constrained embedded system that communicates

using only a low bandwidth short-range infrared interface on each of its four side.
Two tiles can only communicate if they are placed next to each other within a few
centimeters. e only output from the system available to the user is a set of light
emitting diodes along the edges of the tiles. On the face of each tile is a replaceable
plastic cover.
ree games have been developed for the tiles.

• One where the goal is to ‘catch’ a blinking tile by touching it with another
tile.

• A scrapple-like game where each tile has a letter on the cover and words
should be formed by moving the tiles around

• A picture puzzle where each cover is a piece of the puzzle.


 .. Contributions

.. Palpability

Palpability is achieved in the games by implementing them using the PalCom as-
sembly script language described in the previous chapter and the PalCom service
framework []. is enables the therapist to inspect the inner workings of the
games in case of break down situations. rough interaction with the assemblies,
the therapist can inspect and change the configurations of the tiles. is way, she
can adapt the therapeutic activity in the middle of an exercise, and the visibility
given by the assemblies helps her to cope with unexpected breakdown situations.
For example, in the puzzle game, the difficulty can be varied by changing the
type of feedback. If no feedback is given before the correct solution is obtained,
the game can be too hard for some children. If, however, feedback is provided each
time a piece of the puzzle is placed correctly, the game is easier. e therapist can
change the type of feedback by modifying the assembly. is can, e.g., be done by
attaching a tile to a computer and modifying the assembly in an interactive way. If
this is a task often performed by the therapist, she can create a new assembly that
can be used to change the other assemblies.

.. Implementation Using the Extended Script Language

e extended PalCom assembly script language, described in the previous chapter,

can be used to implement the puzzle game more naturally than the approach used
in the paper in chapter . Actually, the Active Surface scenario was one of the
conditions prompting the development of the extended script language.
In the puzzle script described in chapter  (figure .), each tile has its own
unique assembly script that describes its part of the whole. While these scripts are
very similar, they differ in an important way: the device declaration part of each
script is unique. Having almost identical assembly scripts on all the nodes has a set
of downsides. First, each newly arriving tile has to be programmed with the script.
Secondly, if the script is updated to a new game, all the tiles have to receive their
own new script and finally, the way the nodes communicate with each other rely on
a basic broadcast mechanism in the PalCom framework and this circumvents the
assembly mechanism.
As an alternative, the extended assembly script language described in the pre-
vious chapter in section .. can be used to implement the puzzle game. By using
the wildcard mechanism, all nodes can use the same script. Furthermore, they can
communicate with each other by using the assembly script mechanisms without
talking directly to the lower layers of the PalCom communication stack.
While the extended script language is strong enough to implement the puzzle
game, it should be noted that the current decentralized interpretation engine for the
assembly scripts has to be optimized to be usable for implementing the game. In
the current implementation, when invoking commands on a set of services declared
with a wildcard, it is done by making a unicast connection to each of them and
then invoking the commands in sequence. is solution will, however, not work on


Chapter . Palpability in Pervasive Computing

the tiles because the bandwidth is too limited. Enabling unicast requires that, at
some level in the communication stack, each tile keeps track of which of the other
tiles it can reach. Maintaining this information generates too much traffic for the
bandwidth limited infrared links.
A better approach, that would be more suitable for the puzzle game, would
be to create a multicast group (cf. section ..) for each of the declarations con-
taining a wildcard. If multicast is implemented by filtering broadcast messages, no
bookkeeping for which nodes are available is necessary.


C Ո 

C

roughout this dissertation, we have approached service oriented architecture for

pervasive computing from different angles by looking at the architecture of vehic-
ular technology applications, data dissemination models, service composition for
pervasive computing, and by investigating palpability in pervasive computing sys-
tems. Together with the contributions of the papers in part II, these angles consti-
tute a step towards using service oriented architecture to alleviate the challenges of
pervasive computing and in particular vehicular applications. In the following, we
summarize the contributions made and present directions for future work.

. S  C

More specifically the contributions can be summarized as follows:

• We investigated architecture in vehicular technology applications from three
different perspectives. ) Looking at a concrete application, we identified
functional and architectural requirements that let to the design of an archi-
tecture that was evaluated though a series of prototypes. ) We presented
a uniform publish-subscribe communication infrastructure for component
based architectures that hides the complexity of low-level network program-
ming and presents a clean and understandable abstraction over communi-
cation to the application programmer. ) We made a connection between
business aspects and software architecture by presenting a business model for
the provision of information about the environment to drivers.
• We presented an overview of data dissemination protocols and their evalua-
tion and presented two lightweight and robust zone dissemination protocols
based on flooding and data aggregation.
• We presented a model and a categorization framework for service composi-
tion in pervasive computing that was used to analyze how the characteristics
of pervasive computing can be support by service composition. We described
how to extend the PalCom assembly script language to support service com-
position with dynamic membership and presented a decentralized interpre-
tation engine.


Chapter . Conclusion

• We demonstrated how palpability can be supported in a prototype of the

Active Surfaces concept by using service composition to open up the system
to the user in breakdown situations.

. F W

e contributions made in this dissertation open up for future work in a variety of

directions. Since the focus in the dissertation have been relatively broad, a natural
direction would be to dig deeper into each of the topics investigated to gain fur-
ther insights into how service oriented architecture can be used to deal with the
challenges of pervasive computing. In each of the papers in part II, we have given
directions for future work. In the following section we describe a few of these.
A natural extension of the Zone Diffusion protocol described in chapter ,
would be to let the structure of the environment representation (ER) reflect the
spatial relevance decrease (cf. section ..) of the data communicated. is could,
e.g., be done by making the cells in the ER larger towards the edges. is would
make sure that less relevant data take up less space in the ER and thereby informa-
tion about a larger area could be contained in the ER.
An interesting tool for the extended assembly script language presented in chap-
ter  and used (unextended) in chapter  would be a graphical user interface for
creation of assembly scripts and interaction with running assemblies. e inter-
face should be designed for end-users with limited previous experience with pro-
gramming and should be used to explore the feasibility of end-user general purpose
programming.
One way to connect the contributions presented in this dissertation would be
to implement a framework supporting service oriented architecture, tailored for
vehicular networks. In section .., we motivated the use for such a framework as,
among other things, a solution to the bootstrapping and fragmentation problems.
In realizing such a framework, there is a set of challenges which we describe in the
following.
Traditionally, service frameworks rely on unicast communication between nodes,
but in vehicular networks, this assumption is unsuitable because the mobility of ve-
hicles makes is necessary to optimize the protocols used to the vehicular environ-
ment and exploit application level information when routing messages. Instead, we
propose to use the publish-subscribe model for communication. In section ..,
we proposed a middleware architecture where the publish-subscribe paradigm was
used to present a clean abstraction over communication to the developer. While, ar-
guably, there is a long way from a publish-subscribe mechanism to a service frame-
work, service invocation can, at a primitive level, be seen as sending a message from
the service consumer to the service provider, and thus the publish-subscribe frame-
work could be used as outset to the realization of a service framework for vehicular
applications.
To realize some of the applications described in section ., it is necessary to al-
low for composites with dynamic membership. It should, for example, be possible


 .. Future Work

to create a composite where when a certain condition occurs, services will be in-
voked on all neighboring vehicles. In the road state notification system, this could,
e.g., be used to disseminate a warning about a pothole. e script language pre-
sented in section .. could be extended to allowing a more detailed specification
of sets of nodes. In the current version, at set of nodes is declared by specifying
a wildcard expression. While this may be at the expense of usability, it might be
necessary to give the language enough expressive power to realize relevant vehicular
applications.
A natural addition to such a framework would be a suite of tools for evaluating
composite services. Part of this suite should be traditional network simulation tools
and mobility models. Since what is tested is service composites, models for service
use [] would also have to be available.

.. Security and Privacy

Two topics of interest that remains largely untouched by this dissertation are secu-
rity and privacy. In the following, we discuss different issues in relation to providing
security and privacy in vehicular networks and provide references to the literature.
Security and privacy are important in vehicular applications for a variety of rea-
sons. For a large part of the applications described in section . the consequence
of service unavailability is loss of safety (cf. table .), and therefore security is cru-
cial. For example, in a platooning system, a malicious attacker could inject false
messages to cause collisions among the vehicles in the platoon. For paid services, it
is important that non-paying drivers are not able to benefit from any information
intercepted and that the paying driver can assume that the data received originates
from the service provider and have not been altered. Furthermore, payment trans-
actions should be possible. With respect to privacy, location information is sensitive
and it should not be easy to log information about other vehicles’ location.
In infrastructure-based vehicular networks, the security and privacy issues re-
semble those that can be found in traditional networks. In VANETs, however,
traditional solutions to security and privacy issues can often not be used because
of the the special characteristics of the environment. For example, in a VANET
there is no central authority that can be reached by all nodes. However, until re-
cently [], security and privacy in VANETs have received only little attention in
the literature.
A starting point for future work in security could be the observation that, for
some applications, security can be achieved by only using ad-hoc communication
when strictly needed. One example could be a navigation system provider that sells
road state notifications to customers. e information could, e.g., be generated by
the navigation systems mounted in the vehicles of the customers and disseminated
using a VANET. To avoid using the insecure communication channel for sending
payment information, the navigation system provider could, e.g., use GPRS for the
payment transaction. is requires however, that the customer does not buy infor-
mation on a notification-by-notification basis, but that some kind of subscription


Chapter . Conclusion

is involved. To avoid that non-paying drivers have access to the information, the
information could be encrypted by the navigation system and keys could be updated
regularly using the GPRS connection.
A service oriented framework for vehicular applications, such as the one men-
tioned above, should include a security architecture.
In the literature, several suggestions have been given to secure communication
in VANETs. In [], Parno and Perrig identify challenges for providing secu-
rity and privacy in VANETs. ey suggest the use of a set of security primitives
as building blocks in secure applications. e primitives include authenticated lo-
calization of message origin, an anonymization service for providing anonymous
identities, and secure aggregation techniques for aggregation of data in the net-
work. In [], Raya and Hubaux provide a detailed threat analysis of VANETs
and present a security architecture based on digital signatures. e architecture
provides authentication but no confidentiality because the authors argue that this
is not necessary for safety applications.


 P II

P


C Ո 

A I   T W S

Jeppe Brønsted, Klaus Marius Hansen, Lars Michael Kristensen

Abstract

e LIWAS Traffic Warning System aims at providing early warning to

vehicles about road conditions, such as whether the road is slippery. e LI-
WAS system is currently being developed and consists of two main parts:
sensors for determining the state of the road and a communication infrastruc-
ture supporting inter-vehicle communication. is paper presents our results
on requirements identification, design, and prototyping of the infrastructure.
e infrastructure combines communication via mobile phones with commu-
nication based on the principles of ad-hoc networking, and it supports units
in being updated during operation. e presented prototypes and associated
experimental results demonstrate the main functionalities of the communica-
tion infrastructure, and have led to the initial deployment of LIWAS units.

. I

Traffic warning and information systems is a promising application area for ad-
hoc networking [] and pervasive computing []. Several research projects are
currently concerned with the development of inter- and intra-vehicle communica-
tion infrastructures to enable such systems. Examples of this include the Virtual
City Protocol [], CarNet [], FleetNet [], INVENT [], and TrafficView
[]. ese projects cover a broad spectrum ranging from application software to
network protocols and data-link layer technologies.
e LIfe WArning System (LIWAS) is a traffic warning system being devel-
oped in a research collaboration between ISIS Katrinebjerg at University of Aarhus
[] and LIWAS Aps []. e LIWAS system is based on sensors that are
capable of determining whether the surface of the road is dry or covered with wa-
ter, snow, or ice. A LIWAS sensor consists of a collection of sensors, and it is the
input from these sensors that are collectively used to classify the state of the road.
A vehicle equipped with a LIWAS sensor is able to inform the driver about the
Published as:
Jeppe Brønsted, Klaus Marius Hansen, and Lars Michael Kristensen. An Infrastructure for a Traffic
Warning System. In Proceedings for the IEEE International Conference on Pervasive Services, pages
–, . Acceptance rate: 


Chapter . An Infrastructure for a Traffic Warning System

state of the road being passed. is can help the driver take precautions according
to the current road conditions. In addition to this intra-vehicle communication,
the vision is to use wireless communication between vehicles to support vehicles
equipped with the LIWAS system to inform each other about the state of the road
being approached. To support this vision, inter-vehicle communication of road-
state information is required. Stationary LIWAS sensors may also be deployed as
part of, e.g., road-signs.
e design and implementation of an infrastructure enabling the LIWAS sys-
tem present several challenges. In early stages there will only be few LIWAS units,
i.e., vehicles and road-signs equipped with the LIWAS system. is means that
an infrastructure based on ad-hoc networking and wireless communication directly
between the LIWAS units will be insufficient. e infrastructure must support a
gradual deployment of LIWAS units which suggests that the infrastructure should
encompass a back-end network such as GSM or GPRS that can provide acceptable
coverage from the very beginning. A centralised architecture may, however, lead to
scalability problems in the long-term as the number of LIWAS units increases. We
have therefore developed a hybrid infrastructure that combines the use of ad-hoc
networking and a back-end infrastructure.
Another main challenge is the testing and deployment of software and hard-
ware implementing the infrastructure. A large-scale realistic evaluation of the LI-
WAS infrastructure prior to deployment would require orchestration of hundreds
of vehicles and is therefore not realistic in practice. is means that, e.g., the scal-
ability of the communication protocols cannot be precisely judged until after the
deployment of the LIWAS system has commenced. As a consequence, it is of great
interest to explore the use of techniques that make it possible to remotely update
running software in already deployed LIWAS units. In this paper, we explain how
we have used the OSVM platform (formerly known as Resilient []) when proto-
typing the infrastructure to enable experiments with performing run-time updates
of the software in the LIWAS units. e capability of being able to update the
LIWAS system when deployed is not only useful for the software implementing
the protocols used in the infrastructure, but also for the software implementing the
classification algorithm determining the state of the road from the measurements
made by the sensors.
e contribution of this paper is twofold. e first contribution is to present
an infrastructure supporting the LIWAS system. e second contribution is to
present the first set of prototypes realising the key aspects of the infrastructure.
ese prototypes have led to the initial deployment of the LIWAS system. e
infrastructure is presented in the context of the LIWAS system, but since the in-
frastructure is independent of the concrete measurements made by the sensors, we
consider the infrastructure applicable also for other types of traffic warning sys-
tems, such as systems informing about queues, delays, and road works. Similarly,
our experiences obtained in the course of developing and evaluating the prototypes
are of general relevance to practitioners in the field. e technical aspects of the
sensor system are out of scope of this paper.


 .. Main Requirements

e rest of the paper is structured as follows. Section . gives a detailed ac-
count of the requirements identified for the LIWAS infrastructure, and Section .
presents the designed architecture. Sections .-. present the three prototypes
that have been implemented to demonstrate a proof-of-concept. Section . con-
cludes the paper by summarising the results and discussing future work items.

. M R

e envisioned functionality of the LIWAS system requires some basic properties

of the system architecture. is section discusses the main requirements that have
been identified. e requirements have been derived directly from the way that the
LIWAS system is supposed to work, and from deployment and maintenance of the
LIWAS system.

Measurement collection is the process of getting measurements from the sensors to

a computation platform at an appropriate rate. e requirement is to do up to 
measurements per second which corresponds to one measurement per meter while
driving at  km/h.

Measurement processing is required to transform measurements into road classifi-

cations, i.e., determining whether the road is icy or covered with snow or water.
Measurements have physical characteristics such as surface reflection, temperature
and dew point, and are not directly linked to the road being slippery. e mea-
surements have to be combined into road classifications that must be computed in
real-time as measurements are received from the sensors.

Classification dissemination deals with sending classifications of road state to other

LIWAS units. A central feature of the LIWAS system is the ability to warn drivers
of icy conditions and therefore communication between LIWAS units must be sup-
ported. Furthermore, such warnings must be received in due time. is is a key
requirement to the communication infrastructure.

Scalability. e infrastructure is required to scale from a few LIWAS units to

thousands of LIWAS units in the total system. In general, the more LIWAS units
that are added to the network, the larger the geographical area for which road state
information is available.

Availability. As a traffic warning system, it is important that the system is contin-

uously available and provide up-to-date information to the users. e probability
that a user (driver) misses a warning increases when the downtime of the system
increases or up-to-date information is not provided. Availability also refers to the
dissemination of classifications even in situations in which the distribution of ve-


Chapter . An Infrastructure for a Traffic Warning System

hicles is sparse, i.e., when there are few LIWAS units in operation. Supporting a
gradual deployment of LIWAS units is important in achieving availability.

Modifiability. e LIWAS system is a large and complex distributed system in

which it is arguably impossible to produce a system that will not need modifications
after it has been deployed. Since high availability is important, it is essential to
support modifiability, and desirable to support this at runtime, i.e., be able to update
the LIWAS units while they are running. e updates must be distributed via the
communication infrastructure.

. S A

is section describes the architecture of the LIWAS system that has been designed
to support the requirements discussed in Section .. Figure . shows a Unified
Modelling Language (UML) deployment diagram for the abstract LIWAS system
architecture. is architecture is an instantiation of the more general Ex Hoc in-
frastructure developed in the LIWAS project []. It consists of three types of
nodes.

Wireless inter-unit link

:Unit Backend: Server

:Communication System

:Management :Dissemination

backend-link
:Communication :Classification

:Java VM
:DOM
WLAN

web service

:OSVM
External Service

sensor link
Legend: UML
dependency
:Sensor System Computational
Node Component Object communication link

Figure .: Deployment diagram for the abstract LIWAS system architecture.

Units that may be either stationary or mobile. ese Units contain a Sensor System
that senses the environment and a Communication System that handles measure-
ments from the Sensor System. e Classification object is responsible for taking
measurements from DOM (Domain Object Model) and compute road classifica-
tions (e.g., wet, slippery, dry). e Communication object is responsible for com-
munication with other Units and with the Backend. e DOM is responsible for
maintaining a current view of the environment of the vehicle in terms of, e.g., recent
sensor measurements and recent classifications. e DOM data is used by both the


 .. System Architecture

Classification and Communication objects. OSVM is the platform on which the

objects in the Units are implemented.

A backend server that handles Management of Units and Dissemination of classifi-

cations and updates via the back-end infrastructure. Depending on whether Units
are mobile or stationary, their communication to the backend may use different
network technologies.

External services that use data from the Backend Server through a web service
interface. An External Service may, e.g., be a web server providing road state clas-
sifications based on information received from the LIWAS units.
e architecture relies on the three kinds of communication links. e sensor
link is a short-range link used to send the measurements from the Sensor System
to the Communication System. e wireless inter-unit link is a medium-range link
used for wireless communication between LIWAS units. e backend-link is long-
range link used for communication with the back-end infrastructure.

In the following we briefly discuss the system architecture in the context of the
main requirements identified in Section ..

Measurement and collection and processing A central component of the Commu-

nication System is the OSVM platform []. e OSVM platform consists of
a small virtual machine running Smalltalk []. e virtual machine runs in 
KB, and combined with libraries and system software written in Smalltalk it runs
in less than  KB. Experiments have shown that the Communication System
is able to handle the soft real-time requirements on measurement collection and
processing when running on an embedded platform based on ARM and Intel 
processors. A critical part in the Communication System is the classification algo-
rithm. It is currently implemented using standard linear discrimination and pattern
recognition. is means that classification can be done in constant time. A further
presentation of the classification algorithm is beyond the scope of this paper.

Modifiability e LIWAS system supports modifiability through the use of the

OSVM platform and the Management part of the Backend. e OSVM sys-
tem supports modifiability that makes it possible to change Smalltalk classes in
a running and deployed system. Since most of the OSVM platform is written in
Smalltalk (including the scheduler and device drivers) it is possible to update most
aspects of the system. e ability to do runtime software updates gives rise to a
host of possibilities. In [], three basic kinds of updates are described: corrective
- malfunctioning code is corrected, perfective - functionality is enhanced, adaptive
- the code is adapted to run in a changed environment. Updates of all three types


Chapter . An Infrastructure for a Traffic Warning System

are important in the LIWAS system. We will give examples of perfective updates
later.

Scalability e communication from mobile units to the Backend Server does

not contain all road state classifications, but is subject to a policy that determines
when classifications are to be sent. For the communication between units using the
wireless inter-unit link, we distinguish between data dissemination and management
distribution. e concept of management distribution covers distribution of data
which is not directly linked to the sensors. An example of this is program updates.
e data dissemination is time-critical and most frequent and thus most important
for achieving scalability. With our current communication protocol, the payload of
one message is able to fit within one User Datagram Protocol (UDP) packet.

Availability e Sensor System is designed to do minimal processing and thus

be highly robust and available. e majority of processing is done in the Com-
munication System, which being built on OSVM is running on a small and stable
core.

. P : B W I-U C

e purpose of the first prototype was to experiment with the practical use of WiFi
in the form of IEEE .b ad-hoc mode for implementing the wireless inter-unit
communication between vehicles, and between vehicles and road-signs.
e LIWAS units were represented by laptops running Linux Redhat  and
each equipped with a D-Link Air DWL- Wireless PCMCIA Card configured
to operate in ad-hoc mode. Operating the wireless network card in ad-hoc mode
means that direct communication between the network cards is possible without
the use of base stations. e first prototype did not involve the OSVM platform
since the focus was on data link-layer communication and obtaining some practical
experiences concerning the amount of data that can be exchanged between vehicles
and road-signs at different speeds.
Figure . provides an overview of the physical environment in which the ex-
periments were conducted. e experiments were done on a high-way consisting
of two separated lanes A and B. e distance between the two lanes was approxi-
mately  meters. A stationary LIWAS unit was represented by a laptop on a bridge
crossing the highway. e mobile LIWAS units (M and M) were represented by
cars with a laptop inside, passing the bridge at different speeds.
e communication protocol used in the prototype periodically broadcasted an
UDP packet with a payload of  bytes. In the experiments  ms were used as
the period for packet transmission. Since the purpose of the prototype was to in-
vestigate the amount of information that can be exchanged between the LIWAS
units using .b ad-hoc communication, the specific payload was not of impor-
tance and simply contained a sequence number identifying the packet. e LIWAS


 .. Prototype : Basic Wireless Inter-Unit Communication

Bridge

Lane A M2

S
M1 Lane B

Figure .: Environment for prototype  experiments.

units wrote statistics on the packets received to a log file which could then be used
to determine the number of packets received by the units and the time the packets
were received.

.. Stationary-Mobile Communication

e first set of experiments considered the communication between a stationary LI-

WAS unit (i.e., a road sign) and a mobile LIWAS unit. Figure . show the results
of one of the experiments. e figure shows the number packets received by the sta-
tionary and mobile unit as a function of time when the mobile unit approaches the
bridge at a speed of  km/h. e same setup was also investigated when the mo-
bile units approached the road-sign at speeds of  km/h and  km/h yielding
a similar picture as shown in Fig. .. ree experiments were conducted for each
vehicle speed. Time  corresponds to the time when the first packet was received
by one of the units. e figure also depicts the theoretical maximum of received
packets given the fixed periodic transmission rate of  packet per  ms. It can be
seen in Fig. . that the mobile unit received a total of approximately  packets
in  seconds. e stationary unit received approximately  packets in  sec-
onds. e  seconds is the time that the mobile unit is within transmission range
of the stationary unit (i.e., capable of receiving packets), whereas the  seconds is
the time that the stationary unit is within transmission range of the mobile unit.
Table . summarises the results on the received packets for the three different
vehicle speeds ( km/h,  km/h, and  km/h). e Received columns give the
total number of packets received by the Stationary and the Mobile unit, respectively.
e figure in parentheses after the number of packets received gives the percentage
of received packets compared to the theoretical maximum at  packet/ ms. e
Time columns give the time interval in seconds where packets were received by the
unit. It can be seen that (in general) the number of packets exchanged decreases
as the speed increases. is is expected, since the units will be within transmission
range of each other for a shorter period of time. ere are, however, exceptions to


Chapter . An Infrastructure for a Traffic Warning System

Mobile unit
1200 Stationary unit
Maximum

1000

800

Packets
600

400

200

0
0 5000 10000 15000 20000 25000
Time (msecs)

Figure .: Stationary - Mobile Communication at  km/h.

Speed Stationary unit Mobile unit

Exp km/h Received Time Received Time
   (.) .  (.) .
   (.) .  (.) .
   (.) .  (.) .
   (.) .  (.) .
   (.) .  (.) .
   (.) .  (.) .
   (.) .  (.) .
   (.) .  (.) .
   (.) .  (.) .

Table .: Stationary-mobile communication.

this general pattern. For instance in the third experiment with  km/h, only 
packets were received by the mobile unit which is the lowest number of packets
received by the mobile unit in all experiments. e cause of these variations is
most likely the presence of other vehicles and objects on the road which affects
the propagation of the radio signals, in particular in cases where they obstruct the
line-of-sight between the mobile unit and the stationary unit. e difference in the
amount of time that packets are received by the two units demonstrates that the
communication links are asymmetric.

.. Inter-Vehicle Communication

e second set of experiments investigated was inter-vehicle communication. In

these experiments, two cars (mobile unit  and ) were approaching each other
from opposite directions on the highway (see Fig. .). Figure . shows the total
number of packets received by the two LIWAS units at a speed of  km/h. It


 .. Prototype : Basic Wireless Inter-Unit Communication

500
Mobile unit 1
Mobile unit 2
450 Maximum

400

350

300
Packets

250

200

150

100

50

0
0 1000 2000 3000 4000 5000 6000
Time (msecs)

Figure .: Mobile - Mobile Communication at  km/h.

Mobile unit  Mobile unit 

Exp Speed Received Time Speed Received Time
   (.) .   (.) .
   (.) .   (.) .
   (.) .   (.) .
   (.) .   (.) .
   (.) .   (.) .
   (.) .   (.) .
   (.) .   (.) .
   (.) .   (.) .
   (.) .   (.) .

Table .: Mobile-mobile communication.

can be seen that the time in which packets can be exchanged is much smaller than
in the previous experiments with stationary-mobile communication. e reason is
that the vehicles are approaching each other from opposite directions which means
that a speed of  km/h for each vehicle corresponds to a relative speed of 
km/h. e behaviour for speeds of  km/h and  km/h were similar to what
is depicted in Fig. ..
Table . summarises the statistics on the received packets at different vehicle
speeds. Because of other traffic on the highway, it was not possible for mobile unit
 to drive at the intended speed in all the experiments. e results in the table show
again that in general, the number of packets exchanged decreases when the speed
is increased. e worst-case occurred in the third experiment at  km/h where
mobile unit  received only  packets and mobile unit  received only  packets.
e development of prototype  and the associated experiments demonstrated
that .b ad-hoc communication could be used as a basis for communication
between vehicles, and between vehicles and road-signs. e number of packets


Chapter . An Infrastructure for a Traffic Warning System

exchanged was more than sufficient to exchange information about the state of
road as this requires only a few bytes of information. e experiments showed that
it is fair to assume that - packets can be exchanged between vehicles and
road-signs when they are within transmission range.
Furthermorethe experiments demonstrated that physical phenomena such as
other vehicles on the road have a much higher impact on the amount of data ex-
changed than the speed of the mobile units.
In [] the authors experiments with IEEE .b in vehicular environments
in different propagation and mobility scenarios. Data are logged using GPS to
determine distance between nodes and relative and absolute velocity. It is concluded
that the relative and absolute velocities of the nodes affect the throughput. e data
supporting this conclusion is however for varying distances. It can therefore, in our
oppinion, not be determined that the effect on the throughput is due to velocity or
distance.
e authors of [] also experiment with .b in vehicular environments,
but here the focus is on infrastructure mode and not on ad-hoc mode. General
conclusions on propagation of radio signals from moving nodes are made. It is
concluded that effects due to shadowing dramatically affects the performance.

. P : T OSVM P  A L F

e purpose of the second prototype was to introduce the OSVM platform and
implement several of the application level features of LIWAS: classification of mea-
surements, dissemination of classifications, and communication and application of
software updates. e source code implementing the second prototype was written
in Smalltalk, compiled to bytecode and executed on the OSVM virtual machine.
e second prototype was based on the same hardware platform as prototype .

.. e Software Update Protocol

Software updates on the OSVM platform consists of a set of bytecode arrays -

one for each Smalltalk class to be updated. e total size of an update is generally
larger than the Maximum Transfer Unit (MTU) of the WiFi medium and therefore
a simple update protocol was designed for transmitting software updates.
e update protocol is designed so that it enables one-to-many reliable commu-
nication and can be classified as a variant of reliable broadcast. An update of N bytes
is sent in k fragments each of consisting of n bytes such that n(k − 1) < N ≤ nk .
e fragments are sent in sequence repeatedly so when the sender has sent frag-
ments 1 to k it starts over again. No acknowledgements are included in the pro-
tocol. Each packet contains an update identifier, the total size N , payload size,
a sequence number, and a fragment of the update (payload). Including N in each
packet makes it possible for the receiver to reserve buffer space for the whole update
upon reception of the first fragment, and to determine when the complete update
has been received. When a receiver has successfully received an update, it applies


 .. Prototype : e OSVM Platform and Application Level Features

180
Feasible update size

160

140

120
Needed packets

100

80

60

40

20

0
0 20 40 60 80 100
Number of fragments (k)

Figure .: Relative speed of  km/h.

the update. e update can optionally include code that returns an acknowledge-
ment to the sender. e update protocol has the property that if a fragment is lost,
the receiver has to wait until it is transmitted again. is retransmitted fragment
might again be lost and so on.
We would like to investigate how large an update it is feasible to transmit in
different scenarios. To get a first realistic measure of these figures we used commu-
nication traces from the experiments performed with prototype . In the experi-
ments with prototype , each UDP packet contained a sequence number that made
it possible to identify precisely which packets were lost. For each of the traces we
have computed how many UDP packets it takes to transmit an update consisting
of k fragments. Each UDP packet contains a fragment of  bytes and  bytes
of control information. is makes each UDP packet carry a payload of  bytes.
Figure . shows the required number of packets for successful transmission of an
update as a function of the number of fragments (k ) in the update for one of the
traces. It can be seen that the function is discontinuous indicating that for some
values of k it was not possible to successfully transmit an update consisting of k
fragments. ere are a number of peaks in the graphs. ey correspond to cases
where packets with the same sequence number are repeatedly lost. e figure of
interest is the largest value of k where the update is successfully received and where
it is successfully received for all smaller values of k . is point is indicated by the
+ in Figure ., and is referred to as the feasible update size.
We have computed the corresponding feasible update size for each of the com-
munication traces obtained with prototype  assuming that each packet carries a
fragment size of  bytes. Table . shows the minimum, average, and maximum
feasible update size for all communication traces. e results are listed according to
the relative speed in km/h between the two LIWAS units - no distinction is made
between mobile-mobile and mobile-stationary experiments. A general tendency is
that the feasible update size decreases as the relative speed increases.


Chapter . An Infrastructure for a Traffic Warning System

Relative Minimum Average Maximum

Speed bytes bytes bytes
 , , ,
 , , ,
 , , ,
 , , ,
 , , ,
 , , ,
Table .: Feasible update sizes in different scenarios.

e extent to which these figures are adequate is of course highly dependent

on what needs to be updated. To investigate this issue we designed two updates
each representing different types of updates. Both can be classified as perfective
updates as they enhance the functionality of the system. e first update was made
to demonstrate that is is possible to use updates to diagnose the infrastructure.
When executed it measures the amount of free memory and broadcasts the result
for a fixed period. e amount of free memory is an indicator of how loaded the
unit is. e other update displays a text on the display of the LIWAS unit when
executed. is could be used by a stationary unit to notify all passing units about an
accident ahead or for commercial purposes. e size of the heap measuring code
is  bytes and the size of the message displaying code is  bytes. Since the
results obtained with the traces from prototype  show that in all scenarios it was
possible to transmit an update of size ,, it can be concluded that the available
bandwidth is more than sufficient for representative updates.

.. Classification

Prior to the development of the second prototype an initial version of the Sensor
System and a classification algorithm were developed and tested separately. To
estimate the load placed on the LIWAS unit by the classification and communi-
cation parts of the system architecture in conjunction, the implementation of the
classification algorithm was included in prototype . Since the Sensor System was
not available for integration in the second prototype, randomly generated measure-
ments were used to emulate the Sensor System in the prototype.

.. Communication

e communication part of the system architecture was implemented in prototype

 using broadcast of UDP packets and was responsible for sending and receiving
classifications and software updates.
A set of experiments was conducted to evaluate the prototype. For compara-


 .. Prototype : Initial Deployment

Mobile unit
1200 Stationary unit
Maximum

1000

800
Packets

600

400

200

0
0 5000 10000 15000 20000 25000
Time (msecs)

Figure .: Stationary - Mobile at  km/h.

bility, the experiments performed with the first prototype were repeated with the
second prototype. e LIWAS units were broadcasting and receiving road classifi-
cations, each classification in a single UDP packet. As in the experiments with the
first prototype, packets were transmitted every  ms. Along with this, one of the
LIWAS units was continuously transmitting a software update, each fragment in
an UDP packet. e other unit listened for the update and applied it.
Figure . shows the number of classifications received by a unit as a function
of time in milliseconds in one of the experiments. When comparing the results
with the results from the experiments performed on prototype  (see Figure .),
no significant change is observed. e general picture is that the values from the
experiments performed on prototype  are slightly lower but that can be attributed
to the fact that both classifications and software updates were transmitted.
e results from the experiments with prototype  was confirmed and it can be
concluded that using OSVM as the underlying platform for the units of the LIWAS
system is feasible. In each experiment the software update was successfully sent,
received, and applied. is demonstrates the feasibility of software updates, and
confirms the initial off-line experiments with the update protocol. Furthermore, the
second prototype demonstrates that the Communication and Classification parts
of the system architecture works and can operate jointly with the software update
mechanism.

. P : I D

e purpose of the third prototype was to switch from laptops to a more compact
hardware platform suited for being mounted inside vehicles, to integrate the actual
sensor system, and to add the backend communication link. Furthermore, the aim
was to make an initial deployment of the resulting prototype inside a set of trucks


Chapter . An Infrastructure for a Traffic Warning System

that would be running in continuous operation for several months.

e LIWAS unit in the third prototype was based on a Compaq iPAQ running
Familiar Linux ... Compared to the laptops used in earlier prototypes, the iPAQ
has a size that enables it to be mounted inside a vehicle. Furthermore, since various
GPS based navigation systems already exist for the iPAQ platform, the platform
is not new to the vehicular environment and accessories such as a mounting kits
and power supplies are standard equipment. e iPAQ was connected to the actual
sensor system by means of an EIA- connection. e backend communication
link was provided by a GSM mobile handset connected to the iPAQ using Blue-
tooth. e iPAQ used has built-in WiFi communication capabilities constituting
the wireless inter-unit link.
e software developed for the prototype  units was moved unmodified to the
Linux/iPAQ platform since the OSVM virtual machine is also available for this
architecture. e only exception to this was that instead of randomly generated
measurements, the prototype  unit was receiving measurements from the actual
sensor system.
An addition to the prototype  software was the implementation of the back-
end link using SMS messages. SMS is currently the only reliable communication
link that provides coverage for most of Europe. e bandwidth is severely limited
implying that not all classifications can be sent to the backend server. We chose
to send classifications periodically, but the sending of SMSs will be subject to a
more subtle policy in future versions. e backend server was implemented using
a Windows PC connected to a Nokia  GSM Connectivity Terminal and set up
to run a Java program receiving SMSs from the LIWAS unit.
A graphical user interface was developed to warn the driver of hazardous road
conditions and to enable the driver to provide feedback to the system. In situations
where the driver disagrees with the road classification provided by the system, it
was possible to press a button having the effect that the current measurements, the
computed classification, the driver’s classification, and a timestamp was logged to
a file on the iPAQ for later evaluation of the classification algorithm. Figure .
shows the user interface which is based on a traffic light metaphor where red indi-
cates slippery road conditions.
e prototype  unit was deployed in the first truck in January  and will
run in continuous operation for several months. e truck is owned by a truck com-
pany that operates routes in northern Scandinavia, an area in which environmental
conditions are sufficiently diverse to provide a good testbed for the LIWAS system.
Since only one unit is deployed at the time of writing the disseminating of
classifications using the wireless inter-unit link is not currently used. However in
the near future two copies of the prototype  LIWAS unit will be manufactured
and installed in trucks operated by the same company. is will enable inter-vehicle
classification interchange between the trucks when driving in convoy.
In conclusion, the third prototype implements all parts of the system architec-
ture except the external service part and thus provides a proof-of-concept validating
the system architecture.


 .. Conclusion

Figure .: Platform and user interface for prototype .

. C

In this paper we have presented an infrastructure for the LIWAS traffic warning
system. We have identified important requirements and proposed a solution. Al-
though presented in the LIWAS context, the infrastructure applies to other traffic
information systems as well. e main features of the infrastructure is the combi-
nation of different communication technologies enabling communication in dense
and sparse networks, and the support for modifiability of the software while the
system is in operation. is in turn means that the infrastructure supports gradual
deployment.
e system architecture on which the infrastructure is based has been validated
by the development of three prototypes covering the key aspects of architecture. e
development of the prototypes has led to the initial deployment of a first LIWAS
unit that will be duplicated in three copies and evaluated by continuous operation
in northern Scandinavia over the next months.
During the prototyping process a lot of experiences were gathered that applies
to other practitioners in the field of ad-hoc networking and embedded systems.
ey can roughly be divided into two categories: validation experiences and plat-
form experiences.
e prototypes developed validates the basic functionality of the architecture,
but has limitations in terms of evaluating the scalability. We are therefore currently
investigating the use of simulation and emulation models for further evaluation of
the infrastructure. e use of simulation models and emulation makes it possible
to investigate scenarios with hundreds of LIWAS units which is not feasible with
the prototypes presented in this paper. Simulation and emulation, however, rely on
making abstractions, e.g., with respect to physical characteristics of communication
and in our view, a combination of prototypes, simulation, and emulation is required
to conduct a proper evaluation of the class of systems considered in this paper.
Several hardware platforms were considered during the project including lap-


Chapter . An Infrastructure for a Traffic Warning System

tops, the Intrinsic CerfCube, and the Compaq iPAQ. In our view, the iPAQ plat-
form is currently the best prototyping platform as it is a compact device, provides a
display, and has good I/O capabilities in terms of a serial interface, Bluetooth, and
WiFi.
e work on the LIWAS system currently continues based on the experiences
and continuous feedback obtained from the deployment of the third prototype.
Some main areas for future work are the communication protocols used for dissem-
ination of classification and software updates, in particular when to use the backend
system and when to use direct wireless communication between the units. For the
dissemination of classification one key aspect is how to ensure that the units receive
up-to-date information in due time. An important aspect of software updates is
management and version control.

. A

We would like to thank Toke Eskildsen and Rolf Ehrenreich orup for their help
in developing the LIWAS prototypes and LIWAS ApS for their cooperaton. e
work described in this paper has been supported by ISIS Katrinebjerg Software and
the Danish Natural Science Research Council.


C Ո 

S  P E  T

Z D P  V A-
N
Jeppe Brønsted and Lars Michael Kristensen

Abstract

Vehicular ad-hoc networks is an emerging research area focussing on com-

munication infrastructures that support vehicles and road-signs in distribut-
ing road-state data such as information about hazardous road conditions ahead,
approaching emergency vehicles, and traffic delays. Vehicular ad-hoc net-
works combine the areas of sensor networks (data acquisition) with mobile
ad-hoc networks (highly dynamic topology and lack of pre-existing infras-
tructure). One of the main challenges of vehicular ad-hoc networks is the
data dissemination protocols capable of distributing road-state information
among vehicles. is paper presents two candidates for dissemination proto-
cols: a zone flooding protocol and a zone diffusion protocol. e two proto-
cols combine ideas from sensor networks and geocasting to ensure that data is
aggregated and distributed only in a bounded geographical area. We present
a comparative simulation study of the two protocols evaluating their rela-
tive performance using conventional metrics (such as network load) as well
as application-specific metrics (such as awareness). e simulation study has
been conducted using the Network Simulator  (NS-) and has highlighted
key properties of the two protocols that can be used as a basis for selecting the
most appropriate protocol.

. I

Ad-hoc wireless communication among vehicles enables a multitude of applications

ranging from improved traffic safety to road maintenance and high-speed tolling,
and promises to significantly change the transportation sector in near future [,
]. e new applications rely on the acquisition and processing of sensor data

Published as:
Jeppe Brønsted and Lars Michael Kristensen. Specification and Performance Evaluation of Two Zone
Dissemination Protocols for Vehicular Ad-hoc Networks. In Proceedings of the th Annual Simulation
Symposium, pages –, Los Alamitos, CA, USA, . IEEE Computer Society. Acceptance rate:



Chapter . Two Zone Dissemination Protocols for Vehicular Ad-hoc Networks

and the dissemination of data via infrastructure-less wireless communication. e

area of vehicular ad-hoc networks thereby combines the areas of sensor networks
and ad-hoc communication.
A main challenge of vehicular ad-hoc networks is the protocols for dissemina-
tion of sensor data among vehicles. Information about a phenomenon observed by
the sensors must reliably reach the vehicles that may be affected by this phenomenon
in due time, so that drivers can react without creating dangerous situations. Fur-
thermore, the protocols must be able to handle high vehicle density and mobility
and at the same time be robust to sparse network connectivity.
Previous work [] has shown that the performance of advanced dissemination
protocols [, ] is highly sensitive to the parameters chosen and to the traffic
scenarios. ese advanced dissemination protocols typically improve performance
by exploiting properties of the environment that may not always be available. e
effect is that these protocols have good performance under some conditions, but
poor performance under other conditions. One way to avoid this is reduce the
assumptions about the environment and use light-weight protocols (both in terms
of protocol complexity, parameters, and internal state) which provide reasonable
performance in all traffic scenarios. ese light-weight protocols will never reach
the high performance of the advanced protocols when these operate under optimal
conditions, but will perform reasonably under most conditions arising in practise.
Furthermore, light-weight protocols typically use less computational resources and
are easier to implement.
e work presented in this paper has been developed in the context of the LI-
WAS research project[]. e LIfe WArning System (LIWAS) is a traffic warn-
ing system for informing drivers about hazardous driving conditions such as ice,
water, and snow on the road being approached. LIWAS units are embedded sys-
tems with sensors capable of measuring a wide range of physical phenomena such
as light reflection, air temperature, and dew point. LIWAS units are mounted on
vehicles and alongside roads to detect the condition of the road. e sensed data is
combined into road classifications and distributed to other LIWAS units to provide
information to drivers. It is not only information about where a road is icy that is
distributed, but also information about where the road is not icy. A driver can thus
be certain about whether the road ahead is safe before initiating an overtaking.
e communication infrastructure supporting the LIWAS system can be re-
alized in many ways ranging from a centralized architecture based on, e.g., GSM
or GPRS networks combined with Web servers [] to a decentralized architec-
ture based on ad-hoc networking and multi-hop communication between vehicles.
e two architectures have their pros and cons. e centralised architecture has
an advantage in coverage, but a potential problem with scalability. e decentral-
ized architecture has an advantage in scalability, but may have a potential problem
when the density of the vehicles equipped with LIWAS units is low. In this paper
we focus on protocols suited for the decentralised architecture.
e contribution of this paper is twofold. e first contribution is the speci-
fication of two protocols for data dissemination in vehicular ad-hoc networks. A


 .. Related Work

Zone Flooding (ZF) protocol and a Zone Diffusion (ZD) protocol. ey are both
designed to be light-weight protocols, robust to varying network density and mobil-
ity. e ZF protocol is a variant of flooding and constitutes a very simple protocol
while the ZD protocol exploits properties of the data to optimize data dissemina-
tion by means of aggregation. Both protocols can be used for the LIWAS system,
but also for other traffic information systems dealing with information about the
road and/or vehicles.
e second contribution is a comparative simulation study evaluating the pro-
tocols through simulation of various mobility scenarios. e comparison is done in
terms of conventional metrics such as network load and through application specific
metrics that expose properties relevant to applications using the data dissemination
protocols. e simulations have been conducted using the network simulator NS-
[].
e rest of the paper is structured as follows. Section . provides a brief sur-
vey and comparison of related work. Section . contains the specifications of the
two zone dissemination protocols. Section . presents the simulation model and
defines the performance metrics. Section . presents the evaluation results for the
two protocols. Finally, in section . we sum up the conclusions and discuss future
work.

. R W

Several protocols for data dissemination in vehicular ad-hoc networks can be found
in the literature. ey can roughly be divided into three categories: unicast, flood-
ing, and diffusion.
Traditional ad-hoc network routing protocols [] or position based routing
protocols [, ] can be used to establish general unicast communication in a
vehicular ad-hoc network. A service discovery mechanism is then required to let
nodes know where to get the needed information [, ]. ere is, however,
an overhead in maintaining the service discovery mechanism, neighbour lists, and
routing tables that introduces latency and diminished network capacity making this
method infeasible for most safety critical applications.
e other two methods (flooding and diffusion) rely on the observation that
the importance of sensed information about a particular location decreases with
the distance to that location. Data therefore only needs to be disseminated in the
vicinity of its origin. is is the case for most safety applications, but not for e.g.
infotainment [] or environmental applications, where all data comes from or is
collected at a central location.
Flooding can be used to disseminate data in a certain area which can be de-
termined in different ways. e work presented in [] and [] uses hop-count
to limit forwarding of packets whereas in [] the area is implicitly defined by an
application specific interest rate function. Before a node forwards a received packet
it uses the interest rate function to determine whether the amount of interest its
neighbours have in the packet is above a certain threshold. Geocasting[] assumes


Chapter . Two Zone Dissemination Protocols for Vehicular Ad-hoc Networks

that nodes can determine their geographical location (e.g. using a GPS device[])
and stop forwarding when packets leave a predetermined geographical area. is
method is used in our Zone Flooding protocol described in the next section.
A general problem with flooding protocols is that they tend to have a lot of re-
dundant transmissions which causes several problems []. is can be remedied
by letting the nodes attempt to estimate whether a potential retransmission will
be redundant [, ] or by lowering the transmission power []. In the Zone
Flooding protocol we limit the amount of redundant transmissions by ensuring that
a node transmits a packet at most once. More advanced mechanisms have been left
out to keep the protocol light-weight.
Another method for dissemination of information in the neighbourhood of a
source is to use a technique known as diffusion [, ]. Each node maintains a
view of its surroundings and periodically broadcasts that view. Each time a view
is received that view is aggregated with the local one. We use this approach in the
Zone Diffusion protocol. In [] the authors compare different aggregation algo-
rithms using application specific metrics similar to ours, but do not try to estimate
the relationship between network load and protocol performance as we do. In []
the amount of sensed data is small compared to our scenarios making frugal use of
network capacity less important.

. Z D P

As pointed out in the previous section both our protocols rely on the observation
that the relevance of information about the road at some location decreases with
the distance to that location.

.. e Zone Flooding Protocol

e Zone Flooding protocol is a variant of basic flooding with three modifications

to limit the dissemination of packets. It can be seen as a special case of flooding-
based geocasting [] in the sense that the source is located inside the geocast zone.
Traditionally the problem with flooding-based protocols [] is that they congest
the network with hordes of packets. To alleviate this problem we use several tech-
niques to limit the forwarding of packets.
A hop-count is embedded in every packet and decremented when the packet is
forwarded. When the hop-count reaches zero the packet is discarded. is has the
effect that the packet only reaches nodes in the part of the network that is within a
certain hop-count radius from the originator of the packet. It is, however, possible
that nodes near the originator forward a packet multiple times.
To avoid that a node forwards a packet more than once, we use sequence lists as
in [, ] to detect whether a packet has been received before. Packets should
only be forwarded upon the first reception. Each node maintains a sequence number
that is incremented every time a new packet is created by the node. e sequence
number is embedded in every packet originating from the node. Every node also


 .. Zone Dissemination Protocols

maintains a sequence list, mapping other nodes to their last known sequence num-
ber. When a packet is received the sequence number for the originator is updated.
If the sequence number contained in the packet is the same or lower than the se-
quence number in the sequence list, the packet has been received before and should
thus not be forwarded. If the sequence number in the packet is strictly lower than
the one in the sequence list, the packet being received must have been overtaken. If,
however, the sequence number in the packet is greater than the sequence number
in the sequence list it is known that the packet is being received for the first time
and therefore should be forwarded. e amount of memory used by this mecha-
nism can be limited by for each entry in the sequence list noting the time at which
the last packet was received. When a packet is received multiple times it always
happens inside a short period of time. A copy of a packet can in practise only be
delayed shortly because when a packet is received by an intermediate node it is ei-
ther dropped or forwarded immediately. erefore, the sequence list can be cleaned
up periodically by removing the oldest entries.
To further limit the dissemination of packets the concept of a flooding zone is
introduced. In every packet a flooding zone is embedded specifying a geographic
destination area. In the current implementation of the protocol the flooding zone is
a rectangle, but other shapes are possible. When a node receives a packet it checks
(e.g. using a GPS device) whether its current position is inside the flooding zone
and discards the packet if that is not the case. e effect is that packets are only
delivered to nodes in a certain geographical area.
Figure . illustrates the operation of the Zone Flooding protocol. e white
source node broadcasts a packet that is forwarded by other nodes until it reaches a
node outside the flooding zone.

n e
Zo
i ng e
od ran
g
Flo
s ion
ns mi s
Tra
Source
Node
Transmission

Figure .: e Zone Flooding Protocol.

When limiting the forwarding of packets by using the flooding zone, the hop-
count limitation almost never gets effectuated because packets move out of the


Chapter . Two Zone Dissemination Protocols for Vehicular Ad-hoc Networks

flooding zone before they reach the hop-count limit. However, since nodes are
constantly moving, it is possible (albeit unlikely) that a packet would be forwarded
infinitely inside the zone provided that new nodes keep entering the zone at an
appropriate rate. Hop-count is therefore necessary to ensure correctness of the
protocol.
To summarise, the techniques described above limits the forwarding of packets
in three ways: No packets will reach nodes outside a certain hop-count radius from
the source, no packets will be forwarded more than once by each node, and no
packets will be forwarded by nodes outside the flooding zone.
e pseudo code for the Zone Flooding protocol can be found in algorithms ..
and .. and consists of two parts: _ and . e primitives
used are described in appendix .. _ is called when the system is
started and  is called every time a packet is received.

Algorithm ..: _(bcastInterval)

whiletrue

 classification ← _()



 pos ← _()



 zone ← _(pos)


seqNumber ← seqNumber + 1
do



packet ← _(classification, zone,



 seqNumber)



  (packet)


(bcastInterval)

Algorithm ..: (packet)

if packet.hopcount ≤ 0
then return
senderSeqNumber ← _(packet.sender)
if senderSeqNumber ≤ packet.seqNumber
then return
pos ← _()
if _(packet.zone, pos)
then return
_(packet.sender) ← packet.seqNumber
_(packet)
(packet)
return


 .. Zone Dissemination Protocols

.. e Zone Diffusion Protocol

e Zone Diffusion protocol is based on data aggregation which is a commonly used

technique in sensor networks [, , ]. Each node maintains an environment
representation (ER) representing the surrounding environment. e ER is updated
every time data arrives from the sensors. To disseminate data the ER is periodically
broadcasted. When an ER is received from another node it is aggregated with the
local ER by merging the information in the received ER that intersects with the area
covered by the local ER. Contrary to the Zone Flooding protocol, packets are never
forwarded. However, data about the local environment is indirectly forwarded to
other nodes since nodes periodically broadcasts their ER. e protocol is thus data-
centric as opposed to node-centric.
e ER is divided into cells of equal size each representing an atomic part of the
road. When a node receives information concerning a cell it already has information
about, the information is combined according to a data combination policy. One
policy could be to make a conservative estimate: if one node thinks the cell is dry
and another node classifies it as icy then the cell is to be considered icy. Other
policies are also possible. e actual choice of policy is, however, out of the scope of
this paper. In the implementation of the protocol we just store in each cell whether
the node has received information about that cell at all and so the protocol can
accommodate different policies depending on the specific application.
Figure . illustrates the operation of the Zone Diffusion protocol. Node A
sends it’s ER (depicted over it with a white car in it) to node B. Node B aggregates
the received ER with its own and thus learns about icy cells up ahead (marked with
“ICY” in bold font and capital letters).
e pseudo code for the Zone Diffusion protocol consists of three parts -
_, _, and  given in algorithms .., .., and ...
_ and _ is called when the system is started and -
 is called every time a packet is received. _ ensures that the ER
is continuously updated with road classifications from the sensor of the vehicle.
_ periodically broadcasts the ER and  handles incoming
ERs from other nodes, compares them with the local one, and combines the inter-
secting cells.

Algorithm ..: _()

whiletrue

classification ← _()
do c ← _()

ER.at(c) ←(ER.at(c), classification)


Chapter . Two Zone Dissemination Protocols for Vehicular Ad-hoc Networks

ER of node B
dry
dry
dry
dry

ICY
ICY

icy
ER of node A icy
B
icy
icy icy Local classification
ICY Received classification
A
Transmission
Node A
Node B

Figure .: e Zone Diffusion Protocol.

Algorithm ..: _(bcastInterval)

while{true
(ER)
do
(bcastInterval)

Algorithm ..: (packet)

commonCells ← _(ER, packet.ER)

{ c ∈ commonCells
for each
ER.at(c) ← (ER.at(c),
do
packet.ER.at(c))
return

. S M

To evaluate the protocols simulations have been conducted using the discrete event
simulator NS- []. e setup has been chosen so that it resembles a realistic
scenario for the LIWAS system - a straight section of a road,  meters long
and  meters wide, with vehicles moving in both directions. An overview of the


 .. Simulation Model

road scenario is shown in figure .. Ideally the scenario would just consist of two
lanes of vehicles entering the road section at the one end, and leaving it at the
other. However in NS- [] it is not possible to add or remove nodes once the
simulation has started. e ideal situation is obtained by turning the nodes around
and resetting them at both ends of the road section thereby making them behave
as new nodes.
ree classes of mobility, low velocity, medium velocity, and high velocity, each
corresponding to a typical traffic situation, were generated using the FreeWay tool
[]. For each class the node velocity changes randomly every  seconds according
to a Gaussian distribution having the effect that overtaking occurs once in a while.
e average node velocity and the velocity variance corresponding to the mobility
classes are listed in table ..
Each node is equipped with an IEEE . radio operating in broadcast mode
meaning that there is no channel reservation or acknowledgements. e transmis-
sion range is set to  meters and the bandwidth is  Mbit/s. We use the two-ray-
ground radio propagation model that comes with the NS- simulator.
Each simulation was run for  seconds of simulation time with , , and
 nodes. e two protocols were each simulated with broadcast intervals ranging
from . second to  seconds.
For the Zone Flooding protocol the size of the flooding zone is set to  by 
meters, the packet size is set to  bytes, and the hop-count is . As mentioned
in section .., the hop-count only ensures that packets will not travel infinitely
inside the flooding zone.
To enable comparison, the environment representation for the Zone Diffusion
protocol is set to have the same size as the flooding zone for the Zone Flooding pro-
tocol. Each cell in the environment representation is  by  meters and can hold
one of  values. e packet size is  bytes which is enough to hold information
about  cells and some additional auxiliary information. Table . provides an
overview of the simulation parameters.

.. Performance Metrics

e protocols have been evaluated both in terms of general protocol performance

metrics and in terms of application specific performance metrics.
To estimate the load placed on the network by the protocols we record the
amount of packets sent, received, and dropped. ese figures can be measured in
any network and thus enables comparison with protocols not related to traffic warn-
ing systems. It should be noted that for connection-oriented protocols the limita-
tion of dropped packets is typically handled by a MAC layer protocol. is implies
that direct comparison with connection-oriented protocols is not appropriate.
Besides the general metrics, the protocols have been evaluated according to
traffic warning system specific metrics. One goal of a traffic warning system is
to provide information to drivers about the road ahead and the two application
specific metrics investigated relate to this goal. First we will intuitively introduce


Chapter . Two Zone Dissemination Protocols for Vehicular Ad-hoc Networks

the concepts of Information Distance and Awareness Percentage, and then we will go
into further details about how the figures are determined.

Information Distance When a node learns something about a phenomenon fur-

ther up the road for the first time, the Information Distance is the distance
from the current position to that phenomenon.

Awareness Percentage For a particular location, the Awareness Percentage is the

fraction of nodes passing the location that had information about the location
before entering it.

To determine the Information Distance and the Awareness Percentage the sim-
ulation area is divided into  by  meters sectors. Every sector represents an atomic
part of the road; if a sensor somewhere inside the sector classifies the road as being
dry, the whole sector counts as being dry. is mimics the fact that if a sensor at
some point classifies the road as being dry, there is a high probability that the area
around the sensor will be dry as well.
Each time a node receives information about a sector that is has no previous
information about, the distance to that sector is the Information Distance. Only
information from sectors that the node will eventually enter is counted. In fig-
ure . information about sector  travels from node B to node A - either directly
by forwarding of packets in the Zone Flooding protocol or indirectly travelling
from one ER to the next in the Zone Diffusion protocol. When node A receives
the information, the distance from itself to sector  is the Information Distance. It
is assumed that the vehicles continuously measures the road implying that if a node
knows nothing about a sector immediately before entering it, it will learn something
about the sector the instance it enters it, implying that the Information Distance in
that situation is . e Information Distance is a measure of what warning distance
the driver of the vehicle can expect.
Let N be the set of nodes and S be the set of sectors. Because the simulation
area only consists of a straight section of a road a node n enters a sector s at most
once per simulation (recall that nodes are treated as new nodes when they turn at
the end of the road). is allows us to define the set of events ES ⊂ N × S so that
if node n enters sector s some time during the simulation S then (n, s) ∈ ES . e
point pS (n, s) is the position of node n when it first got information about sector
s in S - either receiving it in a packet or measuring it on the road. e function
pS is partially defined on the set N × S . For each event (n, s) ∈ ES we define the
Information Distance (ID) to be:
ID(n, s) = the shortest distance from pS (n, s)
to a point in s
e Awareness Percentage for a sector is the fraction of Information Distances
that are above  and is therefore only defined on the set of sectors that at some
time during the simulation contains a node. is means that if for a sector s :


 .. Performance Evaluation

{n | (n, s) ∈ ES } ̸= ∅, then we define the Awareness Percentage (AP) to be:

|{n | ID(n, s) > 0}|

AP (s) =
|{n | (n, s) ∈ ES }|

. P E

is section presents the performance evaluation of the protocols. e network

load, Awareness Percentage, and Information Distance of the protocols obtained
from the simulations are analysed and at the end we sum up conclusions concerning
the choice of protocol and parameters.

.. Network Load

Figure . shows packet statistics for the medium velocity mobility class with 
nodes. e number of packets sent, received, and dropped is shown as a function of
the number of broadcasts per second. For a single packet transmission the number
of received packets is the number of nodes in range that receives the packet whereas
the number of dropped packets is the number of nodes in range that due to signal
interference do not receive the packet. Each number displayed in the graph is a sum
over all transmissions in a simulation run. erefore, as can be seen in figure .,
the number of received packets is larger than the number of sent packets.
Both axes are scaled logarithmically implying that exponential functions are
shown as straight lines. e curves for packets sent, received and dropped for the
Zone Flooding protocol in the interval . to . broadcasts per second are straight
lines and therefore exponential functions. e base of the exponential functions is
one and therefore there is a linear relation between the number of broadcasts per
second and the number of packets sent, received, and dropped. An explanation of
this is that when the number of broadcasts per second is low the probability that
separate floodings will interfere is low. If a packet originating from a particular
flooding is dropped, it is most likely because it collides with another packet from
the same flooding. erefore, when the number of broadcasts per second increases
with a constant, the number of packets sent, received, and dropped increases pro-
portionally.
When the number of broadcasts per second exceeds . the Zone Flooding
protocol changes behaviour. Instead of being linear, the number of packets sent,
received, and dropped are approximately constant. is indicates that separate
floodings start to interfere. Even though more floodings are initiated the amount
of packets sent, received, and dropped remains almost constant. e interference
between separate floodings causes packets to be dropped and since a node has to
receive a packet before it can forward it, the number of nodes that sends pack-
ets originating from a particular flooding decreases. When fewer packets are sent,
fewer packets get dropped. As mentioned, the figures remain approximately con-
stant and that means that the average number of receivers per flooding decreases


Chapter . Two Zone Dissemination Protocols for Vehicular Ad-hoc Networks

approximately as fast the number of broadcasts per second increases. Hereby, the
protocol continues to have reasonable performance in spite of increased network
load and thus the effect resembles a crude form of congestion containment.
e Zone Diffusion protocol has no forwarding of packets and the number of
sent packets therefore only depends on the number of broadcasts per second. At
more than  broadcasts per second an increased number of dropped packets can
be observed indicating that the network has reached its maximum capacity. e
number of received packets decreases accordingly as a consequence.
With less than . broadcasts per second the number of packets sent, received,
and dropped for the Zone Flooding protocol are about a factor  larger than the
corresponding numbers for the Zone Diffusion protocol.
e packet statistics for the other mobility classes are similar although as the
node count increases the number of broadcasts per second for which the protocols
change behaviour decreases.
To summarise, the network load of the Zone Flooding protocol is linear in the
number of broadcasts per second until a certain threshold after which it is constant.
e network load of the Zone Diffusion protocol is linear for all broadcasts per
second and is a factor  less than the network load of the Zone Flooding protocol
when the number of broadcasts per second is low.

.. Awareness Percentage

As described in section .., the Awareness Percentage is associated with a sector,

and the sector for which the Awareness Percentage is considered in the rest of the
paper is the one in the centre of the road section. is sector is chosen because
flooding zones and ERs centred at this sector are fully contained in the simula-
tion area and thus the boundaries of the scenario have no effect on the Awareness
Percentage of this sector.
Figure . shows the Awareness Percentage for the two protocols as a function
of the number of broadcasts per second in the medium velocity mobility class with
 nodes.
When comparing the protocols’ Awareness Percentage for a given number of
broadcasts per second the Zone Flooding protocol outperforms the Zone Diffusion
protocol in most cases. As mentioned in the previous section the Zone Flooding
protocol sends about a factor  more packets than the Zone Diffusion protocol
when the network is not congested and therefore much more information can be
exchanged. In figure . it can be seen that the difference between the two protocols
is not always as significant as in figure ..
e Awareness Percentage that the protocols are able to achieve remain fairly
constant across most velocity classes and node densities, indicating that the proto-
cols are indeed robust to varying network density and mobility.
To investigate the advantage the Zone Flooding protocol has by using more
network capacity than the Zone Diffusion protocol, we investigate how the pro-
tocols perform in terms of Awareness Percentage versus number of packets sent


 .. Performance Evaluation

(instead of number of broadcasts per second). As seen in figure . the Zone Dif-
fusion protocol achieves good performance using significantly fewer packets than
the Zone Flooding protocol implying that there is a trade-off between high Aware-
ness Percentage and low network utilisation. Where high Awareness Percentage is
the primary goal, the Zone Flooding protocol should be used and when low net-
work utilisation is the goal the Zone Diffusion protocol is to be preferred.
ere are a few exceptions to this pattern as can be seen in figure .. In some
scenarios the Zone Diffusion protocol performs better for any number of packets
sent and thus no trade-off is present. e circumstances for which there is a trade-
off will be further discussed in section ...
In summary the Zone Flooding protocol uses more network capacity than the
Zone Diffusion protocol and thereby achieves better Awareness Percentage in most
cases. Zone Diffusion provides reasonable performance using less network capac-
ity and therefore there is a trade-off between Awareness Percentage and network
utilisation.

.. Information Distance

As was the case with the Awareness Percentage, the Information Distance is mea-
sured at the sector in the centre of the road section. e Information Distance for
the centre sector is specified as an average over all Information Distances for that
sector together with a confidence interval of . Assuming that the Informa-
tion Distances for the sector is distributed according to the Gaussian distribution,
the confidence interval is the range in which the actual average (as opposed to the
average of the point samples) is located with a probability of .
In figure . the average Information Distance is shown as a function of the
number of broadcasts per second for the low velocity mobility class with  nodes.
When comparing the average Information Distance obtained for the two protocols
at corresponding broadcasts per second two issues are evident. Firstly, with less
than one broadcasts per second the Zone Flooding protocol always achieves the
largest average information distance. As was the case with Awareness Percentage
this can be explained by the difference in sent packets. Secondly, when the number
of broadcasts per second is greater than one, the average Information Distance for
the Zone Flooding protocol decreases and the Zone Diffusion protocol becomes
superior. In section .. we saw that the number of nodes that receive a particu-
lar flooding decreases as the network gets congested. Combined with the fact that
the average Information Distance decreases as the network gets congested, we con-
clude that the nodes that receives a particular flooding in a congested network are
the nodes located closest to the origin of the flooding. In other words, when the
network gets congested the area of dissemination decreases in size.
Figure . and . shows the average Information Distance as a function of
the number of packets sent. When comparing the two protocols, the behaviour
from section .. is repeated. In some cases there is a trade-off between a large
information distance and low network utilisation while in most cases the Zone


Chapter . Two Zone Dissemination Protocols for Vehicular Ad-hoc Networks

Diffusion protocol outperforms the Zone Flooding protocol.

e Information Distance the protocols achieves remains fairly constant across
varying mobility classes and node densities, as was the case with the Awareness
Percentage,

.. Zone Flooding versus Zone Diffusion

In the previous sections we saw that in some cases there is a trade-off between
Awareness Percentage (and Information Distance) and network utilisation. e
Zone Flooding protocol achieves better performance than the Zone Diffusion pro-
tocol by using more network capacity. is section further explores in which sce-
narios the trade-off is present and what effect is has on the choice of protocol and
parameters. e following analysis considers high Awareness Percentage and low
network utilisation as goals. e analysis could easily be extended with the average
Information Distance as a goal parameter, but that has been left out due to space
limitations.
For a given scenario the problem of choosing a protocol and the number of
broadcasts per second such that the Awareness Percentage is maximised and the
number of sent packets is minimised can be categorised as a multi-objective opti-
misation problem. Each candidate solution consists of a pair (protocol, broadcasts
per second) with an affiliated Awareness Percentage and a number of sent packets.
To identify optimal solutions we use the concept of Pareto optimality [].
A solution is Pareto optimal if all other solutions that are better according to one
goal parameter is worse according to the other. Pareto optimality can be defined as
follows. Let s be a solution in the solution space S = {ZF, ZD} × {0.017, ..., 100}
 and P S(s) be the number of packets sent for s and AP (s) be the Awareness

Percentage for s. en a solution s ∈ S is Pareto optimal if ∀t ∈ S :

P S(t) < P S(s) ⇒ AP (t) < AP (s)
∧
AP (t) > AP (s) ⇒ P S(t) > P S(s)
For each scenario (node count, traffic speed) the set of solutions have been plot-
ted and the Pareto optimal solutions have been connected to form a Pareto curve.
Figure . shows the Pareto curve for the high velocity mobility class with 
nodes.
For each solution on the Pareto curve the corresponding protocol (ZD for Zone
Diffusion and ZF for Zone Flooding) and the number of broadcasts per second have
been noted. As an example it can be seen in figure . that the Zone Flooding
protocol with . broadcasts per second (ZD, .) is a Pareto optimal solution
for the high velocity mobility class with  nodes. Since AP(ZD, .) = . and
PS(ZD, .) =  we know that any solution that has more than . Awareness

¹Note that these values specifies the number of broadcasts per second while the values in table .
specifies the broadcast interval (seconds/broadcast).


 .. Performance Evaluation

Percentage sends more than  packets and any solution that sends less than 
packet has less than . Awareness Percentage.
For all mobility classes and nodes densities, it is the case that the Pareto curves
are monotone in the sense that the first half of the solutions (the one with the low-
est Awareness Percentage) includes the Zone Diffusion protocol and the other half
includes the Zone Flooding protocol. is means that if the Awareness Percentage
is the primary optimisation factor, then the Zone Flooding protocol should be used
whereas if low network load is the prime consideration the Zone Diffusion proto-
col should be used. However, it is usually not the case that one of the factors is
the primary. Usually, there are certain demands for Awareness and limitations on
network utilisation. To analyse this question in detail we have determined which
is the lowest Awareness requirement for which the Zone Flooding protocol would
be best, and similarly, which is the highest packets sent allowance for which the
Zone Diffusion protocol should be used. ese figures have been derived from the
Pareto curves and are listed in tables . and .. e node density is specified as
the average number of nodes per square meter in the scenarios. Since we are not
aware of theoretical results [] that allow us to characterise the broadcast capacity
of a mobile ad-hoc network, we use packets sent per square meter per second as a
measure of network load in table ..
As an example we see in table . that for the medium velocity mobility class
with a node density of . nodes/m2 the lowest Awareness Percentage require-
ment that would require us to choose the Zone Flooding protocol is . - if we
can settle with anything less the Zone Diffusion protocol should be used. Simi-
larly, we see in table . that if we in the medium velocity mobility class with .
nodes/m2 can settle with anything worse than . packets/m2 /sec sent the
Zone Flooding protocol should be used.
In a few cases (the slow scenarios with . and . nodes/m2 ) all the Pareto
optimal solutions include the Zone Diffusion protocol. In these cases the Zone
Flooding protocol should never be used. e corresponding entries in the tables
are marked with None and All. Table . indicates that the Awareness requirement
weakens (excluding the (fast, .) scenario) as the number of nodes increases.
When turning to the values in table . we again see that the packet requirement
weakens as node count increases.
A general conclusion is that the Zone Flooding protocol achieves the best
Awareness Percentage in all but a few cases, and the Zone Diffusion protocol sends
fewest packets. Furthermore the two goal functions - Awareness Percentage and
the number of packets sent - are inversely connected; optimising one lowers the
other and vice versa.
However, the Pareto graphs and the associated tables above allows us to con-
clude that if we can settle with an Awareness Percentage of . in worst case the
Zone Diffusion protocol should always - no matter what scenario - be used. A
similar conclusion cannot be drawn regarding the number of packets sent since, as
we saw before, sometimes the Zone Flooding protocol should never be used. If we
however, limit ourselves to only consider the medium and high velocity scenarios


Chapter . Two Zone Dissemination Protocols for Vehicular Ad-hoc Networks

we see that if we can accept that our protocol uses . packets/m2 /sec in worst
case then the Zone Flooding protocol should always be used.

. C  F W

In this paper we presented two light-weight protocols for data dissemination in

vehicular ad-hoc networks. e protocols only rely on the assumption that the
relevance of information about a particular phenomenon decreases with the distance
to that phenomenon and can therefore be used in typical vehicular ad-hoc network
applications.
To be able to evaluate the performance of the protocols we defined general
metrics that measure the load placed on the network by the protocols and domain
specific metrics that characterise how the data is disseminated. e domain specific
metrics have general applicability in the area of data dissemination protocols for
vehicular ad-hoc networks.
In the evaluation of the protocols, we concluded that the protocols are robust
to changes in network density and mobility. e Zone Flooding protocol generally
achieves better Awareness Percentage and Information Distance than the Zone
Diffusion protocol, but the Zone Diffusion protocol achieves reasonable perfor-
mance at a much lower network utilisation. In most mobility classes and node den-
sities, there is a trade-off between Awareness Percentage and network utilisation.
An analysis of the trade-off revealed that in most applications (where an Awareness
Percentage of . is acceptable) the Zone Diffusion protocols should be used.
By a crude form of congestion containment, the Zone Flooding protocol adap-
tively decreases the size of the area in which data is disseminated when the networks
gets congested. e Zone Diffusion protocol could be improved by adding conges-
tion control - either by limiting the dissemination area or by decreasing the number
of broadcasts per second.
As mentioned earlier, the relevance of information decreases with the distance
to the source. Some data dissemination protocols [, ] reflect this by letting
the information resolution decrease with the distance from the originating node.
e Zone Diffusion protocol could be extended with such a mechanism.
Based on the evaluation results presented in this paper, the Zone Diffusion
protocol will be implemented as part of the general communication infrastructure
for the LIWAS system[]. Once implemented, the conclusions of this paper can
be validated by real world experiments.

. A P


 .. Algorithm Primitives

m
00
20
th
le ng
ck
Tra

ge
ran
ion
m iss m
n s 0
Tra 10

10
m

Figure .: e simulation scenario.

Class Average velocity Variance

Low m/s(km/h) 
Medium m/s(km/h) 
High m/s(km/h) 

Table .: Mobility classes.

General parameters Zone Flooding parameters

MAC protocol IEEE . Flooding zone size  m ×  m
Propagation model Two ray ground Packet size  bytes
Transmission range  m Hop-count 
Simulation duration  secs Zone Diffusion parameters
Broadcast interval [. .. ] secs ER size  m ×  m
Node count , ,  Packet size  bytes
Cell size  ×  m

Table .: Simulation parameters.


Chapter . Two Zone Dissemination Protocols for Vehicular Ad-hoc Networks

B
r 4
cto
Se

ta nce
n dis 3
atio
r
cto
Se
orm
Inf

r 2
cto Node A
Se
A
Node B
r1 Information
cto
Se

Figure .: e Information Distance metric.

1e+008

1e+007

1e+006
Packets

100000

10000

Zone Diffusion- Sent

1000 Zone Diffusion - Received
Zone Diffusion - Dropped
Zone Flooding - Sent
Zone Flooding - Received
Zone Flooding - Dropped
100
0.01 0.1 1 10 100
Broadcasts per second

Figure .: Medium velocity,  nodes.


 .. Algorithm Primitives

100

95

90
Awareness Percentage

85

80

75

Zone Diffusion
Zone Flooding
70
0.01 0.1 1 10 100
Broadcasts per second

Figure .: Medium velocity,  nodes.


Chapter . Two Zone Dissemination Protocols for Vehicular Ad-hoc Networks

100

95

90

85
Awareness Percentage

80

75

70

65

60
Zone Diffusion
Zone Flooding
55
0.01 0.1 1 10 100
Broadcasts per second

Figure .: Low velocity,  nodes.


 .. Algorithm Primitives

100

90

80
Awareness Percentage

70

60

50

40

Zone Diffusion
Zone Flooding
30
100 1000 10000 100000 1e+006 1e+007
Packets Sent

Figure .: High velocity,  nodes.

100

95
Awareness Percentage

90

85

80

Zone Diffusion
Zone Flooding
75
100 1000 10000 100000 1e+006 1e+007
Packets Sent

Figure .: Low velocity,  nodes.


Chapter . Two Zone Dissemination Protocols for Vehicular Ad-hoc Networks

750

700

650

600
Information Distance

550

500

450

400

350

300
Zone Diffusion
Zone Flooding
250
0.01 0.1 1 10 100
Broadcasts per second

Figure .: Low velocity,  nodes.


 .. Algorithm Primitives

750

700

650

600
Information Distance

550

500

450

400

350

300
Zone Diffusion
Zone Flooding
250
100 1000 10000 100000 1e+006 1e+007
Packets Sent

Figure .: Low velocity,  nodes.

900

800

700
Information Distance

600

500

400

300

200

Zone Diffusion
Zone Flooding
100
100 1000 10000 100000 1e+006 1e+007
Packets Sent

Figure .: High velocity,  nodes.


Chapter . Two Zone Dissemination Protocols for Vehicular Ad-hoc Networks

1e+007
Pareto curve
Non pareto optimal solutions

1e+006
(ZF 3.12)(ZF 1.78)

100000
Packets Sent

(ZD 0.31)
10000
(ZD 0.17)
(ZD 0.1)
(ZD 0.05)
(ZD 0.03)
1000
(ZD 0.01)

100
30 40 50 60 70 80 90 100
Awareness Percentage

Figure .: Pareto optimal solutions. High velocity,  nodes.

Node density/Mobility Low Medium High

. None . .
. None . .
. . . .

Table .: Lowest Awareness Percentage requirement to choose Zone Flooding.

Node density/Mobility Low Medium High

. All . .
. All . .
. . . .

Table .: Maximum packets sent allowance requiring Zone Diffusion to be cho-
sen.


 .. Algorithm Primitives

Primitive Description
 Broadcasts the argument
_ Returns a collection of cells that exists in both environment repre-
sentations
_ Given a packet it decrements the hop-count of the packet
_ Returns the current cell
_ Returns a classification of the road
_ Returns the current position
_ Returns true if the given position is outside the given zone
_ Constructs a new packet containing the arguments.
_ Given a position it returns a zone having the position at its centre
 e given classifications are combined and return according to the
combination policy
_ Given a node identity, it returns the stored sequence number for that
node. If no sequence number is stored, infinity is returned
 Waits for a given interval
packet A data structure for a Zone Flooding packet containing fields:
hopcount (an integer)
seqNumber (an integer)
classification (an integer)
zone (a zone represented by two corners)
ER A data structure for an ER. Maps cells to classifications (ER.at(pos))


C Ո 

A U P-S I 

C  W M E
Jeppe Brønsted, Klaus Marius Hansen, Rolf orup
Abstract

In near future the transportation sector will be communication enabled.

Devices in vehicles will be able to communicate and thus make a new range
of services possible. However, heterogeneous communication capabilities and
vehicle mobility complicates the art of designing and implementing these new
systems and therefore it is important to have communication middleware that
hides the complexity of low level network programming and presents a clean
and understandable abstraction over communication to the application pro-
grammer. It has previously been shown that the publish-subscribe messaging
paradigm provides a good communication abstraction for wireless networks
of mobile nodes. In this paper we present PSI, a uniform publish-subscribe
based infrastructure, for communication in wireless mobile environments. In
PSI the application is divided into software components that each handles a
well defined part of the functionality and communicate with other compo-
nents using the publish-subscribe paradigm. From a components perspective
it makes no difference where the receivers of a message are located - in the
same process, in another process on the same node, or in a process on a re-
mote node. All communication is handled uniformly. By showing how the
infrastructure is used in a concrete instance we argue that it meets the require-
ments for middleware stated above and provides a good programming model
for distributed systems in mobile environments.

. I

In distributed systems programming where involved parties communicate in het-

erogeneous ways a common problem is how to separate communication logic from
Published as:
Jeppe Brønsted, Klaus Marius Hansen, and Rolf orup. A Uniform Publish-Subscribe Infrastruc-
ture for Communication in Wireless Mobile Environments. In th International Conference on ITS
Telecommunications Proceedings, pages –, June . Acceptance rate: 
A previous version was published as a workshop paper:
Jeppe Brønsted, Klaus Marius Hansen, and Rolf orup. A Uniform Publish-Subscribe Infrastruc-
ture for Communication in Wireless Mobile Environments. In Proceedings of the rd MiNEMA
Workshop, February 


Chapter . A Uniform Publish-Subscribe Infrastructure

application logic. ere is a need for middleware that handles the communication
part of the system in a way that lets the programmer focus on developing the ap-
plication. When communication in distributed systems is established by wireless
multi-hop ad-hoc networking, connections are often unreliable and not well suited
for connection-oriented communication []. Systems are better supported by
message-oriented communication. e exchange of messages can be seen as a com-
mon denominator for all communication media and is therefore a natural candidate
for a communication atom from which higher level abstractions can be developed.
To exchange messages it has previously been shown that publish-subscribe is a feasi-
ble and well-suited communication paradigm for mobile environments [, , ]
providing decoupling in time, space, and flow [].
In this paper we introduce the PSI publish-subscribe infrastructure for com-
munication in mobile environments. PSI supports a model for distributed systems
programming where the functionality is divided into independent software com-
ponents that communicate using the publish-subscribe messaging paradigm not
only for inter node communication but also for communication internally on the
nodes. In fact we discourage letting components communicate directly without
using messages. Messages are distributed using buses. Multiple buses can coexist
in the system delivering messages in different scopes. Buses are linked by special
Gateway components that are configured to relay messages from bus to bus.
Using the same communication abstraction internally on the nodes and exter-
nally between the nodes provides a uniform approach to communication in wireless
mobile environments. We demonstrate the use of PSI in a distributed system con-
sisting of mobile nodes and show how PSI can be used not only to structure the
system in a uniform way but also how to achieve high-level multi-hop communi-
cation between nodes.
e work presented in this paper has been developed in the context of the LI-
WAS research project[]. e LIfe WArning System (LIWAS) is a traffic warn-
ing system for informing drivers about hazardous driving conditions such as ice,
water, and snow on the road being approached. e operation of the LIWAS sys-
tem can be seen in figure ..
LIWAS units are embedded systems with sensors capable of measuring a wide
range of physical phenomena such as light reflection, air temperature, and dew
point. e units are mounted on cars and alongside roads to detect the condition
of the road. e sensed data is collected from the sensor mounted on vehicle A us-
ing a serial connection and combined into a classification of the state of the road and
presented to the driver on a PDA. From the PDA the classification is distributed
to other drivers and to road authorities - using ., GSM, or similar wireless
communication technology - to improve traffic safety and optimize road mainte-
nance. It is not only information about where a road is icy that is distributed, but
also information about where the road is not icy. A driver can thus be certain about
whether the road ahead is safe e.g. before initiating an overtaking. Communication
capabilities may vary from unit to unit depending on what hardware is present.
e rest of the paper is structured as follows. e section following this presents


 .. Related Work

RS-232

A 802.11
GSM

Figure .: LIWAS operation

related work. In section . we describe PSI and its elements. Section . demon-
strates the use of PSI in the LIWAS system and in section . we discus the prop-
erties of PSI and outline future work.

. R W

Using publish-subscribe for universal inter-process communication was introduced

in []. In each process a IPC daemon handles publications and subscriptions.
e IPC daemon coordinates with other IPC daemons so that they agree on sub-
scriptions and publications which makes the system sensitive to node and commu-
nication link failures. In PSI there is no coordination among components about
subscriptions and publications. ese are handled by the buses which, depending
on their implementation, delivers messages in different scopes and with different
levels of service. Furthermore in [] the communicating entities are processes -
as opposed to components in PSI - limiting the flexibility in how implementation
can be divided into components.
In [] the concept of a bus to handle distribution of events was introduced.
Ethernet broadcast is used to broadcast events on the local area network and infor-
mation routers, corresponding to Gateways, relay events from LAN to LAN. e
design goal of the information routers is to create the illusion of a single, large bus. e


Chapter . A Uniform Publish-Subscribe Infrastructure

information routers determine, based on information about subscriptions, when to

relay events. In a wireless settings we cannot assume that the Gateways are able
to determine this. Our approach is instead to explicitly let the Gateways know (by
publishing events) which events should be relayed and thereby also gain more flex-
ibility in where events should go. In [] the bus concept introduced in []
was extended to event channels providing different levels of service. Each event is
tagged with a list of attributes containing the functional and quality requirements
the event should be delivered according to. While this provides fine grained con-
trol over quality of service, the mechanism is possibly too heavy to be used for intra
process communication.
While we use message-oriented communication between components some
systems use message-oriented communication at an even lower level. In TinyOS[]
the notion of components resemble that of traditional objects and all communica-
tion between components is message oriented. At compile time a component graph
specifies between which components messages can flow. is implies that the com-
munication structure is static and thus cannot be modified at runtime. [] also uses
message-oriented communication at the object level. A virtual machine makes sure
that systems can be modified at runtime.
In both [] and [] events are not only used for communication, but also for
iteration. e threading model is based on the assumption that objects will only
perform quick tasks and then immediately return control to the scheduler enabling
fast context switching. An object simulates loops by sending messages to itself after
which the control is immediately handed over to the scheduler. e scheduler will
then let other threads run and in turn return control to the object when the time
has come to process the message. While this solution is certainly an alternative to
ours, the programming model forces the programmer to give attention to low level
threading issues such as e.g. how much code can be executed before control should
be handed over to scheduler. is approach is well-suited for very resource-limited
devices, i.e.  bit micro controllers with a few kilobytes of RAM, but for PDA-class
systems it is our opinion that the programmers attention should be spent on higher
level issues.

. PSI -  P-S I

On an abstract level PSI consists of components, events, buses, and gateways, that
combined provide uniform message-oriented communication. e intent of the
infrastructure is to support the development and deployment of mobile, wireless
systems.
In the infrastructure, runtime components are the communicating entities that
exchange messages in the form of events. Events are exchanged through buses ac-
cording to the publish-subscribe messaging paradigm[]. To send an event, a
component publishes it on a bus from which other components can receive it, pro-
vided they have notified the bus of their interest in the event by subscribing to it. To
make events travel from one bus to other buses, special components called gateways


 .. PSI - a Publish-Subscribe Infrastructure

link two buses by relaying events in a controlled manner. An example of a gateway

could be one linking local host communication with a local area network in order
for multiple hosts to communicate using publish/subscribe.
An example deployment diagram of the infrastructure can be seen in figure ..
Each element of the figure will be described in detail shortly.

Host

Component Component Gateway

Bus

Bus

Figure .: Infrastructure deployment diagram

As can be seen in figure . the mechanism for communication internally on

nodes and externally between nodes is the same. Seen from a components perspec-
tive it is transparent whether communicating partners are on the same node or on
other nodes. Besides providing a simple and elegant conceptual model of commu-
nication it decouples the communication technology from the functionality that
uses it which has several benefits:
Any information an internal component produces can be made available to ex-
ternal components and vice versa - without modifying the component originating
the information. Furthermore, it can be remotely configured which events should
leave a node. An example of this will be given in section ...
Traditionally, when debugging a distributed system, one approach is to monitor
communication between nodes. If the system uses a heterogeneous set of commu-
nication protocols and technologies this can be difficult. Communication intercep-
tion and analysis tools has to be developed for each protocol and technology. In
our infrastructure all communication is done by buses and therefore analysis can
be done easily. Only one event sniffer per bus has to be implemented to see what
information is exchanged.
e system can be dynamically configured to adapt to varying communication
capabilities. A component could monitor the state of network interfaces and choose
the one that is best for a particular purpose. When a WiFi connection to the Inter-
net is available, it is usually preferable to a slow and expensive GPRS connection.
When the WiFi connection at a later time becomes unavailable the GPRS connec-
tion should be used again.


Chapter . A Uniform Publish-Subscribe Infrastructure

A drawback of using the same method of communication internally on nodes

and externally between nodes is that there is a performance drawback when all
communicating parties are located on the same node in comparison with ordinary
procedure calls. However, we state that the benefits from the increased flexibility
outweigh the penalties induced by the performance overhead.
e infrastructure is implemented on top of the .NET Framework[] using
IP for communication and can run on PDAs as well as PCs. A Java version of the
system is under development.

.. Components

We define a component as unit of software that is responsible for a well defined

part of the intended system functionality and that has well-defined dependencies
only []. Separating the functionality into distinct components has many well-
proven benefits among which one of the most important is separation of concerns.
In our component model, each component is defined in a .NET assembly and can
be loaded and run dynamically at runtime.
Much like the JAR-based component model of OSGi for Java [], a special
activator class in the assembly is responsible for initializing the component. e
activator receives a handle to the communication bus and all further communication
is done through this bus. A component may run in a separate thread, but does not
need to.
Components operate independently in the sense that if one component fails,
other components will not fail directly as a consequence. is means that inter-
component communication should be designed so that, e.g., if some component
relies on a GPS component that fails, it should not itself fail, but rather stop func-
tioning until the GPS component recovers or another component providing similar
functionality is loaded, and then start functioning again.

.. Events

Traditionally publish-subscribe systems can be divided into topic-based and content-

based systems. e difference lies in the flexibility in describing what kinds of
events a component can subscribe to. In content based systems the component
specifies an event predicate that defines which events the component subscribes to.
e predicate can be of almost any form. In topic-based systems, which to a large
extent can be seen as a specialized version of the content-based, each event is sent
to a (hierarchical) topic which components may subscribe to. e component will
receive all events that are sent to the topics it subscribes to.
Our system is topic-based for several reasons. Most importantly, better perfor-
mance of the bus can be achieved in a topic-based system because the bus only needs
to interpret the topic of an event to determine who should receive it. In content-
based systems, the bus has to be able to make a semantic interpretation of the whole
event before it can determine the appropriate subscribers to send the event to. An-


 .. PSI - a Publish-Subscribe Infrastructure

other reason for using topic-based publish/subscribe is that new data formats may
be introduced without altering the bus. is is harder to do in a content-based
system because along with the new format, the interpretation must be specified.
To be able to flexibly categorize events, each topic consists of a sequence of
subtopics. e subtopics are organized in a tree so that each node corresponds to
a topic. When a component subscribes to a node, t, in the tree, it will receive all
events that have a topic corresponding to a node in the subtree rooted at t. In
figure . a subset of the topics in the LIWAS system is shown. A component
subscribing to Measurement.RoadSensor would receive all events published with the
topics Measurement.RoadSensor, Measurement.RoadSensor.Simulated, and Measure-
ment.RoadSensor.v. Each subtopic is identified by a byte which allows a compact
representation of the event and allows fast interpretation of the topic.

Measurement Classification Dissemination

RoadSensor GPS Positioned EnvRep

Simulated V1

Figure .: Topic hierarchy

.. Buses

Each time an event is published on a bus, the bus is responsible for delivering the
event to the nodes or components that subscribe to it on that bus. Our infrastruc-
ture does not mandate any specific form of communication technology for buses,
but in the LIWAS system we use IP-based communication to deliver events.
IP communication is used in LIWAS for two reasons. Firstly, almost any pro-
gramming API and platform supports IP communication and thus the infrastruc-
ture can effortlessly be integrated in most systems. is means e.g. that a .NET
component can subscribe to events published by a Java component and vice versa.
Secondly, when one process is interested in receiving some but not all events from
a bus, the operating system can be used to filter out the uninteresting events in a
simple yet powerful manner. is will be described later.
When a bus is created it is specified to which IP address events should be sent
and at which IP address events will arrive. When a bus is used for internal commu-
nication between components on a single node, the bus will send events to the local-
host multicast address ... and listen for events at localhost ....
If more than one receiver should be able to receive an event, the send address must
be a multicast address.
e operation of the bus can be seen if figure . and ..
To be able to publish events of a specific topic, a component first has to Advertise


Chapter . A Uniform Publish-Subscribe Infrastructure

a Component a Bus

Advertise(topic)
new
a Publisher

new
a Socket

Publish(event)
UdpSend(datagram)

Figure .: Publish

the bus, i.e., notify that it wishes to publish events of a certain topic. Enforcing
this makes it possible for the bus to determine who publishes what. e bus in
turn returns a Publisher -object that can be used to publish events. Each time the
component publishes an event using the Publisher, the Publisher will wrap the event
in a UDP datagram and send it to a predefined port number depending on the
topic. In the current implementation this port number is a constant offset plus the
identifier of the first subtopic. is means that if e.g. a component is interested
in events of the topic Measurement it only has to listen to the port associated with
Measurement. All other events will be filtered out by the operating system (since
they will be sent to other ports).
To share sockets, only one Publisher is created for each port number used, im-
plying that the next time a component advertises the same topic no Publisher will
be created. Instead the already existing Publisher will be returned.
Figure . describes what happens when a component subscribes to a topic.

a Component a Bus

Subscribe(topic,this)
new(c)
a Listener

a Socket
new

loop Receive

Handle(event)

Figure .: Subscribe


 .. PSI - a Publish-Subscribe Infrastructure

When a component subscribes to a topic, it specifies a component to be notified

when an event arrives (itself in the figure). e bus creates a Listener associated
with the component (c in the figure) that in turn creates a socket for receiving UDP
datagrams on the port number that corresponds to the topic. e Listener waits
for incoming datagrams in a new thread. As was the case when publishing, only
one Listener is created for each port number used. Each time a datagram arrives,
the Listener notifies the components associated with it.
As mentioned previously, the bus can be used for communication both inter-
nally on a node and with other nodes. e only difference is the IP addresses
specified for receiving and sending events. As an example, an . WiFi radio in
ad-hoc mode could be used to publish events to other nodes in the vicinity. How
this can be used to establish multi-hop inter node communication will be shown in
section ..
Traditionally in publish-subscribe systems the bus guarantees that published
events will reach all subscribers. Clearly we cannot make such a guarantee when
communicating wirelessly. However, in the case where all communication is done
inside a node, the operating system will provide a high guarantee that events are
delivered.

.. Gateways

As can be seen in figure ., gateways are a special kind of component with two
buses associated and that have the responsibility of relaying events published on
one bus to the other bus and vice versa. e operation of the gateway is controlled
by publishing events containing gateway commands specifying which events should
be relayed. A command consists of a topic and whether the relaying should go from
one bus to the other, or the other way around. An example use of gateways could
be the following:
We wish to log the location of a set of mobile nodes on a central server. On
each node is a GPS component that publishes events containing the location of the
node. e locations should be sent by a GPRS connection to the server and logged.
A deployment diagram of the example is shown in figure..
To control the communication with the server, a gateway component is created
on each node. e gateway is attached to the internal bus and a bus is created that
sends events to the IP address of the server and receives events at the IP address of
the GPRS interface. Similarly on the server side, a gateway is created that listens
for events on the IP address of the server’s Ethernet network interface card. If
the IP addresses of the node’s GPRS interfaces are on the same subnet, the subnet
multicast address can be used for publishing events - otherwise a multicast service
should be used. Another alternative is only to use one way communication - from
the nodes to the server.
In the example, the gateways of mobile nodes can be configured either locally
or from the server by publishing the event: {Measurement.GPS, internal-to-GPRS}
with the topic Gateway.GPRS. If the gateways are configured from the server, the


Chapter . A Uniform Publish-Subscribe Infrastructure

Node Server

GPS Gateway Logger Gateway

Bus Bus

GPRS Ethernet

Bus

Figure .: Gateway example

logging of locations in the example is completely transparent seen from the mobile
nodes (excluding their gateways).
Gateways can also be used to enable wireless ad-hoc communication between
nodes as we will see in the next section. To use communication technologies that
do not use IP (e.g., SMS) a specialized version of the gateways can be implemented.
PSI poses no constraints on how buses and gateways are connected and there-
fore care must be taken when configuring the gateways to avoid cycling events.

. PSI   LIWAS S

In this section we exemplify the use of PSI in the LIWAS system. As mentioned
in section . the LIWAS system consists of nodes equipped with sensors that de-
termine the state of the road. e information is communicated to other nodes to
warn drivers about hazardous driving conditions.
In figure . a deployment view of a LIWAS node is shown. It consists of a
PDA, a road sensor and a GPS [] unit. e PDA is connected to the road sen-
sor by a serial RS- link and to the GPS unit via a Bluetooth [] link, and
the PDA communicates with other LIWAS nodes via a .b connection in ad-
hoc mode. On the PDA a set of components handles various parts of the system.
As the system is implemented using PSI all inter component communication goes
through a central bus, but to avoid cluttering the bus has been left out in the fig-
ure . e arrows between the components show dependency relations among the
components. e event-hierarchy used is the one shown in figure ..
e functionality of each of the components is described below. For each com-
ponent it is described which event topics they publish and subscribe to.


 .. PSI in the LIWAS System

RoadSensor
e RoadSensor receives sensor readings from the road-sensor and publishes events
with the topic Measurement.RoadSensor on the bus. e events contain values for
e.g. air temperature, humidity, and dew point.

GPSSensor
e GPSSensor receives location strings from the GPS unit and publishes Mea-
surement.GPS events.

Classifier
e Classifier is responsible for transforming measurements which are physical in
nature into classifications, such as dry, wet, icy, that are semantic interpretations of
the measurements. It is currently implemented using standard linear discrimination
analysis and pattern recognition. e classifications are published in events with
the topic Classification. e Classifier subscribes to Measurement.RoadSensor and
Measurement.GPS.

WiFi Gateway
e WiFi Gateway component is a gateway as described in section ... It links
the internal bus with the .b device in ad-hoc mode so that events can be
relayed from the internal bus to other nodes in range by broadcasting them on the

LIWAS Node

PDA

UserInterface

Dissemination

Classifier

RoadSensor GPSSensor WiFi Gateway

802.11b

RS 232 Bluetooth

Sensor System GPS

Figure .: LIWAS deployment


Chapter . A Uniform Publish-Subscribe Infrastructure

WiFi interface, and events received on the WiFi interface can be relayed on the
internal bus.

Dissemination
e Dissemination component handles the distribution of road classifications to
other nodes by use of the Zone Diffusion protocol[] which can be described as
follows. e Dissemination component maintains in memory a environment repre-
sentation representing the surroundings of the node. e component subscribes to
Classification and each time a classification is received the environment represen-
tation is updated. e environment representation is periodically published with
the topic Dissemination.EnvRep. e WiFi Gateway is configured to relay events
with the topic Dissemination.EnvRep both from the internal bus to the WiFi in-
terface and vice versa. e Dissemination component also subscribes to Dissemina-
tion.EnvRep and each time an event is received, the received environment represen-
tation is aggregated with the local one. Every time new information is learned in
the aggregation process a corresponding classification is published using with topic
Classification.Positioned.
e Zone Diffusion protocol differs from traditional multi-hop ad-hoc routing
protocols in that no messages are sent over more than one hop explicitly. Instead,
classifications travel from environment representation to environment representa-
tion and can thus reach nodes many hops away.

UserInterface
e UserInterface presents the LIWAS system to the user by showing classifications
on a map. e UserInterface subscribes to Classification and therefore receives all
classifications published by the Classifier and Dissemination.
A prototype of the system has been implemented and is currently deployed at
an airport near Aarhus, Denmark. e deployment includes only one node and
therefore the communication parts of the system have been replaced by logging
facilities.
. D

Besides providing a clean an understandable abstraction over communication to the

application programmer PSI provides support for a set of architectural qualities[]
that are important to a wide range of applications namely availability, modifiability
and testability. In the following we list the qualities along with descriptions of how
they are supported.
High availability is supported by having a loose coupling between components.
If one component fails other components will not automatically fail as a conse-
quence. An example could be the UserInterface component from figure .. Since
the UserInterface receives classifications from both the Classifier and the Dissem-
ination component it will continue to be available if Classifier or Dissemination


 .. Discussion

fails. Another feature providing support for high availability is the loading of com-
ponents at runtime. is makes it e.g. possible to add a new dissemination protocol
at runtime without shutting down the system.
Another benefit of having a loose coupling between components is that changes
to the system will typically only include a few components thus supporting high
modifiability. e incorporation of a new type of communication link into the
system e.g. GPRS would only require a gateway component to be implemented
and configured to relay the appropriate events. We plan to further support high
availability and modifiability by implementing a component that allows other com-
ponents to be downloaded from a remote node. is would ease the process of
updating software on already deployed nodes.
A major problem in programming distributed systems consisting of wirelessly
connected mobile nodes is to test protocols and collective behavior without orches-
trating hundreds of nodes. Testability is supported in PSI by making it possible
to replace components with simulated ones and having explicit control over inter
node communication. It is future work to make a simulation tool that emulates
GPS components and WiFi gateways according to a simulation scenario.
In this paper we demonstrated how PSI can be used to structure a distributed
system consisting of wirelessly connected mobile nodes. We saw how inter com-
ponent communication is easily facilitated by using the bus and how multi-hop
communication can be implemented using gateways. It is clear that the benefits of
PSI comes at a price, but, other than just observing that a relatively complex system
can be implemented on top of it to run on resources constrained devices such as e.g.
PDAs, it is future work to accurately estimate the performance penalty imposed by
the infrastructure.

A

e authors would like to thank Toke Eskildsen for implementing large parts of
the system, Lars Kristensen for valuable input on the infrastructure, LIWAS ApS
for their corporation and the MiNEMA network for valuable feedback.

¹http://www.minema.di.fc.ul.pt/


C Ո 

P  

Jeppe Brønsted, Erik Grönvall and David Fors

Abstract

In ubiquitous computing, as more and more devices are embedded into

the environment, there is a risk that the user loses the understanding of the
system. In normal use this is not always a problem, but when breakdowns
occur it is crucial that the user understands the system to be able to handle
the situation. e concept of palpable computing, introduced by the PalCom
project, denotes systems which support such understandability. In PalCom,
a set of prototype scenarios provide input for an open software architecture
and a conceptual framework for palpable computing. One of these prototype
scenarios is based on the Active Surfaces concept in which therapists rehabil-
itate physically and mentally impaired children by means of an activity that
stimulates the children both physically and cognitively.
In this paper we demonstrate how palpability can be supported in a pro-
totype of the Active Surfaces. Services on the tiles have been developed using
the PalCom service framework that allows them to be combined into PalCom
assemblies. e support for palpability is shown by examples of use scenarios
from the work of the therapist who can inspect and alter the runtime state
of the tiles to change their configuration and cope with breakdown situations.
e prototype implementation runs on a standard PC simulating the network
layer and a first reference implementation has been made on the target em-
bedded platform.

. I

Palpable computing is a new perspective on ubiquitous computing, in which tra-

ditional ubiquitous computing challenges such as invisibility and composition are
complemented with visibility and deconstruction. e concept has been formed
based on the observation that when applied in real settings, ubiquitous computing
systems tend to become hard to understand for users. Mark Weiser painted a vi-
sion of systems being ‘physically invisible’ and that these systems also mentally (as
Published as:
Jeppe Brønsted, Erik Grönvall, and David Fors. Palpability Support Demonstrated. In Proceed-
ings of Embedded and Ubiquitous Computing, volume  of LNCS, pages –, Taipei, Taiwan,
December . Springer. Acceptance rate: 


Chapter . Palpability support demonstrated

maybe physically) could disappear through use. Dr. Weiser describes the concept
well as follows; “Whenever people learn something sufficiently well they cease to be
aware of it.” and “e most profound technologies are those that disappear” [].
is implies not only that as we learn to master a technology, we move the use
(or perception) of it from a foreground to a background cue [], but also that a
technology that has the capacity to allow the user to interact with or through it as
a background process is a more thoughtful, intense or reflective technology.
As part of the ubiquitous conceptual framework and closely related to the work
regarding foreground and background cues is the notion of ‘calm technology’ [].
Calm technology as described by Weiser and Brown regards how technology can
move from the centre of our attention out to the periphery, and between those two
states as required by the situation at hand. e vision of calm technology is that
technology should not overload us with information or require an ongoing ‘active’
mental activity. Weiser and Brown argues that this can be reached in two ways;
) Allowing the technology (or information) to move between the centre to the
periphery of our attention (and between these two states) and ) by enhancing our
peripheral reach. is is done by allowing more data to enter the periphery cues.
As described in their paper, a video conference could be an example of technology
that enhance the peripheral reach in respect to an ordinary telephone call where the
users cannot use facial and body expressions as part of their communication [].
In many ways, ubiquitous systems tries to embed the notion of ’ready at hand’,
meaning that these highly distributed, networked systems and devices should adapt
to the current needs of the user or users. In normal use the system should be invisible
and not interfere with the present task. However, when a breakdown occurs the user
should be able to inspect the system to determine the reason and, if possible, resolve
the situation. If the system is composed of multiple devices, it should be possible
to replace malfunctioning devices with new ones without having to recompile or
restart the system. We do not claim that techniques such as self-reconfiguration,
error detection and fault tolerance should not be used. We make the observation
that such mechanisms will never be perfect and that we therefore, as a supplement,
need a way to handle the situations where the mechanisms are imperfect.
Palpable computing is researched in the EU IST project PalCom []. e
main output of the project is a conceptual framework for palpable computing, an
open architecture supporting palpable computing, and a collection of tools to be
used in development of palpable computing applications. A part of the work in the
project deals with developing palpable computing prototypes using participatory
design to provide input to the conceptual framework and the design of the open
architecture.
e Active Surfaces [] concept provides support for physical-functional and
cognitive rehabilitation in a swimming pool setting. e concept has been devel-
oped using participatory design techniques in corporation with therapists and pa-
tients. rough analysis of the rehabilitation practice an activity (i.e. a number of
different games) has been developed in which children assemble floating tiles into
meaningful configurations. Each of the tiles is a resource constrained embedded


 .. Active Surfaces

system that communicates using only a low bandwidth short-range infrared link.
e only output available to the user is a set of light emitting diodes and there-
fore the game is an example of a ubiquitous computing system where it is essential
that the physical and functional characteristics are such that palpability can emerge
during use.
For the software on the tiles, support for palpability is achieved by adhering
to the PalCom open architecture [], and by building on the PalCom service
framework []. Services developed using the framework can be combined into
PalCom assemblies, which coordinate the services and provide support for inspec-
tion, deconstruction and reconstruction. rough interaction with the assemblies,
the therapist can inspect and change the configurations of the tiles. is way, she
can adapt the therapeutic activity in the middle of an exercise, and the visibility
given by the assemblies helps her cope with unexpected breakdown situations.
e rest of the paper is structured as follows. In the next section we describe the
Active Surfaces concept and the physical and functional aspects of the prototype.
Section . presents the PalCom software architecture and demonstrates how it
can be used to support palpability in the implementation of the prototype. In Sec-
tion . scenarios from therapist work are presented, together with an evaluation
of how the prototype supports palpable qualities. Section . sums up conclusions
and presents future work.

. A S

Active Surfaces is a concept developed for rehabilitation practitioners being a sup-

port for physical-functional and cognitive rehabilitation treatments in a swimming
pool setting. erapists working in cognitive and physical rehabilitation with dis-
abled patients usually experience their job as challenging and demanding. Every
time the therapist starts a treatment she has to define a specific program and ad hoc
solutions with the aim of designing a rehabilitation intervention that could adapt
to the individual patients’ needs. us, the work of the therapist is mainly charac-
terized by creativity both in designing engaging activities and suitable tools.
e lack of integration of physical and cognitive rehabilitation represents a con-
straint for current rehabilitation practice. e cognitive tasks are usually too static
and children may lose attention. On the other hand, motor rehabilitation is very
demanding at a physical level and is based on repetitive sequences of actions: pa-
tients often perceive them as tiring and not engaging. Here the Active Surfaces
allow an integration of these two therapeutic goals with the activity. Water as such
is an interesting context from the activity perspective; Water creates a safe context
where impaired people can move autonomously relying on the added support to the
body, something they cannot do elsewhere. Apart from this, water also poses spe-
cific and interesting research issues both for the development of digital technologies
and for the therapeutic practice.
e work has been driven following a co-evolutionary method [, ]. e
approach integrates participatory design with creative concept design, using dif-


Chapter . Palpability support demonstrated

ferent typologies of scenarios for converging ideas into solutions. e concept and
project has been developed together with children affected by different impairments
undergoing therapeutic activities in the swimming pool, their parents, trainers and
therapists at the swimming pool and at the ‘Le Scotte’ hospital in Siena, Italy. e
early phases of the fieldwork have been devoted to understand the activity, to de-
fine requirements, and to collect best practices. On this basis, the concept of the
Active Surfaces has been developed, capitalizing on participatory design activities
and creative workshops together with Traveling Architect [] and Future Lab []
sessions.

.. e Prototype

Figure .: Tiles

e prototype consists of a set of floating tiles (figure .) that can be con-
nected to each other to form a network. e tiles support multiple games by having
a simple composable physical appearance and multi-purpose programmable hard-
ware. On each of the tiles’ four sides magnets are placed to make the tiles “snap”
together when they are in close vicinity. On the top of the tile is a replaceable plastic
cover also held in place by magnets. e image on the cover depends on the game.
On each side of the tiles light emitting diodes (LEDs) provide visual feedback to
the user.
Inside each tile an embedded system uses infrared light to communicate with
and detect the presence of other tiles. Two tiles can only communicate if they
are close to each other. Figure . shows an overview of the hardware compo-
nents in the tiles. e main computational unit is the UNC module, which is
an ARM-based embedded system running uClinux[] at MHz with approx-


 .. Active Surfaces

imately MB ram. e UNC module communicates with a sideboard using a

Tile

DLP
RS-232 (IR ports,
UNC20 IR Modulator, LED
controller, LEDs)

Figure .: Hardware

serial connection. e sideboard is responsible for controlling the infrared commu-

nication and the LEDs. e bandwidth of the infrared communication is approx-
imately  bits per second.

.. Games

e tiles support multiple games and in the following we describe a few suggestions.
To change the current game the therapist connects the tile to a PDA running Pal-
Com software. Since the PDA is not suited for a wet environment this should be
done prior to the training activity.
A lot of games can be imagined for the Active Surfaces. However, for a game to
be appropriate for the tiles it should support both physical and cognitive rehabilita-
tion while at the same time be implementable on the resource-constrained devices.
Furthermore, to be able to help a wide range of patients the set of games should
be of varying difficulty, both on the physical and on the cognitive level. Finally,
the games should be open ended and configurable so that they can be adapted and
customized to each rehabilitation session.
In this section we describe three games with different properties with respect to
physical and cognitive rehabilitation. e first game, catch, is meant to only require
simple cognitive effort but challenges the patients reflexes, speed, and coordination.
e second game, scrabble, has the requirement that the patient should be able to
form words out of letters. e last game, puzzle, is a traditional puzzle game in
which an image is created by assembling the tiles in a specific pattern.

Catch
In the catch game the therapist aligns a set of tiles and gives another tile to the
patient (at the bottom in figure .). When the game is started the point of the
game is for the patient to try to catch the light by approaching her tile to the glowing
tile within a certain timeframe. If she succeeds another random tile will light up
(not hers) and she tries to catch that one. When she eventually fails to catch the


Chapter . Palpability support demonstrated

Figure .: Catch

light before the time limit her tile will blink how many lights she caught. e game
can be adapted to the patient by configuring the length of the timeframe.

Scrabble
In the scrabble game each tile has a letter on the surface. e patient uses the tiles
to create words. When a tile is part of a word it lights up on all four sides. Each
tile should be aware of what letter it has on the face. e memory requirement for
the game depends on the number of tiles and on which letters the tiles have. As
an example at least  English words can be generated from letters on the tiles in
figure . . Since this number grows exponentially with the number of tiles it is
not feasible to store all possible combinations on each tile. Instead, only the valid
words for a particular tile-letter configuration should be uploaded to the tiles. e
letter configuration should therefore be uploaded along with the game before the
training activity.

H H
C ARD CARD
T T
Figure .: Scrabble

¹a, ad, at, act, arc, art, cad, car, cat, had, hat, rat, tad, tar, arch, card, cart, char, chat, dart, hard,
hart, chard, and chart


 .. Implementation

Puzzle
In the puzzle game the face of each tile is part of a larger image (see figure .).
Initially the tiles are spread in a random pattern after which the patient starts to
solve the puzzle. As the game progresses the patient gets continuous feedback from
the LEDs. When two tiles are connected correctly the corresponding sides light up
(fig. .a). When all of a tile’s neighbors are correct all sides of that tile light up
(fig. .b), and finally when the puzzle is solved the outline of the solution lights
up (fig. .c).

(a) (b) (c)

Figure .: Puzzle

During the session the therapist can change the faces of the tiles to make a new
puzzle. To reprogram the tiles a special assembler tile is used. e assembler tile
has the same physical appearance as the other tiles, but also has a button. To make
the tiles remember the new solution they are arranged in the solution pattern and
the assembler tile is put next to one of the tiles and the button is pressed. After
this, the tiles will remember the new solution and can be scattered randomly again.
is way of programming the tiles by showing them the correct solution has some
similarities with programming by example [] and physical programming [].
e LED feedback can be configured by the therapist to alter the difficulty level
of the game. It is, e.g., easier to solve the puzzle if all the outer edges of the final
solution will light up as the game is started.
e different game types described above all have different game rules. ese
rules defines the base of a game. Apart from them, different behavior can be con-
figured to support the game rules and the activity. is can for example be different
output to the end-user to aid in accomplishing the task, i.e. the game. is config-
uration can be physical and logical.

. I

In this section we demonstrate how the PalCom software architecture and runtime
system can be used to implement the Active Surfaces prototype in a way that sup-
ports palpability. We describe the PalCom runtime system (section ..) and a
simulation framework that can be used to experiment with the tiles on a standard
PC (section ..). e top layer of the runtime system is the application layer in


Chapter . Palpability support demonstrated

which applications are built by composing services (section ..) into assemblies
(section ..). Finally, in section .., the implementation of the puzzle game
is described.

.. PalCom Runtime System

Application Layer

Manual & task-driven Assembly Construction

Runtime Components Services Assemblies

Middleware Management

Service Management GUI/Display (opt.)

Assembly Management Persistency (opt.)

Resource Mgt. Contingency Mgt. Storage (opt.)

Runtime Environment

Core

Introspection Communication Discovery

Process & Thread

Runtime Engine

Base J-libs J-Base JRE

or
Pal-VM Java VM (JVM)

Execution Platform

Operating System (opt.)

Hardware

Figure .: PalCom layered runtime system

e PalCom runtime system (see figure .) consists of four layers: the exe-
cution platform, the runtime environment, the middleware management layer, and
the application layer. e execution platform consists of hardware and optionally
an operating system. Presently multiple hardware platforms are supported includ-
ing the UNC [] and standard PCs. e runtime environment consists of
standard libraries and a runtime engine which can be Sun’s Java VM or the Pal-
VM [], which is a compact virtual machine specially designed for embedded
systems for ubiquitous computing. If the hardware platform is the UNC only
the Pal-VM is supported. e middleware management layer consists of managers
handling resources, services, assemblies, and contingencies. For further description
of the middleware managers we refer to []. At the time of writing, the memory
footprint of the middleware management layer is too big to fit into the memory


 .. Implementation

of the UNC (app. MB). erefore, concurrently with the development of the
hardware for the tiles and the optimization of the middleware management layer,
the software for the tiles has been developed to run on a standard PC with sim-
ulated infrared communication, on top of Sun’s Java VM. When the middleware
management layer fits into the memory of the UNC, the implementation of the
prototype should be able to run unaltered on the UNC.

.. Simulation Framework

To ease the development of game logic and software for the tiles a simulation frame-
work (figure .) has been developed. Having a simulator available makes it pos-
sible to develop software and hardware in parallel and high level tools that are not
available for the embedded platform can be used for debugging and profiling. Fur-
thermore, testing involving repeated rearrangement of the tiles is much easier done
using a mouse in a graphical user interface than physically moving the actual tiles
around.
e simulator consists of a model of the swimming pool as a medium for in-
frared communication and a graphical user interface for manipulating the physical
location of the tiles. e user interface is connected with the pool model so that
when a tile is moved in the user interface, the pool model is updated accordingly.

:Tile :Tile :Tile :Tile

MAL MAL MAL MAL

:PoolModel

Figure .: Simulation framework

e model of the pool is also used in the medium abstraction layer of each of
the tiles. When a tile sends a message, the medium abstraction layer of the tile
accesses the pool model to determine which tiles the tile is connected to (if any)
and delivers the message accordingly. From an application developer’s perspective
it is transparent whether the simulation framework or the physical hardware is used.
e only part of the middleware that interacts with the simulation framework is the
media abstraction layer and therefore system behavior experienced on the simulator
is likely to be similar on the embedded platform.

.. Services

e software implementing the functionality of the tiles is divided into services us-
ing the PalCom service framework []. As described in [] a PalCom service is


Chapter . Palpability support demonstrated

an entity that ) contains a number of runtime components, ) is discoverable, and

) can be invoked remotely. e interaction with the service is done using an explic-
itly defined service interface. A PalCom service has a set of commands, in-going or
out-going, that optionally can be grouped. An in-going command specifies a point
of entry to the service that is similar to a traditional interface except that invocation
of the command is done in an asynchronous manner and that no results are returned.
Outgoing commands specify what in-going commands the service invokes. Both
in-going and outgoing commands have types specified by MIME [] strings.
We adopt the UML lollipop interface notation for commands - provided interface
(“closed lollipop”) for in-going commands and required interface (“open lollipop”)
for outgoing commands.
PalCom services can be bound or unbound. Bound services are tied to the hard-
ware device on which they run, and typically expose functionality in the hardware
for remote use. Unbound services, on the other hand, are not tied to the hardware
and can thus be moved to and installed on new devices. We use a UML stereotype
<<unbound>> for unbound services.

.. Assemblies

Services are connected by means of assemblies. e assembly is PalCom’s mecha-

nism for service coordination, central in the project’s approach to support for con-
struction and deconstruction of palpable systems. A system that is constructed us-
ing assemblies can be inspected in a service browser [], making its inner structure
visible at a certain level. is gives better understanding of the system, and is partic-
ularly important when a system breaks down. Furthermore, the assembly concept
targets construction of systems from services that were not originally created for
cooperation with each other. By inspecting the interfaces of a set of services, it is
possible to construct an assembly that combines them. Service composition has
previously been used to implement ubiquitous computing applications [].
Assemblies are defined by assembly scripts that can be loaded at runtime by
interacting with an assembly manager (see figure .). When an assembly is loaded
the assembly manager makes the appropriate connections and governs the flow of
service invocations. We use the nesting mechanism in UML for assemblies.
One goal of the implementation of the tiles has been to make it possible to
replace the game logic easily without rebooting the devices. is is done using
assemblies. A set of basic services encapsulates the basic hardware functionality
of the tiles and each game is implemented as one or more unbound services that
can be connected to these services. e basic services of the tiles are a LED service
controlling the LEDs, a Connectivity service detecting the presence of neighbor
tiles, and a Touch service receiving input from the button if one is present (as is the
case for the assembler tile in the puzzle game). e combination of the assembly
and the unbound services for the game logic can be replaced when switching to
another game. At present only the puzzle game has been implemented.
e split in functionality between an assembly and an unbound service is nor-


 .. Implementation

mal for a PalCom system. e assembly captures the coordination logic between
services, while the services perform most of the calculations. For adding behavior
to a set of services without programming a new service it is possible to express some
calculation in assembly scripts, but the assembly script language is intended to be
much simpler than the general-purpose programming languages normally used for
implementing services. erefore, complex calculations are implemented in un-
bound services that are incorporated when constructing an assembly. Finding the
right level of sophistication in the assembly script language, and how much should
be delegated to unbound services is a challenge that is under active research in the
project.

.. e Puzzle Game

As described in [] each of the tiles can be in one of three states: sideHappy,
localHappy, or globalHappy. e states correspond to the types of feedback given by
the tiles in the game. In figure ., the top-right tile is sideHappy in figure .a,
localHappy in figure .b, and globalHappy in figure .c. ree rules determine
which state a tile is in:

. A tile is sideHappy if it has less than four correct sides.

. It is localHappy if it has four correct sides but at least one of the other tiles
are sideHappy. is means that the tile has found its place in the puzzle, but
the complete puzzle is not solved.

. If no tile is sideHappy then all tiles are globalHappy. e puzzle is solved.

As can be seen from these simple rules, the game has a notion of global state,
namely, whether there is at least one sideHappy node. is information is used by
the tiles to distinguish whether the tile is localHappy or globalHappy. If a tile has
less than four correct sides it does not need this information (because of rule ).
e global state is maintained by handling two situations: e first situation oc-
curs when a tile observes that it has four correct sides instead of three. It then broad-
casts (by using the publish-subscribe mechanism of the communication model) a
challenge to the other nodes requiring any sideHappy nodes to reply immediately
(also with a broadcast). If no responses are received within a certain timeframe it is
concluded that there are no sideHappy nodes and that the node therefore instead of
being sideHappy should be globalHappy. If a response is received the node should
be localHappy. When a localHappy node receives a challenge it treats it as if it was
originating from itself - the node sets a timer and waits for responses. It is assumed
that the solution of the puzzle is connected and includes all nodes and therefore it
cannot be the case that no nodes are sideHappy in a proper subset of all the nodes.

²We define a correct side of a tile to be a side that has a correct neighbor or has no neighbor and
should have no neighbor according to the solution.


Chapter . Palpability support demonstrated

erefore, if there is a sideHappy node there is a path from that node to the node
that initiated the challenge.
e second situation, inverse to the first one, occurs when a node observes that it
has three correct sides instead of four. e new state of the node is now sideHappy.
If the node was globalHappy before the other nodes are unaware that the node is
now sideHappy, and therefore a message is broadcasted specifying so. If the node
was localHappy before, it can assume that there is at least one sideHappy node
in the graph it is connected to. e above paragraphs describe how the global
state is maintained. Alternately, this could be done using the two-phase commit
(PC) protocol. e PC protocol uses, however, a lot more communication and
since the inter-node communication bandwidth is approximately  bits/second
the protocol has been deemed inappropriate.

:Tile :AssemblerTile
PuzzleAsm PuzzleConfAsm

Connectivity Touch

<<unbound>> IR <<unbound>>
Puzzle Configure

<<unbound>>
HappyCoord IR

LED

Figure .: Services in the puzzle game

Figure . shows an UML deployment diagram outlining the structure of the
implementation. In the puzzle game there are two types of tiles - the normal tiles
and the assembler tile. e normal tiles communicate with each other and with
the assembler tile using IR communication. In the normal tiles the PuzzleAsm
assembly (listed in figure .) connects the basic services to the unbound services
handling the game logic. e Puzzle service receives connectivity events from the
Connectivity service (line – in figure .) and determines the local state of
the tile. is information is sent to the LED service (line –) and to the Coord
service (line –) that coordinates the global state using the algorithm specified
above. If all tiles are correctly aligned the Coord service notifies the LED service (line
–). e assembler tile contains a Configure service with the responsibility of
initiating and configuring the game and the PuzzleConfAsm assembly to connect it
to the basic services.


 .. Evaluation

 assembly PuzzleAsm {
 devices {
 device = urn:palcom://Tile_1;
 }
 services {
 Connectivity on device = Connectivity;
 Puzzle on device = Puzzle;
 HappyCoord on device = HappyCoord;
 LED on device = LED;
 }
 connections {
 Connectivity -> this;
 Puzzle -> this;
 HappyCoord -> this;
 LED -> this;
 }
 script {
 when connectivityUpdate from Connectivity {
 send connectivityUpdated(thisevent.param) to Puzzle;
 }
 when localHappy from Puzzle {
 send setled('1 1 1 1') to LED;
 }
 when sideHappy from Puzzle {
 send setled(thisevent.sides) to LED;
 }
 when localHappy from Puzzle {
 send localHappy() to HappyCoord;
 }
 when sideHappy from Puzzle {
 send sideHappy() to HappyCoord;
 }
 when globalHappy from HappyCoord {
 send setled('2 2 2 2') to LED;
 }
 }
 }

Figure .: Puzzle assembly script

. E

We argue that a system can be designed to have some palpable behavior from an
activity perspective in the sense that the system is easily perceivable and allows
for spontaneous interaction. During normal use it can be very hard for a user to
perceive the difference between a system running a palpable framework or not. But
if a breakdown occurs, these systems lose all their palpable qualities if the qualities
only were implemented ‘in the interface’. On the other hand, a system can run
the palpable framework, without a user perceiving any palpability in the use of
the system. If the system is not designed to communicate its palpability to the
users, palpability will not be perceived by the users. But finally, if combined, a
much higher level of palpability can be reached within a system. Palpability is not
only about internal structure of the software, it is also about communication and
interaction.


Chapter . Palpability support demonstrated

In Active Surfaces, as in other distributed systems that are characterized by a

high level of configurability and limited output capability, the contingencies that
might occur over time is of special interest and have to be dealt with. Especially
those that can occur in a multi-user environment. Multi-user not only with re-
spect to the number of users, but also with respect to different kinds of users. e
challenge here is to allow these users to be in control [], a key challenge in ubiq-
uitous computing addressed by Palpable computing. We will try to visualize this
point with a simple scenario.

One day two therapists work at the swimming pool. During the day dif-
ferent children arrive to start their sessions. One of the therapists uses the
assembler tile to program and then configure  tiles to take part in the ther-
apeutic activity concerning one of the children. She makes a puzzle game
with stable and blinking light feedback to indicate the different states of the
system. While she is at lunch, her colleague takes  tiles to use with another
child. By mistake, she includes one of the tiles configured in the ‘first’ game.
As the first therapist returns after lunch, she tries to continue the activity.
Now one of the tiles acts in a strange way, or not at all. As the second ther-
apist now has finished her work, the first therapist cannot consult her to
realize that she might have altered the game. As the first therapist perceives
the situation, the Active Surfaces worked before lunch, and now they do not.

In distributed and resource constrained systems, many error situations can oc-
cur and normally it can be hard for a user to find the reason behind a problem or
a mismatch. e assembler tile introduced before in this paper, can, besides being
used in the therapeutic activity, also be used as an inspection tool. e therapist can
utilize the IR communication protocol to inspect the running services within each
tile. rough the inspection the therapist can understand what services and assem-
blies are running, how they are configured and detect whether there are resource
problems that have to be solved. e therapist starts to inspect the game service,
and realizes immediately that the tile configuration has been altered. It was not a
system error. e therapist reconfigures the tile and can carry on the activity in the
swimming pool.
e Active Surfaces system has been developed together with the users (mainly
therapists) of the system. e use of the Participatory Design [] method includ-
ing different iterations of mock-ups, prototypes and Wizard of Oz [] sessions
indicate that end-users can perceive and control the Active Surfaces as described
above. Further full-scale trials have to be carried out to fully support this claim.
e simple scenario demonstrates the need for inspection and user control.
Here the therapist initially perceives the behavioral mismatch as a bug or error in
the system. In reality all components behave as they should, but one of the tiles
have been reconfigured without the knowledge of the current user. It is an example
of an error occurring over time in one of the distributed components, even when
the system should have been idle. e user must be provided with tools that allow


 .. Conclusions and Future Work

him to understand or ‘look inside’ the system to overcome the mismatch. It is im-
portant that the user understands that this is not an error; it is a misconfiguration
that can be overcome.

. C  F W

In this paper we have described the implementation of the Active Surfaces proto-
type, which is used in physical and cognitive rehabilitation work. We have shown
in an example scenario how palpable qualities in a system can be valuable when the
system behaves in unexpected ways. In those situations, it is beneficial for the user
to have a system that is built as a set of services combined into assemblies. Palpable
system allows for inspection, so errors and misconfigurations can be located and
corrected by end users.
e Active Surfaces prototype has been implemented in a distributed, embed-
ded system, executing in a set of floating tiles, and in a simulation framework run-
ning on a standard PC. Experiences gained during the work on the prototype pro-
vide input to the on-going development of the PalCom assembly concept. e
prototype implementation has helped concretize requirements for supporting more
powerful coordination logic, including coordination based on broadcast communi-
cation. e structure of the tile games calls for assemblies that span over multiple
physical devices, and for decentralized assemblies that do not require particular de-
vices always to be present. When assembly descriptions can express such behavior,
less coordination logic has to be delegated to unbound services.

Acknowledgements
anks to Laura Cardosi, parents and children for their open-minded collabora-
tion and continuous support during fieldwork and participatory design. We also
would like to thank our colleagues at our universities, especially Alessandro Pollini,
Patrizia Marti, Alessia Rullo, Boris Magnusson, Jacob Frølund, Henrik Gammel-
mark, and Mie Schou Olsen. e research was part of the European IST project
PalCom.


C Ո 

H    

   
Jeppe Brønsted and Klaus Marius Hansen

Abstract

In ubiquitous computing, as more and more devices are introduced into

the environment, new applications are made possible that exploit device ca-
pabilities in new ways. Currently, however, there is a mismatch between the
effort involved in implementing these applications and the benefit they pro-
vide. A proposed solution is to use a service oriented architecture and imple-
ment applications as composite services. As long as the set of services that
constitute the composite is static, traditional techniques can be used to spec-
ify the composite. In this paper we show how the PalCom service compo-
sition language can be extended to support service composites with dynamic
membership and present a decentralized implementation. Preliminary user
studies indicate that the extensions are easily understandable and simulations
of application scenarios show that the performance of the implementation is
appropriate for ubiquitous computing applications.

. I

As more and more devices are introduced into our daily lives the vision of ubiquitous
computing approaches realization. Devices interact in new ways to provide services
supporting users in home and work situations that were not possible until recently.
Currently, services incorporating multiple devices are typically implemented by
device manufacturers to add increased value into their products and thus the pos-
sible applications are limited by what devices a particular company manufactures.
Even when manufacturers cooperate to make their devices communicate using, e.g.,

Published as:
Jeppe Brønsted and Klaus Marius Hansen. Handling membership dynamicity in service composition
for ubiquitous computing. Accepted for publication in: International Conference on Mobile Ubiquitous
Computing, Systems, Services and Technologies, UBICOMM ’ , . Acceptance rate: 
A previous version was published as a workshop paper:
Jeppe Brønsted and Klaus Marius Hansen. Handling membership dynamicity in service composi-
tion for ubiquitous computing. In Proceedings of the th MiNEMA Workshop, Magdeburg, Germany,
September 


Chapter . Handling membership dynamicity in service composition

open standards it is hard to predict which services the users want and which devices
to combine. Furthermore, if a given service involves a particular set of devices, the
service will only be available to users having that particular set of devices. Consider
the following geotagger example mentioned in []:

A user has a GPS device, a digital camera, a mobile phone with GPRS, and a
home server. When pictures are taken they are automatically tagged with positional
information from the GPS and uploaded to the server using the mobile phone.

In this application its not clear which manufacturer would implement the appli-
cation since all the devices involved can be used for multiple purposes and should,
e.g., the phone manufacturer decide to implement the service, it would only be of
use to the subset of customers having the particular relevant device constellation.
Another issue with applications consisting of multiple devices interacting is that
if a fault occurs, it can be hard to determine the cause. In the above example, the
GPS device could run out of battery and unless the application has been designed
with that particular contingency in mind, the user has to check each of the devices to
resolve the situation. Another problem could be that the GPS device is configured
to send messages in a format that is not understood by the application. In this case
the user is probably even worse off because all devices will appear to be working
correctly.
If device capabilities are exposed through service interfaces, anyone with ac-
cess to the interfaces can, in principle, develop applications exploiting the devices
and thus the manufacturers will not have to try to anticipate every combination a
particular device might be involved in. To achieve maximum interoperability the
manufacturers have to agree on a format for service specifications or at least make
available the formats used. Whether the manufacturers are interested in this is not
the topic of this paper but if a standard was agreed upon the utility of the devices
would be enhanced.
When users compose services into applications, it is problematic to handle com-
posites with a varying number of members. An example could be a chat applica-
tion that dynamically includes new devices as they arrive. If the application was
expressed in source code, this would typically be handled by collections and spe-
cialized logic specifying how the composite evolves over time. Since source code is
not understandable by end users in general, we do not consider this to be an option.
e contribution of this paper is twofold. Firstly, we present an extension of
the PalCom assembly script language that makes it possible to specify assemblies in
which the member set varies over time. We demonstrate that the extended language
is expressive enough for realistic applications by showing how a prototype scenario
from the PalCom project can be implemented. A preliminary user study indicates
that the language extension is suited for ubiquitous computing applications, that it
is not hard to understand, and that it is only mildly complicated to use. Secondly, we
present an implementation of a decentralized interpretation engine. Experiments


 .. Related Work

show that the performance of the engine is appropriate for ubiquitous computing
applications.
e rest of the paper is structured as follows. e following section describes
related work. In section . we briefly describe the PalCom architecture and
the mechanism available for composing services into applications. In section .
we present the prototype scenario and the problems involved in realizing it using
traditional techniques. In section . we describe the extensions for handling
membership dynamicity, describe how the prototype scenario can be realized us-
ing the extended assembly scripts, and present results from the user study. Sec-
tion . presents the implementation and performance experiments and, finally,
section . concludes the paper and presents future directions.

. R W

Service composition have previously been used to implement applications for ubiq-
uitous computing environments []. Service orientation alone will not solve the
problem of creating services exploiting the particular device set a user has. If appli-
cations are implemented by developers using a service composition framework [,
, ] it is hard for the user to control which services are used, how they are
connected, and how they interact. Another option is to let the user try to specify
the task he wants to solve in an abstract way and let the middleware determine how
services should be composed [, ]. is has the benefit that the user does not
have to know which services are offered by the devices but only has to be able to
specify the task to be solved. On the other hand, if a failure occurs, it can be hard
for the user to find the error because the user’s understanding of the system is rooted
in the abstract task specification. A third option is to let the user experiment with
devices and services and manually compose the application [, , ]. is re-
quires that the composition language or tool is sufficiently understandable and at
the same time complex enough to make it possible to express useful applications.
In [] a composite with a varying member set can be defined using an LDAP
query over service properties, but here the flow of service invocations is specified in
source code. To the best of our knowledge, none of the previous approaches deal
with user-defined composites with varying member sets.
Both centralized [, , ] and decentralized [] algorithms have been
used to govern the flow of service invocations in the composite.

. T PC O A

In the PalCom project [] an open architecture [] has been developed that
supports users and application developers in making more understandable applica-
tions. Using the architecture and the runtime system, applications can be built by
composing services through scripts []. e scripts can be defined by applica-
tion developers or by users interacting with a service browser []. Services can
be composed at runtime and the internal structure of the composite can be opened


Chapter . Handling membership dynamicity in service composition

up and inspected in case of a failure or a misconfiguration. Being able to inspect

the running system supports users in understanding how the application works and
determine in which part of the system a failure is located. e composite can be
altered at runtime by replacing services with alternates to resolve failures or to adapt
the application to changing network conditions.
e design of the architecture and the scripting language has been guided by
requirements arising from a set of prototype scenarios developed in cooperation
with users using participatory design techniques. e scenarios cover a broad range
of application areas including support for major incidents, on site work by landscape
architects, and rehabilitation of children with Downs syndrome. e scenarios have
in common that they exploit combinations of digital devices to better support work
situations and that they do not assume that a fixed network infrastructure is in place.
In PalCom, composite services called assemblies consist of simple event-based
scripts that declare services and devices and describe the flow of events through the
assembly. is is an easily understandable way of composing services and handles
static situations with few devices well. However, the script language has currently
no support for composites where the set of members varies over time. Furthermore,
a URN [] for each of the involved services must be known when the composite
is created. is implies that it is, e.g., not possible to specify a composite that will
dynamically include new devices of a particular type as they arrive.

.. PalCom Assemblies

In the PalCom architecture device functionality is encapsulated in services that can

be remotely discovered and invoked. Each service has a set of commands that can
be either in-going or out-going. In-going commands are similar to asynchronous
methods with an optional number of parameters. ey can be invoked from other
services or by the user. Out-going commands makes it possible for the services to
provide output. e output can be used as input for in-going commands or can be
presented directly to the user. e output has an optional number of parameters.
An example could be a service acting as an interface for a lamp. e service would
have two in-going commands on and off and an out-going command state that
is invoked every time the state of the lamp is changed. Services and commands are
composed in assemblies described by assembly scripts where services and devices
are declared along with a description of which commands are connected. Variables
that can hold state can also be declared.
e example given in the introduction can be implemented by the assembly
script listed in figure .. Lines – declare which devices take part in the as-
sembly. Note that a unique name (URN) is given for each of the devices. Sim-
ilarly, lines – declare the services in the assembly. In line – the flow of
events through the assembly is described. E.g., lines – specify that when the
out-going photo_taken command from the camera’s photo service is invoked, the
tagger service’s tag_photo command on the mobile phone is invoked. In line  a
variable is declared with a MIME-type [] and in line  a value is assigned to


 .. e Site Sticks Scenarios

 assembly GeoTagger {
 devices {
 gps = urn:palcom://gps;
 camera = urn:palcom://camera
 server = urn:palcom://server;
 mobile = urn:palcom://mobile;
 }
 services {
 gps on gps = /gps;
 photo on camera = /photo;
 tagger on mobile = /tagger;
 photo_db on server = /photo_db;
 }
 connections {
 ...
 }
 script {
 variables {
 text/nmea-0183 gpsCoord;
 }
 eventhandler {
 when position from gps on gps {
 gpsCoord = thisevent.NMEA-0183;
 }
 when photo_taken from photo on camera {
 send tag_photo(thisevent.Image, gpsCoord)
 to tagger on mobile;
 }
 when photo_tagged from tagger on mobile {
 send store_photo(thisevent.Image)
 to photo_db on server;
 }
 }
 }
 }

Figure .: Geotagger script

it. e script in figure . can be created by using a text editor or by the user by
interacting with a tool.

. T S S S

Since the users are involved in creating the assembly scripts, an important design
goal is that the script language is as simple as possible. One could easily use a general
programming language to implement the assemblies, but this would defeat the goals
of simplicity and understandability. e assembly script language has to be as simple
as possible while at the same time powerful enough to support relevant scenarios.
In this section we present the PalCom scenario Site Sticks [] where a composite
service with a dynamic member set is required for realization. e scenario has been
developed in cooperation with landscape architects from Edinburgh.
When landscape architects try to visualize how a project will blend into the
landscape at a building site, a typical approach is to place marker sticks that repre-
sent the shape of buildings, roads, gardens, etc. as outlined in the digital building


Chapter . Handling membership dynamicity in service composition

plans. Looking at a site with hundreds of sticks (see e.g. figure .) it can be
hard to figure out which sticks represent a particular building. e challenge is to
visualize the digital design combined with the physical reality.

Figure .: Site Sticks

In the site sticks scenario, each stick is equipped with an embedded system with
wireless communication. When the stick is placed in the ground, the position and
role in the design is registered in the stick using a GPS device and a PDA. Later,
when the architect wishes to visualize a particular part of the design, he can select
the part on the PDA and the corresponding sticks will light up with a distinct color.
e initial placement and the registration will not be dealt with in this paper.
From a conceptual point of view it is natural to express the application that
makes a subset of the sticks light up as a composite service consisting of the sticks
and a PDA. However, the scripting language presented in section .. provides
only limited support for the description of the assembly. One limitation is that
the script will be big because all devices and services have to be declared explicitly.
Another is, that the assembly cannot be expanded to include more sticks without
changing the script. In the following section we propose extensions to the assembly
scripts that will make it possible to express the application described more naturally.

. H M D

e extensions of the assembly scripts we propose can be divided into two parts:
Selection is about selecting which devices should participate in the assembly and


 .. Handling Membership Dynamicity

naming deals with how to represent the services and devices in the specification of
the flow of events.

.. Selection

Given a set of nodes we need a method for selecting those that should be part of the
assembly. In the unextended version of the scripts this is done using URNs but for
assemblies with dynamic membership this is, as mentioned previously, not enough.
Instead, we propose to use a simple wildcard pattern on the device URN so that
a single line in the device declaration part of the script (lines – in figure .)
can declare multiple devices. Lines not including a wildcard character (‘*’) will be
interpreted as before. As an example, the line:

stick = urn:PalCom://stick*

matches all devices with a URN with the prefix urn:PalCom://stick. Hereby, all
the sticks in the site sticks scenario can be declared in a single line.
While wildcards provides an easily understandable way of specifying a lot of
devices, it has the drawback that semantic information has to be encoded in the
device URN. In situations where devices with similar URNs have different service
sets, it can be a problem only to include a subset of the devices in the assembly.
erefore, as an additional method for selection, we also use the information already
present in the service declaration part of the script (lines – in figure .) to
exclude irrelevant devices.
For example, line  in figure .:

photo_db on server = /photo_db;

declares that all devices matching the declaration of server must have a photo_db
service. If a device has a URN that matches the server declaration but does not
have a photo_db service, the device is not included in the assembly.

.. Naming

With the extension mentioned above, each line in the device and service declaration
parts of the script potentially declares multiple devices/services and associates a
name. is name is used in the eventhandler part of the script to specify the flow
of events. We extend the semantics of the eventhandler part so that the line:

when photo_tagged from tagger on mobile {

is used when the out-going command photo_tagged is invoked on any mobile de-
vice. In the case that mobile only denotes a single device, the interpretation is
unaltered. Similarly, the interpretation of the invoke part of the eventhandler is
changed so that the line:


Chapter . Handling membership dynamicity in service composition

send store_photo(thisevent.Image) to photo_db on server;

will invoke the store_photo in-going command on all the devices denoted by
server. Again, if server only denotes a single device, the interpretation is un-
altered.
To allow for local flow of events on devices declared with a wildcard, the key-
word ‘local’ can be inserted into the send statement to denote that only services on
the same device are invoked. Assume for example that my-device is declared using
a wildcard and the eventhandler includes the following lines:

when my-out-command from my-service-a

on my-device {

send local my-in-command()

to my-service-b on my-device;

en, when the my-out-command is invoked on a particular device, the my-in-command

will only be invoked on the same device.
e modifications above all have the property that if no device is declared using
a wildcard, then there is no modifications of the interpretation of the assembly
scripts. is implies that the changes are backwards compatible.

.. Implementation of the Site Sticks Scenario

We claim that the mechanisms for selection and naming described above can be
used to implement the site sticks scenario in a simple and natural way. When placed
in the ground, each of the sticks are assigned a set of group identifiers corresponding
to their role in the building plan.
Assume all sticks are equipped with two services, led and group. e led service
has a single in-going command set that will turn the light on the stick on or off. e
group service has an in-going command is-part-of and two out-going commands,
true and false . If is-part-of is invoked with a building identifier that the stick
represents a part of, the true command is invoked - otherwise the false command
is invoked.
e PDA has a stick-gui service where the user can specify which part of
the building plan he wants to see. e stick-gui service has a single out-going
command group-selected that will be invoked with a group identifier when the
user selects a building.
Given the services and devices described above, the site sticks scenario can be
implemented by the script in figure .. Line  declares the sticks using a wildcard.
Lines – forwards the user specified building ID to the sticks and if the stick
represents part of the building specified, the stick will be told to blink in lines –
- otherwise it will be told to turn of in lines –.


 .. Handling Membership Dynamicity

 assembly SiteSticks {
 this = global-service-name;
 devices {
 stick = urn:palcom://Stick*;
 pda = urn:palcom://PocketLoox;
 }
 services {
 led on stick = /led;
 group on stick = /group;
 stick-gui on pda = /stick-gui;
 }
 connections {
 ...
 }
 script {
 eventhandler {
 when group-selected from stick-gui on pda {
 send is-part-of(thisevent.GroupId) to group on stick;
 }
 when true from group on stick {
 send local set('on') to led on stick;
 }
 when false from group on stick {
 send local set('off') to led on stick;
 }
 }
 }
 }

Figure .: SiteSticks script

e script in figure . expresses the site sticks application in a natural way
because it only contains a representation of the physical elements of the application
(the sticks and the PDA), the base functionality of these elements (the led service,
the group service, and the PDA gui service), and the connections among these
functionalities (the eventhandler script).

.. User Study

A primary design goal behind the wildcard mechanism is to support assemblies with
dynamic membership without making the mechanism too complicated to use. To
evaluate the suitability, understandability, and complexity of the wildcard mecha-
nism we conducted an experimental user study with  participants.
First, the participants were introduced to the PalCom framework and assembly
scripts through a PowerPoint presentation and a demonstration. en, each partic-
ipant used assembly scripts to solve a set of problems. Afterwards, the participants
filled out a questionnaire .
e results are summarized in table .. As can be seen, all respondents esti-
mated the understandability of the wildcard extension to be of neutral understand-

¹Presentation, questionnaire and complete result set can be accessed at http://www.daimi.au.

dk/~jb/PalComEvaluation or by contacting the author


Chapter . Handling membership dynamicity in service composition

ability or easy to understand.  of  replied that it is not complicated or mildly

complicated to use the extension, and  of  replied that the wildcard extension is
suited or very suited for making dynamic composites from ubiquitous computing
devices.
While further studies are required to increase the confidence in the results, the
experimental study indicates that users find the wildcard extension not hard to un-
derstand, that it is only mildly complicated to use, and that it is suited for ubiquitous
computing applications.
How understandable is the How complicated is it to the How suited is the wildcard
wildcard extension? use the wildcard extension?a mechanism for making dy-
namic composites from ubiq-
uitous computing devices?a
Not understandable  Not complicated  Very unsuited 
Hard to understand  Mildly complicated  Unsuited 
Neutral understandability  Complicated  Neutral suitability 
Easy to understand  Fairly complicated  Suited 
Very easy to understand  Very complicated  Very suited 

a
Only  participants responded to this question

Table .: Experimental user study

. D I

One way to interpret the assembly scripts is to let a central node handle the even-
thandler part (e.g. lines – in figure .) of the scripts. Every time an out-
going command is invoked, a message is sent to the central node, which then de-
termines which in-going commands should be invoked. As long as the assemblies
only include a few nodes all connected to the same network, centralized interpreta-
tion is a viable option. However, for assemblies like the site sticks assembly it is not
a good idea because the group service’s invocation of the led service (lines – in
figure .) would have to go through the central node. erefore, we argue, it is
necessary to interpret the scripts in a decentralized manner.
Unlike its centralized counterpart, decentralized interpretation requires that all
nodes are able to interpret parts of the scripts and this excludes a class of devices with
very limited resources. An alternative to completely decentralized interpretation is
to relieve some nodes of the interpretation responsibility. is, however, requires a
method for selecting the nodes taking over the responsibility and has been left as
future work.
Two steps are required to interpret an assembly script in a decentralized manner
on a set of nodes. Firstly, the script needs to be distributed to a subset of nodes
(possibly all), and secondly some nodes have to make the out-command events
propagate into in-going command events. In the following we present some of the
design considerations behind our implementation.


 .. Decentralized Interpretation

Distribution Clearly, a node should have a representation of the script (or at least
a part of the script) to be able to interpret the script. Since the set of participating
nodes can vary over time, it cannot be assumed that all nodes are present when the
script is first executed and therefore the network should continuously be monitored
to include newly arriving nodes. To avoid that the assembly stops working if a
single node disappears, we let all nodes monitor the network.

Event propagation Decentralized interpretation is implemented by letting each

node handle a part (possibly empty) of the eventhandler script. is amounts to
invoking in-going commands when out-going commands are invoked by the ser-
vices.
When the member set of an assembly varies over time it is important that the
interpretation responsibility is divided in such a way that nodes leaving the network
have as little influence as possible on the execution of the assembly. is means that
if an out-command on node N should result in the invocation of an in-command
on node N, the responsibility of handling this event transformation should be
placed on N or N. Hereby, that part of the assembly only fails if N or N fails.
We divide the handling of each eventhandler part of a script according to the
following simple rule: An eventhandler clause should be handled by the node orig-
inating the out-going command in the clause. As an example, the eventhandler
clause in line – in figure . is handled by the pda node because the out-
going command invocation comes from the pda. Similarly, lines – should be
handled by each of the sticks. Using this rule, all invocations with local scope will
only result in intra node communication. is is not, in general, guaranteed with
centralized interpretation.

.. Performance

To estimate the time for a command to successfully propagate from the PDA to the
sticks in the site sticks scenario, we simulated the scenario on a set of PCs.  PCs,
connected through Ethernet, were each running a number of Java virtual machines.
e scenario was simulated with  to  nodes implying that one to six Java virtual
machines were running on each PC. For each node count commands were sent
periodically every two seconds for a period of  seconds. For every command
sent, we measured the propagation time.
In figure . the mean command propagation time along with  confidence
intervals are shown. As can be seen in the figure, the mean propagation time in-
creases approximately linearly with the number of nodes. In all the experiments,
the mean propagation time was below  milliseconds, which is appropriate for
the scenario.


Chapter . Handling membership dynamicity in service composition

Figure .: Mean command propagation time

. C

In this paper we investigated the problem of handling composite services with dy-
namic membership. We presented extensions of the PalCom assembly scripts that
make it possible to specify composites with dynamic member sets and showed how
a prototype scenario from the domain of landscape architects could be implemented
using the proposed extensions. e idea behind the language is a basic case con-
struct that specifies the flow of service invocations. A visual representation of the
language might further support the user in understanding the scripts.
A preliminary user study indicates that the language extension is suited for ubiq-
uitous computing applications, that it is not hard to understand, and that it is only
mildly complicated to use, but further studies are needed to increase the confidence
in the results. We presented an implementation of a decentralized interpretation
engine and experiments showed that the performance of the engine is appropriate
for ubiquitous computing applications.
e suggested decentralized interpretation requires that all participating nodes
are able to interpret the script and that can be a problem for very resource con-
strained devices. More powerful devices acting as proxies for the limited devices
could be one way of handling this. In contrast to its centralized counterpart, the
decentralized interpretation has the potential to scale better since no node has the
sole responsibility for all communication in the assembly.


 .. Conclusion

A

e author acknowledges the work done by the participants of the PalCom project
to develop prototype scenarios and design and implement the PalCom open archi-
tecture and associated tools. e work presented in this paper has been supported
by ISIS Katrinebjerg (http://www.isis.alexandra.dk) and by PalCom [].


C Ո 

I  S C  P C

Jeppe Brønsted, Klaus Marius Hansen, and Mads Ingstrup

Abstract

Composition of services, i.e. providing new services by combining existing

ones, is an idea pervading and thus important to pervasive computing. How-
ever, compared to other areas of computer science, pervasive computing tech-
nologies are more openended, context aware, dynamic, heterogeneous, often
use networked sensors and actuators, and present new challenges to usability.
ese six characteristics pose requirements to the design of service composi-
tion mechanisms that are unique to pervasive computing. We catalogued the
technologies that in one form or another can be said to support service com-
position for pervasive computing, and describe their variation points. ese
variation points in the design of existing composition mechanisms are impor-
tant indicators for how well the resulting composites are able to cope with and
exhibit the six key characteristics of pervasive computing. Our assessment of
the selected technologies indicate that there is a need for more research into
providing appropriate security for composites; into managing the contingen-
cies which arise naturally in a pervasive computing environments; and for do-
ing more thorough evaluation of the technologies, both with respect to utility
and performance.

. I

e ability to seamlessly compose the services from various devices in a more or

less ad-hoc manner is a frequently emphasized feature of ubiquitous computing (cf.
e.g. [, , ]). Given the abundant mention of this feature in visions and
scenarios, one would expect a sizeable body of research and development work ded-
icated to its realization. However, in practice we have found far fewer cases than ex-
pected where service composition for ubiquitous computing has been a main focus
of research efforts. By “main focus” we mean that actually designing, implementing
and evaluating a composition technology has been a main part of the contribution

Under submission. A previous version was published as a workshop paper:

Jeppe Brønsted, Klaus Marius Hansen, and Mads Ingstrup. A Survey of Service Composition Mecha-
nisms in Ubiquitous Computing. In UbiComp  Workshop proceedings, pages –, . Second
Workshop on Requirements and Solutions for Pervasive Software Infrastructures (RSPSI)


Chapter . Issues in Service Composition for Pervasive Computing

of the work. With that said, however, work has been carried out in the area. In
this paper we take a look at this work and draw out the experiences and lessons it
holds for continued development of the field. ere are two primary reasons that
prompted us to do this work.
Firstly, we believe, with our colleagues whose work we survey, that there is a real
need for good composition mechanisms. is need arises on a variety of temporal
scales, including, for instance, the user on fieldwork who is prompted by immediate
circumstance to compose a set of services that allows a display on a GPS device to
temporarily replace a broken one on an otherwise functional cell-phone. Or the
administrator who needs to tailor commercially acquired services to the needs of
people in his or her particular organization. Towards the goal of developing a good
service composition mechanism, our contribution is to help understand what “good”
might mean when talking about service composition for ubiquitous computing, or
rather to give an account of advantages and disadvantages of various approaches
and identify areas that need further attention from the research community.
Secondly, we wish to support the claim of service composition for ubiquitous
computing as an area of study in itself. Composition is a natural concept around
which to structure ubiquitous systems and individuate parts of it that are suitably
subject to e.g. contingency management, application, or storing, as witnessed by its
frequent use as a new and more open-ended replacement for the traditional appli-
cation concept of desktop computers. When a composition of services is utilized
as a unit of application, deployment, storing, or adaptation it becomes a natural
frame for addressing systemic issues such as performance, usability, security, etc.
which are not determined by any particular service, but largely by the system archi-
tecture—how services are combined. is makes service composition a viable topic
of research in itself.
Some service composition and related techniques exist in computer science,
but the composition of services in a pervasive computing environment poses new
challenges. Pervasive computing technologies are characterized by being openended,
context aware, dynamic, heterogeneous, and they may incorporate networked sensors
and actuators. Furthermore, they present new challenges to usability.
While any given application of pervasive computing does not necessarily exhibit
all these traits, several of them are more and more often found at the same time.
is means, first, that existing composition technologies are often not adequate(see
section ..) and that, second, there is a research challenge in understanding how
to do service composition in a pervasive computing environment.

Dynamicity includes changing availability of services and network connectivity.

In a pervasive environment, a given service in a composite may become unavailable
and need replacement. e logic for discovering and inserting a replacement ser-
vice cannot be located in any of the constituent services, because they may become
unavailable. erefore, contingency management is a concern for the composition
mechanism.


 .. Introduction

Context awareness. A Service composite can be context aware either if it is itself

sensitive to changes in context or if its constituent services are context aware. A
service composite may itself be context aware if the set of composed services varies
with changes in context. A commonly used example of such a service is one for
printing, which is often selected based on location.

Heterogeneity has several dimensions. e amount of resources available for com-

putation, storage and communication varies a lot from device to device. In terms
of mobility, devices embedded in buildings are highly static while personal devices
or those built into vehicles may be highly mobile.
Largely orthogonal to these other dimensions of heterogeneity is the middle-
ware and information models that devices are equipped with and its embedded ser-
vices therefore rely on. is kind of heterogeneity is an important concern because
it may hinder interoperability.

Networked sensors and actuators are in many cases used in pervasive computing sys-
tems, often to retrieve context information or for more application specific purposes
of sensing and control.

Usability. In applications of pervasive computing, new models of interaction are

needed because a desktop-based computer interface structured with distinct appli-
cations is no longer always available nor practical. Instead, the “applications” of
pervasive computing may be composites of services targeted towards supporting
particular user tasks, perhaps composed and recomposed by users themselves ac-
cording to their individual and changing circumstances of engaging with pervasive
technology.
Although the traditional view is that usability is first and foremost determined
by the user interface of systems, there are several ways in which the architecture
may strongly influence the usability of a system, e.g. the support for undo func-
tionality []. Likewise, we find that certain features at technical level are key to
supporting a model of use envisioned for pervasive computing.

Openendedness. Traditional systems and applications tend to have a fairly well de-
fined application and problem domain. is is often not the case for devices and
services that make up a pervasive system. us a cell phone, while certainly de-
signed to be used as a telephone, is being used for broad variety of other purposes,
including payment, navigation, music playback, and photography. A move from
mobile technology to pervasive technology requires techniques that are able to cope
not just with the openendedness of how devices like cell phones are used in isola-
tion, but with the ways in which they are combined to achieve additional value. is
challenge is what service composition for pervasive computing seeks to address.
ese characteristics have implications for service composition, but not in a
straightforward way. Because a composite of services depends on other services


Chapter . Issues in Service Composition for Pervasive Computing

for realizing its behavior, its properties depend to some degree recursively on the
properties of its constituent services.
If, for instance, one wishes a given composition to have new functionality that
can often be achieved either in the logic of the composed service or by modification
or replacement of a constituent service. erefore, the design of a service composi-
tion mechanism is a stronger determinant of the qualitative than of the functional
properties of the service compositions, and it is with the qualitative aspects our main
focus in this paper lies.

.. What Makes Service Composition in Pervasive Computing Special?

Service composition (also know as “service federation” or “service orchestration”)

has arguably been an issue since the advent of the service concept in distributed
computing. Several different technologies provide service composition mecha-
nisms:

(Web) Service technology A range of composition mechanisms is available for web

services including BPEL, OWL-S, and Web Components []. BPEL supports
composition through the specification of processes that combine services (partners) in
a procedurally specified workflow. With Web Components [], services are com-
ponents that may, e.g., be reused and specialized. Furthermore, a Web Component
may encapsulate compositional logic in the form of sequential, parallel, conditional,
or iterative compositions. Further solutions in the web service area include using
π -calculus and Petri nets to specify composition [].

Agent technology A basic tenet of agent-based system is that agents should be so-
cial, i.e., an agent should be able to interact with other agents to solve problems [].
Abstractly, Agent Interaction Protocols can be modeled, e.g., with UML interaction
diagrams through Agent UML []. Concretely, the JADE agent middleware []
supports interaction protocols as specified by the Foundation for Intelligent Phys-
ical Agents’ (FIPA’s) Agent Communication Language [].

Middleware technology CORBA is a widely used middleware also for embedded

systems. CORBA does not inherently support composition []. However, two
specifications provide some support: the CORBA configuration specification []
describes assemblies which may package components and connect components whereas
the IDLScript extension [] allows for dynamic scripting of CORBA server ob-
jects and thus for a form of service composition.
As noted by [], a technical solution to service composition needs at to con-
sider at least

. Planning involving discovery of candidate services and checking of compos-

ability and performance. e desired dynamicity and openendedness of per-


 .. Indicators for Characteristics

vasive computing puts demands on this phase. In particular, discovery at

runtime should preferably be supported.
. Definition involving the actual generation of the specification of service com-
position. e heterogeneity and openendedness of pervasive computing means
that definitions may have to take into account different, possibly a priori un-
known, service classes.
. Implementation of the composite service bindings. In pervasive computing,
dynamicity and context awareness means that the runtime of a service com-
position needs to be highly dynamic.
Web service composition, for instance, which do support building distributed
systems, is not appropriate because it cannot adequately cope with high degrees of
dynamism [], and it cannot run on very small devices, so coping with heterogeneity
in device size requires workarounds.
e special requirements for pervasive computing in the three phases of ser-
vice composition are not well supported by the three technologies. Web services,
agents, and CORBA may be (and are) used as middleware for pervasive computing,
but specialized solutions need to be considered for service composition in order to
provide support for pervasive computing.

. I  C

Looking at a range of service composition mechanisms, we identified a set of vari-

ation points that serve as indicators for the support for each of the characteristics
described in the introduction. e service composition mechanisms were selected
according to the following criteria:
• We only considered architectures that enable composition of services. We
defined a service to be a unit of runtime software accessible by others.
• A composite is a grouping of services interacting with certain purpose
• e technologies should be targeted towards ubiquitous computing. As a
minimum, this means the range of devices the technology works with is not
limited to desktop PCs, and that it allows for distributed deployment of the
composed services.
Other constraints such as on prominence, availability of technical documenta-
tion and adequate evaluation has played a role albeit we have not used strict selection
criteria on these issues.
For the sake of simplifying the description of the indicators, a general model of
the process of composing services is depicted in figure .. e following features
of the model are used as variation points in the technologies catalogued. Table .
shows the technologies catalogued. In the description below the indicators are in
italics.


Chapter . Issues in Service Composition for Pervasive Computing

A composite is specified by a specifying actor (end-user or developer). e com-

posite is specified at development time or runtime and it can be specified in a config-
uration file, in source code or directly through end-user interaction. In the speci-
fication, the level at which a service is specified may be instances, types or implicit
specification. e specification sometimes allow for expression of quality of service
requirements, though the expressiveness varies a lot. At runtime, the composition
mechanism has a resource use suited for a class of devices (a PDA, a Desktop PC, or
both, for the surveyed technologies). For a service composite, there may be support
for managing contingencies at runtime. e composite may rely on a fixed or ad-hoc
infrastructure and have either centralized or decentralized topology.

Composite

Service
Specifies Specification Instatiated Service

Specifying Service
Actor
Optionals

Figure .: A general model of the elements in service composition.

. C/I D

Each of the characteristics presented in the introduction are affected by one or more
of the indicators from the previous section. In the following, we describe how the
characteristics depend on the indicators and give examples of technologies that pro-
vide good support for the characteristics and thus are suited for service composition
for pervasive computing. Since some characteristics have overlapping indicators, we
present an overview in table ..

.. Context Awareness

For a pervasive computing system to be context aware, it should be able to respond

to changes in context by providing information or executing commands. If the
constituent services themselves are context aware, the system as a whole will also
exhibit context awareness. Here, we only focus on context awareness provided by
the composite.
We divide the support for context awareness according to when it is provided.
Before the composite is instantiated, support for context awareness can be provided
by selecting the services to participate in the composite based on context informa-
tion. Hereby, a composite specification can result in different composites according


 .. Characteristic/Indicator Dependencies

QoS requirements
Contingencies

Infrastructure
Resource use
Specified by

Specified in
Specified at

Topology
Level
Context Awareness x x x x
Networked Embedded Sensors and Actuators x x x
Heterogeneous Devices x x
Dynamicity x x x x
Openendedness x x x
Usability x x x

Table .: Characteristic/Indicator Dependencies

to which circumstances it is instantiated under. e level of the specification of the

participating services determines the set from which the services should be selected.
If, e.g., the services are specified by listing instances the room for selection is small.
e selection of the participating services can be determined by specifying quality
of service requirements or by selecting the services among the candidates that best
match type or functionality constraints.
At runtime, context awareness can be supported by providing contingency han-
dling. If the composition mechanism only supports detection of contingencies, it
is important that the composite can be modified or re-specified at runtime.
Amigo, DSCiPC, DSD, and Paths are predisposed for supporting context aware-
ness because they all have the features of using implicit specification of a compo-
sition, and because they do so at runtime. e use of implicit specification means
that they are able to resolve an abstract specification to a concrete composition of
services. If the context of a concrete service composite changes such that it is no
longer an appropriate resolution of its abstract specification, then it would take a
mere re-activation of the resolution process to arrive at another concrete compos-
ite that is appropriate to the changed context. Having the composite specified at
runtime ensures that such resolution can indeed be performed at runtime.
Composites realized in Amigo, DSCiPC, or DSD can automatically resolve
contingencies at runtime and since these technologies also allows for quality of
service requirements in the composite specification, the set of context changes the
composite can react to also includes quality of service parameters.

.. Networked Embedded Sensors and Actuators

A prerequisite for including embedded nodes in a composite is that the composition

mechanism is designed so that the resource requirements for the embedded nodes are
suitable. Typically, this implies that not all nodes are equal in the composite with
respect to monitoring connections, forwarding service invocations, etc., and there-
fore a centralized, or at least not completely decentralized, topology is preferable. If


Chapter . Issues in Service Composition for Pervasive Computing

the topology is completely decentralized, all devices must have a representation (or
at least a part of ) the composite specification, which makes it important that the
composite is specified in a compact form. An xml configuration is typically more
cumbersome than compiled source.
Of the technologies listed in table . the only service composition mechanism
that directly includes embedded nodes in composites is DSCiPC. Here, the nodes
are divided into a four-leveled hierarchy according to their resource availability. e
powerful nodes are responsible for service discovery, composition etc., whereas low
level sensors and actuators depend on other nodes to act as proxies.
 of the remaining  technologies only support PDA-like devices and can
thus only include embedded nodes by presenting their interfaces through services
developed for the purpose.  of these rely on a decentralized topology making it
important that the composite specification is compact.
e remaining two technologies require a JSE virtual machine on each node,
which significantly limits the set of nodes that can participate in the composite.

.. Heterogeneous Devices

Since it can be expected that pervasive computing applications will consist of het-
erogeneous devices, the composition mechanism should be designed to distribute
responsibilities in the composite based on device capabilities. It is not necessarily
good that the resource use of the composite mechanism is low, because this typically
implies that the functionality of the composite will be limited by the least capable
node. Rather, heavy tasks should be delegated to powerful nodes. is also implies
that a completely decentralized topology is not desirable.
Nodes can be heterogeneous in terms of computation capability, memory avail-
ability, communication capability, power availability, mobility, user interface, etc.
and therefore it is important that the composite is instantiated considering the avail-
able context. Optimally, the responsibility of managing the composite should be
distributed among the most capable nodes, considering the concrete requirements a
particular management task has. If, e.g., service descriptions are stored in a central
registry, the node hosting the registry should have high availability and should be
able to handle a high number of requests. Similarly, if the user can interact with a
composite management interface, the interface should be located in close proximity
to the user and on a device with suitable IO capability.
As mentioned above, DSCiPC distributes the management tasks according to
which class a device belongs to and have multiple versions of the middleware, each
suited for the particular device type.
Because different devices and services may rely on different interaction and in-
formation models, interoperability is an important and difficult challenge for service
composition in pervasive environments. Speakeasy is based on a thorough analysis
of this, and relies in its design on three key principles to further interoperability.
First, a small set of fixed and domain independent interfaces help ensure interoper-
ability by “not requiring each party engaged in an interaction to have prior domain


 .. Characteristic/Indicator Dependencies

specific knowledge of every entity it may encounter.” [, p. ]. Secondly, the
use of mobile code ensures that the set of fixed interfaces can acquire new behavior
as appropriate. Finally, “users are the ultimate arbiters of whether an interaction
among compatible entities occurs.” [, same, p. ].

.. Dynamicity

Software is more dynamic the more modifications can be done at runtime instead
of development time. For service composition, a key indicator for dynamicity is
when and in what form the composite is specified. We see in table . that in 
of the  technologies we have looked at, the composites are specified at runtime.
Further, in  of the  technologies the composite is specified in either end-user
interaction or in a configuration file. e odd combination of values for these fea-
tures is found is one.world, in which composites are specified in source code, but
at runtime. e services in one.world are applications which are programmed in
source code. An application operates within and is contained in an environment.
Environments can be nested, and composites can be specified across nested envi-
ronments. An outer environment can intercept all of the communications of an
environment nested within it, and can therefore to some degree reconfigure com-
posites specified across its nested environments at runtime. In principle this allows
a tool to handle composition at runtime, but there is to our knowledge no such tool
available in one.world.
Dynamic service availability can be supported by providing contingency han-
dling. In case of a fault, a replacement service should be found and/or the user
should be notified. In some applications, any node can enter or leave the network
at any time. Under these circumstances, the topology should be decentralized in
case the contingency handling node leaves, and the requirements for infrastructure
should only be ad-hoc.
Since we argued in section .. that a completely decentralized topology can
result in unsuitable resource requirements for embedded nodes, there is possibly a
tradeoff between the support for low end devices and contingency handling.
Quality of service requirements in the composite specification is necessary to han-
dle dynamism in network bandwidth, latency, and throughput.

.. Openendedness

In traditional systems, applications are closed and cannot be modified. is is in

contrast to pervasive computing environments where it cannot be expected that
the purpose and functionality of a composite application remains the same for the
lifetime of its constituent parts. It is often the case that applications of pervasive
computing need to be repurposed to match new user requirement or changes in
the context. When applications are structured in service composites, these need
to be changeable, preferable at runtime. To some degree, changes in context can
be resolved automatically (cf. section ..) but new user requirements are more


Chapter . Issues in Service Composition for Pervasive Computing

complicated to react to. Here, it is necessary that the user is in the loop, because
the system typically has no way of knowing of the new requirements.
If the composite can be specified by the end user, as it is the case for  of 
technologies in table ., the user actively takes part in communicating the appli-
cation requirements to the composition mechanism. Specification by the end user
implies that the composite is specified at runtime. Of the  technologies, PalCom
is the only one that does not let the composite be specified in end-user interaction.
In PalCom, the user has to make a configuration file specifying the composite.

.. Usability

Our main criteria for assessing the usability of a composition mechanism is whether
the composite services built with a given mechanism suit the users optimally given
what services are available for composition. A strong determinant of this is how the
service composites come to exist. Another is whether a composite, once created,
can adapt (or be adapted) to change of circumstance, such as due to contingent
availability of services and resources or changes in users’ intentions with the com-
position. We discuss the first issue below and the second in the next paragraph.
Regarding the first, we may question whether developer-specified, users-specified,
or e.g. automatic synthesis based on interpretation of high-level sentences []
leaves the user better off. e PalCom assembly concept is based on an elaborate
conception of this issue. It is held that autonomic, perhaps AI-based, composition
or developer-specified composition based on anticipation of the user’s needs are fine
in so far as the resulting composite does what the user wants it to. However these
approaches are for a variety of reasons not flawless and complete enough to work
consistently and so they need to be supplemented by architecture and tool support
that empowers the user to create composites or modify existing ones to suit their
purpose. []
us the way a composite service is specified is influential on usability by de-
ciding whether the users can specify composite services themselves (specified by),
whether they can do so at runtime (specified at ), and how it is done (specified in).
Only  of the  surveyed technologies enable end-users to specify composite ser-
vices.
Lack of support for end user composition appears in several cases to be due to
the focus of the research project in question rather than a fundamental constraint
of the architecture it produces: In  of the remaining  composition mechanisms
the composite is specified in a configuration file and at runtime. ese are arguably
only a composition tool away from supporting end-user composition, albeit the
configuration file format may be more or less constraining depending on its level of
support for scripting.
In general, the considered composition mechanisms may be geared more to-
wards the user or the developer. In ICrafter, for instance, the composition is ex-
plicit mainly in the tools used by the user, rather than at the architectural level.
Speakeasy, in contrast, does not provide tools for the end user to do composition,


 .. Discussion

but consists of a more general framework that developers can use in their applica-
tions.

. D

Quite a few service composition mechanisms exist of which we have only reported
on a subset, although we believe that subset to be representative. In doing so, how-
ever, it has been characteristic that no papers have focused mainly on service com-
position. Our analysis suggests that there are indeed both opportunities and reasons
for doing so.
In particular, service composition is entangled with several complex features
such as service discovery and matching, contingency management, and reconfigu-
ration. erefore, it provides a good frame around which to explore those features
and their interrelation. is, however, is an area where further research is needed:
the surveyed technologies only begin to scratch the surface of contingency man-
agement and efficient resource management. Likewise, more work is needed to
explore the relationship between manual and autonomic execution of functional-
ity. Concerning the notion of service composition, we found very limited signs of
research that leveraged the result of previous research in the area. Such leverage is
arguably easier to achieve with a common conceptualization of the research area,
and we consider this survey of issues a step towards that in addition to providing an
overview.
Most of the technologies presented are evaluated by demonstrating that the
composition mechanism can be used to implement various ubiquitous computing
applications. Example applications invented by applications developers typically
demonstrate a wide range of features whereas application scenarios developed in
cooperation with users, have emphasis on posing relevant challenges. In some of
the projects, it is evaluated how usable the composition mechanism is for users
and/or developers, and, finally, some projects present measurements of various
performance parameters. We note that only  of the  technologies have used
scenario-based evaluation. is means that for most of the technologies, there is
weak empirical support to a claim that the technology works in realistic settings.
e six characteristics that have been our locus of analysis constitute only a
subset of the qualities that may be important in a particular application of perva-
sive technology. We looked at these because they emphasize the design challenges
of composition mechanisms that are peculiar to pervasive computing. However,
a concrete design of a composition mechanism involves tradeoffs between these
qualities and efficiency and security.
Concerning efficiency, a specification working at the level of types (or is im-
plicit) must use additional resources on instantiation (cf. figure ..) compared to
an instance-based specification. For this tradeoff  of the  surveyed technolo-
gies have chosen the more flexible but poorer performing solution of type-based or
implicit service specification. However, lack of performance data prevents a quan-
titative assessment of that performance penalty.


 Composite Specification Runtime Deployment
System Specified by Specified at Specified in Level QoS req. Contingencies Resource use Infrastructure Topology Evaluation
Amigo [109, 148] End-users Runtime End-User int. Implicit Yes Automatic PDA+Server Fixed Centralized Sce. perf.
Aura [56, 141] End-users Runtime End-User int. Types Yes Automatic PDA+Server Ad Hoc Centralized Example
Daidalos [160] Unknown Runtime Configuration Types Yes Runtime Unknown Unknown Centralized Example
DSCiPC [79] App. Devs Runtime Configuration Implicit Yes Automatic PDA+Mote Ad Hoc Decentralized Ex., Perf.
DSD [8] App. Devs Dev. time Configuration Instances, Implicit Yes Automatic J2SE Ad Hoc Decentralized Example
GAIA [135] App. Devs Dev. time Configuration Types No Automatic PDA+Server Fixed Centralized Example
Chapter . Issues in Service Composition for Pervasive Computing

ICrafter [130] End-users Runtime End-User int. Instances No None PDA Fixed Centralized Example
Obje [41] End-users Runtime End-User int. Instances No Detection PDA Ad Hoc Decentralized Example
one.world [62,63] App. Devs Runtime Source Code Instances No Detection J2SE Ad Hoc Decentralized Sce., Usab., Perf.


Ozone (WSAMI) [75] App. Devs Dev. time Source Code Types Yes None PDA Ad Hoc Decentralized Ex., Perf.
PalCom [145] End-users Runtime Configuration Instances No Automatic PDA Ad hoc Centralized Scenario
Paths [86] App. Devs Runtime Configuration Implicit No None PDA Fixed Centralized Scenario
QuAMobile [2] App. Devs Runtime Configuration Types Yes Automatic PDA+Server Ad Hoc Unknown Scenario, Perf.
SCfME [32] App. Devs Runtime Configuration Types No Detection PDA Ad hoc Decentralized Performance
SpeakEasy [40, 42, 115] End-users Runtime End-User int. Instances No Detection PDA Ad Hoc Decentralized Ex., Usab.
TCE [100, 101] End-users Runtime End-User int. Instances No None PDA Ad Hoc Centralized Example
UbiDev [94] App. Devs Dev. time Source Code Implicit No Automatic PDA+Server Ad Hoc Centralized Example
Table .: Categorization of Service Composition Mechanisms
 .. Discussion

Further towards favoring the dynamicity/adaptability end of the dynamicity-

performance tradeoff, the specification of composites may support quality-of-service
requirements which implies a more complex and therefore costlier instantiation (cf.
figure .) step. In addition to this,  of the  technologies have some support
for monitoring QoS at runtime. is enables detection of non-compliance with a
QoS requirement which can initiate reconfiguration to ensure better reliability, but
again at a cost of increased resource consumption.
It is notable that only one of the surveyed technologies appears to scale to low-
end devices such as sensor motes even though this may certainly be relevant.
Although it seems plausible that a tradeoff exists between security and several
of the other qualities we have considered, we have no data to support that claim.
at is because we found very few examples where security had been considered in
the design of the composition mechanism. In  of the  surveyed technologies
have support for quality of service requirements in the composite specification and
some of these technologies explicitly state that security requirements can be spec-
ified as QoS requirements. For instance, in the QoS model in Amigo [, ]
security is represented by three boolean parameters: confidentiality, integrity, and
non-repudiation.

A

e research presented in this paper has been partly funded by the EU projects
“PalCom” (IST-; http://www.ist-palcom.org) and “Hydra” (IST-;
http://www.hydra.eu.com).


C Ո 

S O A  I-

A
Jeppe Brønsted, Klaus Marius Hansen

Abstract

A requirement for the mass-market adoption of co-operative applications

for vehicular ad-hoc networks is that the IT and communication infrastruc-
ture supports concurrent deployment of independent services and applications
that cooperate across organizational and commercial boundaries. In this pa-
per, we demonstrate how a Service Oriented Architecture (SOA ) can provide
value for all stakeholders and from a business case we deduce technical re-
quirements for a service infrastructure for VANETs.

. I

In recent years, the adoption of distributed systems in vehicles have increased signif-
icantly by the introduction of GPS-navigation systems, fleet management systems,
speed camera notification systems, TMC traffic information notification systems,
etc. One example is the OnStar system in which a cell phone and a GPS system
are connected to the vehicle bus to provide a wide range of services ranging from
remote engine diagnostics to automatic geo-tagged emergency calls. e system
has currently over  million subscribers and processes more than  calls every
month.
A common point of the systems mentioned above is that most use wide-range
radio technology for communication. Only a few, if any, rely on vehicular ad-hoc
networks (VANETs) using short-range communication. We conjecture that this is
due, at least partly, to the fact that most applications utilizing VANETs require a
critical mass of participating nodes to function optimal. If multiple corporations
and organizations each try to independently establish the required user-base of their
systems they will most likely fail.

Published as:
Jeppe Brønsted and Klaus Marius Hansen. Service Oriented Architecture for Inter-vehicle Applica-
tions. Accepted for publication in Proceedings of the th World Congress on Intelligent Transortation
Systems, 
¹http://www.onstar.com


Chapter . Service Oriented Architecture for Inter-vehicle Applications

In this paper, we claim that to maximize the number of nodes participating in

the systems, it is important that corporations and organizations cooperate to merge
their user bases so that they each reach the critical mass of participating nodes
required to realize the full potential of the systems. We show how service oriented
architecture can be used to by split applications up in services and sharing them
across different ownership domains in a way that provides value for all stakeholders.
From a business case for a set of applications, we deduce technical requirements for
a service infrastructure for VANETs.
A supplement to using SOA could be to, as suggested in [], extend the user-
base by motivating drivers to invest in wireless equipment by offering infrastructure-
based services such e.g. car-to-home date exchange. In [] a taxi radio dispatch
application scenario based on mobile ad-hoc networking is presented including an
analysis of both technical and financial feasibility. In the scenario, the critical mass
of participating nodes (taxis) is reached by an initial investment by the taxi company.
e rest of the paper is structured as follows. In the following section, we
describe the characteristics of VANETs followed by a motivation for the use of
VANETs for intelligent vehicle systems. Section . introduces service oriented
architecture. e business case and the requirements for a service infrastructure are
presented in section . and ..

. VANET C

Vehicular ad-hoc networks consisting of nodes communicating by using short-

range wireless radios are characterized by having a high degree of variability in
node mobility and node density. Normally, on highways approaching vehicles will
only be within transmission range for a few seconds, depending on antenna and
propagation conditions. However, if traffic congestion occurs, vehicles driving in
the same direction can be within range for hours. While driving in populated ar-
eas, vehicles will be within range for most of the time, but in rural areas, the traffic
density can be very low.
While these characteristics make it complicated to implement applications that
utilize VANETs for communication, VANETs are nevertheless necessary for sev-
eral reasons.

. W U VANET

One reason for using short-range wireless communication is that it can be used
for proximity detection - if a node overhears a broadcast it can be certain that the
broadcasting node is within a short range.
A more important reason is that the alternative, wide range cellular communi-
cation, has a set of downsides that may negatively influence an applications ability
to provide its services.
First of all, currently cellular technology provides significantly lower bandwidth
on node-to-node communication. Wide range communication have the property


 .. Service Oriented Architecture

that the nodes in range share the communication capacity of the medium, and the
larger range a signal has, the more nodes have to share the bandwidth. is is not
necessarily a problem if the node density is low (e.g. in rural areas), but in areas
where the node density is high, severe constraints are put on the communication
bandwidth. Secondly, the coverage provided by cellular systems is limited in some
regions. Note however that this may change in time. Finally, using cellular com-
munication usually entails some form of paid subscription.  
ese downsides have the effect that some applications cannot be realized using
cellular communication. e literature provides a wealth of examples. E.g. systems
that warn about hazardous driving condition such as ice, roadwork, traffic conges-
tion, road tolling systems, vehicle collision avoidance systems, etc. To realize the
full potential of these applications, short-range wireless communication must to be
used.
In spite of the reasons for using short-range communication mentioned above,
only a few, if any, commercial applications employ it. One factor is that systems re-
lying on short-range wireless communication are typically more complex in design,
implementation, evaluation, and deployment. If the application can be realized
without short-range communication, it is most likely a cheaper solution, but as we
argued above, this is not always possible.
Another factor is that a lot of the applications mentioned above require a critical
mass to work optimal. One example could be a system providing warnings about
icy roads. Vehicles equipped with the system disseminate warning messages to ap-
proaching vehicles. If not enough nodes are equipped with the system, there is a
high probability that messages will not reach the approaching vehicles. Further-
more, only vehicles equipped with the system will receive warnings.
To reach the critical mass for a system, it is important that commercial players
and organizations cooperate to include as many nodes as possible into the system.
If the system is closed and based solely on proprietary protocols most likely only a
small subset of the market will join in.

. S O A

A way to enable cooperation among corporations and organizations is to open up

systems and make capabilities available to be included as parts of other systems by
using a service oriented architecture.
Service Oriented Architecture (SOA ) is a paradigm for organizing and utiliz-
ing distributed capabilities that may be under the control of different ownership
domains []. In SOA, the needs of entities are met by capabilities provided by
other entities.
In the example mentioned above, at least four capabilities can be identified; the
ability to detect ice, the ability to determine the position of the icy spot, the ability
to disseminate a warning in a particular region (the approaching vehicles), and the
ability to alert the driver. Clearly, some of these capabilities could be useful as parts
of other systems and furthermore the ice warning systems functionality will not any


Chapter . Service Oriented Architecture for Inter-vehicle Applications

longer solely depend on its own market penetration but rather on the availability
of a set of services that also could be used by other systems. For example, the
ice warning system could use the same warning dissemination service as a traffic
congestion notification system uses.

. A B C

Service orientation from a technology perspective is however not enough. e fact

that corporations and organizations can match capabilities with needs across or-
ganizational and commercial boundaries does not necessarily imply that they will
actually do so. Without the proper incentive for stakeholders in the system nothing
will happen.
To demonstrate how a service oriented architecture can be used to more quickly
reach the critical mass for a system we present a business case for implementing a
set of applications with value propositions for the key players.
e applications all share a common goal; to provide drivers with valuable in-
formation about the environment. e drivers can subscribe to different types of
data, such as information about the condition of the road, traffic congestion, gas
prizes, etc. that originate from various sources. e drivers are notified through a
navigation system or PDA that also is used to disseminate data to other vehicles.
We divide the players into three categories. In each category, there can be in-
dependent players. For each of the categories, we present examples of who would
be in that category. An overview is shown in figure ..

Sensor manufacturers sell sensors or software for detecting different kinds of in-
formation about vehicles and the environment. is could, e.g., be an ice
sensor manufacturer or a company that makes software that can detect traffic
congestion by correlating a vehicle’s current velocity with the velocity allowed
at the vehicle’s current location.

Data providers are individuals or organizations collecting data using the sensors
and/or software provided by the sensor manufactures. One example is a road
assistance company with ice sensors installed or individuals with the traffic
congestion software installed.

Presentation providers are companies delivering equipment or software for dis-

playing data in vehicles. One example could a navigation system provider
that delivers stand-alone systems or software that can run on a PDA.

Data consumers are the individuals or organizations interested in the data pro-
vided by the data providers. is could, e.g. be drivers or road authorities.

e flow of money between the stakeholders is also shown in figure .. e

data providers buy sensors or software from the sensor manufacturers and sells ac-
cess to the collected data to the presentation providers. e presentation providers


 .. Requirements on SOA Infrastructure

Sensor manufacturer Presentation providers

Traffic Navigation
Ice sensor
congestion system
Manufacturer
software prov. provider

Buys Buys Subscribes to

sensors/software data access data categories

Data providers Data consumers

Road Idividual
Assistance Idividual driver Driver
Company

Money

Figure .: Value chain

offer subscriptions for data to their customers (the data consumers) and hereby add
value to their products (the navigation system or PDA) and generate continuous
revenue from the subscription.
Because the data is disseminated through the VANET, it is important that the
presentation providers by contract agree to disseminate information received from
all nodes - both the nodes that have installed the software or navigation system
provided but also data received from competitor systems. An agreement such as this
is beneficial to all parties because without it data would not be properly disseminated
and no value would be added.
In figure ., an example of the operation of such a system can be seen. e
purple van in the bottom left corner observes an icy area and disseminates the infor-
mation to the other vehicles and the road authorities using a combination of short
range (WLAN) and long range (GSM) wireless communication. Installed in the
van is an ice sensor bought form a sensor manufacturer. e van belongs to a com-
pany that has a contract with a navigation system provider (presentation provider) to
deliver information to the navigation system providers customers. ese customers
subscribe to the information.

. R  SOA I

Before a service oriented architecture can be realized in a VANET environment, a

set of technical challenges have to be addressed.
First, since data should only be available for the entities paying for it, it should
be possible to encrypt the data. is could, e.g. be done by the data providers by
using a private key. e presentation providers could then buy matching keys for a
set of services and sell the information to subscribers. If the keys are time-limited,
they have to be updated by connecting to the Internet.


Chapter . Service Oriented Architecture for Inter-vehicle Applications

ICE!
Road Authorities

WLAN GSM Data provider Data consumer

Figure .: Example operation

In the example in figure ., the van company would sell access to the data
it collects by selling the decryption keys that will unlock the data. e van com-
pany distributes the information collected using short range and wide range wireless
communication. e navigation system provider buys keys from the van company
and distributes them, using a GSM connection, to those of their customers that
subscribe to the data. e customers that do not subscribe to the data will not have
access to it, but their navigations system will still relay data to other vehicles.
Secondly, data have to travel from the nodes that detect it to the nodes that
consume it. To make sure that data arrives in due time, VANET data dissemination
protocols, such as e.g. [, , ], should be used. ese protocols typically
exploit properties of the data communicated to optimize routing. Since we argued
above that encryption should be used, it is a challenge to construct protocols that
can exploit properties of encrypted data. It is a requirement that the encryption
used allows for optimized routing.
Finally, since the SOA infrastructure should be used for multiple applications,
it is important that it is open-ended in the sense that it should be possible to add
new applications to the system during operation. It should, for example, be possible
for new players to enter the market.


 B

[] Speed trap information system, September  . US Patent ,,.

[] Sten L Amundsen and Frank Eliassen. A resource and context model for
mobile middleware. Personal and Ubiquitous Computing, . published
online first.

[] Jacob R. Andersen, Lars Bak, Steffen Grarup, Kasper V. Lund, Toke Es-
kildsen, Klaus Marius Hansen, and Mads Torgersen. Design, Implemen-
tation, and Evaluation of the Resilient Smalltalk Embedded Platform. In
Proceedings of the th European Smalltalk User Group Conference, .

[] Anupriyaa Ankolekar, Mark Burstein, Jerry R. Hobbs, Ora Lassila, David
Martin, Drew McDermott, Sheila A. McIlraith, Srini Narayanan, Massimo
Paolucci, Terry Payne, and Katia Sycara. DAML-S: Web service description
for the Semantic Web. In Proceedings of the First International Semantic Web
Conference (ISWC ), volume  of LNCS, pages –. Springer-
Verlag, .

[] Sèbastien Baehni, Chirdeep Singh Chhabra, and Rachid Guerraoui. Fru-
gal Event Dissemination in a Mobile Environment. In Proceedings of
ACM/IFIP/USENIX th International Middleware Conference, .

[] Fan Bai, Narayanan Sadagopan, and Ahmed Helmy. IMPORTANT: A

framework to systematically analyze the impact of Mobility on Performance
of RouTing protocols for Adhoc NeTworks. In Proceedings of IEEE INFO-
COM, pages –, .

[] Vince Barabba, Chet Huber, Fred Cooke, Nick Pudar, Jim Smith, and Mark
Paich. A Multimethod Approach for Creating New Business Models: e
General Motors OnStar Project. Interfaces, ():, .

[] Luciano Baresi, Elisabetta Di Nitto, Carlo Ghezzi, and Sam Guinea. A
framework for the deployment of adaptable web service compositions. Ser-
vice Oriented Computing and Applications, ():–, April .

[] Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Prac-
tise. Addison-Wesley, nd edition, .


BIBLIOGRAPHY

[] B. Bauer, J.P. Mueller, and J. Odell. Agent UML: A Formalism for Speci-
fying Multiagent Software Systems. In Proceedings of the First International
Workshop on Agent-Oriented Software Engineering (AOSE ), number
 in LNCS, pages –. Springer.

[] F. Bellifemine, A. Poggi, and G. Rimassa. Developing multi-agent systems

with JADE. In Proceedings of the th International Workshop on Agent eories
Architectures and Languages, number  in LNCS.

[] Pierpaolo Bergamo, Daniela Maniezzo, Kung Yao, Matteo Cesana, Gio-
vanni Pau, Mario Gerla, and Don Whiteman. IEEE. Wireless Net-
work under Aggressive Mobility Scenarios. In Proceedings from the th An-
nual International Telemetering Conference, .

[] Richard Bogenberger, Wolfgang Kellerer, Timo Kosch, omas Reicher,

Christian Schwingenschlögl, Peter Sties, and Matthias Wagner. Virtual
City Portal - A Multi-Network Personal Information System for Automo-
bile Users. In IEEE/ITG International Workshop on Multiradio Multimedia
Communications, .

[] Linda Briesemeister. Group Membership and Communication in Highly Mo-

bile Ad Hoc Networks. PhD thesis, Technical University of Berlin, School of
Electrical Engineering and Computer Sciences, Berlin, November .

[] Linda Briesemeister and Günter Hommel. Integrating Simple yet Robust
protocol Layers for Wireless Ad Hoc Inter-vehicle Communications. In
Proceedings of Communication Networks and Distributed Systems Modeling and
Simulation Conference (CNDS), pages –, .

[] Jeppe Brønsted, Erik Grönvall, and David Fors. Palpability Support
Demonstrated. In Proceedings of Embedded and Ubiquitous Computing, vol-
ume  of LNCS, pages –, Taipei, Taiwan, December .
Springer. Acceptance rate: .

[] Jeppe Brønsted and Klaus Marius Hansen. Handling membership dynam-
icity in service composition for ubiquitous computing. In Proceedings of the
th MiNEMA Workshop, Magdeburg, Germany, September .

[] Jeppe Brønsted and Klaus Marius Hansen. Handling membership dynam-
icity in service composition for ubiquitous computing. Accepted for publi-
cation in: International Conference on Mobile Ubiquitous Computing, Systems,
Services and Technologies, UBICOMM ’ , . Acceptance rate: .

[] Jeppe Brønsted and Klaus Marius Hansen. Service Oriented Architecture
for Inter-vehicle Applications. Accepted for publication in Proceedings of the
th World Congress on Intelligent Transortation Systems, .


[] Jeppe Brønsted, Klaus Marius Hansen, and Mads Ingstrup. A Survey of
Service Composition Mechanisms in Ubiquitous Computing. In UbiComp
 Workshop proceedings, pages –, . Second Workshop on Re-
quirements and Solutions for Pervasive Software Infrastructures (RSPSI).

[] Jeppe Brønsted, Klaus Marius Hansen, and Lars Michael Kristensen. An
Infrastructure for a Traffic Warning System. In Proceedings for the IEEE
International Conference on Pervasive Services, pages –, . Accep-
tance rate: .

[] Jeppe Brønsted, Klaus Marius Hansen, and Rolf orup. A Uniform
Publish-Subscribe Infrastructure for Communication in Wireless Mobile
Environments. In th International Conference on ITS Telecommunications
Proceedings, pages –, June . Acceptance rate: .

[] Jeppe Brønsted, Klaus Marius Hansen, and Rolf orup. A Uniform
Publish-Subscribe Infrastructure for Communication in Wireless Mobile
Environments. In Proceedings of the rd MiNEMA Workshop, February .

[] Jeppe Brønsted and Lars Michael Kristensen. Specification and Perfor-
mance Evaluation of Two Zone Dissemination Protocols for Vehicular Ad-
hoc Networks. In Proceedings of the th Annual Simulation Symposium, pages
–, Los Alamitos, CA, USA, . IEEE Computer Society. Accep-
tance rate: .

[] Monika Büscher, Margit Kristensen, and Preben Mogensen. Making the
future palpable: Notes from a major incident Future Laboratory. In Pro-
ceedings of the th International Conference on Information Systems for Crisis
Response and Management (ISCRAM), May .

[] William Buxton. Integrating the Periphery and Context: A New Model of
Telematics. In Proceedings of Graphics Interface, pages –, .

[] Jain Cai and David J. Goodman. General packet radio service in GSM.
Communications Magazine, IEEE, ():–, Oct .

[] T. Camp, J. Boleng, and V. Davies. A survey of mobility models for

ad hoc network research. Wireless Communications and Mobile Computing,
():–, .

[] A. Carzaniga, D.S. Rosenblum, and A.L. Wolf. Design and evaluation
of a wide-area event notification service. Foundations of Intrusion Toler-
ant Systems, [Organically Assured and Survivable Information Systems], pages
–, .

[] Yair Censor. Pareto Optimality in Multiobjective Problems. Applied Math-

ematics and Optimization, ():–, Mar .


BIBLIOGRAPHY

[] Humberto Cervantes and Richard S. Hall. Automating Service Dependency

Management in a Service-Oriented Component Model. In Proceedings of
ICSE CBSE Workshop, May .

[] Dipanjan Chakraborty, Anupam Joshi, Tim Finin, and Yelena Yesha. Ser-
vice Composition for Mobile Environments. Mobile Networks and Applica-
tions, ():–, August .

[] H. Chesbrough and R.S. Rosenbloom. e role of the business model in

capturing value from innovation: evidence from Xerox Corporation’s tech-
nology spin-off companies. Industrial and Corporate Change, ():–,
.

[] T. Clausen and P. Jacquet. Optimized Link State Routing Protocol (OLSR).
http://www.ietf.org/rfc/rfc3626.txt, .
RFC .

[] A. Conta and S. Deering. Internet Control Message Protocol (ICMPv)

for the Internet Protocol Version  (IPv) Specification, .
RFC .

[] Aino Vonge Corry, Klaus Marius Hansen, and David Svensson. Traveling
Architects – A New Way of Herding Cats. In Quality of Software Architec-
tures, pages –, .

[] Paolo Costa and Gian Pietro Picco. Semi-probabilistic content-based

publish-subscribe. In Proceegins of the th IEEE International Conference
on Distributed Computing Systems (ICDCS’), pages –, Los Alami-
tos, CA, USA, . IEEE Computer Society.

[] P. De, A. Raniwala, R. Krishnan, K. Tatavarthi, J. Modi, N.A. Syed,

S. Sharma, and T. Chiueh. MiNT-m: an autonomous mobile wireless ex-
perimentation platform. Proceedings of the th international conference on Mo-
bile systems, applications and services, pages –, .

[] Christophe Dony, Jacques Malenfant, and Pierre Cointe. Prototype-based

languages: from a new taxonomy to constructive proposals and their valida-
tion. In OOPSLA ’: conference proceedings on Object-oriented programming
systems, languages, and applications, pages –, New York, NY, USA,
. ACM.

[] W. Keith Edwards, Mark W. Newman, Jana Sedivy, and Shahram Izadi.
Challenge: recombinant computing and the speakeasy approach. In Mo-
biCom ’: Proceedings of the th annual international conference on Mobile
computing and networking, pages –, New York, USA, . ACM
Press.


[] W. Keith Edwards, Mark W. Newman, Jana Z. Sedivy, and Trevor F. Smith.
Bringing Network Effects to Pervasive Spaces. IEEE Pervasive Computing,
():–, .

[] W. Keith Edwards, Mark W. Newman, Jana Z. Sedivy, Trevor F Smith,

Dirk Balfanz, D. K. Smetters, H. Chi Wong, and Shahram Izadi. Using
speakeasy for ad hoc peer-to-peer collaboration. In CSCW ’: Proceedings
of the  ACM conference on Computer supported cooperative work, pages
–, New York, NY, USA, . ACM Press.

[] Stephan Eichler, Christoph Schroth, and Jörg Eberspächer. Car-to-Car

Communication. In Proceedings of the VDE Kongress – Innovations for Eu-
rope, .

[] R. L. Erdmann and A. S. Neal. Laboratory vs. field experimentation in

human factors–an evaluation of an experimental self-service airline ticket
vendor. Human Factors, ():–, December .

[] J. Eriksson, L. Girod, B. Hull, R. Newton, S. Madden, and H. Balakrish-

nan. e Pothole Patrol: Using a Mobile Sensor Network for Road Surface
Monitoring. In Proceedings of the th international conference on Mobile sys-
tems, applications and services, MobiSys, pages –, New York, USA, June
. ACM Press.

[] Patrick . Eugster, Pascal A. Felber, Rachid Guerraoui, and Anne-Marie

Kermarrec. e Many Faces of Publish/Subscribe. ACM Comput. Surv.,
():–, .

[] W. Fenner. Internet Group Management Protocol, Version . http://www.

ietf.org/rfc/rfc2236.txt, .
RFC .

[] Andreas Festag, Holger Fussler, Hannes Hartenstein, Amardeo Sarma, and
Ralf Schmitz. Fleetnet:Bringing Car-to-car Communication into the Real
World. In Proceedings of the th World Congress on ITS, .

[] FIPA. FIPA Abstract Architecture Specification. Technical Report

SCL, Foundation for Intelligent Physical Agents, .

[] B. Fleming. Automotive Safety and Convenience Electronics. Vehicular

Technology Magazine, IEEE, ():–, March .

[] Walter J. Franz, Hannes Hartenstein, and Bernd Bochow. Internet on the
Road via Inter-Vehicle Communications. In Proc. of Workshop der Informatik
:Mobile Communications over Wireless LAN, .


BIBLIOGRAPHY

[] Keita Fujii and Tatsuya Suda. Dynamic Service Composition Using Seman-
tic Information. In Proceedings of the nd International Conference on Service
Oriented Computing, New York, New York, U.S.A, November . ACM.

[] Holger Füssler, Martin Mauve, Hannes Hartenstein, Dieter Vollmer, and
Michael Käsemann. A Comparison of Routing Strategies for Vehicular Ad-
Hoc Networks. In Proceedings of MOBICOM, . Student Poster.

[] Holger Füßler, Marc Torrent-Moreno, Matthias Transier, Andreas Festag,

and Hannes Hartenstein. oughts on a Protocol Architecture for Vehic-
ular Ad-hoc Networks. In Proceeding of the nd International Workshop on
Intelligent Transportation, pages –, .

[] Benoit Garbinato, Rachid Guerraoui, Jarle Hulaas, Ole Lehrmann Madsen,
Maxime Monod, and Jesper Honig Spring. Mobile Computing with Frugal
Objects . Technical report, EPFL I&C, .

[] David Garlan, Dan Siewiorek, Asim Smailagic, and Peter Steenkiste.
Project Aura: toward distraction-free pervasive computing. IEEE Perva-
sive Computing, ():–, .

[] O. Gehring and H. Fritz. Practical results of a longitudinal control concept

for truck platooning with vehicle to vehicle communication. In Prooceedings
of IEEE Conference on Intelligent Transportation System, pages –, Nov
.

[] Shahram Ghandeharizade, Shyam Kapadia, and Bhaskar Krishnamachari.

PAVAN: a policy framework for content availabilty in vehicular ad-hoc net-
works. In VANET ’: Proceedings of the st ACM international workshop on
Vehicular ad hoc networks, pages –, New York, NY, USA, . ACM
Press.

[] Carlo Ghezzi, Mehdi Jazayeri, and Dino Mandrioli. Fundamentals of Soft-
ware Engineering. Prentice-Hall, .

[] Adele Goldberg and David Robson. Robson: Smalltalk-: e Language

and Its Implementation. Addison-Wesley, .

[] Joan Greenbaum and Moten Kyng. Design at work: cooperative design of
computer systems. Lawrence Erlbaum Associates, Inc. Mahwah, NJ, USA,
.

[] Robert Grimm. One. world: Experiences with a Pervasive Computing Ar-
chitecture. IEEE Pervasive Computing, ():–, .

[] Robert Grimm, Janet Davis, Eric Lemar, Adam Macbeth, Steven Swanson,
omas Anderson, Brian Bershad, Gaetano Borriello, Steven Gribble, and


 David Wetherall. System support for pervasive applications. ACM Trans.
Comput. Syst., ():–, .

[] Erik Grönvall, Patrizia Marti, Alessandro Pollini, and Alessia Rullo. Ac-
tive surfaces: a novel concept for end-user composition. In NordiCHI ’:
Proceedings of the th Nordic conference on Human-computer interaction, pages
–, New York, NY, USA, . ACM Press.

[] Erik Grönvall, Alessandro Pollini, Alessia Rullo, and David Svensson. De-
signing game logics for dynamic Active Surfaces. Presented at MUIA :
third international workshop on mobile and ubiquitous information access,
.

[] Piyush Gupta and P. R. Kumar. e capacity of wireless networks. IEEE

Transactions of Information eory, ():–, .

[] Klaus Marius Hansen, Lars M. Kristensen, Toke Eskildsen, Kenneth-

Daniel Nielsen, Rolf E. orup, Jack Fridthjof, Ulrik Merrild, and Jørn Es-
kildsen. e Ex Hoc Infrastructure Framework - Enhancing Traffic Safety
through LIfe WArning Systems, .

[] Uwe Hansmann, Lothar Merk, Martin S. Nicklous, and omas Stober.
Pervasive Computing. Springer, .

[] J.K. Hedrick, M. Tomizuka, and P. Varaiya. Control issues in automated

highway systems. Control Systems Magazine, IEEE, ():–, Dec .

[] Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David Culler, and
Kristofer Pister. System Architecture Directions for Networked Sensors.
In Proceedings of the th international conference on Architectural support for
programming languages and operating systems, volume , pages –, New
York, NY, USA, . ACM Press.

[] Gavin Holland and Nitin Vaidya. Analysis of TCP performance over mobile
ad hoc networks. Wireless Networks, (/):–, .

[] Elgan Huang, Wenjun Hu, Jon Crowcroft, and Ian Wassell. Towards com-
mercial mobile ad hoc network applications: a radio dispatch system. Pro-
ceedings of the th ACM international symposium on Mobile ad hoc networking
and computing, pages –, .

[] Yongqiang Huang and Hector Garcia-Molina. Publish/Subscribe in a Mo-

bile Environment. Wireless Networks, ():–, November .

[] Mads Ingstrup. Towards distributed declarative architectural reflection. PhD

thesis, University of Aarhus, .


BIBLIOGRAPHY

[] Valerie Issarny, Daniele Sacchetti, Ferda Tartanoglu, Francoise Sailhan,

Rafik Chibout, Nicole Levy, and Angel Talamona. Developing Ambient
Intelligence Systems: A Solution based on Web Services. Automated Soft-
ware Engineering, ():+, .

[] N.R. Jennings, K. Sycara, and M. Wooldridge. A Roadmap of Agent

Research and Development. Autonomous Agents and Multi-Agent Systems,
():–, .

[] Bonnie E. John and Len Bass. Usability and software architecture. Behaviour
& Information Technology, ():–, .

[] David B Johnson and David A Maltz. Dynamic Source Routing in Ad Hoc
Wireless Networks. In Imielinski and Korth, editors, Mobile Computing,
volume , chapter , pages –. Kluwer Academic Publishers, .

[] Swaroop Kalasapur, Mohan Kumar, and Behrooz A. Shirazi. Dynamic Ser-
vice Composition in Pervasive Computing. Parallel and Distributed Systems,
IEEE Transactions on, ():–, .

[] H.A. Karimi and J.T. Lockhart. Gps-based tracking systems for taxi cab
fleet operations. In Proceedings of the IEEE-IEE Vehicle Navigation and In-
formation Systems Conference, pages –, Oct .

[] Brad Karp and H. T. Kung. Gpsr: greedy perimeter stateless routing for
wireless networks. In MobiCom ’: Proceedings of the th annual interna-
tional conference on Mobile computing and networking, pages –, New
York, NY, USA, . ACM.

[] Young-Bae Ko and Nitin H. Vaidya. Flooding-based Geocasting Protocols

for Mobile Ad Hoc Networks. Mobile Networks and Applications, :–,
.

[] Birgitta König-Ries, Michael Klein, and Tobias Breyer. Activity-based user
modeling in wireless networks. Mob. Netw. Appl., ():–, .

[] Timo Kosch, Christian Schwingenschlögl, and Li Ai. Information Dissem-

ination in Multihop Inter-Vehicle Networks. In Proceedings of the Interna-
tional Conference on Intelligent Transportation Systems, pages –, .

[] Lars M Kristensen and Kenneth-Daniel Nielsen. On the Application of

Zone Flooding in a Traffic Warning System. Technical report, Department
of Computer Science, Univerity of Aarhus, .

[] Emre Kıcıman and Armando Fox. Using Dynamic Mediation to Integrate
COTS Entities in a Ubiquitous Computing Environment. In Proceedings of
HUC , number  in LNCS, pages –, .


[] Hermann Rohling Lars Wischhof, André Ebner. SOTIS - A Self-
Organizing Traffic Information System. In Proceedings of the IEEE Vehicular
Technology Conference Spring, volume , pages –, April .

[] Alfred Leick. GPS Satellite Surveying. John Wiley and Sons, .

[] Ilias Leontiadis and Cecilia Mascolo. Opportunistic spatio-temporal dis-

semination system for vehicular networks. In MobiOpp ’: Proceedings of
the st international MobiSys workshop on Mobile opportunistic networking,
pages –, New York, NY, USA, . ACM Press.

[] Philip Levis, Nelson Lee, Matt Welsh, and David Culler. Tossim: accurate
and scalable simulation of entire tinyos applications. In SenSys ’: Proceed-
ings of the st international conference on Embedded networked sensor systems,
pages –, New York, NY, USA, . ACM.

[] Fan Li and Yu Wang. Routing in vehicular ad hoc networks: A survey.

Vehicular Technology Magazine, IEEE, ():–, June .

[] Matthew MacKenzie, Ken Laskey, Francis McCabe, Peter F Brown, and
Rebekah Metz. Reference Model for Service Oriented Architecture ..
Technical report, OASIS, August .

[] Samuel Madden, Michael J. Franklin, Joseph Hellerstein, and Wei Hong.
TAG: a Tiny Aggregation Service for Ad-Hoc Sensor Networks. In Proceed-
ings of the Fifth Symposium on Operating Systems Design and implementation,
pages –, .

[] S. Maffioletti, MS Kouadri, and B. Hirsbrunner. Automatic resource and

service management for ubiquitous computing environments. Pervasive
Computing and Communications Workshops, . Proceedings of the Second
IEEE Annual Conference on, pages –, .

[] David A. Maltz, Josh Broch, and David B. Johnson. Experiences Designing
and Building a MultiHop Wireless Ad Hoc Network Testbed. Technical
report, School of Computer Science,Carnegie Mellon University, .

[] S.T. March and G.F. Smith. Design and natural science research on infor-
mation technology. Decision Support Systems, ():–, .

[] Patrizia Marti and Claudio Moderini. Creative design in safety critical sys-
tems. In Proceedings of ECCE , September .

[] Patrizia Marti and Antonio Rizzo. Levels of design: from usability to ex-
perience. In Proceedings of HCI International, July .


BIBLIOGRAPHY

[] David Martin, Massimo Paolucci, Sheila McIlraith, Mark Burstein, Drew
McDermott, Deborah McGuinness, Bijan Parsia, Terry Payne, Marta
Sabou, Monika Solanki, Naveen Srinivasan, and Katia Sycara. Bringing
Semantics to Web Services: e OWL-S Approach. Proceedings of the First
International Workshop on Semantic Web Services and Web Process Composition
(SWSWPC ), pages –, .

[] Ryusuke Masuoka, Yannis Labrou, Bijan Parsia, and Evren Sirin. Ontology-
enabled pervasive computing applications. IEEE Intelligent Systems,
():–, .

[] Ryusuke Masuoka, Bijan Parsia, and Yannis Labrou. Task Computing –
e Semantic Web Meets Pervasive Computing. e Semantic Web - ISWC
, /:–, .

[] Martin Mauve, Jörg Widmer, and Hannes Hartenstein. A Survey on

Position-Based Routing in Mobile Ad-Hoc Networks. IEEE Network
Magazine, .

[] René Meier, Jörg Kaiser, Barbara Hughes, Christiano Brudna, and Vinny
Cahill. An Event Model for Real-Time Systems in Mobile Environments.
In Proceedings of Workshop on Software Technologies for Future Embedded &
Ubiquitous Computing Systems (WSTFEUS), .

[] Lachlan B Michael. Adaptive Layered Data Structure for Inter-Vehicle

Communication in Ad-Hoc Communication Networks. In Proceedings of
the th World Congress on Intelligent Transportation Systems, .

[] N. Milanovic and M. Malek. Current solutions for Web service composi-
tion. Internet Computing, IEEE, ():–, .

[] R. Moats. URN Syntax. http://www.ietf.org/rfc/rfc2141.txt, .

RFC .

[] P. Mockapetris. Domain names - concepts and facilities. http://www.ietf.

org/rfc/rfc1034.txt, .
RFC .

[] Prasant Mohapatra, Chao Gui, and Jian Li. Group communications in mo-
bile ad hoc networks. Computer, ():–, .

[] Sonia Ben Mokhtar, Jinshan Liu, Nikolaos Georgantas, and Valérie Issarny.
QoS-aware dynamic service composition in ambient intelligence environ-
ments. In Proceedings of the th IEEE/ACM international Conference on
Automated software engineering, pages –, New York, NY, USA, .
ACM.


[] Jaime Montemayor, Allison Druin, Allison Farber, Sante Simms, Wayne
Churaman, and Allison D’Amour. Physical programming: designing tools
for children to create physical interactive environments. In CHI ’: Pro-
ceedings of the SIGCHI conference on Human factors in computing systems, pages
–, New York, NY, USA, . ACM Press.

[] Robert Morris, John Janotti, Frans Kaashoek, Jinyang Li, and Douglas De-
couto. CarNet: A Scalable Ad Hoc Wireless Network System. In Proceed-
ings og the th ACM SIGOPS, pages –, .
[] Brad A. Myers. Visual programming, programming by example, and pro-
gram visualization: a taxonomy. SIGCHI Bull., ():–, .

[] Tamer Nadeem, Sasan Dashtinezhad, Chunyuan Liao, and Liviu Iftode.
TrafficView: A Scalable Traffic Monitoring System. In Proceedings of the
 IEEE International Conference on Mobile Data Management, pages
–, January .

[] Valery Naumov, Rainer Baumann, and omas Gross. An evaluation of

inter-vehicle ad hoc networks based on realistic vehicular traces. In Mobi-
Hoc ’: Proceedings of the th ACM international symposium on Mobile ad
hoc networking and computing, pages –, New York, NY, USA, .
ACM.

[] Mark W. Newman, Jana Z. Sedivy, Christine M. Neuwirth, W. Keith Ed-

wards, Jason I. Hong, Shahram Izadi, Karen Marcelo, Trevor F. Smith, Jana
Sedivy, and Mark Newman. Designing for serendipity: supporting end-user
configuration of ubiquitous computing environments. In DIS ’: Proceed-
ings of the conference on Designing interactive systems, pages –, New
York, NY, USA, . ACM Press.

[] Sze-Yao Ni, Yu-Chee Tseng, Yuh-Shyan Chen, and Jang-Ping Sheu. e
Broadcast Storm Problem in a Mobile Ad Hoc Network. In Proceedings of
the th annual ACM/IEEE international conference on Mobile computing and
networking, pages –, New York, NY, USA, . ACM.
[] Brian Oki, Manfred Pfluegl, Alex Siegel, and Dale Skeen. e Information
Bus® - An Architecture for Extensible Distributed Systems. In SOSP ’:
Proceedings of the fourteenth ACM symposium on Operating systems principles,
pages –, New York, NY, USA, . ACM Press.

[] OMG. CORBA Scripting Language Specification. Technical Report

formal/--, Object Management Group, .

[] OMG. Deployment and Configuration of Component-based Distributed

Applications Specification. Technical Report Formal/--, Object
Management Group, .


BIBLIOGRAPHY

[] OMG. Common Object Request Broker Architecture (CORBA) Specifi-

cation, Version .. Part : CORBA Component Model. Technical Report
formal/--, Object Management Group, .
[] PalCom. PalCom External Report no : Deliverable  (..): Palpability
- a conceptual framework for palpable computing. Technical report, PalCom
Project IST-, .
[] PalCom. PalCom External Report no : Deliverable  (..): PalCom
Open Architecture. Technical report, PalCom Project IST-, .
[] PalCom. PalCom External Report no : Deliverable  (..): End-User
Composition: Software support for assemblies. Technical report, PalCom
Project IST-, .
[] Ramu Panayappan, Jayini Mukul Trivedi, Ahren Studer, and Adrian Perrig.
VANET-based approach for parking space availability. In VANET ’: Pro-
ceedings of the fourth ACM international workshop on Vehicular ad hoc networks,
pages –, New York, NY, USA, . ACM.
[] B. Parno and A. Perrig. Challenges in securing vehicular networks. In Pro-
ceedings of HotNets-IV, .
[] C. Perkins, E. Belding-Royer, and D. Das. Ad hoc On-Demand Distance
Vector (AODV) Routing. http://www.ietf.org/rfc/rfc3561.txt, .
RFC .
[] C.E. Perkins. Ad Hoc Networking. Addison-Wesley, .
[] C.E. Perkins and P. Bhagwat. Highly dynamic Destination-Sequenced
Distance-Vector routing (DSDV) for mobile computers. Proceedings of the
conference on Communications architectures, protocols and applications, pages
–, .
[] Dewayne E. Perry and Alexander L. Wolf. Foundations for the study of
software architecture. SIGSOFT Softw. Eng. Notes, ():–, .
[] Shankar R. Ponnekanti, Brian Lee, Armando Fox, Pat Hanrahan, and Terry
Winograd. ICrafter: A Service Framework for Ubiquitous Computing En-
vironments. Proceedings of Ubicomp, , .
[] Ragunathan Rajkumar, Mike Gagliard, and Liu Sha. e Real-Time
Publisher/Subscriber Inter-Process Communication Model for Distributed
Real-Time Systems: Design and Implementation. In Proceedings of Real-
Time Technology and Applications Symposium, pages –, May .
[] M. Raya. e security of vehicular ad hoc networks. In Proceedings of the rd
ACM workshop on Security of ad hoc and sensor networks, pages –. ACM
Press New York, NY, USA, .


[] D. Raychaudhuri, I. Seskar, M. Ott, S. Ganu, K. Ramachandran, H. Kremo,
R. Siracusa, H. Liu, and M. Singh. Overview of the orbit radio grid
testbed for evaluation of next-generation wireless network protocols. In Pro-
ceeding of IEEE Wireless Communications and Networking Conference, pages
–, .
[] Robert Bosch GmbH. CAN Specification Version ., Sep .
[] Manuel Román, Brian Ziebart, and Roy H. Campbell. Dynamic Applica-
tion Composition: Customizing the Behavior of an Active Space. In PER-
COM ’: Proceedings of the First IEEE International Conference on Pervasive
Computing and Communications, page , Washington, DC, USA, .
IEEE Computer Society.
[] Bill Schilit, Norman Adams, and Roy Want. Context-aware computing ap-
plications. In IEEE Workshop on Mobile Computing Systems and Applications,
pages –, Dec .
[] Ulrik Pagh Schultz, Erik Corry, and Kasper V. Lund. Virtual Machines for
Ambient Computing: Virtual Machines for Ambient Computing: A Pal-
pable Computing Perspective. Presented at Object Technology for Ambient
Intelligence Workshop, ECOOP, .
[] B. Schunemann, K. Massow, and I. Radusch. A Novel Approach for Realis-
tic Emulation of Vehicle--X Communication Applications. In Proceedings
of IEEE Vehicular Technology Conference, pages –, .
[] Jatinder Pal Singh, Nicholas Bambos, Bhaskar Srinivasan, and Detlef
Clawin. Wireless LAN Performance Under Varied Stress Conditions in
Vehicular Traffic Scenarios. In Vehicular Technology Conference. VTC -
Fall, vol. , .
[] Martin Skafte. Geographically Based Services in Cellular Networks. Mas-
ter’s thesis, University of Aarhus, Computer Science Department, . in
danish.
[] João Pedro Sousa, Vahe Poladian, David Garlan, Bradley Schmerl, and Mary
Shaw. Task-based adaptation for ubiquitous computing. IEEE Transac-
tions on Systems, Man, and Cybernetics—Part C: Applications and Reviews,
():–, .
[] Eduardo Souto, Germano Guimarães, Glauco Vasconcelos, Mardoqueu
Vieira, Nelson Rosa, Carlos Ferraz, and Judith Kelner. Mires: a Pub-
lish/Subscribe Middleware for Sensor Networks. Personal and Ubiquitous
Computing, pages –, Nov .
[] William Stallings. Data and Computer Communications. Prentice Hall, sixth
edition edition, .


BIBLIOGRAPHY

[] David Svensson. PalCom Working Note : Service framework. Tech-
nical report, PalCom Project IST-, .

[] David Svensson, Görel Hedin, and Boris Magnusson. Pervasive applications
through scripted assemblies of services. In Proceedings of IEEE International
Conference on Pervasive Services, pages –, .

[] Clemens Szyperski. Component Software – Beyond Object-Oriented Program-

ming. Addison-Wesley/ACM Press, .

[] e OSGi Alliance. OSGi Service Platform Core Specification. Release , .

[] Mathieu Vallee, Fano Ramparany, and Laurent Vercouter. Flexible Com-
position of Smart Device Services. In e  International Conference on
Pervasive Systems and Computing (PSC-), Las Vegas, Nevada, USA., June,
pages –, .

[] Proceedings of e First ACM International Workshop on Vehicular Networks,

.

[] Proceedings of e Second ACM International Workshop on Vehicular Networks,

.

[] Werner Vogels, Robbert van Renesse, and Ken Birman. e power of epi-
demics: robust communication for large-scale distributed systems. SIG-
COMM Comput. Commun. Rev., ():–, .

[] Mark Weiser. e Computer for the Twenty-First Century. Scientific Amer-
ican, ():–, .

[] Mark Weiser. e computer for the st century. SIGMOBILE Mob. Com-
put. Commun. Rev., ():–, .

[] Mark Weiser and John Seely Brown. Designing Calm Technology. Power-
Grid Journal, .

[] Brad Williams and Tracy Camp. Comparison of Broadcasting Techniques

for Mobile Ad Hoc Networks. In Proceedings of the ACM International Sym-
posium on Mobile Ad Hoc Networking and Computing, pages –, .

[] Hao Wu and Michael Hunter Richard Fujimoto, Randall Gunsler. MDDV:
A Mobility-Centric Data Dissemination Algorithm for Vehicular Networks.
In Proceedings of e First ACM International Workshop in Vehicular Networks
, pages –, .

[] Bo Xu, A. Ouksel, and O. Wolfson. Opportunistic resource exchange in

inter-vehicle ad-hoc networks. In Proceedings of IEEE International Confer-
ence on Mobile Data Management, pages –, .


[] J. Yang and M.P. Papazoglou. Web Component: A Substrate for Web Ser-
vice Reuse and Composition. Proceedings of the th International Conference
on Advanced Information Systems Engineering (CAiSE’), Toronto, Canada,
pages –, .
[] X. Yang, L. Liu, N.H. Vaidya, and F. Zhao. A vehicle-to-vehicle communi-
cation protocol for cooperative collision warning. In Proceedings of e First
Annual International Conference on Mobile and Ubiquitous Systems: Network-
ing and Services, pages –, Aug. .
[] Yuping Yang, Fiona Mahon, M. Howard Williams, and Tom Pfeifer.
Context-Aware Dynamic Personalised Service Re-composition in a Perva-
sive Service Environment. In Proceedings of Ubiquitous Intelligence and Com-
puting, volume  of LNCS, pages –. Springer, .
[] Mark D. Yarvis, W. Steven Conner, Lakshman Krishnamurthy, Jasmeet
Chhabra, Brent Elliott, and Alan Mainwaring. Real-world experiences with
an interactive ad hoc sensor network. In Proceedings of the International Work-
shop on Ad Hoc Networking, pages –, .
[] Jijun Yin, Tamer ElBatt, Gavin Yeung, Bo Ryu, Stephen Habermas, Hari-
haran Krishnan, and Timothy Talty. Performance evaluation of safety appli-
cations over DSRC vehicular ad hoc networks. In VANET ’: Proceedings of
the st ACM international workshop on Vehicular ad hoc networks, pages –,
New York, NY, USA, . ACM.
[] F. Zhu, M.W. Mutka, and L.M. Ni. Service discovery in pervasive com-
puting environments. Pervasive Computing, IEEE, ():–, Oct.-Dec.
.
[] H. Zimmermann. OSI Reference Model–e ISO Model of Architecture
for Open Systems Interconnection. Communications, IEEE Transactions on,
():–, Apr .
[] Esmertec - OSVM product description.
http://www.esmertec.com/solutions/M2M/OSVM/.

[] European GSM coverage.

http://www.coveragemaps.com/gsmposter_europe.htm.

[] Garmin TMC navigation systems.

http://www8.garmin.com/traffic/fm/index.jsp.

[] Google Maps.

http://maps.google.com.

[] INVENT.
http://www.invent-online.de.


BIBLIOGRAPHY

[] ISIS Katrinebjerg.

http://www.isis.alexandra.dk/english/.

[] LIWAS: Life warning systems.

http://www.liwas.dk.

[] Mesh Dynamics.

http://www.meshdynamics.com/FAQ_4455.html.

[] Microsoft .NET Framework Home.

http://msdn.microsoft.com/netframework/.

[] MIME Media Types.

http://www.iana.org/assignments/media-types/.

[] OnStar.
http://www.onstar.com.

[] PalCom - making computing palpable.

http://www.ist-palcom.org.

[] PalCom: On Site.

http://www.ist-palcom.org/application-areas/on-site/.

[] RDS-TMC: What is it all about?

http://www.rds.org.uk/episode/rdstmcbrochure.htm.

[] Sinalgo.
http://dcg.ethz.ch/projects/sinalgo/.

[] Specification of the Bluetooth System, v..

https://www.bluetooth.org/.

[] e Network Simulator.

http://www.isi.edu/nsnam/ns/.

[] TomTom GO  T datasheet.

http://www.tomtom.com/lib/doc/GO920Tdatasheet.pdf.

[] uClinux.
http://www.uclinux.org/.

[] UNC.
http://www.unc20.net/.

