Wireless Devices & Location Smart Databases

IETF and the Spatial Location Protocol (SLoP)
The Internet Engineering Task Force (IETF) is working on a new protocol called the spatial location protocol (SloP) [BOF]. The problem they are trying to solve with this protocol is: “How can an application on an IP network acquire the location of something represented on an IP network in a reliable, secure, and scalable manner?” The components of the necessary architecture are very similar to those we have already discussed:

The Client	This is the element that requests the Physical Location of something (called the Target).
The Server	This is the element that provides the Physical Location of the Target to the requesting Client.
The Target	This is the element whose Physical Location the Client requests.
The Proxy Server	Is a Serverthat either aggregates great numbers of Targets for location requests, or represents itself in place of Targets that do not have their own Server Processes.

In order to determine where the Target is, the Client makes a request of a Server, which could either be a process on the Target Device, or a Proxy Server representing the Target. This Birds-of-a-Feather group within the IETF is still very much in its formative stage and among the issues that they are still discussing are:

The mechanism by which the SLoP server acquires the location of the Target should be undefined.
Targets should be either IP Devices, or that which can be represented by IP Devices (like a Proxy Server).
Targets could be things that are non-IP targets that are nameable with a URL.
The SLoP should represent Location using a format that includes the following as a minimum for interoperability reasons: Longitude, Latitude, Altitude, Timestamp, and accuracy. The specific Data Format has not been agreed to yet. Additional coordinate representations should be allowed, but these should be optional and negotiated between elements. They further recommend that an Abstract Location representation Model (such as civic address) be considered.
To determine which format is chosen, there should be a negotiation mechanism between the Client and the Server either on the Target Device, or in representation of that Target (performing as a Proxy Server for that Target in this case).
The SloP should have a policy mechanism that determines who gets what, when they get it and how it's delivered. This should likely be coordinated based on the Profile of that Target.
Security involving Authentication, Authorization, Secrecy and Integrity, MUST be considered when creating this Protocol.
In the model they describe, the Client requests the location of a Target. This is a “Pull” Model, which they highly recommend SLoP MUST support as defined as single location requests. There is also a discussion whether a “Push” Model can also be stipulated. They have not reached any agreement on this and are seeking input as to the need for supporting the situation where a Target either uni-directionally or via broadcast, announces its location to one or more Clients; or a situation in which the requesting Client sets some type of reply frequency for automatic location updates from the Target.
The accuracy of the location received should be based on the Profile of a Target, enforced somewhere within the Network. A Server Process shall likely provide a different reply to a SLoP location request from different Client types, or even different Clients.
How can a Target obtain its coordinates?
Where should a target store or register its coordinates?
How can a called party obtain the calling party's coordinates?
How can a target “advertise” its location information? As a new IP device comes on-line within a domain that either has, or mandates, SLoP, it will (likely) determine if a Server exists via DNS query. A “yet-to-be-decided” method of authentication of the Server from the new IP device's point of view should be required. If successful, it should then either transmit or reply, respectively, its location based on the performed function of SLoP to that Server. Again, with a “yet-to-be-decided” method, authentication should be performed, this time from the server's point of view that this is a valid IP device for this domain. Each Server must determine its own location. This location discovery and determination will be performed in a manner outlined/stipulated in the definitions of the Spatial Location Protocol (SLoP) itself.
It appears likely that there is a need for an Authentication Server, similar to a Security Server, which should be within the Network Domain of a SLoP Server in order to validate its existence within that Domain.

Protecting Privacy
There may be a privacy issue with Location Based services. For example, the location of a person (or personal device) may be requested. The following approaches may be used to protect privacy:

Allow No Proxies:	In the no-proxy scenario, the personal device itself must service all requests for the location of a personal device. The owner of the device may adjust parameters in the device to allow, disallow, or selectively allow his or her location to be exposed.
Employ a Proxy:	Mobile devices could delegate to proxy servers the business of exposing their Location. Such a proxy could maintain a list of devices that are allowed to receive Location information to specific personal devices. When the Proxy receives a request for a personal device Location, it checks its list and behaves accordingly.
Issue a Certificate:	In the certification architecture, the Location interface raises an exception unless the interface invocation is accompanied with a certificate allowing the location to be exposed. Certificates are issued by special components on the Internet. Owners of personal devices may be able to influence the criteria by which certificates are issued and denied. An advantage of this architecture is that it provides for certain authorities to use Location services in emergencies.
Other Approaches:	Other approaches to privacy are possible. For example, a personal device may provide selective accuracy. In this scheme, a personal device will only expose the county or country in which the device is located, and more precise information only to those with a password.

