Introduction

Faced with an increasingly difficult challenge in growing both average revenue per user (ARPU) and numbers of subscribers, wireless carriers and their partners are developing a host of new products, services, and business models based on data services. Location services, which provide information specific to a location, are a key part of this portfolio.

Location-based services offer many opportunities. For the mobile user, some examples of location-based services are:

• Requesting the nearest business or service, such as an ATM or restaurant
• Receiving alerts, such as notification of a sale on gas or warning of a traffic jam
• Finding a buddy

A big advantage is that mobile users don't have to manually specify ZIP codes or other location identifiers to use location-based services.

For the carrier, location-based services provide value add by enabling services such as:

Resource tracking with dynamic distribution

Taxis, service people, rental equipment, doctors, fleet scheduling

Resource tracking

Objects without privacy controls, using passive sensors or RF tags, such as packages and train boxcars

Finding someone or something

Person by skill (doctor), business directory, navigation, weather, traffic, room schedules, stolen phone, emergency 911

Proximity-based notification (push or pull)

Targeted advertising, buddy list, common profile matching (dating), automatic airport check-in

Proximity-based actuation (push or pull)

Payment based upon proximity (EZ pass, toll watch)

Back to top

How location-based requests work

The alarm goes off at 5:30 a.m., an hour earlier than normal. Bob's calendar shows he has an 8:00 a.m. meeting today in Boulder, CO, which is an hour further than his usual commute. He gets ready for his day and is out the door at 6:30. In the car Bob enters his destination into his auto assistant, and checks the traffic pattern. All is well. At 7, he is alerted there has been a wreck on I-70, ten miles ahead. The auto assistant informs him of a better way to travel to avoid the accident. At 7:35 a.m. Bob is in Boulder. He gets a page from his boss that his meeting has been postponed to 9 a.m. Bob accesses his wireless access protocol (WAP) phone and uses his buddy finder to see if his colleague Sue has arrived in Boulder yet. He sees that Sue is within 5 miles, and instant messages her to ask if she wants to grab a bite to eat while they wait. Sue agrees. Bob again uses his WAP phone to search for the restaurants closest to his current location. He decides on Boulder Cafe, and informs Sue of their meeting place.

In the scenario above, Bob used some aspects of location-based services. He received a traffic alert, found the location of a colleague, and searched for the three closest restaurants. What happens when these requests are made? This article focuses on the simplest request, the closest restaurants, and follows a request flow.

Bob accesses the services page of his WAP phone provider, as shown in Figure 1 below.

Bob chooses Location Service. He then decides to Find Nearest places to his location. He chooses to find nearest Restaurants.

In this example, Bob's predefined user preferences specify to show three restaurants. However, a further page could ask for the number of restaurants Bob would like to see.

The Restaurant link on the WAP phone corresponds to an HTTP link to a location-based service that is offered by a service provider, HTTP://<host>/service/locationbasedservice/nearestrestaurant.wml.

As shown in Figure 2 below, the WAP request enters a wireless network (point 1 in the figure). The wireless network directs the request to a middleware location-based service product (point 2). The middleware product in this example is IBM WebSphere Everyplace Server (WES). WES provides a gateway that converts the WAP request into an HTTP request. The gateway also attaches Bob's mobile identification number (MIN), which in this example is a phone number, to the HTTP flow as part of the HTTP header. WES then authenticates user Bob and the request is forwarded to the location-based service component within Everyplace Server.

At this point the HTTP flow contains:

• URL: HTTP://<host>/service/locationbasedservice/nearestrestaurant.wml
• MIN: 9192549876
• User: Bob

Back to top

Privacy considerations

Privacy is a very important issue in location-based services. As a user, Bob decides what applications are allowed to receive his location. These applications are previously registered in Bob's user preferences. Once the location-based service receives the HTTP request from WES, privacy checks are performed. A check is made to determine if the requested application is a location-based application. Additionally, a check is made to determine if the application is allowed to receive Bob's location. If all checks are returned positive, the location-based service sends the XML request to a mobile location provider (MLP) to find Bob's location (Figure 2, point 3). Below is an example of an XML request to the MLP.

