Nomadic Positioning Services for a Mobile Services Platform

(1)

Nomadic Positioning Services for a

Mobile Service Platform

E.A.M. Schoot Uiterkamp

Thesis for a Master of Science degree in

Telematics from the University of Twente,

Enschede, The Netherlands,

(2)

(3)

Nomadic Positioning Services for a

Mobile Service Platform

E.A.M. Schoot Uiterkamp

Thesis for a Master of Science degree in

Telematics from the University of Twente,

Enschede, The Netherlands,

26 August 2005

University of Twente Department EWI

Architecture and Services of Network Applications Graduation Committee:

Dr. ir. A.T. van Halteren Dr. ir. D.A.C. Quartel B.B. Shishkov, Msc.

(4)

(5)

Abstract

There is a growing number of people that carry a personal mobile device, such as a Personal Digital Assistant (PDA) or a smartphone. These mobile devices are becoming more and more powerful. Processing power increases and a growing number of mobile devices is equipped with wireless networking capabilities, such as WLAN, GPRS, UMTS or Bluetooth.

These trends enable a new way of service provisioning, called nomadic service provisioning. This type of service provisioning envisions the use of personal mobile devices as a platform for the deployment of services. Individuals start acting as service providers to others located anywhere on the Internet. Due to temporary unavailability of the mobile device (e.g. as a result of network disruptions or battery failure) nomadic services are offered on an ad-hoc basis.

This thesis investigates a software infrastructure for nomadic service provisioning. This software infrastructure, called Mobile Service Platform (MSP), aims to simplify the development of nomadic mobile services. In this thesis MSP is used to develop a nomadic positioning service.

A nomadic positioning service offers the position of the mobile device to interested parties. However when designing such a service a number of issues have to be taken care of. The processing power of mobile devices has increased, but is still limited. Wireless networks are slow compared to fixed networks and the user may have to pay for the amount of data that is communicated. Therefore the design of the nomadic positioning service meets with the following requirements:

a) Efficient use of bandwidth – the amount of data traveling between the mobile device and the (fixed) Internet can be tuned to the capacity and cost of the available wireless technology;

b) Numerical scalability – the bandwidth usage on the wireless link does not increase with the number of parties interested in the location of a mobile device;

c) Plug-and-work – no additional configuration is required for publishing services when new devices come online;

Besides the limited processing power and limited network capacity, a mobile environment introduces a number of other challenges, such as Network Address Translation (NAT), Automatic Private IP Addressing and temporary service unavailability because of broken network connections. Another issue that needs to be taken care of is that position information is considered privacy-sensitive information. The last issue is that the used positioning technologies may not be available or applicable at any time. Therefore the nomadic positioning service provides a technology independent way to determine the position of a mobile device, supporting GPS, WiFi, Bluetooth and possibly other technologies for positioning.

To satisfy these requirements the nomadic positioning service uses a service discovery architecture combined with positioning software. Service discovery protocols make it possible to offer services to anyone, anywhere over the network without any additional configuration after the first set up. The Jini Surrogate architecture is a service discovery architecture that defines protocols for service discovery.

The Jini Surrogate architecture specifies a protocol-independent structure that allows for an efficient way to offer nomadic services over a network. MSP provides an HTTP based implementation of the Jini Surrogate architecture. The Jini Surrogate Architecture specification defines how services can join a Jini network using a

(6)

surrogate service. The surrogate service runs in the fixed network and acts as a proxy on behalf of a device. All communication to the nomadic service runs transparently through the surrogate service. This allows for optimization of the amount of data that is communicated via the wireless network. When more parties are interested in the position of the mobile device, requests from these parties can be combined into one request to the nomadic service or these requests can be answered by the surrogate with the last known position of the mobile device. This optimizes the amount of data communicated over the wireless network and prevents an increase in the amount of resources needed from the device and wireless network when more parties are interested in the position. Alternatives to the Jini Surrogate architecture, such as SLP or UPnP can be used for service discovery. These technologies however do not provide any functionality to optimize usage of the wireless network and processing power in the mobile device.

Place Lab is a Java library that provides functionality for determining the position of a device using GPS, WIFI, GSM, Bluetooth and other technologies. In the nomadic positioning service WiFi will be used for the positioning for demonstration purposes. Place Lab offers functionality to calculate the position of the mobile device on the device itself. This allows the service to send only the calculated position and no other privacy sensitive information to the service user. Place Lab however only provides position information on the device but does not allow others to retrieve the device position.

This Masters Thesis demonstrates the feasibility of nomadic positioning services, while dealing with the requirements and issues mentioned above, using a combination of the Jini Surrogate architecture and Place Lab. Along the way, problems with the Jini Surrogate Architecture, MSP, Place Lab and the used positioning hardware are reported. For some of these problems a solution is presented; others are left for further research.

(7)

Preface

This Masters Thesis involves research, design and implementation on nomadic positioning services. Combining Place Lab positioning technologies with the Jini Surrogate architecture seems a promising way to realize positioning services in a device and network independent way. This thesis researches whether this combination is as ideal as it looks. This Masters Thesis was carried out internally, at the University of Twente in Enschede from January until July 2005.

I would like to thank my supervisors Aart van Halteren, Dick Quartel en Boris Shishkov. With their comments, help and suggestions I enjoyed working on this assignment and was able to finish it.

I want to thank Peter van Tol and Rob Schoot Uiterkamp who took the time to read this thesis and gave me good advice and comments on how to improve it.

Furthermore I want to thank my family, friends and student colleagues for the moral support and their critical view on what I was doing.

Emiel Schoot Uiterkamp

(8)

(9)

3 DESIGN OF A NOMADIC POSITIONING SERVICE... 21

3.1 INTRODUCTION... 21 3.2 REQUIREMENTS... 22 3.2.1 Functionality ... 22 3.2.2 Performance ... 22 3.2.3 Scalability... 23 3.2.4 Reliability ... 23 3.2.5 Manageability... 23 3.2.6 Privacy ... 23 3.3 HIGH-LEVEL DESIGN... 24

3.4 THE MOBILE SERVICES PLATFORM... 25

(10)

3.5 THE POSITIONING SERVICE... 35

3.5.1 The Jini service interface... 35

3.5.2 MSPLocationService ... 37

3.6 THE SERVICE USER... 43

3.7 VALUE-ADDED SERVICE... 43

3.7.1 Requirements... 44

3.7.2 High-Level Design ... 45

3.7.3 Mapper service ... 46

3.7.4 Changes to the MSPLocationService... 47

4 EVALUATION OF THE NOMADIC POSITIONING SERVICE... 49

4.1 REQUIREMENTS EVALUATION... 49

4.1.1 Functionality ... 49

