Wireless Devices & Location Smart Databases

Wireless Devices & Location Smart Databases

David Warren
Vice President R&T Cquay Inc.
300, 555 4th Ave SW Calgary, Alberta, Canada

A number of international organizations are active in the field of location based mobile services, in particular, the OpenGIS Consortium [OGC], the World Wide Web Consortium [W3C] and the Wireless Application Programming Forum [WAP]:

The OGC manages consensus processes that result in interoperability among diverse geo-processing systems. To paraphrase the consortium’s own words: “Much geospatial data is available on the web and in off-line archives, but it is complex, heterogeneous, and incompatible. Users must possess considerable expertise and special geographic information system (GIS) software to overlay or otherwise combine different map layers of the same geographic region. Data conversion is cumbersome and time-consuming, and the results are often unsatisfactory. Common interfaces are the only way to enable overlays and combinations of complex and essentially different kinds of geographic information to happen automatically over the Internet, despite differences in the underlying GIS software system. OGC brings together key players and provides a formal structure for achieving consensus on the common interfaces.”
The W3C is dedicated to leading and advancing the development of the World- Wide-Web.
The WAP Forum is dedicated to enabling advanced services and applications on mobile wireless devices, such as cellular phones, pagers, personal digital assistants and other wireless terminals.

In 1997 there was an upsurge of interest amongst W3C members for access to the web via mobile and wireless devices. In 1998 the mobile access interest group was formed in the W3C. This group is chartered with the investigation of the impact of mobile access on the specifications and recommendations of the W3C.

The objectives of the WAP Forum are:

To bring Internet content and advanced data services to digital cellular phones and other wireless terminals.
To create a global wireless protocol specification that will work across different wireless network technologies.
To enable the creation of content and applications that scale across a very wide range of wireless networks and wireless device types.
To embrace and extend existing standards and technology wherever appropriate.

Both W3C and the WAP Forum are working together to achieve the following:

Bring Internet and WWW technologies to digital cellular phones and other wireless terminals by adapting the Web architecture to the wireless environment.
Establish productive working relationships between the W3C and WAP Forum in the areas where common organizational goals exist.
Reduce overlapping technical work between the W3C and WAP Forum.
Cross reference technical specifications and perform joint test-bed and protocol validation work.
Work toward a unified information space and toward common standards and technologies.
Enable the delivery of sophisticated information and services to mobile wireless terminals.

Technical Problems
Providing Internet services on a wireless data network presents many challenges. Most of the technology developed for the Internet has been designed for the desktop and larger computers supporting medium to high bandwidth connectivity over generally reliable data networks. Similarly, wireless data networks present a more constrained communication environment compared to wired networks, because of fundamental limitations of power, available frequency spectrum, and mobility.

Several fundamental constraints place restrictions on the type of protocols and applications offered over the network. They are:

Power consumption – as bandwidth increases, power consumption increases and in a mobile device this reduces battery life.
Cellular network economies – mobile networks are typically based on a cellular architecture. Cells are a resource shared by all mobile terminals in a geographic area, and typically have a fixed amount of bandwidth to be shared amongst all users. This characteristic rewards efficient use of bandwidth, as a means of reducing the overall cost of the network infrastructure.
Latency – the mobile wireless environment is characterized by a very wide range of network latency, ranging from sub-second round trip times to many tens of seconds.
Bandwidth – the mobile wireless environment typically has far less bandwidth available than in a wireline environment.

Wireless devices operate under a set of physical limitations imposed by their mobility and form factor, including:

Limited power – mobile devices have a very limited power reserve due to existing battery technology. This reduces the available computational resources, bandwidth, etc.
Size – many mobile devices are very small.

Mobile wireless devices are also characterized by a different set of user interface constraints than are personal computers. To enable a consistent application-programming model a very wide range of content scalability is required. In practice, a significant amount of the current WWW content is unsuitable for use on a hand-held wireless device. Reasons for this include:

Output scalability – existing content is designed for viewing on PC screens, whereas mobile devices will have a wide range of visual display sizes, formatting and other characteristics.
Input scalability – mobile devices feature a wide range of input models, such as numeric keypads and very few or no programmable soft keys.

Many wireless devices are consumer devices, used in a wide variety of environments and under a wide range of scenarios, for example:

Simple user interface – consumer devices demand that their user interfaces be extremely simple and easy to use.
Single purpose – the goal and purpose of most mobile devices is very focused, which is in contrast with the general-purpose nature of the PC. This motivates a very specific set of use cases, with very simple and focused behavior.
Hands-free, heads-up operation – many mobile devices are used in the environment where their use should not be necessarily distracting (driving a car for example).

WWW Developments
The next generation of web technologies is intended to enhance the users’ and publishers’ control over the presentation of the information (Cascading Style Sheets, CSS), the management of the information (Resource Description Format, RDF) and its distribution (Platform for Privacy Preferences, P3P). Furthermore, they are based on technologies that structure and distribute data as objects (XML and HTTP-NG), and include the following future developments:

