Nomadic Positioning Services for a Mobile Services Platform

Transcription

1 Nomadic Positioning s for a Mobile 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

2

3 Nomadic Positioning s for a Mobile 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 s of Network Applications Graduation Committee: Dr. ir. A.T. van Halteren Dr. ir. D.A.C. Quartel B.B. Shishkov, Msc.

4 ii Nomadic Positioning s for a Mobile s Platform

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 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. 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 iii

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. iv

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 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 Enschede, 26 th of August 2005 v

8 vi Nomadic Positioning s for a Mobile s Platform

9 Table of Contents ABSTRACT... III PREFACE... V TABLE OF CONTENTS... VII 1 INTRODUCTION THE FREEBAND AWARENESS PROJECT Goal of the AWARENESS project The AWARENESS Infrastructure NOMADIC SERVICES NOMADIC POSITIONING SERVICES COMBINING SERVICE DISCOVERY AND POSITIONING SOFTWARE AS A SOLUTION RESEARCH QUESTIONS APPROACH Background Design and implementation of a Nomadic Positioning Evaluation THESIS STRUCTURE BACKGROUND POSITIONING HARDWARE GPS GSM triangulation WIFI Access Points Bluetooth beacons Sensors POSITIONING SOFTWARE JSR Place Lab NetStumbler WiFiFoFum SERVICE DISCOVERY Jini Jini Surrogate Architecture SLP UPnP SECURITY AND PRIVACY CONCLUSION DESIGN OF A NOMADIC POSITIONING SERVICE INTRODUCTION REQUIREMENTS Functionality Performance Scalability Reliability Manageability Privacy HIGH-LEVEL DESIGN THE MOBILE SERVICES PLATFORM HTTPInterconnect vii

10 3.5 THE POSITIONING SERVICE The Jini service interface MSPLocation THE SERVICE USER VALUE-ADDED SERVICE Requirements High-Level Design Mapper service Changes to the MSPLocation EVALUATION OF THE NOMADIC POSITIONING SERVICE REQUIREMENTS EVALUATION Functionality Performance Scalability Reliability and Manageability Privacy EVALUATION OF THE VALUE-ADDED SERVICE ENCOUNTERED PROBLEMS CONCLUSION CONCLUSIONS AN EFFICIENT AND PRIVACY SENSITIVE WAY TO OFFER POSITION INFORMATION CHALLENGES IN A MOBILE ENVIRONMENT TECHNOLOGY INDEPENDENT POSITIONING CONCLUSION RECOMMENDATIONS FOR FURTHER RESEARCH FURTHER RESEARCH ON THE JINI SURROGATE ARCHITECTURE FURTHER RESEARCH ON PLACE LAB BIBLIOGRAPHY GLOSSARY APPENDICES APPENDIX A: CLASS DIAGRAM MSPLOCATIONSERVICE SERVER APPENDIX B: CLASS DIAGRAM MSPLOCATIONSERVICE SURROGATE APPENDIX C: CLASS DIAGRAM MSPLOCATIONSERVICE CLIENT viii

11 ix

12 x Nomadic Positioning s for a Mobile s Platform

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 s 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: 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, 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. 1

14 To satisfy these requirements the nomadic positioning service can use a service discovery architecture combined with positioning software. 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 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 S. 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] 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 The AWARENESS Infrastructure The AWARENESS network and service architecture consists of three layers (figure 1.1): the Network Infrastructure Layer, the Infrastructure Layer and the Mobile Applications Layer. The Network Infrastructure Layer and the Infrastructure Layer form the real AWARENESS infrastructure. The Mobile Application Layer consists of the (prototype) health applications that are used to validate the infrastructure. 2

15 The network Mobile Application Layer infrastructure provides Context-aware, pro-active context-aware mobility support in a dynamic network environment Infrastructure where unmanaged and Generic service components managed networks coexist. The network Security and identity AWARENESS Context management supports context-aware Infrastructure mobility by taking the Network Infrastructure context of the user into Context-aware mobility support account when controlling the connectivity that is provided to this user, for instance, dynamic Figure 1.1: The AWARENESS Infrastructure 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 proactive 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 s 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. Mobile Device Nomadic 2,5G or 3G Network Fixed or Mobile Device Internet Provider User Figure 1.2: A Nomadic Provider and 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. 3

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 privacysensitive 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. s 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 these services. To make these protocols work in a mobile environment, they need to be able to cope with the challenges of the mobile environment. 4

17 1.3 Nomadic Positioning s 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 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 Mobile Device Nomadic Positioning Positioning Software Positioning Hardware GPS, GSM, WiFi, etc. Figure 1.3: Nomadic Positioning on a Mobile Device 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. 5

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. s 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. Provider Nomadic Registry Internet User Figure 1.4: Discovery Architecture 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. 6

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 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. discovery architectures provide a framework that can be used to advertise services over the network. Research will be done on these service discovery 7

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 Design and implementation of a Nomadic Positioning 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 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. 8

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 valueadded 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. 9

22 10

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] 11

24 2.1.1 GPS The Global Positioning (GPS) uses 24 satellites that are in orbit at 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 Figure 2.1: GPS Constellation 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] 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. Figure 2.2: GSM Triangulation 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. The big advantage of using the GSM network for positioning is that it can be used both indoors and outdoors. Coverage is relatively good, but not as good as GPS. In densely 12

25 populated areas the coverage is good, but less populated areas may not be covered completely. [Hee02] 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 is the international standard for WIFI (or WLAN) technology. WIFI can be used both indoors and outdoors. WIFI forms cells around the 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] 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) 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. 13

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] 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 (resourcelimited) 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] 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] The Place Lab Architecture The Place Lab architecture consists of three key elements: The Spotter (that detects radio beacons in the environment), the Mapper (a database that holds information about beacons positions) and the Tracker (the Place Lab client that uses the Mapper and the data of the Spotter to estimate the current position). 14

27 The Spotter in Place Lab works by listening for the transmissions of wireless networking sources like 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 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 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 Subsequent estimates (including loading the drivers) Direct Linking 320 ms 115 ms Embedding Place Lab 60 ms 6 ms Table 2.1: Place Lab testing results 15

28 2.2.3 NetStumbler NetStumbler is a wireless network scanner that allows a user to detect WLAN access points that are nearby using b, a and g 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] WiFiFoFum WiFiFoFum is a wireless network scanner (for b, a and g). 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 Discovery A 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 users. The service user discovers the service in the service registry and binds to this service. [Dea03] Register the service Provider Registry Bind to the service Discover the service User Figure 2.3: A Oriented Architecture for Discovery 16

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 missioncritical 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 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, The service discovers and registers with the service and uploads the service proxy Registry (Lookup ) The service user discovers the lookup service and finds the service. A proxy object for the service is downloaded Provider User The client communicates with the service via the service proxy Figure 2.4: The Jini Architecture for Discovery 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 discovers the Lookup and registers its service with this Lookup. A service proxy is uploaded to the Lookup. The Lookup keeps track of the Jini s and provides the service proxies to service users. The service user discovers a Lookup and requests a certain type of service. If this type of service is registered with the Lookup, 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 is RMI (Remote Method Invocation). Though other underlying systems may also be used. [Gol02], [Jin05], [New00] 17

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 registration Surrogate Host Registry (Lookup ) Bind to service User Figure 2.5: Jini Surrogate Architecture discovery 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. Interconnect Surrogate Host Figure 2.6: The provider connected to the surrogate host 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] 18

31 2.3.3 SLP The 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 Provider, Registry and User are called the Agent, Directory Agent and User Agent. User agents search for needed services on behalf of clients. agents advertise the availability of services, either directly to user agents or to directory agents, if at least one directory agent is available. Directory Agent Register Acknowledgement Agent Bind to the service Reply Request User Agent Directory agents serve the same Figure 2.7: The SLP Architecture purposes as lookup services in Jini by cataloging available services, but directory agents store only service contact information, not code. 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 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. Controlpoint Broadcast availability Bind to Device Figure 2.8: UPnP Architecture 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 selfdescribing 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. s 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 19

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 s. 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 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 mobile environment. Place Lab supports positioning based on GPS, WIFI, GSM and Bluetooth. This allows the service provider to choose the most suitable, available positioning technology. 20

33 3 Design of a Nomadic Positioning 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. Mobile Device Nomadic Positioning Provider 2,5G or 3G Network Internet Fixed or Mobile Device User Figure 3.1: A Nomadic Provider and User 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: 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; 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. 21

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 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 must implement methods that can be used to access this functionality. An interface for the Jini service has been defined, the Jini service must implement a getlocation() method that returns a Location and setlocationlistener(locationlistener) method, which allows a service user to subscribe to regular position updates. Positions will be stored in RDNAP format, this format is used in Dutch geographic systems. The advantage of RDNAP is that the coordinate is equal to the number of meters east and north from a fixed reference point. Because the available bandwidth often is limited the service must use it in an efficient way. The service should provide a way to optimize the amount of position information that is sent from the nomadic service to the surrogate, because the service provider may need to pay for the data communicated over the wireless network. Some service users may need to know the position exactly and require real-time position information, for other service users one update every minute is good enough. Depending on the requirements of the service user the service needs to be able to optimize the amount of position information that is sent. The nomadic positioning service must offer position information to interested parties. To determine the position of the mobile device the nomadic positioning service must provide a technology independent way to determine that position. The service needs to support at least GPS, WiFi, Bluetooth and possibly other technologies for positioning. Furthermore the challenges of a mobile environment should be taken into account. The service has to deal with Network Address Translation (NAT), Automatic Private IP Addressing (APIPA), temporary unavailable because of limited network connection, limited processing power and limited battery power. The service should run on a mobile device, such as a PDA or a smartphone. If the service does not deal with these issues, the service cannot be used in a mobile environment Performance The nomadic positioning service sends location updates at a regular basis to the subscribed service users. To be useful for service users or other services the determined location should be accurate. The accuracy that is needed depends on what the service is used for. Depending on the needed accuracy, the positioning hardware and the algorithms for calculating the position should be chosen. Some hardware is much more accurate, but is also more expensive compared to others. Refining the algorithm that is used for the calculation of the position may give a more accurate position, however this algorithm may also use more processing power. 22