4.1.2 Performance ... 50

4.1.3 Scalability... 54

4.1.4 Reliability and Manageability... 55

4.1.5 Privacy ... 55

4.2 EVALUATION OF THE VALUE-ADDED SERVICE... 55

4.3 ENCOUNTERED PROBLEMS... 56

5 CONCLUSIONS ... 59

5.1 AN EFFICIENT AND PRIVACY SENSITIVE WAY TO OFFER POSITION INFORMATION... 59

5.2 CHALLENGES IN A MOBILE ENVIRONMENT... 60

5.3 TECHNOLOGY INDEPENDENT POSITIONING... 61

6 RECOMMENDATIONS FOR FURTHER RESEARCH ... 63

6.1 FURTHER RESEARCH ON THE JINI SURROGATE ARCHITECTURE... 63

6.2 FURTHER RESEARCH ON PLACE LAB... 63

7 BIBLIOGRAPHY ... 65

GLOSSARY ... 67

APPENDICES... 69

APPENDIX A: CLASS DIAGRAM – MSPLOCATIONSERVICE SERVER... 69

APPENDIX B: CLASS DIAGRAM – MSPLOCATIONSERVICE SURROGATE... 70

(11)

(12)

(13)

1

Introduction

More and more people own a personal mobile device such as a Personal Digital Assistant (PDA) or a smartphone. Processing power in these personal mobile devices is increasing and mobile devices are more and more equipped with wireless networking capabilities, such as WLAN, GPRS, UMTS and Bluetooth. These different types of networks enable the devices to communicate with each other and with their environment. Based on knowledge about their environment and near devices mobile devices can identify their location and their context.

The increasing processing power of these mobile devices and the advance in wireless connectivity (WLAN, GPRS, UMTS and Bluetooth) allow for a new way of service provisioning, called nomadic service provisioning. Nomadic service provisioning allows individuals to deploy a so called ‘nomadic service’ on a mobile device. Individuals can act as service providers by offering a nomadic service to interested parties via the Internet. These nomadic services are offered on an ad-hoc basis to users (due to possible temporary unavailability as a result of network disruptions or battery failure). Within the Freeband AWARENESS project a Mobile Services Platform (MSP) has been developed. The MSP is a software infrastructure that aims to simplify the development of nomadic services.

Location based services are services that use the ability of context-awareness to provide users of mobile devices with personalized services tailored to a specific location. As a result of increasing processing power and an advance in wireless connectivity, the application range of location based services is rapidly developing, particularly in the field of geographic, telematic, traffic, tourist and logistic services. An example of a location based service is a service that gives information about nearby restaurants. [Mah04] Another example is a nomadic positioning service. A nomadic positioning service is a nomadic service that offers the position of the mobile device to interested parties via a network.

However when designing such a nomadic positioning service a number of issues have to be taken care of. The processing power of mobile devices has increased, but is still limited. Wireless networks are slow compared to fixed networks and the user may have to pay for the amount of data that is communicated. Therefore the design of the nomadic positioning service meets with the following requirements:

b) Numerical scalability – the bandwidth usage on the wireless link does not increase with the number of parties interested in the location of a mobile device; c) Plug-and-work – no additional configuration is required for publishing services when new devices come online;

Besides the limited processing power and limited network capacity, the combination of mobile devices and wireless networks introduces a number of challenges specific for mobile computing environments. Examples of these challenges are Network Address Translation (NAT), Automatic Private IP Addressing and temporary service unavailability because of broken network connections. Another issue is that the used positioning technologies may not be available or applicable at any time. Therefore the nomadic positioning service provides a technology independent way to determine the position of a mobile device, supporting GPS, WiFi, Bluetooth and possibly other technologies for positioning.

(14)

To satisfy these requirements the nomadic positioning service can use a service discovery architecture combined with positioning software. Service discovery protocols make it possible to offer services to anyone, anywhere over the network without any additional configuration after the first set up. The Jini Surrogate architecture is a service discovery architecture that defines protocols for service discovery. The Jini Surrogate architecture specification is independent of the used protocol for communication. MSP provides an HTTP based implementation of the Jini Surrogate architecture. This implementation can cope with the challenges of the mobile environment. Furthermore is may solve some of the efficiency issues mentioned before. Alternatives for the Jini Surrogate architecture are the Service Location Protocol (SLP) or Universal Plug and Play (UPnP).

There is a Java library, Place Lab, that provides functionality for determining the position of a device using e.g. GPS, WIFI, GSM or Bluetooth beacons. This library allows switching between available positioning technologies. It however only provides position information on the device but does not allow others to retrieve the position of the device. Combining this positioning technology with a service discovery architecture seems a promising way to realize positioning services in a device and network independent way.

This chapter starts with an overview of the objectives of the AWARENESS project, in which the MSP has been developed. One of the features of the AWARENESS infrastructure is the development of nomadic services. In the second section the concept of nomadic services is introduced. In the third section the nomadic positioning service and the problems that arise when designing and implementing such a nomadic positioning service are considered. In the fourth section the Jini Surrogate architecture is introduced as a possible solution to these problems. Finally the approach that will be taken to prove whether this assumption is correct is explained.

1.1 The Freeband AWARENESS project

Context-awareness allows for a new type of context-aware network and service infrastructure. The Freeband AWARENESS project aims at researching and designing such an infrastructure to support context-aware mobile applications. The Freeband AWARENESS project is a Dutch collaborative project on context AWARE mobile NEtworks and ServiceS. Eight partners from industry and academia work together in this project (Lucent Technologies, University of Twente, Roessingh R&D, Telematica Instituut, Twente Institute for Wireless and Mobile Communications, Ericsson, Yucat, Twente Medical Systems International). [AWA05]

1.1.1 Goal of the AWARENESS project

The goal of the Freeband AWARENESS project is to research and design a service and network infrastructure for context-aware and pro-active mobile applications, and validate this through prototyping with mobile health applications. In the AWARENESS project vision a human user is always and everywhere surrounded by a networking environment ('ubiquitous') that is able to determine the identity of the user and the (upcoming) context information that is (or might become) relevant to service provisioning ('attentiveness'), such that the user can have anywhere, anytime access to mobile services in a secure and privacy-sensitive manner.

1.1.2 The AWARENESS Infrastructure

The AWARENESS network and service architecture consists of three layers (figure 1.1): the Network Infrastructure Layer, the Service Infrastructure Layer and the Mobile Applications Layer. The Network Infrastructure Layer and the Service

(15)

The network infrastructure provides

context-aware mobility support in a dynamic network environment where unmanaged and managed networks co-exist. The network supports context-aware mobility by taking the context of the user into account when controlling the connectivity that is provided to this user, for

