Geographic Location in the Internet

GEOGRAPHIC LOCATION IN THE INTERNET THE KLUWER INTERNATIONAL SERIES IN ENGINEERING AND COMPUTER SCIENCE GEOGRAPHIC ...

Author: Behçet Sarikaya

30 downloads 1046 Views 3MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

GEOGRAPHIC LOCATION IN THE INTERNET

THE KLUWER INTERNATIONAL SERIES IN ENGINEERING AND COMPUTER SCIENCE

GEOGRAPHIC LOCATION IN THE INTERNET

edited by

Behcet Sarikaya Alcatel USA

KLUWER ACADEMIC PUBLISHERS NEW YORK, BOSTON, DORDRECHT, LONDON, MOSCOW

eBook ISBN: Print ISBN:

0-306-47573-1 1-4020-7097-7

©2002 Kluwer Academic Publishers New York, Boston, Dordrecht, London, Moscow Print ©2002 Kluwer Academic Publishers Dordrecht All rights reserved No part of this eBook may be reproduced or transmitted in any form or by any means, electronic, mechanical, recording, or otherwise, without written consent from the Publisher Created in the United States of America Visit Kluwer Online at: and Kluwer's eBookstore at:

http://kluweronline.com http://ebooks.kluweronline.com

Contents

Contributors Acknowledgements Preface

xi xv xvii

Chapter 1 . Location Based Services

1.

Introduction

1

2. Location Based Services

2

3. Lbs Prototypes

3

4. Application Programming Interfaces

4 4 7

4.1 CDMA2000 LBS Applications 4.2 MLP

5.

Summary

10

6.

References

11

Chapter 2. Geolocation on Cellular Networks

1. Introduction

13

2. Existing and Future Cellular Network Technologies

14

vi

Contents

3. GSM and its Successors

16

4. The GSM Location Services Framework

21

5.

6.

Mobile Positioning Methods 5.1 Cell Identity 5.2 Time of Arrival and Time Difference of Arrival 5.3 Enhanced Observed Time Difference 5.4 Observed Time Difference of Arrival with Idle Periods in the Downlink 5.5 Advanced Forward Link Trilateration 5.6 (Assisted) Global Positioning System 5.7 Comparison of the positioning methods Geographical Area Description

26 27 28 30 32 32 33 35 37

7. Positioning Procedures in the Location Services Framework

39 40 7.1 Mobile Originating Location Request (MO-LR) 7.2 Mobile Terminating Location Request (MT-LR) 42 7.3 Mobile Terminating Deferred Location Request (Deferred MT-LR) 44 7.4 Network Induced Location Request (NI-LR) 45

8.

Summary

References

45 46

Chapter 3. Location Service in CDMA2000 Networks

1. Introduction

51

2. Location Service Based on IS-41 Network

53 53 54 55 56 56 56 58 60 60 61

IS-41 Based Network Reference Model for Location Service Location Service Control Position Determination Location Service Procedure 2.4.1 Registration Procedure 2.4.2 Location Information Retrieval Procedure 2.4.3 MS Assisted Position Determination Procedure 2.5 Application Examples 2.5.1 Find Nearest McDonald Restaurant 2.5.2 Emergency Service Call

2.1 2.2 2.3 2.4

Contents

vii

3. Location Service in All-IP Network 3.1 All-IP Network Reference Model for Location 3.2 Position Service Registration in All-IP Network 3.3 Location Service Scenario

4.

Service

Conclusion

References

62 62 64 65 66 67

Chapter 4. Application of Location Information to SIP

1. Introduction

69

2. The Session Initiation Protocol

70 71 72 75 75 75 76 76 79

2.1 The SIP protocol 2.2 The SIP architecture 2.3 SIP in wired networks 2.3.1 SIP within ISP 2.3.2 Providing Location Data in Wired Networks 2.4 SIP in wireless networks 2.4.1 UMTS Architecture 2.4.2 Provisioning Location Data in UMTS networks

3. SIP Service Provisioning 3.1 SIP mechanisms for Services provisioning 3.2 SIP services provisioning 3.3 Architecture and Data Formats for Location Information Location Interoperability Forum 3.3.1 3.3.2 WAP Forum Spatial Location Information in Fixed IP Networks 3.3.3 3.4 Location Based Services Scenarios 3.4.1 Emergency Call 3.4.2 Location Based Supplementary Services Service Discovery 3.4.3 3.4.4 Security at SIP Layer

4. Conclusion 4.1 Security

5. References

79 80 81 81 82 88 92 94 95 99 102 102 104 104 105

viii

Contents

Chapter 5. Protocols for Updating Highly Accurate Location Information

1. Introduction

111

2.

113 113 113

Background 2.1 Positioning Sensors 2.2 Network Environment

3. Update Protocols 3.1 Classification 3.1.1 Querying Protocols 3.1.2 Reporting Protocols 3.1.3 Combined Protocol 3.2 Behavior in Case of Disconnection 3.2.1 Querying Protocols 3.2.2 Reporting Protocols 3.2.3 Combined Protocol 3.3 Summary

4. Analytical Comparison of the Protocols 4.1 4.2 4.3 4.4 4.5

5.

Location and Uncertainty Model Querying Protocols Reporting Protocols Combined Protocol Discussion

Simulation Results

114 115 115 117 120 121 122 122 122 122 123 125 127 128 130 131 135

6. Conclusion

139

References

140

Chapter 6. Geographic Search Engines

1. Introduction

143

2. HTML Markup

144

3. Web Traversal and Indexing

145

4. Search Algorithm

146

5. Presentation

147

Contents

ix

6. MAP Caching

149

7.

Mobile Applications

150

8.

Geographic Datum

151

9. Advanced Geographic Searching 9.1 9.2 9.3 9.4

Keywordless Searching Keywordless Search Algorithms Applications of Keywordless Search Zipcode searching

151 152 153 154 157

10. Property Rights Issues

158

11. References

158

Chapter 7. The Elements of Location Tracking and Privacy Protection

1. The Critical Need for Privacy Protection

163

2. Diversity of Location Service Scenarios

165 165 166 166 167

2.1 2.2 2.3 2.4

Open or Closed Location Environments Tracking a Person or a Thing Fixed or Mobile Locations Private or Public Raw Location Data

3. The Elements of Location Computation 3.1 A Framework to Describe Location Computation Scenarios 3.2 The Basic Location Computation Scenarios 3.3 Examples of Scenarios

168 168 170 171

4. After the Location Computation

172

5. Privacy Rules and Their Enforcement

173 173 174 175 176 177

5.1 5.2 5.3 5.4 5.5

General Elements of Privacy Specific Elements of Location Privacy A Critical Need for Strong Default Privacy Rules Implications of the Location Computation Scenarios Possible Technological Considerations

6. Conclusion

178

7. References

178

x

Contents

Chapter 8. Location Information Privacy

1. Overview

179

2. Motivation: The Problem

181

3. Framework: Entities, Flows, Scenarios

182 182 185 185 186 187 188 189 190 191 192 193

3.1 Entities 3.2 Data 3.2.1 Sighting 3.2.2 Location 3.2.3 Identities and Credentials 3.2.4 Policies 3.3 Data Flows 3.4 Scenarios 3.4.1 Scenario 1: The Handset-based Solution 3.4.2 Scenario 2: A Network-Based Location Data Source 3.4.3 Scenario 3: External Location Server 3.4.4 Scenario 4: External Location Server and Location Recipients 3.4.5 Scenario 5: External Location Data Source and Locati Server 3.4.6 Scenario 6: Untrusted Local Location Server

4. Identity Management 4.1 Privacy: Definitions 4.1.1 Other considerations 4.2 Identity of Users, Location Recipients 4.2.1 Public Identities 4.2.2 Private Identifiers 4.2.3 Some realizations of the identity/credential requirements

194 195 197 197 197 199 200 200 203 205

5.

Summary of Requirements

206

6.

References

208

Contributors

Behcet Sarikaya obtained his PhD in Computer Science from McGill University, Montréal, Canada in 1984. He worked in University of Sherbrooke (1984-1985) and Concordia University (1985-1990) as Assistant Professor and in University of Montréal (1990-1991) as Visiting Professor in Montréal, Canada. In 1991 he joined Bilkent University, Ankara, Turkey and worked there until 1993 as Associate Professor. He worked at the University of Aizu, Computer Communications Lab in Aizu-Wakamatsu, Fukushima, Japan as Professor during 1993- 2001. In January 2001 he joined Alcatel, USA, Network Strategy Group in Plano, Texas where he works at Mobile IP and 3GPP2 case. His research interests include mobile networking, next generation All-IP cellular networks and location based computing. Email: [email protected] Pekka Sahi received the M.Sc. (Economics and Business Administration) degree from Helsinki School of Economics, Helsinki, Finland, in 2001 and the M.Sc.(Tech) degree from Helsinki University of Technology, Espoo, Finland, in 2002. Sahi has a versatile background in sales, marketing and business development. He is currently employed as the Sales and Marketing Director at BellStream Corporation, a company specialized in tailored, strategy-aligned e/mBusiness solutions. E-mail: [email protected]

Xiaofeng Xu is a research scientist for the Mobile Networking Technologies project in Network Strategy Group within Alcatel in Plano,

xii

Contributors

Texas. He received his B.S. in electrical engineering from University of Science and Technology of China in 1993. He joined Alcatel in July 1993. Since then he has been involved in research and development of networking systems in GSM, GPRS and CDMA standards, and responsible for 2G/3G wireless standardization on behalf of Alcatel in China Wireless Telecommunication Standards Group (CWTS). He is currently working on Mobile IP and CDMA2000 network research. E-mail: [email protected] Jose Costa-Requena is currently working for Nokia Mobile Phones in Helsinki, Finland. He is also a senior researcher in the Telecommunication Department at Helsinki University of Technology (HUT) where he developed his Master Thesis. He is studying his PhD and leading a group of researchers at HUT. He studied telecommunication engineering at the Polytechnic University of Valencia, Spain. As part of his research, he is developing new network architectures and designing new services for 3GPP. His other interests include terminal capabilities, database systems security and AdHoc networks. E-mail: [email protected] Alexander Leonhardi received his M.S. degree (Diploma) from Stuttgart University in 1997. Since then he has been working as a research assistant in the Distributed Systems Resarch Group at Stuttgart University. His current research interests are mobile computing, location-awareness, location manangement and ubiquitous computing. Email: [email protected] Andrew Daviel lives in Vancouver, Canada where he works at TRIUMF, the High Energy Physics facility, as Computer Security Manager and as an electronics designer. He has worked on Internet-related projects both inside and outside TRIUMF including search engines, web page caching, the Dublin Core metadata project and the IETF geopriv working group. He is also an avid reader of science fiction. E-mail: [email protected] John B. Morris, Jr., is the Director of the Center for Democracy & Technology's Internet Standards, Technology and Policy Project. The Project seeks to work within Internet standards setting bodies to identify and address public policy issues raised by proposed standards and technology, and to build better communication among technologists, public interest advocates, and policy makers working on issues Internet policy issues. Prior to joining CDT in April 2001, Mr. Morris was a partner in the law firm of Jenner & Block, where he litigated groundbreaking cases in Internet

Contributors

xiii

and First Amendment law. He was a lead counsel in the ACLU vs. Reno/American Library Association vs. U.S. Dep't of Justice case, in which the U.S. Supreme Court extended to speech on the Internet the highest level of constitutional protection. Prior to becoming a lawyer, Mr. Morris designed and developed computer software systems for use by members of the U.S. Congress, and in 1985 he co-founded Intelligent Solutions, Inc., which until its acquisition in 1997 was the leading software vendor to Congress. E-mail: [email protected] Jorge R. Cuéllar studied mathematics (BA. and MA.) at the Universidad de los Andes, Bogotá and obtained a Ph.D. from the University of Mainz in Germany. He was faculty member of the Ohio State University and the Universidad de los Andes. Since 1987 he has been with Siemens, where he is Principal Research Scientist and has held visiting teaching positions at Technical University of Chemnitz, Technical University of Munich, University of Dortmund, University of Freiburg, and the University of Canterbury (Christchurch, New Zealand). He has worked in operating systems, formal methods, neural networks, performance and network security. E-mail: [email protected]

This Page Intentionally Left Blank

Acknowledgements

Behcet Sarikaya would like to express his gratitude to all the chapter contributors whose hard work, timely responses, professionalism and diligence made this book possible. He is grateful to Alex Greene of Kluwer for approaching him to undertake this project and Melissa Sullivan of Kluwer for her expert assistance in helping prepare the manuscript for typesetting. Last but not least he thanks his wife Nursen, daughter Didem and son Dennis for patience, love and support. Xiaofeng Xu would like to express thanks to his colleagues in Alcatel Network Strategy Group for their help in the work, and special thanks to his wife (Yihui Wang) for her patience and support. Jose Costa-Requena wishes to thank all his colleagues from Nokia that helped him on this topic, especially Haitao and Mary. He would like to thank the Kluwer team and Dr Sarikaya for this opportunity and to ensure that the book got published. He thanks his work mates Matti, Juha, Raimo and all Tampere team. Especially to his wife for providing him the necessary strength and his family (Tomas, Fineta, Espi, Pou, Gema, Tomas, Neich, Peri, Moni, Ro, Ste, Noe, Ines, Ste, Vicenton and a unfinished list) for their support during the sunny days. The author of Chapter 7 acknowledges the critical contribution of SabraAnne Kelin of the Samuelson Law, Technology and Public Policy Clinic at the Boalt Hall Law School at the University of California at Berkeley. The author also acknowledges Deirdre K. Mulligan, the Director of the Clinic, and two additional Clinic participants, Christopher K. Ridder and Eddan Katz. The author is in debt to all of the participants of the Internet Engineering Task Force's "geopriv" working group, in particular Jorge Cuellar, Alan Davidson, Randall Gellens, Allison Mankin, Brian Rosen, and

xvi

Acknowledgements

Behcet Sarikaya. Finally, the author's work in the field of Internet standards in general, and geo-location privacy in particular, is made possible by the Center for Democracy & Technology. The author of Chapter 8 greatly acknowledges the discussions in the geopriv working group and mailing list. Also, in alphabetical order: Keith Drage, Randall Gellens, Allison Mankin, Mehmet Ersu, Peter Moritz, John Morris, Ajith Narayanan, John W Noerenberg II, Max Riegel, Brian Rosen, Bobby Sardana, Behcet Sarikaya, Henning G. Schulzrinne, Adam Shostack, Kenji Takahasi, Mario Tapia, Christoph Valentin, and John Wells.

Preface

This book is on making digital location information available to software applications running on mobile devices. Mobile devices are connected to the Internet using various wireless link-layer techniques. Digital location information is the geographic location information which can take several different forms. Location-aware or location-based computing is making possible applications with the capability to sense their location and modify their settings, user interface, and functions accordingly. Chapter 1 is entitled Location based services. It aims at bridging the subjects described in the following chapters by first introducing the locationbased services and then describing location-based standardized application programming interfaces. Chapter 2 is entitled Geolocation on cellular networks. Cellular networks can be divided into first, second and third generation. The most successful mobile standard is GSM, which will evolve via GPRS and EDGE into UMTS. The GSM LCS framework is a distributed positioning architecture whose two logical components are the LCS Client (external to the PLMN or within MS) and the LCS Server (within PLMN). The latter adds a GMLC, an SMLC and an LMU into the existing architecture of GSM or its successors. The positioning methods included in the various cellular standards are CI+RTD (TA or RTT), TOA/TDOA, E-OTD, OTDOA-IPDL, AFLT and AGPS. They can be evaluated on the basis of accuracy, reliability, availability, latency and feasibility. The network positioning procedures include Mobile Originating, Mobile Terminating, Mobile Terminating Deferred and Network Induced Location Requests. In GSM and its successors, whenever an LCS Client produces an LCS Request, one of these procedures will be

xviii

Preface

used to provide an LCS Response by the combined logical LCS server component. In the response, the location estimate is then expressed using the WGS 84 co-ordinate system as an ellipsoid point, an ellipsoid point with an uncertainty circle, an ellipsoid point with an uncertainty ellipse, an ellipsoid point with altitude, an ellipsoid point with altitude and an uncertainty ellipsoid, a polygon or an ellipsoid arc. Velocity information may also be given as horizontal velocity, horizontal velocity with uncertainty, horizontal and vertical velocity and horizontal and vertical velocity with uncertainty. Instead of this GAD format, some other local geographical reference system may also be used. Chapter 3 entitled Location Service in CDMA2000 Networks introduces 3GPP2 or CDMA2000 location services. It starts with IS-41 based services and continues to describe CDMA2000 All-IP architecture based location services. Chapter 4 entitled Application of Location Information to SIP is on the Internet Engineering Task Force’s Session Initiation Protocol (SIP) based location based services. It introduces SIP and then shows how location information can be supported by SIP servers. The chapter continues with a coverage of SIP in wireless networks such as GPRS and UMTS. Next discussed are the location data formats used by the location information forum (LIF) and 3GPP and the mobile location protocol (MLP) developed by LIF and location based Wireless Application Protocol (WAP) services. Chapter 5 is entitled Protocols for Updating Highly Accurate Location Information. Detailed location information of mobile objects, for example that of a user with a mobile computer or phone, is an important input for many location-aware applications. However, constantly updating the location information for thousands of mobile objects is not feasible. Therefore, special update protocols for location information are required that transmit this information as efficiently as possible, that is, requiring only few update messages, while still being effective in returning the location information with a requested accuracy. Different classes of such update protocols, including a promising dead-reckoning protocol, are described in this chapter and a new combined protocol is proposed. To be able to compare their effectiveness and efficiency, it presents an analysis for the minimum and average resulting accuracy of the location information, in comparison with the number of messages transmitted. The chapter also presents the results of simulations based on real-world GPS traces to back up the analysis. Chapter 6 entitled Geographic search engines first introduces the geographic search engine called Geotags and then continues to discuss the

Preface

xix

issues involved in advanced geographic searching such as keywordless searching. Geographic search engines enable us to find places which have less than ten centimetres of rainfall a year, or a motorist may wish to find the nearest service station all requiring the meta data of the geographic location integrated with IETF’s HTTP and HTML, i.e. the Web browsers. Remaining of the book is devoted to chapter on location information privacy, an issue of growing importance. Chapter 7 entitled The Elements of Location Tracking and Privacy Protection addresses the critical need for privacy protection of the location information.The methods and uses to protect privacy depend on diverse location service scenarios which are described next. The chapter concludes with a discussion of the privacy rules and their enforcement. Chapter 8 entitled Location Information Privacy explores the technical requirements for protocols used to transfer location data, focusing on authorization, integrity and privacy. As motivated in the previous Chapter, there is a need to securely gather and transfer location information for location services, protecting the privacy of the individuals involved. This document explores some of the requirements for protocols used to transfer location data, focusing on authorization, integrity and privacy. Although complete anonymity may not be appropriate because of legal constraints or because some location services do in fact need the explicit identification of the user, we argue that in most cases, the services do not need precise context-independent location information, but only require a less precise or context-dependent location information, which is not so easily understood and linked by outsiders. Also, the location services do not need the identity of the user but only some attribute of the user, authorization information, and/or anonymous identifier of the user. The book is an ideal reading for everyone involved in mobile networking as geographic location is an integral part of any mobile system. The book is written for engineers who work on any of the mobile networking and mobile computing areas as technical reading book. It can also be used as text book for a graduate course on geographic location and location-based systems.


Chapter 1 Location Based Services Behcet Sarikaya Alcatel USA

1.

INTRODUCTION

Geographic location of mobile devices can be determined in the form of a triplet: latitude, longitude and altitude using various techniques. The possibility and if possible the accuracy of the geographic location depends on the technique used as well as if the mobile device is located indoors or outdoors.

Figure 1 shows a generic architecture. The mobile device should be location enabled. The mobile network with its base stations/ access points

2

Chapter 1

and other infrastructure should be location enabled possibly with the addition of the location server shown on the left. Optionally the use of the geographic positioning system (GPS) satellites is required. After determining the geographic location in the World Geodetic System 1984 (WGS 84) format this data can furthermore be enhanced to become more meaningful if the triplet can be located in a map. Such an enhancement would enable whole new sets of location based applications. With the addition of the altitude and more detailed map information, the mobile device location even be more enhanced adding other sets of new location based services.

2.

LOCATION BASED SERVICES

Early location based services (LBS) were developed based on GPS satellite access and did not require the use of the Internet. A prominent example is car navigation systems. New systems are deployed in cellular networks that are being integrated with the Internet. Enhanced 911 (E911) regulation introduced by the Federal Communications Commission (FCC) of the USA is the driving force of recent developments in this area. Phase I of E911 started to be implemented in April 1998. Phase II implementations began in October 2001 with two tracks of technology and accuracy requirements: for handset-based solutions, it was required to have 50 meters of accuracy for 67% of the calls; for network-based solutions 100 meters of accuracy for 67% of the calls [2]. LBS can be classified into the following categories [3]: - Enhanced Personal Safety & E911 Child safety and enhanced road assistance systems and E911 based systems require the identification of the general neighbourhood and if enhanced accuracy is available, the identification of the callers home or the street. - Concierge Services The systems that provide driving directions such as the car navigation systems and mobile yellow page systems are concierge services. Depending of the accuracy, the service may be able to provide only the address of nearby banks and ATM. The service may as well offer detailed directions to the nearest ATM. - Commercial applications Zone-based billing, taxi, pickup delivery systems, permission-based advertisements are examples of commercial applications. These systems can either identify the stores in a general area or with increased accuracy the user may be able to get directions to the store of choice.


3

- Tracking high value assets These systems track containers, railcars, truck trailers of high value. They may also be used to track offenders. They may be only able to identify general location of assets or identify the street and even the street corner.

3.

LBS PROTOTYPES

So far several prototypes of location based systems have been built using different mobile devices connected to different access technologies [4]. Active Badge indoor system uses infrared technology. The user carries an electronic badge which communicates with fixed infrared sensor infrastructure deployed in the rooms. Absolute location data is made available in the form of an application programming interface (API) to the applications and used by nearby computers to modify their behaviour such as redirecting the user’s X Windows system environment to wherever the user goes, an early teleporting type of application [4]. PARCtab system extended Active Badge with a palm-sized tablet computer. The tab commands the applications, but the applications are executed in the computer infrastructure and then the results displayed on the screen of the tab, transmitted over the diffuse IR network. Active Bat indoor system has a more accurate location sensing capability. The Bat that the user carries emits an ultrasonic pulse to ceiling-mounted receivers. At the same time the controller sends the radio frequency request packet, it also sends a synchronized reset signal to the ceiling sensors using a wired serial network. Each ceiling sensor measures the time interval to ultrasonic pulse arrival and computes its distance from the Bat. The local controller then forwards the distance measurements to a central controller, which performs the lateration computation. This way a Bat can be located within 9 cm of its true location. Active Bats can be used to implement a more precise teleporting. A user may have a number of desktops on different machines. One of the buttons on the Bat is used to allow the selection of an alternative desktop once the user has teleported to a display. Tablet based computers equipped with IEEE 802.11 wireless cards communicating with base stations are used in Guide system. The location of the user is provided using location beacons sent by the base stations to the tablets and therefore is not very accurate. The geographic model contains two distinct object types: navigation point objects and location objects. Navigation point objects represent waypoints between location points such as intersections. Guide uses navigation points to provide route guidance. Location objects represent points of interest in the city, such as landmarks,

Chapter 1

4

shops, and cafés. Location objects also encompass state information associated with the entity they represent and at least one link to an associated Web page describing the location. Examples of state information include whether the location is open or closed for business and the number of times the user has visited the location. The Guide end-user system provides several capabilities such as access to information such as their location and preferences; tailored city tours with route guidance to help users move between locations on the tour; users can exchange messages with other Guide users and with the Tourist Information Center staff helping them to keep in touch and ask questions. E911 is the term used for emergency-services calls to 911 made from cell phones. The new E911 requirements effective in the US as of 1 October 2001 require that 95 percent of emergency-services calls made from mobile handsets be locatable to within 150 meters. Mobile operators are deploying new services to respond to the location of E911 caller. The same mechanisms that enable emergency services will likely be made available to higher-level services, which in turn will provide an API for developers. Application writers can use this interface to augment existing applications or invent entirely new ones.

4.

APPLICATION PROGRAMMING INTERFACES

Location-based service applications are developed using standardized application programming interfaces (API) and their access to the cellular network by third party service applications is enabled by network specific means. We will describe the position server control plane for CDMA2000 networks and an example API developed by the location inter-operability forum called MLP.

4.1

CDMA2000 LBS Applications

We take the Location Server in a cellular network as shown in Figure 1. In CDMA2000 3G cellular network such a server is called a Position Server. The Position Server may be accessed from applications in both the home and visited network. The movement of a roaming Mobile Station’s related position service capabilities between Access Gateways in a hard handoff situation is also supported [6].


5

The first step is the registration of the mobile station with the Position Server. This may require the interactions with the Position Server in the visited network with a Proxy Position Server in the visited and home networks and the Authentication, Authorization and Accounting (AAA) servers for security establishment as shown in Figure 2.

6

Chapter 1

This enables access by the applications on the home network the position information of the user.

The application sends a Position Information Request to the Network Capability Gateway in its own network (1 in Figure 3). Network Capability Gateway interrogates the home AAA to authenticate and authorize access to


7

position information.(2 in Figure 3). After the security is established the visited Proxy Position Server forwards the Position Information Request to the Position Server in the visited network (8 in Figure 3). The Access Gateway responds with the position service information (10 in Figure 3). The Position Server in the visited network then sends a Position Information Response to the visited Proxy Position Server (13 in Figure 3). Finally the Network Capability Gateway forwards the Position Information Request Response to the requesting home network Service Application (16 in Figure 3).

4.2

MLP

There are two standardized application programming interfaces (API) that are location data enabled: PARLAY and MLP. These APIs are designed for developing Internet based application that use location data of mobile devices connected to cellular networks. We discuss MLP in detail. Location Inter-operability Forum (LIF) has recently developed an API to transport the location information of a node in a wireless network to an Internet host called mobile location protocol (MLP) [5].

MLP defines the interface between a location-based application and a location server such as GMLC of 3 GPP described in Chapter 2 and MPC of 3GPP2 described in Chapter 3 (The content is defined in the markup language of XML and is independent of any transport mechanism used. MLP is structured into three layers as shown in Figure 5. The lowest layer is the transport layer. XML content can be transported using different protocols such as HTTP, WSP, SOAP, etc. Presently only HTTP transport is defined. The element layer defines core location elements used by the services. Service layer defines actual services provided by MLP. Presently only basic

8

Chapter 1

MLP services are defined such as Standard Location Information Service (SLIS) consisting of more than one messages.

Location services are invoked by the LCS client sending a request using HTTP POST to the Location Server at a certain URI such as: http://host:port/LocationQueryService/ The response is returned using an HTTP response. The response is the answer to the location query and is included in the message body and the Content-length entity will be set to the length of the answer. There are a number of different possible types of location services such as Emergency Location Immediate Service, Standard Location Immediate Service and Triggered Location Reporting Service. Emergency location immediate service for example is a service used especially for querying of the location of a mobile subscriber that has initiated an emergency call. The response to this service is required immediately (within a set time). MLP uses ellipsoid coordinates of longitude, latitude, altitude as well as Universal Transverse Mercator planar coordinate system which is obtained by using x,y where x is the longitude divided by a constant factor of 6 and y is the latitude. Using UTM, zones can be defined on the world map. An example MLP location service is the standard location immediate service, a standard service for requesting the location of one or more Mobile Subscribers. The service is used when a single location response is required immediately (within a set time). An immediate request should be used when the LCS Client wants to receive the answer to the request over a persistent connection.


9

The service consists of the following messages: Standard Location Immediate Request; Standard Location Immediate Answer and Standard Location Immediate Report. If several location requests are made then the location server may initiate several connections using HTTP Post to LCS Client to send the responses as shown in Figure 6. An example Standard Location Immediate Request can be defined as Document Type Definition (DTD) in XML as follows: <slir ver="2.0.0" res_type="PERSISTENT"> <msids> <msid type="IPV4">93.10.0.250 <msid_range> <start_msid>461018765710

10

Chapter 1 <stop_msid>461018765712 <eqop> 1000 IDMS3 <prio type="HIGH" /> <truckco_send_sms> You have been positioned by The Truck Company

5.

SUMMARY

We defined a generic architecture with which geographic location of mobile devices can be determined. The architecture includes wireless base stations, a location server and GPS satellites. Location-based services that can be offered to people carrying mobile devices include emergency services such as enhanced 911, high value asset tracking systems and commercial services such as location-based advertisements. Several LBS prototypes have been developed in the universities and research centers. The location of the mobile devices in these prototypes can be accessed using different wireless access technologies. An application programming interface and databases must be designed to enable the development of different types of applications using real-time absolute location data. Standardized APIs and architectures are required to access the location data from cellular networks. We described the example of CDMA2000 cellular networks and the example API called mobile location protocol developed by the location interoperability forum (LIF).


6.

11

REFERENCES

[1] Fall 2001 Location Based Services Forum , October 2001, Santa Clara, CA, USA, URL:http://pulver.com/ [2] Thomas Sugrue, Wireless E911:Regulatory framework, current status and beyond, presentation in [1]. [3] Tom Wrappe, Implementing a Wireless Assisted GPS Solution for Location-based Services, presentation in [1]. [4] Expanding the Horizons of Location-Aware Computing, IEEE Computer Magazine

Special

Issue,

August

2001,

URL:

http://computer.org/computer/co2001/r8toc.htm. [5] Mobile Location Protocol Specification, Location Inter-operability Forum (LIF) TS 101 v2.0.0, Approved specification, November 2001. [6] IP Network Architecture Model for cdma2000 Spread Spectrum Systems, 3GPP2 SC.P000X, August 2001, URL: www.3gpp2.org.


Chapter 2 Geolocation on Cellular Networks

Pekka Sahi Helsinki University of Technology, Finland

1.

INTRODUCTION

This chapter will explain how positioning is arranged in the current and future cellular networks. It will concentrate on network architecture, positioning methods and positioning procedures, thus leaving network signaling, interfaces, information storage arrangements and operational as well as privacy aspects out of its scope. GSM and its successors will be held as a running example. This is because the GSM technology now accounts for more than 70 per cent of the world's digital mobile phones, and its successors are expected to grab more than 85 percent of the total third generation (3G) wireless market (GSM ASSOCIATION 2001). The University of Technology, Sydney claims that in 1996, it was the first place in the world to demonstrate accurate positioning of a GSM mobile telephone (UTS 2001). But the large-scale deployment of the positioning technologies by the mobile operators has not yet happened, and by now there are only few commercial services based on location capability. It is important to note that the location/proximity information has no value in itself, since it is only one of several elements that are necessary to make the services valuable to users. For example, details on the location of a mobile user who is trying to locate a favorite restaurant are not particularly valuable without the underlying database that can match user location to street maps with names and location of various retail establishments. (UMTS FORUM 2001, 35-36)

14

Chapter 2

This chapter is organized in the following manner. Existing and future cellular networks will first be put into their context, after which GSM and its successors will be presented more thoroughly. This will make the unaccustomed reader able to understand positioning architectures and methods; but on the other hand, cellular professionals can naturally skip the first two sections. The GSM Location Services framework will then be presented, after which the positioning methods will be elaborated and compared. The network positioning procedures and the Geographical Area Description will then be discussed, after which the summary closes the chapter.

2.

EXISTING AND FUTURE CELLULAR NETWORK TECHNOLOGIES

Figure 7 (next page) presents some examples of the first, second and third generation mobile telecommunications networks. They are all cellbased systems where a bigger region is divided into smaller cells each served by a separate base station. First generation networks were realized through an analogue radio link technology and mostly digital network signalling (Judén & Kuokkanen 2000, 2). They include NMT (Nordic Mobile Telephone) 450 and 900, which were taken into use in 1981 (Nordic countries) and 1986 (Nordic countries, Holland and Switzerland), respectively. NMT has also been used in France and many Eastern Europe countries (Penttinen 2000, 11-12). AMPS (Advanced Mobile Phone Service) was developed in the Bell laboratories in 1970 and taken into commercial use in 1983 in the US. Developed by Motorola, the AMPS based TACS (Total Access Communications System) was first taken into use in Great Britain in 1985 (Judén & Kuokkanen 2000, 6) and then later in Austria, Italy and Spain. Many country specific systems were also developed, of which Radiocom 2000 is French, RTMS (Radio Telephone Mobile System) Italian, C-NETZ German and the TACS based JTAC Japanese. (Penttinen 2000, 12)

2. Geolocation on Cellular Networks

15

The first generation systems have in recent years given room for the fully digital and therefore more efficient second-generation networks (Judén & Kuokkanen 2000, 2). These include GSM (Global System for Mobile communications) whose technical and commercial building blocks were established in the MoU (Memorandum of Understanding) signed by 13 European operators in 1987, and which was taken into use in 1991. GSM now covers most of Europe and significant parts of US, Australia, Asia and Africa. (Penttinen 2000, 11; 14-15) DCS (Digital Cellular System) 1800 is based on GSM, but due to its higher operating frequency, smaller cell size and wider frequency band, it enables higher capacity and is used where that of GSM is full (Judén & Kuokkanen 2000, 8). The PCS (Personal Communications Services) 1900 is the North American implementation of DCS 1800. Trial networks were operational by 1993, and in 1995 the FCC (Federal Communications Commission) auctioned commercial licenses for the US. (IEC A, 16). The D-AMPS (Digital AMPS) uses the same setup protocols as analog AMPS and the TDMA (Time Division Multiple Access) digital air interface standard. The IS-54 (Interim Standard 54) specifies the traffic on its digital voice channels (IEC A, 13-15) and the IS-136 adds the Short Message Service (SMS) capability to this (Taylor et.al. 1996). Networks that utilize the IS-95 CDMA (Code Division Multiple Access) air interface and the ANSI-41 network protocol are branded as cdmaOne. The first commercial launch of cdmaOne was in Hong Kong in 1995. (Larsson 2000, 59) Also Japan has its own digital mobile network PDC (Personal

Chapter 2

16

Digital Cellular) that was introduced in 1993. (Judén & Kuokkanen 2000, 89). In addition to the above, paging and cordless systems should be mentioned in connection to the first- and second-generation mobile systems. Paging systems include e.g. ERMES (European Radio MEssaging System). Cordless telephones are a wireless extension to the PSTN (Public Switched Telephone Network) and they include the analog CT1 (Cordless Telephone, generation) and the digital CT2 (Cordless Telephone, generation), DECT (Digital Enhanced Cordless Telecommunications), and PHS (Personal Handy Phone System) (Chakraborty 1999, 850; Penttinen 2000, 13)1. For the smooth evolution to the third generation networks, GSM Phase 2+ releases have introduced new transmission principles such as HSCSD (High-Speed Circuit Switched Data), GPRS (General Packet Radio Service) and EDGE (Enhanced Data rates for GSM and TDMA/136 Evolution). 3G systems, known collectively as IMT-2000 (International Mobile Telecommunications 2000)2, are a single family of 17 compatible standards accepted by the International Telecommunications Union (ITU) in 1999. They were drafted by regional standards developing organizations and they include UMTS (Universal Mobile Telecommunications System) as GSM’s successor – also known as W-CDMA (Wide-band CDMA); CDMA2000 as a successor to IS-95; and TD-SCDMA (Time Division-Synchronous CDMA) as IS-136’s successor – also called as UWC-136 (Universal Wireless Communication-136/EDGE). (IEC B, 3-4)

3.

GSM AND ITS SUCCESSORS

In 1989 ETSI (European Telecommunications Standards Institute) TC SMG (Technical Committee Special Mobile Group) started the governance of the GSM specification work, which was formerly done by CEPT (Conférence Européenne des Postes et Télécommunications). On the other hand, the GSM Association governs for the general principles of the GSM community – e.g. billing – in accordance to the GSM MoU. (Penttinen 2000, 14-16) Figure 2 below depicts the architecture of a GSM network, which consists of Mobile Stations (MS) and a PLMN (Public Land Mobile Network). The PLMN can be divided into three main subsystems. First, in the Base Station Subsystem (BSS) one Base Station Controller (BSC) 1

2

Sometimes the term CT0 is used for unofficial cordless telephones that are not accepted by authorities (Penttinen 2000, 13). Formerly known as FPLMTS (Future Public Land Mobile Telecommunications System) (Penttinen 2000, 17)


17

controls the radio resources of one or more Base Transceiver Stations (BTS), that each serves one cell (Penttinen 2000, 33, 46; GSM 03.02 1996, 15). Second, the main element of the Network Switching Subsystem (NSS) is the Mobile services Switching Centre (MSC), which performs all the switching and signalling functions for the MSs located in a geographical area designated as the MSC area (GSM 03.02 1996, 14). It looks like an ordinary digital exchange to the fixed networks (e.g. PSTN) (Penttinen 2000, 48), but in fact it communicates with them via an integrated InterWorking function (IWF) (GSM 03.02 1996, 14). In addition, if there is a connection from an outside network or switching centre to an MSC into whose area the target

MS has not registered, the Gateway MSC (GMSC) will handle routing forward to the appropriate MSC. There can be five registers connected to MSC, of which the Home Location Register (HLR) and the Visitor Location Register (VLR) are mandatory (Penttinen 2000, 48-50). The HLR stores the subscription information and some location information enabling the charging and routing of calls towards the MSC where the MS is located (Penttinen 2000, 50, 196-198; GSM 03.02 1996, 12). The VLR in charge of one or more MSC areas controls an MS roaming there. When a mobile station enters a new location area (consisting of all cells in a particular geographical area), it initiates a registration procedure where the MSC in

18

Chapter 2

charge of this area transfers the VLR the new Location Area Identification (LAI). If the MS is not yet registered to the VLR, the latter and the HLR exchange information to allow correct call routing (GSM 03.02 1996, 13). The optional registers are the Equipment Identity Register (EIR), the Authentication Centre (AuC) and the Group Call Register (GCR). Third, there are one or more Operations and Maintenance Centres (OMC) in the Operations Sub-System (OSS), whose main tasks include network operation and maintenance and management of subscriber information and mobile terminals. (Penttinen 2000, 52-57) Figure 2 presents also the PLMN’s signalling interfaces, of which some may become internal as some network functions are integrated in the same physical equipment – e.g. in the case of MSC/VLR (Penttinen 2000, 51; GSM 03.02 1996, 15). The services provided by GSM are divided into bearer services, teleservices and supplementary services. The bearer services make it possible to transfer voice and data, operating at GSM layers comparable to the physical, link and network layers of the ISO’s (International Standards Organization) OSI (Open System Interconnection) model. The teleservices implemented in the GSM networks on top of the bearer services include voice (ordinary and emergency calls), Short Message Service (SMS) and fax3. The GSM supplementary services include e.g. call waiting or forwarding. In addition to the above there is a fourth (although not standardized) group of services value added services – that use the standardized GSM services as their platform. (Penttinen 2000, 107-113) In 1996, ETSI decided to enhance GSM in annual Phase 2+ releases that incorporate 3G capabilities (IEC B, 3). The first extension to the existing GSM technology is HSCSD, which is a concept to increase data transfer rate from 9,6 kbps of the basic GSM to 38,4-64 kbps by using multiple TDMA frames. HSCSD became available during 2001. Some operators have implemented it and there are terminals able to support it. (Koskinen 2001, 9; Penttinen 2000, 183-186) ETSI governed for the development of the GSM specifications until July 2000, when the TC SMG was closed and the development work continued in 3GPP (Third Generation Partnership Project)4. (3GPP, 2001; Meredith 2001; Penttinen 2000, 17) 3GPP, founded in 1998, will provide globally applicable Technical Specifications (TS’s) for 3G systems based on evolved GSM core network. These TS’s will then be 3

Data services are also possible in GSM, but they should not be considered part of any predefined service group. They are implemented through connecting the MS to a computer with e.g. a PCMCIA (Personal Computer Memory Card International Association) card, and using the phone as a modem in a circuit switched network. (Penttinen 2000, 148) 4 At the same time, TC MSG (Technical Committee Mobile Standards Group) was formed as the successor body to TC SMG. The former is responsible for formulating the future GSM standards and 3GPP deliverables for regulatory use. (Guitterez, 2000)


19

transposed by relevant standardization bodies – including ARIB (Association of Radio Industries and Businesses) and TTC (Telecommunications Technology Committee) in Japan; CWTS (China Wireless Telecommunications Standard group); T1 in the US; TTA (Telecommunications Technology Association) in Korea; and ETSI – into effective standards. (3GPP 1998, 5; Penttinen 2000, 19) 3GPP has also specified GPRS, the most important evolutionary step of GSM toward UMTS. GPRS introduces packet switching into GSM CN (Core Network) and allows direct access to PDNs (Packet Data Networks). This enables high-data rate packet switched transmissions well beyond the 64 kbps limit of the former GSM signaling network, thus making GPRS a prerequisite for UMTS introduction. (IEC B, 8) Despite this, the practical transmission rates will remain at 43 kbps (Müller-Veerse 1999, 13). As depicted in Figure 3 (next page), several new network elements – and their associated interfaces are introduced in the GPRS network as compared to GSM5. The Serving GPRS Support Node (SGSN) keeps track of the individual MSs’ location and performs security functions and access control. The Gateway GSN (GGSN) provides interworking with external packet-switched networks, and is connected with SGSNs via an IP-based GPRS backbone network. The HLR is enhanced with GPRS subscriber information (GPRS Register) (GPRS 03.60 2001, 13) and the BTS’s with a PCU (Packet Control Unit). In addition, a BG (Border Gateway) is used to route traffic securely to the Inter PLMN GPRS backbone. GPRS enables all packet switched applications (e.g. World Wide Web - WWW) (Penttinen 2000, 164-165; 181) that require 9150 kbps to operate smoothly (GPRS 03.60 2001, 13). As of 2001, the GPRS networks are available but there are very few terminals supporting them (Koskinen 2001, 8). As the next step in GSM evolution there will be a new modulation method in the radio interface, raising theoretical data speeds up to 384 kbps. This functionality is the first phase of EDGE, and it will primarily enhance

5

Note that for the purposes of presentation, some network elements have been omitted (EIR, GCR, another VLR, GMSC, AuC, OMC), and others moved (MSC)

20

Chapter 2

HSCSD and GPRS – therefore the names E-HSD (Enhanced High Speed Data) and E-GPRS (Enhanced GPRS). (Penttinen 2000, 282) In its second phase, through the introduction of a GSM/EDGE Radio Access Network (GERAN), EDGE will evolve further into being capable of supporting realtime packet data and thereby the full range of 3G services (Eriksson et.al. 2000, 902). EDGE could be the highest stage of GSM evolution for those operators that have not received UMTS licences, necessitating changes in their existing network elements and terminals. Other operators might be encouraged to move directly to UMTS (Koskinen 2001, 11), whose logical network architecture is depicted in Figure 4 (next page). Notice on the user’s side that UMTS introduces the User Equipment (UE) as a counterpart to the GSM MS (IEC B, 12) and on the network side that UMTS builds on GPRS CN, and that the GSM BSSs’ can be used aside the new UTRAN (UMTS Terrestial Radio Access Network) (Penttinen 2000, 288). UTRAN is subdivided into individual RNSs (Radio Network Systems), each controlled by an RNC (Radio Network Controller) that is connected to a set of Node B elements serving one or several cells (IEC B, 9). The UMTS radio network


21

consists of two components that are allocated their own radio frequency bands. First, the FDD (Frequency Division Duplex) component will be implemented through a Wideband Code Division Multiple Access (WCDMA) technology. Second, the TDD (Time Division Duplex) component will be implemented through the Time Division TDMA (TDTDMA) technology, which is a combination of TDMA and CDMA technologies. (Penttinen 2000, 287-288) Naturally, an UMTS network might also include a GERAN component in addition to older GSM based radio network systems and UTRAN (although not depicted in Figure 4). The realistic transmission speed of the UMTS network should be 384 kbps, and first such networks are anticipated in 2003 (Müller-Veerse 1999, 13).

4.

THE GSM LOCATION SERVICES FRAMEWORK

The Standards T1P1.5 group from the Standards Committee T1 in the US developed the ETSI proposals for the Location Services (LCS) framework. These proposals are now included in Releases 1998 and 1999 for GSM and

22

Chapter 2

Release 4 for GPRS and UMTS. (Baumann et.al. 2001, 99-107; Kilpeläinen 2001) Figure 5 (next page) depicts the generic LCS logical architecture in a

GSM network. Notice that the following network elements have been added, as compared to the standard GSM network (refer to Figure 2 in page 15). The LCS client is a logical functional entity within or outside the PLMN (including in the MS). It first requests location information for one or more target MS’s within a specified set of parameters such as Quality of Service (QoS) and then receives a response, which contains either the requested information or a failure indication. To do this, an external LCS client contacts the Gateway Mobile Location Center (GMLC). The latter requests routing information from the HLR; performs registration and authorization; and sends positioning requests to and receives final location estimates from the MSC/VLR. The Serving Mobile Location Center (SMLC) manages the overall coordination and scheduling of resources required to perform


23

positioning; calculates the final location estimate and accuracy; and uses the Cell Broadcast Center (CBC) to broadcast positioning assistance data to MS’s. Finally, a Location Measurement Unit (LMU) makes measurements to support one or more positioning methods. These measurements include location measurements specific to one MS and assistance measurements specific to all MS’s in a geographical area. They are all supplied to an SMLC that also gives instructions regarding their timing, nature and periodicity. The LMU can be accessed through the air interface (LMU Type A) or the Abis interface (LMU Type B). (GSM 03.71 2001, 15-16, 20-22) The same network elements are also introduced in the GPRS network, with very few changes to the existing GPRS specifications (compare Figure 6 below to Figure 3 in page 20). The same applies to UMTS (compare Figure 7 in the next page to Figure 4 in page 21).

24

Chapter 2

If one had been precise above when talking about requests and responses, one would have said that the LCS client sends a Location Services Request to the LCS server. The LCS server is a logical functional entity that accepts requests, services them, and sends back Location Services Responses. It consists of LCS components that in turn comprise a number of functions, which are distributed to network elements in one or more PLMNs and/or service providers. (UMTS 23.271 2001, 10) The allocation of these functions to various network elements is depicted in Table 1 (next page) – for conciseness, it is assumed here that the component/function names give the reader enough advice about their purpose and functionality.


25

Chapter 2

26

5.

MOBILE POSITIONING METHODS

Wide area mobile positioning technologies can be categorized to four groups, according to where the position calculation is conducted. In 1) pure network-based methods, it is done in the PLMN and in 2) pure MS-based methods, in the MS. In 3) MS-assisted network-based methods, the MS sends assistance data to the network where the position is calculated; and in 4) MS-based network-assisted methods the opposite happens. (Kilpeläinen 2001; Syrjärinne 2001, 26) This section will present those methods that have been standardised for major cellular systems. For each system, Table 2 (next page) categorizes these techniques into three groups. Categories 1 and 2 are cellular system specific – the former guarantees a basic service level to all (including legacy) handsets and the latter an enhanced service level for all new handsets with reasonable cost. Category 3 is common to all systems, providing an enhanced service level to all new handsets with higher cost. (NOKIA 2001,8).


