Lookahead.org

Lookahead SmartCity BigData MobileIoT M2MCloud

About

This site provides a web service for the predictive location tracking with circular geofence (read the research papers). It aims to facilitate the mobile Internet of Things (IoT) on aggregating the spatiotemporal context data efficiently and effectively. By adopting the lookahead strategy, the cost of Machine-to-Machine (M2M) communications can be reduced by up to 50 per cent in average. (The cellular M2M data plan is one or two orders of magnitude more expensive than the consumer data plan.) Under user's consent, the raw data gathered here will be shared as Open Data, the natural resource that fuels the smart city. Please contact author by email in case of any problem on using the open API.

Lookahead API

This is a server-side web API to computing the lookahead location. It is designed for the communications between Location Server and Lookahead Server. The Location Server is owned by the location-awared application service provider and directly serves its mobile clients. In addition to location tracking, the Location Server is responsible for its own tasks such as mobile user authentication, privacy policy control, geofence radius setting, route planning, geo-coding and push notification of location update as appropriate. The Lookahead Server can be co-located with Location Server or deployed on the cloud remotely (right here you are visiting now) to support the Location Server (e.g., your server) to compute the lookahead location, as shown in the following message flow.

MessageFlow

For better location prediction, optionally the destination location (obtained from the GPS navigator of the consumer user, or the fleet management server of the enterprise user) can be sent to the Lookahead Server, in addition to the updated location on each location update. The Lookahead Server will construct the route plan accordingly, then perform the greedy lookahead over the deterministic trajectory (see Demo 2) such that the location updates can be halved comparing to the baseline circular geofencing where the lookahead strategy is not adopted (see Demo 1).

If the destination location is not available to Lookahead Server, the Lookahead Server can still perform the greedy lookahead over the mobile's location cache. According to mobile's updated locations, the Lookahead Server will try best to reconstruct the historical trajectory (usually similar to the actual trajectory if the geofence is not too large) and store it in the location cache so as to perform the greedy lookahead on the subsequent tracking sessions over the same trajectory (see Demo 4). In case of location cache miss, the location prediction will fall down to regressive lookahead for penalty avoidance (see Demo 3).

To adopt the cloud-based lookahead computation, the Location Server must obtain the user consent for location tracking and caching anonymously.

The target audience of the following specification is the software programmer who will utilize the Lookahead API for the development of online location-awared services. The impatient visitor can jump to the graphic demo programs for a quick understanding on the lookahead strategy.


Web Service #1. Compute lookahead location for mobile-centric geofencing.

To request for the web service, the Location Server makes an HTTP request to the Lookahead Server with the following fields in query string.

Field Key Value Description
Mobile Identity mid A 32-byte character string

A 32 lowercase hexadecimal digits such as 123e4567e89b12d3a456426655440000. It can be a Universal Unique Identifier (UUID) with no dash, or an MD5 hash value of the customer namespace.

Because the mobile ID is not a real world identity like email address or phone number, the user privacy is preserved like anonymous.

Due to the nature of UUID and MD5, the probability of ID collision is low even though the Lookahead Server enforces no access control at the stage of minimum viable product.

Geofence Radius gra An integer number The spatial threshold in unit of meter, in the range of [100,2000].
Updated Location upd Two floating point numbers separated by comma

The GPS coordinate of the current location, i.e., latitude and longitude in WGS84.

The latitude and longitude are present in degrees to a precision of 5 decimal places, e.g., 51.18400,-3.97831. A higher precision won't increase the lookahead performance while a lower precision may decrease the lookahead performance.

Latitude is in the range of [-90,+90]. Longitude is in the range of [-180,+180].

(Optional) Next Stop Location nxt Two floating point numbers separated by comma

The GPS coordinate of the next stop location with regard to the updated location (i.e., the current location) of a certain route plan.

The next stop location is equivalent to the destination location if the mobile trajectory known a priori contains only one shortest-path route.

This field is optional. Please do not present the next stop location to Lookahead Server if you don't know for sure. A misleading information will bring you the penalty of location prediction error, and waste the computing resources of Lookahead Server. The location prediction will be more accurate if the correct next stop location is available.

Without setting the next stop location, the mobile terminals and Location Server just need a minor software change — take the lookahead location instead of the updated location as the geofence center.

Open data opt 1 (opt-in) or 0 (opt-out)

Agree or disagree to share location as open data.

To push for public interest, the default value is set to 1. Please explicitly set it to 0 if you have any concern or would like to monetize your own data exclusively.

The following string is a sample URL the Location Server sends to the Lookahead Server.
      http://lookahead.org/api2/lu?mid=123e4567e89b12d3a456426655440000&gra=1000&upd=50.09291,-5.66548&nxt=52.45935,1.71386

The Lookahead Server will return the lookahead location and result code in JSON format such as {"lat":50.09291,"lon":-5.66548,"res":210}. In case of critical error, the lookahead location may be nullified (e.g., {"lat":0,"lon":0,"res":512}) and shall be ignored (i.e., fall down to no lookahead). The possible result codes include but are not limited to the following (subject to change):

Result code Type Description
211 Successful Done for a new or an existing mobile
212 Successful with warning The location update is unnecessary because the prescribed geofence is not breached yet. For penalty avoidance, no location prediction is performed for this transaction. So the updated location is returned as the lookahead location.
213 Successful with warning The displacement from the previous update is much larger than the geofence radius. (Perhaps due to tunnel, urban canyon, or discontinuous tracking session.) The Lookahead Server may still return the best guess.
214 Successful with warning The route planning to the next stop location is failed (e.g., no route, map not matched, too far away from the updated location). The Lookahead Server may still return the best guess.
421 Client Error Missing or invalid mobile identity
422 Client Error Missing or invalid geofence radius
423 Client Error Missing or invalid coordinate of the updated location
424 Client Error Invalid coordinate of the next stop location
511 Server Error Lookahead Server busy
512 Server Error Lookahead Server error