instance, dynamic routing protocols,

security settings and network selection. Furthermore the network provides a source of context information, such as presence information or available bandwidth.

The service infrastructure consists of generic service components that support easy and rapid development of ubiquitous attentive applications. The support functionalities include context management, intelligent context information processing, federated identity management, third party access control, mobility management, service discovery, privacy enforcement and security mechanisms.

The AWARENESS infrastructure is validated by prototyping context-aware and pro-active mobile applications. Most applications in the AWARENESS project are in the healthcare domain. AWARENESS will develop a mobile health service platform and health applications.

1.2 Nomadic Services

One of the promising features the AWARENESS infrastructure offers is the development of nomadic services. Nomadic services are services that can be offered by a mobile device. These nomadic services are offered on an ad-hoc basis to users (or even to other services). Because nomadic services are offered by a mobile device, they may enter or exit the network on arbitrary moments.

Figure 1.2: A Nomadic Service Provider and Service User

Figure 1.2 shows a nomadic service provider offering a service on a mobile device. The service may be offered through a 2,5G or 3G network as well as through any other wireless network. This network is connected to the Internet, via which the service user on a fixed or mobile device can use the service.

Service Provider Service User 2,5G or 3G Network Internet Mobile Device Nomadic Service Fixed or Mobile Device

Figure 1.1: The AWARENESS Infrastructure Mobile Application Layer

Context-aware, pro-active

Service Infrastructure

Generic service components Context management

Security and identity

Network Infrastructure

Context-aware mobility support

AWARENESS Infrastructure

(16)

An important issue for nomadic services is efficient communication. Because part of the communication runs over a wireless network (in which the user has to pay for the data that is communicated), it is important that the amount of data communicated over the wireless network can be optimized. Preferably the amount of resources needed from the device and wireless network do not increase when more parties are interested in the nomadic service. This improves scalability. Nomadic services may appear and disappear because of network availability or other issues. Once set up it should require minimal (preferably zero) configuration to support additional mobile devices.

Another important issue is privacy. Because the nomadic service may share privacy-sensitive information, it must be guaranteed that this information is not available for everyone. It should be possible to authenticate the service users that are able to receive this information. Furthermore as less privacy sensitive information as possible should be sent through the wireless network.

Because nomadic services run in a mobile environment a number of challenges may be encountered. Examples of such challenges are Network Address Translation (NAT), Automatic Private IP Addressing, temporary unavailable because of limited network connection, limited processing power and limited battery power. [Hal04]

Network Address Translation (NAT) is the translation of an IP address used within one network to a different IP address known inside another network. Mobile devices are connected to for example a 2.5 or 3G network, which is connected to the Internet via a router. The mobile devices have a local IP address on the 2.5 or 3G network, all local IP addresses are mapped to one global IP address on the Internet. This helps to ensure security and reduces the demand on the (limited) number of global IP addresses. However, NAT inhibits hosts connected to the public Internet to initiate a connection to a host behind a NAT router. Consequently, initiating a connection to a service deployed on a mobile device becomes practically impossible.

Automatic Private IP Addressing (APIPA) is a feature that enables a device to assign itself an IP address when there is no DHCP server available to perform that function. When a mobile device enters a network without a DHCP server, it may assign itself a IP address, however this address is not known by other devices in the network. The IP address cannot be resolved through a DNS service. Consequently, finding the IP address of a service deployed on a mobile device becomes practically impossible. Mobile devices use a wireless network to communicate. These networks can be temporarily unavailable because of interference or other reasons. When a service is offered via this network, the service is also unavailable. Limited processing and battery power of a mobile device limit the life-time of services that are offered on that device. A developer of nomadic services needs to keep these limitations in mind. To make a service available to service users, communication between the service user and the service needs to be established. In fixed networks the position of a service (e.g. the host it runs on) can be fixed and therefore the service user can easily connect to the service. In a mobile environment however this is not the case. Services may appear and disappear whenever they want and run on different positions (on one host, but with a changing address because of roaming through different networks). If the position of the service is not fixed there are several ways to make the service available to other users. One way is advertising the service using service discovery protocols, such the Jini, SLP or UPnP. These service discovery protocols allow services to be advertised on the network and allow service users to discover and connect to

(17)

1.3 Nomadic Positioning Services

There are many services one can offer on a mobile device. An example of a useful nomadic service is a nomadic positioning service. A nomadic positioning service is a service that can offer the current position of a mobile device (and its owner) to other users.

Such a service may be used as a standalone service or as a building block for other services. The standalone service can be used to find your friends or it can be used by parents who want to know where their children are. The positioning service may also be used by value-added services, to which the position of the service is relevant. FLAVOUR is a friendly location-aware

conference aid with privacy observant architecture. The FLAVOUR project offers a conference aid, which will be provided for the first time to the participants of the fourth Annual Conference on Scalable Vector Graphics (SVGOpen 2005) taking place in August 15-18 at University of Twente. This conference aid can find fellow attendees, locate and use resources and receive messages and notifications. This aid uses the nomadic positioning service to locate the attendees. FLAVOUR is a service that acts as a service user. [Mut05]

An example of a value-added service that enhances the basic functionality of the nomadic positioning service is a database

service with a database, in which the position of beacons (GPS, WIFI access points, GSM cells, Bluetooth beacons, etc) can be stored. Users can download a databaseview with position information of all known beacons around their current position (based on at least one detected beacon). When a user detects a beacon that is not already in the database, information about this beacon can be added to the database.

To offer the current position of the mobile device (on which the service runs) to service users, the service must be able to determine the position of the mobile device. There are several types of positioning hardware, such as the Global Positioning System (GPS), Bluetooth, WIFI, GSM and others. Positioning hardware is able to detect corresponding beacons. Which technology should be used depends on the available technologies on the mobile device. Furthermore it depends on the situation in which it is used, because each technology has its own advantages.

Based on the detected beacons, the response time of the beacons and signal strength the position of a device can be determined by positioning software. Positioning software uses certain algorithms to determine the position. Several algorithms are available for the different positioning hardware, each varying in complexity and accuracy. Depending on the desired accuracy and the used positioning hardware suitable positioning software can be chosen. This positioning software provides functionality to determine the position of the mobile device. It however does not offer functionality to provide the position of the device to other users. Combining the positioning software with a service discovery architecture may solve this issue.

Mobile Device Nomadic Positioning Service Positioning Software Positioning Hardware GPS, GSM, WiFi, etc.

Figure 1.3: Nomadic Positioning Service on a Mobile Device

(18)

1.4 Combining service discovery and positioning software as a solution