5.1

27

Cell Identity

The simplest of pure network-based positioning methods is Cell Identity where location is determined based on the ID of the current cell. Naturally, accuracy is dependent on the size of that cell, ranging from few tens of meters (micro- or picocells) to as much as 35 km or more (macrocells and extended cells). Cell Identity positioning accuracy can be improved by utilizing the so called Round Trip Delay (RTD) measurement. RTD measurements form a circle around the base station where the radius corresponds to the measurement delay. As depicted in Figure 8 (next page), this circle together with Cell Identity can be used to narrow down the possible location of the MS. In GSM, RTD is called Timing Advance (TA)

and in 3G systems it is called Round Trip Time (RTT). (Syrjärinne 2001, 3233) To change transmission timing to correspond the respective distance, the MS measures the TA to the serving BTS during handover procedure and during dedicated modes (e.g. call connection or in-call). It also sends this value to the serving BSC. The GSM TA value is quantified into 64 levels, 6

Also called as Cell Coverage or Cell of Origin (COO) or Cell Global Identity (CGI)

28

Chapter 2

each corresponding to (~550 m), resulting in a rather crude resolution. (Syrjärinne 2001, 32-33; Penttinen 2000, 88-90, 216) Thus for cells with less than 550 m radius, there is no improvement in the accuracy due to the TA parameter (Collomb et. al. 2001, 49). To obtain TA values in case the MS is in idle mode a special call, not noticed by the GSM subscriber (no ringing tone), is set up, and the TA is returned along with the Cell Identity of the serving cell. In GSM LCS, CI+TA has been standardized to assist all positioning mechanisms and as a fallback procedure. (GSM 03.71 2001, 13) But surprisingly, it is the non-standardized Cell Identity based solutions that have been chosen by many operators to start implementing commercial location based services. First, in a SIM (Subscriber Identity Module) Application Toolkit based method, a new SIM card is placed into a legacy mobile phone. The card holds a script that extracts desired measurement data and sends it to the network using SMS. This data may include e.g. CI, TA and/or measured signal strength (Rx) levels. (Collomb et. al. 2001, 53) An Rx level corresponds roughly to the distance between the MS and the base station; thus, position estimation is again based on the principle depicted in Figure 8. To control the transmission power, the MS automatically measures Rx levels from each nearby BTS. It also reports these values to the PLMN. (Syrjärinne 2001, 2931) Second, during the WAP (Wireless Application Protocol) call set up the appropriate Cell Identity can be forwarded to the WAP Gateway and thus to the WAP database, where it will be available for immediate or later use. Third, the Cell Identity can also be requested from the VLR via an Intelligent Network (IN) service. (Baumann et. al. 2001, 74-76) In the standardized UMTS LCS framework, the LCS requests are forwarded to the SRNC that knows the target Cell Identity. If the target UE is in a state where the Cell Identity is not directly available, it is paged to determine the appropriate cell. For an improved accuracy, the SRNC may then also request RTT (FDD only) or Rx Timing Deviation (TDD only) measurements from the Node B or LMU associated with the Cell Identity. Before being sent from UTRAN to CN, the positioning results are mapped to geographical coordinates or a Service Area Identifier (SAI), which can include one or several cells. (UMTS 25.305 2001, 25-27)

5.2

Time of Arrival and Time Difference of Arrival

In addition to Cell Identity, the standardized GSM LCS framework includes another pure network-based positioning method in Category 1, namely the uplink7 Time of Arrival (TOA). This technique is based on measuring the 7

Uplink = transmission is directed from the MS to the BTS.


29

Time of Arrival of a known signal sent from the MS and received at three or more LMUs. The signal is a series of access bursts generated by forcing the MS to perform an asynchronous handover (which is intended to fail). (GSM 03.71 2001, 99; Baumann et. al. 2001, 76-77) In a synchronous network (e.g. CDMA in the US), it would then be possible to calculate the position of the mobile terminal, knowing when the MS transmitted the signal and remembering the principle depicted in Figure 8 (note that the radii of the circles equal the propagation time of the signal multiplied by the speed of light). But in GSM (and as will be seen, in the forthcoming 3G networks), the method is complicated by the fact that the network is asynchronous, meaning that there is no common reference time and the exact time of transmission is not known at the base station end. Thus, the LMUs need to be brought to the common reference time by first measuring the Real Time Differences (RTDs) between them, and then tying them to the selected reference LMU or time. The clock bias between the network and a phone due to the unknown time of transmission can then be removed algebraically, provided that the geographical coordinates of the measurement units are known8. By this doing, the TOA positioning in fact converts into Time Difference of Arrival (TDOA) positioning9. As illustrated in Figure 9 (next

8

Syrjärinne (2001, 35-36) provides the following two dimensional algebraic example. Consider

where defines the distance between the MS and is the measured TOA at the ith base station, is the estimated time of transmission, is the location of the ith LMU, c is the speed of light, is the clock bias between the MS and the base stations and is the unknown location of the terminal. Subtracting the first TOA measurement from the second and the third measurements, respectively, yields

9

where is the difference of the distances between the ith and they jth LMU. According to Syrjärinne (2001, 36), the distance differences – i.e. the equations in (2) correspond to the time differences (TDOA) as

30

Chapter 2

page), TDOA measurements form hyperbolas, which intersect each other at the receiver’s position. At least two hyperbolas (three TOA measurements) are needed for an intersection, but for an unambiguous solution three hyperbolas (four TOA measurements) are required. (Syrjärinne 2001, 34-36) It is the SMLC that decides how many LMU’s will be utilized to provide these measurements. The SMLC does this on the basis of the desired accuracy level indicated in the LCS request. It then collects the measured TOA values together with their accuracy parameters from the participating LMU’s, produces a position estimate using the logic described above, and delivers it together with an uncertainty estimate to the requesting application. (GSM 03.71 2001,99)

5.3

Enhanced Observed Time Difference

Enhanced Observed Time Difference (E-OTD) is a TDOA-based technique that can be implemented as either MS-assisted network-based or


31

as a pure MS-based method. It has been standardized in the GSM LCS and in the EDGE/UMTS LCS for GERAN. (GSM 03.71 2001, 12-13, 100-102; UMTS 23.271 2001, 15) The former framework distinguishes between hyperbolic and circular types of the method. First, the hyperbolic type is associated with three basic timing quantities. 1) The Observed Time Difference (OTD) is the time measured by the MS between the reception of the burst signals from two different BTS’s. Thus, if a burst is received from BTS1 at time and from BTS2 at time then 2) The Real Time Difference (RTD) is the relative synchronization difference in the network between two BTS’s. Thus, if BTS1 sends a burst at time and BTS2 at time then 3) The Geometric Time Difference (GTD) is a quantity related to the positions of the MS and the BTS’s. If the length of the propagation path between BTS1 and the MS is and the length of the path between BTS2 and the MS is then where v is the speed of radio waves. These timing quantities are related by

Now this reduces to which is represented in Figure 9 (previous page) as the bolded portion of the propagation path from the BTS’s to the hyperbolas, whose intersection forms the location of the MS (note that instead of LMU’s in TOA, the hyperbolas are now formed on the basis of BTS’s). Second, the circular type of E-OTD is associated with five quantities. The Observed Time 1) at the MS (MOT) and 2) at the LMU (LOT) are the times at which a signal arrives from the BTS, as measured by the MS and the LMU, respectively. In addition, there are 3) a timing offset between the MS’s and the LMU’s internal clock and the geometrical distances 4) from MS to BTS (DMB) and 5) from LMU to BTS (DLB). These quantities are related by

where v is again the speed of the signals. There will be one equation of the form (5) for each BTS, and thus the unknown quantities can be solved if measures applicable to at least three BTS’s are obtained. The position of the MS is then defined by the intersection of the circles centered at these BTS’s (refer to Figure 8, page 27). Whatever the type of E-OTD is implemented, it is expected to require an LMU to BTS ratio between 1:3 and 1:5. (GSM 03.71 2001, 100-102) In the hyperbolic type, these LMU’s are needed to measure the RTD values. These values are maintained in the SMLC, which also calculates the requested position in the MS-assisted network-based case of both types. (Syrjärinne 2001, 37-38) In the MS-based network-assisted E-

32

Chapter 2

OTD, the SMLC may use the CBC to broadcast the RTD values, the BTS coordinates and other information simplifying the measurements to the subscribed MS’s in a partially ciphered message of less than 82 octets length. With this assistance data, an MS is able to calculate its position also in an idle mode. This enables a very high frequency of positioning needed in certain applications. An MS in a dedicated mode may also request assistance data via point-to-point messaging. (GSM 03.71 2001, 83-88; GSM 04.35 2001, 27)

5.4

Observed Time Difference of Arrival with Idle Periods in the Downlink

Observed Time Difference of Arrival with Idle Periods in the Downlink (OTDOA-IPDL) is again a TDOA-based technique that can be implemented as either UE-assisted network-based or as a UE-based network-assisted method. It has been standardized in the UMTS LCS for UTRAN (UMTS 25.305 2001, 11), and its functionality is in fact very close to that of the EOTD method standardized for the EDGE/UMTS GERAN. Compared to that technique, the fact that UTRAN is CDMA based causes a potential interference problem since the weak signals (i.e. bursts in E-OTD) coming from the distant Node B’s cannot be heard by the UE because of the strong signal coming from the serving Node B. Therefore, in OTDOA-IPDL, the TDOA measurements (i.e. OTD in the previous paragraph) are taken during an idle period in the downlink, i.e. when the serving Node B turns off its transmission and allows the mobile stations in its cell to hear distant base stations. (Syrjärinne 2001, 39; Porcino 2001, 223) In the UE-assisted network-based mode, these measurements are sent to the network, where the serving NRC carries out the position calculation. In the UE-based networkassisted method, the UE calculates its position based on these measurements and the assistance data (e.g. position of the measured Node B’s) that is broadcasted to it from the network. (UMTS 25.305, 30)

5.5

Advanced Forward Link Trilateration

Advanced Forward Link Trilateration (AFLT) is a positioning method aimed for the US CDMA system. It can be used in either MS-assisted network-based or MS-based network-assisted mode. The basic principle of AFLT is again the same as that of E-OTD; the differences are in TOA measuring and in the fact that the network is already synchronized. However, compared to the OTDOA-IPDL method outlined in the previous paragraph, this method suffers very much from the interference problem


33

since it was not taken into account in the network’s design phase. Partly due to this reason, AFLT is still in its research phase. (Syrjärinne 2001, 38-39)

5.6

(Assisted) Global Positioning System

There is a variety of radio beacon based systems dedicated solely for navigational purposes that could be used in cellular systems (see Table 3 in the next page). Farrell & Barth (1999, 16-17) advocate the use of space based systems over ground based ones, because they enable higher accuracies stemming from higher frequencies without sacrificing global range that can be achieved with a constellation of space based transmitters. In Table 3, the Transit system is the United States’ oldest family of radionavigation satellites and it is in the process of being phased out. (Farrell & Barth 1999, 16-17) The Russian Glonass system has suffered economic difficulties that have led to the degradation of the space fleet and thus also the positioning service (Syrjärinne 2001, 19). For global cellular positioning, the only feasible space based navigation system is thus the Navstar Global Positioning Systems (GPS), operated by the US Air Force under the US Department of Defence control. Naturally, other space based radio navigation systems have also been planned, but not deployed. First, EGNOS (available from 2004) should augment the GPS and GLONASS with integrity information, making it suitable for safety critical applications. Second, Galileo (operational from 2008) is an independent, global, European-controlled system (i.e. Europe’s response to GPS). (Baumann et.al. 2001, 88)

The Navstar GPS uses a constellation of 26 satellites (Baumann et.al 2001, 83) that orbit the earth so that a user located anywhere on the globe has a direct line of sight to at least four satellites at any time. Using CDMA

34

Chapter 2

to separate transmissions from those of other satellites, each satellite transmits on two carrier frequencies (L1 and L2) that are modulated by three pseudorandom noise (PRN) ranging codes. First, the coarse/acquisition (C/A) code modulates the L1 carrier with a period of 1 ms. It is different for each satellite and makes the GPS receivers able to lock on to a particular satellite. Second, the precise (P) code modulates both carrier frequencies with a period of one week and in practice, is accessible only for authorized (US military) users that have cryptographic keys to the encrypted Y(P) code. In theory, the GPS receiver can deduce the time required for the signal to propagate from the satellite to the receiver by using the TOA of the transmission (measured by the receiver’s clock) and information contained in either P or C/A code (resulting in better or worse precision, respectively). Multiplying this time with the propagation speed (i.e. the speed of light) would result in the propagation distance that, if the satellite locations were known, would define a sphere of possible receiver locations. The intersection of two such spheres would define a circle of possible locations, and the intersection of three spheres would define two possible locations. With either a prior estimate of the receiver location or another range estimate, a single receiver position estimate would result. But in practice, the propagation distance measurements are biased by e.g. the receiver and the satellite clock errors and therefore they are called pseudoranges. All these errors can be reduced with (and the satellite coordinates can be computed through the use of) information contained in the third PRN code – the navigation message – except for the receiver clock offset from the standard GPS time. Fortunately all simultaneous pseuderange measurements are biased by the same clock error, which in the search for a unique positioning solution can be accounted for by adding a fourth range measurement10. 10

Let the receiver clock offset from the satellite system time be denoted as and the receiver earth-centered earth-fixed (ECEF) coordinates as (x, y, z). These four unknown quantities can be determined from the following equations for the measured pseudoranges representing four different satellites:

where are the ECEF position coordinates of satellite i, is the clock bias of the satellite, is the atmospheric delay, represents the deliberate corruption of the satellite signals under the policy of selective availability, represents error in the broadcast ephemeris data, represents multipath error, represents


35

(Farrell & Barth 1999, 142-144) The errors can be essentially eliminated through the use Differential GPS (DGPS) by acknowledging that a second GPS receiver in a fairly close proximity (i.e. within 10 km) to the first will experience basically the same error effects when viewing the same reference satellites. If this second receiver is fixed at a precise location, its calculated GPS location can be compared to its known position to generate a composite error vector that can be passed to the first (mobile) receiver to null out the unwanted effects. (Borenstein et.al. 1996, 75) In an Assisted GPS (A-GPS) solution - standardized for GSM LCS, its successors and most other 3G systems - the cellular network can be used to deliver these differential corrections to the mobile. In addition, approximate handset location and other assistance data is sent to the MS to reduce its sensor start-up time, increase its sensor sensitivity and to make it consume less power than standalone GPS receivers. In an MS-assisted network-based A-GPS solution, majority of the traditional GPS receiver functions are shifted to the network and only a very short, partially ciphered assistance message is sent to the MS. This message, consisting of e.g. GPS time, visible satellite list, and code phase search windows, is valid only for a few minutes and enables the MS to calculate its pseudoranges to the satellites. These ranges are returned to the network, where the location is first solved from (6) and then, if desired, finalized by applying the differential corrections. In an MS-based networkassisted A-GPS solution, in the start-up phase durable (valid for four hours) data is first broadcasted to the MS in partially ciphered messages. This data includes e.g. the GPS time, reference location, satellite ephemeris (i.e. precise orbital parameters of the satellites) and clock corrections. Assisted by this data, the GPS receiver in the MS then makes the measurements for pseudorange calculations, uses (6) to solve for its location, and if desired, applies the differential corrections (which are broadcasted to the MS frequently, i.e. every 30 seconds). (GSM 03.71 2001, 103-106)

5.7

Comparison of the Positioning Methods

All the positioning methods presented in this chapter can be evaluated on the basis of accuracy, reliability, availability, latency and feasibility. Accuracy and availability for each method is depicted in Figure 10 below, and reliability, latency and feasibility in Table 4 (next page). Factors

receiver tracking error noise, and c is the speed of light. Under the policy of selective availability, satellite clock and ephemeris data available to nonauthorized users were corrupted. Authorized (US military) user receivers had the ability to access the Y(P) code and remove the effects of the AS. (Farrell & Barth 1999, 144-145) According to Syrjärinne (2001, 24), SA became uneffective in May 2000.

36

Chapter 2

affecting availability include channel capacity, cell coverage, base station geometry and sensitivity in the signal propagation environment (including

underground, indoor, urban/city, suburban, rural or remote environment). Latency measures the time passed from the time of power-up to the instant when the first location measurement is obtained. In GPS, this is also known as time-to-first-fix (TTFF). Note that the usability of many applications


37

decreases if the vendor cannot guarantee real-time operation. On the basis of many technical and commercial factors, it is also possible to draw conclusions on the feasibility of these technologies. The factors that affect feasibility11 include power consumption, hardware size, software size, processing load, supported positioning modes, network dependency, signaling load, cost and standardization maturity. (Syrjärinne 2001, 7-18, 46) From the commercial standpoint, the pure Cell Identity method should be widely available in the GSM networks from mid-2002 onwards since making appropriate network modifications takes 12-18 months. CI+TA, enhanced optionally with Rx level measurements, will take more time (probably 18-24 months) and be available in large scale in 2003. New network elements to support E-OTD are estimated to be on sale in summer 2002, and terminals in the beginning of 2003. The deployment by the operators will take an additional 12-18 months for limited coverage and 2436 months for full service coverage, leading to commercial implementations as late as 2003-2005. New network elements supporting A-GPS could be available in mid-2002, and new terminals in 2003-2005. A-GPS network deployment will take an additional 12-18 months for a limited coverage and 24-36 months for full service coverage, leading to commercial implementations in 2003-2005. (Collomb et. al. 2001, 95-96) Due to its impact on the network and thus the high cost (Baumann et. al. 2001, 77, 143), the TOA/TDOA method will probably not be implemented at all by the telecom operators. Finally, the OTDOA-IPDL could be implemented at earliest after the first installations of the UMTS UTRAN in 2003.

6.

GEOGRAPHICAL AREA DESCRIPTION

In GSM and its successors, the geographical reference system chosen for the coding of the locations is the World Geodetic System 1984 (WGS 84). As depicted in Figure 11 below, the WGS 84 ellipsoid is constructed by the rotation of an ellipse around the minor axis (shorter than the major axis) oriented in the North-South direction. The rotation axis is the polar axis of the ellipsoid, and the plane orthogonal to it and including the center of symmetry is the Earth equatorial plane. Co-ordinates are expressed in terms of longitude and latitude. The former runs from –180° to +180°, where 0° corresponds to the Greenwhich Meridian, and the positive angles are to the East while the negative angles are to the West. The latter runs from –90° to +90°, where 0° corresponds to the equator, and positive angles are to the North and negative to the South. Altitudes are defined as the distance 11

Originally called by Syrjärinne as “applicability”

38

Chapter 2

between the surface of the ellipsoid and the point, along a line orthogonal to the surface. The shapes included into the GSM/UMTS Geographical Area Description (GAD) framework include 1) an ellipsoid point (depicted in Figure 11), 2) an ellipsoid point with an uncertainty circle, 3) an ellipsoid point with an uncertainty ellipse, 4) an ellipsoid point with altitude, 5) an ellipsoid point with altitude and an uncertainty ellipsoid, 6) a polygon and 7) an ellipsoid arc. The application developer chooses one of these shapes to

describe the geographical area. Each shape is encoded into a bit string in a slightly different way – for example, Figure 12 below shows the bit encoding of an ellipsoid point.


39

Any target entity on or close to the surface of the WGS 84 ellipsoid may also be subject to a Velocity Description. As depicted in Figure 13 below, horizontal velocity is characterized by the speed magnitude and bearing (taken clockwise from North). Vertical velocity gives only the magnitude of the speed component in the vertical direction. Depending on the needs of the application, velocity can be described in a standardized bit string as 1) horizontal velocity, 2) horizontal velocity with uncertainty, 3) horizontal and vertical velocity and 4) horizontal and vertical velocity with uncertainty. (UMTS 23.032 2001, 6-22)

7.

POSITIONING PROCEDURES IN THE LOCATION SERVICES FRAMEWORK

Now that the LCS framework, the positioning methods and the method to describe the position estimate have been adequately discussed, the network

40

Chapter 2

positioning procedures can be elaborated in more detail. They will be illustrated by presenting the Mobile Originating, Mobile Terminating, Mobile Terminating Deferred and Network Induced Location Requests in the UMTS packet switched domain. This will be enough to give the reader an idea of the positioning procedures in general and enable him/her to make inferences of those procedures in other contexts. The procedures all have three main parts. First, the Location Preparation Procedure is concerned with verifying the privacy restrictions of the UE subscriber, reserving network resources, communicating with the UE to be located and determining the positioning method to be used for locating the UE subscriber based on the requested QoS and the UE and network capabilities. Second, the Positioning Measurement Establishment Procedure is concerned with performing positioning measurements. Third, the Location Calculation and Release Procedure is initiated after the measurements are completed and is concerned with the location calculation and releasing all resources used for positioning. (UMTS 23.271 2001b, 32)

7.1

Mobile Originating Location Request (MO-LR)

The following procedure (depicted in Figure 14, next page) allows an UE to request its own location, location assistance data or broadcast assistance data message ciphering keys from the network. It may also enable the UE to request that its own location be sent to another LCS client. In the Location Preparation Procedure, if in the idle mode, the UE first requests a packet switched signaling connection from the SGSN. (UMTS 23.271 2001b, 49) After this, the SGSN may perform authentication and other security functions (UMTS 23.271 2001b, 49; UMTS 23.060 2001, 91). The UE then sends the SGSN a message that specifies the type of location service that it wants – i.e. its own location, its own location send to another LCS client, assistance data or ciphering keys. The message also includes the information needed to deliver this service – e.g. QoS parameters, the identity of the other LCS client and the address of the respective GMLC, the type of assistance data or deciphering keys and the specification of the positioning method to be used. If allowed by the subscription profile of the UE, the SGSN then sends a Location Request message to the SRNC associated with the UE. The message indicates whether a location estimate or location assistance data is needed, and delivers information for SRNC to be able to deliver this service.


41

If the assistance data is needed, this is delivered to the UE, but otherwise the Positioning Measurement Establishment Procedure is begun. (UMTS 23.271 2001b, 49-50) It will here be illustrated for the case of the Cell Identity based method. In a mobile originating location request, the Cell Identity is readily available to the SRNC, and thus the UE need not be paged to obtain it. But in order to increase the positioning accuracy the SRNC may request RTT (FDD only) or RX Timing Deviation (TDD only) measurements from the Node B or LMU associated with the Cell Identity. The SRNC may also map the Cell Identity to the corresponding service area identified by the SAI. (UMTS 25.305 2001, 25-26) When a location estimate has been obtained or when the requested location assistance data has been delivered to the UE, the Location Calculation and Release Procedure is begun. First, a location response is returned to the SGSN, indicating the location estimate, ciphering keys or a failure cause. Then, if the UE requested transfer of its location information to another LCS client, this is sent via the respective GMLC.

42

Chapter 2

Finally, the UE is sent a message carrying either an estimate of its location, a confirmation that this estimate has been delivered forward, or the deciphering keys. (UMTS 23.271 2001b, 50)

7.2

Mobile Terminating Location Request (MT-LR)

As depicted in Figure 15 (next page), in MT-LR an external LCS client requests the UE location from the GMLC, which authenticates the client, checks its authorization, and derives the identity of the UE and the relevant QoS level either from the client subscription data or from the request. The client may also request a periodic location or location of more than one UE, in which case the steps described here are repeated. If the GMLC does not know the SGSN address applicable to the particular UE, it requests this from the HLR/HSS – which verifies the authorization of the GMLC. The GMLC then sends the SGSN a message carrying more specific information about the request (e.g. requested QoS etc). The SGSN verifies that a location request is allowed from this GMLC, its PLMN and its country, and that the UE’s barring restrictions allow replying to this request (unless the request has an override capacity). If yes, the UE is paged if it is in the idle mode, and the security procedures may be executed. If the location request comes from a value added LCS client, the UE may be notified of this request if demanded by the UE subscription profile. The final location estimate can only be delivered to the requesting client if the user then grants permission for positioning (or if the notification was not sent in the first place). (UMTS 23.271 2001b, 33-34, 41-43) The Positioning Measurement Establishment Procedure is illustrated here for the case of OTDOA based positioning. First, the SRNC requests from the UE the measurements of the OTDOA for the signals in the active and neighborhood cells, and the UE Rx-Tx timing difference information (FDD only) – if considered advantageous. The SRNC, after getting this information, decides whether more is needed, and if necessary, requests the RTT (in FDD) or the Rx timing deviation (in TDD) for the UE from the serving Node B, as well as the RTD values (in FDD) from the associated database. The Node B returns the requested measurements, and the SRNC performs the position calculation using all the information it has gathered. Before passing the position estimate to the SGSN along with its time of day and accuracy, the SRNC may transform it to the co-ordinate system requested by the application. (UMTS 25.305 2001, 32-33) But of course, despite all efforts, no location estimate may be obtained, in which case the Location Report message contains a failure cause and the SGSN may return the last known UE location to the GMLC. If there is an estimate, this is returned to the GMLC (if allowed by the user and his/her barring list) – otherwise an error report is delivered. The GMLC then


43

passes this estimate – possibly after transforming it into some local geographic format – to the requesting LCS client. In the procedure, both SGSN and GMLC may have recorded appropriate billing information. (UMTS 23.271 200lb, 43)

44

7.3

Chapter 2

Mobile Terminating Deferred Location Request (Deferred MT-LR)

In the Deferred MT-LR (Figure 16 below), the Deferred Location Request is delivered to the SGSN, including the event that shall trigger the sending of the Location Report. If the SGSN cannot support the request (e.g. for privacy reasons), an error report is returned to the GMLC. If the request can be supported, the GMLC is notified of this (without sending any location estimates yet). The SGSN verifies if the requested event has already been satisfied or if it can immediately be satisfied. If not, the SGSN waits until the event is triggered – or until the UE moves to some other SGSN’s area, in which case the GMLC starts over with this SGSN. When the event becomes satisfied, the SGSN proceeds in the manner explained in the previous


45