XML and HTTP – The W3C has recently decided to initiate an activity to create a new generation of HTML. This will be based on XML and is likely to include features that make it more efficient for mobile use.
XML and SVG – The W3C is working on a specification for a Scalable Vector Graphics (SVG) format, again based on XML. The SVG will be implemented in browsers and authoring tools and should be the natural replacement for many of the current uses of raster graphics. Adoption of SVG should mean that the graphics in web documents will be smaller, faster, more interactive, and be displayable on a wider range of device resolutions from small mobile devices through to high resolution monitors and printers.
WML – Wireless Markup language (WML) is based upon XML and is intended for use in specifying content and user interface for narrowband devices, including cellular phones and pagers. WML has been designed with the limitations in mind of the wireless devices that we have already talked about.
NVML – Navigation Markup Language is a markup language, defined using XML, for describing navigation information such as locations of points and route information, which enables the use of a navigation service not only in cars but also on other transportation systems using mobile devices ranging from handheld PCs to cellular phones.
GML – Geography Markup Language is an XML encoding, being developed by the OpenGIS Consortium, for the transport and storage of geographic information, including both the spatial and non-spatial properties of geographic features. It is anticipated that GML will make a significant impact on the ability of organizations to share geographic information with one another, and to enable linked geographic datasets. GML encoding is intended to support both data storage and data transport. Implementors may decide to store geographic information in GML, or they may decide to convert from some other storage format on demand and use GML only for data transport.

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

Location-Smart Databases
The infrastructure required to deploy location based services for wireless devices has to offer a rich set of interfaces that demonstrate the characteristics of scalability, reliability, security, and availability. The end-user devices that consume these services demonstrate the characteristics of limited resources, limited bandwidth and are not permanently wired into any network.

The technical architecture required to meet these characteristics is one of a highly distributed nature, with most, if not all, of the processing happening on servers within the Internet. Furthermore, no single portal or server is capable of supporting the millions of wireless devices that are capable of making requests for a location-based service.

Any location-smart database will consist of collections of features that give context to where, including one or more ways of abstract positioning such as a civic address or legal land survey addressing. In addition they will have to provide services for transforming position coordinates from one coordinate system (geodetic or projection) or datum (horizontal or vertical), to another.

Any interfaces to these feature collections and addressing services will have to be web capable; for example, the API will use XML or Java. Messaging between services will require the use of distributed object technologies such as, SOAP and CORBA in its architecture. (The new SOAP protocol uses an XML encoding scheme to enable remote procedure calls (RPCs) through the HTTP protocol.) The OpenGIS Consortium has already published and/or tested many such interfaces, with the goal of defining a common set of interfaces that hide the complexities of the underlying data stores as well as the many and varied formats that the data repositories can have (DGN files, relational and object databases, GIF images, etc.).

In addition to standardizing on the interface to such location-smart databases, the International Standards Organization has a large working group, ISO/TC211, that is looking at a broad range of things under the heading of Geographic Information/Geomatics. As this work becomes accepted ISO standards, it should be easier to attain interoperability between location-based services. One of the more interesting standards to come out of this working group will be one describing the spatial data types for geometry and topology. Database vendors are today working towards implementing these data types within their DBMS offerings.

Conclusions
Wireless devices and networks pose many challenges for the provider of location-based services, such as less client-side resources (CPU, RAM) and less bandwidth and network stability and availability. These characteristics and the diversity of available devices means that providing location-based services over mobile networks requires an architecture that has the following characteristics:

Interoperability – terminals from different manufacturers must be able to communicate with services from different providers in the same mobile network
Scalability– mobile network operators must be able to scale services to meet customer demand
Efficiency – provides quality of service suited to the behavior and characteristics of the mobile networks and provide for maximum user loads that a given network configuration is capable of supporting
Reliability – provides a consistent and predictable platform for deploying services
Security – enables services to be extended over potentially unprotected mobile networks while still preserving the integrity of user data and protects the devices and services from security problems, such as the need to know the location.

Location-based services are predicated on the need to know where and this can take many forms:

Absolute position in the form of a latitude, longitude and elevation
Relative position in the form of distance from a landmark
Abstract position in the form of an address (civic, legal land, etc.)
Fuzzy position in the form of the device being within a pre-defined region (zipcode or city boundary)

Location-smart databases need to support the many new data types for geometry and topology and expose the APIs necessary to support a particular service using emerging or existing Web standards such as Java, or XML, and to support the distributing computing architectures offered by CORBA and EJB. Such systems also need to advertise their capabilities in such a way that the devices can negotiate such things as the format of the content being provided. Present thinking is that XML provides the means to achieve this.

References

[W3C] – World Wide Web Consortium home page, http://www.w3.org/
[WAP] – Wireless Application Programming Forum home page, http://www.wapforum.org/
[BOF] – Internet Engineering Task Force home page, http://www.ietf.org/
[OGC] – OpenGIS Consortium home page, http://www.opengis.org/