Supporting Environment Configuration with Generic Role Assignment.
ABSTRACT Due to the fact that distant objects are often less relevant to an application than objects in the proximity, middleware systems for pervasive computing typically exploit locality to improve efficiency. To do this, they configure the environment by introducing logical boundaries that reduce the number of interacting devices. Yet, in cases where applications require the interaction with distant objects, the boundaries become an artificial barrier that must be overcome by supplemental mechanisms. In this paper, we show how this problem can be avoided by using role assignment as a generic mechanism for environment configuration. To do this, we first derive the requirements for configuring a pervasive computing environment. We discuss how these requirements can be met by means of role assignment. To evaluate the approach, we present a prototypical implementation which we use to quantify the resulting overheads. The results indicate that role assignment enables a more flexible definition of boundaries at a low cost.
- SourceAvailable from: Renato Cerqueira[Show abstract] [Hide abstract]
ABSTRACT: We envision a future where people's living spaces are interactive and programmable. Users interact with their offices, homes, cars, malls and airports to request information, benefit from the resources available, and configure the habitat's behavior. Data and tasks are always accessible and are mapped dynamically to convenient resources present in the current location. Users may extend the habitat with personal devices that seamlessly integrate with the environment. Such user-oriented interactive environments may require a novel software infrastructure to operate their resources, sense context properties, and assist in the development and execution of applications. In this article, we present an experimental middleware infrastructure called Gaia that we have used to prototype the resource management of and provide the user-oriented interfaces for such physical spaces populated with network-enabled computing resources.Mobile Computing and Communications Review. 01/2002; 6:65-67.
Conference Paper: Portability, extensibility and robustness in iROS[Show abstract] [Hide abstract]
ABSTRACT: The dynamism and heterogeneity in ubicomp environments on both short and long time scales implies that middleware platforms for these environments need to be designed ground up for portability, extensibility and robustness. In this paper, we describe how we met these requirements in iROS, a middleware platform for a class of ubicomp environments, through the use of three guiding principles - economy of mechanism, client simplicity and levels of indirection. Apart from theoretical arguments and experimental results, experience through several deployments with a variety of apps, in most cases not done by the original designers of the system, provides some validation in practice that the design decisions have in fact resulted in the intended portability, extensibility and robustness. A retrospective examination of the system leads the authors to the following lesson: A logically-centralized design and physically-centralized implementation enables the best behavior in terms of extensibility and portability along with ease of administration, and sufficient behavior in terms of scalability and robustness.Pervasive Computing and Communications, 2003. (PerCom 2003). Proceedings of the First IEEE International Conference on; 04/2003
Conference Paper: Algorithms for generic role assignment in wireless sensor networks.[Show abstract] [Hide abstract]
ABSTRACT: We consider configuration of wireless sensor networks, where certain functions must be automatically assigned to sensor nodes, such that the properties of a sensor node (e.g., remaining energy, network neighbors) match the requirements of the assigned function. Essentially, sensor nodes take on certain roles in the network as a result of configuration. To help developers with such configuration tasks for a variety of applications, we propose generic role assignment as a programming abstraction, where roles and rules for their assignment can be easily specified using a configuration language. We present such a role specification language and distributed algorithms for role assignment according to such specifications. We evaluate our approach and show that efficient and robust generic role assignment is practically feasible for wireless sensor networks.Proceedings of the 3rd International Conference on Embedded Networked Sensor Systems, SenSys 2005, San Diego, California, USA, November 2-4, 2005; 01/2005
Supporting Environment Configuration with
Generic Role Assignment
Wolfgang Apolinarski, Marcus Handte, Pedro Jos´ e Marr´ on
Networked Embedded Systems Group
University of Duisburg-Essen
Abstract—Due to the fact that distant objects are often less
relevant to an application than objects in the proximity, middle-
ware systems for pervasive computing typically exploit locality
to improve efficiency. To do this, they configure the environment
by introducing logical boundaries that reduce the number of
interacting devices. Yet, in cases where applications require
the interaction with distant objects, the boundaries become
an artificial barrier that must be overcome by supplemental
mechanisms. In this paper, we show how this problem can
be avoided by using role assignment as a generic mechanism
for environment configuration. To do this, we first derive the
requirements for configuring a pervasive computing environment.
We discuss how these requirements can be met by means of role
assignment. To evaluate the approach, we present a prototypical
implementation which we use to quantify the resulting overheads.
The results indicate that role assignment enables a more flexible
definition of boundaries at a low cost.
Keywords-Role Assignment, Adaptation, Configuration
Pervasive computing envisions seamless task support by
means of applications executed on devices integrated into
everyday objects. Thereby, pervasive applications try to mini-
mize the user distraction by supporting tasks in an unobtrusive
manner which requires a high degree of automation. Due to
their integration, the devices encountered in pervasive systems
are often resource-poor and specialized. Moreover, the devices
usually interact with each other through wireless commu-
nication technologies and they may exhibit mobility. As a
result, pervasive computing applications are usually distributed
because they need to combine the specific capabilities of a
number of devices. Furthermore, they must be adaptive to deal
with the dynamics of the underlying networks.
To ease application development, existing middleware sys-
tems for pervasive computing can provide a diverse set of
supportive mechanisms. At the lowest level, they can provide
basic networking functionality. Beyond networking, the mid-
dleware systems can provide distributed object, service ab-
stractions or component frameworks to simplify development,
deployment and maintenance of applications. On top of that,
they may provide intelligent automation, for example, to adapt
applications to user preferences or to the available devices.
Intuitively, the resource utilization of many of these mech-
anisms is tightly tied to the number of devices that must be
considered. As an example at the networking level, consider
a mediator-based discovery scheme in which a central device
collects all device information. Such a scheme may only work
effectively in scenarios with a limited number of devices. At
the automation level, the same holds true. For example, to
automatically adapt a distributed application, it is often nec-
essary to compute possible configurations. As the number of
possible configurations increases with the number of devices,
this kind of automation is hard to apply to large scale systems.
Since distant objects are often less relevant to an application
than objects in the proximity, middleware systems typically
exploit locality to improve performance. To do this, they
introduce logical boundaries on the environment that reduce
the number of devices. Although, the idea of exploiting locality
is suitable in many scenarios, there are several cases in which
applications may need to interact with distant devices. Some
examples are scenarios that require access to resources in a
remote smart environment or scenarios that require the remote
collaboration of users in two separate smart environments.
In this paper, we show how this problem can be avoided by
means of using role assignment for environment configuration.
To do this, we first derive the requirements on environment
configuration and thereafter, we describe how role assignment
can be used as its basis. In order to evaluate the approach,
we present a prototypical implementation which we use to
quantify the resulting overheads. The evaluation indicates that
role assignment enables a flexible definition of boundaries at
a reasonable cost without introducing artificial barriers.
The remainder is structured as follows. Next, we revisit
the problem of environment configuration and derive its re-
quirements. In Section III, we describe the application of role
assignment to environment configuration and in Section IV,
we present a prototypical implementation. In Section V, we
evaluate the approach and in Section VI, we describe related
work. Finally, in Section VII, we conclude the paper.
The main goal of environment configuration is to identify
the set of devices of a pervasive computing system that may
interact with each other. Intuitively, due to the dynamics of the
underlying systems, the identification of these devices must be
done continuously at runtime. From this goal, we can derive
the following requirements on solutions that identify the set.
• Configurability: In environment configuration, the maxi-
mal set of devices is usually defined technically by means
of connectivity. However, in order to maximize the per-
formance, environment configuration typically strives for
determining a minimum set. Yet, in many cases it is not
feasible to clearly define the minimal set without running
the risk of excluding devices that may be relevant for an
application. In addition, a suitable definition may often
be scenario-specific. As a consequence, a generic solution
for environment configuration should be configurable in
order to support the definition of effective boundaries in
a scenario-specific way.
• Flexibility: Since distant objects are often less relevant
to an application than objects in the proximity, existing
middleware systems are exploiting locality to define the
boundaries. Thereby, they consider a single characteristic
of the context of a device such as a geographic location
or physical proximity. Although, this approach has been
proposed several times, it often does not result in minimal
sets. In many scenarios, characteristics such as the device
owner, for example, can be used more easily and result
in smaller sets. Thus, instead of being fixed to a sin-
gle context characteristic such as location, environment
configuration should support the flexible definition of
boundaries on various context characteristics.
• Composability: In order to avoid the introduction of arti-
ficial boundaries, environment configuration should sup-
port the on-demand extension of existing environments.
However, in order to avoid side-effects between different
applications and to allow the independent development
of various definitions for the execution environment,
the extension of the environment must be done in a
controlled manner. To do this, environment configuration
should support the composition of new environments by
composing them from existing ones.
• Efficiency: A primary goal of environment configuration
is to improve middleware and application performance by
minimizing the set of devices that they must consider. As
a consequence, environment configuration itself must be
light-weight. This is specifically true, since the dynamics
of pervasive systems require the continuous computation
of the set. Furthermore, in order to support resource-poor
devices, the mechanisms that are needed for configuration
should exhibit a small size.
To provide a solution to environment configuration that
fulfills the requirements described previously, we base our
solution on the idea of role assignment. As a consequence,
we first describe the overall idea of role assignment before we
discuss how it can be applied to the problem of environment
A. Generic Role Assignment
As described in , the basis for generic role assignment
is a set of devices that can communicate with each other.
Fig. 1. Using Role Assignment for Environment Configuration.
We assume that each device has some a priori knowledge
about its context and that it is able to perceive parts of its
context at runtime. Given that a lot of context such as the
device type and owner for example are usually static and that
more dynamic context such as the device’s location can often
be acquired automatically by means of built-in sensors or by
retrieving sensor values from other devices, this assumption
can be fulfilled by most mobile devices today. Furthermore,
we assume that the context of a device is stored locally so that
it can be accessed when needed.
Based on these assumptions, generic role assignment uses
the device’s context to assign roles. A role is essentially a tag
that can be assigned to one or more devices. By definition, a
role is assigned to any device as long as there are no further
constraints that limit the assignment. To enable the automated
computation of an assignment that reflects a particular goal,
we introduce rules. Rules define contextual constraints on the
assignment of roles to devices.
In , we identified 4 different classes of rules to support a
broad range of configuration tasks. However, for environment
configuration, we only require two classes of rules, which
we call filter rule and reference rule. A filter rule simply
constraints the set of devices to a set of devices that exhibits
a particular context. An example for such a filter rule is
to demand that all devices should be at a certain location.
A reference rule references other role assignments. As an
example for such a reference consider a rule that demands
that a device must exhibit a particular role. Thus, by using
reference rules, it is possible to assign roles hierarchically.
The set of roles together with their corresponding rules form
a role specification. To express complex logic, a single role
may be constrained using several rules that are combined using
the logical AND and OR operators. The logical NOT operator
is not supported as this can easily lead to sets that require the
evaluation of all globally connected devices. In practice, we
did not find this to be problematic since it is usually possible
to avoid NOT operators by an explicit enumeration of filters.
Given that the necessary contextual information is known to
each device, we can automatically assign roles to the devices
whose context satisfies the constraints specified by their rules.
Alternatively, we may also empower a user to manually assign
roles to support cases where the necessary context is not
available or where automation is not desirable. However, in
this paper, we focus on the automatic assignment, exclusively.
It is worth noting that a similar concept has also been pro-
posed to configure sensor networks  and distributed robot
systems . However, the role specification and algorithms
used in these works are specific to monitoring tasks and
distributed robot coordination. As a consequence, the overall
architecture and role specification language differ significantly.
For example, the approach taken in  focuses primarily on
network-related metrics whereas  applies utility functions
to achieve a targeted coverage.
B. Application to Environment Configuration
To apply generic role assignment to environment configura-
tion, we can use role specifications to define the boundaries.
The actual assignment of a single role can then be used to
define the set of devices. Thereby, we may reason about roles
from the perspective of the device, i.e. whether the device has
a certain role, or from the perspective of the overall system, i.e.
which set of devices has a certain role. Thus, we can identify
whether a particular device belongs to the environment and we
can identify the total set of devices that form the environment.
Figure 1 shows an example for this. To specify the typical
boundaries of a smart space, a developer can create a role
specification that assigns Role A to all devices whose location
is known to be inside Home A. To do this, the developer
creates a filter rule for the location and attaches it to role
A. After the assignment, the devices within the home can
be identified by the role. Intuitively, in order to cope with
changes, the assignment process must be performed at regular
intervals. Similarly, in order to specify the boundaries on the
basis of device ownership, a developer can specify a filter rule
that constraints the set of devices to a particular person (Role
B). In order to combine these sets of devices, two reference
rules can be used to reference the roles A and B. Using
Boolean operators it is possible to further restrict the set of
devices, e.g. to only select mobile ones. As we discuss later on,
the resulting role assignments can then be used independently
from their definition to optimize middleware functions.
To evaluate the approach, we have implemented a prototyp-
ical role assignment system. In the following, we first describe
the architectural components. Thereafter, we describe how they
interact. Finally, we describe some example mechanisms that
use an assignment for optimization.
Fig. 2.Generic Role Assignment System Architecture.
The individual layers and the high-level building blocks of
our generic role assignment system are depicted in Figure
2. Conceptually, the four main layers are communication,
context management, role assignment and services that use
the assignment as environment definition.
To enable communication between devices, we rely on
BASE , an existing communication middleware for perva-
sive systems. BASE provides the basic communication func-
tionality such as support for device discovery and interaction.
On top of that, BASE provides a basic service model that we
use to implement the remaining layers of the role assignment
system. Thereby, every building block is implemented as a
well-known service that can be accessed locally and remotely.
To automate role assignment, the system needs to be able to
automatically capture context information. Due to the differ-
ences in sensor APIs for various devices, the acquisition must
usually be done in a device-dependent manner. Additionally,
the context management layer is responsible for abstracting
from the details of gathering context information by providing
a uniform query interface. To represent context information,
we are using RDF  which enables data modeling and
reasoning on the basis of standard ontology languages such
as OWL. In order to query the RDF data, we use SPARQL
 basic graph matching patterns which we extend with non-