section, and eventually, the Positioning Measurement Establishment Procedure is begun. (UMTS 23.271 2001b, 44-45) It will this time be illustrated for the case of Assisted GPS based positioning. The UE first receives certain assistance data from the SRNC. In the UE-based networkassisted method, the UE then calculates its position and returns it to the SRNC together with the measurement time and an accuracy estimate. In the UE-assisted network based method, the SRNC may have requested for the LMU update (of the time difference between the GPS and the Node B) and the RTT measurements (from the Node Bs in the active set) prior to sending the assistance data to the UE. The UE then returns the satellite pseudoranges and other needed data to the SRNC, which calculates the UE position, and passes it to the SGSN. (UMTS 25.305 2001, 38-89) After this (or when the timer expires), a Subscriber Location Report is returned to the GMLC together with an indication that this is a response to a deferred location request (and if appropriate, an error cause). The GMLC then returns the LCS Response to the LCS Client as with the ordinary MT-LR. (UMTS 23.271 2001b, 45-46)

7.4

Network Induced Location Request (NI-LR)

NI-LR may be used e.g. for the positioning of emergency calls. To get an idea of this procedure, disregard steps 1-7 in Figure 16 and consider only steps 8 – 14 in the Deferred MT-LR procedure. (UMTS 23.271 2001b, 4344)

8.

SUMMARY

Cellular networks can be divided into first, second and third generation. The most successful mobile standard is GSM, which will evolve via GPRS and EDGE into UMTS. The GSM LCS framework is a distributed positioning architecture whose two logical components are the LCS Client (external to the PLMN or within MS) and the LCS Server (within PLMN). The latter adds a GMLC, an SMLC and an LMU into the existing architecture of GSM or its successors. The positioning methods included in the various cellular standards are CI+RTD (TA or RTT), TOA/TDOA, EOTD, OTDOA-IPDL, AFLT and A-GPS. They can be evaluated on the basis of accuracy, reliability, availability, latency and feasibility. The network positioning procedures include Mobile Originating, Mobile Terminating, Mobile Terminating Deferred and Network Induced Location Requests. In GSM and its successors, whenever an LCS Client produces an LCS Request, one of these procedures will be used to provide an LCS Response by the

46

Chapter 2

combined logical LCS server component. In the response, the location estimate is then expressed using the WGS 84 co-ordinate system as an ellipsoid point, an ellipsoid point with an uncertainty circle, an ellipsoid point with an uncertainty ellipse, an ellipsoid point with altitude, an ellipsoid point with altitude and an uncertainty ellipsoid, a polygon or an ellipsoid arc. Velocity information may also be given as horizontal velocity, horizontal velocity with uncertainty, horizontal and vertical velocity and horizontal and vertical velocity with uncertainty. Instead of this GAD format, some other local geographical reference system may also be used.

BIBLIOGRAPHIC REFERENCES, ARTICLES AND ELECTRONIC SOURCES 3GPP (1998). 3GPP Description [online]. Created December 1998 [referred to 18.7.2001]. Accessible in Powerpoint (PPT) format through: . 3GPP (2001). 2G Specifications [online]. Last review May 2001 [referred to 18.7.2001]. A description of the future of GSM 2G specifications. Accessible in HTML -format: . Adams, Robert A. (1995). Calculus–A Complete Course. Edition. Addison-Wesley Publishers Limited, Canada. Baumann, Stefan; Collomb, Frederic; Dien, Hai P; Paris, Gemma; Pilloni, Pierpoaolo; and Casal, Carlos R. (2001). Overview of Location Services [online]. Published 19.2.2001 [referred to 27.6.2001]. Deliverable 1 of the LOCUS (Location of Cellular Users for Emergency Services) project which aims at supporting the European Commission in the definition of the regulatory framework for the introduction of Enhanced Emergency Calls System. Accessible in PDF–format: Borenstein, Johann; Everett, H; and Feng, Liqiang (1996). Where am I? – Sensors and Methods for Mobile Robot Positioning. The University of Michigan, USA. Chakraborty, Shyam (1999). ”Mobile Multimedia: Concepts, Services, and Systems.” In Furht, Borko (ed), Handbook of Internet and Multimedia – Systems and Applications. A CRC Handbook Published in Cooperation with IEEE Press. CRC Press LLC, USA. Collomb, Frederic; Baumann, Stefan; Dien, Hai P; Paris, Gemma; Pilloni, Pierpoaolo; and Casal, Carlos R. (2001). Service definition for Enhanced 112 Emergency Services [online]. Published 22.6.2001 [referred to 6.7.2001]. Deliverable 2 of the LOCUS (Location of Cellular Users for Emergency Services) project which aims at supporting the European Commission in the definition of the regulatory framework for the introduction of Enhanced Emergency Calls System. Accessible in PDF –format: Eriksson, M.; Furuskar, A.; Kronestedt, F.; Lindheimer, C.; Mazur, S.; Molno, J.; and Tidestav, C. (2000) “System overview and performance evaluation of GERAN – the GSM/EDGE radio access network” IEEE Wireless Communications and Networking Conference (WCNC). Volume 2, 2000. Page(s): 902 -906 Farrell, Jay & Barth, Matthew (1999). The Global Positioning System and Inertial Navigation. Mc-Graw-Hill, USA.


47

GSM ASSOCIATION (2001). GSM mobiles reach half billion landmark [online]. Created May 2001, last updated May 2001 [referred to 27.8.2001]. A press release given by the GSM Association. Accessible in HTML -format: . Guitterez, Cesar (2000). Mobile Standards Group. Technical Committee – MSG [online]. Last update October 2000 [referred to 18.7.2001]. A description of ETSI’s TC MSG. Accessible in HTML –format: . IEC (A). Cellular Communications [online], [referred to 17.7.2001]. An IEC (International Engineering Consortium) Web ProForum Tutorial. Accessible through . IEC (B). UMTS Protocols and Protocol Testing [online], [referred to 17.7.2001]. An IEC (International Engineering Consortium) Web ProForum Tutorial. Accessible through . Judén, Juhani & Kuokkanen, Antti (2000). 1. ja 2. sukupolven matkaviestinverkot (engl. “The cellular network systems of the 1st and 2nd generation”) [online]. Published May 4th, 2000 [referred to 17.7.2001]. A paper written for an undergraduate seminar on maturing telecommunications technologies (010651000 Siirtyvä tietoliikenne, Department of Computer Sciences, Lappeenranta University of Technology). Accessible through . Kilpeläinen, Janne (2001). “The technology behind mobile location services” [online]. [referred to 6.7.2001]. Published in 3G2001, an online conference for the mobile communications industry. Accessible through . Koskinen, Pekka (2001). UMTS – Technical presentation [online]. Published March 2001 [referred to 17.7.2001]. A paper written for a postgraduate seminar on telecommunications business (Tik-109.551 Telecommunications Business Research Seminar II, Department of Computer Sciences, Helsinki University of Technology). Accessible through Larsson, Gwenn (2000). Evolving from cdmaOne to third-generation systems [online]. [referred to 27.8.2001]. In Ericsson Review No. 2, 2000. Accessible in PDF format through . Meredith, John M. (2001). ETSI SMG – Special Mobile Group [online]. Last review February 2001 [referred to 18.7.2001]. A homepage of ETSI’s TC SMG. Accessible in HTML – format: . Müller-Veerse, Falk (1999). Mobile Commerce Report [online]. Durlacher Research Ltd [referred to July 2001]. A free report on PDF format, necessitates registration. Accessible through . NOKIA (2001). Mobile Location Services [online]. Written in April 2001 [referred to 6.7.2001]. White Paper, Nokia Mobile Phones. Accessible in PDF format through Penttinen, Jyrki (2000). GSM-tekniikka - järjestelmän toiminta, palvelut ja suunnittelu (engl. ”GSM technology – The functionality, services and design of the system”). edition. Werner Söderström Osakeyhtiö (WSOY), Porvoo. Porcino, Domenico (2001). “Performance of a OTDOA-IPDL positioning receiver for 3GPPFDD mode.” Second International Conference on 3G Mobile Communication Technologies, 26-28.3.2001. IEEE Conf. Publ. No. 477, 2001. Page(s): 221 –225. Syrjärinne, Jari (2001). “Studies of Modern Techniques for Personal Positioning.” Tampere University of Technology, Publications 319.

48

Chapter 2

Taylor, Mark; Waung, William; and Banan, Mohsen (1996). Internetwork Mobility: The CDPD Approach [online]. The book was published in September, 1996 by Prentice Hall Professional Technical Reference [referred to 27.8.2001]. Accessible in HTML, PDF and PS formats through < http://www.leapforum.org/published/internetworkMobility/>. UMTS FORUM (2001). The UMTS Third Generation Market – Phase II: Structuring the Service Revenue Opportunities [online]. Published April 2001 [referred to 27.8.2001]. UMTS Forum report No. 13. Accessible in PDF format through . UTS (1997). Cellular positioning [online]. Last updated August 2001 [referred to 27.8.2001]. Homepages of the Intelligent Transportation Systems group at the Faculty of Engineering, University of Technology, Sydney. Accessible in HTML format through .

REFERRED STANDARDS GPRS 03.60 (2001). Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Service description; Stage 2 (3GPP TS 03.60 version 7.6.0 Release 1998). ETSI TS 101 344 (2001-03). GPRS 43.059 (2001). Digital cellular telecommunications system (Phase 2+); Functional stage 2 description of Location Services in GERAN (3GPP TS 43.059 version 4.0.0 Release 4). ETSI TS 143 059 v4.0.0 (2001-04). GSM 03.02 (1996). Digital cellular telecommunications system (Phase 2) (GSM); Network architecture (GSM 03.02). ETSI ETS 300 522 ed.3 (1996-11). GSM 03.71 (2001). Digital cellular telecommunications system (Phase 2+); Location Services (LCS); (Functional description) – Stage 2 (3GPP TS 03.71 version 8.1.0 Release 1999). ETSI TS 101 724 (2001-04). GSM 04.35 (2001). Digital cellular telecommunications system (Phase 2+); Location Services (LCS); Broadcast Network Assistance for Enhanced Observed Time Difference (E-OTD) and Global Positioning System (GPS) Positioning Methods (3GPP TS 04.35 version 8.3.0 Release 1999). ETSI TS 101 528 (2001-01). UMTS 22.071 (2001). Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); Location Services (LCS); Service description, Stage 1 (3GPP TS 22.071 version 4.3.0 Release 4). ETSI TS 122 071 V4.3.0 (2001-03). UMTS 23.002 (2001). Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); Network architecture (3GPP TS 23.002 version 4.3.0 Release 4). ETSI TS 123 002 V4.3.0 (2001-06). UMTS 23.060 (2001). Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); General Packet Radio Service (GPRS) Service description; Stage 2 (3GPP TS 23.060 version 4.1.0 Release 4). ETSI TS 123 060 V4.1.0 (2001-06) UMTS 23.171 (2001). Universal Mobile Telecommunications System (UMTS); Functional stage 2 description of location services in UMTS (3GPP TS 23.171 version 3.3.0 Release 1999). ETSI TS 123 171 V3.3.0 (2001-03). UMTS 23.271 (2001). Universal Mobile Telecommunications System (UMTS); Functional stage 2 description of location services (3GPP TS 23.271 version 4.1.0 Release 4). ETSI TS 123 271 V4.1.0 (2001-03).


49

UMTS 23.271 (2001b). Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); Functional stage 2 description of location services (3GPP TS 23.271 version 4.2.0 Release 4). ETSI TS 123 271 V4.2.0 (2001-06). UMTS 25.305 (2001). Universal Mobile Telecommunications System (UMTS); Stage 2 Functional Specification of UE Positioning in UTRAN (3GPP TS 25.305 version 4.0.0 Release 4). ETSI TS 125 305 V4.0.0 (2001-03).


Chapter 3 Location Service in CDMA2000 Networks

Xiaofeng Xu Alcatel USA

1.

INTRODUCTION

Code Division Multiple Access (CDMA) technology for commercial cellular network was first developed by Qualcomm in the 1980s [11]. The Telecommunication Industry Association (TIA) published the IS-95 air interface standard in 1993. The commercial CDMA service was deployed in Hong Kong during 1995, then followed by the deployment in Korea and the United States. CDMA technology offers numerous benefits to the cellular operators and their subscribers in terms of capacity increase, call quality, simplified system planning, and so on. The IS-95 standard was revised in 1995, and called IS-95A. In 1998, the standard was enhanced by the support of high speed data operation using up to eight parallel codes, and called IS95B. The CDMA cellular networks use the IS-41 standard to interconnect Mobile Switching Centers (MSC), Visited Location Register (VLR), Home Location Register (HLR) and other service elements. The IS-41 provides the similar functionality as the GSM MAP. CDMA2000 Radio Transmission Technology (RTT), as the evolution of IS-95, has been adopted by ITU as one of the IMT-2000 air interface standards for Generation (3G) mobile communication. The Generation Partnership Project 2 (3GPP2) issued the first phase of the 3G specifications in 2000 -- CDMA2000 1x which supports packet data service with speed up to 153 Kbps and 1.5 times increase of voice capacity. Figure 1 shows the simplified architecture of CDMA2000 network. For detailed architecture information please refer to [1] and [2]. In this

52

Chapter 3

architecture, IS-41 signalling plays the key role of communication to support basic tele-services and value added services. The packet core network comprising PDSN, HA and AAA offers packet service for Internet access. The radio access for both circuit service and packet service is controlled by MSC/VLR with IMSI based subscription profile downloaded from HLR. The PDSN controls PPP session with the MS and provides Simple IP and Mobile IP services with Network Access Identifier (NAI) based subscription profile from AAA servers. The location service is based on IS-41 signalling and supported by Mobile Position Center (MPC), Position Determination Entity (PDE), HLR, MSC/VLR, etc., and supports both IS-95 and CDMA2000 mobile stations.

3. Location Service in CDMA2000 Networks

53

2.

LOCATION SERVICE BASED ON IS-41 NETWORK

2.1

IS-41 Based Network Reference Model for Location Service

Figure 2 shows IS-41 based network reference model for location service provided to IS-95/CDMA2000 1x MSs. MPC and PDE are entities designated to the location service in the core network. (Source [4]) LCS Client (Location Service Client) is an entity that interacts with an MPC to obtain position information for one or more Target MSs within a set of specified parameters such as PQoS. LCS Clients subscribe to LCS in order to obtain position information for the purpose of providing location

54

Chapter 3

based applications. The LCS Client is responsible for formatting and presenting data and managing the user interface. SN (Service Node) and SCP (Service Control Point) are WIN (Wireless Intelligent Network) service entities and may support location based Intelligent Network services. HLR (Home Location Register) keeps track of the MS’s last registered MSC/VLR and/or MPC address. It may also contain the MS’s subscription information about location privacy protection. MPC (Mobile Position Centre) serves as the point of interface to the wireless network for the position determination network. The MPC serves as the entity which retrieves, forwards, stores and controls position information within the position network. It can select the PDE(s) to use in position determination and forwards the position estimate to the requesting entity (e.g. LCS Client) or stores it for subsequent retrieval. The MPC may restrict access to position information for a Target MS (e.g. release position information to authorised entities). Home MPC is associated with the Target MS subscriber’s Home System and to which MS’s user identity (e.g. directory number, MSID) is assigned for location-based services. Serving MPC is associated with the Serving MSC for the Target MS. PDE (Position Determination Entity) facilitates determination of the geographical position of a Target MS. The input to the PDE for requesting the position is a set of parameters such as PQoS requirements. Multiple PDEs may serve the coverage area of an MPC and multiple PDEs may serve the same coverage area of an MPC utilising different position determining technologies. The interface between LCS Client and MPC can be based on IS-41 signalling, but can also be other open or proprietary protocol. Some organizations are making open and standard Application Programming Interface (API). The APIs will allow the third party to develop locationbased applications. The HTTP based API implementation will ease the development and reduce cost.

2.2

Location Service Control

LCS are applicable to any Target MS that is idle or has established a call, and are subject to the location information restrictions specified by the MS subscriber. LCS can be offered without subscription to basic telecommunication services. Location Services (LCS) are available to the following categories of LCS Clients:


55

Value Added Services LCS Clients: use LCS to provide various services to MS subscribers. Wireless Service Provider LCS Clients: use LCS to support WIN (Wireless Intelligent Network) related services, bearer services, teleservices and Operations, Administration & Management. MS Originating Position: the position of the MS is transferred to another specified LCS Client at the request of the MS. LCS Client may subscribe to LCS features with the following subscription profile information: LCS Client ID: The identity of the LCS Client. LCS Client MS Barring List: The LCS Client is not permitted to obtain the position of the MSs identified in this optional list. LCS Client Target MS List: The LCS Client is only permitted to obtain the position for the MSs identified in this optional list. LCS Client Priority: The priority levels that are applicable for the LCS Client. LCS Maximum Transaction Rate: The maximum rate of position information requests applicable for the LCS Client. Response Time: The maximum time delay for obtaining the response to a position information request. The LCS Client subscription profile may contain the range of Position Quality of Service (PQoS) levels that are applicable for the LCS Client. The PQoS is a set of attributes that reflect the accuracy, response time, priority and maximum age of the position information needed for a location based service. The LCS Client specifies the minimum PQoS required for a position estimate in its request to the MPC for the Target MS’s position. The LCS Client may specify that a lower level is acceptable. The Location Information Restriction (LIR) is a feature to protect the MS’s privacy of position information. The LIR subscription information stored in home MPC or HLR specifies the restriction mode: Unconditionally Restricted Pre-Authorized LCS Clients Only Pre-Authorized LCS Clients and User Authorized LCS Clients Unrestricted. The MPC or HLR shall verify that a particular LCS Client is authorized to locate a particular Target MS.

2.3

Position Determination

The previous chapter has discussed the positioning methods used in cellular networks including CDMA. The position determination standard IS801 defines the procedures and protocols between the MS and the network

Chapter 3

56

on performing the positioning methods. The MS and the network exchanges Request and Response operation elements and parameters in Position Determination Data Messages. The messages can be sent over the CDMA Traffic Channel or the CDMA Control Channel using Layer-2 Data Burst Messages in acknowledged mode. Refer to [7] for details about the protocol.

2.4

Location Service Procedure

2.4.1

Registration Procedure

When the MS registers its presence in the visited MSC/VLR, an IS-41 message RegistrationNotification will be sent from the MSC/VLR to the MS’s HLR including parameters of MSC/VLR ID and the address of the MPC associated with the MSC. So the HLR always keeps track of the MS’s serving system address and is first interrogated by LCS Client any time when the location of the Target MS is requested. 2.4.2

Location Information Retrieval Procedure

This scenario in Figure 3 illustrates the successful position information retrieval procedure initiated by a LCS Client. 1. The LCS Client sends an InterSystemPositionRequest (ISPOSREQ) message to the Target MS’s Home MPC indicated by the mobile directory number (MDN). LCSCID parameter identifies the LCS Client. 2. The Home MPC authenticates the requesting LCS Client and verifies that the LCS Client is authorized to obtain position information for the Target MS. The MPC sends a PositionRequest (POSREQ) message to the HLR associated with the MS. 3. The HLR determines that the indicated MS is active and that the requesting LCS Client is of a valid class to obtain the MS geoposition at this time. The HLR returns a positionrequest (posreq) acknowledge message to the Home MPC with Serving MSC ID and Serving MPC ID included. 4. The Home MPC sends an ISPOSREQ message to the Serving MPC in which MS last registered. 5. The Serving MPC verifies that the request for the Target MS position has been received from an authorized entity (i.e. Home MPC). The MPC uses the indicated Position Quality of Service (PQOS) parameter to process the request and sends ISPOSREQ message to


57

the Serving MSC to obtain information on the current radio environment of the Target MS.

6. The Serving MSC includes the MobilePositionCapability (MPCAP) for the current operating mode of the Target MS, the MobileInformation (MOBINFO) parameter and the ServingCellID (SCELLID) parameter in the response to the MPC. 7. The Serving MPC selects a PDE to determine the geoposition of the Target MS based on PQOS and data received from the MSC. The MS Assisted Position Determination procedure (see Section MS Assisted Position Determination) may be carried out depending on PQOS and MS capability information. 8. The Serving MPC returns the Target MS position in the intersystempositionrequest (isposreq) acknowledge message to the Home MPC.

58

Chapter 3

9. The Home MPC returns the Target MS position to the requesting LCS Client in the isposreq message.

2.4.3

MS Assisted Position Determination Procedure


59

Depending on the position QoS parameter and MS capability, the MS Assisted Position Determination could be performed. The MS is assigned a traffic channel (if it is not currently on a traffic channel) for communication of position determination data messages between MS and PDE. The MPC communicates with the MSC via Short Message Service (SMS) protocol. The position determination data messages are formatted according to IS-801 standard ([7]) and carried as bearer data in SMS messages. The scenario is illustrated in Figure 4. 1. The Serving MPC sends a GeoPositionRequest (GPOSREQ) message to the PDE directing the PDE to determine the geoposition of the idle MS. 2. The PDE sends an SMDPP (SMSDeliveryPointtoPoint) message to the Serving MSC to initiate position determination for the indicated MS. The ACTCODE parameter is set to indicate Initiate Active Mode Position Determination – Immediate Response. The IS-801 message is included in the SMS_BearerData. 3. If the Target MS is not currently assigned to a traffic channel, the Serving MSC pages the MS and assigns it to a traffic channel. 4. The Serving MSC sends a data burst message to the MS and includes the bearer data received from the PDE. 5. The Serving MSC acknowledges receipt of the SMDPP with an smdpp message. 6. The PDE sends an SMDPP message to the Serving MSC. The ACTCODE parameter is set to indicate Active Mode Position Determination. 7. The Serving MSC sends a data burst message to the MS and includes the bearer data received from the PDE. The MSC waits for a data burst from the MS. 8. The Serving MSC receives a data burst from the MS. 9. The Serving MSC sends an smdpp to the PDE. 10. The Serving MSC receives a data burst from the MS. 11. The Serving MSC sends an SMDPP message to the PDE with ACTCODE parameter set to indicate Active Mode Position Determination. 12. The PDE sends an smdpp message to the Serving MSC in response. 13. The Serving MSC sends the message received from the PDE to the MS. 14. The Serving MSC receives a data burst from the MS. 15. The Serving MSC sends an SMDPP message to the PDE with ACTCODE parameter set to indicate Active Mode Position Determination.

60

Chapter 3 16. The PDE acknowledges receipt of the SMDPP with an smdpp message. 17. The PDE determines that position determination has been completed. The PDE sends an SMDPP message to the Serving MSC with the ACTCODE parameter set to indicate End Active Mode Position Determination – Immediate Response. 18. The Serving MSC acknowledges receipt of the SMDPPP with an smdpp message. 19. The Serving MSC releases the traffic channel. 20. The PDE sends gposreq message to the Serving MPC with PositionInformation (POSINFO) parameter included.

2.5

Application Examples

In this section we present a few examples of location based applications.

2.5.1

Find Nearest McDonald Restaurant

Figure 5 shows an example of location based Intelligent Network (IN) service. The mobile phone user wants to call to the nearest McDonald restaurant by dialling a service number advertised by McDonald (1). The MSC analyses the dialled number and detects an Intelligent Network service


61

trigger. The MSC sends a query message to the SCP for call routing instruction (2). The SCP address could be translated from the dialled service number or determined by other rules. The SCP analyses the information received from the MSC and knows this call should be routed to a service node based on the MS’s location information, in this scenario the service node is the phone number of the nearest McDonald restaurant. The SCP contacts the MPC for the calling MS’s location (3). The MPC contacts MSC for location data (4,5). Then the MPC contacts PDE to determine the geographic location information (6). The location information is sent back to the SCP (7). The SCP looks up in its database a telephone directory of McDonald restaurants organised by location with the received location information for the nearest restaurant phone number and sends a message to instruct the MSC to connect the call to this number (8). The MSC routes the call to this McDonald restaurant (9). In this scenario, the interaction messages among the MSC, SCP, MPC and PDE are IS-41 protocol based. The call routing protocol between the MSC and McDonald restaurant is the common inter-exchange protocol – ISUP. 2.5.2

Emergency Service Call

It has been mandated in some countries’ that cellular service provider shall provide location service for emergency service call. In 1998, the US Federal Communication Commission (FCC) required wireless carriers to provide to the Public Safety Answering Point the location of the cell site or base station receiving a 911 call [10]. That is called Phase I Enhanced 9-1-1 (E911). In 2001, the FCC required wireless carriers to support Phase II E911 standard [5] with more accurate location information. The location information assists in the provision of timely emergency responses. Figure shows an example of emergency service call scenario (Source: [5]). The MSC receives an emergency service call from the MS (1) and sends IS-41 Origination Request message to the MPC for geographical location information. The MPC relays the request to PDE for position determination (3). The PDE may carry out MS-assisted position determination for more precise information (4). The determined location information is returned to the MSC (5,6). The MSC routes the call to the emergency service center with location information included in ISUP IAM message.

62

Chapter 3

3.

LOCATION SERVICE IN ALL-IP NETWORK

3.1

All-IP Network Reference Model for Location Service

CDMA2000 network is evolving to All-IP architecture. The new radio interface 1xEV-DV (1x evolution data and voice) will support voice and high-speed data service. The Access Gateway (AGW) evolved from PDSN will aggregate both Internet and real-time service. The AAA (Authentication, Authorization and Accounting) replaces the legacy IS-41 as the core control protocol. Communications between any two entities are based on IP protocols. To support location services in this new architecture, 3GPP2 has defined the network reference model for location service shown in Figure 7. RAN (Radio Access Network) performs mobility management, radio resource control and provides an reliable link to deliver user data over radio channel. AGW (Access Gateway) is the aggregation point of IP traffic between radio access network and core network. It manages PPP session for each registered MS and provides Simple IP and Mobile IP services.


63

PS (Position Server) provides position information of visiting MS to request entities. It plays the same role as Serving MPC in IS-41 network. PPS (Proxy Position Server) provides gateway functionality for location services. The Home PPS plays the same role as Home MPC in IS-41 network. There may be a PPS in visited network as a gateway for applications to directly access local PSs. NCGW (Network Capability Gateway) is the gateway entity to provide access to network resources needed during service application execution. The interface towards the Application uses application programming interfaces such as Open Service Architecture (OSA). NCGW together with AAA is responsible for guaranteeing proper authorization for access to resources.

64

Chapter 3

AAA provides IP based Authentication, Authorization and Accounting. The registration of visited Position Server address with Home PPS is carried by AAA protocols.

3.2

Position Service Registration in All-IP Network

The position service registration procedure is shown in Figure 8. When the AGW chooses a Position Server to register the new MS for location service. The Visited Proxy Position Server address is returned to AGW and sent to Home Proxy Position Server via AAA network. In this example, the Position Registration with home network information is sent together with Mobile IP Registration Request.

1. MS sends Origination message to RAN for service request. The RAN may optionally perform IMSI based radio access authentication procedure.


65

2. RAN sends MS Presence to AGW. 3. AGW choose a Position Server to register the MS with Position Registration. 4. Position Server sends Position Registration to its Visited Proxy Position Server (V-PPS). 5. V-PPS sends acknowledgement. 6. Position Server sends acknowledgement with V-PPS address. 7. AGW returns acknowledgement to RAN. 8. RAN sets up an R-P connection with AGW. 9. RAN assigns traffic channel for the MS. 10. The MS establishes a PPP session with AGW. 11. AGW sends Mobile IP Agent Advertisement to the MS. 12. The MS sends Mobile IP Registration Request message to AGW. 13. The AGW sends Mobile IP Registration Request message via Local AAA to MS’s Home AAA. 14. The Home AAA retrieves Mobile’s Visited Proxy Position Server address information and sends Position Registration to Home Proxy Position Server. The Home AAA also contacts MS’s Home Agent for Mobile IP registration and updates related home database.

3.3

Location Service Scenario

An example of location service scenario in All-IP network is shown in Figure 9. Location Service Scenario in All-IP Network (Source: [6]). The location based application as a LCS Client sends Location Report Request to NCGW via OSA interface. NCGW authenticates the client and forwards the request to H-PPS. H-PPS finds out the V-PPS address registered for this Target MS and sends the request to V-PPS. V-PPS may verify via AAA network if H-PPS is authorized for position information access. PS receives the location report request from V-PPS and contacts AGW for MS status and position information data. PS may contact the Target MS if MS assisted position information is needed. PS contacts PDE for position determination and sends Location Report Result back to the requesting entity.

66

4.

Chapter 3

CONCLUSION

The location services provided or soon to be provided by IS95/ CDMA2000 1x cellular operators are based on IS-41 core protocol and can add value to legacy telecom services and emergency services. As the networks evolve toward All-IP architecture, the AAA based protocol will replace IS-41 for service registration and access control. The Open Service Architecture will further stimulate the development of location based applications.


67

References [1] 3GPP2 S.R0005 Network Reference Model for cdma2000 Spread Spectrum Systems [2] 3GPP2 N.S0005 v1.0 Cellular Radiotelecommunications Intersystem Operations [3] 3GPP2 P.S0001 Wireless IP Network Standard [4] TIA PN-4747 Rev.7 Location Services Enhancements [5] TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2 [6] 3GPP2 IP Network Architecture Model for cdma2000 Spread Spectrum Systems [7] 3GPP2 C.S0022 v1.0 / TIA IS-801 Location Services (Position Determination Service) [8] www.cdg.org [9] www.3gpp2.org [10] www.fcc.gov/e911 [11] Tero Ojanpera, Ramjee Prasad, “Wideband CDMA for Third Generation Mobile Communications”


Chapter 4 APPLICATION OF LOCATION INFORMATION TO SIP

Jose Costa-Requena Nokia Corporation

1.

INTRODUCTION

This chapter introduces the provisioning of Spatial Location information in devices connected to wire and wireless IP networks. It analyses the signaling protocol in IP-based networks and the relationship among the elements involved in the architecture. The chapter analyses all the architectures under development for providing location based Services. It includes the different consortiums that are defining the data structures, positioning mechanism and network elements to provide location information and services. The main focus of the chapter resides in the wireless and Universal Mobile Telephony System (UMTS) [1] networks in concrete. Thus SIP and its place in the actual UMTS networks is described. This chapter also includes the relationship between different approaches for providing LBS services in wireless networks such as Location Interoperability Forum (LIF) [2] and Wireless Application Protocol (WAP) [3] and the link with UMTS networks. The wireless industry has initiated, with LIF and WAP, the specification of network interfaces and infrastructure for providing LBS services in the near future. The logical evolution towards 3G networks using SIP is covered. This chapter, as a whole, provides an overview about the roadmap in LBS services over wireless networks.

Chapter 4

70

2.

THE SESSION INITIATION PROTOCOL

After the great success of Internet in the telecommunications, it was necessary to study the possibility of extending the basic Telephony service over Internet-based networks. The first initiative was promoted by the ITU trying to define a signalling protocol for multimedia communications over IP networks. Thus, the ITU-T designed the H.323 [4] recommendation, which defines a multimedia communications system over packet-switched networks, including IP networks. Afterwards, with the same initial objective appeared SIP [5], which comes from the IETF (Internet Engineering Task Force) MMUSIC working group [6]. Two standards compete for IP Telephony signalling. Comparing both signalling protocols, the ITU protocol is heavier due to the concept of legacy telecommunication networks. The other, SIP is not really intended to provide exactly the same basic telephone services as H.323. The aim of SIP is to continue the telephony service implemented over circuit-switched networks and facilitate the development of new services. SIP defines a new network architecture that is flexible enough to handle any future service. SIP moves the complexity from previous telecommunication systems located in the core of the network (e.g., in switches) out to its edge (e.g., in the terminals). SIP replaces the centralized complexity by distributed complexity. SIP is very flexible and in a short time it has the ability to adapt quickly to needs of any Service Providers to meet new customer demands. This is the main advantage compare to H.323, which follows the design of traditionally telephony networks that has limit capacity to adapt to the changes. The reason is that the old telecommunication networks were designed to move voice call efficiently in a centralised network. SIP defines a new network model that allows a service provider to implement the features supported by old networks, with more cost-effective hardware platforms with cheaper and faster access methods. SIP has also been chosen as the signalling protocol for the core network in the next generation of wireless communications. Thus, since it is used in both wire and wireless networks the communications are uniformed independently of the underneath transmission media. SIP adopted as common signalling protocol over IP networks, allows the users to have a contract with the local Internet Service Provider (ISP) or wireless provider while having the possibility to access any service implemented on any IP-based network.

4. Application of Location Information to SIP

2.1

71

The SIP Protocol

This section enlightens the reader about SIP protocol and all the entities involved in a common transaction. It goes through the basis of the protocol, the elements of the SIP architecture, the composition of the messages, and the address format used to identify the user in the SIP messages. SIP is considered an application layer signalling protocol used for creating, modifying and terminating multimedia sessions among different parties. It is used as a call control protocol in IP Telephony replacing the traditional telephone services. SIP is text-based, and uses ISO 10646 in UTF-8 encoding. It makes SIP flexible and extensible. Since it is used for initiating multimedia conferences rather than delivering data, the overhead for using text-based coding is not significant compare to the benefits. The syntax of the messages is similar to HTTP [7] while SIP can carry the transaction by using either UDP or TCP. The message can be either a request or response and follows the RFC 822 [8] format. SIP contains the main headers for establishing a multimedia transaction. The header contents can be easily extended with new features for adapting new services. SIP, by itself, only provides call control. However, SIP accepts complementary information inserted as SIP payload for other applications. SIP is able to set up a voice call carrying the information of a more detailed multimedia session using protocols as the Session Description Protocol (SDP) [9]. The message consists of a start line, one or more header fields, an empty line (Carriage-return line-feed, CRLF) and an optional body. Basically, the start line indicates if the message is a request or a response. The main requests are INVITE, ACK, OPTIONS, BYE, INFO, CANCEL, and REGISTER; while common responses are 100 Informational, 200 Success, 300 Redirection, 400 Client Error, 500 Server Error, and 600 Global Failure. The new requests that are under discussion at the IETF to be included in the standard are MESSAGE, SUBSCRIBE and NOTIFY. The message header is composed by multiple headers indicating origin ("From: "), destination ("To:"), Call Identifier ("Call-ID: "), message sequence ("Cseq: "), transaction path ("Via: "), length ("Content-Length: "), priority ("Priority: "), and content of the body if it is carried inside the message ("Content-Type: "). Finally, the message body contains any type of data, and it can be interpreted depending on the type of message. Generally,

72

Chapter 4

the content of the body presents a session description following a specific format such as the Session Description Protocol (SDP), text or XML scripts. The "Content-Type" header field tells the media type of the message body. It can be extended for indicating the type of payload that the SIP message is carrying. If the body is encoded the coding type is indicated in the "Content-Encoding" header field. The body length is given in the "Content-Length" header field. Furthermore, in case that the whole body is encrypted it would be indicated using the "Encryption" header. This header provides the scheme followed for the encryption. The entities addressed by SIP are users at hosts that are identified by a SIP URL [10]. The URL takes a form of "user@host" where the user can be a user name or a telephone number, and the host would be either a domain name or a network address. SIP URLs are used within the SIP messages to indicate the origin (From), the current destination in the start line (Request URI), and the final recipient of a SIP request (To). The understanding follows the guidelines of RFC 2396 [11], and the syntax is described using Augmented Backus-Naur [12] form, and the characters are reserved within any given URI component.

2.2

The SIP Architecture

The entities usually involved in a SIP session are the User Agent (UA), the Proxy Server, the Redirect Server, the Registrar Server, and the Location Server. The User Agent is located in the user device. The Proxy, Redirect and Registrar are network elements, interacting with the User and other network entities simultaneously. The Location Server helps the previous network elements to identify and locate the user. The UA is normally placed in the user terminal and it can act as a Client (UAC) or as a Server (UAS). The UAC initiates a SIP request while the UAS contacts the user when a SIP request is received and sends back a response on behalf of the user requirements. The Proxy Server is an intermediate entity that behaves as client and server simultaneously. It is a network element that receives the messages (requests) from the user (UA.) It can analyze and modify the request before forwarding it to other servers.


73