Before a service user can use the service, a connection needs to be established between the service user and the service. In traditional networks the address of a service is most of the time fixed and therefore the service user can easily find and connect to the service. In a mobile environment however this is not the case. Services may appear and disappear whenever they want and run on different positions (on one host, but with a changing address because of roaming through different networks). To allow service users to connect to a nomadic service, service discovery protocols are required. A service discovery architecture is an architecture that allows services to be published, invoked and discovered via a network. Such an architecture makes it possible to offer services to anyone, anywhere over the network. It makes the network more dynamic by enabling the ability to add and delete services flexibly. A service discovery

architecture in general consists of a service provider, a service registry and a service user. The service provider can register its service with the service registry. The service user is able to search the service registry to find a service that it requires. Using a service discovery architecture the nomadic positioning service is able to offer its service to interested parties.

There are a number of service discovery architectures that can be used, such as Jini and the Jini Surrogate architecture, SLP or UPnP. Each architecture offers its own advantages and disadvantage. Jini and SLP focus on a large scale network, such as the Internet, UPnP focuses on a smaller home network. The features, advantages and disadvantages of these different architectures have to be compared and the most ideal one will be used in the design and implementation of the nomadic positioning service. Positioning software is software that is able to determine the position of a mobile device, based on positioning technologies such as GPS, WIFI, GSM or Bluetooth. These positioning technologies however may not be available or applicable at any time. Therefore the nomadic positioning service should use positioning software that supports several types of positioning technology. There is a Java library, Place Lab, that provides functionality for determining the position of a device supporting GPS, WIFI, GSM and Bluetooth.

Combining a service discovery architecture and positioning software may allow design and implementation of a nomadic positioning service that meets the requirements that were set in the introduction. Furthermore this combination may solve the challenges of the mobile environment.

Service Registry Internet Service Provider Nomadic Service Service User

(19)

1.5 Research Questions

A number of problems can be encountered when designing and implementing a nomadic positioning service. The design must be able to cope with these problems. Which hardware needs to be used for the positioning, how can the service be advertised and distributed through a network and how can one overcome the challenges of a mobile environment? The combination of a service discovery architecture and Place Lab seems a feasible approach to solve these problems.

The main research question is:

Is the combination of a service discovery architecture and Place Lab an efficient and privacy-sensitive way to realize nomadic positioning services in a device and network independent way?

Before this question can be answered a few sub-questions need to be answered. Is it possible to design and implement a nomadic positioning service based on the combination of Place Lab and a service discovery architecture that is efficient in bandwidth usage, is numerical scalable and needs not additional configuration when new devices come online.

Is it possible for a nomadic service to join a service discovery architecture, although the nomadic service may not be able to meet the requirements due to limited processing power and wireless network links? And is the service discovery architecture able to overcome the issues that may be encountered in a mobile environment, such as NAT, APIPA, failing wireless network connections and limited processing and battery power?

Is it possible to provide a technology independent way to determine the location of a mobile device, based on GPS, WiFi, Bluetooth and possibly other technologies for positioning?

These questions will be answered in this Masters Thesis.

1.6 Approach

Several approaches can be taken to research whether combining the Place Lab positioning technology with a service discovery architecture is a feasible way to realize nomadic positioning services that meet the set requirements. This thesis starts with a literature study to get a view on the background and to determine with service discovery architecture seems the most ideal one for the development of a nomadic positioning service. Next a nomadic positioning service will be designed based on the combination of Place Lab and the chosen service discovery architecture. This design will be implemented and evaluated to see whether the requirements have been met and the challenges of the mobile environment have been overcome.

1.6.1 Background

To get a good view of the context of the assignment, literature on the subject and on research that has already been done on this subject has been studied. More specific literature on service discovery architectures, Place Lab, J2ME (JSR82, JSR179, etc) and on the combination of these technologies has been studied. Good literature on these subjects has been found in the library of the University of Twente or on the Internet.

Service discovery architectures provide a framework that can be used to advertise services over the network. Research will be done on these service discovery

(20)

architectures. The different architectures offer different ways to publish a service via a network. This research must answer how a service discovery architecture can be used to advertise a nomadic positioning service and which architecture seems the most ideal one for this task.

Place Lab offers functionality to determine a users position based on hardware beacons. Place Lab can be used in several ways, such as stand-alone or integrated in the service. These ways will be compared and the best one will be used in the nomadic positioning service. Furthermore research will be done on determining or estimating a position based. There are different ways to determine and estimate a position of a mobile device. A number of simple Place Lab applications have been implemented to compare the different ways in which Place Lab can be used and how the position can be determined and estimated.

To get familiar with Place Lab, the chosen service discovery architecture and other technologies that are important for this assignment, some basic services have been developed using these technologies. The development of these simple services gave a practical insight in what was described in literature. Furthermore the technologies have been combined in different ways to examine which combination was most suitable.

To run a nomadic positioning service on a mobile device it is necessary to implement the service in J2ME (J2ME applications or midlets), because mobile devices (and especially devices with limited processing power) do not support J2EE.

1.6.2 Design and implementation of a Nomadic Positioning Service

Based on the studied literature and the experience gained by developing some simple applications, a nomadic positioning service will be designed. This design starts with the refinement of the requirements. The requirements that were set in the introduction will be explained in more detail. Furthermore this design consists of a high-level overview of the different building blocks of which the nomadic positioning service consists. This design describes these building blocks and how they should be combined. In several steps these building block have been decomposed into smaller building blocks.

To prove the usability of positioning technologies combined with the Jini Surrogate architecture for nomadic positioning services, value-added services have been developed. Value-added services are services that enhance the basic functionality of the nomadic positioning service. There are many possible value-added services that can be designed based on the nomadic positioning service. A database service that offers position information has been designed and implemented.

1.6.3 Evaluation

Next, the nomadic positioning service is implemented according to the design. The implementation will be based on Place Lab combined with the chosen service discovery architecture. Finally, this implementation will be evaluated based on the requirements that were set before. The assumption that the combination of Place Lab with the chosen service discovery architecture is feasible is validated. The chosen service discovery architecture is evaluated and if necessary alternatives will be considered. Based on the evaluation of the design and implementation, conclusions can be drawn and advice for further research can be given.

(21)

1.7 Thesis structure

This thesis is structured as follows:

Chapter 1 introduces the subject of this thesis. First is explained what the AWARENESS project is and what kind of research is done within this project. Next this chapter explains what nomadic services and more specific what nomadic positioning services are and it mentions the technologies needed to provide these services. Furthermore the approach for this assignment is given.

Chapter 2 gives an overview of the technologies that are needed to provide a nomadic positioning service. First this chapter handles several types of positioning hardware, such as GPS, WiFi, Bluetooth and GSM beacons. Next it handles positioning software and protocols for service discovery. Finally it explains several security and privacy issues that are relevant to nomadic services.

