Handling Heterogeneity in Context Aware Services

Ronald van Eijk

, Arjan Peddemors

, Johan de Heer

, Alfons Salden

Petri Määttä

, Ville Haataja

Telematica Instituut, PO Box 589, 7500 AN Enschede, The Netherlands, www.telin.nl

VTT Electronics, Telecommunication Systems, P.O. Box 1100, FIN-90571, Oulu, Finland

Abstract. The increasing number of context aware applications, sensing

technologies and positioning algorithms ask for a generic framework that is

able to handle the large heterogeneity in contextual information. Thereto, we

propose a layered context model that describes the heterogeneity in location

information and a reference architecture that contains Distributing Servers and

Location Operation Servers. The proposed framework can support location

services in a heterogeneous environment. Finally we demonstrate the viability

of our framework by implementing parts of our architecture related to a

location service. Our service makes use of two different positioning

technologies, based on WLAN and Bluetooth infrastructures respectively.

1 Why is there a Need for Handling Heterogeneity?

The present variety of positioning technologies for indoor as well as outdoor settings

is large and the diversity of targeted end-users, devices and applications they have

been developed for is growing as well. Originally many specific user groups and

professions have required highly limited and restricted navigation tools. These

technologies have been developed according to specific application requirements but

after being implemented they have found broader use, i.e. use by other types of

applications. However, the applications are specifically proprietary and not easy to

use in other network environments. Furthermore, for these different environments

other positioning technologies, e.g. based on wireless local area network or mobile

phone base station networks have been developed. There is extensive literature about

positioning technologies, location information representation and how to deal with

location information. For an overview of positioning technologies we refer to [1] and

[2]. An excellent overview of location modelling work can be found in [3]. A few

important research results will be discussed here.

The solutions mentioned here are not technology and application independent.

Therefore, we will define a framework that is both technology and application

independent. Our solution will be capable of dealing with the whole process of

sensing the location, processing and combining location information and distributing

it to interested entities. In our view there are two major functional requirements that

have to be satisfied by our envisioned generic framework, namely:

van Eijk R., Peddemors A., de Heer J., Salden A., Määttä P. and Haataja V. (2004).

Handling Heterogeneity in Context Aware Services.

In Proceedings of the 1st International Workshop on Ubiquitous Computing, pages 18-27

DOI: 10.5220/0002656300180027

 SciTePress

• Handling heterogeneity of sensing technologies, among which are those for

positioning, e.g. positions may be calculated from the network or determined

from sensors or beacons.

• Sustainability of contextual parameters, e.g. parameters describing the

situation of a group of users being in a meeting

In line with these functional requirements we aim in this work to combine two

positioning technologies that are not compatible with each other, i.e. they do not

support the same coordinate system and their methods for determining and

representing location information are significantly different. However in many future

scenarios some of these technologies or like in some cases, all of them, are embedded

or attached to the same physical device, e.g. a PDA or laptop. In other words different

applications running on one device have to be able to use different technologies or

even combine location information that comes from these different technologies. This

can only be done if the details of the technology are shielded from the application,

and location information is always communicated in a way that the application

understands. This makes it a challenge to develop an application or a service that is

able to use all possible positioning technologies to acquire location information in

every situation and as accurate as possible in a generic way that is independent of the

technical details of the positioning technology.

In the next section we propose a context model that is required to describe and model

the heterogeneity in location information. When location information has to be

communicated between clients and servers, intelligent Distribution Servers and

Location Operation Servers have to be defined. Therefore, we propose a reference

architecture for intelligent location handling in section 3. In section 4 we describe our

implementation of a Location Service to demonstrate our ideas. This service makes

use of two totally different positioning technologies and shows how our framework

can handle heterogeneity in location information caused by various positioning

technologies. In section 5 we draw conclusions on our ideas and our implementation.

2 A Five Layer Context Model

In order to share contextual information with other applications and users, contexts

need to be represented in a generic way to a certain degree. This requires knowledge

modelling with respect to contexts. Dey et al. [5] pointed out that context models have