standard geo-spatial extensions for range and nearest-neighbor
queries. This allows us to express location-based queries which
are often useful for environment configuration. Consequently,
filter rules are formulated as SPARQL queries whose suc-
cessful evaluation determines whether a device matches the
filter. In order to support context provisioning on resource-poor
devices, we have implemented two alternative context services
for different classes of devices. On resource-rich devices, we
use JENA and ARQ to store context and to evaluate queries.
On resource-poor devices, such as mobile phones or Sun
SPOTs, we use a custom implementation that stores all context
information in-memory and implements a large subset of the
SPARQL language with limited reasoning capabilities over a
set of statically compiled ontologies.
On top, the generic role assignment layer provides the
functionality to define role specifications using roles and rules.
Once a role specification is passed to the role assignment layer,
it can automatically perform the assignment using context
information. To do this, the layer provides an assignment
service that computes an assignment. Once the assignment has
been computed, the roles need to be distributed to the devices.
This enables them to determine whether they exhibit a certain
role. To perform this distribution in an application-independent
manner, the role assignment layer includes a notification
service which is notified by the assignment service whenever
a local assignment changes. Note that the assignment service
is not needed by each device. Instead, it is only necessary
on those devices that are actually computing an assignment.
Thus, to minimize the resource consumption, it is possible to
deploy only the notification service.
At the service layer, other services and applications may use
the role assignments to optimize their mechanisms. Thereby,
they can use the local notification service to react to changes
of roles. Alternatively, they can query the assignment service
in order to retrieve the current assignment. The former reflects
the per device view, the latter reflects the system view.
To clarify the architecture, we describe the runtime in-
teraction of its components in the following. As explained
earlier, each device is equipped with an instance of BASE and
the additional services that form the generic role assignment
system. To configure an environment or an application, a
middleware service may start a role specification by sending
it to a device equipped with an assignment service.
Since multiple role specifications may use the same role
identifiers, the role assignment service first creates a globally
unique id for the specification. This enables the unique iden-
tification of individual roles which is required to reference
a particular role. To do this, the role assignment service
concatenates the BASE device id with a locally unique id.
Once the id has been assigned, the assignment service analy-
ses the specification to determine whether the role specification
references some other role specification by means of reference
rules. If the role specification does not contain reference rules,
the assignment service creates a list of all SPARQL queries
that represent the filter rules. Thereafter, it sends a single batch
query to all connected devices. Once the list of responses is
returned, the role assignment service evaluates the Boolean
expression over the rules and computes the assignment.
If the role specification contains reference rules, the assign-
ment service forwards the specification to the assignment ser-
vice that is executing the referenced role specification. If a role
contains multiple references, the specification is forwarded to
each referenced assignment service. The assignment service
that receives the specification will then execute it locally.
Thereby, it considers only those reference rules that refer-
ence local assignments. The other rules are simply ignored.
After the assignment has been computed at the referenced
assignment service, a list of candidate assignments is returned
Fig. 3. Generic Role Assignment Example
to the original assignment component. There, the candidate
assignments are transformed into final assignments. To do this,
the assignment component may have to intersect or unify the
candidate sets in order to compute the result in cases where
multiple references are concatenated using a conjunction or a
Once the final role assignment has been determined, the role
assignment service calls the notification service on each device
that receives at least one role. Thereby, the service transmits
all assigned roles. Applications may register local listeners at
their notification service to receive changes to assignments.
An example for this process is depicted in Figure 3. The
figure shows 7 devices that execute two role specifications.
The first role specification defines two environments using the
roles A and B. Both roles solely rely on filter rules in order to
define the sets of devices. In order to keep the figure simple,
we refrain from using SPARQL syntax, instead we simply
assume that role A requires context A and role B requires
context B. Once the role specification is started at device 6, the
device assigns a unique id, i.e. <6><id-1>. Thus, the roles
can be identified by concatenating the role specification id with
the role name, i.e. <6><id-1><A> or <6><id-1><B>.
Since there are only filter rules, the assignment component
queries the context of the connected devices and computes
the assignment according to the rules. Finally, the assignment
component notifies all devices that received a particular role.
The second role specification in the example refers to the
first specification to define an environment using role C that
consists of all devices that have role A or B. When the
role specification is started at device 7, the unique id is
generated and the role specification is analyzed. Since the role
specification contains reference rules, the role specification is
forwarded to the devices that are managing the referenced
specification. In this example, this is done by device 6. To
determine the managing device, the device 7 can simply use
the BASE id that is embedded in the reference. Device 6 then
computes the candidate set consisting of devices with role A
and role B and returns it to device 7 which performs the final
assignment. In this example, the candidate set and the final
set are identical. However, if several specifications on multiple
devices are referenced, it may be impossible to determine the
Fig. 4.Role-based Communication
set locally on the referenced devices. Once the set has been
computed, device 7 notifies all relevant devices.
To validate the architecture of the role assignment system
with respect to its interfaces, we modified the BASE service
registry so that it benefits from the environment configuration.
In addition, we have implemented a BASE communication
plug-in that provides environment-based communication. In
the following, we briefly outline the implementation.
To enable the spontaneous interaction of devices, BASE
not only supports device discovery and interaction but it also
provides a simple service abstraction. In order to find local and
remote services, BASE provides a service registry. To support
the dynamics of pervasive systems, the BASE service registry
uses a reactive federation scheme. Each BASE-enabled device
is equipped with a local registry that can be accessed locally as
well as remotely. In order to export a service, an application
simply calls an export function on the local registry which
stores the associated service information. To search for avail-
able services, an application can call a search function locally.
Internally, the search is then automatically distributed across
all devices in order to return the complete set of services.
To improve the efficiency of the federation scheme, we have
extended the registry to support the search within a particular
environment. To do this, an application developer can define an
environment using a role specification. Later on, the developer
can search within the environment by sending a query and an
associated globally unique role identifier to the local registry.
Internally, the registry will then first contact the assignment
service to retrieve the devices that exhibit the role and later
on, it will only forward the queries to these devices. Thus, we
speed up the search by minimizing the set of devices.
In addition to this, we have implemented a BASE com-
munication plug-in that provides environment-based commu-
nication. Similar to the service registry, the communication
plug-in restricts the distribution of a particular message to an
environment that is defined by a role assignment. To distribute
the load of message forwarding, the plug-in uses the hierarchy
that is created by reference rules for distribution. When a
device receives a role, it may use the role to join a group
communication channel using the BASE plug-in. If a message
must be transmitted, the plug-in simply forwards the message
to the device that performs the assignment. This device then
forwards it to other devices, either directly - if it has performed
the assignment - or indirectly - if it uses another device to
compute candidate sets.
An example for this is depicted in Figure 4. If device 2 sends
a message using the channel defined by role C, it forwards
the message to device 1, since this device is responsible for
performing the assignment. Device 1, in turn, uses device 5
to compute parts of the assignment and thus, it forwards the
message to this device. Furthermore, device 1 distributes the
message to all devices with the role A, since it has performed
the assignment for this role. If the message arrives at device
5, the device distributes the message to all devices with role
B, since it is responsible for assigning this role.
In this section, we evaluate the approach. To do this, we
first discuss the requirements on configurability, flexibility and
composability before we determine efficiency experimentally.
As discussed in Section II, approaches that support envi-
ronment configuration should be configurable, flexible and
composable to be applicable to a broad range of scenarios.
In the following, we briefly discuss why and how generic role
assignment fulfills these requirements.
• Configurability: By design, environment configuration
that is implemented using generic role assignment can be
flexibly configured to meet the needs of the applications.
To do this, an application developer may specify arbitrary
filter and reference rules that can be evaluated automat-
ically at runtime. Thereby, the developer may start and
stop a number of role specifications on-demand in order
to enable the definition of sets that result in an optimal
middleware and application performance.
• Flexibility: Environment configuration with generic role
assignment is not primarily based on location. Instead, it
enables developers to define boundaries using properties
of the device context. Clearly, in order to use a property
in a role specification, it must be available on the relevant
devices. However, when looking at the increasing number
of sensors that are deployed in current smart devices, it is
conceivable that many devices will be able to perceive a
large part of their context. As a result, role assignment in-
creases the flexibility of environment configuration when
contrasted with the locality-based approaches.
• Composability: Generic role assignment is not limited
to a single role specification. Instead, multiple specifi-
cations may be developed independently and executed
simultaneously. The support for reference rules within
role specifications enables the hierarchical composition of
environments. By supporting the hierarchical composabil-
ity, generic role assignment can be used to dynamically
extend existing environments in a controlled fashion.