Chapter 3 describes the design and implementation of a nomadic positioning service. This chapter starts with a high-level design and uses a top down approach to specify the different elements of this service. The design is validated by the implementation of a prototype. Next it describes the design and implementation of a value-added service. The value-added service shows that the nomadic positioning service can be used as a building block for other services. The value-added service enhances the basic functionality of the nomadic positioning service. Furthermore this chapter shows how the nomadic positioning service needs to be adapted for usage of this value-added service.

Chapter 4 starts with a general evaluation and a requirements evaluation of the designed and implemented prototype of the nomadic positioning service. Next this chapter gives an evaluation of the value-added service. This chapter evaluates the designs based on the requirements that were set in the third chapter.

Chapter 5 describes the conclusions that can be given based on the literature study and the experiences that have been encountered during the Masters assignment. In this chapter the research questions are answered. Furthermore this chapter gives a reflection on this Masters Thesis.

Chapter 6 gives recommendations for further research. Issues that were discovered during this Masters Thesis or issues that were deliberately not researched, but that are interesting for further investigation, are described in this chapter.

(22)

(23)

2

Background

To provide a nomadic positioning service, as described in the first chapter, that can offer the current position of the mobile device, the mobile device must be able to obtain its current position. There are several technologies that can be used to determine ones position, such as GPS, WIFI, Bluetooth beacons, GSM cells and sensors. Based on at least one of these positioning hardware technologies the current position of a mobile device can be determined. Each of these hardware technologies has its own advantages and disadvantages, such as accuracy, coverage, cost, reliability, etc.

Several types of positioning software can be used to determine the current position based on one or more types of positioning hardware. The JSR179 Location API for J2ME is a library that offers an API for localization on mobile devices. This API needs a location provider that communicates with the hardware, needed for localization. Place Lab is an example of such a location provider. Place Lab is a java library that can calculate the current position based on GPS, GSM triangulation, Bluetooth beacons, etc. Place Lab can be used as a location provider in the JSR179 or can be used standalone. There are several other tools that can be used to scan for near WiFi beacons, these tools however do not have a Java interface.

Once a nomadic positioning service has been designed and implemented, it needs to be published so other users can locate it and connect to it. There are several ways to advertise a service to potential users. One way of advertising a service is by using service discovery protocols, such as Jini, SLP or UPnP. These discovery protocols are designed for a fixed network, therefore implementing them in a mobile environment may cause problems.

2.1 Positioning Hardware

To be able to provide location-based services the service must be able to discover the current position of the device. The position can be expressed in spatial terms or as text description. A spatial position is expressed in latitude, longitude and altitude. There are several positioning systems, such as GPS and RDNAP, which use different coordinates. The reference point (0,0,0) and the steps (1,0,0 may mean 1 meter north or 1 degree north, etc) differ in these systems. A text description is normally expressed as street address, city, postal code, etc. [Mah04]

GPS coordinates are used in many internationally used applications. It uses the meridians of the earth as steps in the coordinate. RDNAP is used in many Dutch applications. RDNAP measures the coordinates in meters from a certain reference point. The advantage of RDNAP is that 1 step is always one meter, in GPS it is 1 meter at the North Pole, but it is 7 kilometers in the Netherlands.

There are several types of positioning methods. These methods have advantages and disadvantages, such as the accuracy, the price of needed hardware, etc. Because some applications do not need high accuracy and others might be useless if the position isn't accurate enough, the method that should be used for positioning depends on the application (which accuracy is needed) and the situation (which positioning methods are available).

The Global Positioning System (GPS) is probably the currently most used method for positioning. This method uses 24 satellites that are orbiting the earth. But there are other methods that can be used for positioning, such as triangulation using GSM, WIFI access points, Bluetooth beacons or Sensors. [Bor05]

(24)

2.1.1 GPS

The Global Positioning Service (GPS) uses 24 satellites that are in orbit at 10.600 meter above the earth. GPS makes it possible for people with ground receivers to determine their geographic position. GPS determines the current position based on the differences in the travel time of signals from the different satellites.

The satellites are placed in such a way that from any point at the earth there will be at least four satellites above the horizon. Each satellite contains a computer, an atomic clock and a radio. Each satellite continually broadcasts its position and the time. On the earth surface a GPS receiver receives this information and calculates (triangulates) its position (longitude and latitude) based on the information of three satellites. Based on the information of a fourth satellite the altitude can be determined.

GPS can achieve accuracy between 4 and 40 meters. In military approved equipment accuracy can be pinpointed to within one meter. The GPS receiver needs to have a clear view of the sky, so it cannot be used indoors and may suffer from distortion in a city with high buildings. Because

GPS uses satellites the coverage is good, it can be used all over the world. The GPS is owned and controlled by the US Department of Defense, but is available for general use around the world. [Wik05]

2.1.2 GSM triangulation

Another positioning method is positioning using the mobile phone network. The mobile phone network consists of a large number of cells. Each cell has a unique ID, which can be used to identify the Base Transceiver Station (BTS) that the device is communicating with. The coordinates of each BTS are known. When the ID of the BTS the user is communicating with is known, the position of the user is known. The accuracy of the positioning method depends on the size of the cell. In densely populated areas the cells may have a diameter of 300 meters, but in less densely populated areas cells may have diameters up to 20 kilometers.

An other positioning method based on the GSM cells uses the Timing Advance (TA) to estimate the Time of Arrival (TOA = propagation delay). The TA is a quantized measure (a value of 1 = 550 m) of the transit time between the mobile device and the base station. When TAs from at least three base stations have been acquired the position of the mobile device can be determined (triangulated). The accuracy of this method depends on the size of the cells and may differ a lot because cells may be anywhere from 2 to 20 kilometers in diameter. Techniques based on this method can achieve an accuracy of 150 meters or even better.

Figure 2.1: GPS Constellation

(25)

populated areas the coverage is good, but less populated areas may not be covered completely. [Hee02]

2.1.3 WIFI Access Points

GPS offers a good positioning method for outdoors; GSM offers a less accurate method that works outdoors as well as indoors. But there are other technologies that can be used for positioning such as WIFI access points. These technologies can be used in a relatively small area, such as within a building or on a campus.

IEEE 802.11 is the international standard for WIFI (or WLAN) technology. WIFI can be used both indoors and outdoors. WIFI forms cells around the 802.11 access points. Mobile devices can determine their current position based on the ID of the access point they are communicating with. Accuracy depends on the size of the WIFI cells. A WIFI cell can have a diameter up to 100 meters. In for example buildings, where many users use the network, more than one access points are placed, therefore cells may overlap. When a user can detect more than one access point it can calculate its position more accurate by comparing the signal strengths of the different access points. [LaM04]

