Location Based Services: Interfacing to a Mobile Positioning Center

location based services

Location Based Services for wireless devices, and particularly for WAP-enabled phones, are currently attracting the attention of the market. The possibilities and benefits of such services have received extensive media coverage in the past few months, but when the developer faces the development of software for these services, he may find out soon that there is no such extensive technical information about the basic building block to develop these services: the location information itself.
Simply stated, the real problem is how to get access to the location information describing the position of the target device, previously obtained by means of one of several physical positioning technologies (CGI+TA, E-OTD, UL-TOA, A-GPS...etc)
The logical reference model for LCS (LoCation Services), a widely accepted model, states that a LCS Client is enabled to request location information for one or more target Mobile Stations (MSs) from a LCS Server supported by a Public Land Mobile Network (PLMN). The LCS Server, in turn, makes use of a physical positioning technology to obtain the location information and deliver the information to the LCS Client.
In this article, I'll be discussing the issue of interfacing to a particular LCS Server, the Ericcson's Mobile Positioning Center, one of the few fully working positioning solutions currently available. Later, I'll be presenting the Spatial Location Protocol (SLoP), one promising effort aiming for the standardization of the process of interchanging spatial location information.
Mobile Positioning Protocol
The Mobile Positioning Protocol (MPP), currently in version 1.1, is an Internet-based protocol used by location-dependent applications to interface a Mobile Positioning Server. Through this protocol it is possible to request the position of mobile terminals.
The Mobile Positioning System (MPS) is the particular Ericsson solution for providing Location-based Services (LCS) and, as part of this system, the Mobile Positioning Center (MPC) is the gateway between the mobile network and location-dependent applications, playing the role of the LCS Server component in the forementioned LCS Reference Model. As expected, the MPC calculates the position of a mobile terminal, based on information from the network and delivers it to the application. (See Figure 1)

The MPP offers a carefully designed generic interface towards the MPC, thus making the applications independent of the underlying physical positioning technology that is used when retrieving the position of a mobile terminal. So, when new positioning technologies are developed, the location-dependent applications will immediately take advantage of them (by now, the MPC makes use of Cell Identification and Time Advance technologies for positioning).
Also, the MPP is fully based on HTTP, thus making the MPC available from any platform with TCP/IP capabilities, for example, from a Java Servlet responsible for the dynamic generation of WAP contents, and running on an Origin Server.
Positioning requests in MPP
The Mobile Positioning Protocol defines an URL that location-dependent applications can use to request the position of a mobile station. As a response to the position request, the MPC delivers an answer telling the client positioning application the estimation of the mobile terminal location.
The MPP specifications define a set of parameters for a positioning request such as the MSISDN of the mobile phone to be positioned and an Username/Password pair used to log on to the MPS.
The MPP response to a position request describes an area in which the mobile terminal has been located. As an example, a response may describe an arc –one of the best types of results in MPP in precision terms- using the coordinates (latitude, longitude) of a reference point, an inner and outer radius, and start/stop angles.
And now, one practical question: How long does it take for the system to locate a phone?. Usually, the response time varies between 2 and 8 seconds, 5 seconds being the average time. Really, the time from sending a position request until an answer is received for an application is dependent of several parameters. For example, the current traffic load in the mobile network, the status of the mobile station, traffic load on the IP-network and the load on the MPC.
Another practical question: Do I need to know the inner details of the MPP in order to develop a LBS application?. The answers is NO. The MPS SDK offers a set of Java classes which provide a high-level abstraction of the Mobile Positioning Protocol, hiding the HTTP transmision of position requests sent and responses, and dealing with all necessary data parsing.
So, by the use of this class library (mppsdk package) it is possible to develop positioning applications with little or no knowledge about the Mobile Positioning Protocol. Also, as a value added, the use of these classes protects the applications from changes in the syntax of MPP requests and responses.
One final question, this time about privacy: Does Ericsson's MPS include any mechanism for subscriber's privacy protection? Of course, privacy concerns can't be obviated. In first place, a request to retrieve a user’s location information must be authorized, and permission can be restricted to certain mobile phones, or granted only to the emergency services. Second and even more important, mobile subscribers can choose not to be located.
Testing applications
For testing purposes, Ericsson offers access to a publicly available MPS located in Sweden, along with all the forementioned required data for locating a simulated moving target station (See Figure 2, that shows the results of a positioning request to locate this swedish target station).