The Redirect Server is another network entity that receives the messages from the user and maps the address indicated by the request into zero or other addresses. Thus, the client should try again the addresses returned by the Redirect Server to contact the callee or another SIP server that can handle the message in case of special requirements. This entity is part of the mobility functionality included in the SIP architecture. The Registrar Server accepts the user registration (REGISTER message). The user information received within the SIP message at the Registrar is extracted from the SIP message and forwarded to be stored at the Location server. The Location Server (LS) is an element used by a Redirect or Proxy server to obtain user information (including Location information of the callee, etc.). The Location Server is a SIP entity allocated within the Registrar server. It is implemented like records in database where the basic information (IP address, URL, and other Contact data) of the user that has been registered under the SIP Registrar is collected. Therefore, in this paper the Location Server is improved with the storage of Spatial Location information for emergency purposes. Based on this architecture SIP supports name mapping and redirection service enabling personal mobility. Personal mobility is the end users ability to originate, receive calls, and access subscribed services on any terminal in any location. It is also considered the network facility to identify end users as they roam among network sites. Personal Mobility is based on the use of an exclusive personal identity based on the SIP URL. The SIP URL is used for finding a user based on DNS SRV lookup [13]. The client queries the DNS server that has address records of the destination address. If the DNS does not return any address record, it means that the end user cannot be reached. Other alternative protocols for locating a user are finger (RFC 1288 [14]), rwhois (RFC 2167 [15]), LDAP (RFC 1777 [16]), and other multicast based protocols available to determine whether a user is reachable. In this situation, it is possible to receive a list of network locations because the user is logged in at several hosts simultaneously. The user can have access to various devices using a telnet or any remote access protocol but his physical location is unique, and corresponds to one of the entities where he is logged in. The current SIP mechanism to contact the user is trying each of those addresses sequentially or in parallel until the user is reached. Hence, the SIP server creates multiples instances of the same message and they are sent to all the possible locations where the user is

74

Chapter 4

supposed to be. Exclusively the entity where the user is present replies with a 200 OK SIP response and the rest send a 300 USER HAS MOVED or 600 BUSY EVERYWHERE responses. Figure 1, shows an example of multiples instances of the same request trying to contact a remote user that has several possible locations where he can be logged in.

The SIP also supports terminal mobility by proxying and redirecting request to the current network location where the user is logged in. The user can register his current network location and also the service profile required for the session using SIP. In the registration process the user provides his personal identity for achieving the Personal Mobility. This feature is crucial for emergencies and other location-based services independently of the physical location of the user or his attachment point to the network. Furthermore, this aspect is essential for building a global architecture that allows the user to move among different networks independently of the network technology. Thus, the SIP server can find the user while he/she is registered in different network.


2.3

75

SIP in Wired Networks

SIP is used in wired Internet networks as signalling protocol for establishing a media session between terminals. In this case the link between terminals is reliable and it has more bandwidth capacity than in wireless links. With SIP, a session can consist of any form of communication so in wired networks it is possible to promote a session to a telephone call or even a whiteboard or video session among connected devices. It is also easy to invite other people to join a session, creating spontaneous conference calls. SIP is a lightweight client easily embedded in end-user device. Wherever there is a requirement for real-time sessions to be established, SIP can reside in the communications device and handle these sessions. Therefore, the role of SIP as signalling protocol is evident regardless it is wire or wireless networks.

2.3.1

SIP within ISP

SIP is signalling protocol used in IP networks regardless they are wired or wireless. Thus, an Internet Service Provider (ISP) that offers IP connection to the clients will provide SIP capabilities as well. The ISP will include SIP network entities where the user can access for establishing a multimedia session among other users in the network. Therefore, using SIP the ISP can build a set of supplementary services for the subscribers. Thus considering SIP as part of the ISP infrastructure that includes web servers, mail servers and others will generate a set of new services.

2.3.2

Providing Location Data in Wired Networks

It seems that providing location information does not make sense considering that the terminals are static. The fact is that some devices despite they use the wired networks as point of attachment; they are mobile in the sense that they can get temporary IP addresses (Mobile IP). Furthermore, the users on a SIP network may have a number of devices or IP addresses on the network, and proxy, redirect, and location servers provide the functionality to unite these devices for providing a single address as part of a unified communications/ messaging. Therefore, as part of the user registration it can be included the location information indicating the geographical situation of the user. This information independently whether it is coming from static or from a mobile device, binds the user to the terminal indicating the location where the user is available. This information can be used for providing a set

76

Chapter 4

of services that require the location information such as emergency. Thus, when the user logs in an IP device that provides the location information, it can be used to deploy a set of LBS.

2.4

SIP in Wireless Networks

The next generation of wireless networks UMTS [1] or well-known 3G are IP-base networks and use SIP as signalling protocol. The organisation that is defining the standards and architecture is the 3GPP [17] and it has adopted SIP as the signalling protocol in the core network.

2.4.1

UMTS Architecture

The elements defined in UMTS network architecture have the same logical functionality than SIP network entities (SIP proxies and Registrars). This section describes the terminal and the network elements according to the UMTS naming. UMTS networks are considered the evolution from the GPRS networks towards All-IP networks. Figure 2 shows the network architecture in GPRS or 2.5G networks.


77

The Call Processing Server (CPS) controls the Call State, performs the right decisions, and handles the routing process to set up the call. The Call Processing Server (CPS) implements the Call State Control Function (CSCF) as part of the core network access control. CSCF is the logical entity that contains the SIP functionality for terminating the user-to-network signalling for network accessing. The CSCF, as part of the CPS contains the SIP functionality of Proxy server, Redirect, and Registrar. Furthermore, depending on the functionality, the CSCF can be (1) I-CSCF -Interrogating CSCF, (2) P-CSCF -Proxy CSCF, and (3) S-CSCF -Serving CSCF. The CSCFs query to the I-CSCF to obtain the callee address for routing to reach the destination. The P-CSCF is an intermediate CSCF that receives the incoming messages from the terminal, and forwards them to the S-CSCF. After the terminal registration, an S-CSCF is assigned to the subscriber to attend all his messages. Figure 3 shows the UMTS or 3G architecture as evolution from GPRS networks.

78

Chapter 4

When interoperability with legacy networks is involved, other elements can either be included as part of the CPS. Those elements are used to perform the routing and message translation within the UMTS architecture towards legacy networks. The Media Gateway (MGW) converts the media stream between SCN and IP. The Media Gateway Control Function (MGCF) translates 3G SIP signalling to SCN. The Roaming Signalling Gateway (RSGW) updates the information in the Home Subscriber Server (HSS) when users are roaming between wireless networks (2G, 3G). The Border Gateway Control Function (BGCF) is the last element in the 3G network that acts like a CSCF. The Gateway Mobile Switching Centre (G-MSC) role is to adapt the signalling from 3G to the Mobile Switching Centre (MSC) used in 2G. The HSS stores user profile, and has the same functionality as the Home Location Register (HLR) and the Visited Location Register (VLR) in 2G networks. Additionally, numbering translation is performed at the HSS.


2.4.2

79

Provisioning Location Data in UMTS networks

The 3GPP have defined a set of network entities for provisioning of location information in 3G networks. It is based on 23.271 [18] standards and has identified a set of elements that will calculate the user location information using the existing network infrastructure. Thus it is defined a Positioning Function (PF), which determines the spatial location of a given terminal. It can be an integral terminal function, e.g. based on GPS, Local Positioning System (LPS; 23.271) or it can be provided by a Network Provider, e.g. based on radio cell information or a triangulation mechanism. It has been defined a set of additional elements to interact with the termianl and the PF for providing the location information.

3.

SIP SERVICE PROVISIONING

SIP is quickly gaining popularity with Application Service Providers (ASPs), Communication Service Providers (CSPs), and Network Service Providers (NSPs) focused on offering their customers innovative, new IPbased services. SIP provides for the seamless transmission of voice, fax, and data across IP and traditional telephone networks. SIP is the heart of future All-IP multimedia and Mobile Internet service architectures. This section describes the suitability of SIP for implementing those new services. On SIP, intelligence is pushed to end-user equipment, and the network is kept as simple as possible. This enables faster and more flexible implementations of new services. On the other side, failure in a network node is not critical. Other nodes can take over the work. Reliability is obtained by implementing end-to-end services in which the network failure will not lead to a loss of state information essential for the service. SIP is used to establish peer-to-peer media sessions on an IP network including Internet telephony, conferencing, instant messaging, and unified messaging. It uses less bandwidth than H.323 because it requires fewer and smaller messages to set up and tear down a call. SIP addresses the following criteria for establishing and terminating multimedia communications:

Chapter 4

80

User location, determinating the device to be used for communication. User capabilities, determinating the media and media parameters to be used. User availability, determinating the willingness of the called party to engage in communications. Call setup, establishing call parameters at both called and calling party (alerting). Call handling, including transfer and termination of calls.

3.1

SIP Mechanisms for Services Provisioning

SIP network contains a proxy server, which is analogous to a router. Common proxy services include basic address translation, redirect, multicast, load balancing, registration, and authorisation. Most proxy servers have the ability to modify and configure existing services or provide additional services through HTML, XML [19], or Java script. This capability allows existing services to be easily reconfigured and new services to be defined. The proxy server takes the SIP call, determines the correct address for the recipient, and sends the SIP INVITE message. A location server finds the user and the specified device. Users can predefine filters depending on the time of the day, where they are, who is calling, etc. In that case, the user sets his profile according to his preferences. SIP paradigm is based on using intelligent terminals. Users can create new services by writing their own call handling scripts or by downloading other users' available scripts. The Call Processing Language (CPL) [20] is on of the mechanisms where the user can design its own services and afterwards uploads them in the servers. It is a language that can be used to describe and control Internet telephony services [21]. Furthermore, SIP unifies major communications services such as voice, video, user presence, instant messaging (IM), etc. SIP enables new combined services integrating voice, video, IM, presence, e-mail, and web. The result will be a "killer application" for communications on the Internet. Presence and communication protocols simplify the delivery of combined services. The location data is an important part of the user presence information to enable LBS services in addition to specific presence related services.


3.2

81

SIP Services Provisioning

Based on open Internet protocols, service creation languages and technologies, All-IP system provides seamless integration of communication services and Internet applications. By increasing the flexibility and rapidness of service creation, end-users can be delighted with completely new rich communication experiences. Furthermore, an IP platform will potentially reduce mobile network costs by enabling an integrated network infrastructure and optimised transmission system to be realised. SIP includes an interesting concept called presence. Users can make a SIP connection between two endpoints, but the interesting element is that each endpoint can be any number of devices including cell phones, desktop phones, Internet phones, PDAs, etc. The SIP environment determines where the user is (presence), how willing the user is to accept communications, the terminal device's media capabilities, and which devices have priority for connection attempts. SIP may try to connect with each device one at a time or send an INVITE to multiple devices at the same time (multicast). Presence services range from the simple follow-me and instant-messaging services to highly advanced community gaming concepts. Some possible examples of services are traffic news to your handset, delivery tracking, stockwatch, sales-force tracking, and taxi services. Presence makes the telephone more effective both by adding dynamic information about the user to the static address of the device and by placing it in a broader context of devices. Therefore, the presence and the location as part of it, facilitate the provisioning of big bunch of services that increase the added value to the existing services.

3.3

Architecture and Data Formats for Location Information

It has been identified the importance of the location information for provisioning LBS. Therefore, it has been initiated a set of different efforts from different consortiums in wireless and fixed IP networks. The aim is to define and standardise the data structure and infrastructure to include the location information as part of the communications in IP terminals.

82

Chapter 4

3.3.1

Location Interoperability Forum

LIF [2] is an industry consortium that was formed in September 2000. The aim of this initiative is to develop common solutions for Location Services in mobile terminals. LIF defines a set of recommendations and specifications to provide Location services, which are independent of the network protocol and the positioning technology. These specifications will allow the users to obtain location information from the wireless networks independent of their air interfaces and positioning methods. Furthermore, these specifications define interoperable location services to be used also from any internet-based application. Thus, for this purpose LIF identifies a set of interfaces that will facilitate interoperability among different network operators and manufacturers. According to the LIF consortium, the main interfaces identified to achieve a complete interoperability are the following. 1. The interface between the wireless network and applications: Applications should use one interface obtain location information from any wireless network irrespective of whether the network is GSM, CDMA, TDMA, etc., and the positioning technology used. 2. The interface between the application and content engines and databases; Applications should also be able to use one interface to access contents. 3. Interface for billing and revenue sharing: Network operators, application providers, and contents provider, should be able to bill for their services and share revenue amongst themselves. 4. Interface for privacy and security: it is extremely important to develop trust models between the service provider and the end user. This interface developing secure and effective methods for obtaining subscriber profiles, location information, billing, etc. This Interface has to satisfy regulatory guidelines for providing secure API between the application and the network.

LIF defines MLS as a collection of technologies and applications that will estimate the location of a mobile device, and will deliver customised, and personalised information (contents) based on the device’s location and user preferences.


83

Current LIF focus include: 1. Define a simple and secure access method that allows user appliances and Internet applications to access location information from the wireless networks irrespective of their underlying air interface technologies and positioning methods.

2. Promote a family of standards-based location determination methods and their supporting architectures, that are based on CellSector-ID, Cell-ID and Timing Advance, E-OTD (GSM), AFLT (IS-95), and Assisted-GPS.

3. Work with industry experts and organisations to define/adopt common solutions that facilitate billing and revenue sharing of location services and applications in multi-network, multi-vendor and multi-service environments. 4. Work with industry experts and organizations to define/adopt common solutions that facilitate provisioning of location services and applications in a multi-network, multi-vendor and multi-service environments. 5. Establish a framework for contributing to the global standard bodies and specification organizations to define common methods and procedures for the testing and verification of the LIF-recommended access method and positioning technologies. Figure 4 shows the terminology and procedures defined in LIF compare with similar specifications defined for location provisioning in UMTS networks.

84

Chapter 4

Thus LIF will define a set of algorithms for Location Positioning including different technologies such as Bluetooth, GSM and others. LIF defines a set of APIs to manage the data coming from the terminals and those interfaces are available for the companies involved in the consortium. It defines a closed architecture of terminals and networks that share the same interface for deploying location-based services. Figure 5 presents the services definition and functionality specified by LIF.


85

3.3.1.1 Mobile Location Protocol Specification LIF has defined a Mobile Location Protocol (MLP) that can be used by a location-based application to request MS location information from a Location Server (Gateway Mobile Location Center defined in GSM and UMTS –GMLC, Mobile Positioning Center defined in ANSI standards – MPC or other entity in the wireless network). MLP is an application-level protocol for querying the position of mobile stations independent of underlying network technology. The MLP serves as the interface between a Location Server and a location-based application. It aims to be a ubiquitous protocol for location services, which support different transport mechanisms. Thus, in MLP the transport protocol is separated from the XML content and it includes HTTP, WSP, SOAP and others (SIP). The HTTP protocol ("HTTP/1.1 "[7]) is the only currently defined MLP transport. HTTP provides a request/response protocol involving a server and a client. In the context of MLP, the client is referred to as the LCS Client and the server is the Location Server (GMLC/MPC). The Location Server should provide two

86

Chapter 4

socket ports for operation, one for encryption with SSL/TLS and one without. The reason for having one insecure port is that encryption can consume resources, and if the client is in a secure domain there might not be a need for encryption. Therefore, the applications residing in an insecure domain they can use the secure port to ensure the security and privacy of the location information.

