Location-Based Services & Their Revolutionary Revenue Model For IP-based Service Providers

Dr. Hossein Eslambolchi
March 2012

Location-based services (LBS) are services contingent upon the location of a user or a user’s device and the location of others the user may wish to interact with. These services can include self-explanatory location-tracking services and position-aware services which are customized based on the device’s location.

Location-based services differ from presence services, which make use of the ability of the network to determine information about a user’s status, such as whether the user is online or talking on the cell phone, for example.

Both presence and location-based mobility services offer a great deal of promise, especially to mobile service providers looking for new market growth opportunities.

LBS enables a new class of instant messaging services, tagging messages with geographical location. Thus LBS capabilities allow for new pet- and courier-tracking services, remote monitoring and security services, and new possibilities for mobile commerce.



• Few location-based services are currently offered for the United States because location-determining technology is not yet fully in place. Additionally, the needed wireless service is not yet widely available and there are few useful location-based applications.

• Japan has the most location-based services available, followed by Scandinavian countries and Switzerland.

• Services over IP (SoIP) introduce new challenges and opportunities for location-based services that should be understood by global service providers.



LBS integrate the location of a user equipped with a mobile data device with other data sources to perform a useful task. These services depend on the following elements:

• A wireless data network, preferably supporting speeds of 56 Kbps or greater.

• A mobile data device with a network connection, preferably including an Internet connection.

• Position Determining Equipment (PDE), which determines the location of the mobile user, preferably within 100 meters. PDE requires either a network-based system with equipment located at switches, or a mobile device-based approach with an integrated GPS system.

• A mobile positioning center (MPC), which manages the location information supplied by the PDE and enforces privacy requirements.

• An Internet gateway – the server that processes requests from the mobile device and sends the request to the application.

• Middleware software, which allows positioning information to interface with applications.

• Applications which derive customize and personalize content based on the users location and preferences.

• Geographic and location-based databases, including roadmap, landmark, yellow-pages and boundary information for the application to access.

• A billing platform which creates invoices for services using location information in addition to processing traditional billing input.

While location-determining technology is not yet fully in place in the United States, a suitable infrastructure will be available once mobile service providers deploy the needed technology to provide E911 caller information as mandated by the FCC. To date, implementation of the FCC Phase II order has been spotty.

Companies that harness CDMA are adding satellite-based GPS or eGPS technology that requires mobile service customers to upgrade their handsets. Companies that deploy GSM are working on time difference of arrival (TDOA) triangulation from base stations. Some GSM/TDMA carriers have adopted network-based solutions using cell identification.

All major cell phone companies have deployed E911-Wireless Phase II technologies. T-Mobile originally chose the GPS option but later decided to use the network option. Some of the Public Safety Answering Points (PSAPs) are equipped with electronic maps that automatically display the location of a call using the information provided by cell phone companies.

Another reason that location-based services have not achieved wide success is that no compelling applications are available. In turn, compelling applications remain undeveloped because there is no standard platform off of which to build. Several attempts to develop such a platform have achieved modest success.

BREW (Binary Runtime Environment for Wireless) from Qualcomm, available for several years, is one such attempt, but it is hampered because native BREW applications must be built using C and C++. On the positive side, it has a library supporting location-based services. Another attempt at a standard platform is J2ME (Java 2 Micro Edition). However, J2ME suffers from complexity, a lack of support for basic data types, and a lack of support for industry standards such as XML Web Services.

The jury is still out on whether either of these platforms will achieve widespread success. Some service providers now support BREW or J2ME (Java) mobile platforms and offer a limited set of handsets that utilize them.

A successful platform structure should draw ideas from Open Service Architecture (OSA), providing application developers a simple and unified interface to query the location of a subscriber’s cell phone. In this way, application developers do not have to worry about the specific technology used by the carrier to determine position.

Although users have indicated an interest in location-based applications, service providers, device vendors and mobile application developer plans have not been in sync. In some cases phone features precede service availability. In other cases service providers offer the capabilities but haven’t cultivated the community to develop applications. For example: An increasing number of service providers, particularly in Europe and Japan, are offering location-based, as well as presence-based, services, but most handsets don’t support the services, which naturally limits the rate of adoption.

Surveys of consumers in the United States show a high interest in emergency services, navigation and traffic information. Navigation and direction services consistently rate “high” on surveys of potential LBS applications.

There is more moderate interest in information services, such as tour guides, shopping directories and schedules for nearby trains. There is a similar level of interest for services to track family and friends, particularly children, although consumers have expressed privacy concerns about these applications.

There is much less interest in location-based entertainment, alerts from nearby retailers and mobile dating services.

A wide variety of location-based services will be possible once the appropriate elements are in place. These services could include:

• Enhanced E911

• Billing

• Traffic conditions and direction services

• Directory services

• Messaging

• Vehicle tracking

• Personal security

• Car insurance

• Dating services

• Tourist services

• Promotions from nearby stores

• Schedule information (transportation, entertainment, etc.)

• Games

Service providers are under pressure to create new revenue streams. The traditionally high-growth mobile markets in areas such as Japan, the Nordic nations and North America will mature, and service providers will face increased competition from Wi-Fi players. Eventually, acquiring new customers will not be enough. LBS will become an attractive way to provide alternative revenue streams.


