INTERNET-DRAFT S. Nyckelgard Internet Engineering Task Force Telia Issued: 8 March 2000 J. Loughney Expires: 8 September 2000 Nokia ISL Architectural Considerations 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. To learn the current status of any Internet-Draft, please check the '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract As more and more wireless devices interact with IP networks, location becomes an important parameter in providing and accessing services. This draft strives to provide an architecture to answer the following questions: 1) How can a terminal obtain its coordinates? 2) Where should a terminal store or register its coordinates? 3) How can a called party obtain the calling party's coordinates? 4) How can a terminal 'advertise' its location information Internet Draft ISL Architectural Considerations March 2000 1. Introduction.......................................................3 1.1 Scope ............................................................3 1.2 Terminology ......................................................3 1.3 Architecture .....................................................3 1.3.1 Reference Model ...............................................3 1.3.2 Implementation Scenarios ......................................4 1.3.3 Component Interfaces ..........................................5 2 Location Information.................................................5 2.1 Obtaining Location ...............................................5 2.2 Placement and Distribution of Location Information ...............6 3 Protocol Considerations..............................................6 3.1 Accuracy .........................................................6 3.2 Time To Live .....................................................6 4 Procedures...........................................................6 4.1 Obtain Location of the Callee ....................................6 5 Possible Services....................................................7 5.1 Broadcast Services ...............................................7 6 Privacy Concerns.....................................................7 7 Security.............................................................8 8 Acknowledgements.....................................................8 9 Authors' Addresses...................................................8 Nyckelgard, et al. [Page 2] Internet Draft ISL Architectural Considerations March 2000 1. Introduction 1.1 Scope This document strives to present basic considerations on developing an architecture to support location information services. This architecture should consider solutions being developed within other bodies, such as the WAP Forum and W3C. The architecture developed should support and interwork with such other architectures rather than replace them. 1.2 Terminology Location Information Service (LIS) - A DNS-like service that resolves location to address, and visa-versa. Location Proxy - A device which acts on-behalf of the terminal for requesting and authorizing Location Services. Terminal - A device which is the end user of location based services. 1.3 Architecture 1.3.1 Reference Model The figure below shows a reference model for a Spatial Location (SL) service. It shows the components that are involved but does not suggest how and where these components should be implemented. +-----------+ (A) +----------+ (B) +-------------+ | User |---+---| Location |---+---| Positioning | | Interface | | Agent | | Function | +-----------+ +----+-----+ +-------------+ | | (C) +-------------+ `---------+---| Information | | User | +-------------+ A User Interface (UI) is what the user utilizes to manage Location Agents. An UI is typically implemented as an integral part of a mobile terminal or as an application on top of a WEB and/or WAP server belonging to a Network Provider. A Location Agent (LA) is stores and distributes location information related to a specific terminal. It is typically implemented in the terminal in concern or in a server (Location Proxy) at an arbitrary place, not necessarily owned by a Network Provider. A Positioning Function (PF) determines the location of a given terminal. It is typically an integral terminal function, e.g. based on GPS, or a Location Information Service (LIS) provided by a Network Provider, e.g. based on radio cell information or a triangulation mechanism. An Information User (IU) is typically a value-added service, a lifesaving service (emergency center, etc.) or a terminal-integral display function. Nyckelgard, et al. [Page 3] Internet Draft ISL Architectural Considerations March 2000 There MAY be multiple instances of a LA serving to the same terminal, though not necessarily instances of the same LA implementation. Each LA instance MAY interact with multiple PF and IU. 1.3.2 Implementation Scenarios The reference model can be implemented in several different ways. In a Terminal Centric implementation the UI, LA and PF are integrated in an advanced mobile terminal, thus giving the user access to the service regardless of if the Network Provider provides a Spatial Location service or not. +------------------------+ | Terminal | | | | +----+ +----+ +----+ | +----+ | | UI +--+ LA +--+ PF | | +----+ | | +----+ +--+-+ +----+ | +----+ |-+ | `----------------+ IU |-+ +------------------------+ +----+ Figure: Terminal Centric Implementation In a Network Centric implementation, the UI, LA and PF are parts of a service node, enabling the Network Provider to provide a complete Spatial Location service that does not require any support from the terminal. +----------+ +------------------------+ | Terminal | | Location Proxy + LIS | | | | | | | WEB/WAP | +----+ +----+ +----+ | +----+ | |-----------+ UI +--+ LA +--+ PF | | +----+ | | | | +----+ +--+-+ +----+ | +----+ |-+ | | | `----------------+ IU |-+ +----------+ +------------------------+ +----+ Figure: Network Centric Implementation In a mixed implementation UI could, for example, be implemented in the terminal, use a PF provided by the current Network Provider and use a LA that is integrated with the user's home domain location service (SIP Registrar Server, Gatekeeper, etc.). +----------+ +--------+ +--------+ | Terminal | |Location| | LIS | | | | Proxy | | Server | | +----+ | | +----+ | | +----+ | | | UI +---------+ LA +--------+ PF | | | +----+ | | +--+-+ | | +----+ | +----+ | | | | | | | +----+ | +----------+ +----|---+ +--------+ +----+ |-+ `----------------------+ IU |-+ +----+ Figure: Mixed Implementation Nyckelgard, et al. [Page 4] Internet Draft ISL Architectural Considerations March 2000 1.3.3 Component Interfaces Information that is distributed periodically or recurrently generates less network load if the distribution is based on a subscription mechanism since information can be carried by one-way messages. A retrieve mechanism requires two-way signaling, a query and a response. It is hence to prefer that propagation of location information be based on a subscription-oriented model. The reference model identifies three interfaces, (A), (B) and (C). +----+ (A) +----+ (B) +----+ | UI |-----| LA |-----| PF | +----+ +----+ +----+ | | (C) +----+ `-------| IU | +----+ Figure: Component Interfaces Interface (A) is used for managing the LA. The UI can subscribe to distribution of location information, i.e. making the LA forward location information, obtained from a PS, to any number of IU. Interface (A) can also be used for ordering LA to subscribe to Location Information from one or more LIS or to seek for a new LIS. It can also be used for informing LA which IUs that are authorized to request location information. The latter should only be used for lifesaving services, not for value-added services. Interface (B) is used for subscribing to location information from a LIS and for conveying location information from LIS to the subscribers. Interface (C) is used for conveying location information from LA to IU and for authorized IU to retrieve location information on demand. It might be a good idea to use deliverables from the IMPP WG for the subscription mechanisms and just add specifications of message formats for location related messages. 2 Location Information 2.1 Obtaining Location Geographical coordinates for a terminal can for example be obtained from: * A terminal-integral PF, e.g. a GPS receiver. * A network-integral PF, e.g. based on a triangulation mechanism. * A terminal configuration file (only suitable for fixed devices). In order to make all solutions inter-operate, a standard format for location information should be developed. Nyckelgard, et al. [Page 5] Internet Draft ISL Architectural Considerations March 2000 2.2 Placement and Distribution of Location Information The storage of the location information is the user's responsibility. The user must hence have, or subscribe to, one or more Location Agents (LS) that collect, store and forward location information. The terminal itself can include a LA. Alternatively the Access Network Provider and independent Service Providers can provide LAs that act on behalf of the user that subscribes to it. Enterprise servers like SIP registration Servers and Gatekeepers can also include this function. The LA is instructed via the UI to automatically distribute location information or to provide location information on demand to specified IUs. It's the user's prerogative to control the location information by means of controlling the LA. 2.3 Location Information Format It is suggested that a common format be adopted for presenting and storing location information in order to support uniformity and interworking. GPS coordinates could be the basis for such a format. Regardless of which mechanism that is used to obtain the location information, the location should be expressed in a common formation (such as GPS coordinates) with the addition of a statement of accuracy. For example, in a cellular network the coordinates may be those of the base station and the stated accuracy would depend on the size of the radio cell. 3 Protocol Considerations Any protocol designed to support this architecture will have to transport several things, among them location information, accuracy of the location information and time-to-live of the location information. 3.1 Accuracy Depending on the technique and technology used to location a user, there will be some degree of accuracy associated with the location information presented. 3.2 Time To Live In a mobile environment, the location information may not be accurate for long. All location information data MUST be have an associated time-to-live field with it. If the time expires before an update is made to the location information data, then the location information data MUST be assumed to be invalid. 4 Procedures 4.1 Obtain Location of the Callee Nyckelgard, et al. [Page 6] Internet Draft ISL Architectural Considerations March 2000 There are several solutions for obtaining the location of the callee, for example: * The callee can provide the coordinates in the call set-up message (e.g. in SIP INVITE). * The called party can request coordinates directly from the callee, e.g. via a new protocol. The callee should be able to reject the request unless it comes from a client that is trusted by national authorities, etc. A certificate issued by a certain (international) authority and included in the request message can indicate that "law" requires the coordinates to be provided. This solution eliminates the need for terminals to store and maintain a list of destination numbers to which coordinates must be provided. This should work world wide and the user doesn't have to re-program the terminal when accessing from different locations. * Request coordinates from the user's location server, e.g. by means of a SIP OPTIONS message. The user's location server will only provide coordinates to clients that the user has listed as trusted (requires a digital signature) and to clients that are trusted by national authorities. Requires certificate (as above) and the user must keep his location server update. * Use a new protocol to request coordinates from the network operator that administers the callee's network access. The called party would need to be able to map the calling address (CLI or IP address) to the operator's location server. The server should only accept requests from clients that are trusted by national authorities. Requires certificate (as above). 5 Possible Services 5.1 Broadcast Services Services such as broadcast of emergency warnings, are one possible service. When a user enters a new domain (the terminal connects to a new network) the local Location Information Server provides services that I can subscribe to. Terminals could also be programmed to automatically subscribe for certain services, for example emergency information. If the service requires location information, again it is the user that shall provide the information to the service, not the network. When the user leaves the domain, the terminal should automatically unsubscribe any local services. 6 Privacy Concerns Location information presents privacy concerns. It could be possible to track a user's location if not designed correctly. It is a basic assumption that the user MUST be in control of his/her location information. The user MUST explicitly authorize access to his/her location information data. Nyckelgard, et al. [Page 7] Internet Draft ISL Architectural Considerations March 2000 It should be noted that there may be local regulations which necessitate the access of location information data to third parties (for the purposes of emergency calls, etc.). 7 Security The communication between the various entities transporting location information data MUST be secure. There must be an authorization method for allowing users to access location services and allowing those services from querying users based upon location information. 8 Acknowledgements The authors would like to thank the members of the IP-Location mailing list for their comments and on-going discussion of related matters. 9 Authors' Addresses Soren Nyckelgard Telia Research AB Chalmers Teknikpark 41288 Goteborg SWEDEN soren.m.nyckelgard@telia.se John Loughney Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland john.loughney@nokia.com Nyckelgard, et al. [Page 8]