always been application dependent. Hence, there are not really generic context models

suitable for all kinds of applications. For our purposes we will use a context model in

order to define context levels (different levels of abstraction); mappings and

operations on contextual representations; reuse in applications; roaming between

different positioning technologies.

In particular we follow the context model given by Ailisto et al. [9] and apply their

context model for location information services using different positioning

technologies. In their model different abstraction levels are defined for context

processing objects and the location information that they produce (see Fig. 1). In this

model information is processed and combined by objects at different levels as

follows: (1) On a physical level, position is measured by hardware equipment, e.g. by

a terminal or sensors observing signal strengths or Cell Ids, respectively. (2) On the

data level, this information is processed and new data is computed, e.g. the absolute

location of an object in x,y coordinates. (3) On the semantic level semantic

information is collected (for example references to other places in the world) and used

to enrich the location data and produce location information that is more meaningful

and understandable to both applications and human users. (4) On the inference level,

information is used from the semantic level, history information and inference rules,

possibly dynamically learned, to make educated guesses what the user is doing and

what kind of services he might want. (5) On the application level, decisions are made

about taking actions triggered by situations defined at the inference level.

It should be noted that location information on a higher abstraction level may

combine input from one or more sources of information defined at lower levels. This

is indicated in Fig. 1 by input arrows.

Sensor

Data processing

Object

Semantic processing

object

Inference

object

Application

Level 1: Physical

Level 2: Data

Level 3: Semantic

Level 4: Inference

Level 5: Application

Sensor output

Processed data

Semantic information

Inferred result

Context levels

Location example

WLAN

Hardware

Positioning Server

Building Map

Server

Presence Server

Instant Messaging

Signal Strength

x,y coordinate

Room number

User is in room

User

Identification

Building map

database

Fig. 1. Layered context model. Adapted from [9].

3 A Reference Architecture for Location Information Handling

Because high-level applications and users cannot deal with low-level sensor data, it is

necessary to introduce a reference architecture that collects raw sensor information,

translates it to an application-understandable format, and disseminates it to interested

applications or end-users. In this section we present such a reference architecture that

makes use of our context model presented in Section 2. Note that other reference

architectures are possible that could support our same context model, because our

model is not dependent of any architecture.

First, we describe the components of a physical frameworks and their functionality.

Second, we describe in more detail the two main architectural components: Location

Operation Servers and Distribution Servers. Finally, we give an example to illustrate

the roles of the components in an intelligent location handling system.

3.1 System Architecture and its Functional Components

For our system architecture we were inspired by the layered architecture of the TEA-

system [4] and the Context Toolkit [5]. The following components form the basis of

an architecture that can be used to determine position, to exchange location

information and to present it to users and applications:

• Positioning units. For example the user’s device itself that has a hardware

interface to perform measurements or that can receive information from

sensors in the environment. These units produce physical information, e.g.

signal strength. Two ways are possible (and might even be mixed): sensory

data coming from the user's device and sensory data coming from devices in

the user’s neighbourhood (e.g. WLAN access points).

• Location Operation Servers. Servers that can transform, adapt, pre-process

and do calculations on location information.

• Distribution Servers. These servers have the task to collect, store and

distribute location information according to queries.

• Client devices. The client device will be equipped with different

communication interfaces (GPRS, WLAN) and different positioning

technologies (GPS, WLAN, Bluetooth beacons).

Together, these entities are part of an architecture, in which location information is

requested, obtained, forwarded, processed etc. The roles of Location Operation

Servers and Distribution Servers will be explained in more detail now.

Location Operation Servers. In our reference architecture the heterogeneity in

location representations and positioning technologies can be handled by what we will

refer to as “Location Operation Servers” where the transformation and adaptation

process is done in one or several specific instances that could function in a distributed

manner. A Location Operation Server can for example enrich location information

with references to other information, e.g. a map, and thus convert it to a more

semantic level according to our context model (see Fig. 1). Another example is

calculating the distance between two objects.

