A Decentralized Location Service Providing Semantic Locations · PDF fileA Decentralized Location Service Providing Semantic Locations ... 9.3.7 Discovery, ... Europe will set up a

A Decentralized Location ServiceProviding Semantic Locations

Habilitationsschrift

dem Fachbereich Informatikder FernUniversität in Hagen

vorgelegt von

Dr. rer. nat. Jörg Roth

am 25. Oktober 2004

angenommen am 8. Dezember 2004

PART I: CONTEXT, LOCATION-BASED SERVICES AND POSITIONING ............1

1 Introduction .......................................................................................................1

2 Context and Location-Awareness ....................................................................52.1 The Notion of Context and Situation..........................................................52.2 Location-Awareness and Location-Based Services ....................................62.3 Summary...................................................................................................11

3 Positioning Systems .........................................................................................133.1 Introduction...............................................................................................13

3.1.1 Properties of Location Data..........................................................133.1.2 Basic Location Techniques...........................................................15

3.2 Satellite Positioning Systems....................................................................163.2.1 Basic Principles ............................................................................163.2.2 GPS...............................................................................................183.2.3 DGPS and WAAS.........................................................................213.2.4 Other Satellite Systems ................................................................21

3.3 Indoor Positioning Systems ......................................................................223.3.1 Infrared Beacons...........................................................................223.3.2 Radio Beacons..............................................................................253.3.3 Ultrasound Systems......................................................................263.3.4 Video-Based Systems ...................................................................27

3.4 Network-Based Positioning ......................................................................283.4.1 GSM .............................................................................................283.4.2 Wireless LAN ...............................................................................30

3.5 Summary...................................................................................................31

PART II: THE NIMBUS LOCATION SERVICE FRAMEWORK ............................33

4 Nimbus Overview ............................................................................................334.1 Goals and Objectives ................................................................................334.2 The Nimbus Software Architecture ..........................................................35

4.2.1 The Base Layer.............................................................................364.2.2 The Service Layer.........................................................................374.2.3 The Application Layer..................................................................37

4.3 Overview of the Next Chapters ................................................................37

5 The Nimbus Location Model..........................................................................395.1 Introduction...............................................................................................395.2 Related Work ............................................................................................405.3 The Nimbus Location Model....................................................................42

5.3.1 Structuring the Space Using Domains and Hierarchies ...............435.3.2 Associations..................................................................................455.3.3 Operations on the Model ..............................................................475.3.4 Compressing Associations ...........................................................485.3.5 Abstract Domains .........................................................................525.3.6 A Realistic Example .....................................................................53

5.4 Summary...................................................................................................54

i

6 The Nimbus Runtime Infrastructure............................................................ 576.1 Introduction.............................................................................................. 576.2 Related Work............................................................................................ 576.3 The Nimbus Service Infrastructure .......................................................... 58

6.3.1 Distributing Domains Among Location Servers ......................... 596.3.2 Performing Resolution Operations .............................................. 626.3.3 The Role of the LLS .................................................................... 666.3.4 Looking up Location Servers....................................................... 666.3.5 Protocol Details ........................................................................... 68

6.4 Caching .................................................................................................... 736.5 Performing Triggers ................................................................................. 776.6 Summary .................................................................................................. 78

7 Integrating Positioning Systems.................................................................... 797.1 Introduction.............................................................................................. 797.2 Related Work............................................................................................ 797.3 Processing Location Data in Nimbus....................................................... 83

7.3.1 Modelling Locations .................................................................... 857.3.2 Accessing Positioning Systems (VPS 1) ..................................... 877.3.3 Mapping Locations (VPS 2) ........................................................ 897.3.4 Handling of Several Positioning Systems (VPS 3)...................... 907.3.5 Resolving Locations (VPS 4) ...................................................... 967.3.6 Extending the Semantic Resolution Algorithm ........................... 987.3.7 Simulating Positioning Systems ................................................ 101

7.4 Proximity Resolution ............................................................................. 1027.5 Summary ................................................................................................ 104

8 Geocasting ..................................................................................................... 1058.1 Introduction............................................................................................ 1058.2 Related Work.......................................................................................... 1068.3 Semantic Geocast Using Nimbus........................................................... 109

8.3.1 The Semantic Geocast Mechanism............................................ 1098.3.2 Address Propagation...................................................................1118.3.3 Message Passing .........................................................................1128.3.4 Dealing with Restrictions, Scalability ........................................1138.3.5 Security Issues ............................................................................1158.3.6 Further Details ............................................................................115

8.4 A Sample Nimbus Application Using Geocast Services ........................1168.5 Summary .................................................................................................117

9 Communication and Security Issues............................................................1199.1 Introduction.............................................................................................1199.2 Related Work.......................................................................................... 1209.3 The Network Kernel Framework ........................................................... 121

9.3.1 Protocols, Modules, and Methods ............................................. 1219.3.2 Network Modules ...................................................................... 1249.3.3 Security ...................................................................................... 1259.3.4 Encoding and Decoding Data .................................................... 1269.3.5 Identifying Hosts, Devices, and Services .................................. 126

ii

9.3.6 Specifying Connection Properties ..............................................1279.3.7 Discovery, Lookup, and Negotiation..........................................1289.3.8 State of the Implementation........................................................1289.3.9 The Role of NKF in the Nimbus Framework.............................130

9.4 Security Considerations ..........................................................................1309.4.1 Secure Communication and Authenticated Servers ...................1319.4.2 X.509 Certificates.......................................................................134

9.5 Summary.................................................................................................135

10 Location-based Services Using the World Wide Web................................13710.1 Introduction.............................................................................................13710.2 Location-Based Applications in Browser Environments .......................13810.3 The PinPoint Approach...........................................................................139

10.3.1 Data Flow in the PinPoint Component.......................................13910.3.2 Context Information ...................................................................14010.3.3 PinPoint Tags..............................................................................14010.3.4 Security Issues ............................................................................14310.3.5 Implementation Details ..............................................................144

10.4 A Tourist Guide with PinPoint................................................................14410.5 Summary.................................................................................................145

11 Acquiring, Storing, and Processing Domain Data......................................14711.1 Introduction.............................................................................................14711.2 Spatial Data.............................................................................................14711.3 Spatial Data in Nimbus...........................................................................150

11.3.1 Two-Dimensional Data Representation......................................15011.3.2 Considering the Third Dimension ..............................................154

11.4 Import of Data from Land Survey Sources.............................................15811.4.1 Import of Data from ATKIS Data Files......................................15911.4.2 ATKIS Import Result..................................................................163

11.5 Summary.................................................................................................166

PART III:ANALYSES, FUTURE WORK AND SUMMARY ..................................169

12 Performance Analyses...................................................................................16912.1 Introduction.............................................................................................16912.2 Location Server Performance .................................................................16912.3 Cache Efficiency.....................................................................................17212.4 Area Resolution ......................................................................................17412.5 Compression ...........................................................................................17512.6 Summary.................................................................................................177

13 Conclusion and Future Work.......................................................................17913.1 Implementation Details...........................................................................17913.2 Summary of the Nimbus Concepts .........................................................17913.3 Future Work ............................................................................................182

Bibliography .......................................................................................................185

Index....................................................................................................................197

iii

iv

Part I: Context, Location-Based Services and Positioning

1 Introduction

The answer to the question "Where am I?" is becoming increasingly important formobile users. In the future, it will not only be sufficient to know the coordinates of thecurrent location, but also to know information about the current location. Typical ques-tions will be: "Where is the nearest hotel?", "Which bus takes me from here to the rail-way station?" or "Who of my friends are currently in this restaurant?".

Over the last years, many researchers developed so-called location-based servicesand location-aware applications that take into account the user’s current location andrespond to such questions. For such services, experts expect a huge market potential ofseveral billion dollars in revenue worldwide in the next years [85, 167]. The followingtechnologies are closely related to the success of location-based services:

■ In the last years, wireless communication technologies have become very success-ful. In some areas they replaced traditional wired technologies. Wireless communi-cation technologies range from personal area networks (e.g. Bluetooth) over localarea networks (e.g. WLAN 802.11) to cell phone networks (e.g. GSM, UMTS). Inthe year 2003, more than 1.2 billion people in the world used mobiles phones [111].

■ In addition to mobile phones, many new mobile hardware platforms have becomeavailable. Powerful notebooks are getting smaller and smaller while still providingnearly similar computing power as desktop computers. Small computers such asPDAs, handhelds or smart phones provide a high mobility, battery lifetime andbecome increasingly powerful. Software platforms allow developers to create appli-cations for such devices.

■ With satellite navigation systems (first and foremost with GPS), people can deter-mine their locations worldwide with high accuracy. As a result of continuous minia-turization and price reduction, over 20 million people used GPS worldwide in 2003[45]. GPS receiver hardware is built into several mobile devices such as PDAs ormobile phones. Europe will set up a highly accurate satellite navigation systemcalled Galileo in the next few years.

■ Geographic information is becoming more and more available as digital data. Dig-ital maps, height profiles, geo-referenced information, digital street maps, etc. areavailable from local land survey offices and industrial sources. So, location-basedservices can rely on a huge set of digitally available geo data.

These technologies simplify the development of location-based services, but research-ers and industries still have to face certain problems. While developers can use well-established mechanisms to retrieve location-based information, positioning is still an

Introduction 1

issue. No currently available positioning system fulfils all requirements of conceivableservices. The following problems can be identified:

■ Many systems have a limited coverage. E.g., GPS does not work indoors and oftenfails in city centres. Indoor positioning systems only cover some rooms or buildings.Systems with a higher coverage (e.g. systems based on mobile phone cells) are ofteninaccurate.

■ The way to access the positioning hardware (e.g. via a capturing protocol) is signifi-cantly different between the positioning systems. In addition, the positioning sys-tems produce different location output regarding coordinate systems and dataformats.

■ Often, location based services need symbolic location information that carriessemantics about the location, but most positioning systems only provide physicallocations.

As a result, services suffer from inadequate coverage and accuracy. Services have todeal with protocols to capture locations and have to process raw location data. More-over, the integration of positioning systems is often ’hard-wired’, i.e. the access to therespective positioning system is fixed without the possibility of an easy replacement ata later stage. The capability to deal with multiple positioning systems is only rarelyincorporated into current location-based services.

Symbolic Location Information

The role of symbolic location information is discussed with the help of an example.

Fig. 1-1 presents a location-based bus planner. The user simply selects the destination(fig. 1-1, left) and the application computes the appropriate time table for the selecteddestination, while taking into account the current time and location (fig. 1-1, middle).

Fig. 1-1. The Nimbus bus planner

2 Jörg Roth

After boarding the bus, the planner supervises the current location and informs the userwhen to exit (fig. 1-1, right).

This application is not primarily interested in the physical coordinates of the user’scurrent location, but wants to know at which bus station the user is waiting. In this con-text, locations such as "Bus Station at the Central Railway Station" are called symbolicor semantic locations. As many positioning systems produce physical location infor-mation, the application or service has to perform a mapping of physical coordinates tothe respective semantic location (in the example to the bus station) internally. Thisapproach has two drawbacks:

■ This mapping is separately integrated into multiple applications, which causes anundesired code overhead.

■ This mapping requires geo data that the service provider has to collect and to admin-istrate. This can be an expensive task.

The Nimbus Framework

As a solution, the Nimbus framework was designed and realized to encapsulate allfunctions related to positioning and mapping to semantic locations. The framework hasthe following characteristics:

■ Positioning systems are completely separated from the location-based service. Theservice developer does not have to deal with the capturing protocol to get locationinformation from a positioning system. Services can be developed independently ofthe used positioning systems. New positioning systems can be integrated after deliv-ering the end-user’s applications.

■ The framework provides location information in a globally uniform format. If dif-ferent positioning systems are connected, the framework automatically makes aselection. In particular, it provides a handover from one local positioning system toanother at runtime.

■ Apart from physical locations, the framework provides semantic location informa-tion according to a predefined name space. Applications do not have to deal with thecorresponding mapping.

■ The mapping between physical and semantic location information is provided by adecentralized federation of location servers. Local information is entered andadministered at a local server.

■ The infrastructure is highly scalable, since a location server only has to host localmobile users. An advanced caching concept additionally reduces the overall load.

■ As the correctness of mapping is important for certain applications, the authenticityof semantic location information can be verified with the help of security mecha-nisms.

■ Several location-related functions (e.g. trigger services and semantic geocast) sim-plify the development of location-based services.

To demonstrate the strength of Nimbus, a huge amount of semantic location data areimported from land survey office sources. Performance analyses at the end of this the-sis demonstrate the scalability and efficiency of the overall approach.

About this Thesis

This thesis presents my research results of the last four years at the University ofHagen. The thesis contains three parts: part I describes general issues concerning con-

Introduction 3

text, location-based services and positioning, part II describes the Nimbus frameworkand part III finally presents the analyses, future work and conclusion.

It is a difficult task to describe a framework like Nimbus, as many facets have to beconsidered. To have a clear idea of Nimbus, all the components have to be describedin-depth. Even though the chapters separately present a specific aspect of the Nimbusframework, the components are strongly interrelated. The presentation of related workand state of the art is also difficult, as the respective systems have to be examined fromdifferent points of view. Therefore, each chapter presents its individual related worksection discussing approaches related to the respective chapter.

4 Jörg Roth

2 Context and Location-Awareness

In the fields of pervasive, ubiquitous and mobile computing, context is an impor-tant concept, which describes entities that define the user’s current situation.Whereas context frameworks consider location as an abstract variable to describea situation, current location-based services deal with location in a more pragmaticmanner. This chapter briefly describes the concept of context and then focuses onlocation-based services.

2.1 The Notion of Context and Situation

The ability to react to the user’s current location and location changes is called loca-tion-awareness. Often, the more general terms context awareness and situation aware-ness are used. Schilit and Theimer provided an early definition of context awareness[151]:

Location information is necessary for users and applications that wantto query and interact with nearby devices and services. Such informationalso allows stationary clients to track moving objects. In general, locationinformation enables software to adapt according to its location of use, thecollection of nearby people and objects, as well as the changes of thoseobjects over time. We use the term context-aware computing to describesoftware exhibiting these general capabilities.

A more concise definition was published by Dey and Abowd [36]:

Context is any information that can be used to characterize the situationof an entity. An entity is a person, place, or object that is considered rele-vant to the interaction between a user and an application, including theuser and the applications themselves.

Both definitions include that data from the environment influence the application’sexecution. Different contexts can be classified as follows [40]:

■ The infrastructure context is closely related to the communication infrastructure.The user perceives this context as network bandwidth, delay or reliability of com-munication links.

■ A mobile application often can be decomposed into a system of distributed compo-nents. The system context describes issues which are a result of the distributed archi-tecture, e.g. the possible interactions between user and application.

■ The domain context describes the relation of users and devices as a result of specialusage scenarios (e.g., in a mobile environments).

■ Mobile users and devices reside in the physical world. The physical contextdescribes the conditions of usage as a result of the specific physical settings. E.g.,using a fixed installed device in a car is completely different from the usage of amobile phone.

Context and Location-Awareness 5

Situations

Whereas the context is viewed as a set of variables describing the user’s state and envi-ronment (e.g. temperature, location, time, the user’s hart beat rate), a situationdescribes a certain setting of these variables with a concrete meaning [30, 35, 41, 54].A context may describe a specific location-time tuple and the corresponding situationcould be "Presenting the Nimbus Paper at the ICETE Conference in Setúbal". Situa-tions can be derived from contextual variables with the help of two mechanisms:

■ Values of a specific context variable can be categorized to a single class with a cer-tain meaning. E.g., in the time dimension a certain time between 1:00 and 2:00 pmcan describe the situation "meeting" for a specific person. All locations inside a spe-cific rectangle can be described as "my office".

■ From all available variables, only a subset is used that is relevant for a specific situ-ation. E.g. inside a meeting, the variable "speed of the user’s car" is not of interest.

Context and situations are investigated with the help of some research toolkits andframeworks. Toolkits such as the context toolkit [149] and contextors [28] model con-textual variables with the help of components (called context widgets in the contexttoolkit). The CoCo framework [19] provides an infrastructure of components support-ing the process of context retrieval and context composition and comes along with agraph-oriented language describing the steps needed to compose context informationfrom sensor output.

These context toolkits describe the interfaces of the required components, their rela-tions and composition to higher-level systems. Other systems implicitly define situa-tions in an application-specific manner. Context-aware messaging systems performtrigger actions according to a specific situation [150]. ComMotion [97] is a systemwhich links personal information to locations and generates events (e.g. sound or mes-sage boxes), when a user moves to a certain location. CybreMinder [37] allows the userto define complex conditions under which a reminder will be generated (e.g. time is"9:00" and location is "office"). Conditions are stored in a database and are linked tousers. Whenever a condition is fulfilled, the system generates a message box.

Context still leads to open research issues. In mobile environments, the first prob-lem is related to sensors for measuring the context variables: as the context theoriesespecially want to integrate mobile users, sensor information has to be available at allpotential locations. It is not clear, if a huge set of expressive sensor information will bewidely available in future environments. To automatically categorize context informa-tion and to derive situations, either a huge set of rules or knowledge of the real world isrequired. In addition, deduction mechanisms similar to those used in artificial intelli-gence scenarios are necessary.

2.2 Location-Awareness and Location-Based Services

Looking at the set of potential context variables, many existing platforms concentrateon location and time as these variables usually are the most important inputs todescribe a specific situation [40]. In addition, there exist techniques and sensors to cap-ture these variables effectively by applications. Nearly all currently available comput-ers know the current time. With the declaration of the Full Operation Capability of theGlobal Positioning System (GPS) in 1995, researches also assume the ability of amobile device to detect their locations (even though GPS is not always available, e.g.indoors).

6 Jörg Roth

The ability to react to locations, the location-awareness, can be considered as a spe-cial form of context-awareness. Corresponding services are called location-based serv-ices (LBS). Even though the term services is traditionally used for networked services,the term is also used to describe applications that work offline such as car navigationsystems. For such applications, the more general term location-based or location-aware applications can be used. Table 2-1 shows some quotations explaining the termlocation-based service and application.

Location-Based Mobile Phone Services

In addition to GPS, several technologies promoted the development of location-basedservices in the last years. One of the most important milestones was the introduction ofdigital mobile phone networks. In Europe the Global System for Mobile communica-tion (GSM) started in the 1990s, which is meanwhile used in more than 190 countriesin the world. The mobile phone was the first mobile and widely available computingplatform. Cellular phone infrastructures are often viewed as the most promising plat-forms for location-based services – very often, people mean by location-based servicesonly location-based mobile phone services.

Table 2-1. Some definitions of location-based services and applications

Network-based services that integrate a derived estimate of a mobile device’s location orposition with other information so as to provide added value to the user. [120]

Location based services are business and consumer services that give users a set of serv-ices starting from the geographic location of the client. These services offer the possibilityto users or machines to find/locate other persons, machines, vehicles, resources and alsolocation-sensitive services, as well as the possibility for users to track their own loca-tion.[...] Most location based services will include two major actions: 1. Obtaining thelocation of a user 2. Utilising this information to provide a service. [57]

The term location-based services (LBS) is a recent concept that denotes applications inte-grating geographic location (i.e., spatial coordinates) with the notion of service. Examplesof such applications include emergency services, car navigation systems, tourist tour plan-ning, or "yellow maps" (combining of yellow pages and maps) information delivery. [153]

Location-based services will allow mobile users to receive personalized and lifestyle-ori-ented services relative to their geographic location. [118]

Business and consumer 3G [Third Generation] services that enable users or machines tofind other people, vehicles, resources, services or machines. They also enable others to findusers, as well as enabling users to identify their own location via terminal or vehicleidentification. [166]

There are two categories of mobile location-based services and applications: location-aware and location-enabled. The principle behind mobile location services is simple:Location-based services use the geographical location of an individual on the move toprovide personalized information, transactions, or interactions. This kind of location-aware dynamic content provides the foundation for a variety of wireless services:navigation, traffic, concierge, and emergency services, "friend finder," and mobilecommerce applications. Mobile location-based services (MLS) also offer significantpotential for businesses and government organizations seeking to increase efficiencies andcut costs by tracking their mobile personnel and assets more effectively. Location-enabledapplications add the important aspect of the device's location on top of existingapplications. [...] Consumer examples include instant messaging, chatting, matchmaking,and so on. Enterprise examples are sales force automation and customer relationshipmanagement. [163]


Although widely available, mobile phones currently have some serious disadvan-tages:

■ Very often, they do not contain any positioning hardware.

■ They offer only very limited computational power.

■ Standardized development platforms are not widely available.

As there is no positioning system available, the mobile phone network roughly deter-mines the user’s location with the help of the communication cells (see section 3.4.1 onpage 28). As standards for data communication, first the instant messaging serviceSMS (Short Message Service), later WAP (Wireless Application Protocol) and i-modewere available. Mobile phone providers offered several location-based services so far –often with only moderate success.

Fig. 2-1 shows two existing location-based phone services in Germany. The upperscreens show the so-called friend zone – an SMS-based service to locate other mobilephone users. Every interaction requires to send an SMS which has to be coded accord-ing to a simple textual protocol. Users can ask the mobile phone network to find out thelocation of friends; each friend has to give explicitly the permission to be tracked byother users. As a second service, a user can broadcast an SMS to all friends in thenearer area.

As WAP becomes more and more available, more convenient services are possible.Fig. 2-1 (bottom) shows the Nightguide service which allows to look up hotels, cashdispensers, cinemas, restaurants etc. For this, the service provider administrates a data-base of the corresponding so-called points of interest.

Fig. 2-1. Location-based mobile phone services in Germany

8 Jörg Roth

Some of the problems of mobile phones mentioned above are more and more elimi-nated:

■ Manufacturers start to equip mobile phones with GPS receivers to determine themobile user’s location with high accuracy.

■ Mobile phones become more and more capable to run powerful applications. So-called smart phones have the computational power of PDAs, which now have thecapability of desktop computers delivered three years ago.

■ Platforms for developing software on mobile phones become available. Early ver-sions of the Java Micro Edition [165] were mainly used to run games, but newerversions provide a reasonable functionality for networked mobile phone applica-tions. For smart phones, platforms such as Symbian [63] or PalmOS [129] allow thedevelopment of applications in C/C++.

With the introduction of UMTS, experts expect a huge market potential of location-based services in mobile phone networks in the future [167].

Classification of Location-Based Services

In the last years, such services have also been created for other platforms than mobilephones. Fig. 2-2 shows some examples: a fleet management application and navigationapplications (outdoor and indoor).

Even though location-based services are available for years, a widely accepted classifi-cation does not exist. Table 2-2 is a compilation of several classifications found in liter-ature [14, 78, 90, 156, 167].

Fig. 2-2. Fleet management and navigation applications

Table 2-2. A classification of location-based services

Category Description Examples

Location-based information services

The mobile user requests information about the location

Local weather forecast, navigation, local maps, local bus schedules

Points of interest The mobile user looks up stationary objects or facilities in the nearer area

Finder services (restaurants, hotels etc.), service lookup (e.g. printers)

Discovering other users

The mobile user looks up other users in the nearer area

Friend finder, flirt finder, games


The following characteristics of location-based services can be distinguished:

■ Business characteristics: For service providers, the underlying business model is ofimportant interest. Location-based services can be distinguished by the classes C2C,C2B, B2B, B2C, C2G and B2W (’B’: business, ’C’: customer, ’G’: government,’W’: workforce) [90]. According to the idea of peer-to-peer networking, a servicecan also be established solely by the users without any service provider.

■ Privacy characteristics: Whenever the location of a user is part of the service, legaland privacy issues have to be considered. Even though the law in many countriesdoes not explicitly declare how to treat a user’s location, it is mostly considered asprivate. For the mobile network it is imperative to know the user’s location, butthird parties should not reveal locations of private users nor should generate move-ment profiles. Some location-based services explicitly transfer location informationfrom one user to another (e.g. assistance services). For such services, security mech-anisms have to be introduced.

■ Technical characteristics: As an important classification, push and pull services canbe distinguished. This classification does not only affect technical aspects of theservice implementation, but also the type of interaction: pull services reply informa-tion on demand, whereas push services deliver information to mobile terminalsbased on an event or trigger condition. Push services require low-level support ofthe underlying network and end-user device. A further distinction considers thestate [78]: a service is stateful if it maintains a state across multiple service requests,otherwise stateless. A final issue is the required accuracy of the underlying position-ing system. Some services require only moderate accuracy whereas other services(especially assistance services) require accurate location information [14, 156].

Table 2-3 summarizes the characteristics of the respective location-based service cate-gories.

Tracking services A (potential stationary) user looks up the location of a mobile object or person

Fleet management, tracking children, tracking assets

Assistance services A service centre receives the location of a mobile caller who needs assistance

Emergency calls, breakdown services

Messaging and announcement services

Mobile users receive a message from another user broadcasted to a certain area

Local advertisements, messages to nearby friends

Trigger services A mobile user receives a trigger when entering a certain location

Location-based reminders, traffic warnings, weather warnings

Location-based billing A user is charged according to his or her location.

Toll billing, home zones

Table 2-2. A classification of location-based services (continued)

Category Description Examples

10 Jörg Roth

2.3 Summary

This chapter takes a look at location-awareness from two perspectives: the notion ofcontext-awareness considers different sensor information to define a situation. Therespective frameworks deal with location in an abstract manner. Location-based serv-ices on the other hand consider location as the major input to define a situation and dealwith concrete issues related to positioning.

Table 2-3. Location-based service characteristics according to [14, 78, 90, 156]

CategoryBusiness

model Pull vs. push

Location accessible by third party State

Required accuracy

Location-based information services

C2B Pull No Stateless <1 km

Points of interest

C2B Pull No Stateless <1 km

Discovering other users

C2C Pull Yes Stateful <200 m

Tracking services

C2C, B2B, B2W

Tracking entity pulls

Yes Stateful <200 m

Assistance services

C2G, C2B Push Yes Stateless <20 m

Messaging and announcement services

C2C, B2C Push No Stateless <1 km

Trigger services C2C, C2B, B2C

Push Both possible Stateful < 500 m

Location-based billing

B2C, B2B Push toward billing infrastr.

Both possible Stateless < 500 m


12 Jörg Roth

3 Positioning Systems

The Nimbus framework provides location data that can be conveniently processedby location-based services and applications and are independent of the used posi-tioning mechanisms. Nevertheless, the design has to consider basic positioningtechniques and positioning systems which actually perform the location capturing.This chapter presents the mechanisms to capture the mobile user’s current loca-tion. After introducing the basic mechanisms and techniques, some positioningsystems are discussed in detail.

3.1 Introduction

Positioning and navigation have a long history. As long as people move across theearth's surface, they want to determine their current location. Especially seafarers needprecise location information for long journeys. In the past, they used stars and light-houses to find out their position, now they rely on electronic systems, especially satel-lite navigation systems.

Several positioning systems have specific advantages and disadvantages, but cur-rently, no single positioning system fulfils all of the needs of any location-based serv-ice. Satellite-based positioning systems such as GPS achieve high coverage andaccuracy, but they fail in indoor environments. Indoor positioning systems on the otherhand require cost-intensive installations and are restricted to buildings or even somerooms inside a building.

Positioning is an important function for many areas, such as land surveying, avia-tion, aeronautic, robotic, or virtual and augmented reality. In this chapter, we limit thelarge area of positioning to systems and techniques that are appropriate for location-based services. Positioning systems that use space-consuming equipment (e.g., insideplanes) or that are restricted to small spaces (e.g., in virtual reality environments) arenot discussed.

3.1.1 Properties of Location Data

Different positioning systems provide location data with different characteristics. Apositioning system has to meet the specific requirements of the location-based service.The following properties of location data can be identified:

■ Coordinate system: Coordinate systems that describe a three-dimensional world-wide unique location can be divided into two classes: Latitude, Longitude, and Alti-tude systems (LLA) use two angles and a height to specify a location in threedimensions (fig. 3-1a); Earth Centred, Earth Fixed (ECEF) systems use Cartesiancoordinates with the zero point in the earth's centre of gravity (fig. 3-1b). Models ofthe earth's surface, usually an ellipsoid, serve as reference frames for coordinate sys-tems. A popular model, WGS 84 (World Geodetic Survey 1984) [47] forms the basisfor the GPS computations. Many coordinate systems make two-dimensional mappings of the three-dimen-sional earth’s surface using cylindrical or spherical projections. For the German landsurvey, the plane coordinate system Gauß-Krüger is used, which projects an orthog-onal meter grid onto the ellipsoidal earth’s surface (fig. 3-1c). As this projection

Positioning Systems 13

leads to projection errors, Gauß-Krüger coordinates have discontinuities every 3degrees of longitude. Inside the continuous regions, computation of distances andareas is simple. The plane coordination system UTM (Universal Transversal Merca-tor) has similar characteristics, but has discontinuities every 6 degrees of longitude.

■ Scope: A positioning system has a certain scope and defines an area of potentialcoordinates. A location can be worldwide unique or only valid in a small area (e.g. abuilding). Indoor positioning systems often provide local locations, relative to, e.g.,a certain corner of the building.

■ Coverage: The coverage describes the area in which positioning is possible. Theactual coverage of a location system may be smaller than the area of potential loca-tions specified by the scope. E.g., the scope of an indoor positioning system may bean entire building, however some rooms are not equipped and therefore outside thecoverage.

■ Accuracy: Capturing a location, a positioning system produces certain measurementerrors. This inaccuracy sometimes is not a result of the used mechanism, butdepends on environmental conditions (e.g., temperature, atmospheric conditions).Therefore, a certain position measuring can lead to different values at the sameplace depending on the time of the day. Users and services that access location datamust be aware of inaccuracy.In addition to accuracy, there is the term precision to describe deviations of locationmeasurements. Accuracy describes the deviation of measured locations to the truelocation, whereas precision describes the deviation of multiple measurementsamong each other. In literature, these terms often are not used uniformly.

■ Type: physical vs. semantic locations: Users or location-based services are ofteninterested in the meaning of a location rather than in the geographic coordinates.Semantic locations [125] are a powerful representation for a great amount of loca-

Fig. 3-1. Geographic coordinate systems

14 Jörg Roth

tion-based services. E.g., instead of the coordinates N51°22.579/ E7°29.615/ 169 m,it may be more meaningful to use the term "University of Hagen, building IZ, backdoor". Some positioning systems already provide semantic locations.

■ Additional spatial data: Sometimes, further spatial information is required. For nav-igation or map services, e.g., it is useful to know the user's orientation. The so-calledthree angles roll, pitch, and yaw specify the orientation in space. The yaw angle issufficient to specify the direction on the horizontal plane. Most positioning systemscannot determine the orientation directly, but calculate the moving direction whenthe user is in motion. Electronic compasses are able to roughly determine the yawangle.Further spatial information is speed. If the positioning system cannot determine thespeed directly (e.g. with the help of the Doppler effect), it can use two deferred posi-tion measurements.

3.1.2 Basic Location Techniques

Systems that determine the location of a mobile user can be divided into the two cate-gories tracking and positioning.

We talk about tracking, if a sensor network determines the location. The user has towear a specific tag or badge that allows the sensor network to track the user's position.The location information is first available in the sensor network. If the mobile userneeds his or her location data, the sensor network has to transfer this information to theuser by wireless communication.

If the mobile system determines the location itself, the term positioning is used. Asystem of transmitters or beacons sends out radio, infrared or ultrasound signals. Loca-tion information is directly available at the mobile system and does not have to betransferred wirelessly. In addition, location information is not readable for other users,thus the positioning system does not have to consider privacy issues.

Systems using tracking as well as positioning are based on the following basic tech-niques, often used in combination:

■ Cell of Origin (COO): This technique is used, if the positioning system has a cellu-lar structure. Wireless transmitting technologies have a restricted range, i.e., a radi-ated signal is available only in a certain area, the cell. If the cell has a certainidentification, it can be used to determine a location.

■ Time of Arrival (TOA), Time Difference of arrival (TDOA): Electromagnetic signalsmove with light speed. As this speed is very high (approx. 300 000 km/s), the corre-sponding runtimes are very short. If we assume a nearly constant light speed, we canuse the time difference between sending and receiving a signal to compute the spa-tial distance of transmitter and receiver. A similar principle can be used with ultra-sound. The signals take a longer time, thus measurement is simpler, but ultrasoundcan only cover small areas.The term TDOA is used for measuring the time difference between two received sig-nals. In GSM networks, the term Enhanced Observed Time Difference (E-OTD) isoften used instead of TDOA.

■ Angle of Arrival (AOA): Using antennae with direction characteristics, receivers canfind out from which direction a certain signal arrives. Given two or more fixed posi-tions and directions from the fixed positions to the same object, a positioning sys-


tem can compute the location of this object. Since it is too difficult to turn anantenna constantly for measuring, receivers use a set of antennae that are lined upwith a certain angle difference in all directions.

■ Measuring the signal strength: The intensity of electromagnetic signals decreaseseven in vacuum with the square of the distance from their source. Given a specificsignal strength, receivers can compute the distance to the sender. Unfortunately,obstacles such as walls or trees additionally reduce the signal strength, so thismethod is inaccurate.

■ Processing video data: Using video cameras, positioning systems can look for sig-nificant patterns in a video data stream to determine the user's location. If users wearbadges with conspicuous labels, they can be detected in video images. For this, posi-tioning systems use techniques of image processing to detect and interpret imagedata. In principle, video positioning systems are based on the angle of arrival tech-nique: a specific pixel in an image represents a certain angle relatively to the cam-era's optical axis. However, video data can transport colour information which canbe used to transfer additional information, e.g., the user’s identification.

In the following sections, a number of systems and techniques are presented in detailaccording to the three classes: satellite positioning systems, indoor positioning systemsand systems which use an existing network infrastructure.

3.2 Satellite Positioning Systems

The idea of satellite positioning systems goes back to the 1960s. Using satellites forpositioning has important advantages:

■ Positioning can in principle be carried out everywhere on the earth.

■ Environmental conditions, such as the weather, have only minimal influence on thepositioning process.

■ A high accuracy is obtained.

Among other things, these advantages make satellite navigation interesting for use bythe armed forces, but a variety of applications is also conceivable for civilian purposes.

The satellite navigation also has some disadvantages:

■ Considerable costs arise for launching and supervising the satellites.

■ Positioning only works, if the user receives a sufficient number of satellites. Particu-larly, positioning inside buildings is not possible.

The most prominent example of a satellite navigation system is GPS (Global Position-ing System). Before describing GPS, the basic mechanisms of satellite navigation arepresented.

3.2.1 Basic Principles

A user who wants to determine a position with the help of satellites needs the exactpositions of the satellites (si) as well as the exact distances to the satellites (ri). Fig. 3-2shows this principle.

16 Jörg Roth

If the user determined the values si and ri, his or her position is restricted to the spheri-cal surfaces around each satellite. At least three satellites are required to determine theuser's location u in three dimensions (fig. 3-2a).

Taken exactly the cut of three spherical surfaces normally leads to two intersectionpoints (fig. 3-2b). The second intersection point lies far in the space, therefore can sim-ply be filtered out for a user within the earth's atmosphere.

Satellites move on fixed orbits. A so-called almanac contains a list of all workingsatellites and their orbits. The almanac is frequently downloaded to the mobile user'sreceiver. It is also updated when satellites are shut down or new satellites start theirwork in new orbits. Note that the accuracy of the values si directly influences the accu-racy of the location u.

To compute the distances ri, every satellite sends a signal which exactly specifiesthe current satellite time. A receiver compares this time with its internal clock. The dis-tance r can be determined from the time difference with the formula (here, c denotes the speed of light, approx. 300 000 km/s).

The time measurement is the critical point at this procedure. As the light velocity isvery high, the time measurement must be carried out exactly. An error of only 1 µs forexample leads to a difference of 300 m in the position calculation. Every satellite istherefore equipped with an atomic clock, which allows an exact time measurement.The exact time of the entire navigation system is called the system time.

A mobile device cannot be equipped with an atomic clock because of the high costand space requirements. Without synchronized clocks, it is not possible to achieve thenecessary accuracy. Unfortunately, synchronization directly with the clocks of the sat-ellites is not possible, as the time information can 'only' be transmitted with the speedof light. As a solution of this dilemma, a fourth satellite is included for position calcu-lation. A user builds a set of equations which put the following variables into relation:

■ the current positions of the satellites,

■ the measured distance from the user to the satellites, which may be different fromthe real distances, therefore called the pseudo ranges,

■ the timing offset of the user’s receiver compared to the system time and

■ the user’s current location.

The satellite positions are known from the almanac, the pseudo ranges are measured.The unknown variables are the timing offset and the user’s location in three dimen-sions. A user needs four equations and thus four satellite signals to determine these val-

Fig. 3-2. Principle of satellite positioning

t∆ r c t∆⋅=


ues. Unfortunately, the resulting system of equations is non-linear. To solve it,receivers can use algebraic solutions [7], solutions with Kalman filters [82] or iterativesolutions with Taylor series.

The signals of the satellites are often interfered. With the help of more than four sat-ellites, the resulting error can be minimized. This mathematically results, however, in asystem of equations that is not longer solvable, but with the help of least square meth-ods receivers can compute an appropriate position. Generally, the more satellite signalsare taken into account, the more precise is the resulting position.

3.2.2 GPS

Different American organizations, especially the armed forces (Department ofDefense, DoD), the Ministry of Transport (Department of Transportation, Dot) and theNASA, were interested in a satellite-based positioning system until the early 1960s.When older navigation systems did not meet the requirements any more, the U.S. Min-istry of Defense conceived in 1970 a system with the name NAVSTAR GPS (NavigationSystem with Timing and Ranging - Global Positioning System), in the following calledGPS. In 1974, they started with the system tests. In 1984, first GPS satellites werelaunched. Until 1990, 12 satellites were working. A first operational status (initialoperation capability, IOC) was achieved with 21 system satellites and 3 reserve satel-lites on Dec. 8, 1993. The full operation capability (FOC) was declared on July 17,1995.

In order to achieve a global coverage from equator up to the poles, 24 satellitesmove on six different orbits with four satellites per orbit (fig. 3-3). Every satelliteorbits the earth in the distance of approx. 20 200 km. A satellite needs 12 hours for acirculation. The satellites move in a way that at least five and at most 11 satellites are inprinciple visible over the horizon from every point on the earth's surface. The numberof satellites which can actually be received can be lower because of shadings by e.g.buildings or landscape formations. As represented in the last section, four satellites arenecessary for a positioning in three dimensions.

A satellite has an expected lifetime of 7.5 years. To be operable after satellite failures,more than 24 satellites are in the orbit. The number was sometimes increased up to 28.Currently, the operator needs 60 days to launch a new satellite into the orbit after the

Fig. 3-3. GPS satellite orbits

18 Jörg Roth

failure of a satellite. It is planned for reasons of cost to shorten the time to 10 days.With this, the number of satellites could be reduced to 25.

A user who wants to determine a position with the help of GPS does not have to reg-ister, but can use the GPS signals free of charge. The mechanism is based on the one-way communication of the satellites to the user. Two GPS services exist:

■ Precise Positioning Service (PPS): This service allows positioning with an accuracyof 22 m in the horizontal and 27.7 m in the vertical. Over a period of 24 hours, 95%of the measuring is within the given accuracy. PPS (formerly called P-Code or Pre-cision Code) is encrypted and can only be decoded by the forces of the USA and theNATO. For civilian users this service is not accessible.

■ Standard Positioning Service (SPS): This service (formerly called C/A-Code orCoarse/Acquisition Code) is available for civilian users. Until April 30, 2000, it hadan accuracy of 100 m in the horizontal and 156 m in the vertical.

The satellites send out a continuous signal with approx. 20 W. They use two frequen-cies: L1 (1575.42 MHz) for PPS and SPS, and L2 (1227.6 MHz) exclusively for PPS.

As all satellites send signals at the same frequencies, a receiver must have the abilityto assign the signals to the respective satellites. GPS uses CDMA (Code Division Mul-tiple Access) for this purpose: every satellite sends out a unique code called the PseudoRandom Noise (PRN). The receiver knows all of the codes and can filter out the corre-sponding sequence from the superimposed signals of all satellites. The PRNs do notdisturb themselves mutually. With the help of the satellite signal, the receiver canmeasure the time difference of the involved clocks and compute the pseudo range. As asecond function, the signal transfers data with a data rate of 50 bits/s. These data con-tain the position of the satellite, the system time and the orbits of other satellites.

GPS Accuracy

Distorting effects such as clock errors, fluctuations of the orbits, disturbances of theatmosphere and ionosphere and multipath error influence the accuracy of GPS. In addi-tion to these effects, the SPS signal was artificially distorted until the year 2000 to pre-vent a more exact measuring. This mechanism, called Selective Availability (SA),randomly dithered the time sent by the satellites. In addition, the orbit information wasdistorted. So, an exact positioning was not possible. The background of SA was thatthe U.S. army did not want to enable a too exact positioning for other forces. SA wasswitched off on May 1, 2000 [34]. Reasons for that were economic considerations.

Even though SA is switched off, the measured position usually is not identicallywith the "true" position, measured by land surveying. Fig. 3-4 shows the results of anexperiment carried out in front of the author’s office, where at a certain fixed position areceiver performs more than 7000 GPS measurements over three days. The x- and y-axes are scaled according the Gauß-Krüger coordinates called easting and northingcorresponding to meter values. The z-axis shows the amount of GPS measurementswhich are inside a certain square of 1 m x 1 m.

Not surprisingly, many measured positions are close to the real position, but therewas one measurement with an error of 277 m. The model to describe GPS accuracy isbased on the assumption of normal distributed measurement errors. In addition, aneffect called GDOP (Geometric Dilution of Precision) [84] describes the influence ofthe constellation of satellites on accuracy.


The actual distribution as presented in the figure is often not meaningful for end-users.A number of characteristic values that describe the accuracy of GPS provide a morecompact representation [172]:

■ CEP (Circular Error Probability) is the radius of a circle around a true positionwhich contains 50% of the measured positions

■ 2dRMS (2 Distance Root Mean Square Error) defines a circle, where 95% of themeasured positions reside.

Fig. 3-4. Measurement of a fixed position by GPS over three days

Fig. 3-5. Characteristics of GPS measurements

20 Jörg Roth

Fig. 3-5 is based on the experiment mentioned above and shows the number of meas-urements which are inside a certain circle around the true position. The greater wechoose the circle, the more measured positions are included. The experiment result val-ues are CEP = 9.7 m (50%) and 2dRMS = 32.3 m (95%). Long-term statistics lead tomore precise statements about the accuracy. SPS without SA provides an accuracy of25 m in the horizontal and 43 m in the vertical (95%). Table 3-1 summarizes the accu-racies of the different GPS services.

It is planned to improve the accuracy of SPS, especially to correct ionospheric distor-tion. The new services will be deployed with satellite launches scheduled until 2012,and with full operational capability expected in 2014.

3.2.3 DGPS and WAAS

Often, the accuracy of GPS is not sufficient. With Differential GPS (DGPS), the accu-racy can be improved significantly with the help of base stations on the earth's surface.These reference or base receivers have a fixed, precisely known position.

The base receiver measures the pseudo range to every receivable satellite and sub-tracts the exact distance (known, since the satellite positions and the base station’sposition are known). The base station broadcasts a correction message for every satel-lite to the user. A user who determined his own pseudo range subtracts the correctionvalue and gets a corrected pseudo range. Since the errors at the location of the basereceiver and the mobile user arise from the measuring with the same satellites, theyalmost compensate (if both are not too far away from each other).

The format for correction data of the base receivers is standardized under the nameRTCM 104. DGPS has an accuracy of approx. 1-3 m (95%). The distance between userand base receivers has an important influence to the accuracy.

The Wide Area Augmentation System (WAAS) also uses base receivers to computecorrection values. Unlike DGPS, the transmitting is not executed with the help of ter-restrial transmitters, but with the help of geostationary satellites. In the area of USA,approx. 30 base receivers currently operate. The correction values are passed to a mas-ter control station that then forwards them to an Inmarsat-3 satellite. This satellitesends the correction data to the users. Since the satellite is on a geostationary orbit(unlike the GPS satellites), correction data are always transmitted to the same geo-graphical area. This is intended since the correction data consist of the base receivers ofthe covered area. For transmitting the correction data to the users, the Inmarsat-3 satel-lite sends at the L1 frequency and uses a free PRN code.

3.2.4 Other Satellite Systems

Other satellite navigation systems are GLONASS and GALILEO:

Table 3-1. Accuracy of GPS services (2dRMS)

Service Horizontal accuracy Vertical accuracy

PPS 22 m 27.7 m

SPS with SA 100 m 156 m

SPS without SA 25 m 43 m


■ The Russian counterpart to GPS is GLONASS (Globalnaya Navigationnaya Sput-nikovaya Sistema). Its service started 1996. Like GPS, it uses two frequencies whereone is reserved for the armed forces. GLONASS does not use encryption of the pre-cise service or mechanisms such as Selective Availability. A civilian user achievesan accuracy of 26 m in the horizontal and 45 m in the vertical.GLONASS had the same availability with 24 satellites as GPS at the start time, butmore and more satellites failed because of the shorter lifetime of the GLONASS sat-ellites (3-4 years). Moreover, GLONASS had financing problems. In the year 2000,only 10 satellites were active, so the global coverage could not be achieved anymore.

■ In Europe plans for a new satellite navigation system exist. In a first step, a systemsuch as the American WAAS is planned, which provides satellite-based correctiondata to GPS and GLONASS. It is called EGNOS (European Geostationary Naviga-tion Overlay System) and started its service in the year 2004.The second step of a European navigation system is an autonomous system likeGPS or GLONASS. In 1999, the EU ministerial committee decided to set up thissystem with the name GALILEO [48]. In 2006, the first of 30 satellites will belaunched; the full operability is planned for 2008. GALILEO will offer three serv-ices: a free service, a service, which only can be used by governmental organiza-tions, and a further encoded service, for which users will be charged.Galileo will offer a number of services with different accuracies, where the moreaccurate services Commercial Service (CS) and Public Regulated Service (PRS) willnot be open to the public. The Open Service (OS) will provide an accuracy of 4-15 m horizontally.

3.3 Indoor Positioning Systems

Satellite navigation provides comfortable, precise, and, from the end-user's point ofview, economical positioning. Unfortunately, these systems can only be used outside ofbuildings as the used radio signals cannot penetrate solid walls. For positioning inbuildings, additional installations, e.g. sensor networks, are required. Depending on themechanisms and techniques, considerable costs arise for the stationary and mobiledevices.

Currently, many systems were developed as research projects. Only in rare casesindoor positioning systems reached a product state. The following sections presentsome indoor positioning system examples, classified by the measuring technique basedon infrared, radio, ultrasound and video.

3.3.1 Infrared Beacons

A class of indoor positioning systems uses infrared beacons. As infrared devices arehighly available and cheap, they are used in many projects.

Active Badge

A very early project based on infrared beacons, called the Active Badge system [178],was developed by Olivetti (fig. 3-6).

22 Jörg Roth

Every user visibly carries a small infrared transmitter, the Active Badge. It has a size ofapprox. 55 mm x 55 mm x 7 mm and weight of 40 g. Every 15 seconds, it sends aninfrared signal of approx. 0.1 s. This signal transports a code that specifies the user'sidentity. Infrared sensors installed inside the building receive the signals and pass theinformation to a computer in the building.

The mechanism is based on the fact that infrared signals normally are limited to asingle room. Inside a room, walls reflect the infrared signal, thus a sensor can evenreceive a signal, if it has no direct sight to the user. The pulse duration of 0.1 s is veryshort compared to the 15 s idle time, which has the following two advantages:

■ An Active Badge can work very long without battery changes. Active Badges workfor approx. one year with a single battery.

■ More Active Badges in the same room only rarely produce colliding infrared lightpulses. By low differences in the period duration of 15 s, it is unlikely that twobadges permanently sent signals at the same time. Note that the system even works,if some of the transmissions are lost because of collisions.

In the first project stage, infrared sensors were connected to the server via a serial 4-wire connection. In a second stage, an Ethernet network is used for communication.

The server collects all sensor information and offers it to other applications. Clientapplications can ask, e.g., which persons are currently inside or outside the building, orin which room a specific person currently resides.

One goal of the first active badges was to have low-cost equipment with a long bat-tery lifetime. As a result, the first Active Badges were not able to receive informationfrom the sensor network. However, the request for two-way communication arose forthe following reasons:

■ A person could easily duplicate a badge that emits the same infrared signal. Thus, anunauthorized person could imitate the signal of another person. In some cases, loca-tion information could be critical, e.g., when location data are used to measure theworking time of employees. A further development, so-called AuthenticatedBadges, use a secret cryptographic key, which is proofed according to the challenge-response-mechanism, which needs two-way-communication.

■ The Active Badge can also be used to display information. For this, two little lightsand a loudspeaker were attached in an extended version of the Active Badges. Theyprovide simple visual and acoustic signals.

To save battery power, a badge waits after its own transmission only for a very shorttime to receive a message. In order to receive messages, further computers becamenecessary. In the latest project stage, the system had the following servers:

Fig. 3-6. Active Badges


■ The Location Server collects the information of the sensors.

■ The Name Server manages a database of all system users with the correspondingbadge addresses.

■ The Message Server coordinates the passing of messages directed to the ActiveBadges.

■ Exchange Servers can combine different systems hierarchically to a larger system.

An objective of the Active Badge system was to keep the mobile devices as simple aspossible. In 1992, the start of the Active Badge project, it was difficult to create smalland computational powerful mobile devices with low energy consumption. As a draw-back, the location data are directly available only at the location server and not at theend-user's device.

WIPS

As a result of the miniaturization of devices in the following years, it was possible toexchange the roles of beacons and sensors. The WIPS project (Wireless Indoor Posi-tioning System) [148] realizes this idea (fig. 3-7) and has the following characteristics:

■ The infrared transmitters are no longer mobile, but form the fixed installation. Theydo not have to be connected to each other.

■ The badges receive the signal of the beacons and pass the corresponding locationinformation to the location server via a Wireless LAN network.

■ The location data are processed by the location server and replied to the mobiledevice (again via Wireless LAN).

The concept of WIPS allows the creation of more complex location-based applications.The mobile devices are connected to the location servers, thus powerful services can beexecuted. The beacons can be built up very simply, as they only need to send out afixed signal periodically, and not require any network connection.

PalmSpot

A combination of the ideas of Active Badge and WIPS is realized by the PalmSpotpositioning system [122]. PalmSpot is a spin-off of the Nimbus project.

PalmSpot uses infrared transceivers off the shelves, which are either built in currentmobile devices or which can be connected via serial ports. Due to the great success ofthe infrared technology IrDA [76, 77], a huge number of mobile devices alreadyinclude infrared transceivers. Often, these transceivers can be accessed on bit level,thus it is possible to run an own link layer protocol for transmitting beacon messagescontaining the position. The role of the mobile device is not strongly defined: themobile device can send out beacon messages which are received by the fixed installed

Fig. 3-7. WIPS

24 Jörg Roth

infrared transceivers. It is also possible to use fixed installed transceivers as senders,whereas the mobile devices receive the beacon messages. In addition, two mobileinfrared devices can detect proximity, if both mobile devices send and receive beaconmessages.

PalmSpot frames are very small (36 bytes) and do not significantly interfere withrunning IrDA connections. As the frames are sent with a low transmission rate of 2400baud, the signal can be received over a greater distance than IrDA transmissions. Usingcommon IrDA hardware, a PalmSpot beacon has a range of approx. 3 m – or evenmore with special infrared hardware. In the frame structure, some payload bytes arereserved for usage by the Nimbus system. In addition, PalmSpot uses the same namespace as the Nimbus location model (see chapter 5).

The design of PalmSpot considered security issues. The goals of the PalmSpot secu-rity functions are

■ to protect the positioning network against unauthorized usage,

■ to protect mobile users against attackers collecting position data and

■ to protect mobile users from misleading beacons sent out by attackers.

The security functions are based on encrypted Secure Beacon Frames. Position infor-mation, payload and time stamp in a beacon frame are encrypted by the symmetric AES(Advanced Encryption Standard, [32]) encryption. Only users who know the passwordcan decrypt secure beacon frames. As the time stamps are part of the encrypted frame,it is not possible for attackers to collect beacon frames and resend them at other loca-tions. If two-way communication is available, further authentication mechanisms basedon the challenge response paradigm are possible.

3.3.2 Radio Beacons

As infrared signals usually flood whole areas such as rooms, they do not allow exactposition measurements. They are useful for positioning systems which provide seman-tic location information. Radio signals, in addition, can penetrate walls. If two or moreradio transmitters are within reach, a physical location can be determined with the helpof their signals. If transmitters are attached in several height levels, a positioning inthree dimensions is possible. Positioning systems can use signal strengths as well asTOA to compute a location. In principle, positioning similar to satellite navigation canbe installed indoor, with several fixed radio beacons instead of satellites.

SpotON

A project that uses signal strengths to determine a location is SpotON [68]. Fig. 3-8shows this principle. As in the Active Badge system, the mobile user sends out a signal.Radio sensors in the building receive the signal and transmit the signal strengths to aserver. The evaluation of these data is more complex than in the infrared case. Theserver has to find a location that matches all measured signal strengths. Therefore, it isassumed that the strength of an electromagnetic signal decreases with the square of thedistance. Unfortunately, the signal strength depends on other factors (e.g. obstacles,disturbances or variations in the transmitting power). As a result, it is not possible toget a precise measurement. SpotON tries to compensate these errors by taking intoaccount many sensor values. The system achieves an accuracy of 3 m.


RFID

RFID (Radio Frequency Identification) transponders are a variant of radio beacons.RFID transponders are small systems with a processor, memory, and antenna, but with-out a power supply. They take the necessary energy for work from the received radiosignals. A signal addressed to a transponder can be an instruction to either load newdata into the memory or reply data from the memory as an answer. The transmitter andthe transponder normally have a maximum distance of one meter. RFID transpondersare frequently used to track objects during the transportation process in a production.The exact three-dimensional positioning is not in the foreground. RFID transponderscan be used to find out, if a certain object has already passed a way point on, e.g. a con-veyer belt.

3.3.3 Ultrasound Systems

Systems based on ultrasound can achieve considerably high accuracy. The time, anultrasound signal needs from transmitter to receiver, is approximately proportional tothe corresponding distance. As the speed of sound (330 m/s) is low compared to radiosignals, it is easier to get an exact measurement without high technical efforts.

Active Bat

The ultrasound positioning system Active Bat [180] obtained an accuracy of 10 cm.Fig. 3-9 shows the principle of Active Bat.

Fig. 3-8. SpotON

Fig. 3-9. Active Bat

26 Jörg Roth

A user carries a device, the so-called Bat, which sends a short ultrasound impulse upona request of the server. The server transmits the send request by radio signal. The serveralways selects a specific Bat for positioning, therefore, ultrasound signals from differ-ent Bats cannot collide. Receivers that are assembled at the ceiling receive the ultra-sound signal. The receivers are attached in a raster of 1.2 m. When they receive asignal, they immediately pass this information to the location server via a wired net-work.

The server has all of the necessary information about the positioning of the corre-sponding user. It can create and solve a system of equations using the runtimes of theultrasound signals. The corresponding calculations are very similar to the calculationsof satellite positioning, i.e., a non-linear system of equations has to be solved (see sec-tion 3.2.1 on page 17). The calculation is simpler, since the radio signals have veryshort runtimes compared to the ultrasound signals. For positioning in three dimensions,the input of at least three sensors is required.

Cricket

The Cricket system [127] switches the roles of transmitter and receiver. Fixed installedbeacons send ultrasound signals received by mobile badges. To measure the transmis-sion time, the beacons send a radio signal at the same time (fig. 3-10). With the Cricketsystem, mobile users can determine their locations without a server. In this project, theexact three-dimensional positioning is not in the foreground. When users enter a room,they get information about available network services, e.g. print services.

3.3.4 Video-Based Systems

Another class of positioning systems is based on the evaluation of video data. Process-ing video is generally computing intensive. With the help of special coloured badges,the evaluation can be simplified significantly. Visual tags [157] have patterns that canbe recognized easily, and have for example red and green squares. The position of thesquares in relation to each other can carry, similar to bar codes, simple informationsuch as the user's identity. As the size of the badges is fixed, the distance to the cameraand the orientation in the room can be roughly detected. Sample visual tags are pre-sented in fig. 3-11a and b.

Detecting a user's location can be done in two ways. First, the building can beequipped with cameras, which look for the visual tags (fig. 3-11c) in their image datastream. If at least two cameras detect the same tag, they can determine the correspond-ing angles under which the tag is visible. As the positions of the cameras are known,they can compute the user's location by triangulation.

Fig. 3-10. Cricket


A second approach is presented in [128]: the mobile user is equipped with a small cam-era, mounted, e.g. on the head. Visual tags are attached on walls inside the building. Inthis case, the visual tags have fixed positions. If the mobile camera detects two or moretags, it can find out its own position.

3.4 Network-Based Positioning

Installing positioning systems is often a significant investment. To reduce the costs,existing wireless networks can be used for positioning services. Particularly cellularnetworks are suitable for this purpose, as the cell identification already transports arough location (COO). Additional mechanisms such as runtime measurement (TOA) orangle measurement (AOA) allow a more exact delimitation of the position.

In the following sections, two systems are introduced exemplarily that use a wire-less network for positioning.

3.4.1 GSM

Cellular phone networks are highly available, cover a large area and reach a highnumber of mobile users. Without any further installations, a simple positioning is pos-sible within the GSM network which knows exactly in which cell which mobile tele-phone is registered. Any participant who enters a specific area is recorded by adecentralized database called the Visitor Location Register (VLR). This information ispassed to the central database, the Home Location Register (HLR) where it is retrieva-ble. Each cell phone operator has its own HLR. With this database, location-basedservices can be offered that use locations with the accuracy of a cell size.

The mobile participant can also access location-related data via the radio signals ofthe base stations. A base station can broadcast such data via so-called Cell BroadcastChannels (CBCH) - a logical data channel in the GSM data stream. A mobile phonehas to listen for specific frames where small pieces of data such as the locations of theemergency phones, hotels, hospitals, gas station etc. can be transferred.

The resolution of the position is too inaccurate for some services. The cell size var-ies from under 1 km in city centres up to 35 km in the countryside. If a mobile userstays in a small cell, the position is relatively exact. The 35 km as a maximum are,however, far too large for most services.

Fig. 3-11. Visual tags according to [128] (a) and [99] (b); principle of video positioning (c)

28 Jörg Roth

As a simple technique to estimate the mobile user’s distance to the base station, thesignal strength of the base station’s signal at the mobile user’s location can be used.Signal strengths to all base stations in range are continuously supervised by mobilephones to decide whether to perform a handover to another base station or not. Thereexist physical models [64, 114] to put distance and signal strength into relation. If thesignal strengths of three base stations are available, a mobile phone can determine thecurrent position.

Mobile Positioning System

Ericsson developed a system called MPS (Mobile Positioning System) [46], whichmakes possible a more exact positioning in large cells. MPS cooperates with standardGSM systems and needs only minimal modifications for installation at the communica-tion infrastructure. The mobile terminals (i.e. the cell phones) do not have to be modi-fied. This point is particularly important, as customers do not accept cost-intensivemodifications of the terminals. The accuracy of MPS can optionally be improved byGPS, but this is not a mandatory prerequisite.

The following applications are conceivable with MPS:

■ The mobile participant can query (much more exactly than with standard GSM) forlocation-dependent data, e.g. the location of the nearest restaurant.

■ Users can supervise the location of other mobile users. A GSM terminal can beinstalled into a vehicle, for example, so an owner can locate a stolen vehicle. Simi-larly, repair or rescue services can be guided to accident locations.

■ It is important for transportation companies to supervise the locations of availablevehicles. So, a cab enterprise can query for the position of all cabs, for example.

■ An application for route planning in vehicles can calculate an optimal route to a tar-get and permanently supervise the route based on the position data.

To compute the positions, MPS uses several mechanisms (fig. 3-12):

■ Cell of Global Identity (CGI) (fig. 3-12a): This mechanism uses the identification ofa cell to roughly determine the position of the mobile participant. This inaccuratemethod is only used, if more precise procedures are not available.

Fig. 3-12. Positioning with GSM networks


■ Segment antennae (fig. 3-12b): Base stations often have antennae, which divide the360 degrees into (usually 2, 3 or 4) segments. Thus, a base station can limit the loca-tion of a mobile user to an angular segment of 180, 120, or 90 degrees.

■ Timing Advance (TA) (fig. 3-12c): Base stations and mobile terminals use certaintime slots for communication. As the timing must be exact, the mechanism takesinto account the signal runtime between terminal and base station. A mobile termi-nal sends a data burst earlier when the distance to the base station increases. Withthis mechanism, a burst always arrives at the base station exactly within a time slot.This information can be used to determine the position within a cell more exactly.The distance to the base station is measured in steps of approx. 555 m. Timingadvance can be combined with segment antennae to increase accuracy (fig. 3-12d).As a disadvantage, the TA value is only available when the mobile phone is cur-rently connected to a base station, (i.e. during a phone call or data transmission).

■ Uplink Time of Arrival (UL-TOA) (fig. 3-12e): An even better positioning is possi-ble, if a mobile participant is within reach of at least four base stations. By measur-ing the signal runtimes from a mobile terminal to the base stations, the position canbe determined with an accuracy of 50-150 m. A similar computation as in the caseof satellite navigation is used.

The location data determined by the different procedures are transmitted to the MPC(Mobile Positioning Centre). All data are processed and stored here. If required, otherusers can access these data e.g., via the Internet.

Position data often have a personal character. Although position monitoring isdesired for certain applications, most mobile participants want to publish their positiondata only reluctantly. At this point, MPS fundamentally differs from GPS, where onlythe user gets access to his or her position data. Especially if position data becomeaccessible over the Internet, a provider must think about access protection, authentica-tion and data encryption. MPS, therefore, allows access to position data only afterauthentication via a password.

3.4.2 Wireless LAN

Inside a building equipped with Wireless LAN access points, a mobile user can findout his or her location by measuring the signal strengths of all access points. The ideawas prototypically realized by Microsoft [6] and very similarly by the Nibble system[169].

Before such a system can be used for positioning, it must be trained. For that pur-pose, a user visits several locations inside the covered area. For every location, the usermakes measurements and stores them in a table using the following method:

■ The user first has to enter the coordinates (x, y) as well as the orientation (d). Exper-iments showed that different orientations lead to different signal strengths. Duringthe training, a user has to execute measurements for a single location looking at dif-ferent directions. The coordinate system may use a specific corner of the building as(0.0) and an orientation of 0° parallel to a specific wall.

■ For each way point and orientation the system measures the signal strengths of allavailable Wireless LAN access points (SSi), which can be identified by their net-work address. Access points can in particular be distinguished from mobile comput-ers using Wireless LAN.

30 Jörg Roth

A table such as table 3-2 is built up during the training phase. If a user now wants toknow his or her location, the system measures the current signal strengths SSi. Then thesystem looks up a set of signal strengths in the list that are most similar to the realmeasurement. To look up an appropriate entry, different algorithms are conceivable.The implementation of Microsoft linearly searches the table and finds the data set withthe lowest Euclidean distance to the current measuring. In an experiment with a cov-ered area of approx. 43 m x 22 m an accuracy of 2-3 m was obtained with 70 waypoints.

If a building is only sparsely equipped with Wireless LAN access points, a useroften receives only one or two signals. This causes frequent jumps of the location out-put, even if the user moves only slightly. Another disadvantage of the procedure is thecostly training phase, which must be executed for every area in which position measur-ing later shall take place. Moreover, the training phase must always be executed againif the environmental conditions change, if, e.g. new access points were installed.

To avoid the training phase, a program could generate signal strength values withthe help of a physical model of the building. The access points, walls, ceilings etc. mustbe entered into a program that carries out a physical simulation of the signal spreading.The program can then go through a grid of test points and write down the simulatedsignal strengths to the table. In experiments, this approach achieved an accuracy ofapprox. 4 m.

3.5 Summary

This chapter presents the basic mechanisms, techniques and systems to capture loca-tion data of mobile users. Table 3-3 provides an overview of the presented systems.

Many location-based services use GPS to determine the current location. GPS receiv-ers are inexpensive and the corresponding location output is accurate, thus GPS iswidely accepted. GPS however has a disadvantage: it only works outdoors since thereceiver must have a direct 'view' to at least four GPS satellites.

Indoor positioning systems are cost-intensive, need extensive installations and havea small coverage. A compromise between accuracy and costs are positioning systemsbased on Wireless LAN.

These issues have serious consequences for location-based services. Currently, nopositioning system is accessible everywhere. If a service wants to have a high cover-age, it has to rely on several positioning systems. Developers of location-based serv-ices currently cannot deal with the positioning system as a black box, but have toconsider the specific system properties such as accuracy or coverage.

Table 3-2. Sample signal strength measurements

x/m y/m d/o SS1/dBm SS2/dBm SS3/dBm SS4/dBm

1.0 3.5 0 20 10 18 25

2.0 3.5 90 25 15 17 25

2.5 3.0 90 15 18 16 16

2.5 1.5 180 6 35 18 20

2.0 2.5 0 12 10 22 14

... ... ... ... ... ... ...


Table 3-3. Comparison of positioning systems

Name Type Scope Class Category Technique Medium Accuracy

GPS Physical Global Satellite Positioning TOA Radio 25 m

DGPS Physical Global Satellite Positioning TOA Radio 3 m

WAAS Physical Global Satellite Positioning TOA Radio 3 m

Galileo Physical Global Satellite Positioning TOA Radio 4-15 m

Active

Badge

Semantic Local Indoor Tracking COO Infrared Cell

WIPS Semantic Local Indoor Positioning COO Infrared Cell

PalmSpot Semantic Local Indoor Both COO Infrared Cell

SpotON Physical Local Indoor Tracking Sig. Strength Radio 3 m

Active Bat Physical Local Indoor Tracking TOA Ultrasound/

Radio

0.1 m

Cricket Both Local Indoor Positioning TOA Ultrasound/

Radio

0.3 m

RFID Semantic Local Indoor Tracking COO Radio Cell

Visual

Tags

Physical Local Indoor Both Video Optical depends on camera resolution

GSM (Sig. Strength)

Physical Global Network Both Sig. Strength Radio some 100 m, de-pends on terrain

GSM (TA) Physical Global Network Both COO, AOA, TOA

Radio cell, distance in 555 m steps

MPS Physical Global Network Both COO, AOA, TOA

Radio 150 m

Nibble Physical Local Network Positioning Sig. Strength Radio 3 m

32 Jörg Roth

Part II: The Nimbus Location Service Framework

4 Nimbus Overview

In this chapter, we learn about the main components of the Nimbus frameworkthat are designed according to a set of design goals. Nimbus contains the threelayers base layer, service layer and application layer. These layers and the respec-tive functions and services are outlined.

4.1 Goals and Objectives

As the main objective, the Nimbus framework has to support developers of location-based services or location-aware applications. The development is simplified with thehelp of general services. With the notion of semantic locations, the frameworks enablesapplications which otherwise were not conceivable or at least very cost-intensive.

Some research frameworks [28, 37, 149] model context and try to identify situationsas described in section 2.1 (page 5). Even though techniques to derive situations fromcontext variables exist, they are difficult to execute in practice. As an example: fromthe viewpoint of a person, it is a completely different situation to be a presenter of atalk or a member of the audience. However, the user’s locations are similar and thetime is the same. We have to consider additional input such as the heartbeat rate (forsome people) or a more exact location information (identifying the lectern) to distin-guish the situations. Besides location and time, context sensors are, however, notwidely available. In addition, to generally detect situations from the huge set of poten-tial sensor input, complex inference methods based on knowledge about the world arerequired.

Therefore, Nimbus chooses another way: the primary goal is not to derive situa-tions, but to provide the most enriched location information available of the positioningequipment including semantic location information.

Once the enriched location information is delivered to the application, the mobileclient can use arbitrary mechanisms to execute the location-based service. Well-estab-lished mechanisms such as databases, component services, web services or simplesocket connections can be used to get further information about the location. The Nim-bus framework does not impose any restriction related to these mechanisms.

Fig. 4-1 shows the data flow in the Nimbus framework. We assume that the posi-tioning systems are either attached to the mobile client or location information pro-vided by a tracking system can be accessed by the mobile client via a wireless network.Most of the systems presented in chapter 3 comply with this requirement.

Nimbus Overview 33

The Nimbus framework has a mobile part installed on the mobile system and a networkpart providing information about the location. The mobile part takes raw positions andrequests the network part to provide an augmentation. As a result, the mobile clientreceives globally unique physical and semantic location information, which now caneasily be processed by the application. As the semantic locations are strings that followa predefined name scheme, semantic location can easily be used for direct queries indatabase tables and lists and can be parts of file names.

Besides the main function of augmenting locations, Nimbus provides several serv-ices strongly related to location-based services such as geocasting services. Mobileapplications can access these services via a well-defined interface.

Goals

The Nimbus framework was designed according to a number of concrete goals derivedfrom the general objectives presented above. These goals can be divided into goalsconcerning positioning, service infrastructure and mobile part:

Goal 1: Provide rich location information:

■ Goal 1a: Positioning should be completely separated from the application.

■ Goal 1b: The framework should provide uniform physical location information in-dependently of the underlying positioning system.

■ Goal 1c: The framework should deal with more than one positioning system andprovide a handover mechanism to access the most appropriate positioning informa-tion.

■ Goal 1d: The framework should provide symbolic names for locations.

Goal 2: Provide a service infrastructure:

■ Goal 2a: The infrastructure should provide a scalable architecture to store locationdata and efficiently run the required algorithms.

■ Goal 2b: The infrastructure should offer services for recurring tasks of location-aware applications.

■ Goal 2c: The infrastructure should protect itself against misleading location dataprovided by attackers.

■ Goal 2d: Location data should be entered, administered and retrieved locally.

Fig. 4-1. Data flow with the Nimbus framework

34 Jörg Roth

Goal 3: Provide a mobile part:

■ Goal 3a: The part of the framework running on mobile devices should respect thelow computational power of (current) mobile hardware platforms.

■ Goal 3b: Weak connections of mobile devices and potentially high communicationcosts should be considered.

■ Goal 3c: Costs to port the mobile part to different mobile devices should be consid-ered.

Goals 1a-d and 2a have a fundamental character and significantly extend the potentialof location-aware applications. They allow a developer to develop new applicationswhich otherwise were impossible or at least too cost-intensive to be realized. Reachingthe goal 2b additionally simplifies the development of such applications as Nimbusoffers services which otherwise had to be coded inside the application. Goal 2c ensuresfundamental security mechanisms, thus users can rely on location data provided by theinfrastructure. According to goal 2d, location data distributed among several serverscan be accessed locally.

Goal 3a and 3b can be viewed as contradictory: either mobile clients can performimportant parts of the computation themselves (conflicts goal 3a) or can leave it to theinfrastructure (i.e. the servers). In the latter case a sufficient communication linkbetween mobile client and servers is needed (conflicts goal 3b). The Nimbus approach,however, provides algorithms which shift computation to the servers and at the sametime, reduces communication to a minimum. Goal 3c finally ensures that the frame-work can be used on a huge variety of mobile devices.

A useful mechanism to reach goal 1 is to build models. To provide symbolic namesof a location (i.e. the semantic locations), a model of real world locations, a so-calledlocation model, structures the space. An additional model of location sensors allowsthe integration of arbitrary positioning systems. The following goals are thus derivedfrom goal 1:

Goal 4: Provide expressive models:

■ Goal 4a: The framework should provide a model for locations.

■ Goal 4b: The framework should provide a model for location sensor output.

The following sections and chapters often refer to these goals. In the last chapter, thesegoals are picked up and it is checked, if Nimbus reached these goals.

4.2 The Nimbus Software Architecture

The layered structure of the Nimbus framework that was realized according to the ini-tial goals is presented in fig. 4-2. The Nimbus design distinguishes three layers, whichare built upon Positioning and Geo Data. This section gives an overview of the Nim-bus components. The respective components are described in detail in the chapters 5 to11.

Nimbus Overview 35

4.2.1 The Base Layer

The Base Layer provides basic services related to positioning systems and geo data. The component Virtual Positioning hides the specific details of underlying real

positioning systems (goal 1a). With this component, the framework can use arbitrarypositioning systems. These systems range from satellite positioning systems (e.g.,GPS), positioning with cell phone networks (e.g., GSM) to indoor positioning systems(e.g. our PalmSpot system). In addition, a simulation tool can simulate sensor informa-tion and can be used to set up realistic test scenarios without going to the respectivelocations.

To achieve the required flexibility regarding positioning (goal 1 and consequentlygoal 4b), the positioning systems are attached via a driver interface described inside thecomponent Positioning Driver. This interface allows the framework to switch betweenpositioning systems at runtime. If sensor output from multiple positioning systems isavailable, the system automatically makes a sensor data fusion.

The component Location Model addresses goal 4a. It structures the physical spaceand forms the basis for location services provided by the framework. It is influenced bythe concept of semantic locations, i.e. locations with a certain meaning for users andapplications. The Nimbus location model couples semantic and physical locations andoffers algorithms to convert between these location types.

Location data inside the model is imported from land survey sources or manuallygenerated by a graphical editor called DomainEdit. Between the location model and thegeo data, a component called Geometry & Geodesy provides import filters for differentkinds of geo data. In addition, it converts between different physical coordinate sys-tems and provides geometric operations (e.g. union or intersection of polygons).

The Location Server Infrastructure (LSI) stores the location data and provides basicservices to access these data (goal 2a). It mainly consists of a federation of so-calledlocation servers, each storing a piece of the overall location model. It is based on the

Fig. 4-2. The Nimbus framework

36 Jörg Roth

component Communication & Security which acts as a communication middlewarewith security services.

4.2.2 The Service Layer

The second layer, the Service Layer, provides higher-level location services.Following goals 1b and c, Nimbus offers so-called resolution services. Three kinds

of resolution services are available: Physical Resolution, Semantic Resolution andProximity Resolution, each of them providing special location information about theenvironment. The Physical Resolution replies physical information and the SemanticResolution retrieves a symbolic name of the current physical location. The ProximityResolution retrieves information about the nearby area.

Further components of this layer simplify the development of applications and pro-vide location-dependent standard services (goal 2b). An important service of this layeris the Semantic Geocast: an application can send a network packet with a single requestto a number of mobile users residing at a certain domain. The component Trigger Serv-ices informs the application whenever a certain location is reached. With this, an appli-cation can react to location changes without polling repeatedly, which helps to get anobject-oriented application design.

4.2.3 The Application Layer

The Application Layer contains the mobile part of the framework and the actual loca-tion-aware application. To run the mobile part, a specific runtime support for the devicehas to be available. A communication middleware called Network Kernel Framework(NKF) was especially designed for small mobile devices such as PDAs or cell phonesand offers communication primitives to access the servers. In addition, it simplifies theimplementation of the mobile part on new mobile platforms (goal 3c).

The counterpart of the resolution component in the service layer is the ResolutionClient. It offers the application a set of calls for using the framework services. It con-siders the low computational power of current mobile devices (goal 3a). A cachingmechanism reduces network traffic and allows the mobile client to perform the resolu-tion task while it is disconnected for a certain time (goal 3b).

To develop location-aware applications inside the Word Wide Web environment,Nimbus offers a high-level component called PinPoint. The World Wide Web is a pow-erful platform to develop location-based services, but currently makes no use of the cli-ent's current position. PinPoint integrates location information into the HTTP datastream and allows the usage of existing components such as Web browsers and Webservers without modification.

4.3 Overview of the Next Chapters

Describing the entire Nimbus framework is a difficult task. Even though the softwarecomponents have a well-defined interface and can in principle be described individu-ally, their functionality is strongly related to each other. To present a specific compo-nent often needs a motivation of the respective functions with the help of othercomponents not already described. A presentation strongly structured by the three lay-ers is therefore not suitable to show the strength of the Nimbus framework. As a conse-quence, the chapters 5 to 7 describe the most important Nimbus components in avertical manner, where related components of different layers and their interactions are

Nimbus Overview 37

presented jointly. Starting from the ’cores’, the Location Model (chapter 5) and theLocation Server Infrastructure (chapter 6), the location resolution mechanisms aredescribed. Chapter 7 present the access to real positioning systems. The location reso-lution mechanisms are extended and the proximity resolution is introduced. The chap-ters 8-11 describe the remaining Nimbus components Semantic Geocast, PinPoint,Remote Access, Communication & Security and Geometry & Geodesy.

38 Jörg Roth

5 The Nimbus Location Model

A location model structures the space and forms the basis for a location-basedapplication or service. This section presents the Nimbus location model with thecorresponding basic operations. Although the model is specified independently ofthe later implementation, it already considers scalability issues. The Nimbus loca-tion model was built according to the idea of semantic locations. It models loca-tions by so-called domains that represent both physical and semantic aspects oflocations. Domains are logically linked to each other by relations and associationsand form higher structures called hierarchies. The two basic operations, thesemantic and the physical resolution, use the logical links to retrieve informationabout the physical and semantic space.

5.1 Introduction

Most people have a clear idea of their location. Often, people reside at known areas andthey can usually express where they currently are. Going to unknown areas, peopleoften still have a certain impression of their location and can use terms like "the busstation in front of the airport" or the "city centre of Paris" without knowing the respec-tive physical coordinates. For applications and services however, the notion of locationis not as clear as expected. Location sensors may provide very different location infor-mation, depending on the technology used.

Location models can help to describe locations more precisely. They can especiallybe used to organize, structure and describe the space for users as well as for applica-tions. The term location model is not precisely defined and many location-based appli-cations or frameworks use an implicitly defined model. Looking at current literature,three main types of location models can be distinguished:

■ Geographic location models describe locations of objects or locations produced bysensors with the help of special languages. The focus of the corresponding researchaccording to these models is to reach the required expressiveness to describe loca-tion information for the intended usage.

■ Semantic location models introduce semantics into location information and gener-ate human-readable semantic locations. They can structure the space according tothe special requirements of the application or service.

■ The last type of location model takes into account the properties of the location sen-sors, which e.g. may only provide information about the proximity of one user toanother.

Location models of the last type (e.g. [3, 55]) have very specific properties and are notsuitable for a general framework such as Nimbus. This chapter will focus on the firsttwo types.

As a further distinction, a model can either be an abstract formalism or a concretemodel which describes a certain environment. This distinction can be compared toclasses and instances in object-oriented class systems. As the counterpart to a class, amodel can be a formalism to describe streets and places in cities in a tour guide. Anelectronic description of the tourist information for the city of Hagen can also be calleda location model. This is the counterpart to an instance. In the literature, both interpre-

The Nimbus Location Model 39

tations are used, sometimes simultaneously in one article. Often, the respective mean-ing can be derived from the context.

5.2 Related Work

This section presents different geographic and semantic location models.

Geographic Location Models

Geographic location models allow the expression of locations and geographic objects.The following list provides an overview of such models:

■ OpenLS is an initiative of the Open GIS consortium [115]. The goal of OpenLS is tosimplify the development of location-based services such as map applications ornavigation services. The language to describe geographic entities is GML [116].GML can also be used to describe the output of location sensors.

■ The Location Interoperability Forum (LIF) [118] standardizes the access to posi-tioning systems, especially in mobile phone networks. Inside the LIF, the LocationWorking Group (LOC) specified the Mobile Location Protocol (MLP) [119] whichdefines message formats in XML. Positions can either be cell information or posi-tions captured by GPS receivers.

■ NMEA 0183 [112] is a standardized message format used to receive position infor-mation from GPS receivers via a serial port or Bluetooth connection. With NMEA,developers can create applications that process GPS coordinates independently ofthe specific receiver device.

■ Nexus [10, 71, 168] is an open platform for context- and location-aware applica-tions. The location model is descried using the Augmented World Modelling Lan-guage (AWML). Queries use the World Querying Language (AWQL) [106]. Bothlanguages use XML schemas for their definition.

■ Further XML languages are used in the research of location-based services. Theselanguages are, e.g., G-XML [31], LandXML [91], or GMML [53]. A list of furthermarkup languages is presented in [89].

■ EDBS [4, 108, 109, 92] is a textual format used to specify geographical data for geoinformation systems based on the ATKIS geo database [5]. EDBS data entriesexpress polygons, lines and points and form the basis for maps and geo data pro-vided by land survey offices in Germany. For the United States, the so-calledTIGER/Line files of U.S. Census Bureau [171] have a similar meaning. As EDBSdata are used for the performance simulations, the format is described later in detail(see section 11.4.1 on page 159).

The usage of meta languages (foremost XML) significantly simplifies the constructionof languages and representation formats. The expressiveness of the correspondingmodels rank from models used to communicate with location sensors to models todescribe polygonal objects, including meta data. The decision for a specific languagehighly influences the interoperability between communicating components, e.g.between client and server. This decision is an issue in distributed architectures usingcomponents off the shelves (e.g. Web servers). Widely accepted standards will simplifyfuture developments in the area of location-based services.

40 Jörg Roth

Semantic Location Models

To discuss semantic location models, we first take a look at the notion of location. Twobasic location types can be distinguished:

■ Physical locations are described using coordinates. Typical examples are longitude,latitude, altitude, e.g. 51º22.634 North, 7º29.694 East, Altitude 164 m, plane coordi-nates, e.g. 2604152 Easting, 5694537 Northing or Cartesian coordinates, e.g.(x, y, z)=(100 m, 50 m, 20 m).

■ Semantic locations [95, 125, 150] have a certain meaning for users or applications.Typical examples are "Campus, University of Hagen" or "City centre of Paris".

In simple words, physical locations can be described by numbers, semantic locationsby strings. Physical locations can be considered as a single point in space, whereassemantic locations usually cover areas. Often, a single physical location can be mappedto multiple semantic locations, e.g. residing at the physical location 51º22.634 North,7º29.694 East, Altitude 164 m, the corresponding semantic locations are "Campus,University of Hagen", "Red Sculpture called Particle Accelerator", but also "NorthRhine-Westphalia" and "Germany". Semantic locations can be of different types:

■ locations with a political meaning: countries, states, cities, districts;

■ geographical locations: continents, oceans, mountains, rivers, lakes, forests;

■ mobile locations: trains, planes, cars;

■ temporary locations: construction zones, fairs;

■ other locations: campus, malls, city centres.

Pradhan distinguishes in addition to physical and semantic locations a third type oflocation, the geographical location [125]. Geographical locations are city names, zipcodes and postal addresses. This chapter does not distinguish geographical and seman-tic locations, but regards any location other than a physical one as a semantic location.

Nokia additionally distinguishes the terms position and location [110]:

■ A position represents an accurate point in space described e.g. by a coordinate pro-vided by a GPS receiver.

■ A location represents a larger area such as a city centre.

A position can be compared to a physical location, whereas Nokia’s location can bemapped to the term semantic location.

Semantic locations are used in various projects. Inside the Nexus framework, differ-ent semantic location can be modelled in the so-called augmented world model [10,71]: static objects like houses or streets, mobile objects such as users or cars and virtualobjects such as virtual post-its or virtual kiosks. Between these locations (called aug-mented areas), relations can be defined which express, e.g., inclusion of areas.

The RAUM location model [13] was designed to address the needs of networkedubiquitous devices such as the MediaCup (a cup with the ability to communicate [12]),the MemoClip (a device which generates a reminder when a user enters certain loca-tions [11]), coffee machines or computer watches. The model was mainly designed forindoor scenarios. The RAUM model in its first version could only store semantic loca-tions without any geographic or geometric information. Its main task was to structurecommunication between the ubiquitous devices. The model mainly consisted of a tree,where nodes can be compared to network routers and leaves correspond to the end-user


devices. In a second version, geometric information was added to the leaves in order toexpress positions of objects.

The ComMotion project [97, 98] aims to learn semantic locations from user behav-iour. When trained, ComMotion can link personal information to locations and cangenerate events (e.g. sounds or message boxes) when a user moves to a certain loca-tion. The location model is generated by detecting frequently visited locations and bydiscovering routes used between locations. Statistical methods such as Bayes classifi-ers categorize locations. The resulting model is a collection of semantic locations with-out any relationship to each other.

Semantic location models may be highly application-specific, e.g., semantic loca-tions for navigation services mainly contain roads and highways, whereas semanticlocations for tourist guides [1, 23] present touristic sites, places, or museums. A seman-tic location model for a general framework such as Nimbus has to provide a structureindependently of the intended application.

5.3 The Nimbus Location Model

The concept of semantic locations highly influenced the Nimbus location model. Thebasic idea was to combine semantic and physical locations and to provide algorithms tomap the location types to each other. An application or service can access location dataof both types, which has the following benefits:

■ Semantic locations have a meaning to the user and can be used to display informa-tion about locations. In addition, if semantic locations are built according to a well-defined name space, they can easily be used as a search key for traditional data-bases, tables or lists or even as substrings in file names.

■ Physical locations on the other hand are useful for all kinds of geometric queries,e.g. asking for distances between locations or asking for directions.

Nimbus assumes a close relationship between semantic and physical locations as pre-sented in fig. 5-1.

Objects in the physical space can be identified by their geometry, whereas objects inthe semantic space can be identified by their name. Objects are mapped between thesespaces by operations provided by the framework. Names of semantic locations in itsoriginal meaning are human-understandable, but the Nimbus location model relaxesthis condition as there is no single human-understandable representation which is suit-

Fig. 5-1. Mapping between physical and semantic space

42 Jörg Roth

able for all conceivable applications. Consider a famous street in Paris, which may benamed "Ave. Champs Elysées" by a tourist guide, or "next street on the right" by a carnavigation system. Semantic locations in Nimbus are thus not named in a final, human-understandable form, although the description gives a basic classification of the loca-tion, even for users. The symbolic names are optimized for the internal Nimbus opera-tions. A location-based service or application has to have its own mechanism to mapthese symbolic names to a final presentation for the end-user. Once the name space isclearly defined, transforming a name to its final representation often means simplylooking up a string inside a table.

The duality of physical and semantic space is reflected by the Nimbus locationmodel, which contains

■ a formal specification of sets that describe locations,

■ a set of rules that define the relations between these sets,

■ a set of operations that process location data and

■ a set of rules to adapt the model according to scalability issues.

Even though the model is defined independently of the later implementation, a decen-tralized storage of location data in the later infrastructure is considered. In particular,the operations should be efficiently executed in a distributed federation of separateservers.

Note that this chapter does not introduce a language to present location data (i.e. ageographic location model), but describes the formal semantic location model. Assum-ing the required expressiveness, a semantic location model can be defined independ-ently of the language that represents the location data. We return to the actual datarepresentation in chapter 11.

5.3.1 Structuring the Space Using Domains and Hierarchies

This section describes the concept of semantic locations in Nimbus more precisely. LetP denote the set of all physical locations inside the observed area. A reasonable set Pcould be the set of all locations from a certain depth below the earth’s surface up to acertain altitude in the atmosphere. The examples in this chapter present two-dimen-sional sets P, but also three space dimensions are conceivable. In a later chapter we dis-cuss issues related to the space dimensions resulting from an efficient implementation(see chapter 11), but they do not affect the following considerations.

We call an area S ⊆ P with a certain meaning a semantic location of P. We further

call a set C ⊂ 2P of semantic locations a semantic structure of P. Here, 2P denotes thepower set of P. In the following, we only consider sets C that contain a finite number ofsemantic locations. Note that two semantic locations do not have to be disjoint. Fig. 5-2 illustrates a sample set of semantic locations where C = {c1, c2, c3, c4, c5, c6, c7}.

To identify semantic locations not only by their area, semantic locations have aname. Let N be the set of all possible names. The function NAME: C → N maps asemantic location to a string. Names are required to be unique, i.e.NAME(c1) ≠ NAME(c2) for c1 ≠ c2. A semantic location with its corresponding name iscalled a domain. For a domain d, d.name denotes the domain name, d.c the semanticlocation. Further D denotes the set of all domains.


In principle, a semantic structure C could be an arbitrary subset of 2P. Looking at real-world scenarios, however, space is often structured hierarchically, e.g. a room is insidea building, a building is in a city and a city is in a country. Thus, C is divided into hier-archies. A hierarchy contains domains with a similar meaning, e.g. domains of cities orgeographical domains. Each hierarchy has a root domain and a number of subdomains;each of them can in turn be divided into subdomains. A top node of a subhierarchy iscalled a master of the corresponding subdomains, denoted m s for master m and sub-domain s. Further denotes the reflexive and transitive closure of , i.e. di dj ifeither di = dj or di is a top node of a subtree that contains dj.

A link between a subdomain and its master is called a relation. Relations carryinformation about containment of domains. Hierarchies are built according to the fol-lowing rules:

■ if di dj, then dj.c ⊂ di.c (condition 1)

■ di dj iff there is a string ncj with dj.name = ncj + '.' + di.name where ncj is called the name component of dj (condition 2)

■ the name components nci, ncj of different root domains di and dj are different;further di.name = nci and dj.name = ncj (condition 3a)

■ for three domains di, dj, dk: if di dj, di dk and dj ≠ dk

then ncj ≠ nck (condition 3b)

Condition 1 ensures that an area of a subdomain is completely inside the area of itsmaster. Note that the opposite direction of condition 1 is not always true: when an areais inside another area, they can belong to different hierarchies and are thus not related.

Due to condition 2 we can check if di dj or di dj with the help of their names.As these checks can use strings, they have an efficient implementation. The name com-ponent ncj can be an arbitrary string containing letters, digits and the characters '-' and'_' and must not contain the character '.'.

Condition 3a and 3b ensure that domain names are unique. Condition 3b ensuresthat two subdomains have different name components, and thus different names. Notethat it is no problem for domains with different masters to have the same name compo-nents nci and ncj.

Fig. 5-2. Semantic locations

44 Jörg Roth

Coming back to the example presented in fig. 5-2: assuming that C containsdomains with two different meanings, two hierarchies can be created, one containingc1, c2, c3 and c4, another containing c5, c6, and c7 (table 5-1).

The relations d1 d2, d1 d3, d3 d4, d5 d6, d5 d7 fulfil the conditions pre-sented above. Note that considering only condition 1, d1 d6 or d3 d6 could also betrue. But the name of d6 does not extend the name of d1 or d3 (condition 2) as it belongsto a different hierarchy. Thus neither d1 d6 nor d3 d6 holds.

Fig. 5-3 presents the resulting hierarchies. Even though relations are directed, thefigure shows undirected lines as the directions are obvious.

5.3.2 Associations

In principle, the model is now expressive enough to specify realistic sets of semanticlocations and their relationship to each other. Now, the important question is:

"Given a physical location p, which semantic locations correspond to p?"

Table 5-1. Domain example

Domain di nci di.c di.name

d1 A c1 A

d2 x c2 x.A

d3 y c3 y.A

d4 a c4 a.y.A

d5 B c5 B

d6 x c6 x.B

d7 y c7 y.B

Fig. 5-3. Example hierarchies


E.g., in fig. 5-3 point p resides in the domains A, x.A, y.A and a.y.A. Since a masteralways fully encloses a subdomain, the results A and y.A do not carry additional infor-mation. A sufficient answer to the question above is "x.A and a.y.A".

Answering such a question, the so-called semantic resolution could be performed bybrowsing through all hierarchies, from the root down to the smallest domains contain-ing p. This, however, would cause a large number of requests and a considerableamount of network traffic in real infrastructures. Therefore, a second relationshipbetween domains is introduced, the association:

Two domains d1, d2 are associated, denoted d1 ~ d2, iff

■ they share an area, i.e. d1.c ∩ d2.c ≠ {} (condition 1)

■ and neither d1 d2 nor d2 d1. (condition 2)

Condition 2 prevents the superfluous linking of masters to their subdomains, as theyalways share an area. Associated domains can be in the same or different hierarchies.With associations, the question above can easily be answered: only one domain d0 isrequired that contains the location p. Only the domains d ~ d0 can potentially contain p.In turn, no other domains have to be checked and thus the time-consuming searchthrough all of the hierarchies can be avoided.

The number of candidates can be reduced even more because applications are onlyinterested in the most specific domains. If, in the example above, an application wantsto know which domains contain the point q, it is only interested in the domains y.Aand x.B, and not in A or B, even though their areas overlap. Taking this into account,condition 1 can be modified as follows: associations only link two domains if theirshared area is not fully covered by their respective subdomains, more formally:

(d1.c \ ) ∩ (d2.c \ ) ≠ {}. (condition 3)

Note that if condition 3 is true, condition 2 is true as well, thus we can use condition 3as a definition of associations. We introduce the abbreviation

(d) = (d.c \ )

for the domain's area excluding the subdomains' area and finally get the short definition

d1 ~ d2 :⇔ (d1) ∩ (d2) ≠ {}.

Fig. 5-4 presents the associations in our sample hierarchies. The area shared by A andx.B is fully covered by the domain y.A, thus A and x.B are not associated since thislink would not provide additional information. Starting at x.B, only y.A has to bechecked. Note that condition 3 does not always reduce the number of queries. Startingat y.A the checks of x.B and B are required as there is an area of y.A ∩ B outside ofx.B.

e1.c

e1 D∈ d1 e1,

∪ e2.c

e2 D∈ d2 e2,

∪

e.c

e D∈ d e,

∪

46 Jörg Roth

5.3.3 Operations on the Model

One goal of the Nimbus approach is to provide uniform location information which isindependent of the actual positioning system. For each position, the framework pro-vides both physical and semantic locations, even though typical positioning systemsoffer only one type (goals 1b and c on page 34). Having both types, the application canchoose the appropriate type (or even both types) for the specific operating condition.To generate the appropriate location data, two operations are provided:

■ Physical resolution: Given a name n. What is the physical extension d.c of thedomain d with this name?

■ Semantic resolution: Given a physical location p. What are the names {ni} of thedomains di that contain p?

The physical resolution is simple and can be outlined by the following trivial code:

Algorithm 5-1: Physical Resolution

physicalResolution(name) → area{ look up the domain d with d.name = name return d.c}

The algorithm only has to look up the appropriate domain using a simple string searchand return d.c. The lookup mechanism is the cost intensive part. It will lead to a net-work search function in the distributed implementation. We discuss this later in chapter6.

The more complex operation is the semantic resolution, as multiple hierarchies anddomains may be involved. The algorithm used to provide this resolution can be out-lined as follows:

Algorithm 5-2: Semantic Resolution

semanticResolution(p) → set of names{ look up an arbitrary domain d0 with p ∈ (d0)

names ← {d0.name} for all d ~ d0 do if p ∈ (d) names ← names ∪ {d.name} return names}

Fig. 5-4. Sample hierarchies with associations


If an arbitrary domain is available that fulfils the first condition, the algorithm can effi-ciently loop through the associated domains. Again, the cost-intensive part is thelookup. Note that the algorithm assumes that at every conceivable location, at least onedomain d0 is available that covers this location. Thus, a full coverage of domains in theintended service area is required.

Proof of Correctness

As D is finite, the set of associations for a domain d0 also has to be finite and the loopterminates after a certain number of iterations. If the lookup terminates (see section6.3.4 on page 66), algorithm 5-2 therefore terminates as well.

We now have to show that after the termination d.name ∈ names iff p ∈ (d):Step 1: we have to show that all names collected by the algorithm correspond to

domains that actually contain p. This is obviously true, as this condition is part of thelookup and if statement before assigning names ← names ∪ {d.name}.

Step 2: we have to show that there is not any solution that the algorithm does notcollect. Assumption: there is such a solution domain h. Thus, no subdomain of h con-tains p (otherwise h would not be a solution, but its subdomain), i.e. p ∈ (h). Further,p ∈ (d0), which is ensured by the first statement of the algorithm. As a result,p ∈ ( (h) ∩ (d0)) and further ( (h) ∩ (d0)) ≠ {}, therefore condition 3 (seeabove) is true and thus h and d0 are associated. As h ~ d0 and p ∈ (h), the algorithm

would have collected h, which is a contradiction to the assumption above.

5.3.4 Compressing Associations

Up to now, we did not discuss the memory requirement related to the storage of thelogical links. In the real implementation, links are stored inside the domains’ record,thus require a certain amount of space. The number of relations is usually uncriticaland can easily be controlled by an appropriate hierarchy structure. Even for large areassuch as countries, the number of subdomains (e.g. the cities or states) is considerablylow.

The number of associations is, in contrast to relations, not controllable by hierarchystructures. Large areas may have a high number of overlapping domains in other hier-archies which cannot be avoided by reconstructing the hierarchies. Using real data,some domains could easily have hundreds of thousands of associations. To ensure scal-ability for real hierarchies, the number of associations has to be controlled by an addi-tional mechanism: if the number of associations exceeds a certain limit defined by thedomain, a server compresses the corresponding associations without losing importantinformation. The cost of compression is a more complex resolution mechanism, whichleads to more network traffic in the real implementation.

Even though this chapter focuses on the formal model, we now have to consider adetail of the later implementation: to derive the maximum benefit from the logicallinks, a domain d stores not only a pointer or the name of related or associateddomains, but also the respective area. In detail, d stores

■ e.c for each subdomain e and

■ (f) for each associated domain f.

We discuss the storage of domains on servers later (chapter 6). At this point it is impor-tant to know that each server can return domain information on request with the cost ofa network transaction. The goal is to run the resolution operations with a minimum of

48 Jörg Roth

network transactions. As a first step, each server can store as much information aboutrelated and associated domains as possible. Knowing the subdomains’ area, a domain dcan easily compute (d). So, associated domains can easily exchange their areas.Once the servers collected these data, the server that stores the domain d0 can effi-ciently run the algorithm 5-2 locally without any further queries to other servers.

As discussed above, the number of associations and thus the memory requirement tostore (f) for each associated domain f may be very high. One idea for compression isto replace (f) by its pointer to the domain f and query (f) via a network whenever itis needed. This mechanism is called the link compression. Note that the link compres-sion only represents a technical mechanism and has no influence on the formal locationmodel.

Another idea is to change the logical structure of associations. This mechanism iscalled the structural compression. It requires a change of algorithm 5-2. Before pre-senting the structural compression in detail, two remarks are to be made:

■ Both compression types can be combined which results in the four choices: no, link,structural, and structural with link compression.

■ All types of compression can be set up for a domain without changing the linksstored in other domains.

The last point is important: a domain (which is later stored on a server) can use com-pressed associations without affecting other domains on other servers. Each domaincan decide locally to compress or not depending on its available memory. A hierarchycan have all kinds of compression side by side without mutual interference. Moreover,even a single domain can compress its links using different kinds of compression. Forexample, it can compress only one half of associations, while the other half remainsuncompressed.

Structural Compression

Fig. 5-5 presents the basic idea of the structural compression, which replaces associa-tions to several domains by a single association directed to their master. The greydomain decides to compress its associations (fig. 5-5 ). The domain that com-presses its associations is called the originator of a compression. To isolate the changesresulting from this compression, an association is split into separate unidirectionallinks for each direction (fig. 5-5 ). Note that only links starting from the originatorwill be changed.

Fig. 5-5. The basic idea of the structural compression


Fig. 5-5 shows the result after compressing: the directed associations from theoriginator are replaced by a single compressed association. To simplify the resolutionalgorithm, the corresponding link is marked as a compressed link inside the link’s datastructure. The endpoint of a unidirectional association is called the target.

The compression can significantly reduce the number of associations, howeverinformation is lost. This results in modifications of the resolution algorithm, with thecost of a longer execution time. That is why a domain has to check carefully if com-pressing is appropriate.

After a compression, an originator does not know any longer which domains insidethe target’s subtree are the appropriate candidates to check if p ∈ (d). As a result,after following a compressed link, the resolution algorithm has to go down the subtreeto find the suitable subdomains. The algorithm can be outlined as follows:

Algorithm 5-3: Semantic Resolution (Compressed Associations)

semanticResolution(p) → set of names{ look up an arbitrary domain d0 with p ∈ (d0) names ← {d0.name} for all d ~ d0 do { if d is target of an uncompressed association { // the old way to handle d: simply check (d) if p ∈ (d) names ← names ∪ {d.name} } else { // then d is target of a compressed association checkset ← {d} while checkset ≠ {} // see below { choose an e ∈ checkset, checkset ← checkset \ {e} if p ∈ (e) names ← names ∪ {e.name} else { for all f with e f if p ∈ f.c checkset ← checkset ∪ {f} } } } } return names}

The algorithm works both for compressed and uncompressed associations. If no com-pressed associations are found, the algorithm works in the same way as algorithm 5-2(page 47). The most important modification is marked by . The loop iteratesthrough the appropriate subtrees to find potential domains that cover p. From a specificdomain, only potential subtrees are inspected (checked by p ∈ f.c), thus only a smallsubset of the overall domains below d will be checked.

As a prerequisite for correct execution, compressed associations have to follow cer-tain rules illustrated in fig. 5-6.

50 Jörg Roth

■ Rule 1: The general compression rule: All directed associations (compressed or uncompressed) to domains in a subtree canbe replaced by a compressed association to the subtree’s root (the target).

■ Rule 2: The downgrading rule: If, before applying rule 1, an uncompressed association to the target exists, it will bereplaced by a compressed association.

■ Rule 3: The subtree rule: The originator of a compressed association must not be a member of the target’ssubtree.

Rule 1 describes the structural compression in its simplest form. The target does notnecessarily have to be the lowest master of the corresponding subdomains. However, ifno further conditions have to be considered, it would be the best choice. Note that allassociations to the subtree have to be replaced. Otherwise, algorithm 5-3 has to memo-rize all visited domains in order not to visit a domain twice. Rule 2 has the same goaland ensures that there are not two associations to a single domain – an uncompressedand a compressed one.

The definition of associations on page 46 ensures that a domain in a subtree is notassociated to the subtree’s root. Rule 3 makes sure that such an association is not aresult of a compression. If such an association was allowed, the algorithm could erro-neously visit the originator.


As D is finite, the two for loops and the while loop always terminate. To show thatalgorithm 5-3 produces the correct results, we show that after the terminationd.name ∈ names iff p ∈ (d):

Step 1: as in algorithm 5-2, we can easily show that all names collected by the algo-rithm correspond to domains that actually contain p, as this condition is part of thelookup and the two if statements before assigning names ← names ∪ {d.name}.

Step 2: we have to show that there is not any solution that the algorithm does notcollect. Assumption: there is such a solution domain h. As in step 2 on page 48,p ∈ ( (h) ∩ (d0)) ≠ {}, thus either h ~ d0 (uncompressed association, case 1) orthere is an h0 with h0 h and h0 ~ d0 (compressed association, case 2).

Case 1 is similar to step 2 on page 48: as h ~ d0 and p ∈ (h), the algorithm wouldhave collected h, which is a contradiction to the assumption above.

Fig. 5-6. Rules to compress associations


Case 2: the algorithm enters the loop and first visits h0. Either h is a subdomainof h0 or there is a subdomain hs with h0 hs and hs h. As the algorithm visits alldomains f with p ∈ f.c, it in particular visits h or hs respectively. Note that when p ∈ h.c,then p ∈ hs.c, which follows from condition 1 on page 44. In both cases, the algorithmchooses the appropriate domain or subtree. In case of a subtree, we can apply the sameargumentation, thus the algorithm finally visits h, which is a contradiction to theassumption above.

Example

Fig. 5-7 shows the hierarchies of the example above (see fig. 5-4 on page 47), if com-pressions rules are applied to all domains.

In this figure, the domains x.A, y.A, and B are originators of a compression. Thesedomains have to store half of the associations compared to the uncompressed scenarioin fig. 5-4 (page 47). This example, however, is not meaningful enough to derivedetailed information about the benefits of compression. A statistical analysis is pre-sented in chapter 12.

5.3.5 Abstract Domains

As discussed in the last section, the number of subdomains is not as critical as thenumber of associations. If the number of subdomains of a specific master is too high, anew layer of domains can easily be introduced, which reduces the average number ofsubdomains per domain. A domain without an individual meaning that is only intro-duced as a means of structuring hierarchies is called an abstract domain. Consider ahierarchy which collects geographical objects such as rivers, lakes and mountains. Afirst approach can define a root domain geo and a second layer with all these entities.More reasonable is to introduce a second layer with the domains river.geo,lake.geo and mountain.geo and put all geographical entities into the third layerbelow the respective domains. The domains river.geo, lake.geo and moun-tain.geo are abstract, as they do not carry any information on their own, but onlystructure the hierarchy and represent their subdomains. More formally:

A domain d is called abstract, if (d) = {}, otherwise concrete.

Fig. 5-7. Example hierarchies with fully compressed associations

52 Jörg Roth

In simple words: an abstract domain does not cover a larger area than the union of allits subdomains’ areas.

Fig. 5-8 presents the example hierarchies where an abstract domain D is integratedrepresenting the areas of x.A and y.A. To be more clear, the figure only shows bidi-rectional associations. To distinguish abstract domains from concrete ones, names ofabstract domains are printed in italic.

An abstract domain cannot be an endpoint of an association. According to the defini-tion on page 46, two domains d1 and d2 are associated if (d1) ∩ (d2) ≠ {}. If eitherd1 or d2 is abstract, (d1) = {} or (d2) = {}, thus (d1) ∩ (d2) = {}. As a result,d1 and d2 cannot be associated. Therefore, new abstract domains do not increase theoverall number of associations.

As an additional benefit, abstract domains are ideal targets for compressed associa-tions, as the memory requirement to store (d) is minimal. Independently of a geomet-ric representation, empty areas only need a small amount of memory. As a last benefit,the test for p ∈ (d) can be performed very quickly. Since this is always false for anabstract domain d, the checks in algorithm 5-3 (page 50), can directly return falseand do not have to perform any geometric tests.

5.3.6 A Realistic Example

Fig. 5-9 shows a part of some realistic hierarchies.

Fig. 5-8. Integrating an abstract domain


The figure shows a small part of a huge set of domains of two hierarchies: a de hierar-chy contains German cities (white boxes) and a geo hierarchy contains geographicalentities such as rivers and mountains (grey boxes). The geo hierarchy contains typicalexamples of abstract domains such as the domains geo, river.geo andlake.geo. Details about the specific geographic extensions are not represented inthis figure, thus the structure of associations cannot be derived from this figure. As anexample, the domain downtown.hagen.de is associated to volme.river.geo,because Volme is a river which flows through downtown Hagen.

Fig. 5-10 shows the same hierarchies after applying all possible compressions. Inthis example, every domain does not have more than one outgoing association.

This example completes the presentation of the Nimbus location model with relationsand associations. Of course, there are more conceivable links between domains.Domains could e.g. be linked, if they have a common border. Such links can be storedas meta data in a domain’s record, but they do not have any influence on the infrastruc-ture described in the next chapter. For the operations provided by the Nimbus frame-work, relations and associations are sufficient.

5.4 Summary

The Nimbus location model structures the space and relates physical to semantic loca-tions. It forms the basis for an efficient infrastructure to store and retrieve location datain a distributed environment.

The Nimbus location model describes locations using domains and defines a set ofrules that expresses the logical links of relations and associations between these

Fig. 5-9. Part of two realistic hierarchies

Fig. 5-10. Realistic hierarchies with fully compressed associations

54 Jörg Roth

domains. The physical and semantic resolution operations retrieve specific informationof domains.

Finally, this chapter presented two mechanisms to ensure the scalability of themodel: the compression of associations and the integration of abstract domains. Whilecompressing associations is a mechanism which runs on a technical level, abstractsdomains are an ideal mechanism to structure the hierarchies semantically.


56 Jörg Roth

6 The Nimbus Runtime Infrastructure

The Nimbus location model provides a formal basis of the framework. This chap-ter presents an infrastructure which effectively stores the location data and is ableto run the required algorithms in a decentralized manner. Domain data are directlyavailable in the formal location model, but the domain access via a network has tobe considered in a decentralized environment.

6.1 Introduction

This chapter focuses on the Nimbus runtime infrastructure which implements the for-mal model. According to the Nimbus software architecture (fig. 4-2 on page 36), theinfrastructure is represented by the component Location Server Infrastructure (LSI).The best way to explain the LSI is to present those components which are involved inan important task of Nimbus – the resolution operations. This vertical presentation cutsthrough the architectural layers of Nimbus and covers the following components:

■ the Physical and Semantic Resolution components,

■ the Resolution Client, especially the cache mechanism and

■ Trigger Services.

The design of these components depends on the Location Server Infrastructure. With adescription of the involved components we also get an indirect presentation of theNimbus Location Server Infrastructure. This chapter describes how the location modelis distributed among the server infrastructure and how the resolution operations areexecuted in a distributed manner. Before presenting the Nimbus Location Server Infra-structure in detail, the following section describes approaches with similar goals.

6.2 Related Work

Storing maps and retrieving location information is traditionally a domain of spatialdatabases and geographic information systems. They provide powerful mechanisms tostore and retrieve location data [164]. Such systems primarily concentrate on accessinglarge amounts of spatial data. Usually, they follow the classical client/server paradigm:all data are stored and administered centrally. Mobile users accessing these data have toconnect to the central storage. For load balancing or fail safety, these data can be repli-cated, but mobile users and operators only notice a single service point instead of a setof servers.

Current location-based services in mobile phone networks also follow the tradi-tional client/sever paradigm. Mobile phone providers cannot give away the mobileuser’s current location without permission. For legal issues, servers are often part of theprovider’s network, even though the service provider is a third party.

Many frameworks in the research area of location-based services deviate from thesingle server paradigm and use multiple servers. The Active Badge projects [178] usesa number of servers to provide tracking and messaging capabilities in buildings: Loca-tion Servers store locations of tracked users, Name Servers store the names of alltracked users, Message Servers route messages between mobile users and ExchangeServers connect different subsystems.

The Nimbus Runtime Infrastructure 57

Leonhardi and Kubach [94] describe the idea of a Universal Location Service whichallows mobile clients to track their positions. As an infrastructure, they suggest a feder-ation of Location Servers, each storing the locations of a subset of tracked objects. Theaccuracy of location information varies from server to server. A primary copy providesthe highest accuracy, whereas secondary copies may have older and inaccurate locationdata. Location Registers find appropriate location servers for a certain object.

Inside the Nexus project [10, 71, 168], a federation of servers store location data.Nexus distinguishes between Area Service Registers (ASR) and Spatial Model Servers(SpaSe). ASRs store meta data of augmented areas and a link to the SpaSes, whichstore objects in the respective augmented areas. A SpaSe stores all static (i.e. non-mobile) objects (real or virtual) in its location area. The idea is to set up SpaSes as eas-ily as Web servers. Requests about objects are first directed to the responsible ASR,which redirects the request to one or more SpaSes. Multiple responses are finally fusedto a single response, which is then transferred to the requesting application.

Some frameworks in the area of location-aware services and application work with-out any server and use ad-hoc or peer-to-peer networks to perform their services. Heu-telbeck [67] suggests a network of stationary and mobile users connected by a network.Since pure ad-hoc networks may not have the desired coverage, mobile users are wire-lessly connected to a traditional backbone network. Mobile users detect their locationand can access location-dependent information provided by other users. The entire net-work is formed by the mobile users – there is no dedicated service provider.

Ad-hoc networks without any fixed network infrastructure may also process loca-tion information. Nodes of an ad-hoc sensor network can measure their own locationand can propagate location measurements of other objects. Lédeczi et al. present suchan approach to detect the location of a shooter in a battlefield scenario [93].

Location-aware ad-hoc networks of the simplest structure only connect two mobileusers. As wireless connections have a certain range, two users can detect if they are inproximity. Simple applications such as the Flirt Getty [50] use this technique to informusers about other users in proximity with the same hobbies or music preferences. Anti-fakos and Schiele [3] pick up this idea and introduce the term semantic proximity fortwo devices that share the same context as a result of their proximity.

6.3 The Nimbus Service Infrastructure

The Nimbus framework stores the location data in a decentralized manner and providesan infrastructure to query these data. In principle, one huge database on a single servercan store all hierarchies with the corresponding domains. This, however, has seriousdisadvantages:

■ A single database would be a bottleneck for a huge number of potential clients.Assuming hundreds of thousands of domains and maybe millions of mobile users,this would cause a serious load problem for a single server. Furthermore, backupsystems have to be installed as the entire service would depend on this single server.

■ Mobile users who want to access domain data would have to connect to this serverover potentially far distances (in terms of network as well as geographically). Itwould be more reasonable for a mobile client to have local access to the service.

■ Information about local domains is usually available locally and is difficult toadministrate in a central database. Consider rooms inside a building: the localadministrator has a ground plan of the building and wants to administer these data ina local database rather than to send these data to a central database administrator.

58 Jörg Roth

As a solution, a distributed system of Location Servers stores the location model. Inprinciple, each server could store a single domain. This, however, would result in anintolerably huge number of servers. Therefore, each location server can store a certainamount of domains. Location servers are connected to each other in a peer-to-peermanner.

The intended usage scenario for Nimbus leads to a strong separation of providers oflocation data and the mobile users asking for these data. An ad-hoc or peer-to-peer net-work without any server infrastructure which only connects mobile users is not suitablefor the intended usage.

6.3.1 Distributing Domains Among Location Servers

In principle, domains could be distributed randomly among the servers, but the morecoherent domains reside on a server, the more queries can be executed on a server with-out additional network transactions. We will discuss the distribution of domains amongservers more precisely.

Let D denote the set of all domains. A partition G = {G1,..., Gn} of D is called aclustering of D, if there exists a set R = {r1,..., rn} ⊆ D where for all i ∈ {1,..., n}:

■ ri ∈ Gi, (condition 1)

■ , (condition 2)

■ (condition 3)

The motivation for the first two conditions is obvious: each set Gi has a special elementri which is the top of the subtree containing all elements of Gi. A domain ri is called thecluster root of cluster Gi.

Condition 3 is more difficult to motivate. Fig. 6-1 shows a clustering which fulfils con-ditions 1 and 2, but should be avoided as a.x.A and A are inside the same cluster andonly connected via another cluster. Condition 3 ensures that only connected subtreesare put into clusters and not isolated elements. We need this condition later for an effi-cient implementation.

If D = {d1,..., dm}, then obviously G = {{d1},..., {dm}} is a clustering of D, which iscalled the fully distributed clustering. If D is partitioned into the hierarchies H1,..., Hh,then G = {H1,..., Hh} is also a clustering called the minimal clustering. As a furtherexample, a clustering of the domains in table 5-1 (page 45) is G = {{d1, d2}, {d3, d4},{d5, d7}, {d6}} with R = {d1, d3, d5, d6}.

The idea is to use the clusters as the entities of distribution: ideally, each serverstores a single cluster. In principle, more than one server process (and thus more clus-

Fig. 6-1. Motivation for condition 3

d Gi : ri d∈∀

d Gi rj R : rj d rj ri⇒∈∀∈∀


ters) could be installed on a physical machine. However, these server instances woulduse the same means of communication (i.e. network messages) even though they com-municate locally. For clarity we make the simplification that each cluster is stored onits own server.

To complete the clustering idea, it is important to know how to get a clustering forgiven hierarchies. We assume that for an existing set of servers, a clustering is alreadygenerated. If a new server with a given cluster root newR is introduced, the clusteringhas to be restored with respect to the new server. Starting with a minimal clustering, thealgorithm allows to iteratively add new cluster roots. Algorithm 6-1 shows how tomodify the clustering.

Algorithm 6-1: Re-Cluster When Introducing a New Cluster Root

recluster(G, R, newR) → G, R{ look up Gi ∈ G with newR ∈ Gi if newR = ri return error "new root is already cluster root" newG ← {} for each d ∈ Gi { if newR d { newG ← newG ∪ {d} Gi ← Gi \ {d} } } G ← G ∪ newG R ← R ∪ newR return G, R}


We want to show that a valid clustering is always transformed into a new valid cluster-ing. As D is finite, the for loop always terminates. We can show the correctness ofthis algorithm as follows:

■ Condition 1: obviously ri ∈ Gi and newR ∈ newG;

■ Condition 2: is still true as we only remove elements from Gi,

is true as it is explicitly expressed in the if statement;

■ Condition 3: for any Gi ≠ newG this is obviously true, thus we have to show that

. For rx = ri this is true as ri newR

(ensured by the first step of the algorithm). For other rx ≠ ri this is true for each d of

the old version of Gi, thus had to be true for d ∈ newG as well.

Properties of Clusters, Links between Clusters

Associations, relations and areas can be defined for clusters and thus for servers in acanonical manner. We get the following definitions:

d Gi : ri d∈∀

d newG : newR d∈∀

d newG rx R : rx d rx newR⇒∈∀∈∀

60 Jörg Roth

■ Gi cluster Gj :⇔ ri rj,

■ Gi cluster Gj :⇔ ,

■ Gi ~cluster Gj :⇔ ,

■ cluster(Gi) = (ri.c \ ).

Note that a definition of cluster with Gi cluster Gj iff ri rj is not reasonable as pos-sibly ri and rj are not related. With the help of cluster we get a so-called cluster tree foreach hierarchy. Fig. 6-2 shows the clustering and the transferred links of the examplehierarchy of section 5.3.6 (page 54). The cluster root is the representative for the entirecluster, thus it is sufficient to simply print the name of the cluster root to define theoverall tree structure.

Fig. 6-3 presents the corresponding infrastructure for these hierarchies. Each locationserver is responsible for a specific domain and all subdomains, for which no other loca-tion server is set up. In our example, the location server for hagen.de coversfley.hagen.de and downtown.hagen.de, but not the domain universi-ty.hagen.de, as it has its own location server.

When a mobile node moves to a specific location, it automatically looks up anappropriate location server for the new location, called the Local Location Server(LLS). The LLS is the representative of the infrastructure for a mobile node and playsan important role for the algorithms presented below.

Fig. 6-2. Clustering and cluster tree of the example hierarchy

d Gi : d rj∈∃

di Gi dj Gj : di dj∼∈∃∈∃

rj.c

Gj G∈ Gi clusterGj,∪


As mobile users are distributed among different location servers, this infrastructure ishighly scalable. The approach does not overload top-level location servers. With thehelp of the reclustering algorithm, one can add a server and restructure the respectivehierarchy, thus it is possible to add server power to the infrastructure in a simple way.

To sum up the benefits of the clustering concept:

■ Operators of location servers have a guideline to decide which domains their servershave to cover. This is both a right and a duty for an operator. Once a cluster root isselected, the only way not to cover a subdomain of this cluster root is to install anew server. Apart from that, it is an obligation to store all subdomains.

■ The cluster tree provides an efficient structure to collect all subdomains of a specificdomain, which is necessary for the network variant of the resolution operation (pre-sented in section 6.3.2). In addition, the cluster tree is used to collect subdomains forthe geocast operation presented in chapter 8.

■ A cluster and thus a location server represent a coherent view of local information.Once a mobile user is connected to a specific server, it can move inside the domain’sarea without reconnecting too often to other servers. In the worst case it has toswitch to subcluster servers, which can easily be accessed by the logical linksbetween the clusters.

6.3.2 Performing Resolution Operations

The migration of the resolution algorithms algorithm 5-1 (page 47) and algorithm 5-3(page 50) to the respective network variants is straight forward. In principle, directaccess to domain data has simply to be replaced by calls provided by location servers.In addition, the algorithm can take advantage of the clustering concept: a server can runparts of queries locally without further network access as long as the domains belong tothe specific cluster. The algorithms can be reformulated as follows:

Fig. 6-3. Mapping of location servers to domains

62 Jörg Roth

Algorithm 6-2: Physical Resolution (Network Variant)

physicalResolution(name) → area{ look up an LLS for domain d0 with d0.name = name return LLS.getArea(name)}

Algorithm 6-3: Semantic Resolution (Network Variant)

semanticResolution(p) → set of names{ look up an LLS for domain d0 with p ∈ (d0)

names ← {d0.name} assocs ← LLS.getAssociated(d0.name,p) for each assoc ∈ assocs do { if !assoc.cFlag // no structural compression names ← names ∪ {assoc.name} else { // structural compression servers ← {assoc.server} while servers ≠ {} { choose an s ∈ servers, servers ← servers \ {s} names ← names ∪ s.getDomains(p) servers ← servers ∪ s.getSubservers(p) } } } return names}

In order to run the queries, each server i storing cluster Gi has to provide a number offunctions as shown in algorithm 6-4, which denotes these functions in an object-ori-ented manner and considers a server as a complex object which provides a number ofmethods. Note that this is only a notation and does not necessarily mean that a serverprovides remote method calls.

Algorithm 6-4: Methods of Location Server i

getDomains(p) → set of names{ names ← {} for each d ∈ Gi if p ∈ (d) names ← names ∪ {d.name} return names}


getAssociated(name,p) → set of (server,name,deltac,cFlag){ assocs ← {} look up d0 ∈ Gi with d0.name = name for all d ~ d0 do { cFlag ← (association to d is structural compressed) if p ∈ (d) or (p ∈ d.c and cFlag) assocs ← assocs ∪ {(d.server,d.name, (d),cFlag)} } return assocs}

getSubservers(p) → set of servers{ servers ← {} for each Gj with Gi cluster Gj if p ∈ rj.c servers ← servers ∪ {serverj} return servers}

getArea(name) → area{ look up d ∈ Gi with d.name = name return d.c}

The method getSubservers in particular takes advantage of the clustering as aserver can easily check whether there is a potential subserver that may cover p.

Algorithm 6-3 always invokes both methods getDomains and getSubserv-ers on a server simultaneously, thus an efficient implementation combines thesemethods to a single method. Algorithm 6-4 contains two separate methods only forclarity.

Example

This section demonstrates algorithm 6-3 with the help of an example. Fig. 6-4 shows ascenario with the clustering of section 6.3.1 (page 59) applied to the hierarchy in chap-ter 5 (page 45).

Fig. 6-4. Scenario for the resolution algorithm

64 Jörg Roth

The scenario assumes two mobile users at the locations p and q. In the following,server<root> denotes the server which stores the cluster with the cluster root<root>. Both mobile users chose servery.A as their LLS. Table 6-1 and table 6-2show the steps to resolve the locations p and q with the help of algorithm 6-3.

Table 6-1 shows the simple case, where the mobile client can resolve the location witha single query. As the domain a.y.A stored in the LLS uses uncompressed associa-tions to potential domains, all requested data are stored locally. Thus, no further net-work transactions are necessary.

The example presented in table 6-2 is more complex, as the association to B is acompressed association and furthermore, serverB is not the responsible server for theposition q. As a result, two more queries (one to serverB and one to serverx.B) arerequired. Note that these two queries are only a result of compression. As discussed in

Table 6-1. Steps to resolve location p

Step Resultcall semanticResolution(p)

look up an LLS ... LLS=servery.A, d0=a.y.A

names ← ... names={"a.y.A"}

assocs ← ... assocs={(serverA,"x.A", (x.A),false)}

for each assoc ... assoc=(serverA,"x.A", (x.A),false)

names ← ... names={"a.y.A","x.A"}

return names return {"a.y.A","x.A"}

Table 6-2. Steps to resolve location q

Step Resultcall semanticResolution(q)

look up an LLS ... LLS=servery.A, d0=y.A

names ← ... names={"y.A"}

assocs ← ... assocs={(serverB,"B", (B),true)}

for each assoc ... assoc=(serverB,"B", (B),true)

servers ← ... servers={serverB}

choose an s ... s=serverB, servers={}

call s.getDomains {}

names ← names ∪ ... names={"y.A"}

call s.getSubservers {serverx.B}

servers ← servers ∪ ... servers={serverx.B}

choose an s ... s=serverx.B, servers={}

call s.getDomains {"x.B"}

names ← names ∪ ... names={"y.A","x.B"}

call s.getSubservers {}

servers ← servers ∪ ... servers={}

return names return {"y.A","x.B"}


section 5.3.4 (page 48), it is necessary to find an appropriate balance between networktraffic and memory requirements to run the resolution algorithm.

6.3.3 The Role of the LLS

The Local Location Server plays a major role in the Nimbus infrastructure. For amobile client, it is the first contact instance – and in many cases it can fully answer thequeries without any further network transactions.

An LLS covers the area of a cluster, thus local users can move around locally with-out looking up a new location server. Only when a mobile user leaves a certain area, anew LLS has to be looked up. The respective lookup mechanisms are described in thenext section.

Being connected to a specific LLS for the first time, the mobile client stores theLLS’s cluster area. Looking up an LLS in the resolution algorithm is simple in mostcases: if the mobile user still resides in the LLS cluster area, it can use the old LLS anddoes not have to perform a search operation.

Nimbus clients distinguish two modes to use a location server: inbound and out-bound mode. Algorithm 6-4 presents the outbound mode: the mobile client first asksthe LLS and, in case of compressed associations, performs further queries to otherlocation servers. This mode can be entirely controlled by the mobile client. This is effi-cient, as long as the mobile client is able to connect to every relevant location server.

In some scenarios, however, this is not possible: a mobile node may be separatedfrom the global network by a firewall, which only allows some hosts to connect tohosts outside the local network. A mobile node using a cell phone network could havequick access to a server inside the phone network, but connections to servers outsideare slow and cost intensive. In cases where location servers outside the network are dif-ficult to connect to, the so-called inbound mode is used: the mobile node only connectsto the LLS, which in turn performs all subsequent queries to other location servers. Inaddition, the inbound mode is suitable for computational weak mobile clients that arenot capable to perform the resolution operation themselves.

Algorithm 6-4 can be modified to get an inbound mode variant: it simply executesall statements below the LLS lookup on the LLS instead of on the client. The selectionof inbound or outbound mode is controlled by the mobile client. However, if a serverbecomes overloaded by too many clients demanding inbound mode resolutions, it canreject further queries in inbound mode and force a client to use outbound mode instead.

6.3.4 Looking up Location Servers

Two different types of lookup are mentioned so far: mobile clients looking up an LLSand a location server looking up other location servers. The latter lookup is called theinter-server lookup. Both kinds of lookup do not use any central instance.

Looking up the LLS is more critical than the inter-server lookup: if a mobile nodemoves to a new location, the mobile user expects to use the service without interrup-tion. The user should not be aware when the system performs a handover to a newLLS. For this, a mobile client automatically supervises its location and possibly dis-covers new servers. The lookup uses the following mechanisms:

66 Jörg Roth

■ a mobile client can receive information about the LLS from the positioning system,

■ a mobile client can perform a search using network mechanisms (e.g., broadcast-ing), or

■ a mobile client can ask another location server for an LLS.

First, the positioning system can distribute information about the LLS as additionalpayload information used in the positioning mechanisms. Some positioning systemsbroadcast beacon messages for the positioning process. Beacon messages can beviewed as network frames with a small payload in which a system can distribute theLLS network address. This concept is integrated in the PalmSpot positioning system(see chapter 7).

As a second mechanism, the mobile client can send lookup requests via broadcastmessages to the local network. An LLS receiving the lookup request can respond to themobile client, which in turn stores the LLS’s cluster area. The client can use UDP mul-ticast, or if available, Multicast IP for this task. The broadcast mechanisms are encap-sulated inside the communication middleware NKF (see chapter 9). Mechanisms suchas Multicast IP may carry the lookup request to a larger area. As a request perhapsreaches servers that do not share the same local area, a request must contain the loca-tion of the mobile client. A location server can simply check if it is responsible for therequesting client.

In order to use higher-level standards to look up LLSs, the mobile client can useservice discovery protocols such as the Service Location Protocol (SLP) [58, 173] orthe Dynamic Host Configuration Protocol (DHCP) [2, 44]. Both protocols are basedon broadcast mechanisms which first look up a directory agent or a DHCP serverrespectively. They transfer additional information about the network or the availableservices to the mobile client. DHCP is often used to provide the local network configu-ration to mobile clients. Inside the DHCP response, server addresses such as the localmail server or the local web servers are transferred. It is possible to transfer additionaluser-defined records which contain the LLS’s address.

As a last network-related mechanism, a mobile client can use the Domain NameService (DNS) [100, 101] of the Internet to ask for a server. Using DNS, a locationserver can use a special network name inside a local network (e.g. lls.<internetdomain>). A similar mechanism is used by the World Wide Web wherewww.<internet domain> is a traditional name for web servers.

Lookup mechanisms with DHCP and DNS are based on the assumption that a locallookup in terms of a local network also means a local lookup in terms of location. Thisis true for many networks (e.g., Internet subnets). Consider networks of companies,universities or departments. They usually reside at a certain location, thus a locallookup is restricted to a specific local area. In contrast, other networks are distributedthroughout a huge area. Consider a network of an Internet provider or a mobile phonenetwork. Using DHCP or DNS to find an LLS in these networks would not be useful.Thus, if a mobile client found a candidate, a potential location server always has tocheck with the help of its location, if it is responsible for a specific mobile client.

Once a mobile client was connected to any location server (LLS or not), it can askfor an appropriate LLS. Part of each location server is a service that offers other appro-priate location server addresses for a specific location. The masters, subdomains orassociated servers are in particular good candidates for new LLSs, when a mobile cli-ent leaves the LLS area, as movements can be divided into three types:


■ A user still resides in the LLS’s area, but enters a lower-level domain (e.g. a sub-domain).

■ A user leaves the LLS’s area, but still resides in the master’s area.

■ A user leaves the LLS’s area and, in addition, the entire hierarchy. In this case, asso-ciated servers are potential candidates.

In all cases, the candidates are stored inside the current LLS state. The next step doesnot necessarily lead to the LLS, but going over multiple steps ensures that, after a cer-tain (small) number of subsequent queries, an LLS will be found. The only prerequi-site: there must be an uninterrupted sequence of relations and associations between thefirst location server and the LLS, which in real environments is usually true.

To ensure finding at least one location server, even if all the mechanisms describedabove fail, a mobile client could have a list of fixed location servers. Even though thenetwork of location servers is self organizing without any fixed network addresses,there will be some location servers with a long lifetime. Especially the addresses ofhigh-level servers (e.g., for de or geo) will not change often, thus such addressescould be distributed to potential mobile clients. However, in order not to overload suchservers, clients should use fixed server addresses only in the worst case that othermechanisms fail.

The termination of the lookup is ensured by supervising certain timeouts for therespective mechanisms. Whenever a mobile client successfully looked up a server, itcan store these data for a certain amount of time. When it enters a specific area again,the lookup can be performed without any network interaction.

6.3.5 Protocol Details

All network operations are modelled using commands. A command contains a com-mand identifier and command-dependent data. There are three communication typesfor commands:

■ Unicast commands are sent via unicast datagram mechanisms such as UDP.

■ Multicast commands are sent to a number of hosts using native multicast capabili-ties of the network (e.g., Multicast IP) or a sequence of unicast datagrams.

■ Stream commands use reliable, bidirectional streams (e.g. TCP) and allow a directreply from the correspondence host without using another network connection.

The actual network mechanism (e.g. TCP, UDP, or Multicast IP) is not used directly,but hidden inside a communication middleware (see chapter 9). With the help of themiddleware the network mechanisms can be replaced without modifying the client orserver software.

Nimbus distinguishes four protocols:

■ The Lookup Protocol is used by a mobile client to find its LLS.

■ The Service Protocol is used by a mobile client once it discovered the responsibleLLS to use the Nimbus services.

■ The Inter-Server Protocol is used by the location servers to maintain the logical net-work between each other.

■ The Mapping Protocol is used by the positioning mechanism.

Table 6-3 shows all Nimbus commands. Besides the functions described above, thecommands of two more functions are shown. The command PERFOM_MAPPING is

68 Jörg Roth

needed to convert local position information output into a global one (see section 7.3.3on page 89). The geocasting commands allow the mobile client to send messages to anumber of other clients at a certain location (see section 8.3 on page 109).

Even though most of the commands result in a reply, only the replies that are not adirect response to a stream command are modelled by an own command. To illustratehow commands are exchanged, the inter-server lookup and the semantic resolution aredescribed.

Table 6-3. Nimbus commands

Command Type Direction Description

Lookup ProtocolSERVER_LOOKUP Multicast Client →

Multiple LSclient looks up an LLS

SERVER_LOOKUP_REPLY

Unicast LS → Client the LLS answers

Service ProtocolRESOLVE_PHYSICAL Stream Client → LS getArea() callRESOLVE_SEMANTIC Stream Client → LS semantic Resolution in

inbound mode, getDo-mains(), getSub-servers(), getArea() calls in outbound mode

SEND_GEOCAST Stream Client → LS send geocastRECEIVE_GEOCAST Stream LS → Client receive geocast

Inter-Server ProtocolINTER_SERVER_LOOKUP

Multicast LS → Multiple LS

LS looks up related or associated LSs

INTER_SERVER_LOOKUP_REPLY

Stream LS → LS a related or associated LS answers

INTER_SERVER_REGISTER

Stream LS → LS a server registers itself as associated or related LS

PING Stream LS → LS checks if another server is still alive

INTER_SERVER_PROPAGATE

Stream LS → LS geocast propagation

INTER_SERVER_GEOCAST

Stream LS → LS geocast message passing

Mapping ProtocolPERFOM_MAPPING Stream Client →

Mapping Servermapping request


Inter-Server Lookup

The Nimbus approach requires the location servers to know their cluster master, sub-cluster servers and associated location servers. The mechanism to build and maintainthe corresponding entries is called the inter-server lookup. As there is no centralinstance, the lookup has to run in a distributed manner. Location servers usually have along lifetime, thus, the links of relations and associations have a long lifetime as well.The inter-server lookup can use well-established discovery mechanisms used in peer topeer networks, which are allowed to need a certain amount of time without significantdrawbacks for the system. The inter-server lookup is performed in three phases: lookup, registration and maintenance. The first two phases only run once when a serverstarts its service.

Fig. 6-5 shows an example for the inter-server protocol using the UML sequence dia-gram syntax. When a server starts up the first time, it has to look for other locationservers using the INTER_SERVER_LOOKUP command. Using network broadcast, aserver transmits a discovery message with its own domain name and the specificationof the physical area it covers. A server that receives a discovery message can easilydecide, whether this message is relevant or not.

When replies to the broadcasted messages arrive, the new location server registersto other servers. The inter-server protocol strongly separates the discovery from theregistration procedure, as both steps use different communication paradigms. Discov-ery uses broadcast and multicast protocols that are only unidirectional and thus notsuitable for registration. The registration step, in contrast, uses a reliable bidirectionaltransport protocol to acknowledge a registration by the receiver. Two kinds of registra-tion exist:

■ a subdomain sends a registration to a master,

■ a server sends a registration to its associated servers.

Note that a master does not register at its subdomains. Moreover, receivers of a regis-tration do not send a registration command back.

Once a registration was processed, servers store the relation or association in theirlocal databases. If a location server breaks down or disconnects from the network, itcannot explicitly inform other servers. Thus, a mechanism is required to ensure thatinactive location servers are automatically removed from databases after a certain time.Active servers have to send a PING command to all related and associated servers peri-

Fig. 6-5. Sequence diagram for the inter-server protocol

70 Jörg Roth

odically. If servers do not answer for a certain time, they are removed from the localdatabase. Note that both the originator and the receiver of a PING command considerthe respective other server as alive, thus the PING command has only to be sent in onedirection in a certain time interval.

When a server decides to compress associations, it has to send a registration com-mand to all associated servers, even though they are removed after the compression.The registration is necessary to create the reverse association. Fig. 6-6 presents an ex-ample. For each location server, assocs denotes the set of collected associated servers.

LS1 looks up associated servers. The example assumes that associations to LS2 andLS4 can be replaced by a compressed association to LS3. After the lookup reply of LS3arrived, LS1 decides to compress. Nevertheless the lookup reply of LS4 leads to a reg-istration, as LS4 has to build an association to LS1.

Semantic Resolution

Fig. 6-7 shows a client which wants to perform a semantic resolution. First, the clienthas to look up its LLS using the SERVER_LOOKUP command. The command containsthe current location, thus a server receiving this command can decide whether it isresponsible or not. If yes, the server answers with a SERVER_LOOKUP_REPLY con-taining an ok. If not, the server may know a more suitable location server, e.g. its mas-ter, one of its subdomain or one of its associated servers that covers the requiredlocation or at least an area that is nearer to the user’s location. In this case, it sends aSERVER_LOOKUP_REPLY containing a redirect and the corresponding serveraddress. Even though the client does not get any direct hit, it can lookup the appropri-ate server with the help of the redirect messages.

A lookup via broadcast may reach many servers which in turn reply a high numberof redirect messages. These could overload a mobile client or its wireless connec-tion. To reduce the overall network traffic, a server answers a lookup according to thefollowing rules:

■ The actual LLS always answers a lookup.

■ Servers which know the actual LLS (as their master, subserver or associated server)always answer with a redirect message.

■ Other servers that receive the lookup and know a more suitable server, reply aredirect with a certain probability. For this purpose, a random numberrand ∈ [0, 1) is generated and only if rand < qredirect the redirect message issent.

Fig. 6-6. Sequence diagram for registration as associated server


The value of qredirect is computed according to the formula

where

■ l is the distance of the domain’s border to the given location,

■ q0 ∈ (0, 1] is the maximum value of qredirect (in the case of l = 0),

■ l0 > 0 is the distance l that leads to qredirect = q0/2 and

■ lmax > l0 is the maximum distance l to get qredirect > 0.

The variable l is measured using geometric operations (see chapter 11). With the helpof the variables q0, l0 and lmax the average number of redirect replies can be controlled.These variables are set by the client that performs the lookup. As an optimal assign-ment requires knowledge about the distribution of domains and the number of serverswhich receive a certain lookup message, the client can only estimate these values. Areasonable assignment is

q0 = 0.05, l0 = 100 m and lmax = 1 km.

If, after a certain time, no reply arrived, the client can broadcast another lookup requestusing higher values for l0 and lmax. When an LLS is found, the corresponding addresscan be cached for further resolution requests.

The example in fig. 6-7 assumes that the LLS can provide the semantic resolutionresult without further queries.

Fig. 6-7. Sequence diagram for lookup and service usage

qredirect

q0

ll0---- 1+------------- if l lmax≤

0 otherwise

=

72 Jörg Roth

After a number of requests, the LLS replies with an error. This can happen as the cli-ent moved out of the LLS’s area. As the location server is no longer responsible, itreplies with a redirect message, which the client can use for another resolutionrequest to another server. Consequently, the client now changes its LLS entry.

6.4 Caching

Caching addresses of LLSs is only one way to reduce network traffic. As a basic idea,clients store pairs of (key, value) of former resolution requests in a table. Before per-forming a new request over the network, the client first checks, if any key correspondsto the new request. If yes, the corresponding value is replied. To take into account thatdomains may change over time, each cache entry has a certain expiration time afterwhich a cache entry is removed.

Not surprisingly, caching the physically resolved locations is simple. Only a hashtable containing pairs of d.name and d.c is required. Caching the results of the semanticresolution is in contrast much more difficult. As a first problem, it is not reasonable touse p as a key for the cache as it is not likely to have exactly the same location p for asecond resolution.

Fig. 6-8 illustrates the second problem. A mobile user resides at location p and getsthe semantic location y.A. The user then follows a path to a location inside x.B. Anaive implementation would use (y.A) as the cache key. As long as the user residesin the dark grey area, the cache resolution produces the right result. However, whenentering the area inside B and being still in (y.A), he would get a cache hit and againthe result y.A. This is only partly true, as we additionally have to consider the secondarea B or x.B as a result.

The correct solution to produce cache entries is more complex. The dark grey area infig. 6-8 represents the area that should produce a cache hit. Let

♦(p) = {q ∈ P | sr(q) = sr(p)}

denote the area of same resolution results as p. The formula uses the abbreviation sr(p)as the result of the semanticResolution operation. Then we get the followingformula to compute a cache key:

♦(p)

Fig. 6-8. Cache example

e( )∆

e D: e∈ d0∼ e d0,=∨ p e( )∆∈

∩

\ f( )∆

f D: f∈ d0,∼ p f( )∆∉

∪

=


for an arbitrary domain d0 with d0.name ∈ sr(p). For the realization, the domain d0 ofthe semantic resolution algorithm (page 47 or page 63 respectively) is used. Note thatthe location model requires at least one domain that covers each conceivable location,thus a domain d0 exists. Further note that all involved domain areas can easily be col-lected by the semantic resolution algorithm, even when using compressed associations,thus the computation of ♦(p) does not lead to more network queries. Moreover, once adomain e or f is collected, the pairs (e.name, (e)) or (f.name, (f)) respectively canbe stored inside a second cache to build future ♦ areas.

In the example shown in fig. 6-8 we get the area ♦(p) by subtracting the areas ofx.A, B and x.B from (y.A) as y.A is the only result of the semantic resolution.

A more complex example is shown in fig. 6-9.

The semantic resolution chooses y.A as d0. First the intersection of (y.A) and (B)is built as both areas contain q. Then (x.A) and (x.B) are subtracted. The choicefor B as d0 leads to another computation ( (B) ∩ (y.A)) \ (A), but the result is thesame.


To show the correctness of the equation above we make two steps. We first assume thatsr(p) = {d1.name,..., dn.name}.

Step 1: to show ♦(p) ⊆ :

Let q be a location with q ∈ ♦(p), then sr(q) = {d1.name,..., dn.name}. As the inter-section loops over the areas of these di, q is inside the intersection. Further, q cannot

Fig. 6-9. Complex cache examples

e( )∆

e D: e∈ d0∼ e d0,=∨ p e( )∆∈

∩

\ f( )∆

f D: ∈ f d0,∼ p f( )∆∉

∪

74 Jörg Roth

be an element of one of the (f) as f ∉ {d1,..., dn}, thus q must be an element of the seton the right side.

Step 2: to show ⊆ ♦(p):

Let q be a location with q inside the set on the left side. For all di, thus q ∈ (di) anddi.name ∈ sr(q). Further q ∉ (f) for f ∉ {d1,..., dn}, thus f.name ∉ sr(q) for any other

domain f. Finally sr(q) = {d1.name,..., dn.name} and thus q ∈ ♦(p).

Cache Modes

It is necessary to compute ♦(p) effectively. First, the client gets all areas of resolvedlocations (which correspond to the variables e in the intersection). A server has now, inaddition, to reply the list of all areas, which are associated to d0, but which do not coverp (these domains correspond to the variables f in the union). It is easy to extend the res-olution algorithms to get the required areas.

A client can compute ♦(p) with the help of these areas and store (♦(p), sr(p)) in thecache. When resolving a new location q, it has to check whether q ∈ ♦(p) for all cacheentries and reply sr(p), when an entry is found. The current implementation simplyloops through all cache entries. This is efficient for some hundred entries, but moreefficient data structures based on e.g. quadtrees are conceivable.

This cache mode is called the complex cache mode. As an advantage of this cachemode, a mobile user can move inside a considerably large area without resolving thelocation over the network. There are, however, some disadvantages:

■ The intersection, union and difference operation to get ♦(p) has to be executed onthe client in the outbound mode. Even though the actual storage of areas is notdescribed yet, it is important to know that union and intersection are difficult opera-tions for weak clients.

■ The memory usage to store ♦(p) can be too high for small clients and a reasonableamount of cache entries.

■ It can be difficult for a client to check a cache hit, as it has to ask, if q ∈ ♦(p) for allcache entries.

While the first problem can be avoided using the inbound mode, the other problems aremore difficult to solve. As the complex cache mode may demand too much computa-tional power of weak clients, Nimbus offers a second cache mode, the simple cachemode.

The idea for the simple cache mode is to use a smaller area ♦’(p) ⊆ ♦(p) as thecache key. In the case of a cache hit using this area, the result is still correct. As a disad-vantage, the resolution requires more network traffic as ♦’(p) does not reflect all avail-able information about the area. It is reasonable to use an area ♦’(p) that

■ can easily be computed by a client,

■ requires a small amount of memory when it is stored in the cache and

■ allows to check quickly, if q ∈ ♦’(p).

e( )∆

e D: e∈ d0∼ e d0,=∨ p e( )∆∈

∩

\ f( )∆

f D: ∈ f d0,∼ p f( )∆∉

∪


The simple cache mode in the current implementation uses a circle around p with aradius r for ♦’(p), thus the cache stores ((p, r), sr(p)). Note that at this point only two-dimensional areas are considered, but the approach can be extended to three dimen-sions (see section 11.3.2 on page 154).

To store a representation of a circle, the cache needs a small amount of memory andthere is an easy check of containment. Finally, a mechanism is required to compute anr that fulfils the requirement stated above. The current realization uses the followingprocedure (fig. 6-10):

■ First compute the distance between p and the nearest point of all involved areas(the variables e as well as f in the expression).

■ Then use the minimum of the distances as r.

Note that the representation of areas and the realization of the respective geometricoperations are presented in chapter 11.

In fig. 6-10, the areas A, B and y.A are involved for the computation of ♦(q). Theminimum distance from q to any of the areas is the distance to (A), thus the ♦’(q)is the presented circle. Note that using the minimum distance avoids that the respectivecircle around q overlaps with any area, at the best touches a border, therefore,♦’(q) ⊆ ♦(q).

This procedure avoids the cost-intensive area operation, but computes reasonablevalues for r. The obvious disadvantage of the simple cache mode occurs near a borderbetween domains. Moving towards a border, r gets smaller, thus cache hits are moreand more unlikely, which results in frequent resolutions over the network. However,for weak clients this mechanism is a reasonable alternative to the complex cache mode.

Both cache modes have their advantages. Obviously the information cached in thecomplex mode is more precise as it completely defines the area of the same results. Inthe simple mode, a mobile client has to resolve more often over the network, but on theother hand this mode leads to an efficient cache implementation. To summarize: thesimple mode is suitable for small devices such as cell phones with reduced memorythat are not able to execute the required polygon operations of the complex mode. Adevice should use the complex mode whenever it is capable, as it reduces the networktraffic even more than the simple mode. It is important to note that each device canconfigure the suitable cache mode individually.

Fig. 6-10. Compute r in the simple cache mode

76 Jörg Roth

6.5 Performing Triggers

Some location-based applications have to supervise the user’s locations permanently.As an example, a car navigation application has to show the current position of the caron a map and recompute the route immediately, if the car leaves the suggested route.Other location-based applications are only interested in certain changes of the location.They should react to certain location-dependent triggers generated by the framework.With trigger services, application developers can use event-oriented application archi-tectures which avoid polling: an application registers certain methods to the systemwhich are called whenever a relevant event occurs. This approach is comparable to thecurrent approaches for applications which react to events generated by the user inter-face, e.g. key events, mouse movements. The Nimbus trigger services are a result ofgoal 2b (page 34).

To realize triggers it is necessary to decide, for which event types an application canregister and how the events are effectively generated at runtime. Nimbus generates thefollowing location-based events:

■ The mobile user enters or leaves a certain physical area (which is not necessarily adomain’s area).

■ The mobile user moves a certain distance from the last triggered location.

■ The set of resolved semantic locations is changed.

■ The mobile user enters or leaves a certain semantic location.

Nimbus allows configuring trigger events in an object-oriented manner: the applicationoffers a listener object with a certain method called in case of the event. The applica-tion registers this listener object and configures the conditions for the event (e.g. thesemantic location that should be observed). To illustrate the strength of triggers, wefirst look at a code sample. A program wants to detect, if the user moves to the city ofHagen:

while (true){ ResolvedPosition p=LSI.resolve(); for (int i=0;i<p.sempos.length;i++) if (p.sempos[i].endsWith("hagen.de")) { ShowMessage("Now I'm in Hagen!"); return; } try { Thread.sleep(1000); // Wait a second } catch (Exception e) {} // before checking again}

Every second, the program performs a resolve call, which requests a location fromthe positioning sensor and computes the semantic locations. If one of the semanticlocations belongs to hagen.de, the loop successfully ends.

One of the flaws of this code example is the sleep statements, which experienceddevelopers try to avoid for tasks like this. A more suitable code example uses triggers:


public class HagenListener implements SemanticPositionEnteredListener { static HagenListener() {LSI.addEventListener(this);} String getHotArea() {return "hagen.de";} void positionEntered() {ShowMessage("Now I'm in Hagen!");}}

Now, the main program just has to create an instance of the class HagenListener –the background task to generate the event is provided by the Nimbus runtime system.

Nimbus avoids resolution operations over the network as long as possible. Based onthe list of listeners and the current location, it decides whether to call a resolution oper-ation or not. If e.g. all listeners only wait for a change of the physical location, nosemantic resolution is required. If semantic resolution is unavoidable, the cache pre-sented in the last section significantly reduces the amount of queries over the network.

6.6 Summary

This chapter presented the Nimbus architecture with the focus on the service infra-structure and demonstrated in particular how to process the resolution operationsdefined by the location model in the distributed environment of mobile clients andlocation servers. Compared to the formal location model, the real infrastructure has toconsider network issues: in the formal model, requesting domain data is an arbitrarystep in the resolution algorithm, but in a real network a certain time may be needed toget these data.

The Nimbus infrastructure considers network issues with a number of concepts:first, servers store sets of domains, which avoid network traffic for locally availabledomains. This issue is formalized with the clustering approach, which controls themapping of domains to servers in an appropriate manner. As a second concept, theLocal Location Server (LLS) is introduced, which acts as the service end point for amobile user. As an LLS covers a local area, mobile users do not have to re-connect todifferent LLSs anytime they move. Two modes of access are introduced: the inboundand outbound mode. They allow balancing the load between the LLS and the mobileclient. A cache concept significantly reduces the amount of queries over the network.Two different cache modes help to tailor the resolution process according to the proper-ties of a mobile client. Finally, trigger services allow a developer to develop an applica-tion in an event-oriented manner.

78 Jörg Roth

7 Integrating Positioning Systems

After introducing the location model and the runtime infrastructure, we now havethe tools to address the primary Nimbus goal: providing access to rich positioninformation, while the actual positioning mechanisms are fully separated from theapplication. As a main concept to reach this goal, the Virtual Positioning System isintroduced. A location sensor model provides a general interface description ofpositioning systems and covers a huge variety of positioning techniques.

7.1 Introduction

An important goal of the Nimbus approach is to provide uniform location informationwhich is independent of the underlying positioning systems (goals 1a-d, page 34). Indetail:

■ Access to the positioning system should be hidden inside the Nimbus framework.

■ Location information should be generalized in terms of scope and type (see section3.1.1 on page 14).

■ Access to more than one positioning system should be considered, which includes ahandover between available systems during the movement.

■ For each position, the framework should provide both physical as well as semanticlocations, even though typical positioning systems only offer one type.

A way to reach this goal was already identified in goal 4b (page 35): the location sen-sor model. So, this chapter starts with the description of possible location sensor mod-els along with some platforms which provide so-called location services, i.e. serviceswhich separate the positioning from the location-aware application.

Nimbus uses a number of concepts to integrate positioning systems into the frame-work. The most important one is the Virtual Positioning System, which has a similarinterface as a real positioning system, but offers certain degrees of abstractions. Severalnested virtual positioning systems act as a positioning system with the desired proper-ties defined by the initial goals.

Considering the data of realistic positioning systems, we have to give up a simplifi-cation of the current semantic resolution algorithm: instead of considering a locationmeasurement as a single point in space, we have to look at a position as an area of pos-sible locations. Giving up this simplification, the resolution algorithm no longer gener-ates a list of semantic locations, but assigns a certain probability of residing at a certainsemantic location. Even though the resulting algorithm is significantly modified, exist-ing building blocks are reused.

7.2 Related Work

The presentation of related work is divided into two subsections. The first subsectiondescribes general location sensor models, the second presents research platforms forlocation services.

Integrating Positioning Systems 79

Models for Location Sensor Output

A typical domain for modelling location sensors is robotics. Mobile robots have todetermine their location with the help of sensors such as distance sensors, odometers,or visual sensors. The concept of sensor data fusion [25, 62, 177] is strongly related tolocation sensor models: to increase availability, coverage and accuracy, the output ofmultiple location sensors can be combined to a single output.

There are three major ways to model location sensor output (fig. 7-1): points, posi-tion probabilities and areas.

Points in Space

The simplest model of a location is a single point in space (fig. 7-1a). Ignoring accu-racy and uncertainty issues, a measurement could be described by a single coordinatesuch as N51°22.579/E7°29.615/169 m. Although it is very unlikely that the measuredand the true location are identical, many applications simply take the measured valuefor further processing without considering the measurement error. As some positioningsystems have a high accuracy, this approach is often suitable.

Having more than one of these points from multiple sensors, a method for fusionuses the weighted average as a result of a composite measuring. To promote moreaccurate sensors, the reciprocal value of the measurement variance can be used as aweight. This method only works properly, if the expectation value of every measuringcorresponds to the true location.

Probabilistic Models

More advanced approaches model location output by a statistical distribution of meas-urements. For two dimensions we get a probability distribution for a certain measure-ment as presented in fig. 7-1b. For a small grid element (e.g. of 10 m x 10 m), thedistribution expresses the probability for a user to reside in this grid element. In thiscontext we talk about the position probability of a mobile user. This expression is orig-inally introduced by particle physics (e.g. ’the position probability of an electron’).From the viewpoint of statistics, the term is not indisputable, as the user’s position is a

Fig. 7-1. Different models for location sensor output

80 Jörg Roth

fixed value, and in contrast to subatomic particles, not a random variable. This term hasnevertheless gained acceptance and leads to meaningful results [62, 182].

An important method is based on Bayes' rule for conditional probabilities: given astate s and a measurement m. A certain state s expresses that the mobile user resides ata certain position. A measurement m could be the output of a GPS receiver. If m ismeasured, the probability that the users resides at a position is

.

Here P(m|s) denotes the probability of a measurement m with a given position and thedevice-dependent distribution as explained with the GPS (section 3.2.2 on page 19).The probability of measuring P(m) is considered as a correction factor and can be cal-culated by adding the individual probabilities. P(s) indicates the probability before onehas received the information from the measurement.

In the case of multiple sensors, we can propagate the information of the individualmeasurements step by step. Starting with an initial probability P0(s) (which may be auniform distribution among all possible locations) and receiving the measurements mi,we get:

.

The Kalman Filter [81] is based on a similar idea. The original approach assumes a sin-gle sensor performing multiple measurements, but the Kalman filter can also be usedfor fusing multiple measurements of different sensors. The Kalman filter requires sen-sors with normally distributed measurements.

To process arbitrary distributions numerically, so-called Position Probability Grids[20] can be used. They divide the set of possible positions into a grid with small unitsizes and assign the position probability to every grid element. As a huge memoryspace is required to represent a larger area, the environment is usually reduced to anadequately small area (e.g. some rooms in a building). After the processing of all sen-sor data is finished according to Bayes' formula, the most probable position can bedetermined with a resolution of one grid element.

As a disadvantage of the Position Probability Grids, many grid elements contain asmall probability value, but need a huge amount of memory. So-called Particle Filtersmodel the position probability with the help of a set of weighted particles (point-likeindividual measurements) [43, 51], which require a low amount of memory. This meth-od processes the position probability similarly to Bayes. In contrast to the Kalman fil-ter, arbitrary probability distributions can be modelled – not only normal distributions.

Areas

As a last model for location output, areas could be used (fig. 7-1c) [94]. An areadescribes the set of possible user locations when a certain measurement is performed.In particular, COO-based location output (see section 3.1.2 on page 15) can easily bedescribed by areas.

As an example, we look at GSM cells in the city centre of Hagen (fig. 7-2). Duringan experiment conducted by the author, the cell IDs of 1000 locations in an area of 15

km2 were measured, which contains 27 GSM-900 cells.

P s m( )P m s( ) P s( )⋅

P m( )---------------------------------=

Pi s( ) P s mi( )P mi s( ) Pi 1– s( )⋅

P mi( )-------------------------------------------= =


Each point of measurement can be mapped to a specific cell. The cell borders are cre-ated by a Voronoi diagram. The area model is suitable to represent the locations as wecan easily specify whether a certain location belongs to a cell or not. In contrast, itwould be very difficult to assign a position probability to a location.

The area model could be viewed as a simple statistical representation where the areaborder separates two regions with a uniform distributed position probability – insidethe area the sum of probabilities is 1, outside it is 0. Often, positioning systems aredelivered without any detailed information about the probability distribution. To findout the actual distribution by measurements is very cost-intensive, so usually the distri-bution is simply estimated. In such cases, the area representation is a reasonable alter-native to the exact probability distribution. Using the area model to represent systemswith normal distributed location values is not optimal, but the region that covers 95%of the possible locations can be used for the area model without losing too much infor-mation.

Compared to detailed statistical models, areas are a simplification: first, the areadoes not identify a specific position with the highest position probability. Second, astrong border often cannot be sharply defined, as there is usually no most distant possi-ble location for a certain measurement. As an advantage, an area is a very compact rep-resentation of a location sensor output. In addition, this model leads to very efficientprocessing algorithms. This issue is picked up in section 7.3.1 (page 85).

Location Service Platforms

The goal of a number of research platforms is to hide the actual positioning task and toprovide a general location service.

Leonhardi and Kubach suggest a Universal Location Service [94]. Location sensoroutput is divided into cellular (e.g., from GSM positioning) and non-cellular locations(e.g., from GPS). Locations are represented as positions (points in space), areas (cir-cles or polygons) or masks (the outline of an arbitrary region). In case of GPS, areas aredefined by the region with 95% probability. As an important design decision, locationinformation is first passed to so-called Location Servers which a mobile client canquery (according to the tracking paradigm).

Fig. 7-2. GSM cells in Hagen

82 Jörg Roth

PoLoS [126] forms a general platform for location-based services. A componentcalled POS is responsible for the integration of positioning systems into the platform.Specific positioning systems are modelled using wrappers. Three wrappers exist: aGMLC wrapper for GSM/UMTS positioning, a WLAN wrapper for WLAN position-ing and a GPS Wrapper to access GPS receivers. PoLoS focuses on an infrastructure topass location information from the positioning system to the application or service.Even though the location can be requested by a uniform method call, no mechanism ispresented to ensure the uniformity of the location response.

Universal Location Framework (ULF) [56, 69] provides a layered approach with aso-called Location Stack to access multiple positioning systems. The layers are (frombottom to top): the sensors, measurements, fusion, arrangements, contextual fusion andactivities. Sensors contain the low-level hardware, e.g. GPS pseudo range measure-ments, pixel identification of cameras, or ultrasound time measurements. Measure-ments combine low-level sensor data to data objects describing the location includinguncertainty. The Fusion layer describes methods to fuse multiple location information.The Arrangements layer contains an engine for probabilistic reasoning about relation-ships between multiple objects (e.g. proximity, containment, or geometric formations).Contextual Fusion merges location data with other contextual information such as cal-endar data, emails or contact lists. Finally, Activities define semantic states, whichinclude location, time and other contextual information. ULF performs a sensor datafusion with particle filters.

7.3 Processing Location Data in Nimbus

An important goal of Nimbus was to separate the positioning systems from the remain-ing system (goal 1a, page 34). The location-aware application in particular should notdirectly deal with positioning system output. The reasons for a strong separation of thepositioning systems and the application are:

■ An application developer should concentrate on the actual application function andshould not struggle with location sensors, capturing protocols etc.

■ An application can use more than one positioning system to get a higher coverageand availability. An application that directly accesses all systems would be over-whelmed by multiple access mechanisms.

■ An application should be developed fully independently of the sensors. If, e.g., newpositioning systems are introduced in the future, an application should work withthese new systems without modification.

To achieve the strong separation, the concept of virtual positioning systems (VPS) isintroduced, as illustrated in fig. 7-3.

A real positioning system (fig. 7-3a) is modelled as a black box that produces a loca-tion output on demand and has the following interface:

Fig. 7-3. Real and virtual positioning systems


■ A requesting component generates a location request whenever it needs new loca-tion information.

■ The positioning system generates a new location in the respective format.

■ In addition, it provides properties containing meta information about the last loca-tion output as well as general information about the positioning system. Typicalproperty information is the accuracy of the measured locations.

At this point, the interface of the positioning system is only described informally. Thedata format of location and properties in particular is not exactly defined and system-dependent – a standardization of the respective formats follows in a later stage.

Note that some positioning systems provide only a subset of the interface connec-tions described above. Usual GPS receivers, e.g., permanently measure the locationand periodically send the current location to the output without an explicit locationrequest.

The Virtual Positioning Structure

The main idea of a virtual positioning system is to provide location output with higherquality (e.g., higher availability, greater coverage) and, at the same time, to preservethe general interface of location, properties and location request. Fig. 7-3b shows a vir-tual positioning system component. It contains one or more inner positioning systemsand an augmentation component. The augmentation component takes the location out-put of the inner systems and generates new location output with improved characteris-tics. Typical types of augmentations are:

■ hide details of inner systems, provide access functions and run a capturing protocol;

■ convert one type of location information into information with a richer meaning or astandardized format;

■ merge the output of several positioning systems into a single output.

The main benefit of the virtual positioning system is a well-defined interface. The soft-ware that has to deal with the capturing and processing of location data is usually com-plex. Once structured with the help of virtual positioning systems, software can bemaintained or modified more easily. Moreover, inner virtual positioning systems canbe exchanged without affecting the remaining system. This is useful when integratingnew mechanisms to augment location information in a later stage of the project. As afurther benefit, inner VPSs can be replaced by simulators whereas outer VPSs remainunmodified. This is useful for developing and testing a location-based application.

In principle, virtual positioning systems can be arbitrarily nested. Several combina-tions are conceivable which can even be established at runtime. Nimbus uses a fixedstructure that is a direct result of goals 1a-c (page 34). It contains the following aug-mentation components (from the innermost VPS to the outermost):

■ Access:Real positioning systems have similar characteristics as hardware components incurrent computer systems. They mainly have to be regarded as a black box with acertain interface. Similar to current operating systems, drivers access the real posi-tioning system. Ideally, drivers are bundled with the positioning systems and devel-oped by the positioning system manufacturer. The driver runs the accessmechanisms, e.g. in case of GPS receivers, the serial protocol to read out GPS data.

■ Mapping:The mapping function converts local location data into location data with a global

84 Jörg Roth

meaning. Typical indoor positioning systems provide locations that are only validinside the covered area. The mapping function maps these locations to globallyunique coordinates. In addition, semantic locations are transformed to the respectivephysical area. Sometimes, mapping cannot be performed solely by the driver, butneeds additional help of so-called mapping servers.

■ Selection & Collection:The application wants to have a single location measurement even though differentpositioning systems are available. For this, available location data are merged to asingle output using a collection component. As for some positioning measurementscosts (e.g. monetary costs, battery power) have to be considered, a selection compo-nent activates an appropriate subset of available positioning systems.

■ Resolution:As a final step, the semantic and physical resolution algorithms are used to provideboth physical and semantic location information. This output presents the mostenriched location information and is directly passed to the application.

Ideally the access to a positioning hardware is inside the innermost VPS as other com-ponents do not want to deal with the technical details of position capturing. A similarargument can be applied to the mapping component, which unifies the location andproperties values.

It is reasonable to perform the selection and collection in a third step, as the selec-tion should be based on globally unique locations. The resolution component requires asingle location as input and thus has to be performed as a final step. These considera-tions lead to the structure of nested VPSs as presented in fig. 7-4.

Before presenting the VPSs and the respective augmentation components in detail, wehave to start with a characterization of the real positioning systems and their output.

7.3.1 Modelling Locations

The semantic resolution algorithm is based on a significant simplification: positioningsystems provide a single point in space as location output, i.e. a location is presented asa point p ∈ P. That corresponds to the point definition of a location (see section 7.2 onpage 80). For many positioning systems in mobile scenarios this is not adequate:

■ Positioning systems based on cell of origin can only specify the location by the cellarea. There is no single point of location as all locations inside the cell are possiblelocations.

■ Similar information is provided by positioning systems that offer semantic locationoutput such as PalmSpot or the Cricket system (see sections 3.3.1 on page 24 and

Fig. 7-4. Virtual positioning systems in Nimbus


3.3.3 on page 27). Again, there is no single point, but an area of possible locationsdefined by a location output.

In principle, a probabilistic model could be used in these cases. But as described above,such models often assume a normal distribution of sensor values, which is not true inthe case of COO-based positioning systems. In addition, density functions may havevery different shapes. Thus, it is difficult to provide a single efficient mechanism topropagate this information. For caching reasons, a huge number of probability valueshave to be stored on a mobile client (contradiction to goal 3a on page 35). The numeri-cal approximation of the location probability and appropriate resolution operations forweak clients is subject of intensive future research.

As a solution, Nimbus uses the area model to describe location sensor output (seesection 7.2 on page 81). A specific location output provided by a positioning system ismodelled by an area A ⊂ P, where the user’s current location is anywhere inside A.From a strict point of view, the corresponding A to a measurement would often be verylarge and thus meaningless, as even accurate positioning systems sometimes producevery inaccurate measurements. To get a useful representation, the Nimbus sensormodel uses an area A which defines the area of most probable locations (e.g. a 95%probability) and not the area that definitely includes the current position. The definitionof A is system-dependent and primarily depends on the accuracy of the system. To givesome examples:

■ GPS: A is a circle around a measured location p using the 2dRMS (section 3.2.2 onpage 20) as the radius. This is a similar approach as described in [94].

■ PalmSpot: A is the area of a specific room from the building’s ground plan.

■ GSM: A is defined by the cell border. For more advanced GSM positioning tech-niques, areas are used as described in fig. 3-12 (page 29). E.g., using TimingAdvance, the area is defined by the 555 m distance steps.

Using this model, it is possible to express the accuracy acc of a location measurement.This is necessary in a later stage to select the most accurate location measurementwhenever two locations are available. Obviously, greater areas A lead to lower accura-cies acc. The relation between A and acc could be described in many ways; the details,however, do not significantly affect a comparison of two positioning systems. Theaccuracy has to be effectively determined at runtime for every measurement, thus acomputation should not be too complicated. According to similar formulas specifyingGPS accuracy, Nimbus uses the formula

where diameter(A) denotes the maximum distance of two points p1, p2 ∈ A. For areas Adescribing a circle, acc(A) is identical to the radius. Using GPS with A as describedabove, acc(A) is equal to 2dRMS.

As a last point it is necessary to discuss how an area A for a location measurement iseffectively represented. Details about area presentation are described in chapter 11. Atthis point it is important to know that Nimbus represents any area by a polygon. Non-polygonal areas (e.g. circles) are approximated by a sufficient number of straight lines.This representation allows the usage of well-known and efficient algorithms for allkinds of required area computation.

acc A( ) diameter A( )2

--------------------------------=

86 Jörg Roth

7.3.2 Accessing Positioning Systems (VPS 1)

The goal of the innermost virtual positioning system is to hide the specific details ofthe real positioning system and to run the respective capturing protocol to get a loca-tion measurement. To classify the location output in later stages, a set of predefinedproperty values is generated:

■ Dynamic properties describe the current location measurement.

■ Static properties describe the positioning system independently of the current meas-urement.

These properties are highly dependent on the positioning system used and cannot becomputed by an automatic mechanism. Nimbus deals with different positioning sys-tems in the same way as operating systems integrate different hardware components: ituses drivers with a strongly defined interface to separate device-dependent componentsfrom the remaining system (fig. 7-5).

Drivers entirely encapsulate the capturing mechanism. In addition to location data, cli-ent drivers provide information about the scope and type of location, thus the client canclassify the positioning system without manual configuration. A user can easily attachpositioning systems with their drivers at runtime.

The described mechanism requires the location information to be available at themobile client. In particular, the position driver runs on the mobile client. Tracking sys-tems such as Active Badge system [178], where location information is primarily avail-able at a sensor network, need to transfer the user’s location to the mobile client via awireless network. This is not a hard restriction and the corresponding communicationfunctions can be fully integrated in the positioning driver.

Even though the location system generates properties in its own format, the drivergenerates a standardized set of properties as presented in table 7-1. Note that theseproperties are generated in a predefined format, thus all subsequent processing stepscan directly interpret these values without further conversion.

Fig. 7-5. Uniform access with position drivers

Table 7-1. Location Properties

Property Type Values Example

Type static {physical, semantic} physical

Scope static {global, local} global

General Accuracy static x meters 20.0 m

Current Accuracy dynamic {x meters, notavailable} 23.5 m

Availability dynamic {available, notavailable} available


Of course, there are many more properties of location measurements conceivable, butthe listed values are sufficient for further processing by the framework. Driver devel-opers may generate more values which are simply passed through.

The properties type and scope are defined according to section 3.1.1 (page 14). Thegeneral accuracy is a system-dependent value that describes the average accuracy ofthe system, whereas the current accuracy describes the last measurement. This is onlypossible if the positioning system offers information about the accuracy. E.g., GPS usesthe satellite constellation to compute the current accuracy of the last measure location.If the positioning system does not offer any accuracy values or if a location is not avail-able, the current accuracy is set to notavailable.

The availability value finally specifies, if location information is currently availableor not. Three types of failures can be distinguished and are indicated by a subentry ofthe availability property:

■ the positioning system is working, but the current position is not covered, e.g. GPSsatellite signals cannot be received at this location;

■ the positioning system is not working properly, e.g. the GPS receiver is currentlystarting up and updates its almanac;

■ the connection to the positioning system fails, e.g. the serial connection to the GPSreceiver cannot be established.

Nimbus positioning drivers are dynamically loadable components that fulfil a certainprogramming interface (in our case a Java interface). The driver interface includes:

■ a method to initiate a location measurement,

■ a method to get the last location output,

■ methods to get the property values described above,

■ methods to configure the driver and the positioning system,

■ methods to open a system-specific configuration window and

■ methods to persistently read and write configuration data.

With the help of configuration methods, an application can set system specific values,e.g. the serial port to access a GPS receiver. Similar to driver configuration windows inoperating systems (e.g. the Windows XP "settings" dialogue to configure the videodevice) a driver-specific configuration window allows the user to configure the posi-tioning system. Finally, an application can read out the driver configuration, store it todisk and restore it at the next start up.

The methods to get the properties generate values in a predefined format. Table 7-2shows the location output format according to its scope and type.

Table 7-2. Location output format generated by drivers

type/scope global local

physical a string representing latitude, longitude and altitude based on the WGS 84 ellipsoid represented in NMEA 0183 format [112]

system-specific string

semantic a domain name according to section 5.3.1 (page 43)

system-specific string

88 Jörg Roth

Positioning systems with local scope generate values in local coordinate systems in asystem-specific format. To support different local formats with a single get method, allthe location output generated by the driver is represented as a string, thus it is possibleto support all current and future location output formats.

7.3.3 Mapping Locations (VPS 2)

Usually, an application is not interested in location output with only a local meaning. Inaddition, the semantic resolution algorithm requires domains with globally valid loca-tions. Thus, in the next step, location information with a local scope has to be con-verted into a global format. As a second function of this step, a point-like locationmeasurement is converted to an appropriate area A according to the model described insection 7.3.1 (page 85).

Fig. 7-6 shows the corresponding VPS, called VPS 2. To produce a globally valid areaA we have to consider the following cases, depending on scope and type produced bythe inner VPS.

■ Global scope, physical type:This is the simplest combination as the measured location already has a globallyvalid representation. To get the area A for a measured location p the VPS has to gen-erate an area according to the accuracy provided by the properties. Ideally, the cur-rent accuracy is available. If not, the general accuracy value is used.

■ Global scope, semantic type:Some positioning systems generate semantic location output. If the positioning sys-tem uses the Nimbus name space, A can directly be computed by the physical reso-lution algorithm 6-2 (page 63). For this, the mapping component needs help from alocation server, but can benefit from caching.

■ Local scope, semantic or physical type:Such positioning systems require an individual mapping mechanism.

Note that inside this VPS all semantic locations (global or local) are converted to aphysical area. Even though a further component (see section 7.3.5 on page 96) willfinally produce semantic location output, semantic location information at this stage isnot used. This is why the semantic output of the positioning system will not use thesame structure as the hierarchies used for semantic resolution.

Fig. 7-6. Generate uniform location output


The case of a local scope is the most crucial one. While the first two cases can behandled with an automatic mechanism included into the Nimbus framework, the lastcase needs a system-specific component to perform the mapping. Similar to the posi-tion driver, a so-called mapping driver is used to convert local into global locations.Often, the mapping cannot be performed by the mobile client as external informationabout the positioning system is needed (otherwise, the position driver could havedirectly generated global locations). Thus, a new kind of server is introduced – themapping server. The mapping server is responsible for a specific location system, e.g.an indoor positioning system with certain coverage. Whenever the positioning systemgenerates a locally valid location, the mapping server maps it to a globally valid loca-tion. As the mapping server knows the specific local coordinate system of the position-ing system used, the mapping function is usually simple.

Looking up the corresponding mapping server for a certain location and positioningsystem (called the Local Mapping Server, LMS) works similar to a LLS lookup pre-sented in section 6.3.4 (page 66). The lookup with the help of the positioning system isa suitable mechanism. An indoor positioning system could e.g. transmit the networkaddress of the LMS via the payload of the positioning signal.

In principle, a single mapping server could host several mapping drivers and thusprovide the mapping function for different positioning systems. As the mapping drivercan contain arbitrary code, even complex mapping schemes can be developed. Notethat VPS 2 is the innermost VPS that is able to produce output and properties, whichare completely independent of the underlying real positioning system.

The integration of any new positioning system requires

■ to install a positioning driver on the mobile client

■ and, if the positioning system generates only locally valid locations, to set up a map-ping server and to install the mapping driver.

Any other mapping included in VPS 2 and all functions of remaining VPSs are entirelyoffered by the Nimbus framework and do not need any further system-dependent com-ponents.

7.3.4 Handling of Several Positioning Systems (VPS 3)

Currently, many projects in the area of location-based services or applications assume asingle positioning system. Future mobile end-user devices will probably have access toseveral positioning systems. In a typical future scenario, a user has access to

■ satellite navigation via GPS,

■ indoor positioning systems which cover some buildings and

■ positioning via a cell phone network, whenever more accurate systems fail.

Consistently, a mobile client hosts a number of VPS 2 components producing multiplelocation and property outputs. Applications, however, do not want to deal with variouspositioning systems and require a single location. This requirement leads to a furtherVPS. There are two mechanisms to deal with several positioning systems:

■ a subset of all positioning systems currently connected to the mobile device is acti-vated (selection component), and

■ the location information of all activated positioning systems that currently provideoutput is merged into a single output (collection component).

The architecture of the VPS 3 containing these mechanisms is presented in fig. 7-7.

90 Jörg Roth

Collection

A simple approach to merge output of different location sensors is to simply choose themost accurate one. In many cases this approach is effective. Whenever an accurate sys-tem is available, less accurate systems do not contribute substantial information. As anexample we consider two positioning systems: the Cricket indoor system (accuracyapprox. 0.3 m) and GSM positioning using cell IDs (accuracy some hundreds meter incities). The latter system does not provide any useful information as long as the Cricketsystem is available. Collecting the most accurate system for output requires only lowcomputational resources and is thus a suitable approach for weak clients.

To describe this approach more formally, we identify the connected positioning sys-tems by a number i ∈ {1,..., s}. Let Availabilityi denote the availability state and Ai thesensor output of the positioning system i. Let further avail denote the set of availablesystems, i.e. avail = {i | Availabilityi = available}. Note that systems can only beavailable, when they are selected by the selection component (see below). The simplecollection approach can be described by the following equations for collected outputAcoll, Availabilitycoll and CurrentAccuracycoll:

■

■

■

Fig. 7-7. Selection and collection of location data

Acoll

Ai for Ai with acc Ai( ) min acc Aj( )( )j avail∈

= if avail { }≠

{ } otherwise

=

Availabilitycollavailable if Acoll { }≠

notavailable otherwise

=

CurrentAccurracycoll

acc Acoll( ) if Acoll { }≠

notavailable otherwise

=


An improved collection component uses sensor data fusion. Whenever two or morepositioning systems provide similar accuracy, the fusion can significantly improve theaccuracy. According to the sensor model, a user location has to be inside each Ai fori ∈ avail. The intersection of all Ai describes all potential user locations. Therefore, animproved collection component can compute the location area as follows:

■

Availabilityfusion and CurrentAccuracyfusion are computed in the same way as Availa-bilitycoll and CurrentAccuracycoll respectively. Note that even though different systemsare available, Afusion could be the empty set when the Ai do not overlap. This usuallyindicates a measurement error, or at least an undesired inaccurate measurement. In anycase, the collected output is not useful and thus the availability is set to notavaila-ble.

Note that the improved collection component requires that client is able to computethe intersection of areas. Weak client issues related to geometric computations are dis-cussed in section 11.3.1 (page 150).

Selection

In principle, the selection component can activate all positioning systems that are cur-rently connected to the mobile system. In this case, all available location data are col-lected. This simple approach is appropriate if positioning is free of charge.Unfortunately, the user is sometimes charged for positioning services, for examplewhen mobile phone networks are involved:

■ The so-called Assisted GPS transmits almanac data (see section 3.2.1 on page 17)via the mobile phone network to improve GPS positioning.

■ Using the Timing Advance value to detect the distance to the next base station (seesection 3.4.1 on page 30) requires an established mobile phone connection whichleads to costs.

■ Some systems for Differential GPS (see section 3.2.3 on page 21) transmit correc-tion values via SMS charged to the user.

■ For some services of the new GALILEO satellite navigation system (see section3.2.4 on page 22) users will be charged.

For mobile systems also non-monetary costs such as power consumption have to beconsidered. A selection component can for example deactivate an unused positioningsystem to save battery power.

The Nimbus selection algorithm assumes that all relevant costs are fixed for a cer-tain time. The cost c for a single measurement usually is a vector of separate costs, e.g.c = (cmoney, cpower). Even though the selection algorithm can process such costs, thedescription considers the costs as scalar values. In the following, ci denotes the cost fora single measurement of positioning system i.

Afusion

Ai

i avail∈∩ if avail { }≠

{ } otherwiese

=

92 Jörg Roth

As a major problem, the selection cannot determine, if a positioning system pro-duces output before the system is activated. E.g. the selection can decide to activateGPS (which drains the battery), but the GPS receiver does not receive any satellites. Asthe availability status may undesirably change after a selection, the algorithm can onlytry to select the most appropriate systems. The following algorithm makes a selectionbased on former measurements. It maximizes the accuracy and availability, but theexpected positioning costs do not to exceed a certain cost limit. The algorithm can becontrolled by two variables. Variable m specifies a cost limit explained below. Every nmeasurements, all available positioning systems are activated to select a new subset ofavailable systems. The rest of the time, only the subset of systems is activated.

Algorithm 7-1: Select Positioning Systems

selectPos(m, n)loop { wait for a location request activate all positioning systems and perform a collection choose a sel ⊆ avail with • average acc(Ai) is minimal, i ∈ sel

• and Σ ci ≤ m, i ∈ sel // see below

for j=1 to n-1 { wait for a location request activate the systems in sel and perform a collection if avail={} restart loop }}

For vectors of costs ci = (ci1,..., civ) the parameter m has to be a vector (m1,..., mv). The

condition marked by is then replaced by

Even though the following consideration can also be applied to vectors of costs, we usescalar costs for clarity.

The problem to compute a set sel inside the loop is similar to the 0/1 knapsack prob-lem: from a set of items some have to be carried in a knapsack. Each item has a weightand a profit. The objective is to choose the set of items that fits in the knapsack andmaximizes the profit. This optimization problem is known to be NP-complete, but theselection component has to deal with a small number of positioning systems (e.g. lessthan 10). Therefore, the selection can simply iterate through all possible combinationswithout consuming noticeable time.

Since every n measurements all systems are activated, the actual costs are higherthan the value m passed to the selection component. For a higher number of measure-ments, the average cost cavg can be approximated using the formula

cij

i sel∈∑

mj for j 1,..., v{ }∈≤


, where .

For n = 1 the algorithm selects all systems, thus behaves as the simple approach whichdoes not consider any positioning costs.

The actual costs can vary from cavg for the following reasons:

■ The costs for the selected systems can be lower as usually a specific selection doesnot exactly reach m.

■ If, after activating all systems, too little positioning systems are available, the costslimit may not be exploited even though sel = avail.

■ The inner loop may not iterate n-1 times when all selected positioning systembecome unavailable. In this case the costs for the whole iteration are higher thanexpected.

Nevertheless, the formula gives an adequate approximation for the expected costs andis verified by the following simulation. The simulation was conducted to investigatethe characteristics of the selection algorithm. A simulated mobile user walks throughan environment that is covered by six positioning systems. As the user moves to certainregions, the subset of available positioning systems changes. Table 7-3 presents thepositioning system settings used for the simulation.

GSM-based positioning and UL-TOA are available indoor and outdoor. GPS is onlyavailable outdoor. A WLAN-based system is installed on a campus (outdoor andindoor). Two indoor positioning systems cover two indoor areas. The simulated mobileuser walks from an area outside the campus, across the campus and finally reaches thetwo indoor areas.

The simulation used realistic settings for the current accuracy according to chapter3. The current accuracy is computed from the general accuracy using a random varia-tion. The simulation assumes that every VPS 2 can measure its current accuracy. Thecollection component uses the simple collection mechanism presented above.

The simulation assumes an abstract cost of 1 unit per measurement. The simulatedmobile system requests 150 measurements during the movement.

Fig. 7-8 presents the results, when all systems are permanently activated (n = 1). Asnot all systems are permanently available, the curves have certain gaps.

Table 7-3. Positioning system settings used for the simulation

Positioning system Covered area

Availability in the

covered areaTotal

AvailabilityCurrent

AccuracyGPS City and Campus 75% 50% 10-25m

GSM positioning Everywhere 95% 95% 150-400 m

UL-TOA Everywhere 70% 70% 120-150 m

Nibble Campus and Indoor 85% 57% 3-5 m

PalmSpot Indoor1 100% 20% 1-3 m

Cricket Indoor2 100% 13% 20-40 cm

cavg

m n 1–( ) cmax+⋅n

-------------------------------------------≈ cmaxci

i 1,..., s{ }∈∑=

94 Jörg Roth

Fig. 7-8. Simulation of the selection component (n=1)

Fig. 7-9. Simulation of the selection component (m=1, n=5)

Fig. 7-10. Simulation of the selection component (m=3, n=10)


The selection algorithm was tested with the values n ∈ {1, 2, 3, 4} and m ∈ {1, 3, 5,10}. Fig. 7-9 and fig. 7-10 exemplarily show results for some settings. Note that onlyaccuracy values of activated systems are displayed.

The selection component indirectly provides a handover mechanism (goal 1c,page 34): as always at least one available system is selected after n requests, a hando-ver to the most appropriate positioning system is performed automatically. In both fig-ures we can see the handover between outdoor to indoor systems and between the twoindoor systems.

In fig. 7-9 the algorithm selects one system. This setting is cost effective, but theaverage availability is only 90%. The setting in fig. 7-10, in contrast, leads to a highavailability of 100%, but produce costs of 3.3 units. Fig. 7-11 shows the results for allsettings in the simulation. In this simulation, the algorithm achieves adequate accuracyand availability values for m ≥ 3 even for higher values of n. As the optimal settingsdepend on the application requirements and cost model, the values for m and n are con-trollable by the application.

Even though the presented selection component effectively limits the costs andachieves high accuracy and availability, other algorithms are conceivable. For the Nim-bus design, it is not intended to make a final decision on how the corresponding VPSactually works. It is important to note that it is possible and intended to introduce newVPSs and simply replace the existing one. As an example, the selection could beimproved using knowledge about the positioning systems. If e.g. consecutive GPSmeasurements indicate a speed of 100 km/h, it is likely to be outdoor. In this case, theselection component should not try to activate any indoor system. The respectiveimprovements are part of future work.

7.3.5 Resolving Locations (VPS 4)

As a final step to enrich the location output, semantic location information is addedusing the semantic resolution. The physical location can be passed directly to the appli-cation. The corresponding VPS 4 is presented in fig. 7-12.

Fig. 7-11. Evaluation of the selection algorithm

n=1 n=3 n=5 n=10 n=1 n=3 n=5 n=10 n=1 n=3 n=5 n=10

m=1 23.6 63.6 70.7 90.9 m=1 1.00 0.90 0.90 0.91 m=1 6.0 2.8 2.1 1.8

m=2 23.6 30.5 39.5 44.1 m=2 1.00 0.99 0.98 0.99 m=2 6.0 3.3 2.8 2.4

m=3 23.6 27.7 27.6 27.2 m=3 1.00 1.00 1.00 1.00 m=3 6.0 3.9 3.5 3.3

m=4 23.6 25.0 26.8 27.2 m=4 1.00 1.00 1.00 1.00 m=4 6.0 4.2 3.8 3.6

96 Jörg Roth

The semantic resolution algorithm 6-3 (page 63) processes single points, not areas,therefore the algorithm has to be extended. As we cannot determine the user’s locationexactly, we only can compute a probability for a user to be inside a specific domain(fig. 7-13).

The only definite statement about the user’s location is that he or she resides in thedomain y.A. For other domains we can only declare degrees of residing in thesedomains. E.g. there is a 50% probability that the user is located in domain B when thepositioning system provides the area A as the current location. The probability pr(A, d)that the actual location is located in a domain d when measuring a location area A is

where vol denotes the size of the surface or volume respectively. The formula assumesa uniform distribution of possible locations over A as requested by the location sensormodel.

In principle, we are also interested in an alternative probability

expressing the probability to reside in the area of d. pr (A, d) is closer to the inten-tion of the point variation of algorithm 6-3, as areas of subdomains are not counted inhigher-level domains. Using pr (A, d) on the other hand, there may be no domain with100% probability, even though the location is enclosed in a domain. E.g., in fig. 7-13

Fig. 7-12. Resolving locations

Fig. 7-13. Location example

pr A d,( ) vol A d.c∩( )vol A( )

--------------------------------=

pr∆ A d,( ) vol A ∆ d( )∩( )vol A( )

------------------------------------=


there is no domain with pr (A, d) = 100%. In contrast, pr(A, y.A) = 100% is a usefulinformation. In the next section, a modification of the algorithm is presented that com-putes probability values for both variations.

7.3.6 Extending the Semantic Resolution Algorithm

If the location is modelled as an area rather than as a single point in space, the semanticresolution is more difficult to perform. Using a positioning system that has a very highaccuracy, the point variation of the resolution algorithm (page 63) can still be usedwithout losing too much information. If the location can only be described with a largerarea (e.g. a GSM cell), it is not reasonable to use this algorithm anymore. A locationcannot only be completely inside a domain, but may intersect a border of a domain. So,the goal is to find an extension of the semantic resolution algorithm with the followingproperty:

Given an area A, produce a list (d.name, pr(A, d)) with pr(A, d)>0.

Algorithm 7-2 outlines the corresponding algorithm.

Algorithm 7-2: Semantic Resolution (Location Areas)

semanticResolution(A) → table of (name, ratio){ initialize hash table nameToRatio() while A ≠ {} { choose a p ∈ A // any p in A will do n ← semanticResolution(p) add names of superior domains to n // to get pr, // remove to get pr

r ← vol(A ∩ ♦(p)) / vol(A) for each name ∈ n add or assign r to nameToRatio(name) A ← A \ ♦(p) } return nameToRatio}

This algorithm re-uses the point variation of the semantic resolution algorithm andworks as follows:

■ It starts with a complete area A and performs a semantic resolution for an arbitrarypoint p inside A with the help of the existing point variation of the algorithm.

■ We get a partial result. As we chose an arbitrary point p, there may be additionalregions of A that lead to other results, but the area around p that leads to the sameresult can be removed from A. This area is obviously the area ♦(p) introduced insection 6.4 (page 73).

If the new A is not empty, the algorithm chooses a new point p and proceeds in thesame way. Inside the loop, the algorithm adds the respective quota of the collectedareas to the final result.

98 Jörg Roth

Note that this algorithm computes values pr(A, d), but we can easily modify thealgorithm to get a list of the pr (A, d). We simply have to remove the statement , asthen only the resolved domains and not any superior domains are considered.


At this point we want to demonstrate that this algorithm works correctly. The area A ispartitioned into a finite number of ♦ areas, thus the while loop terminates after a cer-tain number of iterations. As the number of names that are a result of the semantic res-olution is also finite, the for loop terminates as well.

Using the variation that uses pr (A, d), we have to show that after the algorithm ter-minates, the value of nameToRatio(d) = pr (A, d). An area A is partitioned into{♦(pi)} where i denotes the number of iterations in the main loop of the algorithm. Asany point pi ∈ ♦(pi) leads to the same set ♦(pi), the actual choice of pi does not affectthe set {♦(pi)}. For any point pi ∈ ♦(pi) the result of sr(pi) is identical (see definitionof the ♦ area on page 73). For all pi with d ∈ sr(pi) an ri is added to nameToRatio(d)with

.

Due to the definition of the ♦ area, (d) is partitioned into {♦(pi) | d ∈ sr(pi)}, thus

nameToRatio(d) = = = pr (A, d).

Example

Fig. 7-14 shows an example. The figure assumes that the algorithm chooses p as indi-cated by the numbers 1 to 7. After seven steps, A is fully represented and the algorithmterminates.

Fig. 7-14. Extended semantic resolution example

ri

vol A ♦∩ pi( )( )vol A( )

--------------------------------------=

vol A ♦ pi( )∩( )vol A( )

--------------------------------------

pi : d sr pi( )∈

∑ vol A ∆ d( )∩( )vol A( )

------------------------------------


Table 7-4 shows the steps of the algorithm. The right part of the table shows the accu-mulated ratios where bold printed values indicate changes. The values in the last rowshow the final results.

Efficiency of the Algorithm

Some words about the efficiency of algorithm 7-2 are now necessary. One could arguethat the steps shown above lead to a considerably long execution where many transac-tions over the network are required. The efficiency of this algorithm can be motivatedas follows:

■ Often, the area A is small compared to the size of the domains (think of GPS posi-tioning). In many cases, the result of a single iteration of algorithm 7-2 fully coversA. The smaller A is, i.e. the more accurate a positioning system is, the more thebehaviour of algorithm 7-2 converges to the point variation of the semantic resolu-tion.

■ Once resolved, a certain movement of A is allowed without any further networktransactions. E.g. in fig. 7-15, A can be moved from to location without anyresolution queries over the network. This is because the same ♦ areas are involvedand the algorithm has only to adapt the ratio values.

■ When A leaves the area that can be fully processed by cached areas ( ), often onlya further query is required and then the resolution can again be fully processed bycached areas.

Note that even though a resolution over the network is required, the point variation ofthe semantic resolution often only requires a single query as motivated in section 5.3.4(page 48) and 6.4 (page 73). A simulation presented in section 12.4 (page 174) con-firms these considerations.

As an interesting simplification, the algorithm could list only the domains wherepr(A, d) = 100%, i.e. the domains in which users definitely reside. In this case, a sim-plification is possible: domains that are not considered in a certain step can never reachthe 100%, thus can be directly filtered out. In table 7-4, after step 1, the domains x.B,y.B and B can no longer be candidates. After step 6, the last candidate A can be elimi-nated and the algorithm then terminates – this time without returning any 100%domains.

Table 7-4. Extended semantic resolution example execution

p vol(A∩♦(p))vol(A)

sr(p) a.y.A y.A A x.B y.B B

1 5% a.y.A 5% 5% 5% 0% 0% 0%

2 5% y.A 5% 10% 10% 0% 0% 0%

3 20% y.A,B 5% 30% 30% 0% 0% 20%

4 35% y.A,x.B 5% 65% 65% 35% 0% 55%

5 15% A, B 5% 65% 80% 35% 0% 70%

6 15% B 5% 65% 80% 35% 0% 85%

7 5% y.B 5% 65% 80% 35% 5% 90%

100 Jörg Roth

7.3.7 Simulating Positioning Systems

It can be a difficult task to test location-based applications when a mobile user actuallyhas to go to specific locations. Of course, final tests have to be done with real position-ing systems, but for first tests, it would be more convenient to use a simulation tool.Some positioning devices contain a simulation facility. E.g. several GPS receivers canbe put into simulation mode, in which an example location output is continuously gen-erated. It is, however, not possible to conduct complex simulation tasks with this facil-ity.

The approach of virtual positioning systems significantly simplifies the integrationof a more complex simulation tool. At the level of VPS 1, a simulation driver can beused instead of a driver accessing a real positioning system (fig. 7-16a).

The locations are generated by a tool instead of a real positioning system. As the driverinterface is identical at VPS level, other components cannot see any differences.

A map tool can be used to conveniently produce a sequence of locations of, e.g. apedestrian or a car. With a real map of the environment as a background, a user canspecify a path consisting of a number of lines and speed values (fig. 7-16b). When thesimulator is started, a virtual mobile user walks along the specified path with the corre-sponding speed.

Fig. 7-15. Movement of area A

Fig. 7-16. The positioning system simulator


7.4 Proximity Resolution

The semantic resolution returns information about the current location. For many loca-tion-based services information about the proximity is needed. A tourist could e.g. askfor hotels or restaurants in the nearby area. The required mechanism is called the prox-imity resolution.

A First Proximity Approach

A first realization of the proximity resolution was developed by Hadig [59]. Besidesthe relation and the association, this approach needs a third link – the neighbourhood.Before presenting the final approach, the first proximity resolution based on neigh-bourhood links is briefly described.

If a mobile node leaves a domain d1 and its semantic location changes to a differentdomain d2, then d2 is called a neighbour of d1. This means that either the areas of thetwo domains overlap, but d1 does not contain d2, or the areas have a part of the bound-ary in common. Neighbourhood links are unidirectional. The figure indicates the direc-tion of links by a dot: if d1 refers to a neighbour d2, the dot is shown at the linetermination of d2.

Two domains are either related or associated if they overlap. In the case of an asso-ciation, a neighbourhood link is not necessary as this represent the same information. Ifthe domains are related, the subdomain is located inside the area of the master domain;the subdomain can then have a neighbourhood link to the master domain as the mastercovers the entire border of the subdomain.

If several neighbours cover an overlapping part of the domain border, it is sufficientto link only one neighbour as other neighbours can be found by following the associa-tion and relation links of the neighbour.

For the example in fig. 7-17, the domain a.B has the neighbours B, b.B and c.B.As B covers the complete boundary, only this neighbourhood link is necessary. In thecase of b.B, a neighbourhood link to a.B and c.B is necessary.

The basic idea of the first proximity algorithm is to search all local domains andtheir neighbours in order to find semantic domains that answer the question. For this,the algorithm traverses the logical network, collects result domains and iterativelyincludes connected domains until a maximum search radius is reached. The algorithmguarantees to visit each domain only once, but has some disadvantages: a third logical

Fig. 7-17. Hierarchies with neighbourhood links

102 Jörg Roth

link has to be maintained and the algorithm assumes circular areas in which domainsare looked up (called the proximity areas).

The Final Proximity Algorithm

The final proximity resolution algorithm is based on the same idea as the area resolu-tion algorithm 7-2 (page 98) and does not need any further link between domains. Itcan be used both for point-like and area locations. The proximity areas, in the follow-ing denoted X, are allowed to have arbitrary shapes. Some examples of areas X are:

■ the set of locations that are within a certain distance to the measured location A(called the buffer of A);

■ d.c of the city or city centre domain, in which the user currently resides;

■ a buffer around the street the user currently drives on, covering the next 5 km in thedriving direction.

The actual creation of X is highly application dependent. In principle, X does not neces-sarily have to enclose A. An LLS may define certain restrictions to reduce the load,e.g., it could limit the size and location of X when executing a proximity resolution ininbound mode. Algorithm 7-3 outlines the proximity resolution algorithm.

Algorithm 7-3: Proximity Resolution

proximityResolution(A, X) → table of (name, distance){ initialize hash table nameToDist() while X ≠ {} { choose a p ∈ X n ← semanticResolution(p) dist ← distance(♦(p), A) for each name ∈ n if nameToDist(name) not set or dist<nameToDist(name) assign dist to nameToDist(name) X ← X \ ♦(p) } return nameToDist}

In contrast to the area resolution, an application is interested in the distance from theactual location to the resolved domain. For this, the function distance computes theminimum distance between two points in the argument areas.

Note that the algorithm collects domains that overlap with X. They do not necessar-ily have to be completely inside X. This is done on purpose. Asking, e.g. for a cityinside a radius of 10 km, a city which only scrapes the circle is also a useful response.An application can define further criteria to decide whether a domain is a solution: itcould request the area of the resolved domain and could only collect domains inside acertain (sub-) hierarchy. E.g. if an application is only interested in lakes in the nearbyarea, it only collects domains inside lakes.geo.


7.5 Summary

In this chapter, an approach to deal with different kinds of positioning systems is pre-sented. Virtual positioning systems model all stages of abstractions from raw locationoutput generated by real positioning systems up to high-level location output contain-ing physical areas and semantic locations. The concept of drivers in particular simpli-fies the integration of new positioning systems in the future. Simulated positioningsystems providing realistic testing scenarios are used during the application develop-ment phase.

Often, location output is considered as a single point in space. In reality, thisassumption leads to misleading results, as many positioning systems only provide inac-curate location information. A location sensor model presented in this chapteraddressed this issue. An adaptation of the semantic resolution algorithm considers theinaccurate location measurement and adds probability information to the list of seman-tic locations. The area variation of the semantic resolution algorithm provides an alter-ative to the point variation, whenever a positioning system is only able to expresslocations with the help of greater areas (e.g., in current mobile phone systems). When auser is interested in domains close to the current location, he or she can use the proxim-ity resolution.

104 Jörg Roth

8 Geocasting

Geocast mechanisms allow a sender to transmit network packets to receiversresiding in a certain geographical region. Geocast forms the basis for a number oflocation-based services, such as announcement services, advertisement services orfriend finders. This chapter introduces the notion of semantic geocast, where a tar-get area is not a physical area, but a semantic location. A sender can broadcastmessages to, e.g., a city centre or a specific building, without knowing the physi-cal coordinates. The Nimbus framework offers an ideal platform for geocastingservices. As it already forms a logical network of location servers, it provides anideal transport infrastructure for geocast messages. The number of domains maybe high, thus it is necessary to consider scalability and stability issues. Evaluationsshow the effectiveness of the Nimbus geocast approach.

8.1 Introduction

Geocasting is a powerful approach to combine position data with a network infrastruc-ture. Like traditional multicast, geocast transmits a network packet to a number ofreceivers with a single send operation. In contrast to multicast, the target is a certaingeographical region. This chapter introduces the notion of semantic geocast, where thetarget address is not defined by a physical area (specified by, e.g., a polygon), but by asemantic location. With semantic geocast, an application can, e.g., easily send a net-work package to all students at a campus. Using semantic geocast, users and applica-tions do not have to deal with raw physical coordinates, but can use symbolic locationnames to describe the target.

Geocast is one of the services according to goal 2b (page 34). It is an ideal basicfunction for a number of location-based applications, especially of the categories dis-covering other users and messaging and announcement services (see table 2-2 onpage 9). To give some examples:

■ Broadcast warning: Governmental organizations or rescue services can send warn-ing messages to a region with, e.g., bad weather conditions. People living at theshore of a river can be informed about an expected flooding. A fire alarm messagecan be sent to all mobile phones inside a burning building.

■ Local advertisements: Supermarkets can send advertisement messages to all clientsin the nearby area. People passing by a shop window can receive information aboutnew prices and special offers.

■ Controlling devices: Property management can send a request to all heating systemsinside a specific building to reset their utility meters and go into summertime mode.This of course requires authentication mechanisms (see section 9.4 on page 130).

■ Friend finders: Users can send a lookup-message to all people at a certain location(e.g. a canteen, a shopping mall) to find friends who currently reside at this location.

To realize such applications efficiently, Nimbus offers geocast services. Developerscan send network messages to a specific location with only a few lines of code.

Geocasting 105

8.2 Related Work

Geocast extends traditional networks by services using geographical target addresses.There exist different architectures to realize geocast.

Geocast by Physical Broadcast

The simplest technique to realize geocast capabilities is to make use of the specialproperties of wireless networks, which are usually based on radio. As the energy of aradio signal decreases with the distance to the sender (with the square in theory,approximately with the power of four in real environments), signals can only bedecoded inside a certain range. Thus, the physical broadcast of radio signals is a simplekind of geocast. Some projects use this approach. The tourist guide Guide [23], e.g.,uses WLAN cells to distribute announcements to tourists residing at a certain location.The so-called Flirt Getty device [50] distributes the user’s "flirt" profile (gender,favourite hobbies) to other devices within a distance of 15 m. If a device detects a com-patible profile, it triggers the user. As a third example, the GSM cell phone network candistribute small pieces of data to all mobile phones inside a GSM cell using the CellBroadcast Channel (CBCH). With this, users can, e.g., receive local weather forecasts.

Using physical broadcast for geocasting has an advantage: the mobile devices donot need any positioning hardware as they only have a very restricted notion of loca-tion: they only know whether or not they are inside a certain circle around the sender.This, however, has some important disadvantages:

■ The mobile devices are restricted to a specific communication technology. Devicesresiding at the same location and using other wireless technologies do not receivegeocast messages.

■ Senders cannot restrict their geocasts to regions smaller than their transmission area.If e.g., a WLAN cell covers an entire storey, it is not possible to send a geocast mes-sage to only a specific room.

That is why advanced geocast approaches assume the positioning capabilities ofmobile devices.

The Geo Routing Approach

Imielinski and Navas [73, 74, 105] suggest different routing infrastructures to performgeocasting. In [105] they describe a hierarchical network of geo routers that reflects thestructure of a wireless cellular (e.g., cell-phone) network. As there is no notion ofsemantic locations, only physically defined targets are possible. Fig. 8-1 illustrates thisprinciple.

■ Geo hosts are the receivers and senders of geocast messages.

■ Geo routers form the routing infrastructure. At the lowest level, they connect thebase stations, which are able to broadcast geocast messages physically to their spe-cific service area. Each geo router knows its specific service area that is the union ofthe base stations’ service areas in its subtree.

■ Geo nodes store geocast messages. Whenever a new mobile node enters a servicearea, former geocast messages are transmitted to the new node.

106 Jörg Roth

To send a geocast message, a geo host transmits a request to its local base station. Thesender specifies the vertices of a polygon or centre and radius of a circle to define a tar-get area. To simplify a send operation, the user may use a map application to specifythe target.

The routing mechanism performed by the geo routers works as follows:

■ If the target area is not fully covered by the service area, the packet is passed to itssuper node.

■ In addition, the packet is passed to all sub geo routers that cover the target area (or atleast parts of it).

Finally, the geocast packet is distributed by one or more base stations. As the transmis-sion area is usually larger than the target area, each mobile host has to check individu-ally, whether or not it resides in the target area for the geocast packet.

The Multicast Approach

In [73] Imielinski and Navas suggest to use multicast IP groups [33] for geocast serv-ices. The idea is to define hierarchical groups, each one representing a specific area(fig. 8-2).

Atoms define the smallest areas, whereas partitions hierarchically join atoms or, inturn, smaller partitions. A mobile host residing at a specific location has to join all mul-ticast groups that cover the location, thus it receives all multicast messages targetingthese areas.

Semantic locations are partly supported, as some semantic locations (e.g., countriesand cities) are represented by their own group addresses. This approach is not scalableas the number of potential multicast IP groups is too small to cover a reasonable areasuch as an entire country. In addition, the multicast IP infrastructure is not prepared fora huge number of multicast members, moreover not generally available for mobileusers.

Fig. 8-1. The geo routing approach

Geocasting 107

The DNS Approach

Farrell et al. suggest an approach to use the Internet Domain Name Service (DNS) forgeocasting [49]. A lookup request for the host name University.Hagen.Ger-many.geo can e.g. return the IP addresses of all computers residing at the campus.This approach has some major disadvantages:

■ The original DNS returns a single IP address for a symbolic name. To get a list ofaddresses, all software using DNS has to be changed.

■ It is not clear how mobile hosts can register at a specific domain name server, asthey do not necessarily have to reside inside the local network. Cell phones, e.g.,reside inside the provider’s cell phone network, even though they enter a campuswith a local network.

Even though the DNS approach is difficult to apply in reality, its idea is promising. It ispicked up in the Nimbus geocast approach.

Other Approaches

Heutelbeck presents a geocast approach combining peer-to-peer and ad-hoc computing[67]. Mobile hosts form a logical ad-hoc network based on non-ad-hoc mobile commu-nication infrastructures (e.g., mobile phone networks or wireless LAN networksattached to a campus backbone). As an advantage, mobile nodes are not restricted to aspecific mobile communication technology. As in typical peer-to-peer networks, thelogical infrastructure and their services are provided by the mobile users. So-calledContext Spaces are recursively decomposed areas that enable geocast services. Targetareas only have a geometric meaning without the capability to define semantic areas.

One of our former projects, QuickStep [132], provides rudimentary semantic geo-cast services. Mobile nodes residing at a specific semantic location (e.g. a meetingroom) are automatically connected to a QuickStep server which serves as a relay sta-tion for all mobile nodes inside its area. Even though the QuickStep approach allowsthe hierarchical combination of areas, it does not provide general geocast servicesacross different spaces.

Fig. 8-2. The multicast approach

108 Jörg Roth

Coschurba et al. [27] present an extension to the Geo Routing approach by Imielin-ski and Navas which supports fine-grained addressing. Small areas and areas that havea three-dimensional representation can by used as target addresses.

Geocast is also an issue in the area of multihop ad-hoc routing [96]. Ad-hoc net-works connect mobile nodes without the need of a fixed infrastructure. Location infor-mation can be used in two ways: first, ad-hoc routing algorithms can be improved, ifmobile nodes can detect their physical location. Second, physical locations of ad-hocnodes can be used as target addresses for multicast methods. A simple approach floodsthe entire network. Each node has to check, whether it is within the destination area.Advanced flooding methods define smaller, so-called forwarding zones to avoid flood-ing to the entire network [87]. Further approaches transform existing ad-hoc routingprotocols to support geocast. E.g. GeoTORA [88] is a location-based extension of thead-hoc routing protocol TORA [123]. It maintains for each geocast group a directedacyclic graph comprising all network nodes, which shows the routing direction to thedestination region.

8.3 Semantic Geocast Using Nimbus

The logical structure of relations and associations forms an ideal platform for a geocastmechanism, as geocast messages can be distributed among this logical network [140].Nimbus geocast has the following properties:

■ Nimbus provides semantic geocast: a geocast request r from a mobile node containsa target domain r.domain and a message r.message. The geocast mechanism trans-fers r.message to all mobile nodes residing at locations A with A ∩ r.domain.c ≠ {}.

■ Location servers proactively discover the network and generate routing tables. Asthe logical network may change over time, the routing mechanism has to ensure sta-bility even though routing tables may be incomplete or may have expired entries.

The following sections make a worst case assumption: every domain is represented byits own location server (i.e. the fully distributed clustering on page 59), thus for com-munication between two domains, a network transaction is always needed. In reality,the performance of the system is much better, as communication can often be doneinside a location server. Thus, the performance evaluations in a later section describethe worst-case scenario.

8.3.1 The Semantic Geocast Mechanism

The Nimbus semantic geocast mechanism is executed according to the following steps:

■ Registration: Each mobile node registers itself at all location servers that cover themobile user’s current location. The location servers accept geocast requests and inturn deliver other geocast messages to the mobile nodes.

■ Address Propagation: Each location server builds a list of the network addresses ofother location servers. The lists are periodically updated and thus they notice whenservers start up or are shut down.

■ Message Passing: When a location server receives a geocast request, it looks up anappropriate location server in its address list for delivery and redirects the request.Often, this server is not the final destination, thus additional transfers may berequired.

Geocasting 109

■ Delivery: Finally, a target location server receives the message and distributes it tothe registered mobile nodes. If more than one location server covers the targetdomain, additional transfers to other servers is required.

Fig. 8-3 illustrates the basic mechanism. In this scenario, a mobile node residing atwaterfall.volme.river.geo sends a geocast message to all mobile nodes atuniversity.hagen.de. Nimbus distinguishes the following location servers thatprocess a geocast request:

■ The source location server accepts the geocast request from a mobile node(waterfall. volme.river.geo in fig. 8-3).

■ Intermediate location servers relay geocast requests to the target domains(hagen.de in fig. 8-3).

■ Target location servers are responsible for the target domain and send geocast mes-sages to the mobile nodes (university.hagen.de, 3f07.univer-sity.hagen.de and 3f08.university.hagen.de in fig. 8-3).

Note that, according to the area variation of the semantic resolution algorithm pre-sented in 7.3.6 (page 98), a single mobile node may be reached by different target loca-tion servers. Consistently, each mobile node receives geocast messages for all domainsthat have a non-zero probability to be currently covered by the mobile user’s location.It depends on the mobile node to decide how geocast messages are handled which aretargeting a domain that is not completely covered by the current location.

The communication between location servers can use "short cuts" and is not restrictedto associations and relations. All servers are connected via a global network (e.g. theworldwide Internet). Once a server has another server in its address list, both serverscan communicate directly.

The geocast mechanism mainly contains two parts: a proactive part to collectaddresses and a reactive part to route geocast requests.

Fig. 8-3. The Nimbus geocast mechanism

110 Jörg Roth

8.3.2 Address Propagation

Each server proactively collects addresses of other location servers. This is perma-nently done in the background, thus new servers are registered after a delay. As the listof all location servers in the system can be very large (e.g., many thousands entries),each server can build a list with a specific maximum length. This reduces the amountof memory required by a location server, but also reduces the traffic to maintain theaddress lists. As demonstrated below, the mechanism ensures stability, even if a targetlocation server is not listed by the source location server. Locations servers collectaddresses according to two mechanisms: slow propagation and fast propagation.

The slow propagation is built according to the propagation mechanism integrated inthe DSDV ad-hoc routing algorithm [124]. When a server starts up, it sends an updatemessage with its own address to its "neighbours", i.e. its master, all subdomains and allassociated servers. The message contains a sequence number, which a server has toincrease at every new start-up.

Whenever a server receives an address update, it first looks at its own table whetherit has already received an update with this sequence number. If yes, the message is sim-ply ignored; if not, it stores this new information and forwards the update to all neigh-bours apart from the originator. The sequence number avoids eternally circulatingupdates. Each server periodically (e.g. every day) increases its own address sequencenumber and distributes the address. An address entry has a certain lifetime, specifiedby the originating server. Thus, disconnected servers are removed from the lists afterthe lifetime expired.

To reduce the overall traffic, each server collects update messages for a specifictime (e.g. 10 minutes) and then exchanges them in a bundle. This mechanism is calledthe slow propagation, since it takes a considerable long time (e.g., some hours) forevery location server to list an address of a new server.

To propagate new addresses much faster, an additional mechanism was realized, thefast propagation. A new server starts with the slow propagation. Its own address listinitially is empty and thus it first receives new addresses from its neighbours. When-ever it receives the address of a root domain server, it uses the fast propagation mecha-nism: it once sends an address update to this root server. As a result, this root serverdistributes the new address in its own hierarchy, passing this information down thehierarchy tree. If neighbours of a new server already know the root domains of all hier-archies, addresses are distributed very fast among the entire infrastructure.

Simulations

The effectiveness of the geocast mechanisms was investigated with the help of simula-tions. As Nimbus is fully implemented and operable, the real infrastructure was usedfor evaluation purposes. A simulation tool randomly generates a huge number ofdomains. The tool first creates a root domain for every hierarchy and then additionallevels of domains by adding up to 10 subdomains for each domain. The process runsuntil it reached the required number of domains. Finally, the tool randomly adds asso-ciations between the hierarchies. The author conducted a number of simulations withthe same parameters to compensate outliers. A first simulation uses random hierarchiesto compare the slow and fast propagation (fig. 8-4). In the following, h denotes thenumber of hierarchies and n the total number of domains in all hierarchies.

Geocasting 111

As real network delays highly depend on the actual network structure and load, thesimulation only measures the hops in the simulations. Fig. 8-4 shows the maximumnumber of hops to inform a server about a newly started server, simulated for 2 and 16hierarchies. If all nodes are distributed among a higher number of hierarchies, the prop-agation works more effectively, because associations connect domains more tightly.For any number of hierarchies, the fast propagation needs a significant lower numberof hops to inform all domains, thus the fast propagation is recommended, once a newnode collected a root server address.

8.3.3 Message Passing

Whenever a source location server receives a geocast request from a mobile node, itlooks up an appropriate location server. This location server can either be a target loca-tion server or an intermediate location server. The latter case occurs, if a target locationserver is not listed, either because of a limited list space or the propagation has not yetbeen completed.

Algorithm 8-1 outlines the thread integrated in every location server to handle geo-cast requests. Here, x denotes the respective location server and r the geocast request.

Usually, a source location server handles a request (at ), which is directly passedto a target location server (at ). If a target is not listed, a request is send to an interme-diate location server (at ), which may relay it in turn to another intermediate locationserver. The message passing mechanism ensures that requests finally arrive at a targetlocation server. A target location server delivers the messages to mobile nodes. In addi-tion, it relays the request to all subdomains. Note that as subdomains are completelyinside a master’s domain, every subdomain has to process the geocast request as well.Note that the clustering concept presented in chapter 6 ensures an efficient distributionof messages to all subdomains. Section contains a backup strategy, if address listsdo not contain the required entries. In this case, a server asks its subdomains, its associ-ated domains and its master to pass a request nearer to a target. If address lists contain aminimum of entries (see below), this block usually is not processed.

Fig. 8-4. Comparison of Slow and Fast Propagation

112 Jörg Roth

Algorithm 8-1: Geocast Request Handler

while (true) // The thread loops endlessly{ wait for geocast request r if r.domain x.domain { // I'm a target LLS send r.message to all registered mobile nodes send r to all subdomains } else { // I'm an intermediate or a source LS look up servers s in the local address list where s.domain r.domain - if more than one server is found, choose the lowest in the hierarchy if such a server s is found send r to s else { // Try routing via relations and associations look up subdomain server y of x with y.domain r.domain if such a server y is found // there can only be one send r to y // subhierarchy for r else if x has associations into the target hierarchy { choose an appropriate associated server z (see selection above) send r to z } else if x has a master m // try the master send r to m else return an error to the originating node }}

8.3.4 Dealing with Restrictions, Scalability

On the one hand, the infrastructure has to be scalable for a higher number (e.g., manythousands) of domains. On the other hand, each location server should be very lightweighted, i.e. should not make high hardware demands. As a result, a location servercould have a limited memory space for storing addresses in its list. Let l denote themaximum number of entries in the address list. To simplify the evaluation, each loca-tion server has the same space limitation. In reality, however, top-level servers may beprepared for larger lists. The mechanism collects addresses using priorities:

■ 1 (highest): root domains;

■ 2: all domains of the own hierarchy;

■ 3: all domains of other hierarchies.

Domains with priorities 2 and 3 are further ordered by the domain level (higher levelsfirst). The address list is filled according to these priorities: if the list is full and a newaddress is added, the entry with the lowest priority is dropped. For successfully passinggeocast messages, at least a list of all root domains (except for the own) is necessary,thus l≥h-1. Here h again denotes the number of hierarchies. Note that servers do not

Geocasting 113

store related or associated servers in the address list, as these links use a separate stor-age.

The second step ensures that in case of sufficient address space, at least all serversof a hierarchy know all servers of their own hierarchy. Thus, whenever a geocastrequest was directed to the target hierarchy, only one more hop is required to reach atarget location server. The third step finally fills the list with domains of other hierar-chies.

Fig. 8-5 and fig. 8-6 show the result of evaluating the message passing algorithm.Here, the simulation iterates through all possible pairs of sender and receiver andcounts the maximum and average hops to reach the first target location server. The fig-ures present average numbers of 100 simulations with different random hierarchies.The x-axis shows the limited list space in relation to the total number of domains. Notsurprisingly, the average number of hops converges to 1 for higher l. Each curve has acertain break point (e.g. at 50% for h=2). At this point, address lists are capable to storeall domains of the own hierarchy.

As a result, the maximum hop count to reach a target is 2: one to reach the rootserver of the target hierarchy and one more to reach the target location server inside thehierarchy. Assuming nh domains for each hierarchy, where

for a total number of n domains in all hierarchies, we get a maximum of two hops for

.

Having fewer entries in the address list, but not less than h-1, message passing is stillsuccessful, but the number of hops is considerable high.

Fig. 8-5. Average maximum number of hops when passing messages with reduced address tables (n=1000)

nhnh---≈

l h 1–nh---+≥

114 Jörg Roth

8.3.5 Security Issues

Security is an important issue for distributed systems, especially in mobile computingenvironments. To protect a server or mobile node against malicious servers, a node canrequest an authentication certificate of the correspondence node (see section 9.4 onpage 130). A server can reject any request, if the authentication fails. This includesgeocast requests as well as requests to register as a master, subdomain or associatedserver. To avoid denial of service attacks, an LLS should not accept geocast requestsfor larger target areas (e.g. a country).

If mobile users do not want to receive any geocast message, they can register them-selves in stealth mode. In this case, Nimbus only provides basic services. As the mobileuser is not listed by an LLS, the system does not collect any position data. As Nimbusis decentralized, such servers would have to cover a large area to capture motion pro-files of mobile users. Note that it is generally very difficult to protect mobile usersagainst malicious servers that collect motion profiles. The same unsolved problemoccurs in cell-phone networks.

A mobile user who wants to receive geocast messages is not willing to receiveunwanted (i.e. spam) messages. As in traditional networks, an application listens for aset of predefined ports and ignores all messages arriving at other ports. As the mobileuser cannot send geocast messages directly, but has to use an LLS, the LLS couldrequest identity information from geocast senders. Some mobile networks (e.g. GSM)allow the authentication of mobile users. Authentication information can be passedthrough to all receivers. The author is aware that this mechanism cannot avoid spamcompletely, but even in traditional networks this problems is not solved.

8.3.6 Further Details

As mentioned above, Nimbus and its semantic geocast mechanism is fully imple-mented and tested and offers a convenient interface to use the geocast service. The fol-lowing code shows how to send a geocast message with only a few lines of code:

Fig. 8-6. Average number of hops when passing messages with reduced address tables (n=1000)

Geocasting 115

LSI.startService(); // start the runtime systemLSI.setStealthMode(false); // I want to receive messagesbyte[] msg="hello".getBytes(); // create a messageLSI.sendGeocast(NATIVEGEOCAST, // and send it to MSG_PORT,"hagen.de",msg); // all nodes in Hagen

Two kinds of geocast requests can be distinguished: native requests use UDP for thelast hop, i.e. from a target location server to mobile nodes. Using native requests, areceiver has to listen to a traditional UDP port to receive geocast messages. In contrast,event-based requests use internal protocols between the client and the LLS. Using theevent-based mechanism, an application can either call a receiveGeocast methodto wait for geocast messages or register a listener object that is called when a messagearrived. As a component to deliver event-based geocast messages, the Nimbus triggerservice is used (see section 6.5 on page 77).

8.4 A Sample Nimbus Application Using Geocast Services

The sample application Flirt Finder shows the effectiveness of the Nimbus geocastapproach. Similar to the original Flirt Getty device (see section 8.2 on page 106), theuser configures his or her "flirt profile". The mobile device distributes it to the currentlocation and in turn receives incoming flirt messages. If the profiles are compatible, aring tone is played and the message appears on the screen. Then the receiver may get intouch with the sender using his or her phone number (fig. 8-7).

Compared to the original Flirt Getty, the Nimbus geocast approach has two advantages:

■ Users can use different mobile devices, including mobile phones or PDAs, with dif-ferent communication technologies (e.g., GSM or WLAN), whereas the originaldevices use a proprietary radio format, thus only devices of the same manufacturercan communicate.

Fig. 8-7. The Flirt Finder Application

116 Jörg Roth

■ As there is a notion of a semantic location in Nimbus, transmissions can berestricted to those people who are reachable (e.g., inside the same room). Radio sig-nals from the original Flirt Getty penetrate walls and obstacles and may send errone-ously messages to people who are impossible to meet.

Furthermore, a central administration or storage of user profiles is not necessary. Apartfrom the general geocast service, the application does not need any additional servicesfrom an Internet or mobile phone provider. The Flirt Finder source code has 300 linesof Java ME code – most of them define the user interface.

8.5 Summary

This chapter presented a decentralized, self-organizing approach to provide geocastservices. It introduced the notion of semantic geocast, where target regions are definedby their meaning rather than by their physical area. The Nimbus geocast mechanismproactively collects potential target addresses and ensures scalability and stability, evenif the servers have certain limitations concerning memory space. A flirt finder applica-tion demonstrated the strengths of the geocast service.

Geocasting 117

118 Jörg Roth

9 Communication and Security Issues

As some parts of the Nimbus software run on mobile devices such as cell phones,it is necessary to consider mobile communication issues. Currently, software de-velopment for mobile devices is cost intensive as mobile software and hardwareenvironments still have many limitations. Different software and hardware plat-forms (e.g., tablet PCs, PDAs, mobile phones) may use different communicationtechnologies (e.g., Infrared, Wireless LANs or cell phone networks) to communi-cate with location servers or attached positioning hardware. Currently, the marketfor devices and communication technologies is rapidly changing. To be able to re-use software, even when the underlying communication platform is modified orexchanged, the software should not be developed from scratch, but with the helpof a framework, which separates network related functions from the application.This chapter presents the Network Kernel Framework (NKF), a middleware forsmall devices in mobile environments. In addition to the client-server communi-cation, NKF is used to connect location servers among each other.

9.1 Introduction

At a first glance, realizing mobile or ad hoc connected applications seems to be verysimple: mobile hardware is highly available and inexpensive; the Internet Protocol(IP), often viewed as the lingua franca of networking, connects different computersand devices across platform borders; with the help of higher level services such as JavaRMI or CORBA, an application developer can easily develop networked applicationsby using powerful programming abstractions, first and foremost the remote methodcall.

Having a closer look however, the world is not so well organized and simple. Thereare several problems an application developer still has to face:

■ Serious hardware limitations: some devices (e.g. mobile phones, embedded sys-tems) currently have not enough computational power to support programming lan-guages such as Java in its Standard Edition. Higher-level frameworks often need alarge amount of valuable memory, which, in contrast to desktop computers, is a bot-tleneck for mobile devices. Even if fast processors and big memories are availablein principle, they consume a great amount of valuable battery power. Unless batterytechnology will improve significantly, mobile devices will always be far behind thecapabilities of desktop computers [29].

■ Missing IP support: for some network infrastructures or devices, IP support is inad-equate or unavailable. Having, e.g., an infrared link via IrDA [75], IP support isonly available with some serious drawbacks. In addition, some devices (e.g. CPen[21]) do not offer built-in IP support at all.

■ Missing platform independence and interoperability: languages such as Java oftendo not have the desired level of platform independence. Java for small devices (JavaMicro Edition [162]), e.g., is not compatible with Java Standard Edition, thus pro-grams cannot be used on different platforms without re-implementing major parts ofan application. The Jini framework [176], actually designed for ad hoc networks,requires full Java support, thus currently cannot be used on most mobile devices[170].

Communication and Security Issues 119

■ Missing support from manufacturers: even if devices in principle are able to accom-modate high-level communication platforms, such platforms often are not availablefor new devices. Currently, the market for mobile devices and wireless communica-tion technology rapidly changes. Device manufacturers often do not invest the costsfor an appropriate development support for devices with short life cycles. Third-party solutions often do not reach the required quality and tend to be unstable.

■ Incompatible reference models: looking at the OSI reference model or the referencemodel provided by the IEEE 802 standard, we find strongly structured hierarchicallayers. With these models, it is easy to exchange some layers without affectingupper layers. Unfortunately, most of the networks in ad-hoc scenarios (e.g. the Blue-tooth or IrDA) have their own reference models, which are often incompatible toexisting models.

The lack of middleware platforms leads to monolithic and unstructured code. More-over, changes in the communication infrastructure affect applications, which too oftenhave to be re-engineered. The Network Kernel Framework (NKF) was developed toaddress these problems. NKF leads to lean runtime systems, which even run on verysmall devices, and at the same time it separates all network related functions from theapplication. Moreover, the framework relieves an application from additional functionssuch as data encoding, compression and encryption.

9.2 Related Work

The idea of separating network access from applications is not new; a huge variety oftools and middleware platforms supports developers of distributed applications. Well-known examples are, e.g., RPC [159], Java RMI [160], CORBA [113] and IBM’s DAE[72]. These platforms significantly simplify the development of distributed applica-tions with the help of powerful services such as remote procedure calls or remotemethod invocations. However, to offer this support for new devices, the entire platformhas to be ported to a new hardware or operating system. This is usually a time-consum-ing and cost-intensive task. Even if there exists platform support for a new device, thissupport sometimes can be viewed as a 'black box', i.e. the creation of applications issimplified, but the platform itself cannot easily be modified. This is especially true, ifthird parties developed the middleware platform for commercial purposes. Usuallysuch platforms do not come along with their source codes, thus it is difficult to inte-grate new security protocols, access new network infrastructures or include new dataencoding schemes.

Higher services, which use mechanisms such as RPC and RMI (e.g., [152]), arerestricted to the specific communication paradigm (e.g. remote calls) provided by thebasic platform. Often, such platforms omit a wide area of other useful communicationparadigms. It is not possible to map mechanisms such as multicast or anycast on net-work level directly to remote calls. This forces applications to inefficiently use 'loops'of unicast instead of using native multicast capabilities.

Some systems provide limited access for integrating different network capabilitiesinto existing platforms. Microsoft Windows uses abstract sockets, so-called winsocks,which either can be TCP/IP, IPX/SPX or IrDA sockets [79]. Applications using win-socks can use different communication infrastructures without too many changes. Nev-ertheless, applications cannot be completely network independent, since there areslightly different addressing schemes and discovery mechanisms for different net-works. Similar to winsocks, Java offers so-called socket factories, which give develop-

120 Jörg Roth

ers the possibility to integrate new kinds of network connections into an application.As original Java sockets are based on the TCP/IP protocol suite, new sockets must havesimilar characteristics. Java Micro Edition offers the mechanism of connections [162],which can support a number of communication protocols (e.g., UDP, TCP, HTTP) andprovides a common interface. Once a connection is instantiated, the application doesnot have to consider the actual protocol any longer.

Other approaches avoid network integration issues and only define a high-level pro-tocol. So they leave it to the developers or operating system to make the actual imple-mentation. OBEX (object exchange protocol) [75] is a protocol for exchangingarbitrary objects between different devices such as digital cameras, PDAs and mobilephones. The current OBEX protocol, better known as the 'beaming' protocol [15], usesthe IrDA infrared stack for communication, but in principle can run on every reliablenetwork transport layer such as Bluetooth or TCP. SOAP (simple object access proto-col) follows a similar concept [155]. With SOAP, programs can exchange arbitraryapplication objects using XML for data encoding. Since various platforms can interpretXML, SOAP is highly flexible and interoperable. SOAP uses HTTP to exchange mes-sages, thus is limited to TCP network connections.

To sum up, there exist different levels of development support for distributed appli-cations. Higher-level platforms offer powerful services, but request high implementa-tion efforts to offer this kind of support for new hardware and software platforms.Lower-level support can be realized much easier on any device, but leave much workfor the developer. The problem is to find an appropriate balance between developmentsupport and integration efforts.

9.3 The Network Kernel Framework

The Network Kernel Framework (NKF) [135] is a middleware platform for smalldevices such as PDAs or digital cameras, as well as for traditional desktop systems. Itis designed for supporting new devices that do not come along with publicly availablemiddleware platforms such as CORBA or RMI. NKF does not make high demands ontarget platforms. Though NKF was implemented in Java and C, NKF does not rely on aspecific programming language paradigm. The following sections present NKF indetail.

9.3.1 Protocols, Modules, and Methods

Fig. 9-1 shows an overview of NKF’s architecture. The framework acts as an interme-diate layer between lower-level services provided by the operating system and higherlayers such as applications or high-level services. The framework consists of two dif-ferent kinds of modules: framework and kernel modules.

Framework Modules

Four framework modules are fixed parts of the framework, each offering a specificservice:

■ The lookup module looks up other communication parties inside the network.

■ Once the lookup module found a service, the negotiation module negotiates parame-ters for a specific connection, e.g. which protocol to use and how to present data.


■ The service module performs additional set up and configuration functions for spe-cial network connections. For a serial connection, e.g., parameters such as baud rateand parity have to be configured.

■ With the help of the inspection module, higher services can look up properties of aspecific connection. Using, e.g., a cellular phone connection, it may be helpful toask for the current receiver input level.

Kernel Modules

In contrast to framework modules, kernel modules may vary in number and specificfunctionality. NKF distinguishes three types of kernel modules:

■ Network modules offer a uniform interface to lower-level network services. Net-work modules are, e.g., TCP, UDP, Multicast IP, IrDA, or RS232 modules. Networkmodules and their interfaces to upper modules are described later in detail.

■ Before delivering data to the network, processing modules preprocess data packets.To save network bandwidth, packets may, e.g., be compressed via a deflating algo-rithm. Processing modules can be piled up: after compressing data, e.g., the resultcan be encrypted with asymmetric encryption against unauthorized listeners. On thereceiver's site, the same stack of processing modules has to exist.

■ Codec modules encode application data for transportation. Same codec modules usethe same coding across different platforms and programming languages, regardlessof the specific internal data format. Application developers do not have to strugglewith, e.g., string termination, integer size or byte ordering. Examples for codecmodules are: C codec (C style data format), Java codec (Java data stream format) orString codec (every data transferred as Unicode string). Note that, e.g., the Javacodec may be available for other programming languages than Java – it determinesthe transportation format rather than the interface language.

Example

Suppose that two applications want to communicate, one is running on a traditionalWindows PC, one on a Palm handheld device (see fig. 9-2). We connect both comput-ers either via a serial cable, via infrared (IrDA) or via the TCP/IP stack (which itselfeither uses a serial cable or infrared). Both computers are equipped with a number ofprocessing and codec modules. The 'weaker' device, the Palm, offers only the very sim-

Fig. 9-1. The NKF architecture

122 Jörg Roth

ple compression algorithm RLE (run length encoding) and a C style data encoding, theWindows PC offers in addition the more complex deflater compression, an asymmetricencryption and Java style data encoding. To connect, the devices have to choose mod-ules that are available on both platforms, i.e. the C coding, RLE compression and theIrDA network module. The set of modules can either be specified by the correspondingapplication or can be negotiated automatically.

Both applications can simply send and receive data without considering the underlyinginfrastructure (table 9-1). If in the future new network, processing or codec modulesare integrated, they can simply be added without adapting existing applications.

The Windows PC is the initiator of the communication (new URL(...).get-Codec()) and the Palm waits for incoming connections (NKF_URL_getCodec).The PC specifies a host string ("palm"), thus the underlying system automaticallyuses an initiating connection type. In contrast, the Palm device just specifies a channelnumber ("2000") without a host, thus NKF uses a reacting connection. More aboutthe URL-like notation is presented in section 9.3.6 (page 127).

Once a connection is established, both parties can send and receive messages (sendand receive statements). A single message consists of one or more data entries, e.g.strings or integers. A developer uses putX statements to add data to an outgoing mes-sage and getX statements to read data from a received message. After sending andreceiving messages, both parties terminate the connections (disconnect). To sumup, this example outlines the following benefits of NKF:

■ The two applications communicate across hardware platform borders (Windows PCto Palm device).

■ The two applications communicate across programming paradigms (object orientedto traditional imperative) and language borders (Java to C).

■ The two applications communicate regardless the underlying communication tech-nology, security protocols or data compression algorithms.

Fig. 9-2. NKF data flow example


A crucial point of this example is the string "irda://..." passed to the openingprocedures at the beginning of the applications. This string is obviously not independ-ent of the underlying communication infrastructure. Section 9.3.7 (page 128) describesmechanisms to avoid such strings.

9.3.2 Network Modules

Network modules are the most important NKF modules. With the help of networkmodules the underlying network can be changed without affecting processing or codecmodules. Applications only have to be adapted, if they make explicit use of specificnetwork capabilities via the service or inspection module.

To offer a wide variety of network functions to upper layers, network modules musthave an interface to integrate a high number of network protocols such as

■ TCP/IP suite protocols (TCP, UDP or Multicast IP);

■ a reliable multicast protocol based on Multicast IP and UDP:

■ infrared protocols based on IrDA;

■ Bluetooth;

■ GSM or UMTS, and

■ protocols which communicate via a USB, Firewire, or via a serial or parallel port.

For debugging and testing, an additional network module for simulation is useful. Thismodule can act as a usual network module, but performs configurable bandwidthreduction and delays, thus is ideal for testing an application under realistic conditions.

Different network modules have different characteristics. A module can supportstream connections or datagrams. If datagrams are used, the module can support uni-cast, multicast or anycast; properties concerning packet loss and packet ordering maybe different. To support different communication capabilities, NKF defines a numberof methods, each specifying a specific communication scheme, e.g.:

Table 9-1. Source code examples

Java / Windows PC C / Palm device

c=new URL ("irda://palm:2000/RLE/C"). getCodec();

c.putInt(123);c.putString("hello");c.putBoolean(true);c.send();

c.receive();i=c.getInt();s=c.getString();b=c.getBoolean();

c.disconnect();

c=NKF_URL_getCodec ("irda://:2000/RLE/C");

NKF_receive(c);i=NKF_getInt(c);s=NKF_getString(c);b=NKF_getBoolean(c);

NKF_putInt(c,456);NKF_putString(c,"hello");NKF_putBoolean(c,0);NKF_send(c);

NKF_disconnect(c);

124 Jörg Roth

■ STREAM: stream connection (e.g. TCP, IrDA, serial),

■ UNICAST: unreliable datagrams (e.g. UDP),

■ REL_MULTICAST: reliable multicast

■ ANYCAST: unicast to one of a group (available in IPv6, currently emulated).

Usually, a network module does not support all of the above methods. Via the inspec-tion module, an application can ask for methods a module actually supports; a resultcan be one of {NOT_SUPPORTED, SUPPORTED, EMULATED}. The EMULATEDentry is used, if a specific network module does not support a method in a native man-ner. A UDP module, e.g., can emulate multicast using unicast in a loop. This is, ofcourse, much more inefficient than using native multicast. Nevertheless, using the mul-ticast method rather than making a loop of unicast transmissions inside an application,developers can install an optimized network module later without modification.

9.3.3 Security

Security is an important issue in mobile and ad hoc scenarios. A communication infra-structure should address the following aspects Privacy, Authenticity, and Integrity. Toensure security, current mobile network protocols use cryptographic algorithms such asasymmetric and symmetric encryption and hash functions. Unfortunately, crypto-graphic algorithms, especially asymmetric encryption algorithms, need a lot of compu-tational power, and thus security is not supported in some protocols. OBEX [75], e.g.,only provides authentication on session level. The stronger message-level authentica-tion is not available. More critical, OBEX ensures neither privacy nor integrity. Othermobile protocols only use symmetric encryption and leave it to the application to gen-erate keys via, e.g., public key exchange mechanisms.

An application developer sometimes wants to have fine-grained control about thelevel of security provided by the network. For some applications, no or only low-levelsecurity is sufficient, whereas other applications require higher levels of security. NKFoffers the desired flexibility:

■ Security functions can easily be integrated into an NKF stack with the help ofprocessing modules.

■ The negotiation module can initiate key exchange and session authentication.

■ Processing modules can perform authentication on message-level by adding mes-sage authentication codes (MACs) to outgoing messages and verifying MACs whenthey receive messages.

■ The NKF stack can rely on security functions provided by the network. If, e.g., thenetwork provides Transport Layer Security (TSL) [38], additional security modulesinside NKF are not necessary.

A developer can adjust the level of security without affecting the interface to the appli-cation. In other words: a developer can develop an application without consideringsecurity issues and can add security algorithms later. Currently, many devices are notable to offer complex security functions. If, in the future, new algorithms are availablein hardware (e.g. encryption chips, special smart cards with security algorithms), secu-rity functions can easily be integrated into an existing application.


9.3.4 Encoding and Decoding Data

To exchange data across operating system and hardware borders, data have to beencoded in a platform independent manner. There exists a variety of solutions toaddress this issue:

■ standard data format specifications for native data types (the CORBA approach);

■ equivalent internal data formats or identical virtual machines on different devices(the Java approach);

■ XML to encode data (the SOAP approach);

■ MIME types [16] (the OBEX approach).

All these solutions have advantages and disadvantages. Some applications only trans-fer small amounts of data, thus some of the solutions above are strongly oversized. If,e.g., an application only transfers unstructured data types such as integers and strings,an XML parser or a Java virtual machine are not adequate and it is sufficient to specifybyte ordering and string termination.

With NKF, a developer can realize all the mechanisms described above; it offers theflexibility to either use high-level concepts such as XML or MIME types, or leanmechanisms. To realize an NKF stack for a specific platform, a developer can choosean appropriate level of support by creating a set of codec modules, which contain theappropriate pairs of get and set routines. An application can request specific modules atruntime or leave it to the negotiation module to negotiate an appropriate codec module.

9.3.5 Identifying Hosts, Devices, and Services

Different network infrastructures use different naming conventions to address hostsand services. As the interfaces of all network modules have to be identical, the addressformat has to be identical as well. The addressing format contains (host, channel),where host is a string specification of the host address and channel is a number specify-ing a service on a host. This scheme is appropriate for most networks. TCP/IP hosts,e.g., are identified by the IP address or a host name, which both could be represented asa string. A port number presents a specific service on a host. In the same way, IrDAidentifies devices by a device name. Services on a device are distinguished by anumber called the Link Service Access Point number (LSAP). Exceptions of thisscheme exist: a serial connection, e.g., does not distinguish between different serviceson a single device. The NKF realization of the serial network module therefore imple-ments its own scheme of service numbers with the help of a simple protocol.

There are two different namings for hosts: A global naming has a worldwide uniquename for a specific host or device. A local naming uses different names for the samehost or device which are only unique for a certain host. Examples for global namingsare TCP and UDP: using a fully qualified Internet name, a host has a worldwide uniqueaddress. An infrared connection based on IrDA uses local naming. For a specific host,an infrared device in range may have a name A, whereas another host has no idea aboutA because it is not in infrared range. Even worse, both hosts may know differentdevices with the same name B.

The network module specifies the corresponding naming scheme; an applicationcan query the current configuration using the inspection module. The differencebetween local and global names is important when distributing host names to otherdevices: another device can only use global names directly. To access devices withlocal names, NKF uses a special process, the communication gateway. Communication

126 Jörg Roth

gateways run on top of the NKF platform and allow a device to address other devicesvia their local name. For this, a so-called global cascading name is used, which isdefined as follows:

c_global_name = global_name | local_name "," c_global_name

where global_name and local_name are local or global device names. The string

local_name1, local_name2...,local_namen, global_name

addresses a specific device with local name local_name1, which is connected to adevice local_name2, which in turn is connected to device local_name3 etc. Inorder to get a global unique address, the last device name has to be a global name.Usual cascading names do not have more than two components. E.g.,CPen,132.176.67.44 addresses the device 'CPen', which is connected to a TCPhost with its corresponding IP address. Global cascading names are passed to gatewayprocesses that serve as a kind of routers and link different networks together. Gatewayprocesses are not specified as components inside the network kernel framework, butviewed as higher-level servers built upon NKF.

9.3.6 Specifying Connection Properties

Usually, an application looks up a service via the lookup module. When an appropriateconnection is established, a reference (i.e. an object handle or pointer) representing theconnection is passed to the application. The application uses the reference for sendingand receiving data; usually it is not required to configure the connection. In some caseshowever, an application may want to have explicit control over the used modules. Toconveniently specify network, processing and codec modules, a notation similar to webURLs is used:

protocol://target:channel/proc1/.../procn/codec#method

where target can be one of {<emtpy>, host, [host1,..., hostm]}. Empty tar-gets are used when a host specifies a server end point for incoming connections. A listof hosts addresses multiple hosts at a time for, e.g., multicast. The strings proci spec-ify the stack of processing modules and codec the codec module. Finally, #method,specifies the communication method, i.e. stream or datagram. Some parts of the stringcan be left out, if either there exist default values or the parameters are negotiated atruntime. Example strings are:

■ tcp://carmen:5555 uses a TCP connection to host carmen, port 5555,processing and codec will be negotiated;

■ irda://palm/RSA/deflater/Java uses an infrared connection using RSAencryption, data compression and Java data encoding;

■ udp://[carmen,tosca,orpheus]:55#MULTICAST_MULTIADDRESSsend a UDP datagram to a group of servers.

These strings are passed to a connect operation to establish the desired connection.With the help of this notation, an application developer can simply test different con-nection types in an application by just adapting a single string.


9.3.7 Discovery, Lookup, and Negotiation

Passing a predefined string to an application is suitable for testing scenarios. However,if a device connects to an unknown environment, it knows neither other host addressesnor available modules on peer sites. Applications must have tools to discover the net-work environment and negotiate communication properties at runtime. For this, theframework uses three mechanisms:

■ Discovery is performed by network modules and returns the address of other acces-sible hosts and devices. A discovery of a TCP module, e.g., returns all hosts of asubnet; a discovery of the IrDA module returns all devices, which are in infraredrange. The discovery mechanism is the most important function for ad hoc con-nected devices. It highly depends on the module and can be released in many ways.The IrDA protocol stack, e.g., has a built-in discovery mechanism, thus discovery isavailable without extra costs. Other protocols, e.g. TCP/IP, may need additionalfunctions to discover available devices. A module can ask network devices such asrouters or switches for the corresponding information or send discovery messagesvia native multicast. Regardless of the used strategy to discover the network, thecorresponding mechanisms are encapsulated inside the network module.

■ Lookup: having a list of hosts, an application can look for specific services. Lookupis performed by the lookup module and makes use of a protocol running over well-known channels. An application either can retrieve a complete list of available serv-ices or can specify a query. Each service is specified by a name, a version numberand an instance number. With the latter, identical services on a single device can bedistinguished. If native multicast modules are available, they are used for discoveryand lookup.

■ Negotiation: when an application decides to connect to a service, the actual connec-tion properties have to be negotiated. For this, the negotiation module negotiates thenetwork module, the stack of processing modules and the codec module. An appli-cation can pass a list of preferences to the negotiation module, which maps modulesto one of {REQUEST, PREFER, EVADE, REFUSE}. This, however, can cause a con-nection operation to fail, if requested modules are not available on peer sites. Thus,a developer has to use this feature carefully.

After the module stack is negotiated, the negotiation module asks the individual mod-ules for module-specific negotiation. An encryption module, e.g. may want toexchange public keys with peer devices. Other modules negotiate runtime parameters.Since this kind of negotiation is highly module-dependent, the modules themselves areresponsible for it.

9.3.8 State of the Implementation

NKF currently supports three device types:

■ Java-enabled devices capable of running the Standard Edition (Java SE) [161] suchas desktop computers, notebooks and tablet PCs;

■ small devices running Java Micro Edition (Java ME) [162] such as mobile phones,palmtops and pocket PCs;

■ PalmOS devices [15, 52] such Palm handhelds and some smart phones.

Table 9-2 shows the properties of the respective platform implementations.

128 Jörg Roth

The number of classes or C files, the size of the runtime packages and the communica-tion capabilities significantly differ from platform to platform for the following rea-sons:

■ Java SE offers the highest support for network access. If a communication platformis not supported directly (such as IrDA), native C code is used to access communi-cation facilities. This is not possible with Java ME.

■ In order to reduce the number of classes and thus the overhead during runtime in theJava ME environment, some classes of the NKF class tree are packed together. Theresulting class hierarchy is more difficult to extend, but is more compact with lessredundancy. This especially reduces memory requirements during runtime, which isessential for mobile platforms.

■ Programming in C with PalmOS usually leads to very small runtime packages. Notsurprisingly, the PalmOS package of NKF has half the size of the Java ME package.

NKF offers support for TCP/IP suite protocols, IrDA and serial connections. HTTPplays a special role in this context. HTTP itself is not a transport protocol as it is basedon the transport protocol TCP. However, HTTP often replaces a real transport protocolin mobile environments, even though communication does not deal with the WorldWide Web. When, e.g., connecting mobile phones to the Internet, mobile phone provid-ers often do not offer TCP capabilities, but provide HTTP connections, which arepassed over the provider’s WAP gateway. Former Java ME implementations (MIDP1.0) reflect this limitation where HTTP is the only protocol certainly available on allJava ME devices.

To address this problem, NKF introduced an HTTP module. The reacting part ofthis module offers a small HTTP server; the initiating part performs an HTTP clientcommand. As HTTP connections do not allow raw binary data, NKF transforms binarydata automatically into a string format.

Before NKF was finished, predecessors of NKF are used inside other projects. Afirst version of NKF was used in our groupware platform DreamTeam [131], whichacts as a common platform for distributed applications such as shared whiteboards andshared text editors. DreamTeam was originally created to run on desktop systems, but,with the help of NKF, we could simply implement a DreamTeam extension for palmdevices called Pocket DreamTeam [142, 183].

We further designed a second platform, QuickStep [132, 147], especially for hand-helds such as PalmOS or Windows CE devices. With QuickStep, users can share appli-cation data, e.g., appointments, addresses, memos or business cards with other users.QuickStep has much more flexibility than the 'beaming' protocol OBEX. Users can

Table 9-2. Properties of different NKF implementations

PlatformSoftware Modules

Runtime Package T

CP

UD

P

Mul

tica

stIP

HT

TP

IrD

A

Seri

al

Java SE 59 classes 131 KB

Java ME 13 classes 22 KB

PalmOS 14 C files 11 KB


share entire databases and do not have to transfer data record by record. Moreover,connected users do not have to be 'in range', i.e. users can share data even when theyreside in different buildings. Due to the heterogeneity of devices and networks, Quick-Step was an ideal application for NKF. Several sample applications with QuickStepexist, e.g. a calendar tool, which allows members of a meeting to schedule appoint-ments for future meetings, a brainstorming tool, and a business card collector.

9.3.9 The Role of NKF in the Nimbus Framework

Using NKF in the Nimbus framework has a number of benefits:

■ Nimbus has parts running on traditional workstations and parts running on mobiledevices. For the mobile part, Nimbus has to cover a huge number of differentdevices. Thus, it is necessary to have a communication middleware, which can eas-ily be migrated to different platforms.

■ As full TCP/IP support sometimes is not available on small mobile devices, theNimbus framework must be able to use different transport protocols without chang-ing others parts of the system.

■ Besides the client-server connection, mobile devices have to access their positioningsystems. Usually such systems are attached via serial port, USB, or Bluetooth. Anefficient development of positioning drivers (see section 7.3.2 on page 87) requiresappropriate communication support.

■ The security infrastructure of Nimbus requires secure connections with encryptionand authentication for some protocol phases. Communication processes want to eas-ily switch between secure and insecure connections at runtime.

The last point was the reason to use NKF inside the Nimbus framework not only forclient-server connections, but also to connect location servers between themselves.NKF is used in the component Communication & Security as presented in the next sec-tion. Once using NKF instead of traditional TCP sockets, security services can easilybe integrated into the system without affecting other parts of the system.

9.4 Security Considerations

The location server infrastructure is, as any distributed system embedded in a largernetwork, target of potential security attacks. There are many conceivable threatsagainst the servers and clients:

■ One can install a location server that distributes wrong data to mobile users. Userswho resolve their positions with the help of this server would receive misleadinglocation information.

■ Attackers can modify data exchanged between the servers. This would affect thelogical network of relations and associations between the servers. As the integrity ofthese links is essential for the resolution process, wrong links would lead to wrongor incomplete results.

■ Attackers can also modify data exchanged between the server and client.

■ One can attack location servers directly. Possible attacks are denial of serviceattacks or attacks against the configuration or software installations.

■ One can collect location data of mobile clients. As the location of users is consid-ered as private, this is an attack against privacy of mobile users.

130 Jörg Roth

■ Clients can exploit the geocast mechanism for a denial of service attacks or for dis-tributing spam messages.

■ Corrupted positioning systems and mapping servers can offer wrong location data.

It is a difficult task to make a distributed system secure. The degree of security has tobe weighed up carefully. Integrating security mechanisms usually is a contradiction tobenefits such as openness, low administration costs or convenience of usage. Somesecurity algorithms consume much computational power, thus pure software solutionsmay not be suitable for some mobile computing platforms. As a problem, securitymechanisms cannot be integrated into ’black boxes’ such as some positioning systemsoff the shelves, thus developers have to rely on already existing security mechanisms(e.g. the secure PalmSpot beacons, section 3.3.1 on page 25).

Issues concerning geocast and the collection of mobile users’ locations have alreadybeen discussed in section 8.3.5 (page 115). This section presents Nimbus securitymechanisms that are designed according to the following goals:

■ Each server or client should be able to verify the identity of location servers.

■ The integrity of communication between location servers should be ensured.

■ Each server or client should be able to detect unauthorized changes of the locationserver’s domain configuration.

To achieve the required goals, Nimbus has to give up the completely decentralized andself-organising architecture and introduce a central instance, a certification authority(CA). However, the CA does not have to be online all the time and is only required forcertain functions during the installation of a new location server. Thus the decentral-ized characteristic of the location server infrastructure is preserved. In addition, severalCAs may be available working in different parts of the network, i.e. servers can accessthe most appropriate CA to get the respective services.

The location server infrastructure forms an ideal platform to integrate security func-tions, as the hierarchies already provide a structure, which can be used for administra-tive purposes.

9.4.1 Secure Communication and Authenticated Servers

According to established security infrastructures, Nimbus uses the CA to administrateand sign certificates. Fig. 9-3 shows the steps to get a certificate.

Fig. 9-3. Steps to get a signed certificate


Certification authorities cannot directly proof requests of location servers as dataregarding the domains have to be checked, which requires knowledge about the localenvironment. A certificate request is first passed to the master (step 1), which performsthe following checks:

■ Is the subdomain's name syntactically valid and does it indicate the subdomain rela-tion to this master?

■ Is the subdomain's area valid and completely inside the master's area?

■ Is this the first request with this name or is the name used by other servers?

Only if all checks are positive, a master accepts a request. A master could in principleperform these checks automatically. Additionally, the master’s administrator has tocheck, if the request is reasonable. As an example, a subdomain of de should be a city.The administrator can check, if the name is a city name and the area really describesthe area of the specified city.

Approved requests (signed by the master) are passed to the CA (step 2). The CAchecks, if the master already has a valid certificate, the request is properly signed and ifthe original request comes from one of its subdomains. In a last step, the CA signs therequested certificate and sends it to the originating server.

Top-level servers send their requests directly to the CA, as they do not have a mas-ter. Top-level servers play a unique role in the Nimbus infrastructure and get their cer-tificate from the CA by explicit appointment.

Once the server received a certificate, communication with this server can beencrypted. As a correspondence host can request the signed certificate, it can be sure tocommunicate with the right server. A configuration consists of a number of XML files,each containing, among other details, the domain name and the domain’s geometricextension (see section 11.4.1 on page 162). In principle, a location server could changeits configuration after receiving a signed certificate. To avoid, or at least detect a for-gery, the configuration files have to be signed as well by the CA. Other servers or cli-ents could request the signed configuration files. So, it is possible to detect, whether aresolution reply matches a certified configuration.

Security Commands

In addition to the commands shown in section 6.3.5 (page 69), further commands con-trolling security mechanisms are required (table 9-3).

Table 9-3. Nimbus security commands

Command Type Direction DescriptionVIEW_CERTIFICATE Stream/

InsecureClient → LSLS → LSClient → CALS → CA

ask a server to transmit its signed certificate

VIEW_SIGNED_XML Stream/Insecure

Client → LSLS → LS

ask a server to transmit its signed XML configuration files

REQUEST_CERTIFICATE Stream/Insecure

LS → LSLS → CA

request a new certificate from a master or CA

APPROVE_CERTIFICATE Stream/Secure

LS → CA the master approves a certificate request

132 Jörg Roth

The last two commands are used to manage so-called certificate revocation lists(CRLs). CRLs contain certificates which are not longer valid as their private keys werediscovered, e.g. as a result of an intrusion.

Security commands use the stream method for communication (see page 125). Asstreams are bidirectional, they allow the usage of authentication mechanisms. Securestreams are created as follows:

■ First, the servers exchange their certificates, which include the public keys of therespective key pairs. Each server checks, if certificates are signed by the CA.

■ The public keys are used to authenticate each other using an RSA encryption [130]with 2048 or 4096 bit.

■ Together with the authentication, a secure symmetric key is exchanged using amechanism similar to the Diffie-Hellman key exchange [39]. To avoid replayattacks, secure random numbers are used for this.

■ As asymmetric encryption is time-consuming, further communication is done withthe symmetric encryption AES (Advanced Encryption Standard [32]) using a 256 bitkey.

Messages may be divided into several blocks of encryption. To each block, a messageauthentication code (MAC) is attached, thus the receiver can check if the correspond-ing partner is still the same.

Not all commands have to be sent in secure mode. Any host should be able to viewa server certificate and check the signed configuration files. As the integrity of a certif-icate can be checked using the signature, communication does not have to beencrypted.

From the inter-server protocol, the commands INTER_SERVER_REGISTER,PING, INTER_SERVER_PROPAGATE, INTER_SERVER_GEOCAST are transferredin secure mode. The commands INTER_SERVER_LOOKUP, INTER_SER-VER_LOOKUP_REPLY are insecure because commands in the lookup phase use unidi-rectional unicast or multicast which do not allow key exchange.

Authenticated Registration

Fig. 9-4 shows a secure variant of a location server registration.After looking up a master, the subserver can optionally view and check the master’s

certificate. As a next step, the server creates a key pair and sends a REQUEST_CER-TIFICATE along with the XML configuration files and the public key. The serverchecks the request and passes these data to the CA. As this communication is secure,the CA can rely on the authenticity of the master.

ISSUE_CERTIFICATE Stream/Secure

CA → LS the CA issues a certificate to the originating server

UPDATE_CRL Stream/Secure

CA → LS the CA updates the certificate revocation list

VIEW_CRL Stream/Secure

Client → CALS → CA

ask the CA to transmit the certificate revocation list

Table 9-3. Nimbus security commands (continued)

Command Type Direction Description


The CA may perform further checks. Then the signed certificate is sent to the originat-ing location server. As the CA knows the server’s public key, this communication canalready be encrypted. Thus, the CA knows that the receiver of the certificate is the cor-responding location server. From now on, inter-server commands are secure, thus par-ticipants can rely on the authenticity and integrity of the contents.

9.4.2 X.509 Certificates

The X.509 is an ITU (International Telecommunication Union ITU) standard for publickey infrastructure. X.509 specifies, among other things, standard formats for publiccertificates and certificate revocation lists. X.509 certificates exist in versions 1-3,whereas versions 2 and 3 extend the certificate formats for the needs of the usage in theInternet [24]. Nimbus uses version 1 as the extensions are not needed. An X.509 certif-icate version 1 contains the following entries:

■ X.509 certificate version number (i.e. "V1")

■ the serial number of the certificate defined by the CA,

■ the cryptographic signature algorithm (i.e. "RSA"),

■ the name of the CA,

■ the name of the owner (i.e. the domain name of the cluster root),

■ the owner’s public key and

■ the period of validity.

Note that the certificate itself does not provide a facility to certificate geometric infor-mation (i.e. the domain area). Thus, the logical Nimbus certificate contains an X.509certificate along with the signed XML file.

Fig. 9-4. Secure server registration (secure commands in grey)

134 Jörg Roth

Fig. 9-5 (left) shows the CA application’s front end. A background task collects certifi-cation requests. The CA administrator can view the list and grant or deny the requests.In the case of a granted request, the originating server is automatically informed.

As the X.509 certificates have a standardized format, Nimbus location servers cer-tificates can be viewed by many operating systems or web browsers (fig. 9-5, right).

9.5 Summary

This chapter presented the Network Kernel Framework, a middleware for distributedapplications in mobile and ad hoc environments. The NKF approach is especially use-ful for small devices, for which traditional middleware solutions are not available. Theframework is modular; for a specific device, a developer may only implement anappropriate subset of modules. NKF can easily be implemented on devices with lowcomputational power. Once an application uses only framework services to access thenetwork, modules for new communication infrastructures, new compression or encryp-tion algorithms and encoding schemes can easily be integrated into the frameworkwithout affecting existing applications. This saves implementation costs.

Nimbus uses NKF both for the server and the client side. On the client side, NKFencapsulates communication with the servers and with the positioning hardware. Onthe server side, NKF allows to integrate security services easily into the communica-tion process which ensures the authenticity and integrity of location servers.

To get authenticated location servers, a certification authority generates certificateson request, where a request is approved by the master location server. As an importantfeature of the certification process, the certification authority also signs the domaingeometry, thus it is not possible for a location server to make undiscovered changes togeometric data.

Fig. 9-5. The CA application (left), certificates in Windows (right)


136 Jörg Roth

10 Location-based Services Using the World Wide Web

Many location-based services such as the Flirt Finder have a specialized userinterface with their own windows system and dialogue control. There is, however,a class of applications which are suitable to run as web-based applications inside abrowser environment. Typical examples are tourist guides which offer location-dependent information pages. Particularly, when an application has to presentgraphics or sound, current browsers with their capability to handle different multi-media data formats are an ideal platform. This chapter presents the PinPoint plat-form, which combines the benefits of the World Wide Web with location informa-tion from the Nimbus framework. With PinPoint, a developer of context-awareweb applications can concentrate on the application function and does not have todeal with different client and server platforms or the capturing of contextual data.Context-aware web applications can use existing web browsers and servers off theshelves, thus developers and end-users can use reliable and well-known softwareenvironments. As applications can react to device capabilities (e.g. their screenresolution), they can produce output in an appropriate format.

10.1 Introduction

The World Wide Web is often viewed as the de facto standard for a huge class of client-server applications. Many accepted server and browser environments for differentoperating systems are available. The established formats and protocols make the Websuitable for different usage scenarios. Convenient development tools allow a developerto create complex applications such as electronic warehouses.

In the current World Wide Web, same requests passed to a server return the sameinformation, regardless of the user's current location, browsing device or current time.As a result, a number of desirable services are not directly available and require modi-fications of browsers and servers. Location-based services such as tourist guides orcontent services which adapt the page to the capabilities of the end-user's device arenot possible in the current version of the Web.

This chapter presents the PinPoint platform for context-aware web accesses. Pin-Point is part of the Nimbus application layer (see chapter 4). The PinPoint platformmeets the following requirements:

■ Arbitrary web browsers off the shelves cooperate with PinPoint. Neither browsermodifications nor plug-ins are required. Only two processes have to be installed onthe end-user device in order to collect contextual information. These processes runin the background and do not need the user's attention.

■ Arbitrary web servers (e.g. apache) and additional server environments such asservlets or CGI scripts work together with PinPoint.

■ Developers of context-aware web applications can use well-established tools, e.g.,web editors to create pages.

■ Contextual information is embedded into web pages and URLs with the help of newtags.

Location-based Services Using the World Wide Web 137

As a main benefit, context-aware applications can be set up with low implementationand development costs, since high-quality and inexpensive browser and server envi-ronments can be used.

10.2 Location-Based Applications in Browser Environments

Typical examples for web-based location-aware applications are tourist or museumguides. Guide [23] and Cyberguide [1] offer information to tourists about the currentlocation and provide web pages presenting pictures of sights, their history, maps orinformation about opening hours. Both systems use modified browsers or require acompletely new browser implemented to display information pages (fig. 10-1, left).

Cooltown [86] is a collection of applications, tools and development environments forlocation-based services and applications. It is mainly based on the World Wide Webinfrastructure. The Cooltown museum, e.g., offers web pages about a certain exhibit,when a visitor is in front of it. The corresponding URLs are transported via infraredbeacons (fig. 10-1, right). Even though Cooltown uses standardized web mechanismsto present content, the mechanism to integrate context information into the data flow isproprietary.

Mobile phones become more and more capable to run powerful browser applica-tions. Location-based services in mobile phone networks use web-like infrastructureslike WAP [65, 179] or i-mode [42] with their corresponding browsers. As an advantage,service providers do not have to deal with render mechanisms on different devices.Users on the other hand can access all services with a standardized browser front-end.Location-based services such as Loco Guide or Night Guide [175] follow thisapproach. Users can look for cash dispensers, hotels, pharmacies, restaurants etc. in the

Fig. 10-1. Location-based applications based on web services: the Guide browser application [23] (left) and the Cooltown Museum (right)

138 Jörg Roth

nearer area. Current GSM-based approaches for location-based services use cell IDs tofind the mobile users current location (see section 3.4.1 on page 28). This informationis only accessible for the mobile phone provider, thus the server for the location-based-service has to reside inside the provider’s network.

The most critical drawback of existing systems is the lack of a unique mechanism tointegrate contextual data into the data stream between browser and server. Existingprojects use two approaches:

■ Modification of existing browsers or development of new web browsers: from thearchitectural point of view, this is the simplest approach, as the context informationoften is available at the mobile user’s site. But modifying a browser or developing anew browser is very cost intensive as current browsers are big software systems.The Mozilla browser [103], e.g., consists of approx. 2 million lines of code.

■ Integration of context information on the server side: web servers are more opensoftware systems than browsers. They offer a number of mechanisms to integratesoftware components into the server program, thus it is easier to introduce an appro-priate component which processes context information. Unfortunately, contextinformation is mainly available at the client’s side. Apart from the GSM example, itis, e.g., difficult for a web server to find out the mobile user’s current location.

PinPoint uses a third approach, where neither browser nor server are involved in thecapturing of context information.

10.3 The PinPoint Approach

PinPoint [137] uses a modified HTTP proxy to extend the traditional web architecture.Web proxies between client and server usually act as relay stations and offer functionssuch as caching or filtering. They typically run on special computers, often inside anintranet. The idea is to move the proxy process to the client computer. The proxyenriches the stream of data in both directions. Neither browsers nor servers have to bechanged and the communication protocol HTTP remains unmodified.

10.3.1 Data Flow in the PinPoint Component

Fig. 10-2 presents the data flow of location-aware web applications using PinPoint.

Fig. 10-2. Data flow in the PinPoint architecture


The data flow extends the flow in the Nimbus framework presented in fig. 4-1 (page 34). The numbers indicate the steps performed by the system in chronologicalorder. Besides the proxy process, a so-called Context Manager is hosted on the clientcomputer. The Context Manager collects relevant context data such as user informationor location. These data are collected either with the help of operating system functionsor with Nimbus location services. The main function of the Context Manager is todecouple the web application from capturing context data. Device properties and userdata are collected once (step 1), while location and time information is updated perma-nently.

For each request of the browser, the system performs steps 2 to 7. Steps 2, 4, 5 and 7belong to the standard web data flow. PinPoint performs the additional steps 3 and 6,which integrate contextual data into the data packets with the help of specific tags (seesection 10.3.3 on page 140). All client processes (i.e. proxy and Context Manager) runin the background. Both processes can be started automatically when the end-userdevice boots up.

10.3.2 Context Information

Dey and Abowd mean by context "any information that can be used to characterize thesituation of an entity", where entity can be a person, a place or a relevant object insidea situation [36] (also see section 2.1 on page 5). This meaning of context covers a widearea including social aspects. Nimbus only uses context information that can be ana-lysed by an application. PinPoint distinguishes three types of context data:

■ Time and space: This information is often viewed as the most important contextinformation. Applications such as tourist guides or navigation systems use thisinformation. Time can easily be measured, as nearly all current mobile devices havetheir individual clock. Applications get space information, especially physical andsemantic locations, by the Nimbus resolution mechanism.

■ Device properties: End-user devices have specific properties which rarely changeover time. PinPoint captures the following data: device type (e.g. mobile phone,desktop computer), whether the device is mobile, the screen resolution and the capa-bility to display colours. These data allow a web application to provide user inter-faces adequate for a specific end-user device. For, e.g., devices with low displaycapabilities, images with low resolution or few colours can be used. This reducestransfer times and allows a device to display images directly without re-computingsize or colour tables. For devices with reduced graphical capabilities (e.g. i-modephones, terminals for blind persons), the web application can provide an alternativepage layout.

■ User identity: The PinPoint component identifies the current user with the help ofthe login name passed to the operating system. If the operating system acceptsunregistered users, a user name is taken from a configuration file. As the login nameis not unique outside a local network, PinPoint uses additional information (e.g. theemail address). It depends on the web application to request further authenticationsuch as a password from the user.

10.3.3 PinPoint Tags

The Context Manager adds context data to the data streams between browser andserver with the help of embedded tags. PinPoint defines a set of new tags, which a

140 Jörg Roth

developer integrates into HTML pages or URLs. The following HTML code illustratesthe concept.

<HTML> <HEAD> <TITLE>PinPoint test page</TITLE> </HEAD> <BODY bgcolor=white> <DIV align=center><H1>PinPoint</H1></DIV> <P> Welcome <A href="http://pi2.fernuni- hagen.de/~__Pusername__">__Gusername__</A> <TABLE border=1> <TR><TD>Phys. position:</TD> <TD>__Gpos__</TD></TR> <TR><TD>Semantic position:</TD> <TD>__Gsempos__</TD></TR> <TR><TD>Date:</TD> <TD>__Gdate__</TD></TR> <TR><TD>Local time:</TD> <TD>__Gloctime__</TD></TR> <TR><TD>Screen resolution:</TD> <TD>__Gscreenx__ * __Gscreeny__ Pixels</TD></TR> <TR><TD>Resolution class:</TD> <TD>__Gsemscreen__</TD></TR> <TR><TD>Colors:</TD> <TD>__Gcolbits__ Bit(__Gcols__)</TD></TR> <TR><TD>Operating system:</TD> <TD>__Gos__ Version __Gosver__</TD></TR> <TR><TD>Device type:</TD> <TD>__Gdevice__</TD></TR> </TABLE> </BODY></HTML>

The proxy replaces tags such as __Gusername__ and __Gpos__ by the corre-sponding context information (i.e. the current user name and the current position). Asthe new tags can occur at arbitrary places inside a page (e.g. even inside an HTML tagor inside a path), a design decision was not to use the HTML or XML style tags (i.e.<TAG...>). Fig. 10-3 shows the resulting page.

For each new tag, PinPoint provides a get and a put variation (denoted as__Gtag__ or __Ptag__). Get tags are replaced when a page is transferred fromserver to client (fig. 10-2 on page 139, step 6), whereas put tags are replaced inside aURL request of a client (fig. 10-2, step 3). The Context Manager transforms put tagswhenever a user follows a link and requests a new page. In most cases, get tags are suf-ficient. In rare cases however, a web application needs context data at exactly the time,a user requests a new page. In these cases, a get tag would have been replaced too early(when the page was loaded).


Table 10-1 presents all PinPoint tags (excluding the leading "__P" or "__G" and thetrailing "__"). Some tags express device capabilities with the help of classes (e.g.__Xsemscreen__). They play a special role. Consider a web page contains animage. To present the image on colour, greyscale and black and white devices theHTML page embeds the following image tag:

<IMG SRC="images/picture__Pcols__.gif" ALT="an image">

The tag __Pcols__ can be mapped to the following values: "BW" for black & whitedevices, "GRAY" for greyscale or "COL" for devices with colour capabilities. A serverjust has to store three images named pictureCOL.gif, pictureGRAY.gif andpictureBW.gif. The appropriate image is loaded automatically without any activeserver elements such as CGI scripts.

Physical locations can either be expressed as a single point or an entire area accord-ing to the model described in section 7.3.1 (page 85), where the single point representsthe centre of the area.

As the result of a semantic resolution may be a list of names, different names areconcatenated to a single string separated by ’;’. Using the area variation of the seman-tic resolution algorithm presented in section 7.3.6 (page 98), the tag sempos onlyreplies domain names which fully cover the location. If the application is interested inthe specific probabilities, the tag semposa can be used, which replies a list of namesand the corresponding probabilities (in %).

Fig. 10-3. A simple PinPoint page

142 Jörg Roth

10.3.4 Security Issues

Security issues were already discussed in section 9.4 (page 130). The PinPointapproach now leads to an additional security problem related to the web servers. Con-text information often has a confidential characteristic. Usually, a mobile user does notwant to, e.g., publish her or his current location to any web server. The World WideWeb on the other hand is an open infrastructure, e.g., any server can participate withouta permission of a trusted organization. This leads to the problem of security and pri-vacy. We have to answer two questions:

■ How can a user be sure that only trusted web servers read context information?

■ How can a user be sure that third parties cannot spy out context information when itis transferred to the server?

To ensure privacy during the transfer process, a user can rely on security and encryp-tion mechanisms used with HTTP. The entire communication can be divided into thetwo segments browser ↔ proxy and proxy ↔ server, where only the latter segmentrequires a security protocol. Note that the browser ↔ proxy communication runslocally, i.e. is usually not vulnerable against attacks. For the proxy ↔ server communi-

Table 10-1. List of PinPoint tags

Tag Description Example

pos physical location 5121.12,N,00732.79,E,123m

posa physical location (area) P(5121.05,N,00732.23,E,123m*5122.30,N,00731.19,E,123m*...)

sempos semantic locations hagen.de

semposa semantic locations (areas) hagen.de,100;volme.river.geo,20

time current time 19:30MET

loctime current local time 19:30

date current date 12.08.2001

screenx screen resolution (x) 1024

screeny screen resolution (y) 768

semscreen screen resolution (class) VGA

cols number of colours (class) COL

colbits number bits for colour 24

username user name Lara Croft

uid user ID (e.g. IMSI) 12392139102

os operating system Windows

osver operating system version 2000 Version 5.00

device end-user device class MOBILEPHONE

mobility mobility class MOBILE


cation, protocols such as Secure Socket Layer or Transport Layer Security can be used.In order to detect context tags inside the data streams, the proxy must be able to read allcommunication between browser and server in plain text. Protocols which forwardencrypted data via the proxy (e.g. tunnelling SSL) cannot be used.

The first question is more crucial. On one hand, the user explicitly wants to transfercontext information to some servers in order to get a specific service. On the otherhand, the system should protect users against servers which want to spy out contextinformation. To address this problem, a PinPoint user configures two lists: a black listcontains all web servers which are untrusted, and a white list contains all web serverswhich are viewed as safe. In addition, a user configures three profiles: one for black listservers, one for white list servers and one which applies for unlisted servers. Each pro-file defines for all context data, whether a specific entry will be transferred or not. Ifthe user does not define an explicit rule, the Context Manager asks the user before con-tacting a server. The default profiles provided by PinPoint are:

■ black list: transfer no context information,

■ white list: transfer all context information,

■ unlisted servers: always ask the user.

With profiles, a user can define the security behaviour in a very fine-grained manner.Note that web servers are identified by their Internet address. In addition, a certificatemay be required to put a server into the white list.

Up to now, security issues are discussed from the end-user's viewpoint. There is,however, another important question: How can a server trust context data transferredby a client? This question may be relevant for a number of applications, e.g., mobilepayment or fleet management systems. Currently, this is an open issue, since all con-text data are generated by a possibly untrusted client. Authenticity of context data canonly be proofed, if additional services, e.g., tracking systems or certification authoritiesoutside the platforms, are used.

10.3.5 Implementation Details

The entire PinPoint component (i.e. PinPoint Proxy and Context Manager) was real-ized in Java. The proxy process is a modified Muffin web proxy. The source code ofMuffin is publicly available [104], thus it was easy to extend the proxy to communicatewith the Context Manager (steps 3 and 6 in fig. 10-2 on page 139).

The Context Manager is designed as a background process; however, it provides arudimentary user interface. For testing and debugging purposes, the user can put theContext Manager into a simulation mode, in which the user can enter context datadirectly. With the help of the simulation mode, the developer can, e.g., easily test thetourist guide without moving around. The Context Manager prototype contains driversto read system and user data.

10.4 A Tourist Guide with PinPoint

To verify the PinPoint approach, a web-based tourist guide was developed on top ofNimbus (fig. 10-4). The tourist gets a map which presents her or his actual environ-ment. The current location is marked with an arrow (upper part of the screen). The usercan switch between different maps, i.e. can zoom in and out. For a specific location, theapplication lists information and interesting sights in the area based on the user’ssemantic location (lower part of the screen).

144 Jörg Roth

Since the web application can query the display capabilities of the end-user's device, itcan generate appropriate output. Map images, e.g., are generated according to thedevice’s screen resolution before they are transferred. The map for low resolutiondevices is not just downscaled from the original map, but a different map is generated,which only provides most important entries.

The tourist application passes context data to the server with the help of tags embed-ded into a requesting URL. Each time the browser requests or refreshes a map, the fol-lowing URL is sent to the server:

http://carmen.fernuni-hagen.de:8080/servlet/PinPoint ? serve=page & pos=__Ppos__ & sem=__Psempos__ & quality=__Pscreenx__x__Pscreeny__

In this example, carmen is the tourist guide server, running a servlet which maintainsthe maps and computes the user's position inside the map. The PinPoint componentreplaces the tags by the actual context information. The servlet reads the actual valuesfrom the current parameter set given to the servlet. In order to be up to date when thetourist moves, a small JavaScript procedure embedded into the main page requests anew map every 10 seconds.

10.5 Summary

PinPoint is a platform to develop context-aware web applications. The platform con-sists of a client extension for the Nimbus framework. Web servers and browsers remainunmodified, thus web applications can use widely available and reliable software com-ponents. PinPoint especially avoids system-dependent browser plug-ins. Context-spe-cific processes and devices are strongly separated from the web application, thus the

Fig. 10-4. The PinPoint tourist guide


developer can concentrate on the application function and does not have to strugglewith positioning systems and device protocols.

PinPoint provides three types of context information: space and time, device prop-erties and user's identity. Web applications can use location data without consideringthe used positioning system as they can fully rely on the Nimbus positioning capabili-ties.

Currently, there exists a huge number of mobile web-enabled end-user devices withdifferent display capabilities, e.g. notebooks, sub-notebooks, palmtops or cell phones.An ideal web application does not rely on the browser to generate an appropriate userinterface. With the help of several PinPoint tags, the web application can ask the devicefor its screen resolution, capability to display colour etc., and generate an optimizedpage layout. A tourist guide application demonstrated the strengths of the PinPointcomponent. It uses location information as well as device properties to produce anappropriate output.

146 Jörg Roth

11 Acquiring, Storing, and Processing Domain Data

Up to now, domain areas are described in an abstract way. The algorithms that usedomain areas assume that the required geometric operations can be computed ef-fectively. This chapter describes how geometric areas are stored and processed in-side the Nimbus framework. An import of real domain data from land surveyoffices generates a reasonable number of realistic domains for further evaluations.In the second part of this chapter, the import process is presented.

11.1 Introduction

The algorithms presented in the chapters 5, 6 and 7 need to represent domain areas andlocation sensor output. The algorithms assume a number of geometric operations, suchas the intersection or union of two areas. In detail, they have to

■ specify areas d.c and (d) of domains and the area A of a location output,

■ effectively test, whether a point p is inside an area or not,

■ execute the operations intersection, union and difference on areas,

■ compute certain details of an area, such as the diameter or the volume.

The required geometric operations can be accessed via the Nimbus component Geome-try & Geodesy.

The representation of spatial data in the area of geographic information systems andgeo databases has a long tradition. The next section provides an overview of the differ-ent representations.

11.2 Spatial Data

Geographic information systems (GIS) and spatial databases provide powerful mecha-nisms to store and retrieve location data [164]. Such systems primarily concentrate onaccessing large amounts of spatial data. In the Nimbus approach, the amount of dataper server is low compared to geographic information systems. However, the charac-teristics of data and the required operations are similar.

According to Breunig [18], geo data can be divided into a number of geo-objects,each of them representing real geographic entities such as rivers or abstract entitiessuch as city borders. A geo-object can be described by the following information:

■ an identifier (e.g. a unique name),

■ structure information (e.g. the relations between objects),

■ the geometry,

■ and a thematic description by attributes (containing e.g. the type of the object).

Sometimes, information about relations of objects is solely stored by their geometry. Incontrast, some systems (e.g. street navigation systems) rely on topological relationsbetween objects. From the geo scientist point of view, the thematic description plays animportant role. It describes e.g.

Acquiring, Storing, and Processing Domain Data 147

■ the classification of the object (e.g. topographic, land register, mineral resources,land development, trade and industry),

■ the sub-classification (e.g. river, lake or source for topographic entities)

■ statistical data (e.g. number of cows per square kilometre, coal-mining capacity intons per year),

■ owner of the corresponding area (for land registers),

■ data about the acquisition process (e.g. age of the database entry, operator whoenters the data, or accuracy information).

To organize thematic attributes, either layers or classes can be used. Using layers is theolder approach where layers were represented by transparent foils, each representing aspecial type of geo-object. Maps were constructed by piling these foils and copying theresults. The modern approach relies on class hierarchies, similar to class hierarchies inobject-oriented software development. Classes of geo-objects can be subclassed in asimilar way as software objects.

From this point of view, Nimbus domains are typical geo-objects, as they have aname (d.name), relations to other objects defined by the logical links and a geometricdescription (d.c). Up to now, domains do not contain explicit thematic attributes, butget their classification from the hierarchy (e.g. geo). As a result of the import of realland survey data (see below), thematic attributes are attached to the domain objects.

Properties of Geo-Spatial Data

From the resolution algorithms’ point of view, the geometry is important. The geomet-ric representation of geo-objects can be classified as follows:

■ accurate vs. approximated representation,

■ raster, vector, or analytical representation and

■ the number of represented dimensions.

These classes are not completely independent of each other. Accurate representationsrepresent the geometry exactly. Typically, only simple geometric shapes such as circlesand rectangles can be represented accurately, thus typical spatial databases approxi-mate shapes. Especially natural objects such as rivers cannot be represented exactlywith a finite storage space.

A geometric representation can further be divided into a raster, vector or analyticalrepresentation (fig. 11-1). A raster represents a grid of elements, each of them eitherbelongs to the geo-object or not. Multiple grids can represent different objects. As anadvantage, some required operations such as the intersection of two objects have a sim-ple implementation. However, more accurate rasters require huge storage spaces.

The vector representation uses points and lines to represent the geometry of geo-objects. The accuracy depends on the accuracy of a point representation and thenumber of lines spent to represent curved borders. To achieve a high accuracy, vectorrepresentations usually have a lower storage space requirement than comparablerasters, but the implementation of the required operations is more complex.

As a last representation, the geometry of a geo-object can be stored analytically, i.e.with the help of geometric primitives such as circles and rectangles. Some shapes canbe exactly specified with a low amount of storage space, but there is no easy way torepresent arbitrary shapes as required to represent geographic objects. Analytical repre-sentations do not play an important role for geo information systems.

148 Jörg Roth

A last classification considers the dimension of the represented geometric object(fig. 11-2):

■ 2D representations project all objects to the earth’s surface and only store projected,i.e. two-dimensional data. Even though a lot of information is lost, this representa-tion is suitable for many scenarios. E.g. city maps usually only contain 2D data.

■ 2+1D representations contain height data which is stored independently of the 2Ddata. Height information can be viewed as an independent layer of information.

■ 2.5D representations store height information as an attribute of the geometricdescription (i.e. attached to a polygon point in a vector representation). As theheight is only an attribute, it does not actually belong to the geometric description.Each point is still identifiable by its x-y-coordinates.

■ 3D representations fully store geo-objects in three dimensions.

Fig. 11-1. Different geometric representations (2D)

Fig. 11-2. Dimensions of geo data


In addition to the space dimension, often the time is added as a representation dimen-sion. Spatio-temporal representations (3D space, one time dimension) consider themovement of objects over time. With this information, queries like "where was thecourse of the river in the 19th century?" can be answered.

11.3 Spatial Data in Nimbus

As mentioned above, Nimbus is not actually a geo database, but each location serverprovides similar functions. Thus, the following design decisions have to be faced:

■ Which kind of spatial representation is used: raster, vector, or analytical?

■ How many space dimensions are supported?

Note that in principle Nimbus supports domains that change their geometric extensionover time, but time is not considered as a dimension. Nimbus is not interested in stor-ing older domain states to retrieve past domain information.

As Nimbus domain data both contains larger areas (e.g., countries) and smallobjects (e.g., rooms inside a building), the raster representation is inadequate. Smallgrid cells require huge storage spaces and some operations (e.g. the intersection ofareas) have a long execution time. As a consequence, location servers use the vectorrepresentation.

Looking at the dimensions, a first version used only a 2D representation. There existeffective algorithms to perform the required polygonal operations. Unfortunately, somedomains require height information. An extension is able to represent 3D objects, butstill uses efficient 2D operations. We start with a 2D approach which is later extendedto the third dimension.

11.3.1 Two-Dimensional Data Representation

Domain data representation in Nimbus can be characterized as follows:

■ All domains of a specific location server are stored in XML format. The locationserver reads all XML files during startup.

■ As a location server only has to handle a small number of domains, the approachcan avoid geo databases and uses instead a lightweight toolkit to process polygonaldata. All geometric data are processed in the runtime memory.

There exists a huge variety of standard algorithms to process polygonal data (e.g. [26])for the so-called polygon overlay operations which include intersection, difference andunion of two or more polygons. The OpenGIS consortium publishes recommendationsfor a toolkit for vector data processing [117]. The JTS (Java Topology Suite) [174] fol-lows these recommendations. JTS provides efficient and robust overlay operations andfurther contains test functions for points in polygons. A so-called buffer operation com-putes all points within a certain distance to a given geometric object.

The toolkit allows the expression of different geometric objects as presented in theUML class diagram (fig. 11-3, left).

150 Jörg Roth

This class hierarchy contains classes that represent

■ points that are the primitives to build more complex structures,

■ lines that are open or closed lines, the latter called linear rings,

■ polygons that consist of a boundary (shell) and holes,

■ multipolygons that represent multiple polygons (fig. 11-3, right) and

■ classes which abstract lower-level classes (e.g. the geometry represents any geomet-ric structure).

From these classes, the multipolygon is the most important class for Nimbus purposes.Simple polygons (i.e. linear rings) are not expressive enough to model domains. Somedomains can only be expressed by polygons with holes (e.g. streets forming a loop).Further, some domains or areas contain unconnected parts, thus have to bedescribed by multiple polygon areas.

Nimbus uses the multipolygon to express all kinds of areas: domain areas d.c, (d)and areas describing a location measurement A, intermediate results of the resolutionalgorithms and the area ♦(p) for the cache mechanism. As the algorithms only have todeal with one object type, it is possible to encapsulate areas by an own object type,which wraps the corresponding geometric toolkit representation.

Required Geometric Operations

In principle, the geometric toolkit can be replaced without reengineering the entireNimbus framework. For this, Nimbus contains a wrapper component to the geometrictoolkit. The wrapper is also required for another reason: intersection operations mayundesirably return a line or point, if the arguments have a common border or touch in asingle point. Even though this is geometrically true, points and lines are not consideredas areas inside the Nimbus framework as they do not have a surface. As a consequence,these geometry elements have to be removed from the intersection result.

Table 11-1 shows the required geometric operations in the Nimbus framework andhow they are mapped to the JTS/OpenGIS framework.

Fig. 11-3. The Geometry class hierarchy according to [117] (left) and multipolygons (right)


Most of the required operations are directly available from the toolkit. Some remarksare to be made:

■ The check of M1 ∩ M2 ≠ {} could in principle be performed by first computing theintersection and then checking, if the result is empty. The toolkit can process theintersects operation more efficiently, as it can terminate whenever it detectsany intersection area and does not have to compute the intersection exactly.

■ For the computation of the areas and ♦, the union can be avoided as it only pro-vides an intermediate result subtracted from another area. Instead, each area can besubtracted separately.

■ The diameter operation required for the acc value cannot be computed directly bythe toolkit, but there exists an efficient algorithm [154] which works with the pointsof the convex hull of a polygon.

■ The distance operation required for the computation of ♦’ in the simple cache modemeasures the distance to the multipolygons’ border, while the JTS/OpenGIS methoddistance measures the distance to any point enclosed by the multipolygon. If the

Table 11-1. Mapping of required operations to the geometric toolkit

Required Operation

Usage in Nimbus(LS=Location Server, C=Client)

JTS/OpenGISOperation

M1 ∩ M2 compute ♦ (LS or C)semantic resolution/area (LS or C)collection component in VPS 3 (C)

M1.intersection(M2)

M1 ∪ M2 compute (LS)compute ♦ (LS or C)

M1.union(M2)

M1 \ M2 compute (LS)compute ♦ (LS or C)semantic resolution/area (LS or C)proximity resolution (LS or C)

M1.difference(M2)

vol(M) semantic resolution/area(LS or C) M.getArea()

diameter(M) compute acc (C) M.convexHull() +diameter algorithm

distance(M, p) compute ♦’ (C) M.distance(p)

distance(M1, M2) proximity resolution (LS or C) M1.distance(M2)

M = {} ? semantic resolution/area (LS or C)proximity resolution (LS or C)

M.isEmpty()

M1 ∩ M2 ≠ {}? check ~ (LS) M1.intersects(M2)

M1 ⊂ M2? check (LS) M2.contains(M1)

p ∈ M? check cache hit (C)compute ♦ (LS or C)semantic resolution/point (LS or C)

M.contains(p)

find any p ∈ M semantic resolution/area (LS or C)proximity resolution (LS or C)

M.getInteriorPoint()

152 Jörg Roth

point is inside the multipolygon, the distance operation returns always 0. To get use-ful results in this case, the distance function has to extract the respective borderlinestring from the multipolygon.

The internal format for most computations uses degrees of latitude and longitude inWGS 84 (World Geodetic Survey 1984) [47]. Distances based on degrees can only beused for comparisons. For distances in m or km, a great circle formula is used. To com-pute the vol function, degrees are converted into plane coordinates.

Weak Client Issues

Looking at the initial design goal 3a (page 35), the implementation has to considerweak clients with low computational power, such as current mobile phones. The com-putational power of mobile devices increases with the same speed as the power ofdesktop computers, with a delay of a few years. Therefore, the following considera-tions perhaps are obsolete in some years. However, for current mobile clients it has tobe checked, whether some functions can effectively run on mobile clients. We examinethe operations in table 11-1 and check, if they can effectively be executed on clients(table 11-2).

Two client types can be distinguished:

■ Strong clients have the capability to run all geometric functions with the JTS/OpenGIS or a similar toolkit. Especially intersection and difference operations canbe executed.

■ Weak clients are reduced to the necessary geometric functions. More complex func-tions are either approximated or shifted to the location server.

Table 11-2. Weak and strong client requirements

Nimbus Operation Weak Client Strong Client

compute ♦ shift to server in inbound mode or use ♦’ (simple cache mode) instead

M1 ∩ M2M1 \ M2

M1 ∪ M2

compute ♦’ distance(M, p) distance(M, p)

compute acc approximate with bounding box diameter(M)

semantic resolution/point p ∈ M? p ∈ M ?

semantic resolution/area shift to server in inbound mode M1 ∩ M2M1 \ M2vol(M)M = {}?find any p ∈ M

proximity resolution shift to server in inbound mode distance(M1, M2)M1 \ M2

M = {}?find any p ∈ M

check cache hit p ∈ M? p ∈ M?

collection component in VPS 3

simple approach: only collect most accurate

M1 ∩ M2


There are three critical operations not computable for weak clients: computing the ♦areas (for caches entries), the area semantic resolution algorithm and the proximity res-olution. All three can be shifted to the location server in inbound mode.

To avoid the computation of ♦ and still use the outbound mode, ♦’ can be usedinstead (see section 6.4 on page 75). Checking for cache hits cannot be shifted to aserver as the main reason for the cache is to avoid network transactions. Thus the mini-mum requirements for a weak client are

■ to execute the test whether p ∈ M and

■ to compute the minimum distance of a point p to the border of M.

If a JTS/OpenGIS implementation is not available for clients, these operations have tobe re-implemented. Fortunately, these are simple operations, even for weak clients.Testing of inclusion in simple polygons only needs O(n) steps for n edges. This test caneasily be extended to polygons with holes and multipolygons. Also the distance opera-tion can be performed in O(n) steps.

11.3.2 Considering the Third Dimension

Two-dimensional areas are sufficient for many domains. As our world is three-dimen-sional, for some domains it is necessary to take into account the third dimension. Someexamples:

■ A street crosses another street using a bridge. From the ground plan there is an over-lapping area, thus algorithms have to consider the user’s height and the height infor-mation of the respective streets to decide in which domain a user currently resides.

■ Inside a building with some storeys, the current room can only be identified usingheights.

In principle, location servers could store a domain in three dimensions with the help ofa volume model similar to those in CAD systems (fig. 11-4, left). With such a model,domains could have arbitrary three-dimensional extensions, but two disadvantageshave to be considered:

■ Location servers cannot use the polygon operations presented above.

■ Sometimes it is difficult to specify the three-dimensional domains, as most sourcesfor domain data are basically two-dimensional, e.g. maps or ground plans from landregisters.

Fig. 11-4. Representing domains in three dimensions: full 3D (left), Nimbus domain representation (right)

154 Jörg Roth

As a solution, Nimbus avoids a full 3D representation and uses a reduced 3D represen-tation as shown in fig. 11-4 (right): a domain has a polygonal projection on a referencesurface defined by the WGS 84 ellipsoid [47], which roughly can be viewed as anapproximation of the earth's surface.

The third dimension of a domain is represented with the help of two height profiles– a top and a bottom height profile. A height profile can be

■ a surface specified by a raster, where the grid elements define height values,

■ a constant height, i.e. a surface parallel to the reference surface, or

■ unspecified, i.e. the domain either extends to the sky or to the earth's centre.

Not all conceivable three-dimensional volume elements can be projected to a polygonor can be limited by two height profiles. As a consequence, some objects such as irreg-ular polyhedrons cannot be represented, but most conceivable realistic domains can bedescribed.

The question is how to set the height profiles in reality. First, there is a huge class ofdomains, where the height is uncritical, e.g. countries or states. Domains either leavethese height profiles unspecified, or can use constant heights such as [178 m...181 m]for a specific floor inside a building. For domains that require precise height profiles(e.g. streets), height data as provided by land survey offices can be used. Fig. 11-5shows a height profile of the city of Hagen produced by a German land survey office[92]. Height profiles contain a number of reference points, in, e.g., a grid of 10 m.Interpolation functions can easily compute height values between the grid points.

Fig. 11-5. Height profile of the city of Hagen (only grid, top; with map texture, bottom)


Performing Three-Dimensional Geometric Operations

In principle, all required geometric operations (see table 11-1 on page 152) could beextended to the third dimension. As an example, fig. 11-6 shows the intersection.

As there always exists a polygonal 2D projection of an area, two-dimensional opera-tions can be isolated from height operation and can rely on the efficient 2D operationsalready available. The 3D intersection operation first uses the 2D intersection takingthe projected polygons. To construct the new bottom and height profiles for each pro-file’s grid point, the maximum (for bottom) or minimum (for top) of the input profilesis taken.

It is simple to test, if a point is inside a domain: the test first checks with the polygoninclusion test, if the 2D projection is inside the projected polygon of the domain. If not,the result is negative. Then it computes the domain's height values at the checked posi-tion. If the height is inside the height interval, the result is positive.

Similar to these operations, all other operations could be realized in principle. How-ever, some disadvantages have to be considered:

■ In some cases, the 2D projection of the result is smaller than expected from the 2Doperations. E.g. the projection of an intersection is smaller than the 2D intersectionof the projected areas when some parts of height intervals do not overlap. As a dis-advantage, the potential computation of the smaller projected area has to considerboth polygonal and raster data in the same algorithm.

■ The difference and union operation may result in more than one top and bottomheight per grid element.

■ It is time consuming to run through all involved grid elements for every geometricoperation.

Thus, Nimbus uses another mechanism and considers the height profiles very late inthe resolution process. Time consuming grid operations are avoided. All geometricoperations are carried out in 2D, but height profiles of the involved domains are passedthrough the resolution process. As a consequence, some domains presented as a seman-tic resolution result do not cover the required height. Such domains area called phan-tom domains. In a final step of the resolution process, the phantom results have to befiltered out using the height information.

Fig. 11-6. Intersecting 3D areas

156 Jörg Roth

Fig. 11-7 illustrates the mechanism. The scenario contains three cylindrical domains.From the ground plan, the user resides in all three domains, therefore all these domainsare considered as results in the first step. After checking the height intervals, the resultonly contains the uppermost domain.

Location Sensor Output in Three Dimensions

Output of location systems may also have three dimensions. A location sensor output A(see section 7.3.1 on page 85) may contain two height intervals describing the possiblemaximum and minimum of the user’s altitude. As a result, A is a right prism. In thecase of GPS, e.g., it is a cylinder with the radius of 25 m and a height of 43 m (seetable 3-1 on page 21). If the positioning system does not provide any height informa-tion (e.g. positioning using GSM cells), A remains two-dimensional. The advantages ofthis approach are:

■ If the positioning system does not provide any height information, the resolutionprocess can entirely run in 2D.

■ If the positioning system provides height information, only those domains whichcontain height data stress the resolution process with their height profiles.

However, there are some disadvantages:

■ In some situations a considerable amount of phantom domains are first replied andthen removed during the final check. E.g., inside a building, all rooms covering theuser’s 2D coordinate, even in different storeys are first returned as a result. The cli-ent finally chooses the one of the appropriate storey in the final check.

■ The ♦ areas may be smaller than necessary. Domains which overlap from the viewof the ground plan reduce the size of the ♦ areas even though the domains are at dif-ferent heights. This reduces the cache effectiveness.

■ The computation of the probability values pr (only based on 2D information) has tobe corrected after executing the area variation of the semantic resolution.

■ In the complex cache mode, height profiles have to be stored inside the client’scache.

The first two points affect the efficiency of the used algorithms, but are not critical.

Fig. 11-7. Phantom domains


The correction of the pr values works as follows: after the area variation of thesemantic resolution returns all domains which are inside or cut the location area A inthe plane, the volumes of the three-dimensional areas inside A are computed. Thesevolumes lead to the 3D pr values. As only the volume values are required, the crucialthree-dimensional intersection (see fig. 11-6 on page 156) is avoided.

The client’s cache is the most critical point. As cache functions cannot be shifted tothe server, the client has to store height information locally. An example gives animpression about the space needed to store a height profile: consider a domain which

covers an area of 1 km2. Using a 10 m grid and a height representation with a resolu-tion of 10 cm covering a range of 0 - 200 km, a height value needs 21 bit. As a result,the corresponding height profile needs 26 KB. Even though this is a small amount ofmemory space for desktop computers, for current mobile phones this requirementimposes heavy load on storage space and communication link. As a solution, a clientcan use the simple cache mode. A location server can compute a three-dimensional ♦’describing a cylinder, which can easily be stored and checked in the client’s cache.

11.4 Import of Data from Land Survey Sources

To reach a useful domain coverage, it is necessary to import geo data from existingresources. Commercial systems in the area of location-based services often import geodata from hundreds of geo spatial databases [145]. To investigate import issues, twogeo data resources are exemplarily used:

■ TIGER/Line file [171],

■ ATKIS geo database [5].

The TIGER/Line files are created from the Census Bureaus TIGER (TopologicallyIntegrated Geographic Encoding and Referencing) database of geographic informa-tion. TIGER was developed at the Census Bureau to support the mapping and relatedgeographic activities required by the decennial census and sample survey programs.

The files contain geographic objects such as roads, railways, rivers, lakes, and polit-ical boundaries covering the entire United States. As the files contain polygonal dataabout these objects, the type and name, they are ideal sources for Nimbus domains.From this data set, a subset of about 1300 locations in the San Francisco Bay Area wasused to create configuration files for the location servers [59, 60].

Fig. 11-8. Hierarchies imported from the TIGER/line files

158 Jörg Roth

The resulting hierarchies are presented in fig. 11-8. As the TIGER/line files werealready close to the intended representation, the import was easy. Mainly, the importcomponent has to parse the files, collect the polygons and map them to the respectivehierarchies.

11.4.1 Import of Data from ATKIS Data Files

In contrast to the TIGER/Line files, the import process from the ATKIS geo spatialsource was more complex. ATKIS (Amtliches Topographisches KartographischesInformationssystem, in English: official topographic cartographic information system)provides geospatial data for governmental purposes in Germany. The ATKIS systemunites the distributed data of different land survey offices of the German states. Usu-ally, offices using these data have direct access to ATKIS databases, but private personsor companies can purchase parts of the data exported from the database and exportedas EDBS data [4, 108, 109, 92]. For the Nimbus project, data covering an area of 84

km2 in the area of Hagen was purchased. It contains approx. 80000 EDBS recordswhich were converted to approx. 8000 Nimbus domains.

The entire import can be divided into eight steps:

1. Parsing and Interpreting EDBS Records

EDBS files are text files. Each text line defines a nested multirecord which containsrecord-specific data and a number of subrecords. Fig. 11-9 outlines a part of the syntaxof EDBS files.

The main task of the first step is to parse the record elements such as Gauß-Krügercoordinates and to build the deep structure of an EDBS record. As the internal formatfor further computation describes degrees of latitude and longitude, coordinates have tobe converted.

2. Merging Records to Raw Spatial Objects

The next step merges certain EDBS records to a single spatial object. This is because asingle EDBS record often does not describe a spatial object, but only a part of it.Fig. 11-10 shows the possible contents of an EDBS records.

Each record contains a start coordinate and no, one or multiple end coordinates. Foreach end coordinate a sequence of segments exists which can be straight lines orcurves. A record may define area objects, a single line or a point.

EDBS = EDBSHeader {EDBSLine}EDBSHeader= "EDBS" mapID ...EDBSLine = Lineheader (ULOBNN | ULTANN)ULOBNN = "ULOBNN " ULOB0000 {ULOB100F} {ULOB200F}ULOB0000 = GaußKrügerCoord (* defining the start value *)ULOB100F = ULOB1000 {ULOB110F} {ULOB1200}ULOB1000 = GaußKrügerCoord linetype (*defining a line segment *)ULOB110F = layer ATKISclass objectIDright objectIDleft ...ULOB200F = ...

Fig. 11-9. Part of the EDBS syntax


Line and point objects directly represent spatial objects. Line objects represent, e.g.streets, where point objects represent river sources or archeological sites. Area objects,in contrast, have to be merged by several EDBS records. Each record defines a certainsegment of a border of a number of area objects. In this step, different segments of asingle object have to be collected and combined to a number of closed polygons.Unfortunately, EDBS defines which objects reside on the right and left sides of a seg-ment, but not, how these segments are connected. Thus, the collection process has tocheck, if the end points of different segments are identical in order to construct closedpolygons. As related EDBS records do not necessarily appear nearby in the EDBS file,this is a time and memory consuming process. In addition, this step converts curvesinto a number of straight lines as the Nimbus area representation does not supportcurves.

In our example, the 80000 EDBS records were converted to approx. 13000 spatialobjects.

3. Merging Raw Spatial Objects to Geo-Objects

Geographic objects exported from the AKTIS database are cut according to the Gauß-

Krüger grid (i.e. 1 km2 cells). Larger objects, e.g. rivers, are thus represented as severalclosed areas, each of them fits perfectly into a Gauß-Krüger cell. This simplifies therendering process for certain map applications, but is inadequate for location servers.So the import process has to collect related areas and connect them to the original area.

Another type of merging is necessary for street objects. ATKIS represents a street bysegments, each defining the part from one crossroad to another. As domains shouldstore all parts of an area, all street segments are merged to a single object.

In total, the import merged the 13000 objects from the last step to approx. 8000objects.

4. Converting Line- and Point-like Geo-Objects to Areas

Some objects in the original representation are line- or point-like. Since Nimbusrequires domains to have a certain extension, the import process has to create polygonsfrom lines and points. For this, the buffer operation offered by the JTS/OpenGIS toolkit(fig. 11-11) is used.

Fig. 11-10. Objects represented by EDBS records

160 Jörg Roth

A buffer encloses all points within a certain distance to the line or point. If the lineforms a ring (a street representing a roundabout), the result is a polygon with a hole.Single points are presented by octagons.

Unfortunately, the required buffer size is not part of the original data. The importprocess chooses an appropriate size using the object class. E.g., streets get fixed widthsfor every street type such as highways, country roads, or streets in towns.

5. Finding Names of Geo-Objects

An important attribute of a domain apart from its geometry is its name. As a next step,an appropriate name has to be looked up. For named objects such as rivers, historicsites, suburbs, streets, etc. ATKIS already contains an appropriate name. For otherobjects (forests, farmlands, housings etc.) often no name is available. In these cases,Nimbus uses the object’s class together with the unique EDBS object ID (e.g.TowerA01ZR65). To manually assign names, the Nimbus import tool allows the def-inition of own names for each object.

6. Finding the Hierarchy and the Position Inside the Hierarchy

The set of ATKIS objects inside the database is flat, i.e. the objects are not related toeach other. To build the required Nimbus structures, objects need to have an appropri-ate position inside the hierarchies. The import process uses two criteria: the object’sclass and its physical location. It maps objects according to a number of rules such as:

■ object class is housing and location is inside a suburb: <name>.<suburb>.<city>.<country>

■ object class is river: <name>.rivers.geo

■ object class is street and location is inside a city: <name>.<city>.roads.traffic

It is possible to override these rules and manually assign the hierarchy and positioninside the hierarchy.

7. Integrating Meta Data

Up to now, the domains do not contain any meta data. ATKIS objects contain a classifi-cation reusable inside the Nimbus framework. Some ATKIS classes are, however, notvery expressive: e.g. universities, schools and kindergartens all have the same classifi-cation "area with a special function". Nimbus extends the ATKIS class list to distin-

Fig. 11-11. Generate polygons from line and point objects


guish these objects and allows the manual assignment of classes by the Nimbus importtool.

8. Generating Location Server Files

As a last step the XML files are generated. In addition to concrete domains derivedfrom the ATKIS geo-objects, abstract domains (such as rivers.geo) have to begenerated. Fig. 11-12 shows a generated XML file containing the domain name, thedomain type (abstract or concrete), the definition of the multipolygon and the class def-initions (original ATKIS class and own class).

After the generation process is completed, domains can be reloaded for manual edit-ing with the DomainEdit tool (fig. 11-13).

<?xml version="1.0" encoding="UTF-8"?><lsi> <config domain="Fernuni.fley.hagen.de" servertype="concrete" polyarea="P(5122.7004,N,00729.8548,E,000.0m* 5122.7021,N,00729.8578,E,000.0m* 5122.7514,N,00729.8518,E,000.0m* ... 5122.7004,N,00729.8548,E,000.0m)" atkisclass="2114" lsiclass="22110"/></lsi>

Fig. 11-12. A generated XML file

Fig. 11-13. The DomainEdit tool

162 Jörg Roth

11.4.2 ATKIS Import Result

The imported approx. 8000 domains in the area of Hagen form the basis of evaluationspresented in chapter 12. Fig. 11-14 gives an impression of the imported data.

The data set contains

■ geographic objects: rivers, lakes, sources;

■ nature and agriculture: forests, farmlands, meadows;

■ industrial areas and plants: quarries, industrial areas, water treatment plants, powerstations, power lines;

■ inhabited areas: suburbs, housing areas;

■ special places: sports grounds, graveyards, market places, archeological sites;

■ infrastructure and traffic: streets, parking places, rails, rail stations.

Housing areas are represented by ’blocks’, i.e. the areas are enclosed by their adjoiningstreets. Individual buildings or houses are not distinguishable.

Fig. 11-15 shows the resulting hierarchy structure of imported domains with threehierarchies: A de hierarchy containing the city of Hagen, parts of the city and semanticareas with a relation to these parts. A geo hierarchy contains those domains with ageographical meaning, currently rivers and lakes. Finally, a traffic hierarchy con-tains roads and railways.

The average area covered by a domain is about 40000 m2 and half of the domains

are smaller than 5000 m2. The distribution of area sizes is presented in fig. 11-16.Table 11-3 gives a statistical overview of the generated domains. The table presents

the number of subdomains and associations. As not all 8000 domains can be listed,names starting with ’*’ indicate all subdomains of a specific domain. For these rows,average values for the number of subdomains and associations are presented. Fig. 11-17 presents the distribution of associations among the domains.

Fig. 11-14. Maps of imported ATKIS data


Fig. 11-15. Hierarchy structure of imported domains

Fig. 11-16. Area size distribution (areas up to 20000 m2, class width 250 m2)

Fig. 11-17. Distribution of associations

164 Jörg Roth

Table 11-3. Imported domains in the area of Hagen

Domain#

SubsExample

Subdomain#

Assoc.de 1 hagen.de 0

hagen.de 25 altenhagen.hagen.de 97.4

altenhagen.hagen.de 69 SportplatzB01Y90D-43.altenhagen.hagen.de 45

*.altenhagen.hagen.de 0 - 11.5

berchum.hagen.de 192 Unteres_Wannebachtal.berchum.hagen.de 24

*.berchum.hagen.de 0 - 10.8

boelerheide.hagen.de 122 Kampfbahn_Boelerheide.boelerheide.hagen.de 41

*.boelerheide.hagen.de 0 - 11.0

delstern.hagen.de 124 AbfallbehandlungsanlageA01ZQS2.delstern.hagen.de 63

*.delstern.hagen.de 0 - 12.0

eckesey.hagen.de 102 Wielandplatz.eckesey.hagen.de 37

*.eckesey.hagen.de 0 - 9.4

eilpe.hagen.de 350 Kampfbahn_Struckenberg.eilpe.hagen.de 126

*.eilpe.hagen.de 0 - 12.8

elsey.hagen.de 208 Elseyer_Dorfplatz.elsey.hagen.de 69

*.elsey.hagen.de 0 - 9.9

emst.hagen.de 291 Marktplatz.emst.hagen.de 173

*.emst.hagen.de 0 - 14.0

eppenhausen.hagen.de 189 Goldene_Pforte.eppenhausen.hagen.de 124

*.eppenhausen.hagen.de 0 - 10.5

fley.hagen.de 278 Fernuni.fley.hagen.de 83

*.fley.hagen.de 0 - 9.7

halden.hagen.de 189 TC_Halden_2000.halden.hagen.de 59

*.halden.hagen.de 0 - 11.9

haspe.hagen.de 232 Freibad_Hestert.haspe.hagen.de 148

*.haspe.hagen.de 0 - 11.3

hassley.hagen.de 73 TurmA01ZR65.hassley.hagen.de 37

*.hassley.hagen.de 0 - 11.3

helfe.hagen.de 75 Waldfriedhof.helfe.hagen.de 35

*.helfe.hagen.de 0 - 10.0

herbeck.hagen.de 217 Archaeol_FundstaetteA01ZR4B.herbeck.hagen.de 59

*.herbeck.hagen.de 0 - 9.4

hohenlimburg.hagen.de 296 Platz_der_7_Kurfuersten.hohenlimburg.hagen.de 212

*.hohenlimburg.hagen.de 0 - 8.7

holthausen.hagen.de 143 Holthauser_Bachtal.holthausen.hagen.de 52

*.holthausen.hagen.de 0 - 11.8

innenstadtnord.hagen.de 386 Funckepark.innenstadtnord.hagen.de 146

*.innenstadtnord.hagen.de 0 - 12.3

innenstadtsued.hagen.de 160 Bodelschwinghplatz.innenstadtsued.hagen.de 103


11.5 Summary

This chapter presents two major topics: the representation of domain data in Nimbusand the import of domain data from land survey sources.

The resolution algorithms require geometric operations such as the intersection orunion of areas and the check if a point is inside an area. From the possible representa-tions raster, vector and analytical, the vector representation is the most appropriate forthe Nimbus framework. A two-dimensional representation is based on efficient poly-gon operations provided by a third-party toolkit. Since some operations have to be exe-cuted on mobile clients, weak client issues have to be considered.

As some domains can only be distinguished by their height, the mechanisms areextended to the third dimension. Even though the resulting 3D mechanisms are in prin-ciple usable, they require a certain amount of computing power of the client.

*.innenstadtsued.hagen.de 0 - 14.9

innenstadtzentrum.hagen.de 120 Hagen_Hbf.innenstadtzentrum.hagen.de 54

*.innenstadtzentrum.hagen.de 0 - 11.6

quambusch.hagen.de 131 Wald__ForstB01GG7S.quambusch.hagen.de 37

*.quambusch.hagen.de 0 - 11.1

reh.hagen.de 330 Stadion_Kirchenberg.reh.hagen.de 158

*.reh.hagen.de 0 - 10.1

vorhalle.hagen.de 279 Vossacker.vorhalle.hagen.de 48

*.vorhalle.hagen.de 0 - 10.2

wehringhausen.hagen.de 193 WohnbauflaecheB01Y6U2.wehringhausen.hagen.de 346

*.wehringhausen.hagen.de 0 - 15.9

west.hagen.de 690 BrunnenB01GGHP.west.hagen.de 155

*.west.hagen.de 0 - 8.8

geo 2 lakes.geo 0

lakes.geo 41 Harkortsee.lakes.geo 0

*.lakes.geo 0 - 2.4

rivers.geo 18 Volme.rivers.geo 0

*.rivers.geo 0 - 50.8

traffic 2 roads.traffic 0

rails.traffic 5 BahnkoerperB01Y6YL.rails.traffic 0

*.rails.traffic 0 - 22.2

roads.traffic 3 hagenost.roads.traffic 0

hagenost.roads.traffic 698 Amselgasse.hagenost.roads.traffic 0

*.hagenost.roads.traffic 0 - 13.2

hagenwest.roads.traffic 809 Alexanderstrasse.hagenwest.roads.traffic 0

*.hagenwest.roads.traffic 0 - 11.5

intercity.roads.traffic 885 Herdecker_Strasse.intercity.roads.traffic 0

*.intercity.roads.traffic 0 - 6.6

Table 11-3. Imported domains in the area of Hagen (continued)

Domain#

SubsExample

Subdomain#

Assoc.

166 Jörg Roth

To get a reasonable number of real domains, geographic data of land survey officesare imported. The import process of German ATKIS geo data was exemplarydescribed. A number of steps have to be performed which include the parsing of origi-nal files, the merging of areas, the converting of line- and point-like data and the properintegration into Nimbus hierarchies. The resulting domain data are stored as XML fileswhich can directly be read by location servers.


168 Jörg Roth

Part III:Analyses, Future Work and Summary

12 Performance Analyses

The Nimbus framework is completely implemented and works well. At thismoment it is interesting to know, how effective the concepts and algorithms are.This chapter describes the analyses of the framework properties and its algo-rithms. Response time, scalability and network traffic are examined.

12.1 Introduction

The efficiency of the Nimbus mechanisms is evaluated with the help of several simula-tions. For this, code to get message sizes and response times was integrated into thelocation server process. In addition, a special client application was developed to runthe specific server queries.

The simulations use the 8000 domains imported from the German land survey office(see section 11.4 on page 158). Even though this is a realistic set of data, we have toface a crucial point: the measurement results highly depend on the granularity, struc-ture, size and shape of the used domains and hierarchies. As an example: the averagenumber of polygon points used to describe an area affects the message sizes for clientserver communication. This in turn affects the average response time.

In the next sections, the location server efficiency, the efficiency of the cache mech-anism, the costs for the area resolution and the compression are evaluated.

12.2 Location Server Performance

The location server application consists of approx. 4000 lines of Java code (basiclibraries excluded). On a 2.8 GHz (Windows XP) computer, the location server storingapprox. 1000 domains generates a response to a single semantic resolution request in9.7 ms on average. To examine, how much time is spent for the respective internalcomputations, the Java profiling tool is used, which measures the time the CPU exe-cutes specific methods. More than 600 methods inside the location server are distin-guished by the tool. To get a deeper impression, the individual method calls areclassified:

■ mathematic operations such as round, min, max;

■ string operations;

■ network methods to send, and receive, but also to assemble or disassemble a com-mand message;

■ container operations on hash tables etc.;

■ geometric operations of the OpenGIS/JTS library (see section 11.3 on page 150);

■ main program and protocol threads.

Performance Analyses 169

Fig. 12-1 shows the results. Most of the containers and maths methods are used by thegeometry, but are shown as individual classes. Due to the property of the profiling tool,the maths methods only present mathematic functions accessible as methods, thusbasic operations (+, -, *, /) are not included. The time consumed to compute theseoperations mostly are subsumed under geometry. The network methods only show theactive CPU time and not the time the CPU is blocked, e.g. during a read or acceptoperation. Not surprisingly, most of the time is spent for geometry methods, as themain task during a semantic resolution request is to look up areas that contain the givenlocation.

Real Network Measurements

The 9.7 ms for a location request are measured on a server without any load and with-out considering the network access. The next measurements consider several clientssimultaneously requesting semantic resolutions over the network. All caches wereswitched off. Once receiving a semantic resolution result, the next request is sent with-out any delay. This causes a high load to the servers.

The servers were connected via a 100 MBit/s Ethernet switched network. The delayfor wireless phone connections would be higher, but with higher delays the measuredeffects are diluted and the measurement result would be less expressive. In addition, itis more difficult to impose load on location servers using slow connections.

Location servers are Windows XP computers with a CPU speed between 1.8 and2.8 GHz. Fig. 12-2 shows the results.

The experiments are conducted for 1, 2 and 3 servers. For more than one server,huge parts of the de hierarchy are put on other servers, whereas the remaining de hier-archy, as well as the traffic and geo hierarchy, remain on the first server. Usingmore than one location server, the load of different users is distributed. As expected,the approach is scalable: the more location servers are used, the more the curve is flat.Whenever in reality a location server is overloaded, new subservers can easily be intro-duced. As a location server has to process requests concerning its areas, the load isthen shifted to the subservers.

For low loads, the resolution over the network needs between 130 and 205 ms. Asthe number of simultaneous requests increases, the location server becomes more andmore overloaded. For 100 simultaneous requests, the response time approximatelydoubles.

Fig. 12-1. CPU time consumed by location servers

170 Jörg Roth

It is important to note that in reality a much higher number of users per location serveris needed to cause a specific load for the following reasons:

■ Clients use a cache, thus most of the resolution requests are not carried out over thenetwork, therefore do not cause any server load.

■ Clients usually do not permanently perform resolution requests, but need timebetween requests to process the results and present the output to the user. In addi-tion, dependent on the user’s speed, some applications only rarely need resolutionrequests (e.g. every 10 s or every minute).

As an example we assume that an application needs one location request per secondand, as a result of using a cache, only one of five resolution requests are carried outover the network. Instead of 100 users, we then get a total of 1000 users that impose thesame load to a single location server.

Command Message Size and Storage Requirements

As a last topic related to location servers, some characteristics of domain areas are pre-sented. These data both affect the required storage space of a location server and thecommand message sizes. Table 12-1 shows the polygon statistics.

Fig. 12-2. Average resolution time for simultaneous requests

Table 12-1. Polygon statistics

AreaAvg. Polygons per

MultipolygonAvg. Holes per Multipolygon

Avg. Total Number of Points

d.c 1.1 0.0056 24.9

(d) 1.1 0.01 23.3

♦(p) 2.8 0.0022 52.9


For the areas d.c and (d) the average numbers of all 8000 domains are listed. For thearea ♦(p), 10000 random locations p are used which were uniformly distributed amongthe covered area.

The domain areas mostly contain a single polygon. Holes are very rare. The ♦(p)contains approx. 3 polygons, which can be motivated as follows: very often a largerarea, e.g. a forest is segmented by roads. The area representing the forest (without theroads) thus is divided into several pieces.

For storing domains in XML files as well as for communication, multipolygons arerepresented as strings. Each polygon point needs a storage space of 32 characters. Theaverage string size representing a domain is 796 bytes, 74.7% need less than 1 KB,98.5% less than 5 KB and 99.97% less than 20 KB of storage space. Two singledomains exceed the usual size with 27 KB (the river Volme) and 208 KB (a drainagesystem).

Table 12-2 shows the average size of command messages for the resolutionrequests.

Note that in the inbound mode, the area ♦(p) is returned, whereas in the outboundmode, the (d) is returned which is usually smaller.

The following sections describe the number of network transactions (a request andthe corresponding reply) as they are more meaningful to examine the properties of theinvolved algorithms than the communication time. The actual time can be derived fromthe network transactions using the measurements presented in fig. 12-2. For the simu-lation, all domains were stored on a single server, but the requests are counted accord-ing to the fully distributed clustering (see section 6.3.1 on page 59). As the fullydistributed clustering leads to the highest number of transactions, this marks the worstcase – in reality the number of transactions is much lower.

12.3 Cache Efficiency

The cache is an important mechanism to avoid network traffic. Several simulations areconducted that measure the cache efficiency assuming that a mobile user permanentlymoves with a specific speed on random paths. These simulations use the random waypoint model to simulate the user’s movement. Real paths such as streets are not consid-ered, thus the simulated paths are more disordered than in reality. The details of thesimulations are the following:

■ The mobile user performs a location resolution (point variation) every second. Thespeed together with a resolution frequency describes a meaningful setting, which isequivalent to a spatial distance between two resolution requests.

■ The cache contains only one single entry which stores the current ♦ or ♦’ arearespectively. This is worse than in reality, where a user can cache several areas, butit provides a meaningful worst case estimation.

Table 12-2. Average command message size

CommandRequest (bytes)

Reply (bytes)

RESOLVE_PHYSICAL 50 804

RESOLVE_SEMANTIC (inbound) 39 1793

RESOLVE_SEMANTIC (outbound) 39 1056

172 Jörg Roth

Fig. 12-3 and fig. 12-4 show the simulation result, displayed for different speed ranges.The charts show the average number of resolution requests requiring a network trans-action related to the total number of resolution requests. The simulation performed10000 resolution requests. Not surprisingly, the charts indicate values near to 0 for lowspeeds and have values near to 1 for increasing speeds.

We first look at the complex cache mode: it provides reasonable values even forspeeds in the range of a car. E.g. in a car with the speed of 30 km/h, only 20% of theresolution requests require network access, which means a network access every 5 s.The author is fully aware that the results only indicate a trend as they highly depend onthe average size of the ♦ areas and thus on the specific domain data. In addition, theresolution frequency is highly application dependent – some applications may need aresolution request only on demand which occurs once an hour. However, the chartgives an impression of the caching efficiency, especially when we compare the two

Fig. 12-3. Average number of network transactions per resolution request (0-10 km/h)

Fig. 12-4. Average number of network transactions per resolution request (0-150 km/h)


cache modes. Looking at the simple cache mode, it increases faster to 1. Even though itis suitable for small speeds in the speed range of pedestrians, it becomes less and lessuseful for higher speeds in the speed range of cars.

It is important to note that in reality the cache will be far more efficient. Considertourists visiting a city: they may visit the same areas several times (e.g., the city centre,their hotel). Thus after initially loading the ♦ areas and respective areas, the touristscan work off line for a certain time.

12.4 Area Resolution

The area variation of the location resolution contains a loop of separate point resolu-tions. If a resolution request cannot be fulfilled by the cache, it requests a networktransaction. Thus the number of point resolutions (i.e. the number of ♦ areas) providesa worst case estimation for network requests per area resolution when the cache isempty.

The simulation performed multiple area resolution requests for circular areas with aspecific radius. For each radius, it measured 10000 locations where areas are randomlydistributed among the covered area. For each measurement, the number of ♦ areaswere counted.

Fig. 12-5 shows the results. As expected, the average number of ♦ areas approximatelyincreases with the square of the radius. For an average size v♦ of ♦ areas, the numbercan be approximated by the formula

.

The formula assumes that a circle area can be divided into ♦ areas without any remain-der. For larger circle areas, this is an acceptable simplification. In fig. 12-5, the dotted

line indicates the values of napprox; for our domain data v♦ = 2632 m2.

Fig. 12-5. Number of ♦ areas in a circular area

napproxπ r

2⋅v♦

------------=

174 Jörg Roth

Again, the actual number highly depends on the used domain data. If hierarchieshad a more detailed decomposition into subdomains, the number would be muchhigher. Therefore, this chart only displays a trend.

As this chart only presents the worst case without any cache entry, a second simula-tion measures the cache efficiency related to the area resolution. It is based on a similarassumption as in the last section: a simulated user moves over the covered area usingthe random way point model. The cache only stores those ♦ areas which were theresult of the last area resolution – this is again a reduction of the real expected results.

Fig. 12-6 shows the results. The simulation follows the considerations presented insection 7.3.6 (page 100). For a new area resolution, only those ♦ areas have to beresolved by network, which are undiscovered by the last resolution. For the size of20 m (which approximately corresponds to the GPS accuracy) we have about one net-work resolution even for higher speeds. For the speed of a pedestrian, we have lessthan 10% network resolutions. Larger areas need many more requests, but as a promis-ing result the average amount of 3 network transactions for a 100 m area and 150 km/his still low.

12.5 Compression

This section describes the trade-off between compression and network traffic. For the sample data set compression is not necessary, as the maximum number of

associations is low. However, it is possible to investigate the effects of compression. Asthe number of associations varies from domain to domain, it is useful to express thedegree of compression independently of the number of associations. The compressionratio defines the ratio of saved associations to the number of associations without anycompression. If na denotes the number of associations without compression and nc thenumber of associations after compression, we get a compression ratio

.

Fig. 12-6. Number of network transactions per area resolution request

cr 1nc

na-----–=


A cr value of 0 means no compression. The compression ratio is only defined, if thedomain has at least one uncompressed association, thus the simulation only considersdomains with na > 0. Note that after a maximum compression, nc is not zero, thus thecompression ratio cannot be 1.

The simulation is conducted as follows:

■ The simulation specifies a compression ratio crtotal and forces each domain to com-press according to the given value. A domain compresses as long as cr ≤ crtotal. Itrepeatedly looks for an uncompressed association and removes it, if a compressedassociation to the master exists. Some domains are not able to reach the given valueas the topology does not allow the required compression. In addition, as nc and naare integer values, crtotal usually is not exactly reached. The effective compressionratio creffective defines the average cr value of all domains.

■ The value crtotal is varied and leads to corresponding creffective values. For eachgiven value, 10000 random location resolutions (point variations) are performed.The cache is switched off. The network transactions are measured for the four possi-ble compression modes: no compression, link compression, structural compression,structural with link compression.

Fig. 12-7 shows the simulation results. The maximum possible effective compressionratio is 65.33%. No compression and link compression do not depend on the compres-sion rate, thus mark horizontal lines. The value for no compression is always 1,whereas the value for link compression is the average value of na+1.

The most important part in this figure is the structural compression. While the linkcompression highly affects the network traffic, the structural compression is an ade-quate tool to reduce the storage space for associations, but at the same time only causesa moderate increase of network traffic. Starting at 1 for 0% compression, even at thehighest compression rate, the number of network requests is approx. 3. Note that alocation server is required to store the areas of its subdomains that do not belong to theserver. If the target of the compression is the master of a resolved domain, only onemore network transaction is required.

Fig. 12-7. Average number of network requests for different compression modes

176 Jörg Roth

The shape of the curve link & structural compression is surprising at the firstglance. It starts at the value of the link compression for 0% and nearly ends at the valueof the structural compression for the maximum compression. Especially the effective-ness of this compression increases for higher compression rates. The reason for thisbehaviour is as follows: for low compression rates, the resolution process has torequest the data of all associations over the network. For high compression rates, it firsthas only to request the target domains. As mentioned above, a server has to store itssubdomains. Thus, if one of the subdomains is already the appropriate solution, no fur-ther network request is required. Only if the further resolution requires more than onestep downwards the hierarchy, additional requests are required. However, the curvedoes not exactly end at the level of the pure structural compression, as the resolutionprocess has always to request the target areas, even though it might not cover the cur-rent location. This causes some additional requests.

To sum up:

■ The structural compression is an effective tool to reduce storage space and onlymoderately increases the network traffic.

■ The pure link compression is not useful, as it significantly increases the networktraffic.

■ The combination of link and structural compression is useful for higher compres-sion rates.

Note that these simulations do not use any cache and are based on the fully distributedclustering. Storing clusters of domains on a single server can be viewed as a way ofcompression without any additional network costs. In real scenarios, the number of net-work requests is significantly lower.

12.6 Summary

This chapter presents a quantitative analysis of the Nimbus system. The design of thesystem and its algorithms is justified as the desired characteristics are verified with thehelp of realistic simulations. The location server is able to handle a reasonable numberof simultaneous client requests. Introducing new location servers can avoid overloadedservers as the load of the clients is distributed among the servers. As expected, theNimbus approach is highly scalable. Furthermore, the mechanisms for client caches,area resolution and compression are evaluated. The simulations confirm the assump-tions made during the Nimbus design. In addition, the results can help a systemdesigner to estimate the required network capabilities for a specific usage scenario.


178 Jörg Roth

13 Conclusion and Future Work

This chapter describes implementation details, summarizes the Nimbus conceptsand presents ideas for future research.

13.1 Implementation Details

This section provides an overview of the current implementation of Nimbus. The loca-tion server process (using the Java Standard Edition) and two client variations areavailable. One client runs on full Java-enabled devices (e.g. notebooks) and the otherruns on devices equipped with Java Micro Edition (e.g. mobile phones and PDAs)using the Mobile Information Device Profile 2.0 (MIDP 2.0).

The Java Standard Edition client platform was developed first. To create the MicroEdition variation, some classes had to be replaced. As floating point numbers andmany utility classes such as StringTokenizer or HashSet are not available,alternatives had to be developed. It was a great benefit to use the Network KernelFramework. Even though most of the communication classes are different for the twoplatforms, they can be accessed in a similar manner with the Network Kernel Frame-work.

Besides the location server and the two client platforms, the following componentswere developed:

■ Tools to import and edit geo data: a TIGER/Line import tool, an EDBS import tool(see section 11.4.1 on page 159), a tool to display and edit generated hierarchies (seefig. 11-14 on page 163) and a domain editor (see fig. 11-13 on page 162).

■ Tools for performance measurements and testing: a tool to create paths for simu-lated users (see fig. 7-16 on page 101), a performance measurement tool for resultsas described in chapter 12, a location server test tool for creating test messages, anda browsing tool that scans for servers in a subnet and displays the respective config-urations.

■ Security tools: a certification authority application (see fig. 9-5 on page 135), a toolto administrate requests, to approve certificates and to receive CRLs.

■ Sample positioning and mapping drivers: GPS via serial or Bluetooth, PalmSpot,GSM with signal strength, simulated GPS and simulated PalmSpot.

■ Sample applications: the PinPoint tourist guide (see fig. 10-4 on page 145), the busplanner (see fig. 1-1 on page 2) and the Flirt Finder (fig. 8-7 on page 116).

The entire software system (excluding the NKF components and third-party packagessuch as JTS) contains 36 packages, 300 classes and approx. 80000 lines of code. Themobile client based on Java Micro Edition contains 9 packages, 39 classes and approx.8000 lines of code.

13.2 Summary of the Nimbus Concepts

The main goal of Nimbus is to offer enriched location information that is easy to proc-ess. Nimbus provides globally unique physical locations, independently of the underly-

Conclusion and Future Work 179

ing positioning systems and semantic locations, according to a predefined name space.Nimbus reached this goal with the following instruments:

■ a location model which supports efficient access to decentralized stored semanticlocation data,

■ a distributed, self-organizing infrastructure, easily to be administrated, designedaccording to scalability issues and

■ a concept of modelling positioning systems that allows the easy integration of newpositioning systems and separates positioning issues from the service.

Location Model Concepts

The Nimbus location model contains domains that build hierarchies according to theirgeometry and semantics. Two kinds of links logically connect domains: the associationand the relation. Both links enable an efficient execution of the required algorithms in adecentralized environment. To structure hierarchies according to scalability and admin-istrative issues, the concepts of compression and abstract domains are introduced.

Concepts related to the Infrastructure

The logical structure of associations and relations is passed to the respective locationservers using the clustering concept. A decentralized lookup mechanism allows theservers to connect to each other. Clients look up the Local Location Server and theLocal Mapping Server to access Nimbus services.

The logical network between domains is a suitable structure to administrate locationinformation, especially if security issues are involved. The authenticity of locationservers and the respective resolution replies can be verified with the help of signed cer-tificates. Each master works as a guarantor for its subdomain. In addition to traditionalcertification mechanisms, a signature also authenticates the server’s configuration.

A caching concept significantly reduces the network traffic between the client andthe server. In contrast to traditional caches, key values describe a geometric area. Amethod is provided to compute the respective cached area efficiently. In case of weakclients, an appropriate simplification of the computation is described.

Communication between servers and between clients and servers is encapsulated bya lightweighted middleware called NKF, which can easily be ported to different weakclient platforms.

Positioning System Concepts

Positioning systems are modelled by Virtual Positioning Systems which encapsulatethe different issues related to positioning. Virtual Positioning Systems access real posi-tioning systems using capturing protocols, convert local locations to global ones anddeal with more than one positioning system. A location sensor model allows thedescription of accuracy issues. An extension of the semantic resolution algorithm forinaccurate location sensors computes the probability to reside at a specific domain. Inaddition, the concept of Virtual Positioning Systems simplifies the integration of posi-tioning system simulators.

Storing and Acquiring Geo Data

Nimbus uses a polygonal geometric model to store domain data. A model extensionthat considers heights allows the representation of three-dimensional domain data. Theexecution of geometric operations on mobile devices with low computational power is

180 Jörg Roth

considered. A huge amount of domains was integrated into the system using import fil-ters for land survey sources.

Additional Services

In addition to the main Nimbus services described above, further services are providedwhich simplify the development of applications: trigger services inform an applicationwhen a pre-defined location change happens. Semantic geocast services allow to trans-mit messages to mobile clients residing at a certain location. The PinPoint client sim-plifies the development of location-based services using the World Wide Web. Theproximity resolution finds semantic locations in the nearby area.

Final Evaluation

The infrastructure is designed considering scalability and network traffic issues. Anumber of simulations verify this approach. They show the efficiency of location serv-ers, the scalability of the infrastructure, the cache efficiency and the suitability of thearea resolution and compression.

Table 13-1 summarizes the initial goals of chapter 4 and the respective solutions inthe Nimbus framework.

Table 13-1. Goals and the respective solutions

Goal Nimbus SolutionGoal 1a: Positioning should be completely separated from the application.

Accomplished by the driver concept inside the Virtual Positioning framework (section 7.3.2 on page 87).

Goal 1b: The framework should provide uniform physical loca-tion information independently of the underlying positioning system.

Accomplished by the mapping concept inside the Virtual Positioning framework (section 7.3.3 on page 89).

Goal 1c: The framework should deal with more than one posi-tioning system and provide a handover mechanism to access the most appropriate positioning information.

Accomplished by the selection and collection concept inside the Virtual Positioning framework (section 7.3.4 on page 90).

Goal 1d: The framework should provide symbolic names for lo-cations.

Accomplished by the semantic resolution algorithm (sec-tions 5.3.3 on page 47, 6.3.2 on page 63, 7.3.5 on page 96 and 7.3.6 on page 98).

Goal 2a: The infrastructure should provide a scalable archi-tecture to store location data and efficiently run the required algo-rithms.

Accomplished by the distributed architecture, by the clus-tering concept (section 6.3.1 on page 59), the caching concept (section 6.4 on page 73) and by the compression concept (section 5.3.4 on page 48). Verified by several evaluations (sections 12.2 on page 169, 12.3 on page 172 and 12.5 on page 175).

Goal 2b: The infrastructure should offer services for recur-ring tasks of location-aware ap-plications.

Accomplished by the semantic geocast service (section 8.3 on page 109), trigger services (section 6.5 on page 77), proximity resolution (section 7.4 on page 102) and Web integration (section 10.3 on page 139).


13.3 Future Work

Although the Nimbus framework is fully operable, there are some open issues forfuture work.

The area model for location sensor output is useful for many sensor types, but amodel that takes into account the probability distribution is more accurate. The respec-tive algorithms are more complex and would currently overload weak clients. A futuretask is to find appropriate approximations and simplifications to run probabilistic mod-els on weak clients. Additionally, the application could specify quality of servicedemands to control the selection and collection component. To improve the selectioncomponent, knowledge about the positioning systems and the environment could beused. To realize these approaches the computational power of mobile devices has to beimproved.

Nimbus requires absolute location sensor output, thus positioning systems that pro-duce relative location information cannot be integrated. Examples of relative locationinformation are produced by odometers. Also, wireless ad-hoc communication technol-ogies indirectly produce relative location output. E.g. a Bluetooth device knows when

Goal 2c: The infrastructure should protect itself against mis-leading location data provided by attackers.

Accomplished by secure commands and signed certifi-cates/configurations included in NKF (section 9.4 on page 130).

Goal 2d: Location data should be entered, administered and re-trieved locally.

Accomplished by the mapping of location data to servers; in addition by the LLS concept (section 6.3.3 on page 66).

Goal 3a: The part of the frame-work running on mobile devices should respect the low computa-tional power of (current) mobile hardware platforms.

Accomplished by the location model, which avoids com-plex client computation, by the location sensor model and resolution algorithms, which limit the required geometric operations (section 11.3.1 on page 150); in addition by the simple cache mode (section 6.4 on page 73) and the inbound mode (section 6.3.3 on page 66).

Goal 3b: Weak connections of mobile devices and potentially high communication costs should be considered.

Accomplished by the logical network of associations, which often makes semantic information results available with a single network transaction. In addition, accom-plished by the cache mechanism (section 6.4 on page 75). Verified by evaluations (section 12.3 on page 172).

Goal 3c: Costs to port the mo-bile part to different mobile de-vices should be considered.

The portable communication platform NKF is already available for different platforms (section 9.3 on page 121). As important parts of the resolution results are provided by location servers, it is easy to port client algo-rithms. Weak client issues concerning geometry opera-tions are considered (section 11.3.1 on page 150).

Goal 4a: The framework should provide a model for locations.

Accomplished by the Nimbus location model (chapter 5 on page 39).

Goal 4b: The framework should provide a model for location sensor output.

Accomplished by the Nimbus location sensor model (chapter 7 on page 79).

Table 13-1. Goals and the respective solutions (continued)

Goal Nimbus Solution

182 Jörg Roth

it is within the communication range of another Bluetooth device. The correspondingfuzzy location information can currently not be modelled.

The user’s angular orientation is not considered yet, as nearly none of the position-ing systems provide these data. The orientation is an important information for mobileusers, thus the corresponding sensors (e.g. gyroscopes) may be available in futuremobile devices. The resolution algorithms have to be extended to propagate orientationinformation.

Currently, a client can check if location servers are authentic. With the help of thesigned configuration, it is additionally possible to recompute resolution results in caseof doubts. In principle, a mobile client can modify these data before they are passed tothe location-based services. For some services this is no problem as the mobile user isthe only one who suffers from wrong location information. There are, however, someservices that rely on correct locations, e.g. toll and payment services. For this, anextended security mechanisms is required that produces signed location information.

The current Nimbus framework provides efficient resolution operations for publicstatic domains with a long life-time. There are other conceivable domains:

■ Travellers in a mobile domain such as a ship or a train have the idea of a fixed posi-tion, but their physical area constantly changes. In principle, such domains can cur-rently be stored on location servers that have access to position information of thesedomains and permanently update the domain entry. As a disadvantage, the locationserver has to correct the corresponding associations very often, which causes unde-sirably high network load. Therefore, a mechanism is required which produces thesame resolution results, but avoids high network traffic.

■ Private domains are entered by private persons and do not have public meaning.Examples of private domains are rooms inside an apartment. Private domainsrequire a mechanism for users to enter these domains conveniently and securitymechanisms, which prevent access by other users.

■ Secret domains can only be accessed by authorized users. As an example, a militarybase may want to define domains representing barracks, hangars etc. Outside themilitary base, these domains should not be accessible. Such domains require author-ization mechanisms.

■ Many domains such as parks, lakes, buildings, streets, cities or countries have astrict border, whereas other domains such as city centres or mountains only have afuzzy definition. Such locations can be modelled with the help of fuzzy sets, whereeach point of the area has a certain degree of containment. This, however, leads tomore difficult operations on the location model.

A future goal is to include mobile, private, secret and fuzzy defined domains in theconcept.

Currently, domains are either entered manually or imported from a land surveysource. In both cases, an authority (e.g. the location server administrator) is required toguarantee the integrity of the data. Responsible authorities are also a prerequisite forthe Nimbus authentication process. However, a completely different approach is con-ceivable, where the users are responsible for entering the domain data. This followsideas realized e.g. in the Wikipedia [181] project, where any user is allowed to enterencyclopaedic texts into a huge database. Similarly, users could in principle enterdomains. As a consequence, the framework has to deal with incomplete and partlywrong domain data. An ideal framework jointly supports authorized and user-entereddomain data.


184 Jörg Roth

Bibliography

1. Abowd, G. D.; Atkeson, C. G.; Hong, J.; Long, S.; Kooper, R.; Pinkerton, M:Cyberguide: A mobile context-aware tour guide. ACM Wireless Networks, 3,1997, 421-433

2. Alexander, S.; Droms, R.: DHCP Options and BOOTP Vendor Extensions, Request for Comments 2132,March 1997, http://www.ietf.org/

3. Antifakos, S.; Schiele, B.:Beyond Position Awareness, Personal and Ubiquitous Computing, Vol. 6, No. 5-6, Dec. 2002, Springer-Verlag, 313-317

4. Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bun-desrepublik Deutschland (AdV):AdV Homepage, http://www.adv-online.de

5. Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bun-desrepublik Deutschland (AdV):ATKIS Homepage, http://www.atkis.de/

6. Bahl, P.; Padmanabhan, V., N.:User Location and Tracking in an In-Building Radio Network, MicrosoftResearch Technical Report MSR-TR-99-12, Febr. 1999

7. Bancroft, S.:An Algebraic Solution of the GPS equations, IEEE Trans. Aerospace andElectronic Systems, Vol. AES-21, No. 7, Jan. 1985, 56-59

8. Bakre, A.; Badrinath, R., R.:I-TCP: Indirect TCP for mobile hosts, 15th Int. Conference on DistributedComputing Systems, 1995

9. Barlag, H.; Drautz, S.:Konzeption und Implementierung einer Sicherheitsarchitektur für die LocationServer Infrastructure, Diploma thesis, University of Hagen, Oct. 2003

10. Bauer, M.; Becker, C.; Rothermel, K.:Location Models from the Perspective of Context-Aware Applications andMobile Ad Hoc Networks, Personal and Ubiquitous Computing, Vol. 6, No. 5-6,Dec. 2002, Springer-Verlag, 322-328

11. Beigl, M.:Memoclips: A location based remembrance appliance. Proceedings of the 2ndInternational Symposium on Handheld and Ubiquitous Computing (HUC2000),Bristol, UK, 2000, 230-234

12. Beigl, M.; Gellersen, H., W., Schmidt, A.:MediaCups: Experience with design and use of computer-augmented everydayobjects, Computer Networks, Vol. 35 No. 4, 2001, 401-409

13. Beigl, M.; Zimmer, T.; Decker, C.:A Location Model for Communicating and Processing of Context, Personal andUbiquitous Computing, Vol. 6, No. 5-6, Dec. 2002, Springer-Verlag, 341-357

14. Bellocci, V.; Genovese, S.; Inuaggiato, D.; Tucci, M.:Mobile Location-Aware Services, Market Perspective, Ericsson, DivisionService Architecture and Interactive Solutions, July 18, 2002

185

15. Bey, C.; Freeman, E.; Mulder, D.; Ostrem, J.:Palm OS SDK reference, 3Com, http://www.palm.com/devzone/index.html

16. Borenstein, N.; Freed, N.:MIME (Multipurpose Internet Mail Extensions) part one: Mechanisms forspecifying and describing the format of Internet message bodies, RFC 1341,Sept. 1993

17. BouncyCastle:The Bouncy Castle Crypto APIs, http://www.bouncycastle.org/

18. Breunig, M.:Integration of Spatial Information for Geo-Information Systems, Lecture Notesin Earth Sciences 61, Springer, 1996

19. Buchholz, T.; Krause, M.; Linnhoff–Popien, C.; Schiffers, M.:CoCo: Dynamic Composition of Context Information, in Proceedings of the FirstAnnual International Conference on Mobile and Ubiquitous Computing (Mobi-Quitous) 2004, IEEE, Boston, Massachusetts, USA, August, 2004

20. Burgard, W.; Fox, D.; Hennig, D.; Schmidt, T.:Estimating the Absolute Position of a Mobile Robot Using Position ProbabilityGrids, IAAI, Vol. 2, 1996, 896-901

21. C-Technologies:C-Pen SDK Version 1.0

22. Cheverst, K.; Davies, N.; Mitchell, K.; Friday, A.:The Role of Connectivity in Supporting Context-Sensitive Appliations, Proc. ofthe first Intern. Symposium on Handheld and Ubiquitous Computing HUC '99,Karlsruhe Germany, Springer-Verlag, 1999, 193-207

23. Cheverst, K.; Davies, N.; Mitchell, K.; Friday, A.; Efstratiou, C.:Developing a Context-aware Electronic Tourist Guide, in Proc. of CHI'00, ACMPress, 2000

24. Chokhani, S.; Ford, W.:Internet X.509 Public Key Infrastructure Certificate Policy and CertificationPractices Framework, RFC 2527, Mar. 1999

25. Clark, J., J.; Yuille, A., L.:Data Fusion for Sensory Information Processing Systems, Kluwer AcademicPublishers, 1990

26. Clementini, E.; Di Felice, p; and van Oosterom, P:A Small Set of Formal Topological Relationships Suitable for End-User

Interaction, 3rd International Symposium on Large Spatial Databases, Singapore,June 1993, LNCS 692, Springer-Verlag, 277-295

27. Coschurba, P.; Rothermel, K.; Dürr, F.:A fine grained addressing concept for GeoCast, in: Schmeck, Hartmut (ed.);Unger, Theo; Wolf, Lars (eds.): Proceedings of the International Conference onArchitecture of Computing Systems 2002: ARCS '02; Karlsruhe, Germany, April2002

28. Coutaz, J.; Rey, G.:Foundations of a Theory of Contextors, in Computer Aided Design of UserInterfaces, Springer, June 2002

29. Cox, D., C.:Wireless personal communications: A perspective, in the MobileCommunications Handbook, Second Edition, Gibson J. (ed), CRC Press andSpringer Verlag, 1999

186 Jörg Roth

30. Crowley, J. L.; Coutaz, J.; Rey, G.; Reignier, P.Perceptual Components for Context Aware Computing, UBICOMP 2002,Goteborg, Sweden, September 2002, 117-134

31. Database Promotion Center:G-XML Project Homepage, http://gisclh01.dpc.or.jp/gxml/contents-e/index.htm

32. Daemen, J.; Rijmen, V.:The Block Cipher Rijndael, Smart Card Research and Applications, LNCS 1820,J.-J. Quisquater and B. Schneier (eds)., Springer-Verlag , 2000, 288-296

33. Deering, S.: Host Extensions for IP Multicasting, RFC 1112, Aug. 1989

34. Department of Defense:Global Positioning System - Standard Positioning Service Performance Standard,Oct. 2001

35. Dey, A.:Understanding and Using Context, Personal and Ubiquitous Computing, Vol 5,No. 1, 2001, 4-7

36. Dey, A., K.; Abowd, G., D.:Towards a better understanding of context and context-awareness, GVUTechnical Report GIT-GVU-99-22, Georgia Institute of Technology, 1999

37. Dey, A., K.; Abowd, G., D.:CybreMinder: A Context-aware System for Supporting Reminders, SecondInternational Symposion on Handheld and Ubiquitous Computing 2000(HUC2K), Bristol (UK), Sept. 25-27, 2000, LNCS 1927, Springer-Verlag, 187-199

38. Dierks, T.; Allen, C.:The TLS protocol, RFC 2246, Jan. 1999

39. Diffie, W.; Hellmann, M., E.:New Directions in Cryptography, IEEE Transactions on information Theory IT-22(6), Nov. 1976, 644-654

40. Dix, A.; Rodden, T.; Davies, N.; Trevor, J.; Friday, A.; Palfreyman, K.: Exploiting Space and Location as a Design Framework for Interactive MobileSystems, ACM Transactions on Computer-Human Interaction, Vol. 7, No. 3,Sept. 2000, 285-312

41. Dobson, S.; Nixon, P.:More principled design of pervasive computing systems, EHCI-DSVIS'04, 9thWorking Conference on Engineering for Human-Computer Interaction jointlywith 11th International Workshop on Design, Specification and Verification ofInteractive Systems", Schloss Tremsbüttel, Hamburg, July 11-13, 2004, Springer

42. DoCoMo:All About i-mode, http://www.nttdocomo.co.jp/english/p_s/imode/

43. Doucet, A.; de Freitas, N.; Gordon N. (eds)Sequential Monte Carlo in Practice, Springer-Verlag, New York, 2001

44. Droms, R.: Dynamic Host Configuration Protocol, Request for Comments 2131, March1997, http://www.ietf.org/

45. Enge, P.:GPS Modernization: Capabilities of the New Civil Signals, AustralianInternational Aerospace Congress Congress, Brisbane, Australia, July 29-Aug. 1,2003

187

46. Ericsson:Mobile Positioning, http://www.ericsson.com/developerszone/

47. EUROCONTROL European Organization for the Safety of Air Navigation:WGS 84 - Implementation Manual, Brussels, Belgium, Febr. 1998

48. European Union:The Galilei Project – Galileo Design Consolidation, 2003

49. Farrell, C.; Schulze, M.; Pleitner, S.; Baldoni, D.: DNS Encoding of Geographical Location, Request for Comments 1712, Nov.1994

50. Flirt Getty:The Flirt Getty homepage, www.flirtgetty.de

51. Fox, D.; Burghard, W.; Dellaert, F.; Thrun, S.:Monte Carlo Localization: Efficient Position Estimation for Mobile Robots,Proc. of the 16th National Conf. on AI (AAAI), Orlando, USA, 343-349, 1999

52. Früh, H.:Realisierung eines Network Kernel Frameworks für die PalmOS-Plattform,Diploma thesis, University of Hagen, May 2002

53. Garmash, A.: Management of geographic information in mobile environment, Master Thesis,University of Jyväskylä, Finnland, 2000

54. Gartmann, R; Voisard, A.; Weißenberg, N.:Situation-Aware Service Supply, Münsteraner GI-Tage, July 1-2, 2004

55. Goßmann, J.; Specht, M.:Location Models for Augmented Environments, Personal and UbiquitousComputing, Vol. 6, No. 5-6, Dec. 2002, Springer-Verlag, 334-340

56. Graumann, D.; Lara, W.; Hightower, J.; Borriello, G.:Real-world Implementation of the Location Stack: The Universal LocationFramework, Proc. of the 4th IEEE Workshop on Mobile Computing Systems andApplications (WMCSA 2003), Monterey, CA, Oct, 2003, 122-128

57. GSM-World:GSM - Location Based Services, PRD SE.23, http://www.gsmworld.com, 2002

58. Guttman, E.; Perkins, C.; Veizades, J.; Day, M.: Service Location Protocol, Version 2, Request for Comments 2608, June 1999,http://www.ietf.org/

59. Hadig, T.:Proximity in Location Based Services, Diploma thesis, University of Hagen,Nov. 2003

60. Hadig, T.; Roth, J.:Proximity Services with the Nimbus Framework, IADIS Intern. ConferenceApplied Computing 2004, Lisbon, Portugal, March 23-26, 2004, IADIS press,437-444

61. Hadig, T.; Roth, J:Accessing Location and Proximity Information in a Decentralized Environment,International Conference on E-Business und Telecommunication Networks(ICETE 2004), Setúbal (Portugal), Aug. 25-28, 2004, Vol. 1, 88-95

62. Hall, D., L.:Mathematical Techniques in Multisensor Data Fusion, Artech House, 1992

63. Harrison, R.:Symbian OS C++ for Mobile Phones Volume 1, Symbian PressApril 2003

188 Jörg Roth

64. Hata, M.:Empirical formula for propagation loss in land mobile radio services, IEEETransactions on Vehicular Technology, VT-29(3), 1980, 317-325

65. van der Heijden, M:Understanding WAP : wireless applications, devices, and services, Artech House,2000

66. Hegering, H.–G.; Küpper, A.; Linnhoff–Popien, C.; Reiser, H.:Management Challenges of Context–Aware Services in Ubiquitous Environ-ments, in Self-Managing Distributed Systems; 14th IFIP/IEEE InternationalWorkshop on Distributed Systems: Operations and Management, DSOM 2003,Heidelberg, Germany, Proceedings (LNCS 2867), Springer-Verlag, Oct. 2003,246-259

67. Heutelbeck, D.:Context Spaces – Self-Structuring Distributed Networks for ContextualMessaging and Resource Discovery, CoopIS'02 International Conference onCooperative Information Systems, Irvine, USA, Oct. 30 - Nov. 1, 2002, LNCS2519, Springer-Verlag, 248-265

68. Hightower, J.; Boriello, G.; Want, R.:SpotON: An Indoor 3D Location Sensing Technology based on RF SignalStrength, Technical Report #2000-02-02, University of Washington, Febr. 2000

69. Hightower, J.; Brummit, B.; Borriello, G.:The Location Stack: A layered model for location in ubiquitous computing, Proc.of the 4th IEEE Workshop on Mobile Computing Systems and Applications(WMCSA 2002), Callicoon, New York, June, 2002, 22-28

70. Hofmann-Wellenhof, B.; Lichtenegger, H.; Collins, J.:GPS - Theory and Practice, Fifth, revised edition, Springer Verlag, Wien NewYork, 2001

71. Hohl, F; Kubach, U.; Leonhardi, A.; Schwehm, M.; Rothermel, K.:Nexus - an open global infrastructure for spatial-aware applications, in Proc. ofthe 5th Intern. Conference on Mobile Computing and Networking (MobiCom'99), Seattle, WA, USA, 1999. ACM Press

72. IBM:Distributed Application Environment - Communications system applicationprogramming Volume 1, 2, and 3, Document Number SC28-8278-05, SixthEdition, June 1994

73. Imielinski, T.; Navas, J.:GPS-based Addressing and Routing, Request for Comments 2009, http://www.ietf.org/, Nov. 1996

74. Imielinski, T.; Navas, J.:GPS-based geographic addressing, routing, and resource discovery,Communications of the ACM, Vol. 42, No. 4, Apr. 1999, 86-92

75. Infrared Data Association:IrDA Object exchange protocol, http://www.irda.org, March 1999

76. Infrared Data AssociationSerial Infrared Physical Layer Specification, Version 1.3, Okt. 1998, http://www.irda.org

77. Infrared Data AssociationSerial Infrared Link Access Protocol (IrLAP), Version 1.1, Juni 1996, http://www.irda.org

189

78. Jacobsen, H.-A.:Middleware for Location-Based Services, in Jochen Schiller, Agnès Voisard(eds), Location-Based Services, Morgan Kaufmann Publishers, May 2004

79. Jones, A.; Ohlund, J.:Network programming for Microsoft Windows, Microsoft Press, 1999

80. José, R.; Davies, N.:Scalable and Flexible Location-Based Services for Ubiquitous InformationAccess, Proc. of the first Intern. Symposium on Handheld and UbiquitousComputing HUC '99, Karlsruhe Germany, Springer-Verlag, 1999, 52-66

81. Kalman, R., E.:A new approach to linear filtering and prediction theory, Trans. ASME J. BasicEng., 82, 1960, 35-45

82. Kaplan, E., D. (ed):Understanding GPS, Artech House Boston London, 1996

83. Katz, R., H.; Brewer, E., A.:The case for wireless overlay networks, in Proc. of the SPIE Multimedia andNetworking Conference (MMNC ’96), Jan. 1996

84. Kelly, A.:Modern Inertial and Satellite Navigation Systems, CMU Robotics, InstituteTechnical Report CMU-RI-TR-94-15, 1994

85. Kelsey Group:Advertising and E-commerce, http://www.kelseygroup.com/, 2001

86. Kindberg, T.; Barton, J.; Morgan, J.; Becker G.; Caswell, D.; Debaty, P.; Gopal,G.; Frid, M.; Krishnan, V.; Morris, H.; Schettino, J.; Serra, B.; Spasojevic, M.:People, Places, Things: Web Presence for the Real World, Proc. 3rd AnnualWireless and Mobile Computer Systems and Applications, Monterey CA, USA,Dec. 2000

87. Ko, Y.-B.; Vaidya, N. H.:Geocasting in Mobile Ad Hoc Networks: Location-Based Multicast Algorithms,Proc. 2nd Wksp. Mobile Comp. Sys. and Applications (WMCSA ’99), NewOrleans, USA, Feb. 1999, 101–110

88. Ko, Y.-B.; Vaidya, N. H.:GeoTORA: A Protocol for Geocasting in Mobile Ad Hoc Networks, Proc. 8thInt’l. Conf. Network Protocols (ICNP), Osaka, Japan, Nov. 2000, 240–250

89. Korkea-aho, M.; Tang, H.; Slonen, R.: Expressing Location Information for Applications in the Internet, Personal andUbiquitous Computing, Vol. 6, No. 5-6, Dec. 2002, Springer-Verlag, 329-333

90. Lacy, I.; Quarles, A.; Stokes, T.; Tabuchi, L.:Location, Location, Location – Will Location-based Services Be The NextGolden Child? Kellogg TechVenture 2001

91. Land Development and Transportation Professionals:LandXML Project Homepage, http://landxml.org/spec.htm

92. Land Survey Office North Rhine-Westphalia:http://www.lverma.nrw.de

93. Lédeczi, Á; Maróti, M.; Simon, G.; Balogh, G.:Acoustic Source Localization Using a Wireless Sensor Network, IADIS Intern.Conference Applied Computing, 2004, Lisbon, Portugal, March 23-26 2004,IADIS press, 476-483

190 Jörg Roth

94. Leonhardi, A.; Kubach, U.:An Architecture for a Distributed Universal Location Service, Proceedings of theEuropean Wireless '99 Conference, 1999, 351-355

95. Leonhardt, U.:Supporting Location-Awareness in Open Distributed Systems, PhD Thesis,University of London, 1998

96. Maihöfer, C.:A Survey of Geocast Routing Protocols, IEEE Communications Surveys, Vol. 6,No. 2, 2004, 32-42

97. Marmasse, N.; Schmandt, C.:Location-aware Information Delivery with ComMotion, Second InternationalSymposion on Handheld and Ubiquitous Computing 2000 (HUC2K), Bristol(UK), Sept. 25-27, 2000, LNCS 1927, Springer-Verlag, 157-171

98. Marmasse, N.; Schmandt, C.:A User-Centred Location Model, Personal and Ubiquitous Computing, Vol. 6,No. 5-6, Dec. 2002, Springer-Verlag, 318-321

99. Mitsubishi Electric Research Laboratory:http://www.merl.com/projects/visual-tags/, 2001

100. Mockapetris, P.:Domain Names - Concepts and Facilities, STD 13, Request for Comments 1034,Nov. 1987, http://www.ietf.org/

101. Mockapetris, P.:Domain Names - Implementation and Specifications, STD 13, Request forComments 1035, Nov. 1987, http://www.ietf.org/

102. Mouly, M.; Pautet, M.-B.:The GSM System for Mobile Communications, Published by the authors, ISBN2-9507190-0-7, 1992

103. Mozilla:The Mozialla homepage, http://www.mozilla.org

104. Muffin:The Muffin Homepage, http://muffin.doit.org/

105. Navas, J.; Imielinski, T.:GeoCast - Geographic addressing and routing, Proc. of the 3rd ACM/IEEE inter.conf. on Mobile Computing and networking, Sept. 26-30, 1997, 66-76

106. Nicklas, D.; Mitschang, B.:The Nexus Augmented World Model: an extensible approach for mobile,spatially aware applications, 7th International Conference on Object-orientedInformation Systems, 2001

107. Nimbus Project Page:http://dreamteam.fernuni-hagen.de/nimbus/nimbus_eng.html

108. NÖV – Nachrichten aus dem öffentlichen Vermessungsdienst Nordrhein-Westfalen, Heft 2-3, 1987

109. NÖV – Nachrichten aus dem öffentlichen Vermessungsdienst Nordrhein-Westfalen, Heft 3-4, 1989

110. Nokia, Finnland:Mobile Location Services, White Paper, 2001

111. Nokia, Finnland:Nokia Mobile entry solutions for next billion mobile phone users, http://www.pc4d.com, 2004

191

112. The National Marine Electronics Association:NMEA Specification, http://www.nmea.org/

113. Object Management Group:The Common Object Request Broker: Architecture and specification, Revision2.2, Document 98-07-01, Feb. 1998

114. Okumura, Y.; Ohmori, E.; Kawano, T.; Fukuda K.: Field Strength and its Variability in VHF and UHF Land-Mobile-Service,Review of the Electrical Communications Laboratory, Vol. 16, No. 9-10, Sept.1968, 825-873

115. Open GIS Consortium:OpenLS Home Page, www.openls.org

116. Open GIS Consortium:OpenGIS Geography Markup Language (GML) Implementation Specificiation,www.opengis.org, 2003

117. Open GIS Consortium:OpenGIS Simple Features Specification for SQL, Revision1.1,www.opengis.org, 1999

118. Open Mobile Alliance:OMA Homepage, www.openmobilealliance.org

119. Open Mobile Alliance:Mobile Location Protocol, www.openmobilealliance.org

120. Ovum Ltd.: Mobile Location Services, 2000

121. Padmanabhan, V., N.; Subramanian, L.:Determining the Geographic Location of Internet Hosts, Microsoft TechnicalReport MSR-TR-2000-110, Nov. 2000

122. PalmSpot Project Page:http://dreamteam.fernuni-hagen.de/palmspot/palmspot.html

123. Park, V., D.; Corson, M., S.:A highly adaptive distributed routing algorithm for mobile wireless networks,Proc. of the IEEE INFOCOM ’97, Kobe, Japan, April 1997

124. Perkins, C., E.; Bhagwat, P.:Highly dynamic destination-sequenced distance-vector routing (DSDV) formobile computers, Proc. of the SIGCOMM ’94 Conference on Communications,Architectures Protocols and Applications, Aug. 1994, 234-244

125. Pradhan, S.: Semantic Location, Personal Technologies, Vol. 4, No. 4, 2000, 213-216

126. Prigouris, N.; Papazafeiropoulos G.; Marias, I.; Hadjiefthymiades S.;Merakos, L.:Building a Generic Broker for Location Retrieval, Proc. of the IST Mobile &Wireless Communications Summit, Portugal, June 2003

127. Priyantha, N., B.; Chakraborty, A.; Balakrishnan, H.: The Cricket Location-Support System, Proc. of the 6. Annual Internat. Conf. onMobile Computing and Networking, Boston, Aug. 6-11, 2000

128. Rekimoto, J.; Ayatsuka, Y.:"CyberCode: Designing Augmented Reality Environments with Visual Tags",Proceedings of DARE 2000, 2000

129. Rhodes, N.; McKeehan, J.:Palm OS Programming: The Developer's Guide, O'Reilly, Oct. 2001

192 Jörg Roth

130. Rivest, R., L.; Shamir, A.; Adleman, L., A.:A method for obtaining digital signatures and public-key cryptosystems,Communications of the ACM, Vol. 21, No .2, 1978, 120-126

131. Roth, J.:'DreamTeam': A platform for synchronous collaborative applications, AI &Society, Vol. 14, No. 1, Springer Verlag London, March 2000, 98-119

132. Roth, J.:Information sharing with handheld appliances, 8th IFIP Working Conference onEngineering for Human-Computer Interaction (EHCI'01), Toronto, Canada, May11-13 2001, LNCS 2254, Springer-Verlag, 263-279

133. Roth, J.:Mobile Computing, dpunkt-Verlag, 2002

134. Roth, J.:Mobility Support for Replicated Real-time Applications, Innovative InternetComputing Systems (I2CS), Kühlungsborn, June 20-22, 2002, LNCS 2346,Springer-Verlag, 181-192

135. Roth, J.:A Communication Middleware for Mobile and Ad-hoc Scenarios, Int. Conf. onInternet Computing (IC'02), June 24-27, 2002, Las Vegas, Vol. I, CSREA press,77-84

136. Roth, J.:Patterns of Mobile Interaction, Personal and Ubiquitous Computing, Vol. 6, Issue4, Sept. 2002, Springer-Verlag, 282-289

137. Roth, J.:Context-aware Web Applications Using the PinPoint Infrastructure, IADISIntern. Conference WWW/Internet 2002, Lisbon, Portugal, Nov. 13-15 2002,IADIS press, 3-10

138. Roth, J.:Flexible Positioning for Location-Based Services, IADIS InternationalConference e-Society 2003, Lisbon, Portugal, June 3-6, 2003, Vol. I, IADISPress, 296-304

139. Roth, J.:The Critical Mass Problem of Mobile Ad-hoc Networks, IADIS InternationalConference e-Society 2003, Lisbon, Portugal, June 3-6, 2003, Vol. I, IADISPress, 243-250

140. Roth, J.:Semantic Geocast Using a Self-organizing Infrastructure, Innovative InternetCommunity Systems (I2CS), Leipzig, June 19-21, 2003, LNCS 2877, Springer-Verlag, 216-228

141. Roth, J.:Accessing Location Data in Mobile Environments – the Nimbus LocationModel, Mobile HCI 03 Workshop on Mobile and Ubiquitous InformationAccess, Udine, Italiy, Sept. 8, 2003, LNCS 2954, Springer-Verlag, 256-270

142. Roth, J.:The Resource Framework for Mobile Applicationsin Olivier Camp, Joaquim B.L. Filipe, Slimane Hammoudi, Mario G. Piattini(eds), Enterprise Information Systems V, Kluwer Academic Publishers, Nov.2003

193

143. Roth, J:Flexible Positioning for Location-based Services, IADIS Journal on WWW/Internet, Vol. I, Nr. 2, Dec. 2003, IADIS Press, 18-32

144. Roth, J:Data Collection, in Jochen Schiller, Agnès Voisard (eds), Location-BasedServices, Morgan Kaufmann Publishers, May 2004

145. Roth, J. (ed):1. GI/ITG KuVS Fachgespräch "Ortsbezogene Anwendungen und Dienste", June24-25, 2004, Hagen, Informatik Bericht 317, University of Hagen, June 2004

146. Roth, J:Novel Architectures for Location-based Services, Annual Meeting forInformation Technology & Computer Science, July 7, 2004, Stuttgart, Germany,5-8

147. Roth, J.; Unger, C.:Using handheld devices in synchronous collaborative scenarios, SecondInternational Symposium on Handheld and Ubiquitous Computing 2000(HUC2K), Bristol (UK), Sept. 25-27 2000, LNCS 1927, Springer-Verlag, 187-199

148. Royal Institute of Technology:WIPS Technical Documentation, Schweden, http://2g1319.ssvl.kth.se/2000/group12/technical.html

149. Salber, D.; Dey, A. K.; Abowd, G.:The Context Toolkit: Aiding the development of context-enabled applications,proc. CHI99, ACM, 1999, 434-441

150. Schilit, B.; Adams, N.; Want, R.:Context-Aware Computing Applications, Workshop on Mobile ComputingSystems and Applications, Santa Cruz, CA, USA, 1994

151. Schilit, B., N.; Theimer, M., M.:Disseminating Active Map Information to Mobile Hosts, IEEE Network, Vol. 8,No. 5, 1994, 22-32

152. Schill, A.; Kümmel, S.:Design and implementation of a support platform for distributed mobilecomputing, Distributed Systems Engineering Vol. 2 No. 3, 1995, 128-141

153. Schiller, J.; Voisard, A (eds):Location-Based Services, Morgan Kaufmann Publishers, May 2004

154. Shamos, M., I.:Computational geometry. Ph.D. thesis, Yale University, 1978

155. SOAP Webservices resource center:http://www.soap-wrc.com/

156. Spiekermann, S.:General Aspects of Location-Based Services, in Jochen Schiller, Agnès Voisard(eds), Location-Based Services, Morgan Kaufmann Publishers, May 2004

157. Starner, T.; Mann, S.; Rhodes B.; Levine, J.; Healey, J.; Kirsch, D.; Picard, R.;Pentland, A.:Augmented Reality Through Wearable, Computing, Presence, Special Issue onAugmented Reality, Vol. 6, No. 4, 1997

158. Steenstrup, M.:Cluster-based networks, in Perkins, C., E. (ed): Ad Hoc Networks, AddisonWesley, 2001

194 Jörg Roth

159. Sun Microsystems, Inc.:RPC: Remote Procedure Call, Protocol specification version 2, RFC 1057, June1988

160. Sun Microsystems, Inc.:Java Remote Method Invocation specification, Oct. 1997

161. Sun Microsystems, Inc.:Java 2 Standard Edition SDK, http://java.sun.com

162. Sun Microsystems, Inc.:Java 2 Micro Edition SDK, http://java.sun.com

163. Sun Microsystems, Inc.:Mobile Location Services Reference Architecture Technical FAQs, http://www.sun.com

164. Tomlin, C., D.: Geographic Information Systems and Cartrographic Modeling, Prentice Hall,1990

165. Topley, K.:J2ME in a nutshell, O’Reilly, March 2002

166. UMTS Forum:The UMTS Third Generation Market - Structuring the Service RevenuesOpportunities, UMTS Forum Report 9, Oct. 2000, http://www.umts-forum.org

167. UMTS Forum:Enabling UMTS/Third Generation Services and Applications, Report 11, Oct.2000, http://www.umts-forum.org

168. Universität Stuttgart:Sonderforschungsbereich "Umgebungsmodelle für mobile kontextbezogeneSysteme", http://www.nexus.uni-stuttgart.de

169. University of California:Nibble Location System, http://mmsl.cs.ucla.edu/nibble

170. Urnes, T.; Hatlen, A.; Johansen, R.; Myhre, O.:Using mobile code to build a smart kitchen, Personal Technologies, Vol. 4, No. 4,2000, 202-204

171. U.S. Census Bureau:108th Congressional Districts Census, TIGER/Line Files, http://www.census.gov/geo/www/tiger/index. html, 2000

172. U.S. Coast Guard:Navigation Center Homepage, http://www.navcen.uscg.gov/

173. Veizades, J.; Guttman, E.; Perkins, C.; Kaplan, S.: Service Location Protocol, Request for Comments 2165, June 1997, http://www.ietf.org/

174. Vivid Solutions:JTS Technical Specifications, http://www.vividsolutions.com, March 31, 2003

175. Vodafone:Vodafone Homepage, www.vodafone.com, 2004

176. Waldo, J.:The Jini architecture for network-centric computing, Communications of theACM, Vol. 42, No. 7, July 1999, 76-82

177. Waltz, E.; Llinas, J.:Multisensor Data Fusion, Artech House, 1990

195

178. Want, R.; Hopper, A.; Falcao, V.; Gibbson, J.:The Active Badge Location System, ACM Transactions on Information Systems,Vol. 10, No. 1, Jan. 1992, 91-102

179. WAP Forum:WAP Architecture Specification, July 2001 http://www.wapforum.org

180. Ward, A.; Jones, A.; Hopper, A.:A New Location Technique for the Active Office, IEEE PersonalCommunications, Vol. 4, No. 5, Oct. 1997, 42-47

181. Wikipedia, the free encyclopedia:http://www.wikipedia.org

182. Weber, J.:Globale Selbstlokalisierung für mobile Service Roboter, PhD Thesis, Universityof Kaiserslautern, 2002

183. Zander, M.:Anbindungen von Handhelds an das Sitzungsmanagement von DreamTeam,Diploma thesis, University of Hagen, Sept. 2001

184. Zuendt, M.; Dornbusch, P.; Schaefer, T.; Jacobi, P.; Flade, D.:Integration of Indoor Positioning into a Global Location Platform, 1st Workshopon Positioning, Navigation and Communication 2004, Published at ShakerVerlag ISBN 3-8322-2553-6, March 2004, Hanover, Germany

196 Jörg Roth

Numeric0/1 knapsack problem 93

AAccuracy 10, 14Active Badge 22, 57, 87

authenticated badges 23exchange server 24, 57location server 24, 57message server 24, 57name server 24, 57

Active Bat 26Advanced Encryption Standard

see AES

AES 25, 133Angle of arrival 15AOA 15Apache Web Server 137Assistance service 10Assisted GPS 92Association 46

compressing ~ 48link compression 49originator 49structural compression 49target 50

ATKIS 40, 158, 159Authenticity 125

BBeacon 67Bluetooth 1, 120, 124Buffer 103, 150

CCDMA 19Cell of origin 15Certificate revocation list 133CGI script 137, 142Cluster 59Clustering 59

algorithm 60cluster root 59cluster tree 61fully distributed ~ 59, 109minimal ~ 59

CoCo 6Code division multiple access 19ComMotion 6, 42Compression ratio 175Context 5, 6, 33, 140

domain ~ 5infrastructure ~ 5physical ~ 5system ~ 5

Context awareness 5Context space 108Context toolkit 6

widget 6Contextors 6Controlling device 105COO 15, 86Cooltown 138

~ museum 138Coordinate system

Cartesian 41earth centred, earth fixed 13ECEF 13Gauß-Krüger 13, 19latitude, longitude, altitude 13, 41LLA 13plane 13, 41Universal Transversal Mercator 14UTM 14

CORBA 119, 120Coverage 14CPen 119Cricket 27, 85CRL 133Cyberguide 138CybreMinder 6

DDAE 120DGPS 21, 92

Index

Index 197

DHCP 67Diameter 152Differential GPS 21Diffie-Hellman key exchange 133Distance 152Distribution

normal ~ 81, 86of domains on location servers 59of GPS measurements 20of location sensor values 80uniform ~ 81, 82

DNS 67, 108Domain 39, 43

abstract ~ 52concrete ~ 52master 44name 43name component 44phantom ~ 156root ~ 44sub~ 44

Domain Name Servicesee DNS

DomainEdit 36, 162DreamTeam 129DSDV 111Dynamic Host Configuration Protocol

67

EEasting 19EDBS 40EGNOS 22Enhanced observed time difference 15E-OTD 15European Geostationary Navigation

Overlay System 22

FFirewire 124Flirt finder 58, 106, 116Friend finder 105Fuzzy set 183

GGALILEO 22, 92

commercial service 22CS 22open service 22OS 22PRS 22public regulated service 22

Geo data representationaccurate 148analytical 148approximated 148class 148dimension 148, 149layer 148raster 148vector 148

Geocast 105also see Semantic geocastatom 107geo host 106geo node 106geo router 106partition 107

Geographic information system 147GIS 147Global Positioning System

see GPS

Global System for Mobile communication

see GSM

Globalnaya Navigationnaya Sputnikovaya Sistema 22

GLONASS 22GML 40GMML 40GPS 1, 6, 16, 18, 36, 86

2 distance root mean square error 202dRMS 20almanac 17, 92C/A-Code 19CEP 20circular error probability 20coarse/acquisition code 19FOC 18full operation capability 18GDOP 19geometric dilution of precision 19initial operation capability 18IOC 18L1 19L2 19P-Code 19PPS 19

198 Jörg Roth

precise positioning service 19precision code 19receiver 40SA 19selective availability 19SPS 19standard positioning service 19system time 17

GSM 1, 7, 28, 36, 86, 124CBCH 28, 106cell 81cell broadcast channel 28, 106cell of global identity 29CGI 29HLR 28home location register 28segment antennae 30TA 30timing advance 30, 86, 92UL-TOA 30uplink time of arrival 30visitor location register 28VLR 28

Guide 106, 138G-XML 40

HHandover 96Height profile 155Hierarchy 44HTTP 129, 139

proxy 139

IIEEE 802 120i-mode 8, 138Integrity 125Internet Protocol 119Inter-server protocol 68, 69

look up 70maintenance 70registration 70

IP 119IPX/SPX 120IrDA 24, 119, 120, 122, 124

JJava Micro Edition 9, 119, 128, 179

connection 121Mobile Information Device Profile 179

Java RMI 119Java Standard Edition 119, 128Java Topology Suite 150Jini 119JTS 150

KKalman filter 81

LLandXML 40LBS

see Location-based service

LIF 40Linear ring 151Link Service Access Point 126Listener 77LLS 61LMS 90Local advertisement 105Local location server 61Local mapping server 90Location 41

geographical ~ 41physical ~ 14, 41, 42semantic ~ 14, 35, 36, 39, 41, 42, 43

Location Interoperability Forum 40Location Working Group 40

Location model 35, 39geographic ~ 39semantic ~ 39

Location server 36, 59Location Server Infrastructure

see Nimbus Component

Location service 79Location-aware application 1Location-awareness 5Location-based application 7Location-based billing 10Location-based service 1, 7

Index 199

Loco Guide 138Lookup protocol 68, 69LSAP 126LSI 57

see Nimbus Component

MMAC 125, 133Mapping protocol 68, 69Mapping server 85, 90MediaCup 41MemoClip 41Message Authentication Code 133MIME type 126MLP 40Mobile Location Protocol 40Mobile Positioning Centre 30Mobile Positioning System 29Mozilla Browser 139MPC 30MPS 29Muffin Web Proxy 144Multicast IP 67, 107, 122, 124Multipolygon 151

NNavigation System with Timing and

Ranging - Global Positioning System 18

NAVSTAR GPS 18Neighbour 102Network 119, 120, 121Network Kernel Framework

see NKF

Nexus 40, 58Area Service Register 58ASR 58Augmented Area 41Augmented World Model 41Augmented World Modelling Language

40AWML 40AWQL 40SpaSe 58Spatial Model Server 58World Querying Language 40

Nibble 30Night Guide 138Nimbus

command 68goals 34, 181location-based event 77

Nimbus cache modecomplex ~ 75simple ~ 75

Nimbus componentcommunication & security 37, 38, 130geometry & geodesy 36, 38, 147location model 36, 38, 39, 42, 43Location Server Infrastructure 36, 38, 57LSI see Location Server InfrastructureNetwork Kernel Framework see NKFphysical resolution 37, 39, 47, 57, 89PinPoint see PinPointpositioning driver see Virtual Positioning

Systemproximity resolution 37, 102resolution client 37, 57semantic geocast see Semantic geocastsemantic resolution 37, 39, 46, 47, 57, 96semantic resolution (area variant) 98semantic resolution (network variant) 62semantic resolution with compressed

associations 50trigger services 37, 57, 77virtual positioning see Virtual Positioning

System

Nimbus layerapplication layer 37base layer 36geo data 35positioning system 35service layer 37

Nimbus modeinbound 66outbound 66

NKF 37, 67, 119, 120, 121C codec 122channel 126codec module 122communication gateway 126discovery 128framework module 121global cascading name 127global naming 126host 126inspection module 122Java codec 122kernel module 122

200 Jörg Roth

local naming 126lookup 128lookup module 121method 124negotiation 128negotiation module 121network module 122processing module 122service module 122

NMEA 0183 40Northing 19

OOBEX 121, 125, 126, 129Object Exchange Protocol 121Open GIS Consortium 40OpenLS 40OSI Reference Model 120

PPalmOS 9, 128PalmSpot 24, 36, 67, 85, 86

secure beacon frame 25Particle 81

filter 81Physical location

see Location

Physical resolutionsee Nimbus component

PinPoint 37, 38, 139black list 144context manager 140proxy 139simulation mode 144tag 140unlisted server 144white list 144

Pitch 15Pocket DreamTeam 129Point of interest 8, 9PoLoS 83Polygon 151

overlay operation 150Position 41Position probability 80

grid 81Positioning 15

techniques 15Precision 14Privacy 125PRN 19Proximity 102

area 103Proximity resolution

see Nimbus component

Pseudo random noise 19Pseudo range 17Pull service 10Push service 10

QQuickStep 108, 129

RRadio Frequency Identification 26Random way point model 172RAUM Location Model 41Relation 44RFID 26RLE 123RMI 120Robotics 80Roll 15RPC 120RS232 122RSA 133RTCM 104 21

SScope 14Semantic geocast 37, 38, 105, 109

address propagation 109delivery 110event-based 116fast propagation 111intermediate LS 110message passing 109native 116registration 109slow propagation 111source LS 110stealth mode 115

Index 201

target LS 110Semantic location

see Location

Semantic proximity 58Semantic resolution

see Nimbus component

Semantic structure 43Sensor data fusion 80, 92Serial port 124Service Location Protocol 67Service protocol 68, 69Servlet 137Short Message Service 8Simple Object Access Protocol 121Simulator 36Situation 6, 33Situation awareness 5SLP 67Smart phone 9SMS 8, 92SOAP 121, 126Socket factory 120Spam 115Spatial database 147SpotON 25Symbian 9

TTCP 122, 124TCP/IP 120, 122, 124TDOA 15TIGER/Line 40, 158Time difference of arrival 15Time of arrival 15TOA 15Topologically Integrated Geographic

Encoding and Referencingsee TIGER/Line

Tracking 15Tracking service 10Transport Layer Security 125Trigger service 10TSL 125Tunnelling SSL 144

UUDP 67, 122, 124ULF

see Universal Location Framework

UMTS 1, 9, 124Universal Location Framework 83

activity 83contextual fusion 83fusion 83location stack 83sensor 83

Universal Location Service 58, 82area 82location register 58location server 58, 82mask 82position 82

USB 124

VVirtual Positioning System 36, 83

access 84augmentation 84collection 85, 90dynamic property 87inner positioning system 84location 84location request 84mapping 84mapping driver 90positioning driver 36, 84, 87, 90, 179property 84resolution 85selection 85, 90simulation mode 101static property 87

Visual Tag 27Voronoi diagram 82VPS

see Virtual Positioning System

WWAAS 21WAP 8, 129, 138WGS 84 13, 88, 153, 155Wide Area Augmentation System 21Wikipedia 183Winsock 120

202 Jörg Roth

WIPS 24Wireless Application Protocol 8Wireless Indoor Positioning System 24WLAN 802.11 1World Geodetic Survey 1984 13, 153

XX.509 134XML 40

YYaw 15

Index 203

204 Jörg Roth

Documents

A Decentralized Location Service Providing Semantic Locations · PDF fileA Decentralized Location Service Providing Semantic Locations ... 9.3.7 Discovery, ... Europe will set up a