2.1.4 Bluetooth beacons

Although Bluetooth is designed for wireless communication between devices, it can also be used for positioning in small areas. Bluetooth devices can communicate with other Bluetooth devices that are in a range of 10 to 30 meters. More powerful transmitters have a range up to 100 meters.

Positioning using Bluetooth uses the knowledge of the position of some fixed Bluetooth devices or beacons. When the mobile device detects the fixed devices (of which the position is known) the position of the mobile device can be determined. Because Bluetooth cells are relatively small, the accuracy is rather high (depending on the range of the Bluetooth device).

2.1.5 Sensors

GSM, WIFI and Bluetooth can be used for positioning, but were not developed for this purpose. Several technologies have been especially developed for positioning. Most of these technologies are based on the position of fixed sensors that are located in a building or on a campus. Based on the position of the sensor, the strength of the signals or the round trip times of signals of these sensors the position of a user can be calculated. [Dav02]

The Olivetti Active Badge System or Xerox ParcTab use infrared or radiofrequencies for positioning and have an accuracy of 10 meters. Olivetti and Oracle developed the Bat System, a sensor that uses ultrasonic radio signals, with an accuracy of 15 centimeters.

These sensors are used only indoors. The current position is determined based on the cell in which a user is located. The biggest disadvantage of these sensor systems is that there must be a direct line of sight between the sender and receiver.

(26)

2.2 Positioning Software

In the previous chapter a number of positioning hardware technologies have been described. Applications can be developed to work with these technologies. The JSR179 is a Java location API for J2ME. This API can be used for positioning in Java applications. The JSR179 is independent of the underlying technology. It specifies a LocationProvider, which provides the current position by communicating with the positioning hardware. Place Lab is a library that can be used to determine ones position. This library can calculate the current position based on GPS, GSM, WIFI or Bluetooth (other hardware may be used, but is not supported by default). Place Lab can be used as a standalone application (this way it may act as a LocationProvider for the JSR179). Place Lab can also be used as a building block in other applications, so the positioning is embedded in another application. NetStumbler and WiFiFoFum are tools that allow a user to detect WLAN access points. These tools may be used to detect nearby access points, based on which the position of the user can be determined. [Bor05]

2.2.1 JSR179

The location API for J2ME (JSR179) is an optional package that provides developers with a technology to determine the current position of the device. The JSR179 is an optional J2ME package that can be implemented, however it is not yet supported by most available J2ME distributions.

The JSR179 allows the development of location-based services for mobile (resource-limited) devices. The JSR179 provides mobile services with information about the device’s present position and orientation and supports the creation and use of databases of known landmarks.

JSR179 works with Connected Device Configuration (CDC) or Connected Limited Device Configuration 1.1 and it does not need any particular profile (it can be used with Mobile Information Device Profile (MIDP) or the Personal Profile). The location provider that can be used depends on the available hardware, obviously at least one location provider must be supported. The service selects the most appropriate location provider, based on its needs (accuracy, response time, speed, cost, etc.). The JSR179 does not specify which underlying location providers can be used.

Once the service has selected an appropriate location provider, it can start obtaining the position. The service can invoke the position method once, to get a single position, or it can subscribe to get periodic updates of the position. The location provider returns a position, which contains the coordinates, speed and textual address (if available) and a time stamp that shows when the measurement was taken. [Sun03-1]

2.2.2 Place Lab

Place Lab is a Java library that provides a way of device positioning. Place Lab determines ones position by listening for radio beacons, such as WiFi access points, GSM cell phone towers, fixed Bluetooth beacons or other sensors. These beacons all have a unique or semi-unique id (e.g. their MAC address). When a service detects one or more beacons, the beacons’ position is looked up in a database, based on the position of one or more of beacons the Place Lab software can determine the position of the device. [Pla03], [LaM04]

2.2.2.1 The Place Lab Architecture

(27)

The Spotter in Place Lab works by listening for the transmissions of wireless networking sources like 802.11 access points, fixed Bluetooth devices, GSM cell towers or other sensors. Each radio beacon has a unique or semi-unique id, based on which the position of the device can be determined. The coverage and accuracy of Place Lab is dependent on the number and type of beacons in range of the device. One or more types of radio beacons can be used for determining the position of the device. The Place Lab Mapper contains information on all known beacons. This information is saved in Beacon objects. The information that is saved for a beacon depends on the type of beacon. The coordinates (latitude and longitude) and the address (unique id) are always saved, because Place Lab uses this information to determine the position of a device.

The Place Lab Tracker aggregates measurements from the spotters into an estimate of device position. Measurements of the spotter(s) are fed into the tracker. The Tracker checks if the Mapper has information on the detected beacons to calculate an estimate for the position of the device. To make a good estimate of the position, the Mapper should have accurate information on the beacons.

2.2.2.2 Communication with Place Lab

Place Lab supports six ways of communicating position information to applications:

Direct Linking: Applications may link against the Place Lab Java library and invoke a

single method to start the position tracking service.

Embedding Place Lab: Applications may embed a Spotter, Mapper and Tracker to

make estimates of the device’s position.

Daemon: For lighter-weight interactions, Place Lab can be run in daemon mode and

applications can query Place Lab via loopback HTTP. This HTTP interface allows programs written in most languages and styles to use Place Lab.

Web Proxy: Place Lab supports position-enhanced web services by augmenting