Distribution Servers. Because applications require different forms of location

information about a specific client, it should be possible to receive different types and

formats of location. In order to realise this the Distribution Server can send

information in the right format and to the right interested entities. Only when location

has been described in a rich way, the Distribution Server can carry out queries for

different levels of accuracy, granularity and richness of location information. Such a

Distribution Server can be a moving object database [11] for example. This server

may communicate with Location Operation Servers to perform operations on location

information.

3.2 Handling Diverse Location Information in a Guidance Service Scenario

Let us define a scenario in which a maintenance service person equipped with a PDA

searches target objects that need maintenance. The terminal that the maintenance

person is using is carrying one or several technology modules that can be used for

location determination, e.g. GPS, WLAN or Bluetooth modules. This person is guided

though a large building using a guidance service. This service must receive the user’s

location in the form of logical indoor location, i.e. the user is in room 224 or the user

is on the stairs between floor 2 and 3. Obviously the service does not know or care

about the technology used to actually determine the user’s location. Indoors the GPS

cannot be used, but then the service still has to deal with two different technologies

that may be used: the WLAN based or the Bluetooth based positioning technology.

As data and information is passed from the mobile host to the route planner server, it

is adapted to the needs of the service. First we describe the two technologies used for

deriving the user’s location and then we present the architecture that can deal with

those different technologies.

WLAN based positioning. In case of a WLAN positioning technology (see [7] and

[8]), a Location Operation Server will work in the following way. The client device is

equipped with a WLAN interface and a positioning unit that collects signal strength

information of at least two, preferably three, WLAN access points. These signal

strength measurements are sent to the user’s Distribution Server. The Distribution

Server determines which other servers need to receive the user’s location information

and use one or more Location Operation Servers to convert the raw data into the

required format. Our Location Operation server uses a method called location

fingerprinting, which is based on learning. The signal strengths associated with a

number of locations are measured in the learning phase and recorded into a table

containing the coordinates of each location, the signal strengths and possibly some

related semantic information, such as the name of the room. In this case, the signal

strength values are used to calculate x,y,z information. Then, the x,y,z coordinates are

used to determine the logical location information. The logical location information is

then forwarded to the Distribution Server of the guidance service.

Bluetooth based positioning. The mobile hosts with a Bluetooth interface work in a

different way. The Bluetooth positioning unit collects signal strength information

about available Bluetooth location providers. The best location provider, selected

using the measured signal strengths, supplies the logical location information to the

user’s Distribution Server. This server can now send the information to the

Distribution Server of the guidance service, without adaptation (so, without using a

Location Operation Server).

Positioning

unit

Location Operation

Server

(x,y)

Client A

(x,y)

Distribution

Server

telin.nl

(x,y)

Distribution

Server

vtt.fi

Client B