...
...
...
<LIContent>
<LIVersion version="1.3"/>
<LIServiceRequest>
<liTransactionID>1</liTransactionID>
<LISubscriberID>
<liSubscriberIDType type="MIN"/>
  <liSubscriberIDValue>9192549876</liSubscriberIDValue>
</LISubscriberID>
<LISubLocation><liCellID></liCellID></LISubLocation>
<liServiceType>WHEREAMI</liServiceType>
<liNumberBusiness>1</liNumberBusiness>
<LIContentTypes>
<liContentItem item="Address" />
<liContentItem item="Postcode" />
<liContentItem item="LatLong" />
<liContentItem item="OtherLocation" />
<liContentItem item="LocDesc" />
</LIContentTypes>
</LIServiceRequest>
</LIContent>

For brevity, the DTD has been removed from the XML request and noted by the ellipsis (...). Some relevant parts of the XML request are in bold type.

The important feature to note is that the MIN is input into the request, and the user's location information is returned from that MIN in the response. The MLP in this example uses cell-sector technology to determine location with the aid of Location Finding Equipment (Figure 2, point 4).

The star in Figure 3 below represents Bob's location. The blue dot represents the cell tower that Bob's WAP phone is roaming off. The cell tower has a coverage diameter represented by the circle around the tower. The cell tower's coverage is broken into cell sectors, represented by the three pie shapes within the circle. Location Finding Equipment determines that Bob's WAP phone is located in cell sector 1 by using his MIN, and returns the cell ID (Figure 2, point 5). The cell ID is returned to the MLP where it is translated into a latitude/longitude. The latitude/longitude returned is NOT the exact location of Bob; it is the latitude/longitude of the center of the cell sector. The precision of Bob's location to the center of the cell sector will vary according to the size of the cell sector.

Back to top

Pinpointing Bob

The MLP now knows the latitude/longitude of Bob (within a given variance). It can now reverse geocode that latitude/longitude into location information such as address, postal code, city, county, or country, and return it to the location-based service (Figure 2, point 6). Below is an example of an XML response.

...
...
...
<LIContent>
   <LIVersion version="1.3"/>
   <LIServiceResponse>
      <liTransactionID>1</liTransactionID>
      <liServiceType>WHEREAMI</liServiceType>
      <liNumberBusiness>1</liNumberBusiness>
      <liZone>80302</liZone>
      <liLocDesc>22ND ST and SPRUCE ST</liLocDesc>
      <LIContentInfo>
         <LIContentService>
             <liAddress>2226 PEARL ST</liAddress>
		<liPostcode>803024630</liPostcode>
		<LILatLong>
		<liLatitude>40020712</liLatitude>
		<liLongitude>-105265400</liLongitude>
		<liUncertainty>0</liUncertainty>
		</LILatLong>
		<liOtherLocation>Boulder, Boulder, CO, USA
		</liOtherLocation>
         </LIContentService>
      </LIContentInfo>
      <LIReturnStatus>
         <liStatusCode code="0"/>
      </LIReturnStatus>
   </LIServiceResponse>
</LIContent>

For brevity, the DTD has been removed from the XML request and noted by the ellipsis (...). Some relevant parts of the XML request are in bold type.

Note that latitude and longitude were returned from the MLP, along with reverse geocoded information such as address and so forth.

Location-based services now has Bob' location. It may remove the MIN and User from the HTTP request for privacy reasons, so users and their locations are not associated with each other. And, location-based services will augment the HTTP request with the location information and send that request to the location-based application, where the three closest restaurants are obtained (Figure 2, Point 7).

At this point the HTTP flow contains:

• URL: HTTP://<host>/service/locationbasedservice/nearestrestaurant.wml
• Location Information: (added to the HTTP request)

  <?xml version="1.0" ?> <!DOCTYPE LBSLocation SYSTEM "LBSFeature.dtd"> <LBSLocation> <timestamp>m137/2/01M48000</timestamp> <address> <street>2226 PEARL ST</street> <otherLocation>Boulder, Boulder, CO, USA</otherLocation> <zipcode-postalcode>803024630</zipcode-postalcode> <intersectionStreet>22ND ST and SPRUCE ST </intersectionStreet> </address> <geoLocation> <locationPoint> <PointsrsName="EPSG:4326"> <coordinates>-105.265400, 40.020712</coordinates> </Point> <uncertainty>0</uncertainty> </locationPoint> </geoLocation> </LBSLocation>

  
  

The location-based application parses the location header for the needed location information. It then sends an XML request to a location content provider (LCP) to find the closest restaurants (Figure 2, point 8).

<LIContent>
      <LIVersion version="1.3"/>
      <LIContentRequest>
         <liTransactionID>1</liTransactionID>
         <LISubLocation>            
            <LILatLong>
		<liLatitude>40020712</liLatitude>
		<liLongitude>-105265400</liLongitude>
		<liUncertainty>0</liUncertainty>
		</LILatLong>
         </LISubLocation>
         <liServiceType> RESTAURANTS </liServiceType>
         <liTimestamp>19981117132610100</liTimestamp>
         <LIRadius> 
            <liRadiusValue>5</liRadiusValue>
            <liRadiusUnits units="Miles"/>
         </LIRadius> 
         <liNumberBusiness>3</liNumberBusiness>
         <LIContentTypes>
            <liContentItem item="Name"/>
		<liContentItem item="Address"/>
		<liContentItem item="Phone"/>
         </LIContentTypes>
      </LIContentRequest>
  </LIContent>

The LCP determines the requested content and returns an XML response (Figure 2, point 9).

<LIContent>
      <LIVersion version="1.3"/>
      <LIContentResponse>
         <liTransactionID>1</liTransactionID>
         <liServiceType>RESTAURANTS</liServiceType>
		<liNumberBusiness>3</liNumberBusiness>
         <liZone>Granby, Colorado</liZone>         
         <LIContentInfo>
            <LIContentService>            
               <liName>Boulder Cafe</liName>
		<liAddress>1247 Pearl St Boulder, CO</liAddress>
		<liPhone>303-444-4884</liPhone>
            </LIContentService>
            <LIContentService>            
               <liName>Rocky Mt Joe's</liName>
		<liAddress>1410 Pearl St  Boulder, CO</liAddress>
		<liPhone>303-442-3969</liPhone>
            </LIContentService>
            <LIContentService>
               <liName>Panera Bread</liName >
		<liAddress>1207 Pearl St Boulder, CO</liAddress>
		<liPhone>303-545-2253</liPhone>
            </LIContentService>
         </LIContentInfo>
         <LIReturnStatus>
            <liStatusCode code="0"/>
         </LIReturnStatus>
      </LIContentResponse>
 </LIContent>

The location-based application uses this information and returns the three closest restaurants and their location (Figure 2, points 10, 11, 12). If desired, the application could return more content, such as menu, wait time, and so on.

Bob receives the requested restaurants, and can now contact his colleague and specify where they will meet.

Resources

• Want to know more about Everyplace Suite? Read some related developerWorks articles:
  • "Extending the reach of your applications" (developerWorks, January 2001).
  • "Extending enterprise data to mobile devices" (developerWorks, November 2000).
  
  
  
• Get technical articles and information for WebSphere developers at WebSphere Developer Domain.
  
  
• Read the MBusinessDaily January 2001 article, "Mobile Business Guide to Location".
  
  
• Visit the WES Service Provider Offering page to learn about IBM offerings that include location-based services.
  
  
• The WebSphere Everyplace Suite site includes a developer resource section where you can download a System Development Kit complete with location-based services samples.
  
  

About the authors

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• How location-based requests work
• Privacy considerations
• Pinpointing Bob
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community