Despite the fact that the mobile terminal can directly update location to the Lookahead Server through the API, we encourage the system engineers to minimize the bandwidth consumption on the air interface, e.g., use the IETF Constrained Application Protocol (CoAP), OMA Lightweight M2M (LWM2M), or MQTT over USSD for the data exchange between mobile terminal and Location Server. Besides, the direct update is not useful until the Lookahead Server provides the location query/push service.


Web Service #2. Compute geofence radius for certain route plan and budget plan.

Given (1) the source and destionation as the route plan, and (2) the expected number of location updates as the budget plan, the Lookahead Server will approximate the geofence radius such that the number of location updates on tracking the given route plan can be bounded by the given budget plan.

To request for the web service, the Location Server makes an HTTP request to the Lookahead Server with the following fields in query string.

Field Key Value Description
Source Location src Two floating point numbers separated by comma The GPS coordinate of the source location.
Destination Location dst Two floating point numbers separated by comma

The GPS coordinate of the destination location.

Number of Location Updates nlu An integer number The expected number of location updates, in the range of [1,1000].

The following string is a sample URL the Location Server sends to the Lookahead Server.
      http://lookahead.org/api2/bp?src=50.09291,-5.66548&dst=52.45935,1.71386&nlu=10

The Lookahead Server will return the geofence radius and result code in JSON format such as {"gra":1000,"res":210}. The possible result codes are the same as above.

Research Papers

Lookahead 1.0: The Lookahead Strategy for Distance-Based Location Tracking in Wireless Cellular Networks, published in ACM SIGMOBILE Mobile Computing and Communications Review, vol. 3, no. 4, 1999.
Lookahead 2.0: The Lookahead Strategy for Online GPS Tracking with Circular Geofence, working paper.

Demo

The demo programs require an HTML5 browser to simulate and visualize the process of location tracking with circular geofence. (Here you can test whether your browser supports Canvas for graphic rendering.) The browser plays the dual role of mobile terminal and Location Server. The browser as a mobile terminal will traverse an artificial GPS trace, and update its current position to Location Server on breaching the geofence. At the meantime, the browser as a Location Server will forward the mobile terminal's updated location to the Lookahead Server as shown in the message flow. As soon as the Lookahead Server returns the lookahead location to Location Server, the Location Server will forward the lookahead location to the mobile terminal. The mobile terminal will register the lookahead location instead of the updated location as the geofence center.

Step 1. Generate an artificial GPS trace as an input to the mobile terminal.
     Source location (latitude,longitude)= () Set latitude and longitude by map
     Destination location (latitude,longitude)= ()
     

Step 2. Specify the geofence radius (/maximum location error) as the second input to the mobile terminal.
      (meter)

Step 3. Run the program of different lookahead type.
Program Lookahead Type Use Case Description Setting
No lookahead Before introducing the lookahead strategy to the mobile-centric geofencing. This is the baseline version of location tracking with circular geofence. It is used to benchmark with the other demo programs. No lookahead request will be sent to Lookahead Server.
Greedy lookahead by reference to route plan (1) A consumer user has a GPS device for the turn-by-turn navigation assistance.
(2) An enterprise user has a well planned route to fulfill the task of logistic transport.

Given the source/updated location as well as the destination/next stop location, the Lookahead Server will prescribe the route plan, and do greedy lookahead over it.

On each location update, the destination/next stop location of the route plan will be sent to Lookahead Server as well.

Click here to do budget planning (use Web Service #2).

Regressive lookahead
(No reference to route plan, location cache, or geographic map.)
Neither route plan nor location cache is in place. We still want to have a bare lookahead without the reference of surrounding roadmap. It should be statistically much better than the random guess and able to mitigate the penalty of prediction error. This is the most cost-effective option for the predictive location tracking. If you are satisfied with it alone, you can implement the simple algorithm (read the research paper) in mobile terminal or Location Server, and then be independent to the Lookahead Server! (1) The destination/next stop location will not be sent to Lookahead Server.
(2) A new mobile identity will be generated so the location cache specific to the mobile is empty.
Greedy lookahead by reference to location cache In case the route plan is not available, the Lookahead Server can still perform the greedy lookahead if the mobile is on track of the reconstructed historical trajectory stored in location cache.
(1) A consumer user has a simple round trip between house and workplace in the daily life.
(2) An enterprise user has a regular path of transportation in the routine task.
The mobile trajectory is extended by appending its reverse path, so it becomes a round trip. The regressive lookahead will be performed on forward tracking; the greedy lookahead will be performed on backward tracking. (1) The destination/next stop location will not be sent to Lookahead Server.
(2) A new mobile identity will be generated so the location cache specific to the mobile is empty.

Alternatively, you can use a GPX file instead of the route plan to do the simulation. (Note that Demo 2 is not applicable here because GPX track can not substitute for route plan. By definition, a route plan is a turn-by-turn shortest-path-first routing where the destination location is known a priori. A GPX track by contrast may be comprised of more than one route plans with each toward different destination location that the GPX schema does not specify.)

The GPS trace (either the route plan or the GPX file) won't be made known to the Lookahead Server in practice. Upon location update, only the current location and optionally its destination location will be sent to the server.

Disclaimer of Location Privacy

The Location Server is responsible for the control of privacy and security. The Location Server must obtain the user consent for location tracking and caching anonymously. The mobile identity given by the Location Server is not necessary to be the real world identity.