Service providers in Japan and Europe have introduced location-based services:

NTT Do Como introduced a suite of automated location-based services called i-mode in Japan in July 2001. i-mode’s location data is derived from sectored cell-sites, which have an accuracy of approximately 100-200 meters within the location of the wireless device.

Telia Mobile, a Scandinavian mobile carrier, builds location-based services using the Ericsson Mobile Positioning System, which is based on the GSM positioning system. It uses enhanced cell-site information.

NTT, Telenor, NetCom, Vodafone, and O2 all make their location data available to third parties for location-based services.


Verizon Wireless launched a location-based fleet tracking and administration service in May 2005.

Sprint Communications and its handset partner, Motorola, offer several location-based services using handsets with built-in GPS.

• There are an additional number of competitors, including Open Wave and Telecommunications Systems that specialize in selling middleware to enable data flow management. Other specialists offer mapping and routing middleware that developers can use to build location-based services for the end-user.

• The Open Mobile Alliance (OMA), which in 2002 incorporated the Location Interoperability Forum founded by Motorola, Ericsson, and Nokia, promotes interoperability, including mobile location services. It has more than 200 members.

Open Service Architecture (OSA)/Parlay are currently deployed in many carriers’ networks. OSA/Parlay is an API that enables the rapid creation of telecommunication services, including LBS, by leveraging IT application developers to create telecom services. These technologies independent APIs are defined by the Parlay group, a nonprofit consortium of over 65 companies. OSA/Parlay is probably the best telecom EAI solution today. It provides greater flexibility for emerging SIP/IMS environments, especially in programmability and 3rd party application provider model.


Mobile services operators will provide location information, and it is likely that wireless vendors will charge a fee per location lookup. Wireless service operators should join international forums to help increase interoperability between wireless vendors, third party content providers and global service providers.

The LBS field can be categorized into blue-collar and white-collar applications. Blue-collar applications track and navigate fleet workers; white-collar applications offer directory searches and find-me-follow-me applications. Other applications can be delivered to the mobile user depending on the complexity of the solution deployed.

Wireless LANs are becoming increasingly popular in indoor environments. Global service providers can leverage their managed WLAN services to include location-based services for such clients. This will mean configuring their 802.11 networks to respond to SNMP queries for client locations. The accuracy of the location information will vary, but the types of services that can be delivered will be essential to the business user’s needs.

Providers can use RF identification tags (RFID) to localize a particular user inside a building or for a session initiation protocol (SIP)-based client in a VoIP endpoint. In the latter example, the SIP server contacts a SIP location server to determine where best to route a call that may not have the means to find the called party.

There is a fine line between location and presence, and sometimes presence that may be the more attractive basis for services.

Global service providers have launched a nationwide consumer VoIP offer. This move from circuit-switched to packet-switched voice services has implications for 911 emergency calls. There are two important opportunities and challenges that need to be addressed for providing emergency call services over IP:

1. Selection of emergency service: The distressed VoIP caller needs to reach the correct Public Safety Answering Point (PSAP) – the point that can dispatch emergency help for the caller’s current location.

2. Locating the user: The location coordinates of the caller must be conveyed to the PSAP via the VoIP infrastructure through an IP-to-PSTN gateway.

To solve the first issue, the PSTN gateway needs to access a mapping database that can send geographic or civil coordinates to a PSAP; the database should contain a ten-digit number that can reach an emergency call-taker. The second issue is likely to be handled by protocol-level modifications that are currently being made (e.g., in Dynamic Host Control Protocol) which will convey the approximate user location to the end system. With this addition, the service can easily determine the longitude and latitude of the caller, as well as the street address, avoiding the need to configure devices manually.

The VoIP terminal can then provide user location either in-band or out-of-band. The signaling request in in-band systems contains the location information, either inserted by the end system or by a signaling proxy along the way. In the out-of-band mode, the end system provides an identifier which is then mapped at a PSAP to location coordinates and passed along.

The FCC has already issued final rulings [FCC 05-116] requiring certain VoIP service providers to provide enhanced 911 calling for their customers. These rulings follow a number of well-publicized incidents in which VoIP 911 calls did not reach emergency responders in time because they did not reveal a caller location, or were rerouted through secondary or administrative lines at PSAPs.

The FCC mandated service providers to require VoIP providers to deliver Automatic Number Identification/Automatic Location Identification (ANI/ALI) to customers, and to provide them with information about the capabilities and limitations of VoIP/E911 service. Properly configured VoIP requires E911 calls in case of emergency.

Calls arrive as a normal E911 call, and that ANI/ALI would be displayed to the call-taker. However, the RBOCs’ decision to allow access to their E911 systems does not change or improve the ANI/ALI situation. VoIP subscribers must still properly register their physical location with the carrier in order to transmit the correct ANI/ALI information to the PSAP.

Regardless of the means of access, 911 services are critical and the caller has to be directed to the nearest PSAP. Whether this is done via GPS, triangulation or cell-ID based mechanisms will depend on individual technology and deployment scenarios.