35 Requests from a service user must be processed and answered within an acceptable time span. The time span that can be considered acceptable depends on the application. If responding to a request takes too long, a time-out must be generated. This prevents too many open connections on the surrogate Scalability The nomadic positioning service should be numerical scalable. The nomadic positioning service can be scalable in two ways. The first type of scalability is the number of service users that can be handled by the nomadic service. The nomadic service needs to be able to handle additional service users without the need for extra resources (processing power and network) from the nomadic service and the wireless network. The surrogate handles the communication with the service users and may be the bottleneck. The surrogate however runs in a fixed network on the SurrogateHost, which has much more resources available than a mobile device. Furthermore the architecture should allow multiple nomadic positioning services to be active at the same time. The SurrogateHost must be able to run the surrogates of these nomadic positioning services. The architecture must allow a service user to connect to all available services. Once set up, it should require minimal (preferably zero) configuration to support additional nomadic services Reliability To be useful the nomadic positioning service must be reliable. If a service user requests a position from a service, the service user should always receive a response. This prevents service users from continuously requesting the position of the service when no response is received. The nomadic service should be able to handle problems, for example when a position cannot be determined due to lack of detected beacons. users should not be able to get references to services that have already been stopped. When a nomadic service stops, wanted or unwanted, all service users should be notified of this, so the current service users will not use the service anymore. The service should also be removed from the Lookup Server, so it cannot be resolved by any new service users. This prevents service users to request services that do not exist anymore Manageability The nomadic positioning service must be easily manageable. Deploying the nomadic positioning service in a mobile environment should need as little configuration and set up as possible. Because nomadic service may appear and disappear in different networks, it should not require additional configuration to support additional nomadic services. It would take too much time if it was necessary to add something to the configuration for every new nomadic service that enters the network Privacy Privacy issues are very important in nomadic and context-aware services. The nomadic positioning service should take care of these privacy issues. People value their privacy that high, that they will not use the service if it does not take care of the privacy issues. The service provider should be able to determine which service users can resolve the position. Not everyone should be able to resolve the position. When the nomadic positioning service is used as a building block of another system, the privacy sensitive information should be separated as much as possible. When the service provider information and the position information are separated, a position is less easily coupled to a certain service provider name. 23

36 3.3 High-Level Design A high-level design of a nomadic service in the Jini Surrogate architecture is presented in figure 3.2. This design consists of a service user, a service registry (the lookup server) and the positioning service. The positioning service is composed of the nomadic positioning service and its surrogate. This design gives a general overview of a nomadic positioning service in the Jini Surrogate architecture. However it can be used for all types of nomadic services. This overview abstracts from implementation issues (except from the usage of Jini and the Jini Surrogate architecture). A nomadic positioning service runs in a mobile environment, such as a 2,5 or 3G network or in any other mobile network environment. The nomadic service implements the real service functionality. Because the nomadic service is running on a mobile device, it may not be able to join a Jini network. The surrogate, which is running in the SurrogateHost, functions as a proxy for the nomadic service. The surrogate allows the nomadic service to join a Jini network. The surrogate offers an interface to the Jini network via which the nomadic service can be reached. The nomadic service and the surrogate are able to communicate with each other, using an interconnect. An interconnect is a communication gateway for the physical and logical connection between the mobile device and the surrogate. This interconnect is implemented by the interconnect protocol. The Mobile s Platform (MSP) offers an implementation of this interconnect protocol. The service users communicate with the service via the Jini network. The service user communicates via the service interface that is implemented by the surrogate object in the SurrogateHost. The communication with the nomadic service happens transparently for the service user. Mobile Device Nomadic Positioning Mobile Device Nomadic Positioning Positioning Jini Server Lookup 2,5 or 3G Network Surrogate Host Surrogate Internet Internet Surrogate User Figure 3.2: Design of a Nomadic Positioning Architecture The Jini Lookup server functions as a service registry, where services can register themselves. A service user can search for a service in the lookup server. This way the Jini Surrogate architecture allows nomadic services to join a Jini network, independent of the fact if the service and the device it runs on satisfy the requirements for a Jini service. The surrogate that runs in the SurrogateHost satisfies these requirements and makes it possible for the nomadic service to join a Jini network. 24

37 3.4 The Mobile s Platform The surrogate service of the nomadic service runs in the SurrogateHost. Madison is an implementation of the SurrogateHost designed and implemented by Sun. Madison offers an interface that must be implemented by the interconnect protocol. This implementation is independent of the used networking technology (figure 3.3). The Mobile s Platform (MSP) offers an implementation of the interconnect protocol that is used in the Jini Surrogate architecture. This interconnect protocol is used for the communication between the nomadic service and its surrogate. Nomadic SurrogateHost Surrogate Interconnect Figure 3.3: The positioning service On execution, the nomadic service connects to the SurrogateHost via the interconnect and requests the activation of the surrogate of the nomadic service. The surrogate of the service is loaded from a webserver, activated and executed in the SurrogateHost. Once executed, the surrogate can access the Jini Lookup server and register itself as a Jini service. Once running the nomadic service should send keep-alive messages regularly, to notify the interconnect that it is still alive. This behavior was specified by the Jini Surrogate architecture specification, independent of the used protocols (figure 3.4). Nomadic Interconnect SurrogateHost Surrogate Surrogate activation Activate surrogate request Activation performed, returns a connection to the surrogate Activate surrogate request Surrogate retrieval, activation and execution Load and start surrogate Activation of the surrogate Sending keep alive Keep-alive request Keeping surrogate alive Keep-alive response Figure 3.4: Surrogate loading, activation and execution When the nomadic positioning service has been started and the surrogate is active, they can start sending requests to each other. When the nomadic positioning service sends a request to the surrogate, for example a location update, the request is first sent to the interconnect. The interconnect forwards the request to the correct surrogate. The response to the request is sent back to the service via the interconnect. When the surrogate wants to send a request to the nomadic positioning service, the surrogate sends the request to the interconnect. The interconnect forwards it to the correct service and the response is received via the interconnect again. The interconnect sends the response to the surrogate (figure 3.5). 25

38 Nomadic Interconnect SurrogateHost Surrogate Nomadic service sends a request to the surrogate Send service request Send service request Process request Process response Process request Send response to the service request Send surrogate request Send response to the service request Send surrogate request Surrogate sends a request to the nomadic service. This request may be triggered by a request from a service user Send response to surrogate request Send response to surrogate request Process response Figure 3.5: Sending requests between the nomadic service and the surrogate When the nomadic service stops the surrogate needs to be stopped also. This can be done in two ways. When the nomadic service is stopped, a deactivation request is sent to the surrogate. This stops the surrogate and disposes the objects associated with the deactivated surrogate (figure 3.6). When the nomadic service stops running as a result of an error or a network disconnect, the service cannot send a deactivation request to the surrogate. The surrogate will be deactivated and disposed when the keep-alive messages fail to arrive within a certain keep-alive period. This guarantees that the surrogate is always deactivated when the nomadic service stops running. Nomadic Interconnect Surrogate Host Surrogate Surrogate deactivation Deactivate surrogate request Deactivate and Dispose surrogate Deactivation of the surrogate Figure 3.6: Surrogate deactivation HTTPInterconnect The MSP offers an interconnect implementation on top of HTTP. Part of the development has been done as a part of this Masters assignment. HTTPInterconnect implements the Jini Surrogate architecture specification [Sun03-2] and uses HTTP as communication technology. HTTPInterconnect allows any device that is capable of handling the HTTP protocol, to join a Jini network. This seems a promising approach, because more and more mobile devices are capable of handling this protocol. HTTP offers features that are useful to the surrogate architecture. [Pec95] HTTP has a good and uniform addressing scheme. The developer does not have to worry about addressing issues. The HTTP protocol is based on a request/response paradigm. This allows problems with NAT to be handled. Routers forward response messages to the correct address. The response messages can be used to deliver data to a service that is behind NAT. Custom HTTP header fields allow one to send all kinds of data in HTTP headers. 26

39 Complete freedom to transmit data of any format because HTTP offers an extensible and open representation for data types HTTP is accepted by most firewalls, this allows for easy exchange of messages between the nomadic service and the surrogate. In the HTTPInterconnect protocol messages are sent between the nomadic service and the SurrogateHost in the body of HTTP messages (in the HTTP request as well as in the HTTP response). The nomadic service sends HTTP requests on a regular basis, it puts the messages for the surrogate in the HTTP request body. The SurrogateHost reads the messages from the HTTP request and forwards them to the surrogate. The surrogate processes the message and sends a response back to the SurrogateHost. The SurrogateHost puts these messages in the body of the HTTP response and sends it back to the service. The surrogate cannot send a message to the nomadic service directly. Because mobile devices often are behind a NAT router, they don t have a private IP address that can be reached from the Internet. In HTTPInterconnect these messages need to be wrapped in the body of a HTTP response. The nomadic service sends HTTP requests (keep-alive request or other messages) on a regular basis, responses to these requests can be used to send messages back to the nomadic service (figure 3.7) Using HTTP as a carrier for the messages between the nomadic service and the surrogate, allows devices that are behind a NAT router to also join the Jini network. HTTP requests sent by the nomadic service are sent via the NAT router. The NAT router receives the response and sends it back to the nomadic service. Furthermore the HTTP protocol is allowed to be sent via most routers, other protocols may be blocked by a router of a firewall. This makes it possible to use the HTTPInterconnect implementation of the Jini Surrogate architecture in almost every environment. Nomadic Interconnect SurrogateHost Surrogate Nomadic service sends a request to the surrogate Process response Process request Send service request message Send response to the service request Send keep-alive or other request Send response to keep-alive or request and surrogate request message Send response to surrogate request Send response Send service request message Send response to the service request message Send surrogate request message Send response to surrogate request message Process message Surrogate sends a request to the nomadic service. This request may be triggered by a request from a service user Process response Figure 3.7: Sending messages in HTTPInterconnect 27

40 HTTPInterconnect is a Java implementation of the Jini Surrogate architecture specification based on HTTP as communication technology. This implementation consists of three parts: Messages, IO and Interconnect (figure 3.8). SurrogateHost Nomadic Surrogate IO HTTP Interconnect Interconnect Messages HTTP Figure 3.8: The HTTPInterconnect Messages The messages package (nl.utwente.msp.messages) contains the messages that can be sent between the nomadic service and the surrogate, via the interconnect protocol. Furthermore this package contains functionality for encoding and decoding of data that can be sent in these messages. There are three types of messages: RequestMessage, ReplyMessage and OnewayMessage, which all extend Message. The RequestMessage is a message that contains a request. A RequestMessage may be initiated by the service as well as by the surrogate. A RequestMessage is always followed by a ReplyMessage. A ReplyMessage contains the response to a RequestMessage. An OnewayMessage is a message that does not require a response. An OnewayMessage may be sent by both the service and the surrogate. OnewayMessages were added to the architecture for efficiency issues. A RequestMessage needs to be followed by a ReplyMessage. Before the ReplyMessage can be sent, the RequestMessage needs to be processed (in order to send some relevant data back). Processing of such messages takes time, which may vary from several milliseconds up to several seconds depending on the method that needs to be executed. In some cases it is not necessary to send data back to the sender. For example when the nomadic positioning service sends position updates to the surrogate, the surrogate does not need to send anything back to the service. In these cases the OnewayMessage is useful. All types of messages have the same structure. The message starts with a serviceid, followed by an operationid and a sequenceid. The serviceid is the id of the service that sent the message (or the id of the service the message is destined for, when sending from the surrogate to the service), the operationid is a unique id that is given to the operation of the service or the surrogate. Each operation the service wants to offer to the surrogate and each operation the surrogate offers to the service, needs to have a unique id, so each message can trigger a certain operation. The sequenceid identifies the order of the messages. 28

