The Power Of Location Is Changing How Business Is Done! Learn More Here!

Location Based Services

Subscribe to Location Based Services: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Location Based Services: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

LBS Authors: Liz McMillan, RealWire News Distribution, Kevin Benedict, Shelly Palmer

Related Topics: Java Developer Magazine, Location Based Services

Java Developer : Article

The Location API

The Location API

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.

    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.


  • More Stories By Sven Haiges

    Sven Haiges ( is currently completing degrees in computer science and business administration at the University of Furtwangen, Germany, and the Management of Technolog,y MBA, at Simon Fraser University in Vancouver, Canada. As a specialist in the Java programming language, he combines knowledge of both server-side and client-side Java, especially for mobile Java clients. Sven recently published his first book about the Struts open source Web Application Framework in Germany.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.