3.3.1.2 LIF Service Example An LCS Client requests a Location Service by issuing an HTTP POST request towards the Location Server. The Location Services are invoked by sending a request using HTTP POST to a certain URI (i.e “http://host:port/LocationQueryService/”). The response to the invocation of a Location Service is returned using an HTTP response. Figure 6 shows the LIF service request and response a XML structure for including the location information and the HTTP as transport protocol.


87

If the LCS client requests a periodic reporting of location, the Location Server will return the answer by performing an HTTP POST operation towards the client. The client must specify the URI that the answer should be posted to. Figure 7 shows the LIF service invocation requesting a periodic triggering from the network.

3.3.1.3 LIF Location Structure The MLP implementations should support at least the following coordinate systems; the ellipsoid and the UTM coordinate systems. The ellipsoid coordinate system is sufficient for many calculations. Nevertheless, MLP supports the additional planar coordinate system UTM. Using UTM, clients can just ask for rectangular metric coordinates and don't have to worry about complicated coordinate transformations. The MLP implementations should support at least the ellipsoid WGS-84. Additional ellipsoid coordinate systems and datums (such as BESSEL-1841) can also be supported by certain implementations.

Chapter 4

88

LIF uses XML structures for creating the service invocation to be included in the HTTP requests and responses. For flexibility reasons LIF has defined sseparate DTDs for each message, which allows new messages to be added without affecting the previously specified.

3.3.2

WAP Forum

Wireless Application Protocol (WAP) [22] is a result of the work to define an industry wide specification for developing applications that operate over wireless communication networks. The scope for the WAP Forum is to define a set of specifications to be used by service applications. WAP defines a set of protocols in transport, session and application layers. For additional information on the WAP architecture, refer to “Wireless Application Protocol Architecture Specification” [23]. Location based WAP services, i.e., and services dependent on a geographical location, represent a class of applications with specific needs. The WAP location framework addresses these needs by providing a transparent and position procedure independent location application interface. It also provides guidelines for location related privacy. WAP defines the overall architecture for the access of location information. The WAP location framework uses two XML documents, XML Invocation Document and XML Delivery Document, to carry information when location information is requested and delivered. In this sections it is included a brief description of format of those documents. Figure 8 , gives an overview of the WAP location architecture. This figure only shows entities that are relevant to the location framework. All the areas depicted in the figure are defined within the WAP location framework.


89

Thus, a request from the terminal is routed via the WAP Location Attachment Functionality (part of the WAP Location network) or it can be routed directly to the application server. The main entities in the WAP Location Framework Infrastructure are the following. WAP Client: The WAP client MAY include functionalities implementing the services. WAP Location Network: The entities in the network that include functionalities implementing the services. Application Server: The entity that manages the content of the message for providing the services. The EFI Location Functionality enables a WAP client application to access location information. The WAP Location Query Functionality provides the Location Query Service. This functionality can reside within the WAP Client or as a Supporting Server as part of the WAP Location Network. The WAP Location Attachment Functionality provides the Location Attachment Service. The implementation of this functionality can reside within the WAP Client or as a Feature Enhancing Proxy in the WAP Location Network. The Location Query Service defines the following messages: QueryInvocation QueryDelivery AckQueryInvocation A QueryInvocation is used whenever the initiator queries for location information by providing a Location Invocation XML document in a request. The AckQueryInvocation message is used by the originator to acknowledge the invocation of a QueryInvocation request with a Location Delivery XML document containing status information. A QueryDelivery message is used as a reply to a QueryInvocation message by returning a Location Delivery XML document. A single QueryInvocation message is followed by one or more QueryDelivery messages depending of the content of the QueryInvocation message. The WAP Location Query Service MAY occur on the following service mappings:

90

Chapter 4

1. An application on the Application Server initiates a request for location information from WAP Location Query Functionality in the WAP Client. The location information is returned to the Application Server. 2. An application on the WAP Client initiates a request for location information from WAP Location Query Functionality in the WAP Location Network. The location information is returned to the WAP Client. 3. An application on the WAP Client initiates a request for location information from WAP Location Query Functionality in the WAP Location Network. The location information is forwarded to the Application Server. The Location Invocation document is used to request location information is XML structure. The document is in DTD format and contains the following information. Location information Provided Location format Provided Quality of Position Status code e.g. "accepted" or "location access denied" 3.3.2.1 WAP Service Example This section presents a simple service scenario as part of WAP Location Framework. The user tries to find nearest restaurant via the Location Attachment Service. A user requests information about the nearest restaurant by sending an ordinary request for content to the application URL. WAP Location Attachment Functionality attaches the location of the WAP Client to this request as a Location Delivery XML document. The application server uses the attached location information within the Location Delivery XML document to find the nearest restaurant (Figure 9). It then returns the nearest restaurant information as ordinary WML content. Note the application server does not need the address of the WAP Client.


91

If this application server receives a request without the location information attached, it may return a Location Invocation XML document to indicate the need for location information. Thus, the terminal has to make a Location Query Service for obtaining the Location information. Afterwards, the original request may then be reissued with the Location Delivery XML document attached.

3.3.2.2 WAP Location Structure The WAP location documents have been designed with extensibility in mind. Examples of design principles employed to achieve this include: Client Identity: PLMN - Phone number, e.g. +447968123456 IPv4 - IP version 4 address, e.g. 123.456.789.123 IPv6-IP version 6 address, e.g.ABCD:6785:F65D:56F4:D687:F7DC :372F:F4D5

Chapter 4

92

Location Formats: Mandatory: Latitude and longitude co-ordinates using the WSG-84 datum Optional UTM co-ordinates using the WSG-84 datum Spatial reference systems (based on a spatial reference system, such as the UK national grid). Geo-codes (in terms of geo codes, e.g. postal code, rather than coordinates) Velocity, Altitude and Direction Quality of position (QoP) Age of the location information Accuracy of the location information. Confidence in the accuracy information.

3.3.3

Spatial Location Information in Fixed IP Networks

The previous sections described the different consortiums defining the architecture and infrastructure for providing Location information in wireless environments. In following sections, it is depicted the interaction with those location provisioning mechanisms and SIP to add location capabilities in UMTS networks for emergency services and Location Based Services in general. Similar effort is initiated at the IETF [24] with the aim of defining similar infrastructure and data formats for providing location capabilities in a wired environment. The IETF initiated a set of requirements for defining an open container where can piled up any format or location data structure. Additionally, it aims to define a set of requirements regarding security and privacy to carry the location information over IP based networks. The IETF aims to define a common and extensible container (e.g. XML flexibility and extensibility make this language the best option to define this data structure) to place the user identifiers, security factors, location representation, and other parameters to manage the user location according to his specifications. The IETF specifies the requirements to define a data structure to be secure and self-contained to carry the user information. That structure should include the attributes where the user can specify precise requisites to manage his information by a third entity or provider. That structure should contain a user identifier with mobility features that will


93

allow identify the user when he logs at different access points of the network (Target IDentifier, TID [25]). Therefore, this data structure can be included as part of any text-based IP protocol such as HTTP or SIP. Figure 10 , shows the message format where a XML location structure (LIF, WAP, etc) can be included as part of a textbased transport protocol such as SIP or HTTP.

Thus the location data can be predefined at the user terminal depending on the specific device and afterwards it is carried within a SIP message. The location data format can be negotiated depending on the user device capabilities. The negotiation mechanism is provided by SIP using its request and responses to agree between network elements about the management of the message content. Thus, the previously introduced SIP servers (Proxy, Redirect or Registrar) receive the message with the location data content and forward it to the precise application server. If the device has no capabilities for calculating the user location (e.g. without GPS or any other calculation mechanism) it can be requested from the network using complementary services.

94

3.4

Chapter 4

Location Based Services Scenarios

The wireless and Internet access is rapidly converging. Mobile commerce is expected to grow at seemingly incredible rates as mobile users. Hence, this chapter describes the conjunction of SIP with location information (LIF, WAP or XML-based structures) to support location-based applications. These new applications are location-based messaging, and other location based services. A SIP user enhanced with location information can establish a session with any SIP-speaking provider of location-based services. The SIP message transfers the user location information to a provider. Afterwards, the provider can send back a response to the user based on his spatial location. SIP is a transparent signalling protocol and the location information can be previously obtained using the structures defined at LIF, WAP forum or any similar consortium. Location Based Services (LBSs) are based on retrieving information according to the user location. Adding the location information during the terminal registration enhances the user to access specific network services, and augments the information content value. The geographical data improves the information content because it is related to the real user location. Thus, the user gets the right information and services according to his current situation. They can be either crucial services (e.g. the nearest Emergency service assistance point), or they can just be requiring the precise location to provide accurate information (e.g. looking for the nearest Pharmacy or requesting a taxi providing the exact location, etc.). These services are related to the information content, and when the user requests a specific service the provider immediately checks the user location and supplies the closest site for attending the user request. The knowledge of location information is used to send the data requested based on the user location. The emergency service is a LBS service but it will be included in the category of basic services due to its mandatory aspect. As part of the supplementary services and within the LBS environment there are two kinds of mechanisms to collect service information. They are known as pull and push service cases. The result in both is the same, getting some information, but the procedure is different.


3.4.1

95

Emergency Call

This section describes the implementation of Emergency Call as example of Location Based services. USA and EU governments decided to make all emergency calls geographically locatable by law. IP Telephony supports emergency purposes as E911 call services in USA [26], 110 in Germany, and 112 in the rest of Europe. These services are required to be universally available regardless the network where the user is registered, and the device he is using. Currently, SIP is not capable to support emergency call services yet. SIP is simply the signalling protocol for connecting two entities over IP. SIP does not determine the purpose of the connection. The content of the SIP payload indicates what kind of session is going to be established. Normally, SIP carries an SDP packet describing an audio or video session, indicating the end-terminals capabilities. Other type of sessions requires an additional mechanism including the content information of the specific transaction. SIP can be enhanced with the required Location capability for supporting the mandatory emergency call services. SIP has the capabilities for providing user mobility, and this is indispensable for an emergency service. SIP is designed to perform a session establishment based on the transaction of the media characteristics indicated in the payload of the message. In the same manner, the location information (LIF, WAP or XML structures) can also be considered as session data to be carried in the initial call set up, and placed in the SIP payload instead of the usual SDP packet. In this case, SIP is not used for establishing a complete session between two users. It just registers, stores, and exchanges the user location information. Thus, taking advantage of SIP flexibility for extending new capabilities, it can be easily enhanced with the spatial location capability. Certain spatial location-aware emergency communications are already available in the United States, and they may be mandatory in Europe and other countries soon. The third and fourth generations of mobile phones are moving towards IP infrastructure. Thus, it is necessary to provide these essential services for the IP-based mobile phone. IP Telephony (using SIP) has to be able to offer these services as part of its capabilities. In order to add this feature in SIP, it can be used the recent mechanisms defined in LIF and WAP for requesting the location information. Afterwards, the location data obtained can be placed in the SIP payload during the registration procedure to the UMTS networks. SIP as core signalling protocol in 3G networks

96

Chapter 4

defines a common infrastructure adaptable to different terminals and user requirements. Some devices may not have any system for coordinate calculation and need to be also spatially located. Thus, if the user terminal has adequate resources for calculating the coordinates, the location data field is filled at the user device. Otherwise, the user request to fill the location data structure from external mechanism defined in WAP and LIF specifications using standard UMTS procedures 23.271 [18]. Finally, the terminal has can get access to the UMTS network including the obtained location information as part of the registration or log in procedure. Figure 11 shows the location information query where the terminal receives location-positioning assistance from the network.

SIP provides both user, and terminal mobility. The mobility refers only to the point where the device is attached to the network. SIP is enriched with location data structures (LIF or WAP) to provide the location information for user applications. The mechanism of SIP registration using location data, as part of the SIP mobility capabilities, makes the emergency service globally available. Therefore, every time that the user registers in a different terminal,


97

the location data structure included in the SIP messages is delivered and the location information is continuously updated. In this manner, SIP keeps the user identified and spatially located definitely. The spatial information may be stored in the Location Server depending on user requirements. These requirements are indicated on the management attributes or in the user profile. In case of emergency situations, keeping the information at the LS is extremely useful for obtaining the latest known location of the user. The intention of the emergency services is to provide the spatial location of someone in extreme situations like danger, assistance, accidents, etc. Hence, it is essential to achieve location information establishment and exchange for IP devices. The principal objective is letting URI-addressable entities being able to establish/acquire and provides their location data. Security and scalability are the design constraints of a universal service such as the Emergency service. Furthermore, some data negotiation to achieve global interoperability is provided by SIP server discovery mechanism. SIP is a well-design mechanism to achieve a common understanding among network entities to establish a media session. In this case they have to agree in location data management. Figure 12, shows the negotiation or server discovery mechanism provided by SIP to find out the network entity that can handle the content of the SIP payload.

98

Chapter 4

Data exchanges situations, and services always require security [27]. It is essential to provide a trusted service, where all the information is reliable. For this reason, several security channels between the entity that provides or requests the information, and the entity that stores and retrieves the information for other services (Emergency, Personal services, Signalling, etc) have to be established. We need to utilize a secure channel using a TLS session at the transport level or HTTP basic and digest schemes at the application level [28], which is integrate as part of SIP security mechanisms. Several scenarios and all the information to be exchanged have to be considered. Thus, the type of data exchanged between the possible entities in different scenarios and its updates has to be analysed. Evidently, static users only need to provide their spatial location once but moving devices register their locations frequently. In this case, the traffic generated is considerably increased. The user can be temporarily registered at the local SIP server. The registration simply indicates that the user is located at that network point for


99

a short period of time. This situation involves minimal support from the network. For the new location based services, the users create more traffic depending on the kind of service requested. Services require more support from the network depending on the approach used for implementing the service (Pull/Push). Basically, they use the SIP framework for obtaining the spatial location information in the same registration process. Later on it is also used for the specific service desired. Therefore, the user identifier used in SIP (URL) can provide complementary information about his spatial location. 3.4.2

Location Based Supplementary Services

This part introduces the implementation of Location Based Services as part of supplementary services. The Basic or primary services are considered as the elemental for user communication. The supplementary services are defined as the services that any operator offers to the clients as additional services with extra fee. The telecommunications market are open to equal competition, so the supplementary services are offered by the same operator where the user is subscribed, or they can be accessed in different networks. Following are described the services identified as push and pull Location Based Services. 3.4.2.1 Push Services Push services are those that the user gets after subscribing to them. The user sends a SUBSCRIBE message to a SIP registrar including the information he would like to receive. The registrar server contacts the application server (AS) for handling the user request. When the desired user information is ready, the application server answers to the SIP registrar providing the information that must be sent to the user. Information is sent back to the terminal through the NOTIFY message as depicted in Figure 13 . In this case the user is being pushed getting the messages at the terminal. He may request hottest offers, updated information, new publications on the market, forecast news, etc.

100

Chapter 4

3.4.2.2 Pull Services The pull service is for those people, who seek tailored and personalised services. Pull service case is illustrated in Figure 14 . The SUBSCRIBE and NOTIFY messages are not necessary for this service; instead the MESSAGE method is applied. The user sends a MESSAGE to the SIP registrar server. That message contains the details of the information requested by the user. The server forwards the request to the application sever which contacts with the Service Directory for LBS. When the response for the user is sent back to the SIP registrar, it creates a SIP response (200 OK) with the information desired by the user.


101

This section describes the potential of this architecture to enable LBSs in a wide and scalable manner. The previous chapter presented the core of the UMTS networks based on SIP, its methods and elements employed for providing push and pull services. This strategy can provide the user location information using the existing technologies. Inside the SIP payload can be stored any of the location data structures that are under specification (LIF, WAP, etc.), and it can also be extended with some proprietary structures. This system establishes a virtual channel between the terminal and the application server for enabling LBS services. The application server can be part of the 3G infrastructures or a third party can manage it. In the former case, the provider owns the application server and gets specific services from third parties. This approach is more secure in the sense that the location information is kept internally in the 3G networks, and the provider requests the concrete service on behalf the user. Another business case appears when the provider just supplies the 3G infrastructures for message exchange, and the communication is established between the terminal and a third party application server. This situation requires the existence of a PKI infrastructure to guarantee a safe transaction between the terminal and the service provider. In this case, the application server is outside the 3G domains and the user has to pre-establish a secure association before the connection. The previous scenario is open to a more competitive environment since the user can request the same service from any third party outside the UMTS

102

Chapter 4

networks. The operator just provides the means for communicating, but it does not certify the reliability and security of the service. The operator has to provide the location information in the initial registration of the terminal because it is mandatory for emergency reasons. The operator does not guarantee the privacy of the information when the user establishes the service with another service provider.

3.4.3

Service Discovery

In a global architecture like in the case of Internet based networks, locating the right server that can manage the data provided in the message is essential. This mechanism is provided by the SIP architecture, where the server based on the URL indicated in the message can proxy or redirect the message to the right server. Furthermore, if the client prefers a non-default representation after contacting with the Location Server (LS in SIP architecture, or GMLC; Gateway Mobile Location Center in LIF specifications), he may need to perform a spatial location representation negotiation with the server. At the server side, in case that the information received cannot be interpreted or it is coming from non-IP device, the server needs to contact a Location Gateway to understand the representation received in the SIP payload. If there is no way for the Location server to handle the message it sends back an error SIP message like SIP/2.0 501 Not Implemented or SIP/2.0 503 Service not available. The SIP is enhanced with location data but SIP itself is a signalling protocol and the payload is forwarded to the server that may understand the content. Thus, when the Location Server does not understand the data format it notifies the SIP server that the format is wrong. This is a specific scenario that is part of more complex situations when the Location Server can receive location data from multiple vendors with different approaches for representing the coordinate data. Thus, the SIP architecture defines a default procedure to handle the location data included in the SIP payload, despite the system coming up with a specific format.

3.4.4

Security at SIP Layer

The SIP protocol defines diverse security approaches based on end-toend and hop-by-hop. The SIP servers may require user authentication previous to any access. Thus, the user data can rely on the transport protocol


103

for this issue. Otherwise, it needs an additional pre-agreement with the Location Server for obtaining a shared key for end-to-end encryption. The user indicates the grade of security he wishes for the transaction, and SIP takes care of it. SIP enabled servers authenticate and encrypt the data according to the restrictions defined by the user. If the user prefers an insecure but quick service then the data is sent in plain text. Otherwise, SIP employs its security mechanism described in the following paragraph. If the user tries to register where he is not authorised, the Registrar server returns a 401 Unauthorized response indicating that the registration requires an authorisation using any of the SIP mechanisms. The user has to re-issue the request including the Authorisation header where the credential containing the authentication information is inserted. Basically SIP security is implemented using the approach mentioned previously using HTTP schemas [28]. Based on the RFC 2617, the former approach uses the headers ProxyAuthorisation, WWW-Authenticate, and Authorisation in various messages. It can be used a PKI as authentication mechanism. In this method the client authenticates itself with a request signed with the client's private key. The server can then ensure the origin of the request, if it has access to the public key that was signed by a trusted third party. The algorithms of this scheme are based on RFC 2440 [29] that follows principally the requirements of RFC 1825 [30]. The headers involved in the transaction are the Authorisation, WWW-Authenticate, and Response-Key for providing the user's public key extracted from the PKI infrastructure. The 3GPP define security architecture to guarantee security and integrity of any transaction within 3G networks. The security is based on the Universal Mobile Telecommunications System (UMTS) Authentication and Key Agreement (AKA) [31] mechanism. The terminal authenticates itself using a challenge/response procedure based on a security algorithm run in the Universal Subscriber Identifier Module (USIM) card. The terminal executes this mechanism during the registration, and it obtains session keys to be used for generating the integrity tokens placed in all the messages [32]. Thus, the security is guaranteed between the terminal and the SIP server, but it is not guaranteed for the payload. If the user desires to exchange messages with complete privacy in the content of the messages (payload), it has to obtain a pre-shared key to

104

Chapter 4

encrypt the content of the location data structure. The same key is used for decrypting at the server. Otherwise, it has to be performed a Diffie-Hellman [33] mechanism. The user previously registers his public key in the server, and sends the message encrypted with his private key. This procedure does not increase complexity when the application server is part of the 3G networks and it is collocated with the SIP server. For facilitating the exchange of security information, the location data structure can include an attribute that contains the ID and password to identify the user (e.g.”msid” and “pwd” elements in LIF structure). A third party server uses those attributes to retrieve the keys from a Public Key Infrastructure (PKI). The location data structure can also add the signature of the message and user credentials for integrity checking (e.g. “enc=CRP” element in LIF structure).

4.

CONCLUSION

This chapter describes the management of Location Information at application level. After obtaining the location data from the positioning systems, SIP enables its usage to provide Location Based Services. There are some open issues regarding security and privacy when the information traverses from wireless to wire networks. In Internet the security is performed using basic mechanism and after crossing the border of 3G networks towards public domains, the security is not ensured.

4.1

Security

Mobile customers have to be well informed of location collection and use practices prior to collection [27]; have the meaningful opportunity to consent to the collection and use of this information for location-based services; and ensure of the security and integrity of any collected location information.


5.

105

REFERENCES

[1] The UMTS Forum , URL:http://www.umts-forum.org/ [2] Location Interoperability Forum, UR L: http://www.locationforum.org/ [3] "Wireless Application Protocol Architecture Specification”, WAP Forum, 30-April-1998, URL: http://www.wapforum.org/ [4] "Recommendation H.323: Framework and wire-protocol for multiplexed call signalling transport". ITU, URL: http://www.itu.int/ [5] M. Handley, H. Schulzrinne, E Schrooler, J. Rosenberg. "Session Initiation Protocol", RFC 2543, IETF. [6] "Multiparty Multimedia Session Control, MMUSIC",,IETF WG, URL: http://www.ietf.org/html.charters/mmusic-charter.html. [7] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach and T. Berners-Lee, "Hypertext transfer protocol- HTTP/1.1", RFC 2616. IETF, June 1999. [8] D. Crocker, "Standard for the format of ARPA Internet text messages", RFC 822, IETF, Aug 1982. [9] M. Handley and V. Jacobson, "SDP: session description protocol", RFC 2327. IETF, Aprl 1998.

Chapter 4

106

[10] T. Berners-Lee, R. Fielding and M. McCahill, "Uniform resource locators (URL)", RFC 1738, IETF, Dec 1994.

[11] T. Berners-Lee, R. Fielding and L. Masinter, "Uniform resource identifier (URI)", RFC 2396, IETF, Aug 1998. [12] D. Crocker, Ed. And P. Overell, "Augmented BNF for syntax specifications: ABNF", RFC 2234, IETF, Nov. 1997. [13] A. Gulbrandsen, P. Vixie and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, IETF, Feb 2000. [14] D. Zimmerman, "The finger user information protocol", RFC 1288, IETF, Dec 1991. [15] S. Williamson, M. Kosters, D. Blacka, J. Singh and K. Zeilstra, "Referral whois (rwhois) protocol V 1.5", RFC 2167, IETF, 1997. [16] W. Yeong, T. Howes and S. Kille, "Lightweight Directory Access Protocol", RFC 1777. IETF, 1995.

[17]

"3rd

Generation

Project

Partnership

(3GPP)",

URL:

http://www.3gpp.org/ [18] 3G TS 23.271 V 2.0.0 (2000-12). "3rd Generation Partnership Project; Technical Specification Group Services and Systems Aspects; Functional stage 2 description of LCS (Release 4)".


107

[19] T. Bray, J. Paoli, and C. M. Sperberg-McQueen, Extensible markup language (XML) 1.0, W3C Recommendation, REC-xml-19980210, Feb. 1998. (www.w3.org/TR/REC-xml) [20] J. Lennox and H. Schulzrinne, "CPL: A Language for User Control of Internet Telephony Services", Internet Draft, IETF, Nov. 2001. Work in progress. [21] Inmaculada Espigares, Jose Costa-Requena, " New Tools for Programming

Intelligent

IP

Telephony

Services",

IP

Telephony

workshop,URL: http://www.fokus.gmd.de/events/iptel2000/, April 2000. [22] "Wireless Application Protocol WAP 258 Location XML Document Formats", Draft Version 11-April-2001. [23] “WAP Location Drafting Committee Charter”, WAP Forum, 22-March2000, URL: http://www.wapforum.org/ [24]

"Geographic

Location/Privacy

(geopriv)",IETF

WG,

URL:

http://www.ietf. org/html.charters/geopriv-charter.html. [25] H. Tang, M. Korkea-aho, J. Costa-Requena, and J. Ruutu, "Serving Spatial Location Information over the Internet," Proceedings of International Conference On Mobile Data Management (MDM '2001), pp. 245-251, January 2001. [26] Reporting Deadline Phase II E911 ALI, CC Docket No. 94-102, FEDERAL COMMUNICATIONS COMMISSION. http://www.fcc.gov. SLO in payload

108

Chapter 4

[27] M. Altschuk, R. Coleman. "Petition of the Cellular Telecommunications Industry Association for a Rulemaking to establish fair Location Information Practices," Rcd 6170.FCC. [28] J. Franks, P. Hallan-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen and L. Stewart, "HTTP authentication: Basic and digest access authentication", RFC 2617, IETF, June 1999. [29] J. Callas, L. Donnerhacke, H. Finney and R. Thayer, "OpenPGP message format" RFC 2440, IETF, Nov 1998. [30] R. Atkinson, "Security architecture for the Internet protocol", RFC 1825, IETF, Aug 1995. [31] 3GPP specifications: 33.908 "3G Security; General report on the design, specification and evaluation of 3GPP standard confidentiality and integrity algorithms", (Release 5).

[32] J. Costa-Requena and I. Espigares, "Security Concerns in 3G Networks", Proceedings of International Conference on Internet and Multimedia Systems and Applications (IMSA), pp.91-95, August 2001. [33] E. Rescorla, Diffie-Hellman Key Agreement Method, Request for Comments: 2631, Network Working Group, IETF, 1999.


109

Additional Recommended Reading

H. Schulzrinne, Elin Wedlund, "Application Layer Mobility Using SIP ", Mobile Computing and Communications Review, Vol. 1, No. 2, pp. 1-9, 2001. A. Dutta, "SIP Mobility and 3G Wireless", SIP Summit Presentation, http://www.argreenhouse.com/SIP-mobile/sip-2001-pulver.ppt.


Chapter 5 Protocols for Updating Highly Accurate Location Information Alexander Leonhardi and Kurt Rothermel University of Stuttgart

1.

INTRODUCTION

As detailed information about the location of a mobile device or user has become widely available, mainly through the satellite positioning system GPS, more and more location-aware applications, as for example developed in the GUIDE [3] or the Sentient Computing project [5], are using this information. Examples are car navigation or fleet management systems, as well as location-aware information services for cellular phones, called Location-based Services (LBS). If the location information is acquired on the mobile object itself (e.g., via GPS), it has to be transmitted from the mobile object to a location service, which stores and manages this information, using wireless communication. In case of a distributed service, where the location information is cached or replicated on a number of servers, the information also has to be transmitted between location servers. Finally, the location information needs to be transferred to an interested client. To control the transmission of location information, different update protocols with varying properties have been discussed. In order to be able to guarantee a certain accuracy of the returned location information, this information has to be transmitted (updated or requested) very frequently. If the location information is transmitted from a mobile device to a location server, a wireless channel has to be used, where bandwidth is low and expensive. It is therefore important to use an update protocol that works efficiently, that is, requires as few messages as possible,

112

Chapter 5

and effectively, that is, achieves a desired accuracy of the location information on the server. A cellular mobile communication network, for example, relies on information about a mobile phone’s current communication cell to be able to forward incoming calls to it. In this context, various reporting protocols (e.g., [2], [10] or [1]) have been discussed with the goal of minimizing the overall number of necessary update messages. The location information, however, is in this case a location area of the mobile communication network, which consists of several cells and has a size of between a few hundred meters and up to more than 30 km. For accessing more accurate location information, provided for example by a special component of the mobile communication system, a so-called Gateway Mobile Location Center (GMLC, see, for example, [9]), the Mobile Location Protocol (MLP) has been proposed (see [11]). In this chapter, we focus on protocols suitable for updating location information with a high accuracy and provide a classification of different protocol variants, based on an abstract model of the components involved. We discuss the characteristics of the resulting protocol classes and their subclasses as well as their strengths and weaknesses according to different areas of application. By means of an analysis we determine the efficiency and effectiveness of these protocols, comparing the number of transmitted messages to the resulting minimum and average accuracy of the location information at the server for different mobility characteristics of mobile objects. Finally, we look at the results of various simulations, which we have performed based on real-world GPS traces and which confirm the outcome of our analysis. A very promising class of update protocols for location information consists of the dead-reckoning protocols, which have been proposed by [18]. These protocols assume that the mobile object keeps moving on with the same speed and direction. The mobile object only sends a position update, when the distance between the real and the estimated position becomes greater than a certain distance threshold. In our simulations we therefore look in more detail at a dead-reckoning protocol, which is able to reduce the number of messages by up to 83% compared to a more simple reporting protocol. Additionally, we introduce a combined protocol, which integrates the advantages of two basic classes of update protocols, the reporting and querying protocols. This protocol is able to adapt dynamically to different types of environments, by finding an optimal ratio between the number of position updates and the number of requests. The remainder of the chapter is structured as follows: In Section 2 we describe the assumed technical environment for this chapter. The different

5. Protocols for Updating Highly Accurate Location Information

113

classes of update protocols and their properties are discussed in Section 3, while Section 4 contains an analysis regarding their efficiency and effectiveness. In Section 5 we present simulation results, to support the outcome of our analysis. Section 6 concludes this chapter.

2.

BACKGROUND

This section gives an overview of the technical environment our work is based on, namely the sensor systems the location information is acquired from and the network environment it is transmitted over.

2.1

Positioning Sensors

The location information for a mobile object can be determined through various types of positioning systems (for an overview of existing positioning systems see, for example, [6]). A basic distinction can be made between tracking systems, where a system of stationary sensors determines the location of a mobile object, and positioning systems, where the location information is determined by a sensor on the mobile object itself. A typical tracking-system is the Active Badge system (see [17]), where an Active Badge carried by a user or attached to an office device periodically emits an infrared beacon, which is detected by an infrared sensor placed in each room of a building. An example for a positioning system is the widely used global satellite positioning system GPS (see [7]). Different types of positioning systems return the location information with varying formats and degrees of accuracy. The returned information can be symbolic (i.e., the identifier of a region, like a room or communication cell) or geometric, where it is described by a global geodetic coordinate system like WGS84 (see [8]). The classifications in this paragraph have been taken from [13]. Because no positioning system offers a global coverage (e.g., GPS only works outdoors) a universal location service has to be able to deal with location information acquired by all types of positioning systems.

2.2

Network Environment

In our work, we have assumed the following network environment: Location servers and stationary clients, which query the location information, communicate over a fixed network. Mobile devices need to be connected to this network by a wireless link. They have to be able to communicate and to be contacted independently from their geographical

114

Chapter 5

location (e.g., using a mechanism like Mobile IP [15]). Mobile devices may also act as a client of the location service by posting queries over this wireless link. The wireless network can either be a wireless WAN, like GSM (see [14]), a MAN, like the Metricom Ricochet network, or a LAN, for example according to the IEEE 802.11 standard [3]. A common characteristic of these wireless networks is that a connection can be temporarily lost, while the device is at an unfavourable location (e.g., inside a tunnel), a state that is called a disconnection (see [16]).

3.

UPDATE PROTOCOLS

In this section the different classes of update protocols are introduced and their main properties are discussed. The discussion follows the following abstract model: The discussed protocols are assumed to be used to continuously transmit location information from a primary copy to a remote secondary copy over a (wireless) communication network. The goal is to guarantee a given accuracy of the location information in the secondary copy. The primary copy could, for example, be the location information that is determined on the user’s mobile device by an attached sensor system, like GPS, and which is transferred periodically to a location service, which stores the secondary copy. On the other hand, the primary copy can also be the location information for a mobile phone that is extracted by a Gateway Mobile Location Center from a GSM network and which is transmitted regularly to a secondary copy where it is used by a location based service.

We call the component that manages the primary copy, which may be a mobile device with an attached positioning sensor system or another location server, the source of the location information. The secondary copy is usually


115

stored on a location server, where it is queried by interested location based services or other client applications. Figu1 shows the components that are involved in the transmission of the location information.

3.1

Classification

The update protocols can be divided into three main classes, namely querying, reporting and combined protocols, where each class has a number of typical variants. Each of these protocols has its characteristic properties and is suitable for a given environment or for certain requirements. The reporting protocols are similar to the paging/update schemes that are used for Location Management in the research area of Personal Communication Service (PCS) networks and are summarized, for example, in [2]. True querying protocols cannot be used in PCS, as they would involve the paging of all cells. The classes of update protocols and their relationships are shown in Figure2. 3.1.1

Querying Protocols

A protocol is called a querying protocol, if the server decides when to request the location information from the source. In this case, the source can be very simple, as it does not need to keep extensive information about its state or realize a complicated logic. This may be important for small mobile devices. The simple and the cached querying protocols transmit the location information on-demand, that is only when it is queried by an application. If the location information is queried only rarely, these protocols are more efficient than the reporting protocols described in Section 3.1.3, because the information is not transmitted unnecessarily (see also the analytical comparison of the protocols in Section 4). Simple querying protocol: In the most simple form the server requests the location information from the source each time it is queried by an

116

Chapter 5

application and therefore does not need a secondary copy at all. This leads to the highest possible accuracy of the location information, but also to a large number of messages, if the information is queried very often. The response time of the server is also comparatively large, as the server has to contact the source for each query. The Standard Location Immediate Request of MLP defines such a simple querying protocol.

Cached querying protocol: The cached querying protocol is an optimization of the simple protocol, where the server stores a cached copy of the last transmitted location information (in ). When the location information for this mobile object is queried by an application, the server estimates the accuracy of the cached copy and returns it, if it is considered to be accurate enough. Otherwise, the server has to send a request for the location information of the primary copy to the source like with the simple protocol. A pessimistic cached querying protocol uses the distance, a mobile object may have traveled at its maximum speed for the estimation of the accuracy (see our location model in Section 4.1). If the mobile object’s maximum speed is much higher than its average speed, the cached copy is often unnecessarily considered not accurate enough. An optimistic cached querying approach could use an assumed speed that is smaller than the maximum one for example, the object’s average speed. However, with any optimistic estimation for the accuracy of the location


117

information, the actual location of the mobile object can in the worst case differ from the reported location by more than the requested accuracy. With a cached querying protocol the response time of the server is varying and depends on whether the server can use the cached copy or has to contact the source. The functionality of the cached querying protocol is shown in Figure 3. Periodic querying protocol: If the server requests the location information periodically from the source with a certain time interval T, the protocol is called a periodic querying protocol. Although here the initiative is reversed, this protocol has the same properties as the time-based variant of the reporting protocols described next. 3.1.2

Reporting Protocols

In case of a reporting protocol the initiative is on the side of the source. It remembers which location information it has sent last to the server and therefore knows which location is stored there. An update of the location information is sent, whenever a comparison to the current position of the mobile object exceeds a certain distance or time threshold. The server can therefore conclude the maximum uncertainty of its copy from the value of this threshold. With an unmodified reporting protocol the server always answers the queries of the applications by directly returning the information currently stored in its copy. It can therefore only return the location information with an accuracy specified by the value of the threshold, even if more accurate information is requested by an application. The response time of the server on the other hand is shorter, as it does not have to contact the source. A reporting protocol is usually more efficient for a given maximum accuracy than a querying protocol, if the location information is queried often (see Section 4) or the server has to check periodically for the occurrence of events.

118

Chapter 5

Simple reporting protocol: The most simple reporting protocol sends the location information each time the value of the primary copy changes, for example, because a sensor system has determined a new location sighting. In this case, the number of messages depends on the update rate of the sensor system, which may be very high. We therefore consider it here only for comparison. Time-based reporting protocol: With a time-based protocol the location information is transmitted periodically, each time a certain interval of time T has elapsed. The update rate is fixed and does not depend on the behavior of the mobile object, which guarantees a certain temporal but not a spatial uncertainty of the information. If the object moves slowly or not at all, there is little or no difference in the location information transmitted to the server. If the object moves fast, not enough messages are sent to achieve a high accuracy. With the Triggered Location Reporting Service MLP supports a time-based reporting protocol. Distance-based reporting protocol: The distance-based protocol sends an update of the location information whenever the geographic distance between the current location of the mobile object and the last reported location becomes greater than a given threshold D. As this protocol sends more messages if the mobile object is moving fast and less messages if it is slower or stationary, it is often more efficient for objects that perform sporadic movements between periods of immobility. This is, for example, typical for users in an office environment or more so when tracking the


119

location of pieces of office equipment. To guarantee a certain requested accuracy of the location information on the server the distance threshold D must be set to minus the initial accuracy of the sensor system The functionality of the distance-based protocol is shown in detail in Figure 4. It is also possible to integrate the time-based and the distancebased protocol to combine their properties.

Dead-reckoning: Dead-reckoning is an optimization of the distancebased protocol. Here, the server uses a prediction function pred( ) to estimate the current location of the mobile object based on its last reported state which contains its old location o.pos, speed o.v, the direction of its movement o.dir and maybe also information about the future route of the object12. The source also calculates this estimated location using the same prediction function and sends an update when it differs from the actual location by more than a certain distance threshold D. Variants of the deadreckoning protocol mainly differ in their prediction function. The linear prediction dead-reckoning protocol assumes that the mobile object keeps on moving along a line given by the reported position and direction with the reported speed. As shown in our simulations, this simple to implement protocol is in many cases already a big improvement compared to the distance-based update protocol, especially if the object is a car moving on a 12

If speed and direction are not directly available, they can be inferred from the last n position sightings.

120

Chapter 5

highway, reducing the number of required messages by up to 83%. Figure 5 shows the functionality of a linear prediction dead-reckoning protocol. More advanced dead-reckoning protocols have the mobile object report its future road and assume that is moving along this road with its last reported speed [18]. Or they match the mobile object’s position and course to a map and assume that it is following the current road following the most frequent direction at an intersection. 3.1.3

Combined Protocol

While a plain querying protocol cannot be adjusted to different mobility characteristics of the mobile objects, a reporting protocol does not consider the query rate and the accuracy requested by the applications. With a combined protocol, which integrates the distance-based reporting protocol and the cached querying protocol, both of these features can be achieved (see Figure 6). Similar to the distance-based reporting protocol, the source may update a secondary copy on the server to achieve a given spatial accuracy D. If the location information stored in the secondary copy is not accurate enough for a certain query, the server requests the information from the source as in a querying protocol. To minimize the total number of messages consisting of updates and requests, the combined protocol has to decide whether to update a secondary copy at all and what distance threshold D has to be used, depending on the mobility properties of the mobile object and on the queries by the applications. If the source monitors the mobility properties and the server those of the queries, they can adapt the properties of the protocol dynamically by increasing/decreasing the distance threshold D or by starting/stopping the updating of the secondary copy altogether. The decision, whether to use the secondary copy, to request the information from the source or whether to change the distance threshold, needs only to be performed when an update or query arrives. The combined protocol therefore adds some overhead to query and update processing but requires no additional timer(s).


121

With the combined protocol, the response time is again varying and depends on whether the secondary copy on the server is accurate enough or if the server has to contact the source. Instead of the distance-based reporting protocol, a combined protocol can also be based on a more efficient dead-reckoning protocol. This variant, which we do not discuss here for reasons of simplicity, will reduce the number of updates for a higher query rate, but does not change the over-all behavior.

3.2

Behavior in Case of Disconnection

A problem that frequently occurs with mobile devices and wireless data transmission is a temporal disconnection of the communication link. A protocol that is intended to transmit location information from a mobile device to a server via a wireless communication link has therefore to be able to deal with such disconnections. In the following paragraphs we discuss the properties of the update protocols with regard to disconnections, namely how long it takes to detect a disconnection and the maximum uncertainty of the location information returned during that time. Where necessary, we sketch appropriate modifications to these protocols that enable them to deal with disconnections.

122

3.2.1

Chapter 5

Querying Protocols

In case of a querying protocol, the disconnection is detected as soon as the server receives a query and requests the location information from the source (and, in case of a cached querying protocol, also can not answer the query from its cached copy). Therefore, the server does not at any time return less accurate information than in the normal case. 3.2.2

Reporting Protocols

Time-based reporting protocol: When using a time-based protocol a disconnection can be detected if no update messages have arrived after the time threshold T has elapsed since the last update. Again the server only returns location information with the specified accuracy. Distance-based reporting protocol: With the distance-based protocol alone the server is not able to detect a disconnection. Instead, it assumes that the mobile object has not moved by more than the distance threshold D and returns the old location information as being up-to-date. To be able to detect disconnections, the distance-based protocol can be combined with a timebased one, by having it send a location update at least every time interval A disconnection is therefore detected after a time interval of which results in a maximum uncertainty of the location information of A suitable value for has to be found by considering the message overhead versus the maximum uncertainty, the user is willing to tolerate in case of an error. Dead-reckoning reporting protocol: A dead-reckoning protocol has the same problems with disconnections as the distance-based protocol and the same mechanism can be used to deal with them. 3.2.3

Combined Protocol

How the combined protocol reacts to disconnections depends on how accurate a secondary copy is kept on the server. A disconnection is detected as soon as the server has to request the location information from the source. If this is not the case, the combined protocol behaves like the distance-based protocol and can return inaccurate location information. Again, a maximum time interval between update messages should be specified.

3.3

Summary

A summary of the properties for the different update protocols discussed in this section is contained in Table 1. It shows, whether the message rate of a


123

protocol depends on the mobility characteristics of the mobile objects and whether it depends on the queries of the applications. It also indicates, whether the protocol can guarantee an upper bound for the returned location information and if it allows the applications to request a certain accuracy of the information. The final column shows, whether the protocol is able to deal with disconnections.

4.

ANALYTICAL COMPARISON OF THE PROTOCOLS

In this section, the effectiveness and efficiency of the update protocols are compared in more detail, by means of an analysis. First, the variables that appear in the following analysis are described and a general data model for the location information and its accuracy is defined. The analysis considers the number of messages required for updating the location information on the server as opposed to the minimum and average accuracy of the location information returned to an application. Corresponding formulas are shown first for the querying and reporting protocols, then for a combined protocol. Finally, we discuss the characteristic properties of these protocols, based on the results of the analysis. For reasons of simplicity we do not consider the delays for the transmission of the messages, which would lead to a further (temporal) uncertainty of the location information. Because it is added uniformly to all messages, the delay does not substantially affect the comparison of the protocols. The efficiency of an update protocol is here considered to be the average number of messages m that is transmitted per second between the source and

124

Chapter 5

the server. Messages can be location updates generated by the source as well as location requests from the server. The accuracy of the location information on the server, which describes the effectiveness of a protocol, is defined by the maximum and average deviation between the information returned as a result of a query and the actual position of the mobile object. Up to now, we have assumed that applications are only interested in the maximum uncertainty of the location information, for example if they want to be able to determine which room of a building a certain user is in. However, other types of applications may be more concerned with the average accuracy of the information. An example for this could be a map, where the current location of a number of mobile objects is shown. In our analysis we have therefore considered both, the maximum and the average deviation, and The calculations for m, and are based on the behavior of the mobile object, defined by its average and maximum speed, and and on the uncertainty with which the location information is available at the source. Moreover, the calculations depend on how frequently and to what accuracy the location information is queried by the applications, which is described by the average number of queries per second q and the average of the requested uncertainty The calculations are also affected by characteristic parameters of the different protocols, namely the maximum uncertainty required of the secondary copy the speed that is assumed for the mobile object by the cached querying and combined protocol and the time threshold T for a time-based or the distance threshold D for a distance-based reporting protocol. Table 2 shows a summary of these variables.


125

Some important restrictions between these variables are as follows: Because the information transmitted to the server can not be more accurate than the information of the source, the uncertainty of the secondary copy is always equal to or greater than the uncertainty of the primary copy, Also, it is not practical for an application to request more accurate location information than the one available at the source. Hence, we also assume that For the calculation of the average deviation we assume that the average uncertainty of the location information on the source is half of the maximum uncertainty. The restrictions described here apply to all formulas in this section and are not explicitly stated again.

4.1

Location and Uncertainty Model

For the following analysis we use a uniform model of the location information returned by the different positioning systems and of its accuracy. The location information is in this work supposed to be given by global geodetic coordinates, for example of the WGS84 standard, where the distance between two locations can easily be calculated. A location sighting can have a temporal as well as a spatial accuracy. The temporal accuracy is given by the time that has elapsed since the location sighting has been acquired at time while the spatial accuracy is defined by the maximum distance between the position reported by the sighting and the actual position of the mobile object. For many location-aware applications the spatial accuracy of a sighting is more important, because the applications are concerned with the spatial relationship between (mobile) objects. The uncertainty u(t) of a certain location sighting describes the spatial accuracy at a given time At the time of the sighting the uncertainty is determined by the accuracy of the sensor system. The uncertainty at a later time t can be estimated by the distance the mobile object may have traveled during the time If a maximum bound for the velocity of the mobile object exists, the maximum uncertainty of the location sighting can be calculated by adding the distance the object can have traveled at this speed to the uncertainty of the sensor system. This is described by the following equation:

126

Chapter 5

In many cases, however, the location sighting will be more accurate than the uncertainty given by this equation, as the mobile object will not be moving at its maximum speed or not in a straight line. A person in an office will usually remain relatively stationary at a certain location (e.g., his office or a conference room) for a longer interval of time, while moving at a comparatively high speed between these locations. If the uncertainty does not need to be limited by an upper bound or the maximum velocity is not known, an assumed velocity (e.g., the average velocity of the mobile object) can be used to predict the uncertainty instead of the maximum velocity In some cases this will lead to an actual deviation, which is greater than the predicted one. This error will be worse for the sporadic movement of a person in an office, compared to the more steady movement of a traveling car (see below). Some positioning systems return symbolic location information (e.g., the name of a room) instead of geometric coordinates. Although, they are more meaningful to a user than geometric coordinates they are of less general usage. However, they can easily be converted to geometric coordinates, if there is a system, like a directory service or GIS system, which stores the geometric equivalent of the symbolic coordinates. As most location-aware applications already make use a map as part of their user interface, this information is required anyway. An example for systems capable of such a transformation are commercial Geocoding systems, which take a postal address and map it to the corresponding geographic address. For our purpose, the geometric coordinate, which corresponds to the region described by a certain symbolic name, is given by the center of the region, while the spatial accuracy is the distance from the center to the farthest point in that region. The equations for an approximate calculation of the number of transmitted messages as well as for the maximum and average uncertainty of


127

the location information are shown next for the querying, reporting and combined protocols.

4.2

Querying Protocols

Simple querying protocol: In the simple querying protocol, which is presented here only for reasons of comparison, the number of exchanged messages is equal to the number of queries as every query is forwarded to the source.

If we do not consider the communication delay, the location information presented to the applications has the same accuracy as the location information of the source.

Cached querying protocol: The cached querying protocol uses Equation 1 to estimate the uncertainty of the location information stored on the server and if accurate enough returns it without contacting the source. For the speed of the mobile object used in this formula it can take a pessimistic approach with (as shown in Figure 3), or an optimistic approach with instead of In the following considerations we represent the assumed speed of the mobile object by which is then replaced by the speed used in a concrete version of the protocol. Compared to the simple protocol, the caching approach eliminates all messages where the query falls into the period of time in which the cached copy of the location information is considered accurate enough, (derived from Equation 1). The number of messages transmitted between source and server is therefore the total number of queries, multiplied by the fraction of queries that cannot be answered from the cache, which is approximately

The maximum uncertainty of the returned location information is given by the time the cached copy is considered accurate, multiplied with the maximum speed of the mobile object. To this the initial uncertainty of the location information of the primary copy has to be added. The average

128

Chapter 5

uncertainty can be approximated by the uncertainty of the sensor system, if the location information has to be requested from the source. Otherwise, the average uncertainty is half the distance that the mobile object can have traveled at average speed during the time in which a cached copy is considered valid. The corresponding Equation 5 is shown in a simplified form.

If the assumed speed of the mobile object is set to its maximum speed the uncertainty of the location information presented to the querying application is limited by (substituting the variables in Equation 5). The protocol can therefore in this case guarantee the accuracy requested by the applications.

4.3

Reporting Protocols

Time-based reporting protocol: As the time-based protocol sends a location update periodically, the number of messages depends only on the time threshold T. To achieve a given uncertainty for the secondary copy, T has to be set to the time, the mobile object needs to cover the distance given by minus the uncertainty of the primary copy at an assumed maximum speed,

The maximum deviation can be calculated by adding the distance that the object may have traveled during time T to the uncertainty of the location information at the source. For the average deviation the average speed is used, instead of the maximum one.


129

Distance-based reporting protocol: The number of messages transmitted with the distance-based protocol is also independent of the number of queries. To guarantee a given uncertainty of the location information on the server, the distance threshold D is set to The average number of messages per second can then be calculated by the time interval that the mobile object requires to cover this distance at average speed.

If no messages are lost due to problems with the network connection, the distance-based protocol achieves he requested maximum uncertainty for the secondary copy on the server. On average the uncertainty is half of it.

Dead-reckoning protocol: The behavior of the dead-reckoning protocol is similar to that of the distance-based protocol and therefore the number of messages is also independent of the query rate q. However, the exact number of messages depends on various factors, as, for example, the movement characteristics of the mobile object and the prediction function. In many cases the required number of messages will be much smaller than for the distance-based reporting protocol (see our simulations in Section 5). However, when using an unfavorable prediction function it can also become larger. If is the performance gain of the dead-reckoning protocol, the number of update messages is as described by Equation 10. As deadreckoning protocols are addressed in detail by our simulations, we do not further go into detail here.

Because the dead-reckoning protocol uses the same criterion for updating the location information on the server as the distance-based protocol, it results in the same maximum and average uncertainty on the server:

130

4.4

Chapter 5

Combined Protocol

The combined protocol comprises elements of the distance-based reporting protocol and the pessimistic cached querying protocol. The transmitted messages are the updates sent to keep the secondary copy up-todate as well as the requests for the location information on the source sent by the server, if the secondary copy is not accurate enough. The number of updates can be calculated similar to the number of messages in the distancebased reporting protocol. However, their number, similar to those of the requests, has to be reduced by those that have become unnecessary because of already cached request results. The number of requests is the number of messages in the cached querying protocol, where the query rate is reduced by the probability that the uncertainty demanded in a query is lower than the accuracy of the location information already stored in the secondary copy, This probability distribution depends on how the location information is queried and used by the applications.

Because the combined protocol queries the source whenever the location information stored in the server is less accurate than the accuracy demanded in a query, it can always return the desired accuracy similar to a cached querying protocol. The maximum uncertainty returned is therefore the uncertainty demanded in the queries. The average uncertainty is again a combination of the average accuracy of the reporting and querying protocol.

The behavior of the combined protocol can be controlled through the uncertainty of the secondary copy. If it is set to a low value, the protocol behaves like the distance-based reporting protocol, if it is set to infinity, the combined protocol can be made to behave like a cached querying protocol.


4.5

131

Discussion

In this subsection, we will use the results of the analysis for a comparison of the protocols. Because their behavior depends to a great deal on the mobile object’s movement characteristics, we will look at four different types of mobile objects to The values for the average speed have been taken approximately from the GPS traces that we have recorded for our simulations in the vicinity of the city of Stuttgart, Germany. These types of mobile objects will therefore also appear in the simulations in Section 5. A walking person with an average speed of (4.68 km/h) and an assumed maximum speed of A car in city traffic with an average speed of (36 km/h) and an assumed maximum speed of A car in inter-urban traffic with an average speed of (61.2 km/h) and an assumed maximum speed of A car on a freeway with an average speed of (104.4 km/h) and an assumed maximum speed of For the sensor system we assume in all cases a Differential GPS with an accuracy of 5 meters which we have used to record our GPStraces. The accuracy demanded in the queries is, except for the combined protocol, fixed to

132

Chapter 5

We first look at the efficiency of the protocols, that is the number of messages that are transmitted between source and server. These are shown in Figure 8 for the querying and reporting protocols depending on the number of queries per second. Obviously, the number of transmitted messages has to increase with a higher average and maximum speed. In general, a distance-based reporting protocol performs better than the time-based one and the optimistic cached querying protocol better than the pessimistic one. As can be seen in Figure 8, the difference is more marked for a mobile object with a lower ratio of average to maximum speed, such as While the properties of the reporting protocols are independent from the query rate, the number of messages increases with a querying protocol with the number of queries. The query rate at which the performance of the distance-based reporting protocol becomes better than that of the pessimistic cached querying protocol, which is also able to guarantee a certain accuracy of the returned information, is given by the following in-equation, obtained by combining Equation 4 and Equation 8:


133

In case of a fixed requested accuracy and a sensor uncertainty that is small compared to it, this equation can be expressed in a more simple form:

If is low compared to which is the case for mobile objects with more sporadic movements, the distance-based reporting protocol performs better than the cached querying one, most of the times. The other important aspect of the update protocols is their effectiveness, that is to what degree the server can fulfill the accuracy demanded in a

134

Chapter 5

query. The maximum and average uncertainty ( and of the location information returned by the server is shown separately for the two cached querying and the two reporting protocols in Figure 9. The uncertainty is shown depending on the speed ratio between the average and the maximum speed of the mobile object which gives a good indication of its mobility characteristics. A mobile object with a lower ratio moves more sporadically (e.g., as compared to ), while an object with a ratio approaching 1 moves more steadily. For the graphs we have assumed a query rate q of 0.1 queries per second. Figure 9 shows that all besides the optimistic cached querying protocol can meet the required accuracy independently from the mobility of the object. The optimistic cached querying protocol is especially not suited for objects with sporadic movements as in this case its maximum uncertainty becomes very bad. While the other protocols meet the accuracy requirements, the pessimistic cached querying protocol additionally has a better average uncertainty of the position information for objects with a lower speed ratio, compared to the distance-based reporting protocol. As mentioned before, the performance of the combined protocol depends on the uncertainty with which the secondary copy is updated as well as on the query rate. In Figure 10a, the number of transmitted messages is shown for and the combined protocol depending on the uncertainty of the secondary copy and the query rate. For the uncertainty demanded in the queries we have assumed a Gaussian distribution with an expected value of and a standard deviation of 20 m. All other parameters have the same values as before.

Figure 10a indicates an optimal value for the uncertainty of the secondary copy for higher query rates, whereas for lower query rates the


135

number of messages is lowest, if the uncertainty is set to infinity. As stated in Section 4.4, it is therefore possible to use Equation 12 to decide, whether it is useful to update a secondary copy at all and to find an optimal uncertainty value for it depending on the query rate. For comparison with the other protocols, Figure 10b shows the number of messages transmitted with the combined protocol depending on the query rate for objects to Optimal values for the uncertainty of the secondary copy have been taken from Figure 10a and similar figures. The combined protocol integrates the positive features of the more simple querying and reporting protocols. Although, for a higher query rate it is less efficient than the distance-based reporting protocol, it requires much less messages for a low query rate, similar to the querying protocols. Unlike the reporting protocols, it is also able to meet an arbitrary requested accuracy. Its disadvantages are that it is more complicated to implement, because an optimal value for the uncertainty of the secondary copy has to be found. In summary, the combined protocol is suitable for most cases, especially if a protocol is needed that performs equally well in different environments or even can adapt to them. Of the querying and reporting protocols the pessimistic cached querying protocol and the distance-based protocol are to be preferred, because they combine an upper bound for the spatial accuracy of the returned location information with a good efficiency. Of these two, the former is decidedly better for objects with sporadic movements and for higher query rates, but does not allow the accuracy of the location information to be requested on application-level.

5.

SIMULATION RESULTS

To evaluate the presented update protocols and our analysis of their behavior, we have performed a number of simulations based on actual GPS traces, which we have recorded in the surrounding area of Stuttgart, Germany. As the performance of the protocols, especially that of the deadreckoning protocol, depends to a great deal on the mobility characteristics of the mobile objects, we have recorded GPS traces for four different types of objects (see also Section 4.5): a walking person a car in city traffic a car in inter-urban traffic a car on a freeway

136

Chapter 5

Table 3 summarizes the properties of these traces13. The traces have been obtained using a Differential GPS receiver, which has an accuracy of 2-5 m. Its output has been written to a file every second.

We have implemented a simple simulator, which realizes a location source with a primary copy and a location server with a secondary copy of the location information for one mobile object. The information on the source is updated from the GPS trace, while the server receives randomly created location queries with an exponentially distributed time interval and a fixed requested accuracy, in case of a reporting protocol, or a Gaussian distributed requested accuracy, in case of the querying and combined protocols. The mean value for the exponential distribution of the time interval between queries is the inverse of the query rate q. The fixed accuracy requested in the queries is 100 m for the basic protocols. The Gaussian distributed accuracy for the combined protocol has a mean value of 100 m and a standard deviation of 20 m.

13

Note that it is difficult to obtain an exact value for the maximum speed from a GPS trace, because of the inherent uncertainty of the sensor information.


137

Into this simulation environment different update protocols can be inserted, which specify, how the source and server react to incoming updates or queries and how the location information is transmitted. As in the analysis, the delays for transmitting the messages are not considered. Figure 11 shows the results of the simulation runs for the distance-based reporting, the pessimistic cached querying, the combined and the linear prediction dead-reckoning protocol. The parameter settings are similar to those used in the analysis (Section 4.5). In general, these simulation results confirm the assumptions we have made for the analysis. The number of messages for the cached querying and combined protocols is a little higher. The reason for this is that the location information queried at the source is not determined exactly when queried, as we have assumed there. Instead, it has already an average age of where is the update interval of the sensor system (in our case 1 s), which becomes relevant for larger query rates. In all cases, the linear prediction dead-reckoning protocol has performed much better than the distance-based reporting protocol. For the given setting it reduces the update rate by 53%, in case of a walking user, and by 83%, in case of a car on the freeway.

138

Chapter 5

In our simulations we have therefore looked in more detail at the deadreckoning protocol. In Figure 12 the number of update message is shown when using a distance-based reporting and a linear prediction deadreckoning protocol for the different types of movement characteristics. In each graph the uncertainty requested at the sink is varied from 20 m to 500 m in case of a car and from 20 m to 250 m in case of a walking person. For more details the interested reader is referred to [12].

The results show that the dead-reckoning algorithm with linear prediction is in all cases an improvement on the distance-based reporting protocol. As expected, the improvement is more marked for a car on the freeway (reducing the update rate by up to 83%) than in city traffic (up to 63%). The reason is the much more steady traffic, with respect to changes in speed and direction as well as to the number of intersections, on a freeway. Also, improvements decrease for a larger requested uncertainty of the location information as with a longer update interval it becomes more likely that the object changes its course. There is a small performance decrease at the lowest considered uncertainty of 20 m, because of the influence of the uncertainty of the GPS receiver.


139

To determine the maximum and average resulting deviation, we have performed further simulations for the four types of mobile objects, to with the pessimistic and optimistic cached querying, the distance- and timebased reporting and the combined protocol. The results of these simulations are depicted in Table 4. The query rate has been set to 0.1, while the other parameters have the same values as before. As we have assumed an upper bound for the maximum speed of the mobile objects that is higher than the actual maximum speed in the GPS traces, the maximum deviation for the pessimistic cached querying, the timebased reporting and the combined protocol is considerably lower than (reflecting ). Otherwise, the simulation results generally match the outcome of the analysis, with only the optimistic cached querying protocol not being able to guarantee the requested accuracy of 100 m. In comparison to the number of transmitted messages, the results for the deviations (especially for the maximum one) are, however, more susceptible to short omissions in the sensor data, which can lead to a higher deviation than 100 m if they are not preprocessed accordingly.

6.

CONCLUSION

In this chapter, we have provided a classification of protocols that are suitable for continuously transmitting highly accurate location information. We have discussed different protocol variants and compared them according to their effectiveness and efficiency for characteristic types of mobile objects. Especially the class of dead-reckoning protocols has the potential to reduce the number of required update messages, while still being able to guarantee a certain requested accuracy. More advanced dead-reckoning protocols (such as a map-based protocol) promise to reduce the number of required messages still further. With the help of the analysis presented in this chapter a suitable protocol can be found for a given scenario. Furthermore, the analysis gives an

Chapter 5

140

estimation for the expected network load and the average uncertainty of the transmitted location information, as well as an upper bound for its maximum uncertainty. Based on the querying and reporting protocols, we also proposed a combined protocol that integrates most of the advantageous properties of the basic protocols. Here, the analysis can give optimal parameter settings for a certain environment. Finally, we validated our analytical results by means of a simulation based on real-world GPS traces.

Literature [1]

[2] [3]

[4]

[5]

[6] [7] [8]

A. Bhattacharya and S. Das, LeZi-update: An information-theoretic approach to track mobile users in {PCS} networks. In Proceedings of the Fifth Annual ACM/IEEE International Conference on Mobile Computing and Networking, pages 1-12, Seattle, WA, USA, 1999. ACM Press. A. Bar-Noy, I. Kessler, and M. Sidi, Mobile users: To update or not to update? Wireless Networks, 1(2): 175-185, July 1995. K. Cheverst, N. Davies, K. Mitchell and A. Friday, Experiences of Developing and Deploying a Context-Aware Tourist Guide: The GUIDE Project. In Proceedings of the Sixth Annual ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom 2000), pages 20-31, Boston, MA, USA, 2000. IEEE Computer Society LAN MAN Standards Committee, Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specification. The Institute of Electrical and Electronics Engineers, New York, 1997. IEEE Std. 802.11. A. Harter, A. Hopper, P. Steggles, A. Ward, and P. Webster, The anatomy of a context-aware application. In Proceedings of the Fifth International Conference on Mobile Computing and Networking (MobiCom '99), pages 59-68, Seattle, WA, USA, 1999. ACM Press. J. Hightower and G. Borriello, Location Systems for Ubiquitous Computing. In Location Aware Computing, IEEE Computer 34(8): 57-66, 2001. IEEE Press. B. Hofmann-Wellenhof, H. Lichtenegger, and J. Collins, Global Positioning System: Theory and Practice. Springer-Verlag TELOS, 1997. National Imagery and Mapping Agency, DoD, World Geodetic System 1984, its definition and relationship with local geodetic systems. Technical Report 8350.2, Third Edition, National Imagery and Mapping Agency, 1997.


[9] [10]

[11]

[12]

[13] [14] [15] [16]

[17] [18]

141

Nokia Networks, Nokia Artuse Gateway Mobile Location Center. Web-page, URL: http://www.nokia.com/pc_files/GMLC_datasheet.pdf, 2001. J. Jannink, D. Lam, N. Shivakumar, J. Widom, and D.C. Cox, Efficient and flexible location management techniques for wireless communication systems. In Proceedings of the Second ACM International Conference on Mobile Computing and Networking (MobiCom '96), pages 38-49, Rye, NY, USA, 1996. ACM Press. Location Inter-operability Forum, Mobile Location Protocol Specification. Approved Specification, LIF TS 101 v2.0.0, URL: http://www.locationforum.org/publicdownload/ LIF-TS-101v2.0.0.zip, 2001. A. Leonhardi, C. Nicu and K. Rothermel, A Map-based Deadreckoning Protocol for Updating Location Information. Accepted for the 2nd International Workshop on Parallel and Distributed Computing Issues in Wireless Networks and Mobile Computing (IPDPS/WPIM 2002), Ft. Lauderdale, FL, USA, 2002. U. Leonhardt, Supporting Location-Awareness in Open Distributed Systems. PhD thesis, Imperial College of Science, Technology and Medicine, University of London, 1998. M. Mouly and M.-B. Pautet, The GSM System for Mobile Communications. Cell & Sys, France, 1992. C. Perkins (editor), IP mobility support. RFC 2002, IETF, 1996. M. Satyanarayanan, Fundamental challenges in mobile computing. In Proceedings of the Fifteenth ACM Symposium on Principles of Distributed Computing, pages 1-7, Philadelphia, PA, USA, 1996. ACM Press. R. Want, A. Hopper, V. Falcao, and J. Gibbons, The active badge location system. ACM Transactions on Information Systems, 10(1): 91-102, 1992. O. Wolfson, A.P. Sistla, S. Chamberlain, and Y. Yesha, Updating and querying databases that track mobile units. Distributed and Parallel Databases Journal, 7(3): 1-31, 1999.


Chapter 6 Geographic Search Engines

Andrew Daviel, Felix Kaegi Geotags, Inc

1.

INTRODUCTION

Most people now are familiar with the concept of a "Search Engine" on the Internet, such as Google or the original WebCrawler. These search engines perform what is termed "open text" search, where the user enters some keywords or phrases, and the search engine returns a list of pages that contain one or more of them. Many people are also familiar with the concept of a Metadata search, though they may not realize it. Most public libraries have an index, usually now on computer, and the user can search it for particular items. It is not possible to search for phrases within books, instead one must search for information about a book, such as Author, Subject or Title. These entries are termed Metadata (data about data) and in libraries have historically been compiled manually. HTML documents have historically contained only one explicit item of metadata - the title - but may optionally contain arbitrary metadata using the HTML META element, most commonly Description and Keywords. Opentext search engines such as Google index some of this metadata, but treat it as part of the text (although some elements such as Title may be preferentially weighted compared to words in the body of the document)

144

Chapter 6

A text search is not the only possible form of search, however, although it is now the most ubiquitous. For instance, a researcher might wish to find places which have less than ten centimetres of rainfall a year, or a motorist may wish to find the nearest service station. This kind of search is usually done with a database where it is known that certain fields have specific properties, such as being numeric. The Geotags search engine described here is an example of a locationbased search engine - that is, one that can answer the question "Where is the nearest restaurant ?".

2.

HTML MARKUP

While a normal search engine ranks pages according to their relevancy and popularity, the Geotags search engine ranks them according to their distance from a particular point. For this to be possible, each page must be identified with a geographic position. Currently, it is required that each page submitted to the search engine to be indexed must include geographic metadata in the form of HTML META elements. The META element is familiar to a majority of document authors since keywords and description identifiers may be used to influence many search engine results. The format of position data used for the search engine was chosen to be simple, compact and unambiguous, since it is believed that in many cases this data will be transcribed from navigation units, gazetteers or other documents and manually added to web pages. Two elements are used; a (Latitude, Longitude) coordinate pair given in decimal degrees of arc, and a region code taken from either ISO 3166-2 or ISO 3166-1. These region codes form a restricted vocabulary that is unambiguous and suitable for machine interpretation. These two metadata elements may be easily added to existing HTML or emerging XHTML documents, and are in a standard form understood by many HTML authoring software packages and human authors. The following are examples of the position and region elements:

<meta name="geo.position" content="48.04;123.45"> <meta name="geo.region" content="CA-BC">

6. Geographic Search Engines

145

This describes a location in Vancouver, Canada (hence region "CA" (Canada), "BC" (British Columbia) at Latitude 48.04 degrees North, Longitude 123.45 degrees West (positions West of Greenwich are represented by negative Longitude).

3.

WEB TRAVERSAL AND INDEXING

The search engine described here is intended as a demonstration only and is not suitable for large-scale use. In operation, a single-threaded web crawler traverses HTML documents and builds an index in real-time. The crawler maintains two databases, one of document URLs and one of weighted keywords. Associated with each URL is metadata such as traversal timestamp, HTTP status code, position data and region code, if present, plus a list of keywords. Associated with each keyword is a list of URLs, each with position data and modification time. This is similar in concept to other search engine robots, with the addition of position data. Large search engines may run thousands of threads in parallel, while many engines index documents offline, after completing a run. The region code is currently not used directly for searching, but is used as a validity check on the position data. It is quite common for authors to become confused over quadrants, for instance, and wrongly assign a Longitude in the Eastern hemisphere for a location in the USA. The engine maintains a list of bounding boxes for many countries and regions which permits a simple check on Latitude and Longitude values. Since the penetration of the geographic metadata into the Web is extremely small, the crawler, which only indexes pages with valid position data, does not at present crawl the Web in the normal sense. Instead, it merely indexes documents submitted by users. However, it would be possible for a large search engine to seek position metadata in its existing page database and use that to feed a geographic search interface. In recent development, the original web traversal robot and indexing engine have been replaced by the open-source robot ht://Dig. This offers a number of improvements in indexing and search algorithm over the one based on VWbot, such as the use of a compressed database and fuzzy searching with soundex or metaphone algorithms. In order to do this, a number of additions were made to the htdig and htsearch components. Changes to the traversal and indexing program "htdig" include the ability to record geotag metadata within a document, and also to permit this metadata to influence the decision to traverse and index documents. Normally

Chapter 6

146

traversal is controlled in a similar manner to VWbot by using a depth limit, and by regular expression within the URL. This allows traversal to be limited to one or more domains, for instance. The changes made allow htdig to traverse a document having either region or position metadata, and to index only documents having position metadata. In this way a number of documents at one site may be indexed when only one is submitted, providing that they have geotag elements.

4.

SEARCH ALGORITHM

The search engine described here does not use a true geographic search algorithm; instead it performs a keyword search and then qualifies the results using position data. This is a somewhat easier task, and in the context of a general Web search is more useful. The user interface is presented as a graphic map and a text input box. The user enters search keywords in the text box and then clicks on the map to enter a search position. The search keywords are looked up in the database to yield a list of matching pages. For each page, if its position falls outside the boundary of the map it is ignored. The great circle distance is then calculated between the search position and the geographic position associated with each page. This list is sorted by inverse distance and presented to the user. The great-circle distance between two points (x1,y1) and (x2,y2) may be approximated by:

2 x atan(sqrt(a)/sqrt(1-a)) x 60 x 1.852 x 180/pi where

a = (sin((y2-y1)/2))**2 + cos(y1) x cos(y2) x (sin((x2-x1)/2))**2 A selection box allows the user to alternatively sort by keyword match quality or by document modification time (most recent first). In the demonstration search engine keyword weighting is quite simple based on HTML elements such as title etc. In future versions a relevancy ranking might be used, or distance weighting combined with other rankings to present "nearest useful resource" first instead of "nearest matching resource".


147

The search engine from ht://Dig, htsearch, has been modified to allow geographic searching in a similar manner, by adding a "by-distance" weighting to the search. As in the original search engine, one or more keywords are required in order to return a list of matching pages, which may then be sorted in order based on great-circle distance.

5.

PRESENTATION14

The search results presented in response to a query consists of two parts; a hypertext list of matches, and a graphic representation of the position of each match overlaid on a map of the area of interest. The icons overlaid for each match form hyperlinks to the associated matching document, while the remainder of the map area may be used to enter a new position-based query using the current text search terms. Figure 1 shows the marked-up map for a match located in Paris, where the hit is indicated by a circle. Figure 2 shows a corresponding browser window.

14

The demonstration search engine described here may be found at http://geotags.com.

148

Chapter 6

Overlay of match icons is achieved by markup of a static image using elements available in the cascading style sheet language (HTML CSS). Consecutive searches in the same area will use the same map image from browser cache, thus reducing latency.


6.

149

MAP CACHING

Typical user behaviour while operating the search engine may be to initially enter a search term using a "world" view, then zoom in to see the area of interest. They may then refine their search, while keeping the same view, or may pan back and forth or zoom in or out. It is quite likely that they will wish to revisit a particular map more than once. In order to reduce latency, and thereby user frustration, it is important to ensure that the map images are easily cacheable and that the proportion of cache hits is as high as possible. When this is done, the map image can be made larger and more

150

Chapter 6

detailed than would be the case if it must be retrieved from the origin server for each new query. In order to achieve this goal, two methods are used: map quantization and URL rewriting. The image forming the map is retrieved from a unique URL which contains values for the latitude, longitude, scale factor and level of detail. If raw values derived from user clickpoints are used for these quantities, the number of possible different images is extremely large and cache hit rate correspondingly small. To avoid this, the values are quantized in the search engine by rounding to a given precision. For instance, the user may have requested a map centered on (48.134,1.33) with scale 23.4, but is presented with one centered on (48.1,1.3) with scale 25. This technique limits the number of possible maps, and allows more effective use not only of the users browser cache, but also of content mirroring, server cache (if the maps are generated dynamically) and hierarchical cache. In order to operate effectively with hierarchical and public cache systems, e.g. Squid, a URL rewriting technique is used. The URL request generated by the users browser in response to a search is an HTTP GET operation including a query term (using a "?" character). This query includes the required values for map position and scale. Since queries are essentially open-ended and are not often repeated, most public cache systems do not store the responses. In the demonstration engine, the map URLs are rewritten into a form that does not include a "?" character or the stopword cgi-bin. If it is desired to control staleness of map images in order to deploy updated information, HTTP headers such as Expires and Cache-Control may be used.

7.

MOBILE APPLICATIONS

If the client device is a mobile workstation equipped with a navigation unit such as GPS, then the client location may be sent automatically to the search engine as the default search position. One method which may be used is to include the position data in the HTTP request using extension headers. If this is done, then the graphic map may be dispensed with and only the text matches displayed on the client device, making a geographic search practical on text-only devices such as cellular phones. This concept has been successfully tested using a modified version of the Mozilla browser and synthetic data. In this scheme, a geo-enabled browser sends a query position as an HTTP header, for instance:


151

geo.position: 48.54;-123.84;120 In order to accomodate privacy requirements, the browser may have a dialog with a geo-enabled server whereby the server declares its willingness to accept geographic information by issuing an accept-geo header, and the browser then uses the current user preferences together with encryption and authentication information before sending position data. The risk here is of someone being able to determine a user's position by techniques such as sending them email with a web bug on a geo-enabled server, or identifying home users without their consent by correlating position with home ownership records.

8.

GEOGRAPHIC DATUM

Historically, maps and nautical charts have been referenced to a local datum in each different region which was established by traditional surveying techniques. With the advent of satellite navigation systems, world geodetic systems were created which establish a single datum worldwide. Positions measured using this datum are referred to an imaginary surface called a geoid, which approximates to the surface of the earth at sea level. The datum chosen for the search engine described here is WGS84, the one used by the US GPS navigation system. Adoption of this single datum for position data means that it is not necessary to introduce extra data elements to describe the datum, nor to include conversion routines in the search engine. For many applications the position is known to less precision than the offset between datums; however in some regions this offset may amount to several hundred metres in horizontal distance and tens of metres in vertical distance.

9.

ADVANCED GEOGRAPHIC SEARCHING

At this time, only a search ranked by distance is available from Geotags.com. However, other search techniques are possible, for instance a search within an area or a search within a volume. An areal search may be within a rectangular area, defined by North, South, East and West boundaries, or within an irregular area, defined by a polygon. The page coverage may be an area, while the search defines a point. This kind of search could be performed by the existing Geotags.com

152

Chapter 6

interface, to answer questions such as "which electoral riding is my house in ?", given a single clickpoint on a map. In this case, it is necessary to associate a polygon (or rectangle) with the page, which could be done by introducing additional metadata elements. This kind of search is performed by a polygon inclusion algorithm, and is familiar to many users since it is used in HTML imagemaps, for instance for selecting a country or continent from a map. It would also be possible for the user to specify a search area, where the pages are identified by a point. This is the inverse of the previous case, and corresponds to a question such as "What restaurants are within 3 blocks of my office ?". Currently, there is no way for a user to define a search area at Geotags.com, although the visible map is used as an implicit search area. A Java applet could be used to draw a search area like this. Representing a closed polygon is relatively simple and intuitive - an ordered set of coordinate pairs defines the vertices of a polygon in the order in which they are drawn. It is also possible to define a three-dimensional search volume. This might correspond to questions about mineral deposits beneath the ground, or to the location of fire extinguishers in a building. It is less easy to see how to define the volume in terms of coordinates. However, a mathematical construct known as a convex hull may be used to define a volume that is "convex" - essentially, without holes or dents. Fortunately, this includes many common structures such as buildings, and more complex shapes may be defined as a collection of convex hulls. A convex hull may be defined by an unordered set of coordinate triples (x,y,z), and may be thought of as the shape of a balloon allowed to deflate around a wire cage joining the points. In the case of a rectangular building, perhaps with a pitched roof, it is necessary only to list the coordinates of all the corners in arbitrary order to define the volume.

9.1

Keywordless Searching

The CoolTown project initiated by Hewlett-Packard offers a vision where keywordless searching may be useful. In this vision, people, places and objects in the real world have a corresponding presence on the Web, creating something akin to the "cyberspace" envisioned by Vernor Vinge and William Gibson. In the traditional Web, objects tend to be linked along contextual or descriptive lines. For example, a page may have links to the next page in a document, or to a more detailed description of an object, or to


153

related material on the same topic. Navigation proceeds in pursuit of an idea, either sequentially along a series of pages, or by picking links from a list such as the results page from a text-based search engine. There is no concept of space, in the sense of a two or three-dimensional space in which one can navigate in the traditional sense of moving linearly from point to point (although projects such as Tim Bray's antarcti.ca have explored the idea of mapping knowledge to a two-dimensional representation). In the online ecosystem envisioned by CoolTown, the Web is richly populated by objects and places that have a physical existence at a defined location. In this scenario, it is possible to navigate the Web using a walking or flying paradigm as used in VRML viewers. Simple examples of this in HTML may be seen in the TRIUMF CyberTour or the "Colossal Cave" translation where movement is accomplished by clicking direction buttons such as "East" or "North". In this type of environment, a keywordless geographic search may be useful to identify nearby objects which are otherwise unrelated except by their location; they may belong to different people or organisations and their online identities may be hosted at different service providers. In a private space, such as a museum, it is likely that objects would be registered by the owner of the space (the museum curator), but in a public space, such as a street or a city, this may not be feasible and a search engine would be an efficient mechanism for registering the presence of fixed objects.

9.2

Keywordless Search Algorithms

In a simple keyword-based search, words in a document may be sorted into alphabetic order, as in a dictionary, into a single dimension which may be thought of as points on an imaginary line from A to Z. A binary search algorithm may be used as one might look for a word in a dictionary, deciding first if the word comes before or after "M", then before or after "F". This is a much more efficient method than starting at "A" and comparing the desired word to every single word in the dictionary, in order. A keywordless geographic search cannot take advantage of this onedimensional space (the alphabet) but must instead search in a two or threedimensional space. Algorithms for this purpose (and indeed for higherdimensioned spaces) are described in the literature, for example Mount, Sproull. One such algorithm is the k-d tree described by Bentley. Figure 3 shows a k-d tree structure generated from a set of data points representing major cities around the world on a Mercator projection, generated by ANN .

154

Chapter 6

In this method, the data space is recursively split into cells containing some defined maximum number of points. These algorithms typically require a certain amount of processing time to sort the datapoints first in order to give a quicker search phase. In terms of a search engine on the Web, the sorting phase would be done when the documents are indexed and so not be apparent to the user. These algorithms could equally be applied during the presentation phase of a keyword-based geographic search such as the current Geotags. It may be significantly more efficient to use a Euclidean flat-earth distance calculation than the more accurate great-circle calculation, since it requires less compute time, giving a quicker search. During the presentation phase, the great-circle distances may be calculated only for the results being presented.

9.3

Applications of Keywordless Search

A keywordless search in a rich environment performed using a traditional computer is likely to be of limited use, since the amount of data may be overwhelming and take too long for the user to assimilate. This effect may


155

be likened to someone on safari leafing through a field guide to discover whether an attacking animal is dangerous. There may, however, be occasions when this approach is valuable, such as in a police investigation, in archaeology or in more mundane excavation to check for buried cables etc. In these situations the user has time to perform a careful search, and the geographic search may offer a quicker or more convenient way to discover the required information. In the future there may be various types of non-traditional computing device better suited to keywordless search. Traditional here refers to a device with an opaque screen on which the computer displays text and graphics, equipped with a keyboard and pointing device which is used to input commands and data. This kind of device demands the majority of the user's attention, and cannot be used while driving, walking down the street, or carrying out any other significant activity. Future devices may include voice input and output, and various kinds of transparent display, such as the "heads up" displays used in military and some civilian aircraft. In these displays, computer-generated information is overlaid on the real-world view; for example an aircraft display might show an artificial horizon and airspeed, or threat data for hostile airplanes. A portable device may be contained in a handheld unit such as a pair of binoculars, mounted on a helmet or a pair of eyeglasses, or even in the future implanted directly into the user's body. Many groups, both civilian and military, are working on this kind of device, for instance Steve Mann at the University of Toronto and Microvision, Inc. who have recently announced a commercial helmet-mounted unit. In order to obtain a useful level of functionality, a number of elements need to be present, either combined together in one device as in a pair of binoculars, or split among several units connected with a communications channel such as Bluetooth. These elements are a processing unit, display, locator, orienting unit, input unit, and Internet connection. The locator would typically be a satellite-based system such as GPS or GLONASS, though an auxiliary system may be required in situations of low signal strength such as indoors. The orienting unit is used to determine the direction of view, and might be a fluxgate compass or laser gyrocompass. It may also be useful to have a ranging unit to find the distance of a viewed object. Using these features, the device is able to determine where the user is geographically, which direction they are facing, and potentially what they are looking at. By means of the geographic search engine, it is able to

156

Chapter 6

overlay the user's vision with information about objects in their field of view. Present displays would display this information at a fixed focal distance, typically infinity, while future devices may be able to use holographic techniques to position virtual objects at arbitrary points in three dimensions. Another possible feature is a camera and artificial vision system, able to register objects visually - if the computer knows that a certain object is in a certain position, and has shape data available on that object, it will be able to index individual features in the field of view, such as a particular window on a building or a particular feature on a painting. Within a private space, where all the data belongs to one entity, there are many possible applications for a lightweight device such as this. Instructions and diagrams could be provided for people doing maintenance on complex equipment such as aircraft, or provided for expert surgeons who may be using unfamiliar equipment. Within a public space such as a city, where the data belongs to many different entities, a geographic search engine becomes more relevant. There are many applications possible here also. One might imagine a tourist visiting a historic city such as Paris or New York which has a variety of historic public buildings, entertainment venues, museums and so on. A heads-up data display could provide information about these places such as identity, history, opening hours, special events and so on. With suitable control over the display brightness it should be possible for wearers to safely walk around - or at least, as safely as those currently using cellphones or personal stereos. Another application that has been suggested is using position sensitive devices and the Internet to position messages in space and time. When a user approaches the location of the message it is delivered to him, via display device or a cellphone. This might be seen as a novelty application - it could be used for games, for instance, such as a treasure hunt - or it could be used to deliver advertising. One fictional application described in the book "Giant's Star" is the use of this kind of framework for teleconferencing. In this vision, it is possible for any place within a "wired" environment to be used for impromptu conferencing, in which some participants are physically present and others are added in virtually by the conferencing software. In the book, remote participants saw a synthetic computer-generated view, but it was not clear how local participants saw them in turn. In one possible implementation, local participants see a hologram of remote participants in a heads-up


157

display, while they see the physically present participants using a conventional camera, possibly mounted on a mobile unit such as a robot. In this way a virtual reality space in which participants are seen as avatars is overlaid on a real space, using geographic data to register the two.

9.4

Zipcode Searching

Currently, there are very few documents on the Web that have been marked up with explicit position data suitable for the Geotags robot. However, there is a considerable quantity of material that contains implicit position data in the form of addresses and telephone numbers. This information has been used commercially for geographic profiling and many databases are available of location data. If it is possible to identify a postal address associated with a particular document, then a tentative position may be assigned to it. In some cases, such as with the rectangular grid numbering scheme used in many North American cities, it may be possible to interpolate a relatively accurate position from a street name and number, or it may be possible to derive a position from an identifiable string such as a zipcode (postcode) or telephone number. There are a couple of drawbacks to this method. One is that there is no way of knowing that an address on a given page in fact refers to the page content. In some cases, such as a business listing for a restaurant or bed-andbreakfast establishment, this may be true, but in many other cases an address given may be that of an agent, a publisher, or other entity different from the resource described in the document. Thus a search for a particular wild orchid may return the address of the photographer rather than the place where it may be found. The other drawback is that postal codes were designed for delivering mail and were never intended to indicate geographic location. For instance, postcode regions are irregularly shaped and of very different sizes. In particular, rural codes may be thousands of times the size of urban ones, and where maildrops are used, may not correspond to a street address at all. A similar consideration applies to telephone area codes and exchange prefixes, which may also change from time to time as the telephone system is upgraded.

158

10.

Chapter 6

PROPERTY RIGHTS ISSUES

Although in theory there can be an infinite number of virtual spaces congruent with the real world, much as there can be an arbitrary number of discussion groups on the same subject, each with its own rules, in practice there may be only one such virtual space, much as there is arguably only one Web. The geographic search engine discussed earlier sees only one space, if a common geographic registration scheme is used. There is then a question of ownership of private and public space. It might be argued that property rights in the real world be extended into the virtual world, though this might be hard to enforce. This would mean, for instance, that someone could not place an advertising banner inside your house, or in an operating theater. However, this material might be placed legitimately in the owners private space, such as on a storefront. It might also be placed in a public space, as a kind of virtual fly-poster, in front of public buildings or in front of competitors businesses. Left unrestricted, an intolerable situation could develop with advertising material being placed in the same kind of manner that some unsolicited mail is sent now, or defunct messages remaining in place long after the thing they were promoting has disappeared. Since the choice of which objects to present is left to the search engine (and the user), various methods to filter objects might be adopted, ranging from simply demanding payment for placement in certain areas, to sophisticated spambusting algorithms, to a legislated solution, in which objects in violation of the law would simply be de-listed by the search engine.

11.

REFERENCES

HTML HTML 4.01 Specification: Arnaud Le Hors, W3C, Ian Jacobs, W3C; 1997-1999 W3C. Available at: www.w3.org/TR/html4/ ISO3166-1 International Organization For Standardization / Organisation Internationale De Normalisation (ISO), "Standard ISO 3166-1:1997: Codes for the Representation of Names of Countries and their subdivisions -- Part 1: Country codes", 1997. ISO3166-2 International Organization For Standardization / Organisation Internationale De Normalisation (ISO), "Standard ISO 3166-2:1998: Codes


159

for the Representation of Names of Countries and their subdivisions -- Part 2: Country subdivision code", 1998. GPS ARINC Research Corporation, "Navstar GPS Space Segment / Navigation User Interfaces", in: IRN-200C-002, September 1997 WGS84 United States Department of Defense; DoD WGS-1984 - Its Definition and Relationships with Local Geodetic Systems; Washington, D.C.; 1985; in: Report AD-A188 815 DMA; 6127; 7-R-138-R; CV, KV; WebCrawler Brian Pinkerton, Finding What People Want: Experiences with the WebCrawler. in: The Second International WWW Conference Chicago, USA, October 17-20, 1994. Available at: info.webcrawler.com/bp/WWW94.html Google Sergey Brin and Lawrence Page, The Anatomy of a Large-Scale Hypertextual Web Search Engine, in The Seventh International World Wide Web Conference (WWW7), Brisbane, Australia, April 14-18 1998. Available at: www7.scu.edu.au/programme/fullpapers/1921/coml921.htm CSS Häkon Wium Lie, Bert Bos,Cascading Style Sheets, level 1, in: W3C Recommendation 17 Dec 1996. Available at: www.w3.org/TR/REC-CSSl Squid Duane Wessels and K Claffy, ICP and the Squid Web Cache, in IEEE Journal on Selected Areas in Communication, April 1998, Vol 16, #3, pages 345-357 Available at: www.nlanr.net/~wessels/Papers/icp-squid.ps.gz Cache Duane Wessels, Intelligent Caching for World-Wide Web Objects, in Proceedings of INET'95, Hawaii. Available at: ircache.nlanr.net/~wessels/Papers/ wessels-inet95/wessels-inet95.USLetter.ps.gz HR438

160

Chapter 6

Wireless Communications and Public Safety Act of 1999, in the Senate of the United States, HR 438. Available at: thomas.loc.gov/cgibin/query/z?c106:h.r.438.rfs: HTTP R. Fielding et al, Hypertext Transfer Protocol HTTP/1.1, RFC 2068, January 1997. Available at: www.ietf.org/rfc/rfc2068.txt ht://Dig The ht://Dig search engine by the ht://Dig Group. Available at www.htdig.org CyberTour TRIUMF CyberTour, A.Daviel, sundae.triumf.ca/pub2/ctour/

TRIUMF,

1994.

Available

at

Colossal Cave Don Woods, Will Crowther. HTML by A.Daviel, TRIUMF. Available at sundae.triumf.ca/pub2/cave/node001.html Antarcti.ca Visual mapping Technology, Tim Bray. Available at antarcti.ca

ANN ANN programming manual, David M. Mount 1998. Available at www.cs.sunysb.edu/~algorith/implement/ANN R.L.Sproull, Refinements to nearest-neighbor searching, Algorithmica, 6:579-589, 1991 S.Arya and D.M.Mount. Algorithms for fast vector quantization. Proceedings of DCC '93 Data Compression Conference, pp 381-390. IEEE Press, 1993 Cyborg Cyborg: Digital Destiny and Human Possibility in the Age of the Wearable Computer. Steve Mann, 2001, Randomhouse Doubleday. Related information available at www.wiretap.org Nomad Nomad Personal Display System, http://www.mvis.com/prod_nomad.htm

Microvision.

Available

at


161

Cyberspace Vinge, V. True Names, in Binary Star #5, edited by James R. Frenkel. Dell, New York, 1981. Giant's Star Giant's Star, James P. Hogan, 1981, Ballantine Books


Chapter 7 The Elements of Location Tracking and Privacy Protection John B. Morris, Jr. Center for Democracy & Technology

As location based technology emerges and becomes ubiquitous, so does the need to protect the privacy of the users of such technology. To ensure that the technology facilitates the protection of privacy, it is critical that privacy protection be built into the technology itself [1]. To achieve that goal, one must identify the key stages in the location identification and tracking processes where privacy must be protected. This Chapter considers the need for privacy protection, analyzes where in the location processes such protection is needed, and concludes with a discussion of the elements of privacy to be protected.

1.

THE CRITICAL NEED FOR PRIVACY PROTECTION

Location based products and services offer great potential for convenience and productivity, but they also introduce new and heightened privacy risks for users that must be addressed. The portability of mobile devices and the ubiquity of their applications, coupled with their ability to pinpoint the location of individuals and reveal it to others, could – in the absence of clear privacy rules – produce a system where the everyday activities and movements of individuals are tracked and recorded. Wireless location technology has the potential to take data collection to new heights, allowing records to be compiled not just about discrete transactions but about individuals’ whereabouts, day or night. It is increasingly apparent that products and services that use location information will soon pervade everyday life. People can begin the day driving to work using traffic and navigation services, which allow their exact

164

Chapter 7

route to be monitored and recorded. Passing through a wireless tollbooth collection system, the exact moment an individual crosses over a bridge or passes through a tunnel can be pinpointed and recorded. During the course of the day, the information services available through personal digital assistant (PDA) devices and cellular phones may identify the individual's precise location. The location tracking of a PDA or cellular device may occur whenever the device is powered “on.” Instant messaging services may make an individual's location available to friends, but also potentially to advertisers. Bluetooth-enabled devices will support services such as money transfers between individuals and networked merchants. Each Bluetoothenabled interaction will indirectly reveal the individual's physical location to the device, and corresponding individual or entity, with which it interacts. The location information created by these various interactions can be collected and used by a variety of companies and later accessed by private parties or government agencies without the individual's knowledge or consent. Location-based services will bring many advantages and the potential for desirable new services and applications, but at the same time poses unique risks. For example, wireless location services present a unique opportunity for advertisers to bridge the prediction of a consumer's preferences and buying patterns with direct marketing targeted to the exact moment and location of the consumer. This relationship between the marketer and the consumer can be mutually beneficial, but its desirability and acceptability depends on the consumer's control over the advertising to which they are exposed. Many users are already dissatisfied with the volume of unsolicited marketing directed to them by mail, telephone, and email, and that dissatisfaction is likely to be heightened if advertisements arrive from third parties anytime a user walks down a street. Without awareness of how their location information is being used and who has access to it, users will feel as though there is omnipresent surveillance of their activities by companies or people they do not know. The invasiveness of such advertising increases when the volume and frequency of messages is also outside of their control. Since location information may simultaneously be collected by a number of companies, such as the wireless carrier and the information service provider, users may be confused about who has access to their information. Many will find wireless solicitors tracking and targeting particularly invasive. The availability of location information presents unique risks to individuals. Without the ability to control the collection of location information, consumers may lose the privacy safeguards currently afforded by existing privacy laws. For example, location information reveals physical destinations such as medical clinics or government services buildings. These destinations alone may imply additional information about an individual. In

7. The Elements of Location Tracking and Privacy Protection

165

some cases the information implied from location information reveals information, such as health condition, that is generally afforded protection by laws that limit access to such data. Information in databases is subject to a wide range of risks, requiring appropriate privacy and security measures. The risks include misuse by insiders, unintentional or mistaken disclosure, and access by unauthorized individuals. Because location information reveals, often in real-time, the whereabouts of the individual, the potential for privacy intrusion and other harms is more serious than with some other types of personal information. In extreme cases, improper disclosure of location information could place a person in physical danger; location information could be misused by stalkers or in domestic violence cases. Beyond the privacy risks that location based services can create, consumer demand for privacy protection will likely make privacy an essential requirement for location services. Simply put, if consumers do not perceive that their privacy will be protected, they will hesitate to use location tracking services or devices. To maximize the success of location services, privacy must be a component of such services.

2.

DIVERSITY OF LOCATION SERVICE SCENARIOS

In determining how to protect privacy in the context of location-based services, it is critical to recognize the very broad range of possible services and scenarios that may involve location. The methods and uses to protect privacy will vary depending on the specific scenarios.

2.1

Open or Closed Location Environments

The most common likely location tracking scenarios can be viewed as existing within an “open” or public environment. Customers of cellular telephone or other wireless services will be able to receive location-based services anywhere within the reach of the wireless provider’s network, including partnered networks. Location services based on signals from Global Positioning Satellites (GPS) will likely function even more broadly than wireless service areas. Although both wireless and GPS based services depend on a tracking device being within reach of specific, finite network, the network will generally be so ubiquitous as to reach “anywhere” within large geographic regions.

166

Chapter 7

Other location tracking services and systems may exist entirely within “closed” environments such as a corporate or university campus. Such systems may be used, for example, to track computer equipment within a private network, or to route telephone calls to employees within a corporate complex. It is also possible that essentially “closed” location tracking systems will be built in public spaces, such as single-purpose systems to track mass transit vehicles or equipment within major airports.

2.2

Tracking a Person or a Thing

Because human beings are not inherently trackable (although even this may change [2]), location-based services often rely on location information based on devices that people use or carry. In other words, the location of a person's device is often used as a proxy for the location of the person him or herself. Most commonly, the device is likely to be a cellular telephone, but could well be a laptop computer or even a single purpose location tracking device. In other scenarios, the desired location is that of the device itself, for example if a location tracking device is installed in a shipping container to be tracked, or if a piece of computer equipment is tracked within a corporate network. As location tracking technology becomes more compact and more affordable, it is likely that tracking devices will be included in such tangible things as pet collars. It is important to understand that for a given tracking device, the thing to be tracked may change depending on the circumstances. The most likely use of a tracking device installed in an automobile, for example, will be to provide location based services to the person driving the car, and the driver may well want to be protected by strong privacy safeguards. If the car is stolen, however, the tracking device can facilitate recovery of the car, and a system of privacy protection should permit such use.

2.3

Fixed or Mobile Locations

Although the most familiar location based applications in development involve the tracking of mobile users and handheld devices such a cell telephones, location services will also cover situations in which the location to be determined is fixed rather than mobile. Increasingly, there will be a desire to be able to establish the physical location of a user in a fixed location. Some location services for fixed locations will be similar to mobilefocused location services – such as providing driving directions and maps. In other contexts, the need to determine the location of a fixed individual or


167

entity will be driven by legal or business concerns. A manufacturer might, for example, impose geographic limitations on where a particular item can be sold [3]. Online service providers such as gambling enterprises may want to limit their services to certain regions; indeed, in the United States the state of Nevada has expressly legalized online gambling on the condition that location tracking technology is developed to block gambling in jurisdictions where it is not lawful [4]. For purposes of the fixed-mobile element of this analysis of privacy concerns, what is most relevant is not the actual portability of a target device, but the method of the device's data connection. For example, a laptop computer using a wired data connection (including a dial-up connection through the public switched telephone network) typically indicates that the target is in a fixed location at the point of the location inquiry, while a laptop computer using a wireless data connection should be viewed as "mobile" even if the laptop is in fact not moving. Thus, the type of data connection can indicate a target's "mobility."

2.4

Private or Public Raw Location Data

For more applications and services that are commonly thought of a “location based services,” the location information is drawn from information or systems that can be generally viewed as “private.” Typically, the location information is either a) derived or computed from information generally viewed as non-public, b) determined by a device that is not generally publicly addressable or accessible, or c) manually entered by a target seeking information based on his or her location. As an example of non-public information, location information could be based triangulations on a wireless signal with respect to a wireless carrier's transmitting towers (information that the wireless carrier will not generally make public. Similarly, with fixed, non-mobile targets, location information could be derived from "Caller-ID" or ANI (automatic number identification) information obtained by an Internet Service Provider offering dial-in network access. Devices with GPS (global positioning satellite) capabilities that can provide longitude and latitude information are not generally publicly addressable or accessible, and thus the resulting information is private. Finally, a target him or herself could manually input location information, a process that is likely to be non-public. Not all location tracking, however, is based on information that is generally viewed as “non-public.” Location can in some circumstances be

Chapter 7

168

roughly determined based on generally available information such as an IP or e-mail address. Commercial services exist, for example, that offer to provide rough location information based on IP address [5]. This type of location information is less accurate and has a coarser granularity than location information based on non-public information. Although location tracking based on “public” information raises significant potential privacy and public policy concerns, such services may be outside the reach of technology developed specifically to protect privacy. In the location computation framework set out below, this type of location tracking – based on public information such as IP address – is treated as a special category.

3.

THE ELEMENTS OF LOCATION COMPUTATION

The ability to derive or compute a target's location, and access to the derived or computed location, are key elements of the location-based services privacy equation. Central to protecting the privacy of an individual are: a) the identity of entities that have access to raw location data; b) the identity of entities that derive, compute or process raw location data; and c) the identities of entities that receive or have access to derived or computed location information. The key question is whether those entities can be trusted to know (or learn) and follow the target's privacy rules. This section sets out a framework to identify the various location-computation scenarios, and seeks to identify for each scenario which entities must be trusted to ensure a target's privacy. For the purposes of this framework, "privacy rules" are rules that regulate an entity's activities with respect to location information, including, but not limited to, the collection, use, disclosure, and retention of location information. These rules are more fully discussed below in Section 5.

3.1

A Framework to Describe Location Computation Scenarios

The framework to describe location computation scenarios has three attribute categories: the mobility of the target, which entity has control over the raw data, and the site of the location computation. The first attribute category, the mobility of the target, has two possible common values: fixed


169

or mobile. A third possible value – “unspecified” – is applicable only to the special case of location tracking based on public information. The other two attribute categories can be thought of as decision points that are related to steps in the location computation process. The location computation process contains two steps: 1. obtaining raw data about the target's location, and 2. deriving or computing the target's location using this raw data. One example of such a location computation process is signal triangulation. The raw data (Step 1) includes the direction a cell phone is from certain cell towers and where those cell towers are located. Given this information, one can compute the cell phone's location (Step 2). It is significant that the raw information from Step 1 and the computed location from Step 2 both provide information about the target's position. In Step 2, the raw data from Step 1 is transformed (and perhaps joined with external geographic or other data) into a more useful format. After the target's location has been computed, the location is available to be used in a location service or otherwise served to a requestor. Because location information can be expressed in many formats, it is possible that the location computed in Step 2 will be further transformed so that it is more useful to the requestor. Alternatively, the computed location may be made less precise to protect the privacy of the target. This further processing of the computed location is briefly discussed below in Section and more fully discussed in Chapter 9. The first key “decision point” is who has control over the raw data (Step 1). There are two possible values: the target, or the target's (wired or wireless) network provider. In this framework, if the target cannot control the dissemination of the raw data (such as with a cell phone that transmits information from a GPS chip to the wireless carrier without regard to the user's preferences), then the correct value would be the network provider (even though the user may have the ability to turn the cell phone, and thus the GPS reporting, off entirely). Again, a third possible value – “public data” – is applicable only to the special case of location tracking based on public information, tracking that typically is done by entities having no relationship to the target. The second decision point is the site of the location computation (Step 2). There are three possible values: the target's device, the wired or wireless network provider of the target's device, or a third party who is neither the target nor the network provider. There are two distinct decision points because the entity or device that controls the raw data may transmit it to a different entity before the location computation is performed. Although some initial implementations of location-based services may assume that a wireless provider with access to

Chapter 7

170

raw location data will perform the location computation, any framework to protect privacy should accommodate a model in which third parties can receive raw location data, derive or compute a location, and then serve or otherwise act on the location in accordance with a target's privacy rules. To ensure privacy, the target must be able to set and communicate privacy rules. Furthermore, the privacy rules of the target must be honored both by entities with access to the raw data and by entities (if different) that perform the location computation (and possibly by additional entities that later receive and/or re-serve the computed location). The first decision point - who has access to and control over the raw data — is important because any entity with access to this raw data can likely determine the location of the target independent of the desires of the target. If the target has control over the raw data, the target (if given appropriate tools) can limit transmission of the raw data according to appropriate privacy rules. This would include situations in which raw data is generated by a GPS-enabled device controlled by the target, but also would include scenarios in which a target manually inputs his location into a device or location service. In contrast, if a network provider has access to or control over the location information (such as when the raw data is drawn from a wireless carrier's network), the network provider must know or learn - and follow – the appropriate privacy rules. The second decision point – who performs the location computation - is equally important because, by definition, any such entity knows the target's location. Again, if the target (or target's device) performs the location computation, the target (if given appropriate tools) can limit transmission of location information according to appropriate privacy rules. In contrast, if either a network provider or third party performs the location computation, the provider or third party must know or learn – and follow – the appropriate privacy rules. Together, the entities that control the raw data and perform the location computation determine who knows the target's location. Thus, these entities must protect the location information consistent with the privacy rules set by the target during all uses and disclosures.