41 Id OperationId SequenceId Body Figure 3.9: The structure of a message The body of a message contains operation specific data. A nomadic positioning service may, for example, send regular position updates to the surrogate. The body of these update messages can contain the new position of the device. These messages are sent between the nomadic service and the surrogate in the body of HTTP messages (in the HTTP request as well as in the HTTP response). When the nomadic service sends HTTP request on a regular basis, the nomadic service can put the messages for the surrogate in the HTTP request body. The surrogate than can put its messages in the body of the HTTP response, that needs to be sent back to the service IO The IO package (nl.utwente.msp.io) contains the part of the HTTPInterconnect implementation that is used at the nomadic service side. This package handles all the messages sent to and from the nomadic service. The IO package is composed of several parts. The most important parts are the SurrogateHostHTTPConnection, the SurrogateConnection and the DeviceHTTPConnection (figure 3.10). Nomadic Surrogate HostHTTP Connection Surrogate Connection Surrogate Connection DeviceHTTPConnection HTTPClient When a nomadic service is started and there are no other nomadic services running, there is no context for the device in the Figure 3.10: The IO package SurrogateHost. The nomadic service sends a registration request to the SurrogateHostHTTPConnection. This class represents the connection to the SurrogateHostContext (HTTPcontext in the SurrogateHost where the surrogate of a nomadic service can be registered). The SurrogateHostHTTPConnection sends a device activation request to the SurrogateHost, which triggers the SurrogateHost to create a DeviceContext for this device. If there are no other nomadic services running there is no DeviceHTTPConnection for the device. The DeviceHTTPConnection represents a connection to the DeviceHTTPcontext in the SurrogateHost specific for the device. Surrogates for service on this device can be accessed via this context. The SurrogateHostHTTPConnection initiates a new DeviceHTTPConnection. Each device can have only one DeviceHTTPConnection. Next the DeviceHTTPConnection sends a surrogate activation request to the DeviceContext. If the activation request succeeds the DeviceHTTPConnection returns a SurrogateConnection to the nomadic service. This SurrogateConnection represents a connection to the surrogate in the SurrogateHost. It allows the nomadic service to send messages to its surrogate. If the nomadic service sends messages via the SurrogateConnection, the SurrogateConnection hands these messages over to the DeviceHTTPConnection. The DeviceHTTPConnection contains a MessageWorker thread and a Worker thread. IO 29

42 The MessageWorker creates a HTTP request, puts messages from the service in the body of the HTTP request and sends it to the HTTPClient. Next it receives the HTTP response from the HTTPClient and reads the messages from it. The Worker thread handles these received messages and sends them to the correct nomadic service (figure 3.11). RegisterSurrogate (Device) SurrogateHost HTTPConnection DeviceHTTP Connection executemethod(headmethod) to test the surrogatehostconnection HTTP response HTTPClient HttpClient sends HTTP Head to SurrogateHost and receives response return SurrogateConnection() executemethod(postmethod) device activation request to create devicecontext on the surrogatehost HTTP response Initiate DeviceHTTPConnection (deviceurl) registersurrogate (Device) return SurrogateConnection() Create ActivateMessage and write it to outgoingmessagequeue, MessageWorker creates HTTP Post method executemethod (PostMethod) HTTP response Read and process messages in HTTP response. Create SurrogateConnection HttpClient sends HTTP Post to SurrogateHost and receives response (with deviceurl) HttpClient sends request to SurrogateHost and receives response Figure 3.11: Activation -side When the surrogate has been activated in the SurrogateHost, the nomadic service needs to send keep-alive messages to notify the SurrogateHost that it is still alive. A task for sending these messages to the surrogate is scheduled by the DeviceHTTPConnection (figure 3.12). SurrogateHost DeviceHTTP HTTPClient HTTPConnection Connection Start a keep-alive task that sends keep-alive messages to the surrogate Host executemethod (PostMethod) HTTP response HttpClient sends keep-alive to SurrogateHost and receives response Figure 3.12: Sending keep-alive messages to the SurrogateHost The nomadic service can use the SurrogateConnection to send messages to the surrogate. The nomadic service can send RequestMessages that are followed by a ReplyMessage or it can send an OnewayMessages. These types of messages are used 30

43 depending on the method that is invoked in the surrogate. A number of messages for the same DeviceContext may be combined in one HTTP request. The DeviceHTTPConnection receives the reply for these messages (in the case of RequestMessages) and determines the corresponding nomadic service for the message. Allowing the sending of more than one message in a HTTP request makes the HTTPInterconnect a lot faster (figure 3.13). InvokeRequest (RequestMessage) InvokeRequest (OnewayMessage) Surrogate Connection invokerequest (ReplyBucket, RequestMessage) invokemessage (OnewayMessage) DeviceHTTP Connection HTTPClient InvokeRequest (RequestMessage) invokerequmest (ReplyBucket, RequestMessage) ExecuteMethod (PostMethod) HttpClient sends HTTP Request to the surrogate ReplyMessage ReplyMessage HTTP response ReplyMessage ReplyMessage Figure 3.13: Sending messages to the surrogate HTTP messages received by the HTTP Client are sent to the MessageWorker (in the DeviceHTTPConnection), the MessageWorker gets the messages from the HTTP response. Next the Worker (in the DeviceHTTPConnection) handles these messages and sends them to the correct service. The received message can be a ReplyMessage, if so, it is forwarded to the waiting service as a reply on the outstanding RequestMessage. The message can also be an OnewayMessage or a RequestMessage. This message is sent to the correct service and in the case of a RequestMessage, the service sends back a ReplyMessage (figure 3.14). Surrogate DeviceHTTP HTTPClient Connection Connection ServeMessage(OnewayMessage) HTTP response HttpClient receives a HTTP response ServeRequest(RequestMessage) ReplyMessage ExecuteMethod (PostMethod) Figure 3.14: Receiving messages from the surrogate RequestMessages, ReplyMessages and OnewayMessages can be combined in one HTTP request. The HTTP server in the SurrogateHost receives this HTTP request and gets all messages from the request. The interconnect reads the messages and sends it to the correct surrogate. When the service is stopped, the SurrogateHost needs to be notified so it stops the surrogate. The service requests deregistersurrogate from the SurrogateHost- 31

44 HTTPConnection. The SurrogateHostHTTPConnection forwards this request to the DeviceHTTPConnection. The DeviceHTTPConnection creates a deregister message and sends it to the SurrogateHost via the HTTPClient. The surrogate is deactivated and a reply is sent back to the DeviceHTTPConnection. The DeviceHTTPConnection removes the corresponding SurrogateConnection. If the surrogate was the last for this device, the DeviceHTTPConnection is also closed (figure 3.15). SurrogateHost HTTPConnection DeviceHTTP Connection HTTPClient deregistersurrogate (surrogateconnection) deregistersurrogate (surrogateconnection) Remove Surrogate- Connection and if the last surrogate also the DeviceHTTPConnection invokerequest (RequestMessage) ReplyMessage HTTPClient sends messages to the surrogate in a HTTP request removedevicehttp Connection Close DeviceHTTP Connection Figure 3.15: Deregister at the nomadic service Interconnect The interconnect package (nl.utwente.msp.interconnect) contains the part of the HTTPInterconnect implementation that is used in the SurrogateHost. This package handles the activation and deactivation of surrogates and all the messages sent to and from the surrogate. Interconnect Surrogate InterConnectSession The SurrogateHost is composed of several parts. The HTTP Server receives HTTP-packages from the nomadic service. On start up the HTTPAdapter initiates the context /SurrogateHost/ and a SurrogateHostContextHandler is set to handle requests on this context. The SurrogateHostContextHandler is able to handle HTTP HEAD messages (for connection testing) and HTTP POST message (activation requests). SurrogateHost ContextHandler HTTP Server Device Context Handler Figure 3.16: The Interconnect package When the SurrogateHostContextHandler receives a HTTP HEAD message, it directly sends back a reply, to indicate that there is a connection. When the SurrogateHostContextHandler receives a POST message it extracts the messages from the HTTP message and handles the activation request that was sent by the nomadic service. The SurrogateHostContextHandler checks if the mobile device already has a context. If there is no context for the mobile device, the SurrogateHostContextHandler requests 32

45 the HTTPAdapter to create a context for the device in the HTTPServer. The HTTPAdapter creates a DeviceContextHandler and a context /devices/devicename for the device. HTTP requests that are sent to /devices/devicename are handled by the new DeviceContextHandler. The DeviceContextHandler extracts the messages from the HTTP request and sends these messages to the correct surrogates (figure 3.17). HTTPServer receives HTTP Head request on /surrogateh ost/ HTTPServer addcontext(context) HTTPAdapter Impl HTTPAdapterImpl creates a HTTPContext for /surrogatehost/ and adds a new Surrogate- HostContextHandler as handler to this context handle(pathincontext, pathparams, HttpRequest, HttpResponse) SurrogateHost ContextHandler DeviceContext Handler HTTPServer receives HTTP Post request on /surrogateh ost/ Create httpcontext /devices/de vicename if not there handle(pathincontext, pathparams, HttpRequest, HttpResponse) getcontext (/devices/devicename) Return response adddevicecontexthandler (devicename) return DeviceContextHandler for device devicename Read message from HttpRequest and handle requestmessage Return response with the devicecontexturl /devices/devicename Figure 3.17: Activation surrogate-side To notify the surrogate that it is still alive, the nomadic service sends keep-alive messages on regular basis. These messages are wrapped in the body of a HTTP request and sent to the context of the mobile device. The HTTP server forwards HTTP messages to the DeviceContextHandler that corresponds with the context. The DeviceContextHandler subtracts the keep-alive message from the HTTP message and sends the message to the DeviceContextServant. The DeviceContextServant is the part of the DeviceContextHandler that performs the message handling for the DeviceContext. The DeviceContextServant handles messages for registering and deregistering surrogates and keeping the surrogates for this device alive (figure 3.18). HTTPServer HTTPAdapter Impl SurrogateHost ContextHandler DeviceContext Handler HTTPServer receives HTTP Post with keepalive on /devices/de vicename/ handle(pathincontext, pathparams, HttpRequest, HttpResponse) Return response Read message from HttpRequest and serverequest (request- Message) Figure 3.18: Handling a keep-alive message surrogate-side 33