(((

Map

Fig. 2. The main entities in a reference architecture that handles location. SA = Signal strength

data for client A. In this example client B is subscribed to (x,y) coordinates of client A.

Fig. 2 illustrates this example. This figure shows how client B, in our case, the

guidance service, requests the position of a client A, the maintenance service person.

These can be two users interested in each others position or, as in our scenario, one

user and an application that is interested in the position of that user. Client B wants to

have this position as an x,y coordinate. However, client A can only provide signal

strengths. So in this example a mapping from signal strength to x,y coordinates take

place. This is a transition from physical level to data level.

Fig. 2 also shows how the flow of information takes place. From this figure one can

see that it is the Distribution Server that is responsible for providing coordinates and

thus it will access the Location Operation Server to convert the information. The

advantage of letting intelligent Distribution Servers communicate with the Location

Operation Servers instead of the client is that the client now only has to communicate

with the Distribution Server for sending physical data. This limits the amount of

wireless communications. Disadvantage of this approach is that the Distribution

Server has to be aware of the context of the client. But probably the Distribution

Server is located close to the client and has access to local maps, service directories

and organisational information related to the user.

4 Implementation of a Location Information Handling Service

Two existing positioning technologies, both using different wireless techniques and

both with different ways of determining the actual position of a mobile client have

been used for implementation of part of the proposed solutions. To illustrate our ideas

we started with implementing a generic, i.e. technology independent location handler

interface and a generic location representation format. This section will be concluded

with a description of an exemplary application: the location service.

4.1 The Positioning Technology Independent Location Handler Interface

We have limited our scope by selecting two positioning systems based on WLAN and

Bluetooth technologies respectively to make it easier to implement quick trials to

proof our conceptual framework. In this architecture the positioning hardware itself is

wrapped and hidden from the applications and application developers. Instead the

system provides them a more generic interface to communicate with positioning

technologies to help the design process of the applications and services using

positioning information for their purposes, e.g. tracking or adapting them to user

needs. A well-defined interface layer between hardware and applications provides the

necessary freedom to application engineers to develop location aware services that are

able to use any of different technologies possibly even simultaneously.

4.2 Location Format Compliant to the Mobile Location Protocol

A generic location format at the data level enables the description of location

information at different levels and makes the information useful for different location

aware applications. Main constraint to this format is that it should be technology

independent and that it should be shareable with all possible other applications. For

each level presented in Fig. 1, more parameters are added, but by embedding basic

data in the new enriched format, backwards compatibility should also be sustained.

Finally, a generic location format allows one to match location information to the

different requirements of applications, for example, in terms of accuracy and

granularity. We propose to use the following parameters: (1) Name of the technology

used to obtain this position, (2) Coordinates and a reference to the corresponding

coordinate system, (3) Date and time (to indicate freshness of location) and (4)

Accuracy.

In implementations of our reference architecture a XML based location presentation

language can be used for creating the final location information presentation in the

application layer. In our implementation the presentation form used in carrying the

location information from client to server and further to the subscribers is based on a

subset of the Mobile Location Protocol (MLP 3.0.0), which was defined by the

Location Interoperability Forum (LIF) and is expected to be supported and developed

by the Open Mobile Alliance (OMA, see [12]). It’s structure and parameters make

this protocol well suited not only for describing location but also for querying it.

Another important advantage is its extensibility, simple format and readability.

4.3 Implementation of the Positioning Technology Independent Location

Service.

In both positioning technology cases the location information is stored in a PLIM

(Presence and Location Instant Messaging) server. The PLIM server is a slightly

modified version from the original Instant Messaging (IM) [6] server where just the

presence information was available for clients to subscribe to. In the current modified

PLIM architecture the location information is updated and subscribed as the presence

information in basic IM platform. The PLIM server stores the location (XML based)

presentations in its database and provides them to clients. All the PLIM clients log

into one of the PLIM servers and provide their location information (if capable) to the

server where it is stored in the form of a Mobile Location Protocol (MLP)

presentation. Then other clients are able to access this information if their permissions

are set to allow browsing of location information. The PLIM server is administrating

these user restrictions. In other words, we have used PLIM as a Distribution Server.

Using a publish-subscribe mechanism in the Distribution Server, each interested

entity receives information that is in a format that is suitable for carrying out its own

task. For example, one client might only be interested which room a user is in, while a

tracking application might want to have building coordinates. Nevertheless, they can

subscribe to different sets of location information that is related to the same physical

position of that particular user.

Fig. 3. Map of a large meeting room showing the position of two users equipped with PDAs.

To determine and provide their position, one user is using WLAN technology (WiFi) and the

other is using Bluetooth technology

Then we used the positions of two clients and showed them on a map. This map is a

client of the Distribution Server and receives updates of two users, one using the

Bluetooth positioning technology and one using the WLAN positioning technology.

The complete concept of the map application is presented in Fig. 3.

Depending on the hardware the client software picks the right positioning method and

executes the initialization process accordingly. The technology specific location

handler launches a location update process to acquire the latest position of the device

and delivers it to the Distribution Server that can forward this information to other

clients or entities. Distribution of the location information to other users makes it

possible to see each other on the same map. Distribution to other interested

applications makes it possible to reuse the position in other applications, for example

an Instant Messaging application that wants to know if a user is in his office and thus

available for a chat session.

In the case of WLAN positioning the update process is measuring the signal strength

values from the base stations and delivering them to the location server for

calculations of the location. The location server could also act as an information

source for multiple intelligent services, e.g. tracking or distance calculation services

but the only function currently implemented is a basic service providing xy-

coordinates from signal strengths.

When Bluetooth access points are used, the position is acquired directly from the BT

access points. The client device determines its position (a room) based on the

strongest signal it receives from one of the access points. This means that the access

point functions both as positioning unit and Location Operation Server, because it

maps to a physical location.

Note that this application is now able to use two different technologies to position the

user. This has been made possible because the terminal has a generic interface and

because the application uses the same location format and both technologies share the

same coordinate system, i.e. the same map of the room.

5 Conclusions

A generic framework has been proposed that handles simultaneously the

heterogeneity of both positioning technologies and location representations. The main

characteristic of the framework is a strong functional separation of functionality for

distributing and for processing location information. Location Operation Servers have

been defined to do operations to add information to a location information object

enriching it and bringing it to a higher more meaningful level (from physical level to

data and semantic level). We defined Distribution Servers based on a

publish/subscription mechanism to deal with exchanging location information

between different users or entities. This means that the intelligence that is required for

location handling is not in the Distribution Server nor in the client device, but in

specialized functional components, i.e. the Location Operation Servers.

Our implementation of a location service proved that our context model and reference

architecture are a good basis for building a system that can deal with heterogeneity of

location information. In this case an application was build that made use of two totally

different positioning technologies.

6 References

1. Hightower, Jeffrey and Boriello Gaetano (2001). Location systems for

ubiquitouscomputing. In IEEE Computer, August, pp. 57-66.

2. Chen, G. and Kotz, D. (2000). A survey of Context-Aware Mobile Computing Research.

Darthmouth Computer Science Technical Report TR2000-381.

3. Beigl, M. Gray, P. and Salber, D. (2001). Location modeling of ubiquitous computing.

Workshop proceedings Ubicomp 2001, Atlanta – September 30, 2001

4. A. Schmidt and K. A. Aidoo and A. Takaluoma and U. Tuomela and K. Van Laerhoven

and W. Van de Velde (1999). Advanced Interaction in Context. LNCS 7007, p.89

5. Dey A. Understanding and Using Context, Personal and Ubiquitous Computing (2001) 5:4-

6. Peddemors, A., Lankhorst, M. & De Heer, J., Presence, location and instant messaging in a

context-aware application framework. 4th International Conference on Mobile Data

Management (MDM2003), 21-24 January, 2003, Melbourne, Australia

7. VTT Electronics, Indoor Navigation Using WLAN 802.11 Positioning, Retrieved March

2003 from http://www.6winit.org/presentations/ist/vtt_6winit.pdf

8. Bahl, P., Padmanabhan, V.N., "RADAR: An In-Building RF-Based User Location and

Tracking System," Proc, IEEE Infocom 2000, Tel Aviv, Israel, March 2000.

9. Ailisto, H., Alahuhta, P., Haataja, V., Kyllönen, V. and Lindholm, M. (2002). Structuring

Context Aware Applications: Five-Layer Model and Example Case, Position Paper, VTT

Electronics, Oulu, Finland. Presented at “Models and concepts for ubiquitous computing”,

workshop at UbiComp 2002, Göteborg, 2002.

10. Svetlana Domnitcheva (2001). Location Modeling: State of the Art and Challenges.

Location modeling of ubiquitous computing. Workshop proceedings Ubicomp 2001,

Atlanta – September 30, 2001

11. Ying Chen, Fangyan Rao, Xiulan Yu, Dong Liu, CAMEL: A Moving Object Database

Approach for Intelligent Location Aware Services. 4th International Conference on Mobile

Data Management (MDM2003), 21-24 January, 2003, Melbourne, Australia

12. Open Mobile Alliance. http://www.openmobilealliance.org/