3.2

The Basic Location Computation Scenarios

The three attribute categories and their possible values yield a total of 12 basic scenarios, as illustrated below, plus a thirteen “special” category in which location is derived from public information such as IP address. In the diagram below, the following words stand for the following phrases:


mobility data computation network target Sc n

3.3

171

- mobility of the target - who controls or has access to raw location data - who performs the location computation - the network provider of the target's device - the target or the target's device - scenario number

Examples of Scenarios

Of the 13 scenarios identified, some reflect well-known business and technical models that currently are being implemented. For example, Sc11 represents the common scenario in which the location of a cellular telephone user is determined by the user's wireless carrier based on information in the carrier's network.

Chapter 7

172

Other scenarios reflect plausible if less visible business models, such as Sc9 in which a target has a cellular telephone or other device containing a GPS chip, and the target (or target's device) transmits the raw data to a third party, which returns the target's current street location. Among the "fixed" mobility scenarios, for example, Sc3 would include a situation in which a target manually provides current location information and a third party returns driving direction to a particular retail establishment. Sc5 would include a possible business model in which a carrier provided highly localized targeted advertisements based on "caller ID" information drawn from a dial-in modem port. Sc5 would also include scenarios in which a corporate network operator tracked the location of computer equipment. Certain scenarios, such as Sc4, do not reflect any readily apparent practical implementations but are included to ensure a complete analysis of the scenarios. Finally, the “special” case of Sc13 addresses location tracking services that seek to identify individuals’ location based on information such as IP address, typically with the knowledge or consent of the target. It is important to acknowledge that particular types or formats of location data cannot be easily categorized as always "raw data" or always "computed location information." For example, in Sc9, longitude and latitude data may be the "raw data" returned by a GPS device, and a third party may derive a street address from that raw data. But in Sc12, the raw data may be triangulation data available to a wireless carrier through its network, and based on that raw data the carrier may compute longitude and latitude data to be provided to a law enforcement agency involved in a wilderness search and rescue. Moreover, as discussed below, computed location information may be further transformed into additional, perhaps more useful, location formats.

4.

AFTER THE LOCATION COMPUTATION

After the target's location has initially been computed, there are at least five possible outcomes: a) the transaction is complete (if, for example, the target wants to know its own location and the target computes the location, as in Sc10); b) the entity that computes the location transmits it back to the target, or transmits to the target other information (such as a map) that is based on the target's location; c) the entity that computes the location transmits it to a third party that makes immediate use of the information;


