A Brief History
Throughout the formative years of LBS (circa 1997-2001), the carrier/operator
approach to LBS was to implement a core node within the SS7 network that
was capable of extracting the location of mobile devices from the network.
These now-standardized elements in a wireless network are known as mobile
positioning centers (MPCs) in IS-41 networks and gateway mobile location
centers (GMLCs) in GSM networks. Early providers of these network
location components were Ericsson, Nokia, SignalSoft (now Openwave), and
Telecommunications Systems (TCS). Others to follow in their footsteps
were typical wireless infrastructure vendors such as Alcatel, Hughes, Intrado,
Lucent, Motorola, Nortel, Siemens, and SchlumbergerSema.
With the Phase I architecture model, most carriers/operators took an approach in which they simply opened up prestandards interface access to their network MPC/GMLC to all spatially enabled applications residing outside the network firewall in the IP domain (Figure 1).
Figure 1: Phase I Approach for Carrier/Operator LBS Architectures
In this archaic model, carriers/operators assumed that it would be
the responsibility of application developers to acquire their own GIS for
the spatial aspect of a given LBS application. During this period
there was no standard interface to the MPC/GMLC (e.g., SignalSoft's XWLI
and Ericsson's MPP), nor was there a standardized specification for commercial
Internet GIS mapping servers. Most GIS mapping servers had their
own open XML but used proprietary schemas.
During the years of the Phase I model, most conventional GIS vendors, including ESRI, were limited to marketing and selling Internet mapping technology to application developers, who in turn built applications atop a GIS that they then attempted to sell to carriers/operators for their commercial offerings. This decentralized architecture model worked well for most GIS companies and produced humble results and revenues, but it proved to be an unforgettable fiasco for carriers/operators who wanted to implement many LBS applications smoothly and quickly. There was a plethora of problems encountered with the Phase I approach; integration and interoperability with existing systems dominated the many outstanding issues. Each time a carrier/operator elected to offer a new application to subscribers on behalf of the application developer, the carrier/operator was forced to enact rigorous, expensive, and custom implementation and integration efforts for that LBS application. Each application typically used different GIS and other third party software with its own prestandard APIs. Therefore, each new application did not easily integrate with existing carrier/operator systems. There were also billing issues that had not been resolved. I recall one carrier telling me, "It's difficult to introduce new applications when there aren't mechanisms in place for us to account for activity and bill or reimburse accordingly." All in all, the Phase I model simply did not work beyond nonbillable, closed applications (such as e911) that served autonomous singular functions, and the industry was forced to define a new model in order to expand carrier/operator-driven LBS offerings.
In the latter half of 2000 and early 2001, the LBS industry experienced a reactionary shift in how carriers/operators chose to implement their systems. This change was predominantly driven by past failures, successes, and trial and error rather than by proactive innovation and creativity, though some might argue otherwise. Several carriers/operators around the world who had experienced the integration pains of introducing one-off applications into their networks recognized the need for a centralized system. They wanted a system over which they could have complete control, and they especially wanted to govern how applications interfaced with their network. Most important, they wanted to speed up the process of introducing new LBS applications that they could offer to their subscriber base.
The solution to the problem was an architecture founded on the principles of centralized Web services and one-stop shopping environments for developers. In a Web services model, application developers build location-based applications by using a suite of enabling technologies and APIs. They then publish these applications back to the carrier/operator, and the carrier/operator then makes the applications available for subscriber use. This shift in the architecture approach forced the industry to acknowledge a void and develop new network elements to fill it, which fundamentally changed the way the majority of the industry suppliers looked at LBS systems. Due to the integration problems encountered with the Phase I approach, carriers/operators chose to implement two additional components within the core LBS architecture model. These two enabling technology elements are the location-enabling middleware and the geoserver (Figure 2).
Figure 2: Phase II Approach for Carrier/Operator LBS Architectures
There are several commercial offerings for location-enabling middleware. I will not attempt to speak as an expert about the functionality, but rather describe the generic capabilities of the technology and how it relates to the core competencies of GIS companies. Location-enabling middleware handles many operationally critical carrier/operator requirements, and the technology is now considered the crux of a carrier/operator LBS system. The software interfaces to the MPC/GMLC and all other carrier/operator systems (e.g., WAP-GW, SMSC/MMSC, OAM&P, and billing systems). This centralized interfacing minimizes integration efforts each time a carrier/operator launches a new LBS application. Perhaps more important, location-enabling middleware also handles privacy, presence, and personalization, which are absolute must-haves for LBS, especially in the vertical mass market. Finally, the location-enabling middleware element interfaces to a GIS engine, now commonly referred to as a geoserver. In some cases, the GIS engine is considered a transparent layered function of the location-enabling middleware.
Within this middleware/geoserver-centric model, application providers residing outside the operator firewall in the IP domain consume APIs and embed functionality from both the location-enabling middleware and the geoserver in their applications. Developed applications are then published back to the carrier for deployment and advertisement in the mainstream. The process works the same way for enterprise and/or government applications. The Phase II model ensures that the carrier/operator has complete control over how any application developer interfaces to the core network, and it dramatically reduces implementation costs.
With the Phase I LBS architecture, the industry was plagued with an abundance of nonstandardized proprietary interfaces to closed systems that were neither extensible nor portable. In the new Phase II model, however, standards are very important. There are two standards proposals that promise to expedite integration and stimulate application development, which will hopefully attract developers focused on mass market, business, and government applications. These proposed standards are the Location Interoperability Forum-Mobile Location Protocol (LIF-MLP) API for location and the Open GIS Consortium (OGC) OpenLS API for spatial processing. The LIF-MLP and OpenLS APIs have solved a majority of the integration challenges that slowed down the LBS market in its formative years.
LIF-MLP, OpenLS, and the Phase II LBS Architecture Model
The LIF-MLP API describes the request/response that gathers x,y coordinates
from the MPC/GMLC. In the new architecture model, the location-enabling
middleware effectively acts as an LIF-MLP pass-through and subsequently
passes on requests from the LBS application to the MPC/GMLC for location
gathering. The OGC's OpenLS APIs are XML schemas that describe a
finite, invariant set of spatial processing function interfaces for geocoding,
reverse geocoding, spatial querying, mapping, and routing. The OpenLS
objective is to provide a standardized solution for carriers/operators
that allows them to choose and implement standard interfaces and components
into their LBS systems, ensuring that application developers have standard
tools and/or services to use when building LBS applications.
The OpenLS specification was designed and written under the direction
of OGC by an interdisciplinary group of vendors. The lead sponsors
and editors of the specification include ESRI, In-Q-Tel, Intergraph, Oracle,
Sun, and Webraska, with dozens of other participants from all segments
of the LBS industry. The design of OpenLS is obviously more concerned
with the geoserver component of LBS systems, but the OpenLS API can also
be used to tightly integrate the geoserver with other systems such as the
location-enabling middleware (e.g., those provided by Mobilaris, Openwave,
TCS, and Telenity) and the application server (e.g., those provided by
IBM, Oracle, and Sun). In addition, most location-enabling middleware
vendors and application server vendors who did not participate in OpenLS
nonetheless have plans to integrate the OpenLS API into their products.
Again, the goal of OGC is to facilitate seamless and smooth integration
with other OpenLS-compliant GIS engines for the Phase II centralized architecture
model; thus the more vendors join the cause, the better off the industry
will be as a whole.
The Future and Promise of OpenLS
Applications built within the new Phase II LBS architecture model use APIs from the location-enabling middleware and the geoserver to embed privacy, personalization, and GIS functionality into LBS applications. The future of the Phase II architecture model promises to provide a one-stop-shop Web services API development environment for application providers. It will not matter if the application provider focuses on B2C or B2B applications. All application developers, whether they are businesses, governments, or those focused on the mass market, will use enabling technologies through the carrier/operator in the Phase II model. This is a beautiful model that, again, ensures that carriers/operators have complete control over what applications they introduce and how those applications are integrated with their systems. The idea that carriers/operators will provide application developers with a place to lease location and get privacy APIs and GIS APIs is a spatial application developer's dream come true. The fact that APIs are standard, or soon will be, is even more fantastic. OGC has had a lot to do with realizing the dream, and the OpenLS specification will help bring the industry one step closer to the "killer environment" application developers have hoped for. With technical issues solved, the only remaining challenges the industry should concentrate on are how to help carriers/operators with their business models and how to teach them to attract all those mobile users who use geographic information on a daily basis. This is something veterans of the GIS industry know all too well.
Reprinted with Permission.Copyright 2003 ESRI.All rights reserved.