46 Once the DeviceContext for the device is ready and the surrogate is running the HTTP server can receive messages for the surrogate. When the HTTP server receives an HTTP request on the DeviceContext for the device, the DeviceContextHandler reads the messages from the HTTP request. Three types of messages can be handled by the DeviceContextHandler, the RequestMessage, the ReplyMessage and the OnewayMessage. The RequestMessage, may contain requests for the DeviceContext (management request) itself or for one of the surrogates running on this context. A request for the DeviceContext can be a registersurrogate request, a deregisterrequest or a Keep-alive message. If the RequestMessage contains one of these messages, it is forwarded to the DeviceContextServant (which is part of the DeviceContextHandler) The DeviceContextServant serves messages for the DeviceContext. If the message is a RequestMessage, a ReplyMessage or a OnewayMessage for one of the surrogates, the MessageWorker thread (which is part of the DeviceContextHandler) reads the message and forwards it to the correct surrogate. If the message is a RequestMessage, a ReplyMessage is returned. The DeviceContextHandler puts the messages in the body of the HTTP response and the HTTPServer sends the message back tot the mobile device (figure 3.19). HTTPServer DeviceContext Handler DeviceContext Servant MessageWorker HTTPServer receives HTTP Post with message on /devices/de vicename/ handle(pathincontext, pathparams, Read messages from HttpRequest servemanagementreq uest(requestmessage) Return response serveregularmessage(onewaymessage) serveregularrequest(requestmessage) Messages are send to the correct surrogate Return response HTTPServer sends HTTP response Return response Figure 3.19: Receiving messages surrogate-side When the HTTPServer receives a HTTP request, this request is forwarded to the DeviceContextHandler. All messages in this request are handled. Next the DeviceContextHandler puts the replies to RequestMessages and all other outstanding messages for this device in the body of the HTTP response that needs to be sent back to the mobile device. The surrogate and the DeviceContextHandler share an InterconnectSession. Via this session the surrogate can send RequestMessages and OnewayMessages to the DeviceContextHandler (figure 3.20). 34

47 HTTPServer DeviceContext Handler Interconnect Session HTTPServer receives HTTP Post with message on /devices/de vicename/ HTTPServer sends HTTP response handle(pathincontext, pathparams, Return response Read messages from HttpRequest invokerequest (RequestMessage) invokemessage (OnewayMessage) Figure 3.20: Sending messages surrogate-side Stopping the nomadic service triggers the surrogate to shutdown also. The HTTPServer receives a HTTP request with messages. The DeviceContextHandler reads the messages and the DeviceContextServant handles them. The InterconnectSession that existed between the DeviceContextHandler and the surrogate is removed and the InterconnectSession is terminated. This causes the keep-alive timer task to stop and to deactivate the surrogate (figure 3.21). HTTPServer DeviceContext Handler DeviceContext Servant Interconnect Sesion HTTPServer receives HTTP Post with deregister message on /devices/de vicename/ handle(pathincontext, pathparams, Read messages from HttpRequest serverequest(request Message) removeinterconnect Session(serviceId) HTTPServer sends HTTP response Return (empty) ReplyMessage Terminate() Keep-alive task is stopped and the surrogate is deactivated 3.5 The Positioning Figure 3.21: Deactivation of the surrogate A complete service in the Jini Surrogate architecture consists of the nomadic service on the mobile device, the surrogate of this nomadic service and an interconnect. The positioning service is the complete service. This service is able to determine its own position and to provide it to service users via the Jini network. The nomadic service runs on a mobile device. The nomadic service is connected to a surrogate via the interconnect. The surrogate is able to access the Jini network and has access to the Jini technology infrastructure The Jini service interface The positioning service is a Jini service and can join a Jini network. The surrogate implements the Jini functionality in the service. On execution, both the nomadic service and the surrogate are started (this process will be explained in more detail later in this chapter). If the lookup server is known, a service register request can be sent directly. If the service does not know the lookup server, it needs to discover a 35

48 lookup server, before it can register. The surrogate locates a lookup service by multicasting a request on the local network for any lookup services to identify themselves. When the surrogate registers itself as a Jini service at the lookup server, a stub (reference to the surrogate) is uploaded to the lookup server. This service object contains interface for the service, including the methods that users and applications will invoke to execute the service along with any other descriptive attributes. When the server is registered with the Jini lookup service it receives a lease. Periodically, the service needs to renew this lease. If the service fails to renew the lease, then when the lease expires, the lookup service will remove the entry for it, and the service will no longer be available (figure 3.22). This is according to the Jini Specification. [Sun03-3] Discovery of a lookup server Register Jini Lease received, keep on renewing Multicast discovery request Lookup Server Discovered register request registered Lease renewal Lease renewed Lookup Server Figure 3.22: registration Notify service of lookup server Store service Proxy and service attributes Update lease When the service is registered with the lookup server, a service user can make use of this service. First the service user needs to resolve the lookup server. Next the service user can request the availability of the service from the lookup server. A client searches through the lookup server for an appropriate service by defining an interface or attributes. If the requested service is registered with the lookup server the service user receives the service object of the Jini service. This service object allows the service user to communicate with the Jini service (figure 3.23). The Jini (surrogate) handles the communication with the real service when necessary. 36

49 Lookup Server User Multicast discovery request Discovery of a lookup server Notify service user of lookup server Lookup Server Discovered Search for a service that matches the request Discovery Found Request a service method request Invoke a service method reply Figure 3.23: discovery by a service user MSPLocation The MSPLocation is a nomadic positioning service on top of the Jini Surrogate Architecture implementation (MSP). It consists of a nomadic service and the surrogate of the nomadic service. The nomadic service implements the real positioning functionality. The surrogate implements a Jini service that allows service users to connect to the nomadic service. The Place Lab libraries and some extensions to this library are used to determine the estimate position. A WiFiSpotter needs to be implemented in the nomadic service, to spot WiFi beacons. The calculation of an estimate position can be performed solely in the nomadic service or it can be distributed between the nomadic service and the surrogate. The surrogate runs on a server that has more processing power than the mobile device and that does not have to cope with limited battery power. Running the Place Lab Mapper and Tracker in the surrogate would relieve the nomadic service from the calculation of the estimate location. The beacon information of the detected beacons can be sent to the surrogate and the Tracker and Mapper in the surrogate can calculate the estimate. However the beacon information of the detected beacons may contain privacy sensitive information. When all beacon information is sent to the surrogate, it is possible to determine where a user is, based on beacon names (for example inside the cinema, because beacons with the cinema-name are detected). Sending this privacy sensitive information should be prevented. When the nomadic service calculates the estimate, only the latitude and longitude are sent to the surrogate. Sending only the latitude and longitude to the surrogate also lowers the amount of data sent between the nomadic service and the surrogate. When the nomadic service is connected to the surrogate via 2.5 or 3G networks, one has to pay for the data that is sent, so sending less data saves money. 37

50 Based on the above arguments the nomadic service will contain all Place Lab logic. It is however relatively easy to design and implement the Tracker and the Mapper logic in the surrogate. Place Lab allows serializing the object with data collected by the Spotter, this object can be sent to the surrogate for further processing. Nomadic Positioning Nomadic Place Lab Jini Surrogate Surrogate HTTPInterconnect Figure 3.24: The nomadic service and its surrogate with HTTPInterconnect Nomadic The nomadic service implements the positioning functionality of the service. Place Lab is used to determine the position of the nomadic service. A SurrogateHostHTTPConnection and a SurrogateConnection (from the IO package) are used to communicate with the SurrogateHost and the surrogate. Provider GUI Location Server & Server Location Provider Nomadic Place Lab The nomadic service consists of a LocationServer, a LocationProvider, the Place Lab Surrogate Surrogate libraries and a graphical user HostHTTP Connection interface (GUI). The Connection LocationServer extends the Server. The Server contains all functionality that is specific to the Figure 3.25: Composition of the nomadic Jini Surrogate architecture, the service LocationServer contains functionality that is needed for positioning and the communication with the GUI. Separating the general logic and the positioning service logic in the Server and the LocationServer allows reuse of the Server in other applications. The LocationServer and the Server handle all messages that are received from and sent to the SurrogateHost and the surrogate. The GUI is used to handle input from and output to the service provider (user of the mobile device). To determine the location of the nomadic service the LocationProvider handles communication with Place Lab. Place Lab consists of a Spotter (for spotting beacons), a Mapper (database with beacon information) and a Tracker (for calculating the estimate position). The nomadic positioning service uses a WiFiSpotter to spot WiFi beacons (access points). A (newly developed) FileMapper is used to read beacon information from a file that contains the position (latitude and longitude) of the beacons in the comma separated values (CVS) 38

51 format. A WiFiTracker has been implemented to determine the estimate position of the nomadic service. This tracker uses a very simple algorithm that calculates an estimate position based on the weighed average of the detected beacons (the three beacons with the strongest signal). When the nomadic service is started by the service provider (owner of the mobile device) a new LocationServerServant (inner class in the LocationServer) is initiated. This servant handles all incoming messages from the SurrogateConnection. The LocationServer sends a registerservant request to the Server. The Server sends a registerdevice to the SurrogateHostHTTPConnection, this request contains the URL where the surrogate code can be downloaded and the name of the Device. The SurrogateHostHTTPConnection sends the registration request to the SurrogateHost and returns a SurrogateConnection. The SurrogateConnection represents a connection to the registered surrogate. The Server sets the LocationServerServant as the Servant for the SurrogateConnection (figure 3.26). GUI provider wants to register the surrogate createnewservant (servantname) LocationServer registerservant (Servant) surrogateconnection. setservant(servant) Server registerdevice (surrogateurl, devicename) Return SurrogateConnection SurrogateHost HTTPConnection Surrogate registered is Confirm registration Return SurrogateConnection Figure 3.26: Registration of the Surrogate When the nomadic service and the surrogate are running, the position of the mobile device can be determined. Determining the position can be triggered by the service provider (owner of the mobile device) or by a request from the surrogate. If the service provider wants to send an estimate position once, or wants to send regular position updates to the surrogate, OnewayMessages are sent to the surrogate. If the surrogate requests an estimate position a RequestMessage is sent to the nomadic service, the position is determined and the estimate is sent back to the surrogate in a ReplyMessage. Requests to determine an estimate position, both from the service provider (via the GUI) and from the surrogate (via the DeviceHTTPConnection) are called on the LocationServer. The LocationServer sends a scan request to the LocationProvider. The LocationProvider receives a BeaconMeasurement from the WiFiSpotter, which contains beacon information of all detected beacons. The BeaconMeasurement is sent to the Tracker. The Tracker calculates an estimate position and sends this back to the LocationProvider. The LocationProvider can repeat this process one or more times to get a better, more accurate estimate. Finally the estimate position is sent back to the LocationServer (figure 3.27). 39

52 LocationServer An estimate position needs to be determined scan() LocationProvider getmeasurement() Return BeaconMeasurement WiFiSpotter Start scanning for beacons updateestimate(beaconmeasurement) Tracker Estimate position determined Return position estimate estimateupdated(tracker, Estimate, Measurement) Calculate estimate position Figure 3.27: Retrieving an estimate position from Place Lab When the service provider wants to stop the nomadic service, the surrogate also needs to be deregistered. The service provider sends a deregistercurrentservant to deregister the servant that is selected at that moment. The LocationServer first sends a management message to al clients to notify them that the service is going to be deregistered. Next the surrogate needs to deregister the Jini service from the lookup server. Finally the surrogate can be deregistered and the servant that was connected to the surrogate via the SurrogateConnection is stopped (figure 3.28). GUI provider wants to deregister the surrogate deregistercurre ntservant () LocationServer sendmanagementme ssagetosh(string) deregisterwithlookupi nsh (SurrogateConn) deregisterservant (SurrogateConn) Server invokemessage (OnewayMessage) invokemessage (OnewayMessage) Surrogate Connection deregistersurrogate (SurrogateConnection) SurrogateHost HTTPConnection Figure 3.28: Deregister the nomadic service Surrogate The surrogate of the nomadic service is the part of the service that runs in a fixed network. The surrogate offers on one side an interface to the nomadic service, via the HTTPInterconnect. On another side it offers an interface to the Jini network, by offering a Jini service. JiniLocation Location Surrogate The surrogate consists of two parts, the Location and the JiniLocation. The Location contains all surrogate functionality. This part communicates with the nomadic service via the HTTPInterconnect. Interconnect Session DeviceContextHandler Figure 3.29: Composition of the surrogate 40

53 It handles the sending and receiving of messages and performs the actions that need to be taken as a result of these messages. The JiniLocation is a Jini service that is offered via a Jini network. This service is registered with a lookup service and can be discovered by service users. The JiniLocation offers an interface to the service users to use the nomadic positioning service. When a register request message is received by the DeviceContextHandler, a registersurrogate request is sent to the AdapterContext. The AdapterContext is part of the Madison implementation of Sun. Madison handles all surrogate functionality that is independent of the used networking technology. Input parameters with this registersurrogate request are, an InputStream of the URL where the surrogate code can be downloaded, the size of the jar file, the InterconnectSession between the surrogate and the DeviceContextHandler and a list of Permissions. The AdapterContext trigger the activate(hostcontext, InterconnectSession) method of the surrogate (Location). The Location starts an internal LocationServant that handles all incoming messages. A JiniLocation is sent to the LocationServant as a parameter. The LocationServant registers the JiniLocation with a lookup service. Next the LocationServant is set as the servant for the InterconnectSession that was received with the activate() request. A SurrogateLivenessManager that makes sure the surrogate is kept alive as long as necessary, is registered with the InterconnectSession as a KeepAliveHandler and as a LivenessHandler (figure 3.30). Register Request Message received Return Reply Messag e with service Id DeviceContext Handler registersurrogate (surrogateurl, int, Interconnect Session, Permissions[]) Adapter Context InterConnect Session activate(hostcontext, InterconnectSession) Location SetServant(Servant) SetKeepAliveHandler() SetLivenessHandler() JiniLocation Start JiniLocation and register it with a lookup service Figure 3.30: Register the surrogate and the Jini service When the surrogate is activated and the Jini service is registered, the service is ready to send and receive messages. These messages can come from the nomadic service or from the Jini service user. The nomadic service can send RequestMessages, ReplyMessages or OnewayMessages. These messages can contain activation requests, deactivation requests, location updates, etc. Jini service users can use the methods that are defined in the JiniLocationInterface and are implemented by the JiniLocation, to send requests to the service. Messages from the nomadic service are handled by the DeviceContextServant (innerclass) in the DeviceContextHandler. If the message is a RequestMessage, the serverequest method in the corresponding servant, in this case the LocationServant is called. This method returns a ReplyMessage with reply information, which is sent back to the nomadic service. A ReplyMessage contains reply information for an outstanding request. This message is returned to the outstanding caller. If the message is an OnewayMessage, the void method servemessage in the servant is called (figure 3.31). 41

54 DeviceContext Handler Oneway Message is received with location update Interconnect Session servemessage(onewaymessage Location Handle message, read location information from it setlocation(location) JiniLocation Figure 3.31: Location update message from the nomadic service The Jini service implements two methods, getlocation() and setlocationlistener(locationlistener), that can be called by a Jini service user. The getlocation method returns a Location object that contains information about the latest known position of the nomadic service (figure 3.32). DeviceContext Handler Interconnect Session Location getlocation() JiniLocation getlocation() invokerequest (RequestMessage) Return ReplyMessage invokerequest (RequestMessage) Return ReplyMessage Return Location Return Location Figure 3.32: getlocation invocation on the Jini service The setlocationlistener method registers a LocationListener, which wishes to receive regular location updates. The final interfaces for the Jini service have been defined in the positioning package (figure 3.33). DeviceContext Handler Oneway Message is received with location update Interconnect Session servemessage(onewaymessage) Location JiniLocation setlocation(location) firelocationevent(location) setlocationlistenr (LocationListener) save Listener in Jini service LocationEvent is send to all registered Figure 3.33: setlocationlistener and send a LocationEvent to the listener For sending asynchronous position updates, the Jini remote event model needs to be used. The service user can register itself as a listener. Every time the position is updated an event is sent to the service user. The Jini remote event model allows listeners to receive RemoteEvents. users that want to listen for remote events need to implement net.jini.core.event.remoteeventlistener interface, which includes a single void method notify(remoteevent). The MSPLocation calls the notify(locationevent) method in the client when the position is updated. The LocationEvent extends RemoteEvent. 42

55 3.6 The User The service user in the Jini Surrogate architecture is a normal Jini client application. This client application discovers one or more Jini lookup services and queries the lookup service for services that match a certain template. This template may contain a Java interface the service must implement or a number of attributes the service must match. The Jini architecture offers a DiscoveryManager, which listens for services in the discovered lookup services that match the template. When the lookup service knows services that match these criteria or when new services that match the criteria are added, the DiscoveryManager is notified. The DiscoveryManager notifies the client application. The service user can choose which service it wants to connect to and whose service it wants to use. The service user cannot see whether a service is a surrogate or a real Jini service. The MSPLocationClient is a Jini client that can connect to the MSPLocation. On start up the MSPLocationClient resolves a Jini lookup service and queries it for services that match the JiniLocationInterface, which is implemented by the JiniLocation in the surrogate. If one or more of these services are registered with the lookup service the client gets a stub of these services and can call its methods. The MSPLocationClient can request the position of a nomadic service via the getlocation method or it can subscribe to regular position updates via the setlocationlistener method. The getlocation method returns a Location object instantly. The setlocationlisterner registers the client as a listener, which is notified when the location is updated in the service (figure 3.34). Resolve one or more Jini lookup services and create a Discovery Manager Client Discovery Manager createlookupcache () Listen for DiscoveryEvents FoundEvent JiniLocation _Stub setlocationlistener() LocationEvent LocationEvent When the service gets a new position a LocationEvent is send to all clients. LocationEvent Figure 3.34: Discovering the service and register as listener 3.7 Value-added service The nomadic positioning service offers the basic positioning functionality. A service user can discover the service and request the last known location or can subscribe to regular location updates. The nomadic positioning service however can also be used as a building block for other services. A value-added service is a service that enhances the basic functionality of the nomadic positioning service. This service shows how the nomadic positioning service can be used as a building block in other services. 43

56 An example of such a valueadded service is a Mapper service. A Mapper service is a Jini service that has a database with beacon information. This service can implement the Place Lab Mapper interface. This way one or more Mappers can be distributed through the network. Place Lab applications can use this Mapper service to retrieve beacon information, but also to add information about new Mapper Provider Internet Nomadic Positioning User beacons. The Figure 3.35: The Mapper service MSPLocation can use this Jini Mapper service to retrieve information about unknown beacons that are detected. When the beacon is unknown to the Mapper service, the MSPLocation can determine an estimate for the new beacon and add this information to the Mapper service. The MSPLocation is a Jini client of the Mapper service, but remains a Jini service to the other service users (that are using the MSPLocationClient) Requirements The Mapper 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 Functionality The Mapper service has a database with beacon information that can be shared with Place Lab applications. The service must offer a way to provide this information to its service users. The service can offer beacon information on a specific beacon or it can offer beacon information about all known beacons on a specific position. Furthermore the service must offer a way to add beacon information about newly discovered beacons. The Place Lab Mapper offers an interface for this functionality, the findbeacon(string Id), query(coordinate c1, Coordinate c2) and putbeacon(beacon beacon) methods have to be implemented. The Mapper service must be able to join a Jini network. The service needs functionality to discover and lookup a Jini lookup service and to register itself with it Performance The Mapper service gets requests for beacon information from service users. These requests must be processed and answered within an acceptable time span. This is a Jini (RMI) call, so normally it takes only a view milliseconds. The number of beacons the Mapper service stores information about may grow very large. The service must store the beacon information in such a way, it can read beacon information and write new beacon information without any delay. The beacon information that is sent to the service users should be accurate. A mechanism needs to be thought of that can be used to determine the accuracy of the beacon information. Beacon information that is stored in the Mapper service can be gained in two ways. Position information about beacons that are installed somewhere in a building or on a campus can be determined relatively accurate. Position information about beacons that is estimated is less accurate. 44

57 Scalability The Mapper service should be scalable. The service should be able to handle an acceptable number of service users without the need to add resources. For this prototype up to fifty service users is acceptable. For real-world application this number may be different. The Mapper service is a stand-alone Jini service so it needs to handle all service users itself. Fast handling of requests lowers the number of waiting service users and therefore the number of open connections. Furthermore the architecture should allow multiple Mapper services to be active at the same time. users can connect to one or more Mapper services to get accurate beacon information Reliability The must service must be reliable. If a service user requests information from the service, the service user should always receive an answer. The service should be able to handle problems, for example when no information can be found in the database. The beacon information the Mapper service returns to the service user, must be reliable. However it may not be always possible to resolve the exact position of a beacon. Some beacons are located with GPS accuracy, other beacons are scanned and the position is estimated based on the position of other known beacons. The handle this issue, an accuracy value may be added to the beacon information, so the service user can decide whether to use the information or not. When to Mapper service stops, wanted or unwanted, all service users should be notified of this. This prevents service users to request services that do not exist anymore. The service should also be removed from the Lookup Server Manageability The nomadic positioning service must be easily manageable. Deploying the nomadic positioning service in a mobile environment should need as little configuration and set up as possible. The Mapper service only needs to know the position of the database and possibly the address of a Jini Lookup service (if the address is not known it can be resolved using a multicast discover message). Furthermore starting the service should trigger all necessary tasks to be performed, such as connecting to the database, registering in the lookup server, etc. Stopping the service should deactivate these tasks High-Level Design Figure 3.36 shows a high-level design of the Jini Mapper service as a value added service with the nomadic positioning service. The Mapper service contains a database in which beacon information can be stored. The MSPLocation may use this service to retrieve beacon information about unknown beacons. The design that was presented in chapter three described the MSPLocation. This design contained a Mapper that was used to store information about beacons. The Mapper service can be used to extend or to replace the Mapper in the MSPLocation. 45

58 MSPLocation Mapper Jini Lookup Server Internet The Mapper service is a Jini service and the MSPLocation is a Jini service user (in this example, but other Place Lab applications may also use the Mapper service). The Jini lookup server that is used by the Mapper service can be the same lookup server as the one used by the MSPLocation, but it can be just as easy another one. The service user is the user of the MSPLocation. DataBase User Figure 3.36: High level design of the Jini Mapper service This design gives a general overview of the Mapper service as a value added service for the MSPLocation. This overview abstracts from implementation issues (except from the usage of Jini) Mapper service The Mapper service implements part of the Place Lab Mapper interface. The Mapper service consists of the Mapper, the JiniMapper and a database in which the beacon information can be saved. The Mapper contains the Mapper functionality and functionality to communicate with the database. The JiniMapper is the Jini service that is offered through the Jini network. When the Mapper service is started, a lookup service is resolved and the Jini Mapper service is registered with this lookup service. Once registered the Mapper service can be discovered by the service users, in this case the MSPLocation. The service user gets a proxy object that has a reference to a Mapper service and uses this proxy to call the methods of this service. JiniMapper Mapper Mapper Database The Jini Mapper service implements several methods of the Place Lab Mapper interface. The method findbeacon(string id) returns a Beacon that matches the id Figure 3.37: The Mapper service parameter, findbeacons(string id) returns a Vector with all Beacons that match the id parameter, query(coordinate c1, Coordinate c2) returns a Vector with all Beacons in the area delimited by Coordinate c1 (left-top corner) and Coordinate c2 (right-bottom corner). The putbeacon(string id, Beacon beacon) method allows a service user to add new Beacons to the Mapper service. 46

59 When the JiniMapper- receives a method call from a service user that wishes to receive beacon information about one or more Beacons, the JiniMapper calls the corresponding method in the JiniMapper findbeacon (String id) Return Beacon a findbeacon(string id) Return a Beacon Mapper Database SELECT * FROM mapperdb WHERE ID=ID Return beacon information of a Beacons with the given id Mapper. The Figure 3.38: Processing of findbeacon(string id) Mapper executes the method, gets the needed information from the database and creates a Beacon with the information. Next it returns the Beacon (or a Vector of Beacons) to the JiniMapper. The JiniMapper returns it to the service user. JiniMapper putbeacon (String id, Beacon beacon) Return beacon added new putbeacon(string Beacon beacon) Return New Beacon added Mapper id, Database INSERT INTO mapperdb VALUES (id, beacon) Figure 3.39: Processing of putbeacon(string id, Beacon beacon) When the JiniMapper receives a putbeacon() call, the Mapper is requested to put this beacon in the database. A Beacon check has to be performed, to check if the beacon is valid and not already in the database. Next a message is sent to the service user that the beacon has been added to the database successfully Changes to the MSPLocation The MSPLocation that was introduced in chapter three cannot instantly use the Mapper service. Because the Place Lab Mapper and Tracker are located in the nomadic service, they cannot act as a Jini client (for the same reasons as why it could not act as a Jini service). A surrogate is needed to communicate with the Mapper service. The nomadic positioning service needs to start a second surrogate that functions as Jini client and that connects to one or more Mapper services. The Jini client functionality could be placed in the same surrogate, but this would make the surrogate more complicated. By separating the functionality into two surrogates the different responsibilities are clearly divided (3.40). The Mapper service can be used to extend or to replace the Mapper in the MSPLocation. When the Mapper service is used as an extension of the local Mapper, a caching mechanism can be used for efficiency. Beacon information that has been downloaded once, can be stored in the local Mapper (in a local database or text file). When unknown beacons are detected, the MSPLocation can query the Mapper service for information about these beacons. When the beacon is known to the local Mapper, it is not necessary to query the Mapper service. When the Mapper service is used as a replacement of the local Mapper, caching is also possible. When information has been requested for a certain beacon it can be stored in memory, so it is still known a second time it is detected. 47

60 MSPLocation Nomadic Positioning SurrogateHost MSPLocation Surrogate MapperClient Surrogate Jini Server Lookup Internet Mapper DataBase User Figure 3.40: Changes to the MSPLocation The Mapper in the nomadic positioning service needs to be able to connect to the MapperClient surrogate in the SurrogateHost. Requests on the mapper to find or put Beacons are transparently forwarded to the surrogate. The surrogate calls the find or put methods in the Mapper service and sends the reply back to the Mapper. The nomadic positioning service does not notice that its calls to the Mapper are forwarded to the surrogate and to the Jini service (figure 3.41). Tracker queries the mapper for beacon information Tracker receives beacon information Mapper findbeacon (String id) Return Beacon MapperClient Surrogate findbeacon (String id) Return Beacon JiniMapper findbeacon (String id) Return Beacon Figure 3.41: Receiving a request in the Mapper service Mapper 48

61 4 Evaluation of the Nomadic Positioning The design of the nomadic positioning service shows that Place Lab and the Jini Surrogate architecture can be combined to develop a nomadic positioning service. In this chapter the implementation is used to evaluate the design of the nomadic positioning service. The implementation is used to validate whether the requirements that were set in chapter three, have been met. Furthermore this evaluation shows whether the statement that combining these technologies is a feasible approach to realize a nomadic positioning service. Before the nomadic positioning service could be implemented, some further development on the Jini Surrogate architecture had to be done. The most important issue that had to be resolved was allowing two-way communication. The architecture allowed messages to be sent from the nomadic service to the surrogate, but not from the surrogate to the nomadic service. Some performance issues concerning the Jini Surrogate architecture have also been taken into account. These issues were not needed to be solved per se, but they allowed for more efficient and faster communication between the nomadic service and the surrogate, which was needed to satisfy the requirements of the service. 4.1 Requirements evaluation In the previous chapter a number of requirements were set. These requirements define the minimum functionality the prototype of the nomadic positioning service needs to satisfy Functionality The nomadic positioning service provides position information to interested parties via the Jini Surrogate architecture. This architecture offers an efficient way to provide this information. The nomadic positioning service must satisfy a number of functional requirements. The nomadic service must use available bandwidth efficiently. The amount of information that is sent between the mobile device and the surrogate can be optimized or tuned to the capacity and cost of the available wireless network. The nomadic service can adapt the amount of position information that is sent to the surrogate, depending on the requirements of the interested parties. Storing position information in the surrogate makes the nomadic positioning service numerical scalable. The amount of resources needed in the mobile device and the bandwidth usage on the wireless link and does not increase with the number of parties interested in the location of a mobile device. The Jini Surrogate architecture takes care of the issues that may be encountered in a mobile environment. The HTTPInterconnect protocol allows mobile devices that are behind a NAT router or have a private IP (APIPA) to run a nomadic service. By using the HTTP request/response paradigm, messages can be sent between the nomadic service and the surrogate and vice versa. Moreover when more parties are interested in the nomadic service, the surrogate decreases the amount of resources of the mobile device. The amount of resources (processing power, battery power and network) that is available on a mobile device is limited. Place Lab is used to determine the position of the mobile device. Place Lab offers a technology independent way to determine the position, supporting at least GPS, WiFi, Bluetooth and possibly other technologies for positioning. Place Lab calculates the position on the device. This allows minimization of the amount of privacy sensitive information over the network. 49

62 A simple client has been implemented to test the functionality of the functionality of the nomadic positioning service. This client is able to request the current position of the nomadic positioning service or to subscribe to periodic position updates. The MSPLocationClient is able to draw the position of one or more services on a map Performance The Place Lab Tracker is able to calculate an estimate position of the mobile device. The accuracy depends on the used positioning hardware and the Tracker implementation. The Tracker in the nomadic positioning service uses a centroid algorithm that uses the weighed average of the signal strength of detected WiFi beacons. Two tests have been performed to determine the accuracy. Figure 4.1 shows the fourth floor of the Zilverling building. Both tests have been performed on this floor. The floor contains four WiFi access points, which are placed in a straight line. All coordinates are measured in the RDNAP coordinate system. The RDNAP system is the most used system in Dutch cartography. RDNAP represents the number of meters from a certain reference point (0, 0) Coordinate in RDNAP Access Point 1 X X Test Position Access Point 2 X Test Position 2 X Access Point 3 X Test Position 3 X X Access Point Coordinate in RDNAP Figure 4.1: Overview of the building with access points (4 th floor of Zilverling) The first test compares the estimated position with the real position when the nomadic service remains in one place based on one or more known beacons. This test shows the estimates of the nomadic positioning service on three test positions. The test has been performed five times, with one known beacon, with two known beacons, with three known beacons, with four known beacons and with all beacons (20 beacons) in the building known. The first test shows that the nomadic positioning service is able to determine an estimate position based on WiFi, while not moving. It must be noted that the signal strengths (on which the estimate is partly based) vary quite a lot on the mobile device. This is caused by interference. Smaller devices such as ipaqs suffer more from this interference than laptops. By estimating several times and calculating the 50

63 average, a better estimate can be determined. The results of the first test are shown in the tables below. Real position Estimates Position of known beacons Average Estimate Average Deviation , Null , Null null , , , , meters , , , , , , , , , , , , meters Table 4.1: The estimate position based on one known access point When only one of the detected beacons is known, the nomadic service can be anywhere within the range of that access point. The accuracy of the service depends on the range of the access point and can vary from 0 up to 100 meters. When the nomadic service is out of the range of any known access point, no position can be determined. Real position Estimates Position of known beacons , , , , , , , , , , , , , , , , , , , , , , , , Average Estimate Average Deviation , meters , meters , meters Table 4.2: The estimate position based on two known access points When two of the detected access points are known, the position can be determined more accurate. When both known access points are detected the estimate position lies somewhere in the middle of both access points. When only one of the known access points is detected, the estimate position will be equal to the position of the detected access point. With two known access points, the position can be determined a bit more accurate. The accuracy still depends on the range of the access point and will be somewhere between 0 and 50 meters when both access points are detected and up to 100 meters when only one known access point is detected. 51

64 Real position Estimates Position of known beacons , , , , , , , , , , , , , , , , , , , , , , , , , , , Average Estimate Average Deviation , meters , meters , meters Table 4.3: The estimate position based on three known access points When three of the detected access points are known, the accuracy becomes better. The estimate position still lies somewhere between the positions of the detected access points. When the nomadic service is between these access points, the accuracy will be between 0 and 25 meters and up to 100 meters when less access points are detected. Real position Estimates Position of known beacons , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Average Estimate Average Deviation , meters , meters , meters Table 4.4 The estimate position based on four known access points Real position Estimates Position of known beacons , , , , , , , , , , , , , , , , , , Average Estimate Average Deviation more , meters more , meters more , meters Table 4.5 The estimate position with all access points in the building known 52

65 When four or more access points are known, the accuracy becomes even better. The results for the last test are shown in figure 4.2. When the nomadic service is between the known access points an accuracy of 0 up to 25 meters can be measured. In this test the access points were in a line on every floor of the building. Therefore the estimates lie somewhere on this line. When the access points are in triangles or in squares, the accuracy can be determined even better E2 E1 E1 E1 X1 E1 E1 E2 E2 E3 X X = Test position E = Estimate position E3 E3 E2 E3 E2 X3 E Figure 4.2: Estimates with all available access points The second test compares the estimated position with the real position while the nomadic service is moving. This test shows that the nomadic positioning service is able to determine an estimate with an average accuracy of 20 meters. Real position Estimates Average Deviation , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters , , meters Table 4.6: Positioning with the Nomadic Positioning while walking 53

66 The fact that all access points used in these tests lie on a straight line, makes the estimate less accurate. The positions of the known access points can be seen as a grid. Although the nomadic positioning service may be outside the grid of known access points, the estimate will always lie somewhere within the grid. So when the grid is a line, the estimate will lie somewhere on this line. Nothing can be done to avoid this. Estimating the position within a grid of access points is relative accurate, but can be improved by improving the algorithm that is used for determining the estimate. Whether this is necessary depends on the service. The more complicated an algorithm becomes the more resources of the mobile device it will need. The time the used algorithm needs can be ignored compared to the time the scanning takes. The time it takes to handle requests in the SurrogateHost is the time it takes to send a request to the surrogate, the time it takes to process the request and the time it takes to send the response. The time it takes to handle a request in the nomadic service depends on the keep-alive time. When a number of messages in the surrogate has to be sent to the nomadic service, the surrogate has to wait for a HTTP request (keepalive message or other message) to send the outstanding messages in the body of the HTTP response. When the keep-alive time is set to one minute, it may take up to one minute before the message can be sent to the nomadic service. The time it takes to send a request to the SurrogateHost and to send a request back to the service user is only a few milliseconds, so these times can be neglected. The time it takes to handle a request in the SurrogateHost is: TotalTime = ProcessingTime The time it takes to handle a request in the nomadic service can be defined by: TotalTime = (1-α)KeepAliveTime + ProcessingTime 0 < α < Scalability Using the Jini Surrogate architecture allows the nomadic service to handle a large number of service users. The number of service users is limited by the capacity (speed, processing power and network connection) of the SurrogateHost. The surrogate runs in a fixed network and is able to handle a larger number of service users than the nomadic service would be able to handle alone. The nomadic service would not be able to handle these users without the surrogate. By using the surrogate to store position information and to handle the requests of the service users, the nomadic service is able to handle additional service users without the need for extra resources (processing power and network). The bottleneck for the surrogate is the eventing system. users can register themselves as listeners. Every time the position is updated in the surrogate, an event is sent to each listener via RMI. Each RMI call may take a few milliseconds. When too many users are registered as listeners, it may be possible that the surrogate has not sent all events, before the next position update is received from the mobile device. This results in an infinite queue with events that have to be send. [SDN05] The Jini Surrogate architecture allows multiple nomadic services to run at the same time. Each nomadic service has its own surrogate in the SurrogateHost. When many surrogates are running in the SurrogateHost, it may be necessary to add a second SurrogateHost to the system. The Interconnect protocol will need extra functionality for load-balancing between the two SurrogateHosts. The Jini architecture allows the service user to discover one or more available services and to connect to them. Once setup, it requires no configuration to support additional nomadic services. 54

67 4.1.4 Reliability and Manageability The Jini architecture also handles the reliability and manageability of the service. The release of Jini is a stable release, so it can be expected that it is reliable. Jini handles the communication between the service and the service user (using RMI). The communication between the nomadic service and the surrogate is managed by HTTPInterconnect. HTTPInterconnect is still in development, so it may be less reliable. If the service disappears or stops then architecture deregisters the service from the lookup service and notifies the services that are listening for this service. When the nomadic services is stopped the surrogate is deactivated, however when the nomadic service is disconnected, because of network failure, the SurrogateHost detects this when a certain number of keep-alive messages have not been received. So this may take a while (depending on the keep-alive period). The surrogate handles temporary unavailability of the nomadic service Privacy The nomadic positioning service takes some of the privacy issues into account. By calculating the position on the device a minimal amount of privacy sensitive information is sent over the network. The service is not yet able to do the authentication of service users. For the prototype this issue is not very important, because authentication can be added to the service relatively easy when the service is used in a real application. 4.2 Evaluation of the value-added service The design of the value-added service shows how the MSPLocation can be used as a building block for another service. The Mapper service is a value-added service based on the MSPLocation. The Mapper service enhances the basic service that is offered by the MSPLocation, by offering up-to-date beacon information Functionality The Mapper service contains a database with beacon information. The service allows service users, such as the MSPLocation, to retrieve information about detected beacons, furthermore it allows them to share beacon information on new beacons. The Mapper service can be offered in a Jini network. The service contains functionality to discover a lookup service and to register itself with this service. The Mapper service implements some of the methods of the Place Lab Mapper. The findbeacon(string Id) and query(coordinate c1, Coordinate c2) methods can be used to retrieve information about one or more beacons from the database. The putbeacon(beacon beacon) method can be used to add beacon information to the database. The findbeacons(string Id) method that is defined in the Mapper interface (and was described in the design) cannot be implemented in the Mapper, because the LinkedList this method returns is not serializable. Therefore the LinkedList cannot be sent via Jini (RMI) from the Mapper to the MapperClient. It is possible to wrap the info that was intended to be sent in the LinkedList in another way. However because findbeacons method is not used by the MapperClient, it is not implemented Performance Because the Mapper service is a stand-alone Jini service (not a surrogate) a request can be sent directly to the Mapper. The Mapper processes the request and sends a response back to the service user. Simple database requests (SELECT and INSERT) can be handled fast enough. Even if the database grows large, requests are handled fast, so they will not become the bottleneck. users will not notice that they have to wait for requesting information in the Mapper. 55

68 This service makes it possible to construct a large database with beacon information. The information in the database may be corrupted by incorrect or imprecise estimates or service users who deliberately insert wrong information. This can never be completely prevented. Checking whether the beacon information seems valid (by comparing it to known data), may prevent entering some bogus information into the Mapper service. Furthermore an accuracy value can be added to the beacon information. The accuracy value can be partly based on the service user. Information from known and trusted users can be rated higher than information from unknown users. The accuracy value can also be based on whether the information is based on an estimate or a real position and the technique that was used to determine the estimate position (WiFi, GSM, Bluetooth). Adding an accuracy value to each beacon in the database allows the service user to determine whether it wishes to use the information or not Scalability The Jini architecture allows the Mapper service to be shared with the service users. Jini allows multiple service users to discover and use the Mapper service. Because the Mapper service handles a request relatively fast, the number of waiting service users (users with an outstanding request) remains low. In general, requests can be handled in less then 2 milliseconds. With 500 service requests per second the number of waiting service users is one or less on average. The Jini architecture allows multiple Mapper services to be registered at the same time. The lookup service handles the registration of the services and the discovery requests from the service users. The Jini architecture is able to handle a large number of Jini services at the same time. The Jini architecture does not specify a maximum number of services that can be registered at the same time Reliability and Manageability The Mapper service is reliable. Jini (and RMI) handles the remote communication and makes sure that each request gets a response (when needed). When no information is available about a beacon that was detected by a service user, the service returns a null value, so the service user knows this beacon is not known in the Mapper service. The accuracy of the beacon information is hard to guarantee, because service users may enter incorrect or imprecise information into the database. Adding an accuracy value to the beacon information allows the service user to determine whether it wishes to use the information or not. Management of the service can be handled by the Jini architecture. Starting the service triggers all necessary tasks. The service is registered with a Jini lookup service. When the service is stopped the Jini lookup service is notified. All service listeners get a notification that the service has been stopped. 4.3 Encountered problems The implementation of the MSPLocation shows that Place Lab and the Jini Surrogate architecture allow the development of nomadic positioning services. However some issues and problems were encountered. Some of these problems were caused by limitations of the Jini Surrogate architecture, these problems could be solved by adding functionality. Other problems were caused by the usage of Place Lab and the used positioning hardware. Some of these problems may be solved by further research. Others cannot be solved due to the limitations of the used technology. Before the Jini Surrogate architecture could be used for nomadic positioning services, some work had to be done on this architecture. Madison, implemented by Sun, offers 56

69 a network independent implementation of the SurrogateHost and the Interconnect protocol. A HTTP specific implementation of the interconnect protocol, the HTTPInterconnect, has been designed and implemented in the AWARENESS project. However a number of issues on this implementation still had to be solved, before it could be used for development of a nomadic positioning service. The HTTPInterconnect only allowed messages to be sent from the nomadic service to the surrogate. To allow the surrogate to send messages to the nomadic service, some functionality had to be added to both the IO and the Interconnect packages. These messages can be sent in the body of the HTTP requests. To increase performance, OnewayMessages have been added to the architecture. These messages do not need a ReplyMessage to be returned to the sender. This allows much faster sending of these messages. OnewayMessages can for example be used for position updates from the nomadic service to the surrogate. The surrogate does not need to reply to these messages. Another performance boost was combining several messages in one HTTP request. Sending an HTTP request and waiting for the reply takes some time. When two or more messages are combined in one HTTP request, more messages can be sent in the same amount of time. Some research has been done on the optimal size of the used buffers, to allow larger amounts of data to be sent at once. The optimal size is as small as possible without forming a bottleneck for the application. The optimal size obviously depends on the device the service runs on, because the faster the device is, the faster reading and writing from and to the buffers can be done. For an Ipaq 4 kilobyte is enough, on a laptop buffers of 32 or 64 kilobytes are better. A stable release of Place Lab is available. However there are still a number of problems with this release. An important issue with Place Lab, due to the usage of NDIS drivers, is that Place Lab can only scan when the device is not connected to a WiFi access point. These drivers can only scan for access points or be connected to one. This causes a network connection to break when Place Lab starts scanning for WiFi beacons. When Place Lab scanning is stopped it takes several seconds to restore the network connection (depending on the type of network authentication). Alternatives that may solve this problem have been examined. All applications that allow for WiFi scanning use the NDIS drivers, so the connection is always broken. Another solution is not to use WiFi to connect to the Internet but another networking technology. Using Bluetooth or GPRS for the Internet connection solves these issues. The disadvantage of Bluetooth is that it has a small connection range. GPRS is a better solution for the Internet connection. It is available on most locations and is not very expensive. However the service provider needs a mobile device that supports WiFi for scanning and GPRS for the Internet connection. Another solution is setting the keepalive time longer, this gives the mobile device more time to recover the Internet connection, but replying to a RequestMessage takes longer. Which solution is the most ideal, depends on the application. When fast response is required GPRS or Bluetooth should be used, when e.g. one update per minute is enough, WiFi satisfies. Another important issue is that Place Lab is not compatible with all mobile devices. Only a limited number of ipaqs and mobile phones are supported. This is caused by the fact that a piece of native code is used to send requests to the hardware. When a position needs to be determined based on WiFi, calls have to be made to the WiFi adapter. The WiFi adapters are different in different mobile devices. The stable release of Place Lab runs with the NDIS drivers on several Ipaqs, such as the 1940, the 5450 and the 5550, but may not work on others. This issue is known by the Place Lab development group and a solution is being developed. Place Lab works with most WiFi network adapters (NDIS drivers) in laptops. However Place Lab requires the Windows Zero Configuration feature to be turned of. This feature is preferably turned on when roaming through a mobile environment. A new driver is under development to solve these issues. 57

70 4.4 Conclusion The evaluation shows that combining Place Lab and the Jini Surrogate architecture allows for the development of a nomadic positioning service that satisfies the requirements that were set in the third chapter. However some problems have been encountered in the design and implementation of the service. Further research may be needed to solve these problems. The evaluation of the value-added service shows that it is possible to design and implement value-added services on top of the nomadic positioning service. The Mapper service is a Jini service that uses the Jini network to enhance the nomadic positioning service with mapping functionality. 58

71 5 Conclusions There is an increasing number of mobile devices that is equipped with wireless networking capabilities, such as WLAN, GPRS, UMTS, Bluetooth, etc. These different types of networks enable the devices to communicate with each other and therefore make them aware of their context. When a device is aware of other devices around it, it can react to these devices or even cooperate with them. This makes a new type of context-aware network and service infrastructure possible. These trends allow for a new way of service provisioning, called nomadic service provisioning. Within the Freeband AWARENESS project a Mobile s Platform (MSP) has been developed. The MSP is a software infrastructure, based on the Jini Surrogate architecture, that aims to simplify the development of nomadic services. This thesis researched whether this MSP can be used to develop a nomadic positioning service. The main research question that needed to be answered in this Masters Thesis 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? This thesis described the design and implementation of a nomadic positioning service based on the Jini Surrogate architecture and Place Lab. This service must provide an efficient and privacy sensitive way to make positioning information of mobile devices available to interested parties, while keeping the challenges of a mobile environment in mind. To offer position information to service users, the nomadic positioning service provides a technology independent way to determine the position of a mobile device, based on GPS, WiFi, Bluetooth and possibly other technologies for positioning. 5.1 An efficient and privacy sensitive way to offer position information The first sub-question was: 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. Combining the Place Lab positioning technology with the Jini Surrogate architecture allows the development of nomadic positioning services. Both the Place Lab technology and the MSP implementation of the Jini Surrogate architecture are still under development, therefore these technologies had to be examined closely before they could be combined into a nomadic positioning service and could be used for a value-added service. After adding some functionality to the Mobile s Platform this implementation allowed the design and implementation of a nomadic positioning service. This nomadic service is based on the combination of Place Lab and Jini and the Jini Surrogate architecture and provides an efficient way to make position information available to interested parties. This architecture allows optimization of the amount of data sent over the wireless network by combining messages that need to be sent to the nomadic service. Furthermore some requests can be handled by the surrogate so it is not necessary to send data to the nomadic service. Usage of the surrogate makes it 59

72 possible to add service users, without the need for extra resources from the mobile device and the wireless network. By using service discovery protocols, adding additional nomadic services, needs no extra configuration. Once set up, services can register and deregister whenever they like, without the need for configuration. The service discovery protocols handle the registration of the service in the Jini network and the advertising of this service. Place Lab minimizes the amount of privacy sensitive information that needs to be sent over the network, by calculating the estimate on the device. Only the calculated position is sent to the service user (via the surrogate). This also minimizes the total amount of data that needs to be sent from the nomadic service to the surrogate. The nomadic service can be triggered to send position information on regular basis. This allows optimization of the amount of position information that is sent over the wireless network. 5.2 Challenges in a Mobile Environment The second sub-question was: 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? The Jini Surrogate architecture allows a nomadic service that does not satisfy the requirements for a Jini service to join a Jini network. The surrogate of the nomadic service does satisfy these requirements and therefore can join a Jini network. The surrogate handles communication with the nomadic service. The nomadic positioning service runs in a mobile environment. Running services in a mobile environment causes some challenge, such as Network Address Translation (NAT), Automatic Private IP Addressing (APIPA), temporary unavailable because of limited network connection, limited processing power and limited battery power. Some of these problems are solved by the Jini Surrogate architecture. NAT and APIPA make it difficult to send messages to a service on a mobile device directly. The mobile device however can send messages (in the body of a HTTP request) to a host (SurrogateHost) in a fixed network. Sending messages for the nomadic service in the body of the HTTP response allows the surrogate to communicate with the nomadic service. The surrogate runs in a SurrogateHost in a fixed network. This makes the surrogate always available. The surrogate handles the connection with the nomadic service. This makes temporary network disconnects from the nomadic service no problem. Requests from the service users are handled in the surrogate, if necessary the surrogate connects to the nomadic service. This construction solves the challenge of temporary unavailability of the nomadic service due to limited network connections. The challenges of limited processing power and limited battery power are partly solved by the Jini Surrogate architecture. Part of the processing can be done in the surrogate, this makes the nomadic service more light-weight which saves battery and processing power. The tasks that can be performed by the surrogate should be determined while taking privacy aspects into account. Privacy is an important issue in the development of nomadic services. 60

73 5.3 Technology independent positioning The third sub-question was: 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? An important issue with Place Lab is that is not compatible with all mobile devices. This is caused by the fact that a piece of native code is used to send requests to the hardware. When a position needs to be determined based on WiFi, calls have to be made to the WiFi adapter. The WiFi adapters are different in different mobile devices. The stable release of Place Lab runs with the NDIS drivers on several Ipaqs, such as the 1940, the 5450 and the 5550, but may not work on others. Place Lab works with most WiFi network adapters (NDIS drivers) in laptops. However Place Lab requires the Windows Zero Configuration feature to be turned of, this feature is preferably turned on when roaming through a mobile environment. A new driver is under development to solve these issues. Place Lab offers functionality to determine the position of a mobile device, based on several technologies. Place Lab offers by default support for GPS, WiFi, Bluetooth and GSM. But other technologies can easily be added. 5.4 Conclusion The main research question that needed to be answered in this Masters Thesis 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? The combination of the Jini Surrogate architecture and Place Lab allow for the development of a nomadic positioning service that satisfies the requirements that were set in the third chapter. The Jini Surrogate architecture allows nomadic services in general to join a Jini network and to offer its service to service users. Place Lab offers a technology independent way to determine ones position. The position of a user can be determined based on GPS, WiFi, Bluetooth or other technologies. Combining The Jini Surrogate architecture and Place Lab provides a promising way to realize nomadic positioning services in a device and network independent way. However further research on these technologies is encouraged. 61

74 62

75 6 Recommendations for further research In this masters thesis the possibilities of combining the Place Lab libraries and the Jini Surrogate architecture have been researched. During this assignment a number of problems have been encountered. Some of these problems have been solved, other problems need further research before they can be solved. 6.1 Further research on the Jini Surrogate architecture Some problems were caused by limitations in the Mobile Platform. At the start of this assignment communication in this Jini Surrogate architecture implementation was limited to request-response communication in one way. For the nomadic positioning service communication in two ways is needed. Furthermore performance of this implementation was limited. These problems have been dealt with, by allowing two-way communication, adding one-way messages and optimizing buffer sizes. Other performance limitations such as the optimal number of messages sent in one HTTP message and optimizing the speed (sleep times) of the buffers have not been dealt with. Further research may find solutions to overcome these limitations. Another problem that was encountered is the stability of the Mobile s Platform. When a surrogate has caused errors or exceptions in the SurrogateHost, the SurrogateHost does not function correctly. Some robustness needs to be built into the SurrogateHost to prevent it from malfunctioning after exceptions. Furthermore it might be useful that the connections of a service that is restarted after a time of disconnection are restored. When for example a service is disconnected from the Internet for a few minutes (longer than the keep-alive time times the number of allowed misses) the surrogate is deactivated. The service however keeps on running and gets some exceptions because the message cannot be delivered to the surrogate. When the connection is restored, the keep-alive message is again sent to the surrogate. The surrogate however was deactivated and does not respond to these messages. It might be a nice feature that the surrogate is reactivated when the connection is restored. Another topic for further research is the development of a layer on top of the Mobile s Platform that offers a simple interface to this architecture. With the current architecture the developer of a nomadic service needs to create messages and send these to the surrogate. A layer on top of the architecture that for example implements the methods invokerequest(method) and invokemessage(method), where METHOD is a constant that can be defined by the developer, that is the same in both the service and in the surrogate. 6.2 Further research on Place Lab The Place Lab Tracker that was implemented for the MSPLocation uses a basic weighed average centroid algorithm. This Tracker calculates the position of the nomadic service by weighing the beacon s position with the signal strength. This algorithm is not very sophisticated and can be improved to increase accuracy of the estimate position. Place Lab is available for a number of mobile devices. However due to the native code that is needed it does not work on all mobile devices. The Place Lab developers group is working on this issue. When this problem is solved Place Lab should run on every mobile device. This would make the usage of Place Lab for a nomadic positioning service more ideal. When Place Lab runs only on a limited number of mobile devices it can be used for research but it cannot be integrated in real applications. 63

76 64

77 7 Bibliography [AWA05] The AWARENESS project (2005). A dutch collaborative project on context AWARE mobile Networks and S [Bor05] G. Borriello, M. Chalmers, A. LaMarca, P. Nixon (2005) Delivering REAL- WORLD Ubiquitous Location Systems [Dav02] N. Davies, H. Gellersen (2002) Beyond Prototypes: Challenges in Deploying Ubiquitous Systems Lancaster:Lancaster University [Dea03] R. Dearing (2003) -oriented architecture using Jini [Gol02] R.G. Golden (2002) and Device Discovery : Protocols and Programming New York: McGraw-Hill [Gut99] E. Guttman (1999) Location Protocol: Automatic Discovery of IP Network s [Hal04] A. van Halteren, N. Dokovski (2004). Jini and Next Generation m-health s. Enschede: University of Twente [Hee02] J. de Heer, R. van Eijk, P. Määttä, A. Peddemors (2002). A generic interface for location handling Enschede: GigaMobile [Jin05] Jini Project (2005). The Jini Network Technology [LaM04] M. LaMarca et al (2004). Device Positioning using Beacons in the Wild Seatle: Intel Research [Mah04] Q.H. Mahmoud (2004). J2ME and Location Based services The Sun Developers Network [Mut05] Kavitha Muthukrishnan, Nirvana Meratnia, Maria Lijding (2005) FLAVOUR Friendly Location-aware Conference Aid with PriVacy Observant ArchitectURe [Net05] Netstumbler (2005) Netstumbler.org [New00] J. Newmarch (2000) A Programmer s guide to Jini Technology New York: Springer-Verlag [Pec95] M. Pesce (1995) HyperText Transfer Protocol [Pla03] Placelab.org (2003) What is Place Lab? [SDN05] Sun Developer Network (2005) RMI Slowdown [Sun01] Sun Microsystems (2001) The Jini Technology Surrogate Architecture Overview [Sun03-1] Sun Microsystems (2003) JSR 179: Location API for J2ME [Sun03-2] Sun Microsystems (2003) The Jini Technology Surrogate Architecture Specification [Sun03-3] Sun Microsystems (2003) Jini Specification Archive v1.2 [Sur05] Jini Surrogate project (2005). The Surrogate project 65

78 [Wik04-1] [Wik04-2] [Wik05] [Wif05] Wikipedia (2004) The Location Protocol Wikipedia (2004) Universal Plug-and-Play Wikipedia (2005) Global Positioning System WiFiFoFum (2005) WiFiFoFum scanner All used URLs are of date 20 th of June

79 Glossary APIPA Automatic Private IP Addressing AWARENESS project Dutch collaborative project on context AWARE mobile Networks and S DHCP Dynamic Host Configuration Protocol DNS Domain Name System GSM Global System for Mobile communications GPS Global Positioning System, Positioning Technology GPRS General Packet Radio, Wireless Communication Means HTTP HyperText Transfer Protocol, Communication Protocol HTTPInterconnect Interconnect Interconnect protocol J2ME Jini Jini Surrogate architecture JSR82 JSR179 LAN NAT Nomadic MSP Place Lab RDNAP SLP Surrogate SurrogateHost UPnP WiFi WLAN Implementation of the Interconnect protocol based on HTTP. A communication gateway between a mobile device and the surrogate. Protocol that implements a communication gateway for the physical and logical connection between the mobile device and the surrogate. Java 2 Platform, Mobile Edition Discovery Protocol Architecture that allows a nomadic service to join a Jini network, by implementing a surrogate that represents a nomadic service. Java Specification Request 82, Bluetooth API Java Specification Request 179, Location API Local Area Network, Communication Means Network Address Translation A service that is running in a mobile environment. Mobile s Platform Library that allows positioning based on WiFi, Bluetooth, etc. Dutch Coordinate System (Rijksdriehoeksmeting - Normaal Amsterdams Peil) The complete service that is offered to a service user. Location Protocol, Discovery Protocol that acts for a nomadic service in the Jini network. The surrogate service allows a nomadic service to join a Jini network. Host in which a surrogate can run. Universal Plug and Play, Discovery Protocol Wireless Fidelity, Technology for Wireless Networking Wireless Local Area Network, Wireless Communication Means 67

80 68

81 Appendices Appendix A: Class Diagram MSPLocation Server 69

82 Appendix B: Class Diagram MSPLocation Surrogate 70

83 Appendix C: Class Diagram MSPLocation Client 71