outgoing HTTP requests with extension headers that denote the user's position. By setting their web browser to use the Place Lab daemon's web proxy (in the same way one uses a corporate firewall's proxy), web services that understand our HTTP headers can provide location-based service to the user.

JSR 0179: To support existing Java location-based applications Place Lab supports

the JSR 0179 Java location API.

NMEA 0183: Place Lab provides a virtual serial-port interface that can mimic an

external GPS unit by emitting NMEA 0183 navigation sentences in the same format generated by real GPS hardware.

For the development of services for mobile devices, such as mobile phones or PDAs, the first two ways look most suitable, because the overhead is the least. Testing (on a PDA) proved that embedding Place Lab in the application is the fastest, and most light-weight solution. The results are shown in table 2.3.2.1. Although the result may not be very accurate (because System.currentTimeMillis is not very accurate), it clearly shows that embedding Place Lab in your own code is faster. The processor usage seems the same.

First estimate

(including loading the drivers)

Subsequent estimates

Direct Linking 320 ms 115 ms

Embedding

Place Lab 60 ms 6 ms

(28)

2.2.3 NetStumbler

NetStumbler is a wireless network scanner that allows a user to detect WLAN access points that are nearby using 802.11b, 802.11a and 802.11g standards and show information about these access points such as the MAC address, SSID and signal strength. This tool was intentionally developed for administration tasks, such as verifying network setups, checking coverage of your network and detecting other networks that may interfere with your network.

Although this tool is not intended to be used for positioning, it may be used for this purpose. NetStumbler is a standalone program and has no Java interface, so it is not possible to write a positioning application that can directly query netStumbler to gather data about nearby access points. It is possible to let netStumbler scan on regular basis and save the detected access points to a file. The Java positioning application can read this file and determine ones position based on the information in the file.

Although this may work it does not seem to be a good solution, because a user always needs to run two applications to determine a position. Furthermore the detection of access points by netStumbler is not very fast (more than 0.5 seconds). Furthermore the writing data (detected access points) to a file and reading from it again is unwanted overhead and may be error prone. [Net05]

2.2.4 WiFiFoFum

WiFiFoFum is a wireless network scanner (for 802.11b, 802.11a and 802.11g). This tool can scans for nearby wireless network access points and shows network type (AP or ad hoc), whether a WEP coding solution is present, WiFi channel used for broadcasting, SSID if broadcast, MAC address of the emitting hardware, discovery begin and end times and signal strength.

Like netStumbler, WiFiFoFum has no Java interface, so it is not possible to directly query this tool for detected access points. However the tool is able to temporarily scan and save information about the detected access points to a file. This file may be read by another application that is able to calculate an estimate for the device position. But like the case with netStumbler, this causes unwanted overhead and introduces possibilities for errors. [Wif05]

2.3 Service Discovery

A Service Oriented Architecture (SOA) is an architecture that allows services to be published, invoked and discovered via a network. A SOA makes it possible to offer services to anyone, anywhere over the network.

Most SOA implementations follow in general the same principles (figure 2.2). These architectures consist of a service provider, a service registry and a service user. The service provider is responsible for registering a description of the service to the service registry and hosting the service. The service registry is a repository in which service descriptions are saved and in which services can be discovered by service

Service Registry

Service Provider Service User Register the service Discover the service Bind to the service

(29)

SOA gives a simple way in which businesses can easily register contact information in a registry, publish a service, find a service and invoke the service. The major disadvantage of most current implementations is that existing, static technologies have been used to develop this dynamic architecture. Due to their static nature, systems may fail when the network goes down. This is not acceptable in mission-critical systems. In traditional SOA assumptions are made about the reliability of the network and the static nature of the network. Moreover an administrator is needed to perform maintenance (in case things change in the network or the network goes down). However there are some new SOAs that try to overcome these disadvantages.

2.3.1 Jini

Jini is a de facto standard based on the idea of federating groups of users and the resources required by those users. The focus of the system is to make the network a more dynamic entity that better reflects the dynamic nature of the workgroup by enabling the ability to add and delete services flexibly. Jini tries to address the problems in current SOA implementations, such as assumptions about the network reliability, assumptions about the static nature of a network and the need for administrators to perform several maintenance functions.

Jini services do not need the network to be reliable; Jini services are able to repair themselves without the need for an administrator to fix things. Jini uses the concept of leasing. Leasing means that a service is registered for a certain time, after this time the lease has to be renewed or the service is removed from the registry. Due to the dynamic nature of Jini, a Jini service can handle changes in the network,

there is no need for an administrator to change the URL in software or properties file, the Jini service itself responds to such changes. Communication with Jini services occurs through service proxies that are downloaded when the service is discovered and invoked. Due to this feature the administrator does not need to install code, which is necessary in traditional architectures.

A Jini architecture consists, just like other SOA implementations, of a service provider, a service user and a service registry. The Jini Service discovers the Lookup Service and registers its service with this Lookup Service. A service proxy is uploaded to the Lookup Service. The Lookup Service keeps track of the Jini Services and provides the service proxies to service users. The service user discovers a Lookup Service and requests a certain type of service. If this type of service is registered with the Lookup Service, a service proxy will be returned to the service user. The service user can use this service proxy to invoke the service. The underlying system that is used most of the time to allow service users to communicate with the Jini Service is RMI (Remote Method Invocation). Though other underlying systems may also be used. [Gol02], [Jin05], [New00]

Figure 2.4: The Jini Architecture for Service Discovery The service discovers and registers with the service and uploads the service proxy The client communicates

with the service via the service proxy

The service user discovers the lookup service and finds the service. A proxy object for the service is downloaded Service Registry

(Lookup Service)

(30)

2.3.2 Jini Surrogate Architecture

For a service to join a Jini network (a network of Jini technology-enabled services), it must satisfy several critical requirements: first it must be able to participate in the Jini discovery and join protocols furthermore it must be able to export classes written in Java so that the service is available for downloading by a service user. These requirements are easy to meet for most services, but it may be a problem for some devices with limited computational resources or limited network connectivity.

The Jini Surrogate architecture addresses these problems by defining a means by which these devices, with the aid of a third party, can participate in a Jini network while still maintaining the plug-and-work model of Jini network technology. [Sur05] The Jini surrogate

architecture provides a place (the SurrogateHost) where processing power can be placed for a surrogate that acts on behalf of an attached device. Furthermore the Jini Surrogate

architecture specifies an interconnect, a communication

gateway for the physical and logical

connection between the mobile device and the surrogate. The Jini surrogate architecture allows devices that are not directly connected to a Jini network or are not able to join a Jini network directly, to join a Jini network. A surrogate, written in Java, that is able to access the Jini network and has access to the Jini technology infrastructure, has to be provided for the nomadic service. These surrogates represent the device that is not Jini technology-enabled in the Jini network.

A SurrogateHost is an environment for the hosting of surrogates. Surrogates can be loaded (from a webserver) into a SurrogateHost and executed. SurrogateHosts provide a place where surrogates can participate fully in a Jini network, thereby enabling the device represented by the surrogate to participate fully in a Jini network. SurrogateHosts manage the life cycle of surrogates by loading, starting, stopping, and disposing of surrogates when necessary.

The connection between the nomadic service and the surrogate is implemented by an interconnect protocol. The interface of this protocol is specified by Sun Microsystems. The interconnect protocol functions as a type of middleware layer which can be implemented on top of several forms of communication, such as IP, USB, IEEE1394 and others. [Sun03-2], [Sun01]

Service Registry (Lookup Service) Surrogate Host Service User Service Service

registration discovery Service

Bind to service

Figure 2.5: Jini Surrogate Architecture

Service Surrogate

Host

Intercon-nect

Figure 2.6: The Service provider connected to the surrogate host

(31)

2.3.3 SLP

The Service Location Protocol (SLP) is a de jure standard for service discovery standardized by the IETF. It not restricted to a certain programming language, although APIs are defined for C and Java.

In SLP the Service Provider, Service Registry and Service User are called the Service Agent, Directory Agent and User Agent. User agents search for needed services on behalf of clients. Service agents advertise the availability of services, either directly to user agents or to directory agents, if at least one directory agent is available.

Directory agents serve the same purposes as lookup services in Jini

by cataloging available services, but directory agents store only service contact information, not code. Service location information in SLP is encoded in service URLs, which contain all information necessary for contacting a service. In contrast to Jini, SLP is concerned primarily with putting clients in touch with services. The specific protocols spoken between clients and services are outside the jurisdiction of SLP. [Wik04-1], [Gol02], [Gut99]

The Jini service discovery protocol offers some advantages to java-based clients. The lookup server uses object-oriented matching (by comparing the interface of a class) to find a service that matches the request of the client. SLP and Jini both use attributes to find services that match the client’s requirements, SLP uses strings to describe these attributes, Jini uses Java objects. Furthermore a SLP Directory Agent returns the service URL to the client, while in Jini a proxy to the service is returned. However the advantages that Jini offers, introduce some overhead compared to SLP.

2.3.4 UPnP

Universal Plug and Play (UPnP) is de facto standard for service discovery under development by the Universal Plug and Play Forum, an industry consortium led by Microsoft. UPnP standardizes the protocols spoken between clients and services. Device and service descriptions are coded in XML; and a number of protocols for local auto configuration, discovery, advertisement, client/service interaction and eventing are included in the specification.

Unlike Jini and SLP, UPnP does not support service directories (communication between devices and clients is always direct). A device may contain one or more services. The device itself does nothing more than provide self-describing information such as the manufacturer, model name, and serial number. The services in the device provide the real service. The services broadcast their availability over the network to all control points. Services are described in XML format. Control points can get services information from devices. A control point is a network entity that invokes a device's

User Agent Service Register Service Acknowledgement Directory Agent Service Agent Bind to the service Service Request Service Reply

Figure 2.7: The SLP Architecture

Figure 2.8: UPnP Architecture

Service Controlpoint Broadcast availability Bind to Service Service Device

(32)

functionality, the service user. Control points invoke actions on services, providing any required input parameters and receiving any output parameters and possibly a return value.

UPnP is aimed at smaller environments, such as the home, where the benefits of directories are reduced due to the small number of devices typically found in the network. [Gol02], [Wik04-2]

2.4 Security and Privacy

Most people consider information about their position as private and do not want everyone to be able to see where they are. Therefore security and privacy are important issues in Location-Based Services. Among the most important security and privacy issues are:

• Embarrassment: A user can be embarrassed when another user knows where he has been.

• Target Marketing: The visited positions of a user can be used to classify the user for target marketing

• Service Denial: A user may be denied a certain service because he has visited a certain position.

• Harassment: Position information can be used to find a user and attack him

• Legal Restrictions: In some countries the law protects the privacy of users. In the design and implementation of location-based services security and privacy is very important. There are several solutions to ensure the security and privacy of the user.

First, users should always know when their position is provided and to whom the information is provided. The user should have full control with whom his position is shared and when this position is shared. This can be ensured by implementing a white list or buddy list (a list with allowed users) or a black list (a list with blocked users) in the application that shared position information with other users. Furthermore the user should be able to turn the position information sharing off, whenever he wants. Second, decoupling user information and position information can help to ensure the privacy of the user. When a user is for example visiting a website, that wishes to know the position of the user, the user information should not be coupled with the position information. Legal restrictions can be used to prevent logging of a user’s position. It should not be allowed to store a user’s position for later usage, unless the user has agreed on it.

Third, good security is always important. Information that is shared with other users should be only readable by the intended users. This can be ensured by for example restricted access to the service (authentication required) or by encrypting the data. [Hee02]

2.5 Conclusion

Based on this literature study, combining Place Lab with the Jini Surrogate architecture seems the most ideal combination. Use of a surrogate service seems to solve the challenges of the mobile environment. Furthermore this combination seems to offer a feasible way to design and implement a nomadic positioning service that satisfies the requirements for this service. Alternatives for the Jini Surrogate architecture, such as SLP or UPnP, could have been chosen to deal with the service discovery issue. These techniques however do not deal with the challenges of the

(33)

3

Design of a Nomadic Positioning Service

This chapter gives a design of the nomadic positioning service. Based on experience and the literature study in the previous chapter this design will be based on the combination of the Jini Surrogate architecture and Place Lab. Other architectures, such as SLP or UPnP, could have been chosen to deal with the service discovery issue. These techniques however do not deal with the challenges of the mobile environment. This chapter starts with an introduction on the nomadic positioning service in general. Next the requirements that were set in the first chapter are explained in more detail. The requirements are followed by a high level design that shows the building blocks of which the service is composed. In the following sections this high level design is specified in a top-down approach, by filling the building blocks with specific technologies and implementations.

3.1 Introduction

A nomadic positioning service is a nomadic service that is able to determine its own position and to offer that position to other users. The design that is given in this chapter shows a nomadic service provider that offers a service on a mobile device, which may be offered through a 2,5G, 3G or any other wireless network. This network is connected to the Internet, via which the service user can use the service.

The design that is given in figure 3.1 will be refined in this chapter. This chapter describes the design and implementation of nomadic positioning service, which satisfies the following requirements:

b) Numerical scalability – the bandwidth usage on the wireless link does not increase with the number of parties interested in the location of a mobile device;

c) Plug-and-work – no additional configuration is required for publishing services when new devices come online;

An important issue that the service needs to be able to cope with is the challenges of a mobile environment. Because a nomadic service runs in a mobile environment it has to deal with (or at least take into account) Network Address Translation (NAT), Automatic Private IP Addressing (APIPA), temporary unavailable because of limited network connection, limited processing power and limited battery power.

Service Provider Service User 2,5G or 3G Network Internet Mobile Device Nomadic Positioning Service Fixed or Mobile Device

(34)

To offer position information to service users, the nomadic positioning service provides a technology independent way to determine the position of a mobile device, supporting at least GPS, WiFi, Bluetooth and possibly other technologies for positioning.

3.2 Requirements

The nomadic positioning service must satisfy certain requirements. These requirements define the minimum functionality the prototype needs to satisfy. Based on an evaluation these requirements may be redefined later.

3.2.1 Functionality

The nomadic positioning service must be able to share its position with interested parties. Interested parties can request the last known position of the nomadic service or they can subscribe themselves to regular position updates. The Jini Surrogate Architecture is used to publish the availability of the service and to allow service users to discover the service. To provide this functionality the service m