Professional Documents
Culture Documents
Jeppe Brønsted
PhD Dissertation
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service Composition
. A Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Service Composition Model . . . . . . . . . . . . . . . . . . . . .
. Categorization Framework . . . . . . . . . . . . . . . . . . . . . .
v
Contents
. Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusion
. Summary of Contributions . . . . . . . . . . . . . . . . . . . . . .
. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
II Publications
vi
Contents
Bibliography
vii
L F
. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Service composition model . . . . . . . . . . . . . . . . . . . . . . . .
. GasPrices script . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Tiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ix
List of Figures
x
L T
. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Methods and Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . .
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:
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.
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
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
.. Software Architecture
Chapter . Introduction
. C
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
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
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.
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.
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.
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.
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.
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
.. Outline
C Ո
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.
.. 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.
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 [].
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.
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.
Chapter . Architecture in Vehicular Technology Applications
Architect(s)
Architecture
Architects's Influences
Application Layer
Business Model
...
Middleware Architecture
Network Architecture
System
.. 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
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.
.. 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.
Chapter . Architecture in Vehicular Technology Applications
.. Architectural Choices
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.
.. Architectural Choices
C Ո
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
Content-based publish-subscribe
Data-centric delivery
Topic-based
publish-subscribe
Generality
Multicast Geocast
Unicast
.. 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
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 [].
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.
.. Protocol Evaluation
.. 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.
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
Chapter . Data Dissemination in Vehicle to Vehicle Networks
.. 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.
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.
Application
specific
General
purpose
. 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
C Ո
S C
. A S
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
. 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
Composite
Service
Specifies Specification Instatiated Service
Specifying Service
Actor
Optionals
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.
.. 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.
Chapter . Service Composition
.. 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.
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.
.. Contributions
. C
Chapter . Service Composition
should thus be possible for the user to (re)specify the composite at runtime.
.. Contributions
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
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.
.. 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;
}
}
}
}
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.
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:
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:
.. 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.
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
. C
Chapter . Palpability in Pervasive Computing
the extended script language described in the previous chapter (section ..).
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 .).
• 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
.. 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.
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
Chapter . Conclusion
.. 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.
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 Ո
Abstract
. 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.
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.
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.
: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
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 ..
Chapter . An Infrastructure for a Traffic Warning System
are important in the LIWAS system. We will give examples of perfective updates
later.
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
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.
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)
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.
.. 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)
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.
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 .
.. 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)
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
.. 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
.. Prototype : Initial Deployment
Mobile unit
1200 Stationary unit
Maximum
1000
800
Packets
600
400
200
0
0 5000 10000 15000 20000 25000
Time (msecs)
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.
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
.. Conclusion
. 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 Ո
Abstract
. I
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
.. 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.
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.
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.
.. 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
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.
whiletrue
classification ← _()
pos ← _()
zone ← _(pos)
seqNumber ← seqNumber + 1
do
packet ← _(classification, zone,
seqNumber)
(packet)
(bcastInterval)
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
whiletrue
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
while{true
(ER)
do
(bcastInterval)
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.
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.
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
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.
.. 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.
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
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
¹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.
.. Algorithm Primitives
m
00
20
th
le ng
ck
Tra
ge
ran
ion
m iss m
n s 0
Tra 10
10
m
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
1e+008
1e+007
1e+006
Packets
100000
10000
.. 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
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
.. 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
100
95
Awareness Percentage
90
85
80
Zone Diffusion
Zone Flooding
75
100 1000 10000 100000 1e+006 1e+007
Packets Sent
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
.. 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
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
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
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 Ո
. I
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
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.
Chapter . A Uniform Publish-Subscribe Infrastructure
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
Host
Bus
Bus
Chapter . A Uniform Publish-Subscribe Infrastructure
.. Components
.. Events
.. 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.
Simulated V1
.. 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)
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)
.. PSI - a Publish-Subscribe Infrastructure
.. 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
Bus Bus
GPRS Ethernet
Bus
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.
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
RS 232 Bluetooth
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
.. 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 Ո
Abstract
. I
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.
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
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
Tile
DLP
RS-232 (IR ports,
UNC20 IR Modulator, LED
controller, LEDs)
.. 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
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).
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.
Application Layer
Middleware Management
Runtime Environment
Core
Runtime Engine
Execution Platform
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.
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.
:PoolModel
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
.. Assemblies
.. 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.
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:
. 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.
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 . 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;
}
}
}
. 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
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.
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 Ո
Abstract
. 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.
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.
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
.. 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;
}
}
}
}
it. e script in figure . can be created by using a text editor or by the user by
interacting with a tool.
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.
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.
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 .:
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:
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
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:
on my-device {
to my-service-b on my-device;
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;
}
}
}
}
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).
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-
Chapter . Handling membership dynamicity in service composition
a
Only participants responded to this question
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.
.. 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
. 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 Ո
Abstract
. I
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.
.. Introduction
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.
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.
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 [].
.. Indicators for Characteristics
Chapter . Issues in Service Composition for Pervasive Computing
Composite
Service
Specifies Specification Instatiated Service
Specifying Service
Actor
Optionals
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 ..
.. 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
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 JSE virtual machine on each node,
which significantly limits the set of nodes that can participate in the composite.
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
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
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 Ո
Abstract
. 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
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.
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.
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.
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.
.. Requirements on SOA Infrastructure
Traffic Navigation
Ice sensor
congestion system
Manufacturer
software prov. provider
Road Idividual
Assistance Idividual driver Driver
Company
Money
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.
Chapter . Service Oriented Architecture for Inter-vehicle Applications
ICE!
Road Authorities
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
[] 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, .
[] 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.
[] 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, .
[] 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 .
[] 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
–, .
BIBLIOGRAPHY
[] Dipanjan Chakraborty, Anupam Joshi, Tim Finin, and Yelena Yesha. Ser-
vice Composition for Mobile Environments. Mobile Networks and Applica-
tions, ():–, August .
[] T. Clausen and P. Jacquet. Optimized Link State Routing Protocol (OLSR).
http://www.ietf.org/rfc/rfc3626.txt, .
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 –, .
[] 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,
():–, .
[] 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, .
[] 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.
[] 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, ():–, .
[] Carlo Ghezzi, Mehdi Jazayeri, and Dino Mandrioli. Fundamentals of Soft-
ware Engineering. Prentice-Hall, .
[] 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,
.
[] Uwe Hansmann, Lothar Merk, Martin S. Nicklous, and omas Stober.
Pervasive Computing. Springer, .
[] 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 –, .
BIBLIOGRAPHY
[] 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.
[] Birgitta König-Ries, Michael Klein, and Tobias Breyer. Activity-based user
modeling in wireless networks. Mob. Netw. Appl., ():–, .
[] 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, .
[] 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.
[] 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 –, .
[] 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
, /:–, .
[] 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), .
[] N. Milanovic and M. Malek. Current solutions for Web service composi-
tion. Internet Computing, IEEE, ():–, .
[] 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 .
[] 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.
BIBLIOGRAPHY
[] 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 –, .
[] 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 –, .
[] 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, .
[] 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 –, .
[] 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/.
[] INVENT.
http://www.invent-online.de.
BIBLIOGRAPHY
[] OnStar.
http://www.onstar.com.
[] Sinalgo.
http://dcg.ethz.ch/projects/sinalgo/.
[] uClinux.
http://www.uclinux.org/.
[] UNC.
http://www.unc20.net/.