Location Based Mobile Services
Location based services depend on the match between a position defining the location of the mobile client and information in location-smart databases. By a location-smart database we mean one that is a collection of features that are a combination of attributes and geometry and potentially an agreed to interface which is exposed either within the SQL layer or external to the database in middle-ware that allows for basic spatial analysis questions to be asked of the features. Such features can be placed in a spatial reference frame by either referring to a feature in one of the following ways:

By name
By its geodetic or projected coordinates
By its relationship to other geographic features
By its relationship to geopolitical features (e.g., zip-code boundaries)
By a proprietary, or authority supplied, feature identifier

The use of a name or a relationship to another feature is the most common approach used by people when asking directions from point A to point B, or when wanting to know where something is in relation to where they currently are. This approach is much more common today than offering position dependent services based on location information supplied by GPS through a wireless network, although there are many initiatives aimed at reversing this. Each of these ways of referring to a location has an inherent precision in the answer of where, and will affect the content returned by a service provider when asked where the “nearest” thing of interest is to that location.

Once the current location of the mobile user has been established, information relative to that location can be retrieved from different sources: further user input; a dedicated unit connected to the mobile device (such as a CDROM with street network data); from information stored in the device (addresses of places of interest, say) or from a position dependent information service over the Internet. Such a location based mobile service requires an architecture that has three major components:

A content provider delivering services adapted to the current user location
A mobile user agent (Gateway or proxy Server) controlling the exchange with the content provider
An entity that is able to compute the user location. This can be dedicated hardware, such as GPS or cell tower hardware that triangulates the position based on a time-delay-of-arrival algorithm (TDOA), or a geocoding service provided over the Internet.

It is also very important that an open interface must be standardized between the mobile device and the service so as to let the market provide independent and interoperable solutions (one of the OpenGIS Consortium’s goals). Authentication of the two parties and security of exchange are strong requirements for this interface, as is the issue of privacy. The privacy of the user will have to be guaranteed. This means that the user will have to formally agree on delivering the location information in the format requested by the content provider. Current industry thinking is that the exchange of XML documents is the natural choice for defining the interface to such a service. To allow for the fact that the user’s position can change between requests for information it is necessary to include the position as a property of the client in the content negotiation. There is also a need to work on the rules that apply to classes of privacy or authorization, regarding knowledge of the location of a mobile device. Each of the following classifications of privacy would have a different rule set:

Emergency response
User pre-authorized
Police tracking
Private security
Corporate user
User initiated service

Each one of these classes could also have a time limitation associated with the authorization and could even be limited to knowing where the mobile device has been, not where it currently is.

Also, the way in which these three components (the device, the location service and the content provider) interact can be quite different:

Scenario 1: Device Pulls Content

Scenario 2: Content Provider Pushes Content

Scenario 3: The Gateway or Proxy Server Owns the Location

Car navigational systems are perhaps the most advanced out of all the location based mobile services, although the content information is almost always based on a static database available in the vehicle. The next generation of such systems will provide for dynamic updates and extensions to the database, such as local weather or traffic reports, selections of locations based on nearness to current location and routing to a selected location (some systems already do this).

PDA’s have come a long way since they were first introduced; today we have competing technologies that have different form-factors and user interfaces; The Palm Pilot family and clones such as the Handspring Visor running Palm OS; Palm look-a-likes running Windows CE; and Pocket PCs.

Positioning has been the starting point for context aware mobile device and several methods exist for knowing where the device currently is, such as GPS, geocoding using a network service, and others. Alternatively, if a topical search engine can discover content with certain properties in its metadata that is relevant at a particular location, this content can be matched with the location preference of the user (current location or location of interest).