Home : Support : Documentation : Jack's Hacks : Archive : July 2004
 

July 2004

 

The Open Mobile Alliance (OMA) Mobile Location Protocol (MLP) interface is an XML interface that enables communication between location-based services and location infrastructure (such as LSt). The interface was developed by the Location Interoperability Forum—an international consortium that promotes open standards and interoperability for mobile location services. Since OMA (at the time under the responsibility of LIF- Location Interoperability Forum) first created MLP, it has released updated versions. Location Studio 2.1 supports versions 1.2 and 3.0.0, of which the 3.0.0 version is the most stable and recommended version.

Openwave was the first non-founding member to join the Location Interoperability Forum. Recently, the Open Mobile Alliance (OMA) standards body absorbed the Location Interoperability Forum. Openwave's Location Studio was one of the first location platforms to support MLP for location requests. Supporting MLP is important for Openwave developers as it ensures the widest possible compatibility in the industry.

Location Studio supports two of the top-level elements in the hdr element, namely client and requestor. The client contains a number of subfields, of which all are supported in LSt, but only idand pwd are required. The following illustrates a header where all elements supported in LSt are used.

      <hdr ver='3.0.0'>
      <client> 
      <id>testlst</id> 
      <pwd>password</pwd> 
      <serviceid>FF_123123</serviceid> 
      <requestmode type="PASSIVE"> 
      </client> 
      <requestor> 
      <id>John</id> 
      </requestor> 
      </hdr>

The optional element serviceid can be used to reference the request. This ID will be logged in LSt and can be used for billing or troubleshooting purposes, for example.

The optional requestmode element, with its attribute type, indicates whether the request is passive or active.

The requestor element, with its sub-element id, is used in notification messages. For example, if Lst is set to send a notification message, then the id information is sent out as part of the notification message. For example, "Your buddy John in FriendFinder is locating you." If the requestor element is not present an alternative message will be used.

The MLP interface supports the use of either North American Mobile Identification Number (MIN) or GSM Mobile Subscriber ISDN (MSISDN) as the Mobile Subscriber Identifier (MSID). A subscriber's MIN or MSISDN is simply his or her mobile telephone number. By default the expected MSID is an MSISDN. In order to specify the MSID as a MIN, MIN must be listed as the MSID type using the msid_type element as shown in the following example with two mobile numbers:

	<msids>
	 <msid msid_type="MIN">123456788</msid>
	 <msid msid_type="MIN">123456789</msid>
	</msids>

In some operator networks it is also common practice to support subscriber anonymity through the use of an opaque subscriber identifier.

The different LSt IDs are mapped into different ID types in MLP 3.0.0, as described in Table 6.

• Table 6 ID type mapping

Location Studio ID type	MLP ID type
MSID	MIN or MSISDN
TSID	SESSID
PSID	ASID
OSID	OPE_ID

The syntax to use, for example, the OSID as the mobile station identifier in LSt MLP 3.0.0, is as follows:

	<msids> 
	 <msid type="OPE_ID">123acfd52a</msid> 
	</msids> 
	  

The Location Response

This section describes the location response sent from the system back to the client application using MLP 3.0.0 in response to a location request.

Location Accuracy

The following elements of the response illustrate the returned location information and the radius of uncertainty (<radius> tag), which is 1000 meters in this case. The radius is always defined in meters.

There are many shapes defined in MLP, but Location Studio 2.1 always uses the CircularArea element.

      <shape> 
      	<CircularArea> 
      		<coord> 
        		<X>45 07 24.123N</X> 
      			<Y>100 06 22.111E</Y> 
      			<Z>5280</Z> 
      		</coord> 
      	<radius>1000</radius> 
      	</CircularArea> 
      </shape> 

Browser Test Harness

By default, the page contains a form with the following empty XML request document:

      <?xml version = "1.0" ?> 
      <!DOCTYPE svc_init SYSTEM "MLP_SVC_INIT_300.DTD" 
      [ 
      <!ENTITY % extension SYSTEM 
      "OPWV_MLP_extension_request.dtd"> 
      %extension; 
      ]> 
      <svc_init ver="3.0.0"> 
      <hdr ver="3.0.0"> 
      <client> 
      <id>theasp</id> 
      <pwd>thepwd</pwd> 
      </client> 
      </hdr> 
      <slir ver="3.0.0"> 
      <msids> 
      <msid type="MIN">3033813000</msid> 
      
      </msids> 
      <loc_type type="LAST" /> 
      <opwv_extension_request>Zone</opwv_extension_request> 
      </slir> 
      </svc_init>

Cut and paste from the Examples section of The Location Studio MLP 3.0.0 Developer's Guide document to insert XML requests covering a variety of common request scenarios.

• NOTE
  In order to get a proper response it is necessary to specify the loc_type in test server requests because the test server configuration does not support the default type of "Current". However, all live network implementations will support "Current" requests.

HTTP Post URL

The browser test harness described previously simply takes the XML and posts it to the actual MLP3.0.0 request interface of LSt. After you have verified your XML request is valid and you know what response to expect, you can test your application by posting to the following url:
url.base=http://loc2.Openwave.com:8080/locationstudio/mlp300

Jack's Archives