| By Sven Haiges |
Article Rating: |
|
| October 1, 2003 12:00 AM EDT |
Reads: |
30,861 |
The Location API (JSR 179) was accepted by the Executive
Committee for Micro Edition of the Java Community Process in June
2003. It provides an abstract interface for access to location-based
information, such as the current coordinates of the mobile terminal
independent from the underlying positioning method used.
Mobile Positioning 101
Mobile positioning in general is the process of determining
the location of a mobile terminal; the result of this process is the
mobile location, which is the current location in terms of
coordinates of the mobile terminal. The mobile location can be more
or less accurate, depending on the mobile positioning method used.
The large number of existing methods that can be used for
mobile positioning can be divided into two broad categories:
network-based and handset-based. The first category, network-based
positioning, is made up of many methods that reach from relatively
simple COO (cell of origin) methods to more complex methods like TDOA
(Time Difference of Arrival). The latter category, the handset-based
positioning methods, allows locating the terminal without the help of
the mobile communication network (for example, the GSM or CDMA
network). GPS - the Global Positioning System - is the most prominent
member of that category.
Besides those two categories, there are also hybrid methods
that unite network-based and handset-based methods. AGPS (Assisted
GPS) is one, where you try to speed up the initialization time of the
GPS receiver by using information coming from the mobile network.
The following sections explain the most common positioning
methods in more detail. Figure 1 provides an overview of the
described methods.
Handset-Based Methods
Global Positioning System (GPS): This system was developed by the U.S. Department of Defense and is still maintained by them.
Originally developed only for the military, today this positioning
system is widely used by civilians. The system is based on signals
that are transmitted from 24 satellites that GPS receivers on earth
use to calculate the current location. Each GPS receiver needs to be
in contact with four satellites at the same time to be able to
determine the user's longitude, latitude, and altitude. Among the
advantages are the relatively exact positioning result (close to
10-30 meters) as well as the possibility of determining the altitude
at which the terminal is located. A serious disadvantage is the lack
of reception of GPS signals within buildings, which can make the
positioning process impossible.
Enhanced Observed Time Difference (E-OTD): This method is
often referred to as the opposite of the TOA (Time of Arrival)
method. Instead of measuring the time differences of signals that are
transmitted from the terminal to the base station, the terminal
calculates the location. Therefore, special software has to be
installed in the mobile terminal. In addition, so-called "Location
Measurement Units" have to be installed at each base station. The
accuracy of E-OTD is relatively high, although the best results that
are close to GPS can only be expected in urban areas, where many GSM
cells are available.
Subscriber Identity Module Toolkit (SIM): Another
handset-based positioning method is via the SIM Toolkit. The STK is
an API that allows communication with the SIM smart card, which many
mobile phones have from applications that were installed on the
handset. The quality can be as bad as the COO method, but can also be
improved by some algorithms that are stored on the SIM and by some
extra features that are provided by the network.
Network-Based Methods
Cell of Origin (COO): COO is the easiest and most common
method, but also the most inaccurate one. The network determines only
the cell from which the user is placing a call or initiating a data
transfer and can determine the location based on the known locations
for the base stations of the network. Interestingly, this method is
already sufficient for most location-based services, and additional
calculations like Timing Advance (TA) can further enhance the quality
of positioning.
Angle of Arrival (AOA): This method uses special equipment
that has to be installed at the base stations to determine the angle
of arrival for the radio signals. With some basic geometric
calculations, you can then determine the location of the user with
only two base stations receiving its signal.
Time Difference of Arrival (TDOA): This method uses the
differences of arrival for the radio signals at the base stations
(from the mobile terminal). A minimum of three receiving base
stations is required to calculate the location of the user.
Location Pattern Matching (LPM): This complex method analyzes the radio signals and compares them to patterns saved in a database.
These patterns include signal reflections and echoes. When a pattern
is recognized, the location of the user can be identified. This
method can be used only in urban areas, where these signals often
occur. In these areas the quality might be better than using other
methods; unfortunately this method is not suitable as a general
method for rural areas.
Hybrid Methods
Assisted GPS (AGPS): AGPS uses information from the network to more quickly determine the position of the four satellites that it
needs to listen to. The network cell distributes the locations of
those satellites and can drastically reduce the initialization time
that a normal GPS receiver needs. In addition, this method saves
battery power as the GPS receiver is only activated on a usage basis.
Other methods of mobile positioning include short-range
beacon methods such as Bluetooth or IrDA. Those methods can be used
to locate users indoors and the quality of service is good. On the
other hand, the setup of those networks is a highly complex task as a
new infrastructure is needed and mobile terminals have to be updated
as well.
The Location API
Access to the current location of the terminal is of special
value for mobile phones and embedded systems. The Location API allows
us to access this kind of information through a standard interface.
The underlying mobile positioning method does not change the usage of
the API but, of course, the quality and amount of information that
can be gathered can vary tremendously.
This JSR is led by Kimmo Löytänä (of Nokia Corporation) and
has been accepted in unison by the Executive Committee for Micro
Edition, showing strong industry-wide support for this API, in June
2003. The Location API (package javax.microedition.location) needs
the CLDC 1.1 as an underlying configuration, as support for floating
point numbers is necessary for values such as the longitude and
latitude. Furthermore, the utilization of the security concept of
MIDP 2.0 is recommended in the JSR. If an application wants to make
use of the Location API, the user will be prompted for the
permissions. He or she can decide to give those permissions to use
the Location API on a per-usage basis for the duration of the current
session or in general. This inhibits the abuse of this API, as every
location request might involve costs to the user.
Figure 2 provides an overview of the main classes involved in
the Location API.
The LocationProvider is a Singleton class that is the
starting point for a request to the location service. The method
getInstance(Criteria c) receives a criteria object as a parameter to
determine the needs of the location request (for example, desired
accuracy, whether to include address information, etc.).
Criteria can generally be divided into hard and soft
criteria. Hard criteria are:
Maximum cost per request
Should the speed be determined?
Do we need address information or are the coordinates sufficient?
Soft criteria are:
The horizontal/vertical accuracy of the positioning process
The degree of power consumption tolerated
The maximum response time
In addition to blocking a request by using the method
getLocation() of the class LocationProvider, there's also a
nonblocking LocationListener that can be registered at the
LocationProvider. The LocationListener will then receive the current
location information at regular intervals.
Orientation data can also be gathered directly from the
LocationProvider class and includes the pitch and roll as well as the
compass orientation of the terminal.
The response from the LocationProvider is an object of the
class Location, which encapsulates the location information. It
includes a Coordinates and AddressInfo object. Coordinates provide
information, such as the longitude/latitude values of the location.
AddressInfo provides additional information like the name of the
street, city, etc., if this information has been specified by the
criteria and is available.
Landmarks (not illustrated) allow you to classify locations
and save them to a landmark database on the mobile handset. The
classifications could, for example, include movie theaters, ATMs, or
museums. In addition, personal landmarks such as the home location
can be saved to this database. The database uses the RMS (Record
Management System) that is part of the underlying profile, the MIDP.
That's the theory. Please keep in mind that the actual
location information might not include the street name or the
orientation of the mobile terminal. The accuracy will vary as well
depending on the method used. Although technically feasible with
certain handsets (for example, AGPS-enabled devices from Motorola),
the quality of information will not always be that good. This API has
been designed with the future in mind. As the positioning methods
evolve, the accuracy and the amount of information supplied by this
API will improve and increase.
The example in Listing 1 is taken from the specification and
demonstrates the usage of the API.
Here comes the million-dollar question: When will this API be
available in mass-market Java phones? Good question, I don't think
we'll see the API in a consumer device by the end of this year. The
Roadmap 1 (JSR 185 - Java Technology for the Wireless Industry) does
not include the API in its recommendation, but the Location API seems
to be a hot candidate for the next version of this roadmap. If it
will be added to the roadmap, it will most likely be an optional API
like the current Multimedia API.
Location-Based Services (LBS)
The Location API will allow the implementation of various
location-based services, which can generally be split up into these
categories:
Public security: For determining the user's location in case of an emergency, etc.
Tracking: For tracking fleet vehicles, people, etc.
Traffic monitoring: For the fast recognition of jammed
highway zones, etc.
Location-based information: Navigation services,
city-sightseeing services of mobile yellow pages
A location-based service from Jentro AG, Munich, Germany,
will serve as an example. Jentro AG's navigation solution (see Figure
3) was introduced during one of the general sessions at the recent
JavaOne conference in San Francisco. Besides a Java-capable mobile
phone, the entry version needs only a GPS adapter to turn the mobile
phone into a navigation solution. The MIDlet communicates using the
serial port with the GPS adapter and sends this information via the
MIDP's Generic Connection Framework (GCF) to the server. The server
then calculates the routing information between the start and end
point and transmits this information to the mobile client. Although
Jentro currently does not use the Location API (nor the Multimedia
API), as those APIs become available in mainstream phones Jentro will
consider the switch toward those APIs as it speeds up the development
of new services.
Conclusion
The Location API simplifies access to the results of mobile
positioning methods and allows mobile Java applications to use the
location information via standard APIs.
Applications that use this API are more likely to occur in a
professional environment first, for example, for fleet management. A
developer can target a specific device and a specific network that
supports the level of accuracy that the application needs.
As for the mass market, the differences in mobile positioning
quality that is likely to occur because of the different underlying
mobile positioning methods used will make it more difficult to design
applications that use mobile positioning information.
The JTWI 2.0 will hopefully include the Location API as an
optional API and provide a clear roadmap for this API. As a developer
you don't have to wait until the Location API is available to use
mobile location information. This information can be accessed using a
GPS adapter (via serial interface) and proprietary APIs. As soon as
the Location API is available, switch to using the Location API, as
it will speed up new location-based services development and does not
lock you into proprietary APIs or solutions.
References
www.mobilein.com/mobile_positioning.htm
www.cursor-system.com/products_classic.asp
www.911dispatch.com/911_file/aoa.html
www.911dispatch.com/911_file/tdoa.html
www.911dispatch.com/911_file/lpm.html
http://jcp.org/aboutJava/communityprocess/first/jsr179/index.html
www.umtsworld.com/technology/lcs.htm
Subscribe to JAVA Developer's Journal Email News Alerts
Subscribe via RSS