173

d) the entity that computes the location stores it for later retrieval by the target or possibly a third party; or e) the entity that computes the location transmits it to a third party that in turn serves or stores the location information. Once a location has been computed, it is available to be transmitted or served to a requestor. An entity that serves location information is known as a "location server." It is important to note that any entity can be a location server, including the target's device, the network provider, or a third party. To protect the privacy of the target, any location server must receive and follow the target's privacy rules when it stores location information and/or uses or discloses this information. The protection of privacy after the computation of location is more fully considered in Chapter 9 below.

5.

PRIVACY RULES AND THEIR ENFORCEMENT

The general rules for protecting privacy – whether online or offline – are equally applicable to the protection of location information. But the robust protection of location information will require some additional elements specific to location. This Section looks at the general and specific elements, and consider some special issues raised by the above location computation framework.

5.1

General Elements of Privacy

In both the online and offline world, the protection of privacy typically starts with what are known as “fair information practices.” These practices are drawn from a variety of widely available documents, many of which are based on a key analysis by the Organisation for Economic Co-operation and Development (OECD) [6]. The following elements describe, for each privacy point, what rules are suggested by fair information practices. 1. Notice – A business must provide an individual with full, clear, and conspicuous notice of its information practices. This includes what information it collects, how it collects it (e.g., directly or through nonobvious means), and why it collects it. It also includes how it uses the information, including whether it discloses the information collected to other entities and whether other entities are collecting information through it. A business must also tell an individual how it meets the other principles of fair information practices.

Chapter 7

174

2. Minimization – A business may collect only information that it needs. Need is defined with respect to what the individual expects from a transaction. 3. Consent – Consent is required before information can be collected or used in any way. This consent must come from the individual whose information is being sought. Any secondary use of the information (i.e., use beyond that to which the individual initially consented) requires additional consent by the individual. An individual's access to a service cannot be conditioned upon her consent to secondary uses of her information. In order to be valid, consent must be explicit (opt-in), not implicit (opt-out). 4. Security – Businesses must take reasonable steps to protect the security of the information they collect from individuals. 5. Enforcement – Reliable mechanisms must exist in order to provide sanctions for non-compliance. In general, it's easier to enforce rules if businesses are explicit about their information practices. 6. Retention – Even if a business protects an individual's information and handles it correctly, the mere presence of that information means that third parties could access the information and use it incorrectly. Thus, once information is no longer needed, a business must get rid of it or strip off any identifiers so that the information is less susceptible to abuse by others. 7. Access – If decisions are being made about an individual based on her information, then she has a right to access, correct, or delete that information. Thus, a business must give an individual reasonable access to the information that has been collected about her, including a reasonable opportunity to review, correct, or delete that information.

5.2

Specific Elements of Location Privacy

Location information poses some special factors that are not common in other areas of privacy protection. For example, the protection of privacy may require the obfuscation of precise location information so that general location information (such as the target's current time zone or city) can be disclosed, but nothing more specific. Similarly, location privacy protection may vary depending on the specific time of day. These additional elements should be reflected in any system or technology to protection location privacy.


5.3

175

A Critical Need for Strong Default Privacy Rules

Critically, because of the potentially highly sensitive nature of location information, a location privacy system should “default” to a high level of privacy protection. Location information should be safeguarded unless a target or user has taken affirmative steps to permit its use. Some of the traditional elements of “fair information practices (as detailed in Section 5.1 above) pose particular difficulties in the location tracking context. These difficulties are created because, among other reasons, the user’s device may be severely limited in its ability to receive or respond to queries from a location services provider. Indeed, it is certainly likely that some location tracking devices will be completely unable to receive any data at all – the devices will transmit only in one direction. Moreover, even for devices that have some ability to display information and query a user, a small display size or limited bandwidth may make substantial notices or detailed queries impractical. As a result of the special challenges posed in location services, the default privacy rules should be particularly strict. Because some users of location services may not be able to receive extensive notices or queries, the providers of such services must always assume that the user desires the highest level of protection unless the user has expressly indicated otherwise. The strictest rule applies to any entities with access to raw information data – such entities should not use or retain any location information, and should only forward raw location information to an entity specified by the target or the target’s device. Without such a specification, the raw location data should not be used. An entity with access to raw location information should only compute location or process the raw information with the specific consent of the user. In considering the specific points of fair information practices applicable to “location service providers” (i.e., entities beyond the network carrier with access to raw location information), the special circumstance of location services leads to specific strict defaults: 1. Notice – A service provider should of course provide detailed information about its privacy practices in a readily accessible format (such as on the World Wide Web). But, because a location service user may be wholly unable to access the full notice, a provider’s privacy practices cannot impose on a user a lower level of privacy protection than the user has expressly accepted. In other words, it is not sufficient for a provider to simply post a notice of a privacy-breaching policy – in a location tracking context, the provider cannot breach a user’s privacy without express consent.

176

Chapter 7

2. Minimization – A service provider cannot (without meaningful consent) collect any information beyond what is required for the specific transaction. 3. Consent – Because a location service user may not be able to provide consent, a service provider must not seek to expand the use or retention of information beyond what was originally authorized. 4. Security – Location information must be maintained in a secure fashion. 5. Enforcement – Within a privacy rule framework, a user should be able to completely block access by entities with histories of failure to comply with privacy rules. 6. Retention – A service provider must not retain (without meaningful consent) any identifiable information beyond what is clearly necessary for the initial transaction. 7. Access – A service provider must provide a method of access to users who are unable to obtain effective access through the location tracking device itself. Although the above rules may appear strict, the special constraints imposed in some location tracking situations warrant such clear and unavoidable defaults.

5.4

Implications of the Location Computation Scenarios

As discussed above, two critical elements of location computation scenarios are who controls the raw data and who computes or derives the location. If the target does not both control the raw data and perform the location computation, he or she must form a relationship (even if, in some cases, a very brief one) with at least one other entity, and privacy rules must control this relationship. Who these other entities are must be considered because different entities have different relationships with the target, face different technical constraints, and are subject to different legal considerations. For example, a target who uses a computer to dial into a network (and most other wired connections) typically does so through an Internet Service Provider as the "network provider," and it is likely (but not certain) that the user has a pre-existing relationship with the ISP. In cases where there is a pre-existing relationship, technology may not be necessary to transmit privacy rules to that carrier. Instead, the target and network provider might reach a contractual agreement about privacy, and the target may first express privacy rules in an online or offline form that is stored by the provider. For wireless scenarios, a target typically (but not always) has a pre-existing relationship with a wireless provider, but there may not be any direct


177

relationship with the relevant carrier while a target is "roaming" away from the primary carrier's service area. As for technical constraints, it is possible that a target's mobile device will be small, lightweight, and low on computing power. These characteristics may mean that the device cannot efficiently perform its own computations. Thus, to protect his or her privacy, the target would need to form a trusted relationship with his or her carrier or a third party, obligating them to compute the location and either provide it back to the target's device for serving or abide by the target's rules about privacy. Network providers and others may be constrained by national or local laws regarding how they handle information. For example, in some relevant situations within the United States, "Customer Proprietary Network Information" (CPNI) rules require that telecommunications carriers obtain customer approval before using, disclosing, or permitting access to individually identifiable CPNI [7].

5.5

Possible Technological Considerations

It is not the purpose of this Chapter to identify the specific technologies necessary to protect privacy of location information. But, in considering the framework set out above, the scenarios suggest a number of possible technological needs to protect a target's privacy and transmit a target's privacy rules. Those possible technological needs include: a) a method to transmit to a network provider that has access to raw location data the applicable privacy rules of the target; b) a method to transmit a target's privacy rules to an entity that computes or derives location; and c) a method to transmit a target's privacy rules to any subsequent entity (after the location computation is complete). A single technology could be created to accomplish all three listed needs. It is also possible, however, that the first listed need (to protect privacy of raw data) could be accomplished by the transmission of a more limited amount of data than might be required to accomplish the other needs. For example, if a privacy model permits other entities to receive and follow more complex privacy rules, then a carrier with access to raw data might need to receive only one instruction regarding what other entity should receive the raw data.

178

6.

Chapter 7

CONCLUSION

To maximize the potential for success of location tracking services, privacy must be addressed at the outset, and must be a central design element of any location based service or device. As discussed above, the proper starting point for such privacy protection is with raw location data that can be used to derive or calculate location. If this and every subsequent stage of a location service provides robust privacy protection, and if that protection defaults to strong protection, then location services can become an important and valued technology for the twenty-first century.

7.

REFERENCES

[1] On the need to accommodate public policy concerns within the technical design process, see http://www.cdt.org/standards/overview.shtml. [2] At least one company already offers a device to be implanted into a heart patient’s heart that uses a cellular network to transmit heart data. See http://www.biotronik.de/content/detail.php?id=1446. [3] Manufacturers of DVDs, for example, already use “region codes” to restrict what part of the world a given DVD will function. See http://www.laserrot.com/info/lrinfo/dvdmap.html. [4] See “Nevada rolls the dice http://zdnet.com.com/2100-11 -529961 .html. [5]

on

Net

gambling,”

See, for example, http://www.netgeo.com/technology/technology.html.

[6] OECD, “Guidelines on the Protection of Privacy and Transborder Flows of Personal Data,” http://www1.oecd.org/dsti/sti/it/secur/prod/PRIVEN.HTM. [7] See 47 United States Code http://www4.law.cornell.edu/uscode/47/222.html.

Section

222

at

Chapter 8 Location Information Privacy

Jorge R Cuellar Siemens, Corporate Technology, CT IC 3

1.

OVERVIEW

As already discussed in the previous Chapter, there is a need to securely gather and transfer location information for location services, protecting the privacy of the individuals involved. This document explores some of the technical requirements for protocols used to transfer location data, focusing on authorization, integrity and privacy. The main principles are: 1) Security of the protocol is of utmost importance to guarantee the correctness (integrity) and the confidentiality of the location information. This includes authenticating the main entities of the protocol and securing the exchanged messages. 2) A most important role is played by user-controlled policies, which describe the permissions (or consent) given by the user. The policies specify time and place when location information may be released to whom. 3) The user is able to specify which component or derived measure of the information is to be released and in which granularity or accuracy. 4) The location information may be released in the form of a local place name or a context-dependent identifier, like "atHome" or "building29", which makes sense for the intended recipient, but difficult to link for outsiders who are missing the context information. 5) Whenever possible, the location information should not be linked to the real identity of the user. Rather, the user is able to specify which local

180

Chapter 8

identifier, pseudonym, private identifier, or token is to be linked to the location information. Although complete anonymity may not be appropriate because of legal constraints or because some location services do in fact need the explicit identification of the user, we argue that in most cases the location services may only need some type of authorization information and/or perhaps an anonymous identifier of the user. This is similar to the fact that the location services in general do not need context-independent location information. Motivation for this work is presented in Section 2. Section 3 explores the framework and scenarios. Many different types of applications need geographic location information about a "target". And there are also many different ways in which information is gathered, processed and disclosed to others. Location information is first sent from a "Location Data Source" to a "Location Server". (Precise terminology is introduced and explained later). Then the Location Server filters the information and forwards filtered location information to his clients, called Location Recipients, in agreement with the explicit consent of the target. The first principle is that the "owner" of the target specifies which location information may be released to whom under which conditions. Such an assertion is called a "location information policy" or simply a "policy". Section 4 discusses some technical aspects of privacy: linkability, credentials, pseudonyms, anonymity, etc. and proposes some solutions to the identity management problem for location data infrastructure. Section 5 gathers together and makes explicit the requirements suggested during the rest of the paper. Note that the requirements discussed here are requirements on privacy protocols for location services. Thus the requirements sometimes refer only to the capabilities of these protocols. For example, requiring that the protocol support integrity is not the same thing as requiring that all protocol traffic be authenticated. In other cases, the requirement may be that the user always obtains a notice when his location data was not authenticated. This is clearly not just a capability of the protocol.

8. Location Information Privacy

2.

181

MOTIVATION: THE PROBLEM The motivation for this work lies in the following arguments: 1. It is easy, and common practice, to collect private information about individuals in databases. It is technically simple for location service providers to collect all sorts of personal information (such as a list of shops, hospitals, gambling rooms, law attoneries, etc. visited by an individual in the last couple of years) and to store that information indefinitely, indexed by the user's name. 2. In a near future, private location data will be available not only to the mobile phone providers but also many different kinds of Location Servers and their clients, which are not legally bound by the restrictions of telecommunications secrecy. 3. Long-term storage of personal information brings the threat of eventual disclosure or eventual misuse. Most people want to keep secret from somebody else where they have been. 4. Information may be transferred to other countries where it is not protected by the same privacy laws in effect where that individual resides. 5. Even if the location service providers agree to respect the privacy of the user, disclose privacy policies, or are compelled by laws or regulations to protect the privacy of the user, there is still a chance that personal data may become available to unauthorized persons. This happens easily with a. misbehavior or negligence of the "trusted" server, b. attacks from hackers or other outsiders, c. unauthorized access from insiders d. technical or human errors 6. Several pieces of location information may be linked together to provide much more information than what the user intended to disclose. For instance several measurements give an indication about the direction or velocity of the movement, or the distance to three non-collinear points determine the exact location of the target in the plane. 7. Location information of an individual may provide strong clues about his wealth, health, social interests, friends, preferences, hobbies, political or religious convictions, and other sensitive information. 8. This information may also be used for instance by blackmailers, kidnappers or robbers to select and track their victims.

Chapter 8

182

9. Location information linked to the identity of the user as well as other private information may be aggregated to dossiers about the individual. 10. Privacy concerns are as a long-term impediment to the success of e-business ventures and in particular of location dependent value added services. There is abundant literature about those concerns, see for instance [4], [7], [10], [16], [17], [21], [52], to name just a few. As an illustration for those arguments, the reader could take a look at some recent news and surveys: [19], [44], [17], and [34]. To quote the International Working Group on Data Protection in Telecommunications [21]: "The enhanced precision of location information and its availability to parties other than the operators of mobile telecommunications networks create new unprecedented threats to the privacy of the users of mobile devices linked to telecommunications networks. The Working Group therefore deems it necessary that the technology for locating mobile devices is designed as little invasive to privacy as possible."

3.

FRAMEWORK: ENTITIES, FLOWS, SCENARIOS

In this section we first explain the functional entities that play in a location service system and then discuss how these entities interact in a set of different scenarios. There is here no widely accepted terminology. Some of the terms are perhaps still quite ad-hoc. The author acknowledges the terminology discussions in the geopriv mailing list [18].

3.1

Entities

Target: The entity whose location is desired by the Location Recipient. The target may be a device (say, a cellular phone), a person (say, the subscriber of the cellular phone), an animal, a ship, equipment in the field, a truck, etc. In many cases it can be considered the same to locate a cellular phone or to locate its subscriber, but in some cases there is a difference. Perhaps the phone is owned by a company, and shared between different employees, who enter a code at the cellular phone when they activate the location facilities. Or perhaps an individual uses different types of equipment, depending on where he is, entering again a code when he changes his device,


183

or the device recognizing this through a "logon" or a smart card. Perhaps the target, an individual, is just entering a pin code every time he enters a new region of an airport or a hospital, or sensors to open the doors are reading biometrical data or performing some other kind of pattern recognition. There is of course a difficulty if the location of the target is performed via a device, for instance an active badge, which can be detached from the target. This may be expressed in the amount of confidence that the measurement has. Confidence should not be confused with accuracy, (see later). Another word often used is trust (on the measurement) but in the context of security this term has already too many different meanings. Also notice that to locate a target, several devices can be used simultaneously, as in the case of tracking a ship. This may also happen in other situations, where the purpose is to increment the confidence on the measurement. Also may be observed that the situation will arise in which one Location Server uses the position of one or several targets to infer the location of another target. This should be only possible with the explicit consent of the latter. Location Data Source This is the original source of the sighting, that is, the matching of an identifier for the target, a position, and a time. A complication arises if there is no "security relationship" between the Location Data Source and the Owner. A security relationship is a knowledge (here, usually a knowledge of secret or public keys or of a common trusted third party) that that two entities have of each other that allows them to construct a secure channel between them. In some scenarios, the target itself is the location data source (or better, they are colocated). In some situations the "owner" (see below) may be the original data source, for instance simply because he knows where his equipment is. It is also possible that the Location Data Source has a security relationship to the owner and is full aware of his policies. In those cases the owner is able to authorize the Location Data Source to provide the position to a recipient. The recipient can also easily link the origin of the location data and the origin of the policies, thus convincing himself of the authenticity of the location data. We will say then that the Location Data Source is a Location Server; see below. (But there are Location Servers that are not Location Data Source, since they are not the original source of the sighting.)

184

Chapter 8

In general, the Location Data Source is some network entity, properly authenticated and authorized by the network, but perhaps totally unknown to the target and in particular unaware of the full details of the policies of the user. This entity could be some location detection function in the access network. The authentication /authorization requirements for this case are not trivial since the target may have no direct security relationship (for instance, a secure channel) to the location data source. The trust relationships may have some subtleties, in particular in a roaming situation. Location Recipient: Software and/or hardware entity that obtains the location of targets. To obtain location information for one or more targets, it interacts with a Location Server or with the Location Data Source. The Location Recipient may be a Location Server itself or an Ultimate Location Recipient. Location Server: Software and/or hardware entity offering Location Service capabilities based on user-defined privacy policies. Ultimate Location Recipient: A Location Recipient that is the ultimate recipient of the location information (he may not pass this information, or derived one, to others, except to the target or the owner). Other proposed names for the Ultimate Location Recipient are: Location Requestor, Ultimate Location Requestor, Location Seeker, or Location Service Client. The name client is unfortunate, since the Ultimate Location Recipient may be a location-aware value-added service provider (to the owner or the target) Owner of the privacy rights of the target: or, for abbreviation, the owner: An entity that has the authorization to decide the policies that apply to the location information of the target. Most frequently, when the target is a natural person, the owner of the target is the target itself. One target may have several owners and one owner may have several targets. After the initial registration of a target with the system, the owner is in possession of credentials showing that he is authorized to make the policies for the target. How the owner proves that he owns the privacy rights during the registration and how he obtains the credentials is outside of the scope of this discussion. We simply assume that the owner knows the correct secrets needed to authenticate the policies of the targets. The location data source, or the person who legally owns it, may have the "copyrights" of the sighting, but in general not the ownership of the privacy rights of the target.


185

Policies repository: A repository where signed (or otherwise authenticated) policies, identifiers, and perhaps also requests are stored. Several policy servers may use the same repository or the repository may be distributed or replicated. The user should have full control on his policies in the repository. To quote the International Working Group on Data Protection in Telecommunications [21]: "The user must be able to access, correct and delete his or her preference data also in cases where the preferences of the user are not stored on the mobile device, but within the network." Location Recipients may submit location requests asking for the location of a particular individual, for member of a group, or for targets with given attributes.

3.2

Data

Compared to more general types of private information there is something particular about location data: there are conceptually simple mechanisms to filter the information by introducing a random error, changing the accuracy of the data, or using a geo-political value instead of a geodesic one. For instance, the geographic coordinates may be mapped into, say, country or time zone. Such translations, although more or less straightforward, may require some computing power or data not directly available to the user. The difference in information content between the various data formats or data types is something the user would like to use to take advantage of in his policies. For instance a mobile node may declare that the members of a certain group may know on which time zone he currently is, but not the city. The main data used by the protocol is the "sighting" (the pair identity and location) and the policies. 3.2.1

Sighting

The Location Server has to know to which Location Recipients which information will be transferred. Roughly, the private data that the Location Server may access is a pair: (identifier, information-content)

Chapter 8

186

where information-content is the location information. Eventually this pair is extended to a triple including also a time-stamp. For shortness, we assume no time-stamp, implicitly meaning "at the current time" or "at a very recent time". Notice that this is in many cases enough, since anyway time-stamps are not exact and clocks are not usually synchronized. What the Location Server will forward to the Location Recipient is a new version of this pair: (identifier_1, information-content_1) where information-content_1 is the translation of the location information and identifier_1 is another identifier of the target. See section 4.2. Instead of providing the full information ("user ABC is at coordinates xyz"), the Location Server matches the request of the Location Recipient and the policies for the target and changes perhaps both, the identifier and the location information. He just says: "a customer of yours is at the entrance of the Palace Hotel" to a taxi, or "Gottfried Frege is AtHome" to Gottfried's wife, or "pseudonym2947a is at HangarB371" to a manager in an airport. 3.2.2

Location

There are many location data types and formats from standardization organizations, universities, or other groups, including [1], [28], [33], [43], [23], [19,20], [31], and the Internet Draft of R. Many, "A Simple Text Format for the Spatial Location Protocol, SLoP", (July 2000, work in progress). The less information the information-content of the sighting provides, the better we are securing the privacy. This method of providing privacy will be called information content abstraction. Due to the nature of the data, the set of all different location data types may be seen as being a partially ordered set: a data type DT1 is smaller than another, DT2, if DT1 has less information than DT2. (But some data types are incomparable, for instance the data types Country and Time_Zone: one particular country hay have different time zone and vice-versa, one time zone may correspond to several countries.) There is a natural translation of data type DT1 to DT2 exactly when DT1 has less or equal information than DT2. For instance, it is conceptually easy to translate accurate coordinate based location information to a geopolitical one. Depending on the size of the cell, there may be a translation from Cell-ID to a coordinate system with one or the other accuracy.


187

Ideally, the arrows in this collection of location data types form commutative diagrams, but in the practice this is not really true. This is true because of approximations and errors, but also because the values of the variables represent overlapping regions in space. Also, confidence or accuracy values may be translated, or translations may introduce random errors (obfuscation). Some location Servers may support user-defined data types. Of course, if a standard protocol is to be built that is usable in different settings and by different types of services, some define location data type must be supported by all implementations, both syntactically and semantically. 3.2.3

Identities and Credentials

First of all, identities are used in the sighting information (to tell that a certain target, is at a certain position). One target may use different identifiers, for different purposes. The identity passed in the sighting may be context-dependent, user-defined (for instance, a name that only has meaning for some partners of the owner) or anonymous. This may be used to tell the Location Recipient that some unidentified customer is waiting for a taxi at a certain place. Thus the identifier in the sighting may contain full information, identifying unequivocally the target to anyone, or may have much less information in the following sense: this identifier makes sense only to a small group of recipients, this identifier is valid only for a small period of time, not much other information is already linked to this identifier, or from the point of view of an eavesdropper, many different targets may be meant by this identifier. The more information the identifier used conveys, the more sensitive is the information. Thus anonymity helps to secure privacy because it hides the true identity of the user. The process of changing an identifier by another, more anonymous one, will be called identifier abstraction. It is an abstraction in the sense that there is a substantial intended loss of information content in the translation. (Any computation reduces the information content, the point here is that this is the main purpose of the computation). Second, identities are not only used in the sighting information but also to identify, authorize and authenticate the parties of the protocol. In this

Chapter 8

188

context, not only identities are needed, but also credentials, used to prove the corresponding authentication or authorization claims. To avoid some types of attacks, and to hide the real identities of some entities to others, pseudonyms and other types of anonymous identities should be used. For instance, the list of Location Recipients authorized by a certain owner may be sensitive information, which the owner would like to secure. There are cases for where the owner does not want even the Location Server to be able to collect this information. In that case, the policies of the owner will use private identifiers to refer to the Location Recipients and they in turn will use those private identities (together with the proper credentials) to authorize themselves to the Location Server. A discussion on identities and credentials will be deferred until Section 4.2. 3.2.4

Policies

We use the word policy in the following sense: Privacy Policy is an assertion that a certain amount of information (identity or identifier plus location) may be released to a certain entity (or group of entities) under a certain set of conditions. Notice that P3P uses the same term "privacy policy" to denote "a Web site’s statement to users of what information it collects and what it will do with the information after it has been collected", [35]. Although in this Chapter we do not propose a concrete syntax for a policy language, or even the exact capabilities it should have, some remarks are proper: for standardization and interoperability a policy language must be specified. This policy language may be an existing one, an adaptation of an existing one or a new policy language. The policy language must be strong enough to express policies of the form: a group of Location Recipients are allowed to know a certain transformation of the location of a target together with a given identifier of the target. The group of Location Recipients should be characterized by the possession of (identifiers, credentials) with a certain syntactic property. The abstraction function may be specified in simple cases by the desired data type of the filtered location information. Within those constraints, the policy language should be as simple as possible, or it should be an existing policy language. An example for a policy is the following: "My family is allowed to know my street address;


189

Within 8am-5pm during working days my boss is allowed to know the city and If I am in a campus of my corporation, then also the campus and building number; Any member of my corporation is allowed to know the time zone I am." This policy contains 4 permission rules. 3.3

Data Flows

In the so called "pull-model" the Location Server 1. Receives Location Information from the Location Data Source or from other Location Servers 2. Receives, directly or through a repository or a trusted third party, policies from targets. 3. Accepts services requests from Location Recipients (including other Location Servers), 4. Matches the location request to the policies for the target and processes the Location Information accordingly, and 5. Responds sending back Filtered Location Information of the target. Of course, other models are possible, but in principle, the same information flows between the entities. The single data flows are: LI (Location Information): the location data source (the target itself, an owner of the target or some properly authenticated network element) sends location information to the Location Server. FLI (Filtered Location Information): The Location Server sends filtered location information to the Location Recipient. The information is filtered in the sense that in general not the full information is being delivered, but only an abstraction. Actually there is no technical reason for distinguishing Location Information from Filtered Location Information, it is just a way of insisting that the information sent by the Location Server is (or should be) different from the information he has. Poll (Policy): An owner of the target (or in particular, the target itself) sends a Policy to the Location Server.

190

Chapter 8

PolInfo (Policy Information): the server informs the Location Recipient which data type(s) are available for filtered location information for a given target. This mechanism must be able to be invoked by the Location Recipient before he sends an LRequest. LRequest (Location Information Request): the Location Recipient requests location information for a target, a given class of targets, or for targets with a particular set of attributes. In this request, the Location Recipient may select which location information data type it prefers. The Location Recipient can also specify the need for periodic position updates. There is another interface or set of interfaces between Location Recipient, target (or owner), and location service that is outside of the scope of this paper but needs to be considered in our picture. This set of interfaces will be denoted collectively by "Service". Service: A set of interfaces and data flows used to set-up and provide value-added location-aware services, where the Location Recipient subscribes himself to the services of the Location Server. the Location Recipient and the owner agree on identities (say relation-pseudonyms, purpose-built-identities, local names, or real identities) to be used later as well as on credentials or cryptographic material to prove the ownership of the negotiated identities. This will be discussed later. The value-added service may be provided by sending an encrypted e-mail or other type of e-message to the target or owner, or the owner one activates a web page of the Ultimate Location Recipient using TLS. Knowing now the location of the target the web-server provides a location-based information service.

3.4

Scenarios

In the following scenarios we will consider "ordinary" location recipients only, that is, location recipients that require a very explicit authorization from the owner to obtain the location information. This authorization is given in the form of user-defined policies. It is possible that some classes of location recipients will be subject to different legal constraints than "ordinary" Location Recipients. For instance, "Regulatory Location Recipients", defined by regulatory requirements, (including the receivers of emergency calls, emergency alert, lawful interception) will probably have a different authorization status than ordinary


191