Of course, there's no need to test the applications using this MPS and thus having always to deal with swedish Latitudes/Longitudes. Luckily, as part of the MPP SDK, Ericsson also offers two powerful tools for testing applications developed for the MPS.
The first one is the MPP Emulator1.0, which runs on a web server and makes it possible to test applications for the MPS with position answers from an area of developer's choice. It answers position requests and return a location based on a simulated GSM network created by the developer. So, access to a real mobile network is not needed to test the applications with the MPP emulator.
Within MPP Emulator, developers can create phone routes to simulate one or more moving phones. Also, it is possible to add/remove mobile station numbers, users and cells.
The second tool, Visual Net, is a part of the Mobile Positioning System (MPS) Developer Kit. It is used to create simulated mobile networks for use with the Protocol Emulator. Using this tool, the developer can load or scan a map with an area of his/her choice, define cities and roads and then Visual Net creates the mobile network needed to test and demonstrate the positioning application.
In search of a standard : SLoP
Recently -July 15th-, several IETF (Internet Engineering Task Force) Drafts about a new protocol called SLoP (Spatial Location Protocol) were released for public review.
According to these papers, the purpose of SLoP is to have an standard way for an application to adquire the spatial location of an identifiable resource over or represented on the Internet, in a reliable, secure, and scalable manner.
In communication terms, this protocol will support UDP transport with retry timers for reliability, with TCP as an optional transport, along with RTP and/or SCTP. So, SLoP servers will be accesible from any platforms with TCP/IP capabilities
This protocol will specify an absolute location on the earth and will use WGS84 geodetic datum as default reference system. The format of this default scheme will especify the location in longitude, latitude and altitude parameters, where altitude may be an optional parameter.
Also, in the future SLoP should support other location representations than the default, including existing schemes and formats widely used in other contexts. These location representations may be absolute or descriptive.
In short, SLoP responses will ideally report the following data items (providing that the specified scheme and format have such capability):
Used location type (e.g absolute/descriptive location)
Framework (e.g. WGS84, UTM, etc)
Syntax/format (e.g. long, lat., alt. in degrees).
Geocentric Position
Accuracy
Time stamp (date, time, time zone)
Time-to-live
Others (Direction, Velocity, Orientation...etc)
With respect to privacy protection, SLoP will provide a mandatory-to-implement, optional-to-use authentication mechanism from client to server and from server to client. Of course, the specifications will specify how such a mechanism shall be used in the presence of firewalls and Network Address Translation (NAT) between client and server.
After reading the public IETF Drafts, I must say the work in progress is quite promising. There is still a long way before the release of the first usable implementations of SLoP, but this is definitely a work in the right direction.
About The Author
Sergio Ríos is working as a faculty professor at the Pontificia University of Salamanca in Madrid, Computer Science Engineering, where he teaches courses on Java and Advanced Internet Programming. He regularly writes columns and articles for several Java/Internet publications, has authored two books on Java and HTML, and also is a speaker at national & international conferences. He is now working extensively with WAP technology and Location Based Services.
Glossary
LCS Client: a software and/or hardware entity that interacts with a LCS Server for the purpose of obtaining location information for one or more Mobile Stations. LCS Clients subscribe to LCS in order to obtain location information. The LCS Client is responsible for formatting and presenting data and managing the user interface
LCS Server: a software and/or hardware entity offering LCS capabilities. The LCS Server accepts requests, services requests, and sends back responses to the received requests. The LCS server consists of LCS components which are distributed to one or more PLMN and/or service provider.
Target MS: The MS being positioned.
WAP Origin Server The origin server provides the location dependent service to its clients.
Sponsors
HREF="http://adserv.wirelessdevnet.com/oasis/oasisc.php?s=5&w=160&h=600&cb=1269547182&t=_blank" target="_blank">
Search
Eliminate irrelevant hits with our industry-specific search engine! WirelessDevNet
Wireless Industry-->