INTERNET-DRAFT M. Korkea-aho Internet Engineering Task Force Nokia Issued: 10 March 2000 Expires: 10 September 2000 Some Scenarios for an ISL Architecture Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as 'work in progress.' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Mobile devices place an importance of geo-location. Based upon a user's spatial location, certain applications and servers may differ as compared to other locations. This draft attempts to list some location service scenarios and their impact upon any architecture which serves location based services. Korkea-aho [Page 1] Internet Draft Some Scenarios for an ISL Architecture March 10, 2000 1. Introduction 3 1.1 Scope 3 1.2 Terminology 3 2. Some Scenarios and Implications 3 2.1 Retrieval of Local Information or Service 3 2.2 User Subscribed Services 4 2.3 Broadcasting Information to Devices in a Certain Region 5 2.4 Locate Someone 5 2.5 Infrastructural Services 5 2.5.1 Conversion between Position Presentations 5 2.5.2 Geographical maps 6 3. Some Considerations of Possible Architecture Elements 6 4 Considerations 7 4.1 Security Considerations 7 5 References 8 6 Acknowledgements 8 7 Author's Address 8 Korkea-aho [Page 2] Internet Draft Some Scenarios for an ISL Architecture March 10, 2000 1. Introduction 1.1 Scope This document presents some location service scenarios and their implications to an ISL architecture. The main objectives are to present the need not only for mechanisms for IP devices to provide or announce their spatial position to other IP devices, to request or lookup the spatial position of other IP devices, or to locate IP devices physically located in a certain region. It is as important to be able to locate different services available for a certain spatial region or location, where the services can reside virtually where ever in the IP network. This document builds on the ideas contained in draft-nyckelgard-isl- arch-00.txt [1] and can serve as a basis for further discussions about the need for ISL and its requirements. 1.2 Terminology ISL - IP Spatial Location (Geo-)location (based) service - a service using spatial location LDS - Location Directory Service LIS - Location Information Service Service provider - provider providing location based service Terminal proxy - a device which acts on-behalf of the user's terminal for handling location information requests 2. Some Scenarios and Implications Here are some scenarios which suggest that all above (in section 1.1) mentioned functions should be considered for the ISL architecture. These scenarios should be seen as a limited set of examples, as a basis for further discussion about the needs for ISL and its requirements. 2.1 Retrieval of Local Information or Service Basic assumption: an IP-capable device is providing geo-location based information or service. The device can provide information or service for specific regions or locations. Example A: User N has a mobile device and when moving around (s)he wants to be able to access local information or service (e.g. order taxi, call Korkea-aho [Page 3] Internet Draft Some Scenarios for an ISL Architecture March 10, 2000 hospital, etc.) only by clicking on, e.g. a button or link. No matter where (s)he is (e.g. Helsinki or Munich), the user can push the same button or link and retrieve the local information or service. Example B: User N wants to query for information in a certain region from a web (or some other) server with the user's mobile or static device. Implications: (1) Possibility to find the device providing service or information for the specific spatial region/location. Since the information or service can be located/distributed between different IP devices and may be provided by different providers, there needs to be a way of finding the appropriate place where the information or service resides virtually based on the requester's current spatial location. This could be achieved with a so-called Location Directory Service (LDS). Depending on the capabilities, and the protocols the different parties support; the client terminal, a proxy, or the application server could look up the appropriate local information or service from a Location Directory Service (LDS) for the user. (2) Communicating and obtaining position information. It must be possible for the device providing the service to somehow obtain the position information of the client terminal. There are several mechanisms discussed and envisioned for this (see also [1]): * The client device can provide it * The service provider device can request it from the client device * A terminal proxy presenting the client device can provide it, or it can be requested from it * The client device can publish the location e.g. at a Location Information Service, or Location Directory Service * The client can publish the address of the place where the position can be obtained at a Location Information Service However, the devices might still use other proprietary or not IP-based mechanisms in the complete or as part of the position information acquisition. 2.2 User Subscribed Services Basic assumption: There are separate servers by the service that take care of sending the user subscribed information. The user can set the preferences what kind of messages to receive. Example A: User N is in Adelaide and wants to be notified about sights when walking around. User N can select what kind of sights to be notified of. Implications: (1) The system providing this service must be able to determine the position of the user periodically (track the user) and/or to determine if the user is still within the range for the information to be sent. Korkea-aho [Page 4] Internet Draft Some Scenarios for an ISL Architecture March 10, 2000 The position information or information that the client is not anymore in the region could be retrieved or acquired periodically from the client, terminal proxy, LIS, LDS, or some other instance. (2) In case a distributed system is in consideration, it might be required that the system needs to be able to use certain LDS for determining the server to be used in the other region. 2.3 Broadcasting Information to Devices in a Certain Region Basic assumption: The user should be able to control what kind of broadcast messages to receive. Example A: An authority wants to send out an emergency warning about a severe snow blizzard. Example B: Local site needs to broadcast that it is shutting down for maintenance. Implication: (1) Possibility to determine if an IP devices is in a certain region. The architecture should enable an IP device to publish its location and for other devices to determine if it is in a certain geographical region. This could be done with a Location Information Service (LIS), or Location Directory Service (LDS). 2.4 Locate Someone Example A: User N wants to determine where N forgot N's laptop. Example B: User N wants to know where N's dog is running around (the dog has an embedded IP device in his dog collar.) Implication: (1) Possibility to acquire position information (periodically). The position information could be retrieved or acquired periodically from the client, terminal proxy, LIS, LDS, or some other instance. This may raise certain privacy concerns. If the target to be located is not N's property, N needs the permission from the target in order to do so. 2.5 Infrastructure Services 2.5.1 Conversion between Position Presentations Korkea-aho [Page 5] Internet Draft Some Scenarios for an ISL Architecture March 10, 2000 There are many different ways of presenting location information (E.g. different coordinate representations, street address, city, region). The information can also be presented in different granularities, e.g. on country level, regional level, street level, building level, etc.). Different systems may use different presentation formats and granularities. Users might prefer a specific format. In order to be interoperable and user friendly there will be a need for being able to convert between different presentation formats. These conversions can be conducted on a application level, but it can be argued that one organization will not be able to cover the whole world. A common mechanism for providing conversion services will help solving this problem. Implication: (1) Possibility for parties providing conversion services to publish what kind of conversion they can do, and mechanism for locating a service that can provide the wanted service. Preferably there should be a way to charge for the provided service. 2.5.2 Geographical maps As the conversion service also maps could be served as a general service by different providers. The implications are the same as in the previous case (section 2.5.1). 3. Some Considerations of Possible Architecture Elements When considering an ISL architecture it will be important among others to consider existing solutions, what could be (re)used, interoperability with other systems and system elements, user needs and interests of different players. An abstraction of possible elements in the ISL architecture is presented here for further discussion. Korkea-aho [Page 6] Internet Draft Some Scenarios for an ISL Architecture March 10, 2000 Location Services on IP servers +------------+ +----------+ +---------+ | | | | | | ++ Conversion | | Terminal +-------+ Network | || | | | | gateway | |+------------+ +----------+ | | |+------------+ +---+-----+ || | | ++ Maps | +----------+ | || | | | | |+------------+ | Terminal +-----------+-----------+ |+------------+ | | | | || | +----------+ | +----------+-------++ GIS | | | | || | +---+----+ | | |+------------+ | | +---+---+ +---+---+ |+------------+ |Terminal| | | | | || | | Proxy | | LIS | | LDS | ++ WWW | | | | | | | || | +--------+ +-------+ +-------+ |+------------+ |+------------+ || | ++ ANY | | | +------------+ Where * Terminal can be an IP device or some other device. * Network gateway translates for non-IP terminal devices * Terminal proxy can store terminal spatial location information and acts on-behalf of the terminal for handling location information requests * LIS - Resolves between location and address for client devices * LDS - Resolves where certain location services are available The picture does not necessarily imply a global network, but can be split up according to providers, regions, etc. It is neither implied that all presented elements would be necessary or mandatory. 4 Considerations When possible existing standards and solution should be used. SLP [2] and DNS may be able to solve some parts of the mentioned problems. However, there are still a lot of work to be done. Korkea-aho [Page 7] Internet Draft Some Scenarios for an ISL Architecture March 10, 2000 4.1 Security Considerations Security and privacy are of importance with location based services. The following draft contains some security related needs for ISL systems: draft-polk-slp-loc-auth-server-00.txt [3]. 5 References [1] Internet Draft "draft-nyckelgard-isl-arch-00.txt" S. Nyckelgard and J. Loughney, March 2000, "work-in-progress" [2] RFC2608 "Service Location Protocol, Version 2" E. Guttman, C. Perkins, J. Veizades and M. Day, June 1999 [3] Internet Draft "draft-polk-slp-loc-auth-server-00.txt" James M. Polk and Haitao Tang, March 2000, "work-in-progress" 6 Acknowledgements The author would like to thank all people who have participated on the mailing list at http://www-nrc.nokia.com/ip-location, persons with whom she has discussed about these issues, and who have reviewed this paper. Special thanks goes to the Nokia colleagues. 7 Author's Address Mari Korkea-aho Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organi- zations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." The Expiration date for this Internet Draft is: September 10, 2000 Korkea-aho [Page 8]