recipients. In the case of lawful interception it is even possible that the user is not even notified about the use of his location information. Perhaps another class of Location Recipients that will be treated differently from ordinary ones are what we can call "Operational Location Recipients". Those are recipients that support the operation of the network and/or are needed for ensuring appropriate treatment and payment, for instance: Monitoring of QoS parameters correlated to location for monitoring of Service Level Agreements (SLAs) and for quality assurance, Location Based Charging, allowing a subscriber to be charged different rates depending on the subscriber's location, Utilization review, etc. In any case the user should be notified about this operational use of location information, and, if not bound to the privacy policies of the user, it should probably be regulated and carefully subject to monitoring and control from the corresponding authority. Other types of scenarios, not considered in the following discussion, are chains of Location Recipients, for instance, where a Presence Server acts as a client to a Location Server. In that case, there is another client, the "original" client, 3.4.1

Scenario 1: The Handset-based Solution

The first case we want to consider is a mobile node (laptop or handheld) that at the same time is the target, owner, Location Server, and Location Data Source. The mobile node discovers its own position using a GPS mechanism, a manual input from the user or a co-located sensor that recognizes the relative position of some active badges or other reference points. An application running in the mobile node delivers its location to some Ultimate Location Recipients. An Ultimate Location Recipient that wants to know the position of the mobile node sends a Location Requests to the application running on the mobile node. After authenticating the Location Recipient, the application checks which policy rule matches, translates the location information to the appropriate form and sends back this Filtered Location Information to the Ultimate Location Recipient. Notice that in this case the policies are only for internal use of the mobile node and as such do not have to be standardized. Only the interface to the Ultimate Location Recipients has to be standardized. The Ultimate Location Recipient himself has to obey some generic policies: he is the ultimate recipient of the location information, that is, he cannot pass this information further, and

192

Chapter 8

he has to delete this information for a short period of time (say, in the order of hours). 3.4.2

Scenario 2: A Network-Based Location Data Source

This scenario is very similar to the first one, but instead of the mobile node discovering his position by himself, it uses an underlying location system based on a co-located active badge, a L2 interface, a service provided by his access network or a similar infrastructure.

Notice that in this scenario no Location Recipient exists, besides the owner itself and the Ultimate Location Recipients served by the owner itself. Thus, except for regulatory or operational purposes, the user (owner) is in full control of its private information. But it may be unclear how the user makes sure that the Location Data Source does not provide location information to other location recipients. Either the Location Data Source is aware of the full policies of the owner, (that is it is a Location Server), or the mobile node subscription profile The necessary requirement is that, unless required by local regulatory or operational requirements, or overridden by the user, the mobile node may be positioned, only if allowed in the mobile node subscription profile.


193

Nevertheless, there is already some concern that the location information may leak to entities not authorized. To quote the International Working Group on Data Protection in Telecommunications [21]: "The user must remain in full control on whether precise location information is generated in the network. In this respect, handset-based solutions where the creation of precise location information is initiated by the mobile device seem to offer a better degree of privacy than network-based solutions where location information is generated as a standard feature and choice of the user over this information is limited to the question whether it will be communicated to third parties." Another concern is that, depending on the sensing infrastructure and its trusts relationships to the user, the authentication of the Location Data Source to the Target (= Owner) may be unfeasible: the target may be roaming in a region where it does not have any security relationship to the Location Data Source. Thus the Location Information data flow may not be authenticated and in general an attacker may impersonate the Location Data Source to the Target, presenting him false location information. Even in more general scenarios, the authentication of the Location Data Source to the Location Server may be difficult to implement, since sensor systems are not equipped with encryption software, with the proper keys, or key distribution software. In the other direction, the authentication of the target to the Location Data Source is also an issue (and not only in this scenario, but in general) for instance, because some sensor systems only detect transmitters that can be removed from the mobile object they represent and because of the very low computing power of the sensor systems, precluding cryptography. 3.4.3

Scenario 3: External Location Server

Another variant is when the target does not have enough resources to compute the translation of the location information to the data type that he requires. For instance, the target knows his exact coordinates and wants to retrieve the street address. To do this, the target sends first his (raw) location information to a location service that will perform the translation and than asks for the location information in the required format. Thus here the target is the client of the location service, that is, he is the Location Recipient. Let us further assume that there are no other Location Recipients to the location service besides the target, and the target is also the owner of the privacy rights.

194

Chapter 8

In this case, no explicit policies are needed for the location service: His generic policies are simply that the only entity that may obtain the location information is the target itself, and that the location data has to be erased after a certain amount of time (in the order of hours). 3.4.4

Scenario 4: External Location Server and Location Recipients

The next scenario we consider introduces policies to the external Location Server. This corresponds to scenario 3 when there are other Location Recipients besides the target or owner. Examples for this and the next scenarios are given by Location-Based Information services that allow subscribers to access filtered and tailored information based on the location of the requesting user. Those services include navigation, city sightseeing, location dependent content broadcast, and mobile yellow pages. There is a special case of Scenario 4 that could be considered separately: this is when the Location Recipient is also the owner. This situation is found in particular in some tracking services that include Fleet and Asset Management Services allowing the tracking of location and status of vehicles (cars, trucks, etc.), animal, assets, or people, for example when supervisor of a delivery service who needs to know the location and status of employees, parents who need to know where their children are. There are


195

some examples of tracing services that do not fall in the special case, for instance stolen vehicle location. 3.4.5

Scenario 5: External Location Data Source and Location Server

This scenario is a simple combination of previous ones, but it brings some new complications. The target itself is not able to calculate its position and requires an external location data source. But this location data source passes the information to an external Location Server, instead of the target itself. Even if the target was able to perform the necessary translations, this scenario will be common to support the operation of the access network: for instance Location Based Charging, which allows a subscriber to be charged different rates depending on the subscriber's location, or monitoring of QoS parameters correlated to location for monitoring of Service Level Agreements (SLAs) and for quality assurance, utilization review, credentialing, and other activities that are part of ensuring appropriate treatment and payment. In general, there are some issues with this scenario. The user may be roaming outside of his home network, and the Location Server in the visited network may be untrusted, or the regulations in the given country are not so

196

Chapter 8

stringent as in his. Or perhaps the visited domain does not support the privacy-protecting protocol he needs. That is, perhaps there is no Location Server or the Location Server of the visited domain is perhaps not able even to parse the policies of the user correctly. Another reason may be that the owner does not want to download his policy files at this location because they already contain some private information about the partners that he communicates with, to which groups he belongs to, or the Location Server may observe the IP addresses of the Location Recipients that ask for my location information and deduce from that sensitive information. The user wants to stipulate very simple instructions for the location data source of the visited domain, namely "send the location information to my trusted or my home Location Server!" See Figure 4.

But this proposal has one difficulty: how do the Location Data source and the Home Location Server authenticate each other? We do not expect to have a global PKI or AAA environment to solve the issue.


3.4.6

197

Scenario 6: Untrusted Local Location Server

A solution for the issue mentioned in the last scenario is to use the local Location Server only for purposes of the operation of the access network, for emergency services and lawful interception, and to forward the location information to a home or a trusted Location Server. The local Location Server could have access to some simple user profile to observe if the target may be monitored (for other purposes than the barely necessary for operation and to comply the laws) and to check if he has authorization to download the policies from the home domain. If not, the user again wants to stipulate the very simple instruction "send the location information to my trusted or my home Location Server." See Figure 5.

4.

IDENTITY MANAGEMENT

4.1

Privacy: Definitions

The definition of privacy is somewhat evasive.

198

Chapter 8

Some computer scientists often equate privacy with confidentiality. Others ([29]) argue that anonymity is a higher-order secrecy problem, related to the awareness of a communication, not with the communication content as such. While IPsec can protect the contents of a datagram, the fact of the traffic itself is not hidden. Using standard cryptographic methods it is quite difficult to conceal the address of the receiver of the information, since the routing or naming facilities have to know it, at one point or the other. And, for instance that I am using an anonymous remailer already reveals private information of myself. For legal purposes and in court decisions the definitions of Westin [51] are frequently cited. He describes information privacy as the claim of individuals, groups or institutions to determine when, how, and to what extent information about them is communicated to others. More generally, privacy is a human value with the following dimensions: Anonymity the right not to be known Intimacy the right not to be monitored or tracked Reserve (or control) the right to control one's personal information Solitude the right not to be disturbed In the context of electronic communications and in particular of location information, the last one is basically the ability to be protected against being physically located (or electronically disturbed, which we will not consider here). Although anonymity is not the same as privacy, it is often understood as a technical mean to achieve privacy. But still the technical definition of anonymity is not simple and contains many subtle points. There is still no accepted terminology. We will use the term in the following sense: Anonymity A protocol provides anonymity if observable communication between agents does not leak any information about their identities, [4]. Other definitions may be found in [22], [36], [48], and [42]. There are still other technical methods, besides anonymity and information content abstraction, to provide privacy. See for instance the guidelines of the Safe Harbor agreement [49] or the OECD: Guidelines on the Protection of Privacy and Transborder Flows of Personal Data, [32]. (See also the preceding Chapter of John Morris). Those and similar technical requirements have to be considered in the construction of a location service infrastructure.


4.1.1

199

Other considerations

4.1.1.1 Traffic Analysis Protection against revealing the identity at the application level provides data anonymity. Connection anonymity, on the other hand, is the protection at the link, transport or network layer against disclosure of the MAC Address, IP Address or other routing information. The basic building block for connection anonymity, the mix, was presented in 1981 in [9], Also traffic padding (inserting dummy traffic to hide the real traffic pattern) may be used to hide traffic patterns. For a good survey of the topic see [15]. Traffic analysis is an attack in which the adversary monitors certain parts of the systems to be able to match a message sender with the recipient (sender-recipient matching) or, in particular for mobile systems, to locate or track the movements or sender or receiver. The methods described in this paper are not adequate to protect users against traffic analysis. Of course, something has to be done to prevent the linking of IP Addresses to locations or to users. This issue is quite general and independent of location services, and it may be quite serious for mobile users. The mobile-ip working group is aware of this, see for instance [50], and the Internet Drafts on HIP (for instance, Moskowitz: Host Identity Payload And Protocol, November 2001, work in progress), or the home pages of the mobile-ip WG. Analyzing traffic attacks is difficult. The number of different assumptions and settings is huge; does the attacker only see the IP packets or also the L2 headers? Which parts of the network does the attacker monitor? This makes it difficult to state the problem precisely and to reason about it. 4.1.1.2 Related Privacy-Protecting Efforts P3P [35] is a similar privacy protecting effort, widely known. The P3P policies, written in a standardized XML format, declare how a Web server is intending to handle the private data that he receives from the clients. A P3P user agent, part of a P3P enabled browser at the client’s machine, can automatically read these policies and compare them to the user's privacy preferences. Depending on the result of the comparison, the user may decide not to send his private information to the server. The main differences to P3P are: P3P wants to protect more general type of private data, not only location information. In our case, the user has control on the type of data manipulation that happen in the server and in particular on the information

Chapter 8

200

content abstraction (replacing exact position by the time zone, for instance), before this data is sent further. In our case, the user has also control on the user identification abstraction (replacing his true identity by a pseudonym, a group membership or a role). In P3P the policy of the server is compared to the preferences of the user, but in our case the user policies are to be installed in the server.

4.2

Identity of Users, Location Recipients

As discussed already, public global identifiers providing the full identification of an entity to a rather large class of participants, are to be avoided as well in the sighting information as in the authentication and authorization information. They are replaced by more "abstract" identifiers, whose purpose is to hide the real identity of the target from an unauthorized entity or an attacker, the real identity of the Location Recipient from the Location Server, the real identity of the target from the Location Recipient, and the real identity of the target from the Location Server, and also to limit the amount of information that can be linked to an identifier. This last requirement may be easily implemented by regularly changing the identifiers used. In the next few sections we will look at the first group of requirements. 4.2.1

Public Identities

Public global identifier is a label that identifies an entity in a way that a rather large group of entities can understand. That is, this label belongs to a name space (realm, context) accessible by a rather large group of entities. A public identifier may be the subscription identity at the home domain, a well-known identity (name, address or Tel Number), the Network Address Identifier (NAI), the Subject identity of an X.509v3 certificate, a long-lived public key, or the hash of such a public key. Our use of the word public global identifier includes the public pseudonym of [36], where the linking identifier and its holder is publicly known from the very beginning.


201

Individuals often regard the disclosure of his public identifier in connection with his location or some private activity of him, as a violation of his privacy right. In our context, H. Schulzrinne proposes to use an end system identifier such as a MAC address or the "SLoP identifier" for location services for emergency calls (for details, see: Emergency Call Services for SIP-based Internet Telephony, Internet Draft, work in progress, March 2001). "However," Schulzrinne says, "such an identifier raises privacy issues…" In order to remain anonymous, an entity may use identifiers that convey less information than public identities, are meaningful to a smaller amount of entities, or are meaningful only for a quite short period of time. Thus if A has some information (non public global identifier, information-content) about an individual referenced at a certain point in time by the non public global identifier and A discloses this information to B, then it is quite probable that B may not associate this information with any identifier that he currently knows (unless the information-content itself is linkable to an individual). For instance, a type of public identifier is the pseudonym, in the following sense: The linking between a pseudonym and its holder is known initially only to certain enforcing parties. Later, in case of abuse for instance, the enforcing parties could reveal the identity of the holder. This is known in the literature as identity escrow. Pseudonym is an identifier that ensures that a user may use a resource or service without disclosing its user identity, but can still be accountable for that use… [22]. In our context of Location Services, pseudonyms (that is, identity escrow) are not generally necessary, unless explicitly required by an owner or a regulatory entity to resolve cases of abuse. Another type of public identifier is the public local identity. Public local identity is an identifier which is generally only understood in a certain name domain, context or realm. For instance a corporate may create a set of local identities to be used internally.

202

Chapter 8

Another example of a public local identity schema is given by SDSI/PSPKI, see [41], [38] and [39]. A basic SDSI 2.0 name is an expression with two elements: the word "name" and the chosen name. For example, George: (name Fred) represents a basic SDSI name "Fred" in the name space defined by George. If Fred in turn defines a name, for example, Fred: (name Sam) then George can refer to this same entity as George: (name Fred Sam) There is also a method for anchoring names to public keys. Public local names do not offer too much security, in general. Nevertheless, public local names are to be used in Location Services, but not with the main goal of providing privacy from an attacker, but privacy from a casual unintended recipient. Also public local names have the advantage that the recipient may readily use the identifier, without translation to its context. Observe that such a scheme may not only be applied to names for individuals, but also for organizations and for places. See for instance [24]. This means that the same methods may be used for location abstraction. Another class of public names that provide privacy and can be used to abstract the sighting information is: Group or role identifiers ("administrator", "member of club A", "a prospective customer", etc.) The meaning of the role may be context dependent. The role identifier may not be used when a unique identifier of the user is required. For some types of role identifiers a proof of ownership (that is, authorization to use the identifier) is necessary. Notice that group or role identifiers may not be easily used for purposes of authentication of the entities in the protocol.


4.2.2

203

Private Identifiers

The owner may create special artificial names to be used by the target or by the Location Recipients. The owner communicates "out-of-band" those conventions to the Location Recipients. One-time identifier: an identifier that is used only for a "session". Two occurrences of the same one-time-identifier on different sessions may not correspond to the same user, and may not imply a relation between the two occurrences) Relationship identifier: an identifier chosen with the intention of being used on several sessions, with the same communication partner. Depending on its privacy policy and on the amount of information linked to a particular identifier, an entity may still regard the disclosure of one of his private identifiers (in connection with some activity of him, his location or other attribute) to be a violation of his privacy right. The word "authentication" is used with different meanings, (see for instance the endless discussions on the mobile-ip mailing list during 2001). Some people insist that authentication associates an entity with a more or less well-known identity. This basically means that if A authenticates another entity as being "B", then the label "B" has also a meaning for many entities different from A. In many situations, including pre-paid services, token-based or role-based authorizations, unauthenticated key agreement, and purpose-based identifiers, there is no need for explicit authentication in the following sense: Explicit Authentication The act of verifying a claimed identity, in the form of a pre-existing label from a mutually known name space, as the sole originator of a message (message authentication) or as the end-point of a channel (entity authentication). [30]. Nevertheless, the communication partner wants to make sure that he is communicating to the same entity during the whole session. Thus message authentication codes are used, based on "unauthenticated keys". To avoid confusion let us introduce the following definitions: Purpose-built Authentication The act of verifying that a communication partner, as sole originator of a message or as the end-point of a channel, is the same as a particular previous communication

204

Chapter 8 partner (of the same or of a different entity). The term is borrowed from the Internet Draft S. "A Framework for Purpose Built Keys, PBK" by Bradner, A Mankin, and J. Schiller (Feb 2001, work in progress).

Authorization The act of determining if a particular right, such as access to some resource, can be granted to the presenter of a particular credential. Depending on the type of credential, authorization may imply explicit authentication or not. Authorization credentials may be used very much in the same way as authentication credentials to secure a key agreement in the following sense: one party is assured that no other party aside from the owner of the authorization credentials (and possibly additional identified trusted parties) may gain access to the agreed secret key. The resulting keys are called authorized keys. In real life this corresponds for instance to the following situation: at a cloakroom a person deposits his coat and receives a credential that he may use later to obtain back the coat. Many authorization tokens, electronic variants of coins, vouchers, tickets, prescriptions, have been devised, see for instance [11], [12], [13], [30], [36], [46]. Purpose-built authentication may be implemented in the following way: the claimer creates an ephemeral label that will be used to correlate the different appearances of the claimer to the verifier, together with a corresponding secret. The label, called a purpose-built identifier, and the secret are linked by some mathematical relation. Then the creator can prove "ownership" of the purpose-built identifier, that is, that he knows a corresponding secret. This proof may be achieved via a signature or a challenge-response exchange. For instance, the label is the hash value of a public key, like in the Purpose Built Keys Internet Draft, mentioned above. Purpose-built identifiers may be certified and bound to a real identity or to other attributes of the user, as for instance in the proposals of Moskowitz on HIP (see the drafts on Host Identity Payload And Protocol, work in progress) when the Host Identity Tag (HIT) is certified by DNSSec, or in the proposals of [6] or [10]. PolicyMaker [6] does not use certificates-based on the binding of true identities to keys, but rather it allows requesters of secure services to prove directly that they hold credentials that authorize them to use those services. PolicyMaker binds public keys (purpose-built identifiers) to predicates that describe the actions that they are trusted to sign for, rather


205

than to the names of the keyholders as in current PKI system. The system makes decisions when presented with attributes and requests for access to a service or resource, like a location data. Another possibility is that the CA, which assigns properties to the purpose-built identifiers, achieves this by means of blind digital signatures, [10]. With any of the proposals [11], [7] and [27], it is possible for the user to obtain a credential from one organization using one pseudonym, and demonstrate possession of the credential to another organization without revealing the first pseudonym. For this purpose, a credential can be converted into a credential for the currently used pseudonym. The use of different credentials is unlinkable. 4.2.3

Some Realizations of the Identity/credential Requirements

The first goal is to hide the identity of the owner or target to the Ultimate Location Recipient. This may be easily done using pseudonyms, public local names, group or role identifiers, one-time identifiers, or private names as described in Sections 4.2.1 and 4.2.2. The second goal is to hide the identity of the Location Recipient to the Location Server. Nevertheless, the Location Server has to be sure that the Owner has authorized the recipient to access the location. This is a case of purpose-built authentication: the Location Server has to be sure that the Location Recipient is a particular (i.e., authorized) communication partner of the Owner. This may be done as follows: consider a Location Recipient that obtains a set of "traveller's cheques" from an owner of the privacy rights of a target. The cheques will be used to "buy" location information from a Location Service. Initially, the Location Recipient signs for a first time the cheques with any "signature" that he wants to use. The owner, through his own signature, authorizes the signature of the Location Recipient. When presented to the Location Server, the cheques may be countersigned so that the server is sure that the signer is the same as the one who was authorized by the owner. This countersignature does not only authenticate the Location Recipient to the verifier, but also indirectly to the owner, when the cheque is later presented to him. Incidentally, the owner may achieve full information about who has accessed to his location information. To hide the real identity of the owner to the Location Server, the following dual solution can be used. An owner buys (say, using e-cash) a service from a Location Recipient (e.g. a navigation service). During this transaction, the Location Recipient and the owner agree on one or several pseudonyms and a set of "traveller's cheques" that the target may use later to

Chapter 8

206

authenticate himself to the server and thus indirectly also to the Location Recipient. Since e-cash protocols may be also anonymous, this may be used to hide simultaneously, the identity of the target from the Location Server, the identity of the Location Recipient from the Location Server, the identity of the target from the Location Recipient. But notice that the Location Data Source is in general not able to localize the target based on some short-lived identifier. In this scenario, the Location Data Source should be a Location Server, a different one from the one from whom the identity of the target is to be hidden.

5.

SUMMARY OF REQUIREMENTS

This section collects the possible requirements that are suggested from the discussion so far, making them also more explicit: The following message flows should be secured (mutual endpoint authentication, data object integrity, data object confidentiality, replay protection): LI, Pol, LIF, LRequest, and PolInfo. In full details an with all its consequences, this requirement is already difficult to achieve: the communicating parties must have security relationships between them, allowing them to dynamically construct secure channels between them. This may imply that some scenarios should not be permitted in general. Identity smart cards with cryptographic material providing different attributes, like authorization tokens, roles or short-lived identities, should be allowed. They should allow different authentication schemes, including the integration of conventional and "privacy-friendly" public key infrastructures. (For instance, [7]). It is reasonable to hide the identity of the target and the owner to the Ultimate Location Recipients, and also to hide the identities of the Location Recipients to the Location Server, but not necessarily the identity of the Location Server. Thus, part of the communication to the Location Server may be secured using the X509v3 public key of the Location Server, and/or TLS, but


207

communication to the target or Location Recipient should be authenticated in the general case using some kind of dynamical identities and keys, like private or purpose-built identities. Authorization without explicit authentication should be allowed When a Location Server accepts a policy from an owner, the target must prove the ownership of the claimed group or role identifier that should be passed to the Location Recipient. The target should not be positioned unless the positioning attempt is explicitly authorized Users should be able to disable the precise location determination at any time without disconnecting their device from the network. Users should also be able to disclose their location information at a chosen level of precision (e.g. building, street, city or state level). An API or user interface to manage different pseudonyms / roles / identity cards should be envisioned. The storage of personal data should remain under user control: Policy based use and disclosure access The policy language must be strong enough to express policies like the example in Section 3.2.4. It should be possible to express restrictions on time of the day and location, credentials presented, and type of recipient. The "generic" policies (as opposed to the policies created by the owner of the privacy) used by the Location Data Source, by the Ultimate Location Data Recipients and by the Location Server of Scenario 3 must be made explicit and standard and there should be a method for controlling or supervising their enforcement. If explicitly required by an owner, the system should provide cryptographic logging facilities or other secure possibility of recording the communication in order to be able to reconstruct which party possesses which personal data in case of abuse. This reconstruction should be only possible with the explicit consent of the owner or a legal authority (a judge). In this case identity escrow is also needed. Editor / negotiation tool for policies Support of user-controlled privacy facilities grant of consent, data inspection, desire for change, desire for removal, and revocation of consent,

208

Chapter 8

Notification Interface and/or negotiation tool for other aspects like personal reachability or security configuration, Support from privacy protection authorities, help with configuration; Compliance with legal framework Emergency Services Lawful Interception Even with policy enforcement and a privacy protecting Identity Manager, attacks using the layer 2 or 3 identity or using traffic analysis are not banned. They have to be considered and dealt with independently. Note that this work is an ongoing effort. A more systematic analysis of the weaknesses of the proposed requirements and solutions has to be done. Any suggestion is greatly appreciated. Also, the harmonization of requirements and policy expressiveness for the different systems and standards should be pursued.

6.

REFERENCES

[1] 3GPP (3rd Generation Partnership Project), Technical Specification Group Core Network, Universal Geographical Area Description (GAD), Release 1999, Technical Specification, 3G TS 23.032 V3.1.0 (2000-03) [2] N. Asokan, "Anonymity in Mobile Computing Environment", IEEE Workshop on Mobile Computing Systems and Applications, Santa Cruz, CA, 1994, http://citeseer.nj.nec.com/ asokan94anonymity.html [3] N. Asokan. Security Issues in Mobile Computing. Unpublished manuscript, October 1994. http://citeseer.nj.nec.com/ asokan94security.html [4] O Berthold, M Köhntopp: Identity Management Based On P3P,in: H Federrath (Ed.): Designing Privacy Enhancing Technologies; Proc. Workshop on Design Issues in Anonymity and Unobservability; LNCS 2009; 2001; 141-160 [5] M Blaze, J Feigenbaum, J Ioannidis, and A D. Keromytis: The Role of Trust Management in Distributed Systems Security. In: Vitek, J., Jensen, C.D., (Eds.), Secure Internet Programming, Security Issues for Mobile and Distributed Objects , Lecture Notes in Computer Science.1603, Pages 185-210, Springer


209

[6] M Blaze, J Feigenbaum, and J Lacy: Decentralized Trust Management. [7] Brands S A.: Rethinking Public Key Infrastructures and Digital Certificates, The MIT Press, Cambridge, Massachusetts, August 2000. ISBN 0-262-02491-82000 [8] Brands S A:. Private credentials. White paper by Zero-Knowledge Systems, Inc., November 2000. Available at: http://www.zks.net/media/credsnew.pdf. [9] D. L. Chaum. Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms. Communications of the ACM, 24(2):84–88, February 1981. [10] D. Chaum, Security Without Identification: Card Computers to Make Big Brother Obsolete, Available at: http://www.chaum.com/ articles/Security_Wthout_Identification.htm Updated Version of: Security Without Identification: Transaction Systems to Make Big Brother Obsolete. Communications of the ACM, 28(10): 1030--1044, October 1985. [11]. D Chaum: Showing Credentials without Identification: Transferring Signatures between Unconditionally Unlinkable Pseudonyms; in: J. Seberry/J. Pieprzyk (Eds.): Advances in Cryptology, AUSCRYPT '90, volume 453 of Lecture Notes in Computer Science, 8-11 January, 1990, Sydney, Australia, Springer; 246-264. [12] D. L. Chaum. Achieving Electronic Privacy, Scientific American, August 1992, p. 96-101. [13] Chor, B., Goldreich, O., Kushilevitz, E., and Sudan, M. Private information retrieval. Journal of the ACM 45, 6 (1998), 965–981. [14] J Claessens, B Preneel, and J Vandewalle: "Solutions for Anonymous Communication on the Internet", in Proceedings of the IEEE 33rd Annual 1999 International Carnahan Conference on Security Technology, ICCST’99, Madrid, Spain, October 5-7, 1999, pp 298-303 [15] J. Claessens and B. Preneel and J. Vandewalle, "Anonymity controlled electronic payment systems", 20th Symp. on Information Theory in the Benelux, A. M. Barb et. al. (Editors), ISBN: 90-71048-14-4, pages 109--116, 1999. [16] http://www.cdt.org/privacy/ [17] EPIC (Electronic Privacy Information Center): Surfer Beware III: Privacy Policies without Privacy Protection, December 1999, http://www.epic.org/reports/surfer-beware3.html

210

Chapter 8

[18]

geopriv (Geographic Location/Privacy WG if the IETF) http://search.ietf.org/html.charters/geopriv-charter.html, mailing list archive available at: ftp://ftp.ietf.org/ietf-mail-archive/geopriv

[19] The Guardian, 27 Oct 2001, http://www.guardian.co.uk/mobile/ article/0,2763,581763,00.html [20] J Hagel, M Singer: Net Worth: Shaping Markets When Customers Make the Rules; Harvard Business School Press, U.S.; 1999. [21]

International Working Group on Data Protection in Telecommunications: Common Position on Privacy and location information in mobile communications services. Adopted at the 29th meeting of the Working Group on 15/16 Februar 2001 in Bangalore. http://www.datenschutz-berlin.de/doc/int/iwgdpt/locat_en.htm

[22] ISO IS 15408, 1999, http://www.commoncriteria.org/. [23] Hiroyuki Kanemitsu, Tomihisa Kamada, POIX: Point Of Interest eXchange Language Specification, W3C Note 24 June 1999, http://www.w3.org/TR/poix [24] B. Lampson. Designing a global name service. In Proceedings of the 5th Symposium on Principles of Distributed Computing, ACM SIGACTSIGOPS, pages 1--10, 1986. Available through http://citeseer.nj.nec.com/lampson86designing.html [25] Leonhardi, A.; Rothermel, K.: A Comparison of Protocols for Updating Location Information, To appear in Special Issue on Spatial Location in Networking, Baltzer Cluster Computing Journal, Baltzer Science Publishers, 2001. [26] U. Leonhardt and J. Magee: Security Considerations for a Distributed Location Service, http://citeseer.nj.nec.com/105245.html [27] A Lysyanskaya, R Rivest, A Sahai, and S Wolf. Pseudonym systems, Proceedings of SAC 99, Available at: ftp://ftp.inf.ethz.ch/pub/crypto/publications/LRSW99.ps [28] LIF: Definition of a Mobile Location Query API, Contribution to Location Inter-operability Forum (), API Specification, v. 0.5, 18 Oct 2000 [29] D. V. Martin Jr.: Local Anonymity in the Internet, PhD Thesis, Boston University Graduate School of Arts and Sciences, 1999 [30] A J. Menezes, P C. van Oorschot and S A. Vanstone; Handbook of Applied Cryptography, CRC Press, ISBN: 0-8493-8523-7, Fourth Printing, July 1999


211

[31] NMEA: Bennett P., The NMEA FAQ, version 6.3, April 25, 2000, http://vancouver-webpages.com/pub/peter/nmeafaq.txt [32] OECD: Guidelines on the Protection of Privacy and Transborder Flows of Personal Data, 1980, updated 05 January 1999 http://wwwl.oecd.org/dsti/sti/it/secur/prod/PRTV-EN.HTM [33] OGC: Lake, R., Cuthbert, A. (eds.), Geography Markup Language (GML) v1.0, OGC Document Number: 00-029, 12-May-2000, http://www.opengis.org/techno/specs/00-029.pdf [34] S Olsen " Privacy flaw continues to dig IE hole", CNET News.com, January 15, 2002, 2:40 p.m. PT http://news.cnet.com/news/0-1005200-8494180.html [35]

P3P Glossary: Available http://www.privacyfoundation.org/resources/glossary.asp

at:

[36] Andreas Pfitzmann, Marit Köhntopp: Anonymity, Unobservability, and Pseudonymity - A Proposal for Terminology; in: H Federrath (Ed.): Designing Privacy Enhancing Technologies; Proc. Workshop on Design Issues in Anonymity and Unobservability; LNCS 2009; 2001; 1-9. Newer versions available at http://www.koehntopp.de/marit/pub/anon/ [37] RFC 2486: B. Aboba, M. Beadles. The Network Access Identifier. January 1999. [38] RFC 2692: C. Ellison: SPKI Requirements. September 1999. [39] RFC 2693: C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T. Ylonen: SPKI Certificate Theory.. September 1999 [40] RFC 2704: M. Blaze, J. Feigenbaum, J. Ioannidis, A. Keromytis. The KeyNote Trust-Management System Version 2, September 1999. [41] R. L. Rivest and B. Lampson. SDSI - A Simple Distributed Security Infrastructure. Version 1.1, Presented at CRYPTO'96 Rumpsession, http://theory. lcs.mit.edu/rivest/sdsi11.html, 1996. [42] S. Schneider and A. Sidiropoulos CSP and anonymity , ESORICS, LNCS 1146, 1996. [43] Sekiguchi, et al., Navigation Markup Language (NVML), W3C Note 6 Aug 1999,http://www.w3.org/TR/NVML [44] Kerry L. Shackelford: "Privacy: A Report from the Front Lines" and "Privacy: Taking Action to Safeguard Customer Loyalty", Electronic Banking Law and Commerce Report, Glasser LegalWorks, 150 Clove

212

Chapter 8

Road, Little Falls, NJ http://www.andersen.com/

07424,

Oct/Nov 2001. Available at:

[45] Shmatikov, V., and Hughes, D.J.D. Defining Anonymity and Privacy (extended abstract). In Workshop on Issues in the Theory of Security (WITS '02), 2002. [46] S. Stubblebine, P. Syverson, and D. Goldschlag. Unlinkable Serial Transactions: Protocols and Applications, ACM Transactions on Information and System Security, Vol. 2, No. 4, Nov. 1999. [47] S. Stubblebine, and P. Syverson. Authentic Attributes with FineGrained Anonymity Protection, Financial Cryptography 2000, LNCS Series, Springer-Verlag, 2000. [48] Paul Syverson and Stuart Stubblebine. "Group Principals and the Formalization of Anonymity", in FM'99 Formal Methods, Vol. I, J.M. Wing, J. Woodcock, and J. Davies (eds.), Springer-Verlag, LNCS vol. 1708, pp.814-833, 1999. [49] US Department of Commerce Safe Harbor Privacy Principles, issued on 21 July 2000. Available with the corresponding Commission Decision of the EU of 26 July 2000 at: http://europa.eu.int/comm/trade/pdf/safeharbour.pdf [50] John Wells, Claude Castelluccia, Cloaking: Location Hiding in IPv6, Inria Rhone-Alpes, Rapport de Recherche, June 25, 2001, ISSN 02496399, Available through http://www.inria.fr [51] Westin, A: Privacy and Freedom, New York, Atheneum, 1967 [52] Zero-Knowledge Systems. The Freedom Network Architecture. http://www.zeroknowledge.com/.

Index

AAA authentication authorization and accounting, 5 Active Badge, 3 AFLT positioning advanced forward link trilateration, 32 AGPS assisted GPS, 35 anonymity, 196 API application programming interface, 4 AS application server, 99 Bat, 3 Active Bat indoor system, 3 BSS base station subsystem, 16 CDMA CDMA2000, 51 code division multiple access, 51 CoolTown project, 151 CSCF

call state control function, 77 dead-reckoning protocol, 112 E911 Enhanced 911, 2 GAD geographical area description, 37 Geotags robot, 156 Geotags search engine, 144

GMLC gateway mobile location center, 22 serving mobile location center, 22 GPS geographic positioning system, 2 GSM, 13 Guide system, 3 HLR home location register, 17 keywordless geographic search, 152 LBS location based services, 2 location services, 21 LIF location inter-operability forum, 7, 11

LMU location measurement unit, 23 Location Data Source, 182 location information policy, 178 Location Recipient, 182 Location Server, 72 location service scenarios, 163 map quantization, 149 MGW media gateway, 78 MLP, 7 mobile location protocol, 85 MPC mobile position center, 52

214 NAI network address identifier, 198 ownership of the privacy rights of the target, 182 P3P, 197 PDE position determination entity, 52 policy language, 186 Position Server, 4 privacy rules, 161 Proxy Server, 72 pull-model, 187 Redirect Server, 72 Registrar Server, 72 SIP session initiation protocol, 70 SLA

Index service level agreement, 189 SMS short message service, 59 target, 180 TDOA positioning time difference of arrival, 29 UA user agent, 72 UMTS, 22 URL rewriting, 149 VLR visitor location register, 17 WAP wireless application protocol, 28, 88 WGS 84 World Geodetic System 1984, 2

Geographic Location in the Internet

Location, Location, Location

Location, Location, Location

Language in geographic context

Language in Geographic Context

The Perfect Location

The Location of Culture

The National Geographic Traveler.Египет

On Location

On Location

The Perfect Location

Geographic Information Systems in Business

Geographic Information Systems in Business

Advances in Location-Based Services

Geographic hypermedia

Geographic Profiling

IP Location

Internet Society: The Internet in Everyday Life

Collaborative Geographic Information Systems

Multidimensional geographic information science

Geographic Information Systems Demystified

Location-Aware Applications

Geographic Information Analysis

Geographic Information Systems in Transportation Research

Location, Localization, and Localizability: Location-awareness Technology for Wireless Networks

Geographic Information Analysis

The Location of the treasury of Atreus

Geographic Information Systems in Water Resources Engineering

Geographic Information Systems in Oceanography and Fisheries

National Geographic November 2010

Geographic Location in the Internet

Location, Location, Location

Location, Location, Location

Language in geographic context

Language in Geographic Context

The Perfect Location

The Location of Culture

The National Geographic Traveler.Египет

On Location

On Location

The Perfect Location

Geographic Information Systems in Business

Geographic Information Systems in Business

Advances in Location-Based Services

Geographic hypermedia

Geographic Profiling

IP Location

Internet Society: The Internet in Everyday Life

Collaborative Geographic Information Systems

Multidimensional geographic information science

Geographic Information Systems Demystified

Location-Aware Applications

Geographic Information Analysis

Geographic Information Systems in Transportation Research

Location, Localization, and Localizability: Location-awareness Technology for Wireless Networks

Geographic Information Analysis

The Location of the treasury of Atreus

Geographic Information Systems in Water Resources Engineering

Geographic Information Systems in Oceanography and Fisheries

National Geographic November 2010

Recommend Documents