Lookahead.org |
 |
 |
 |
 |
 |
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.
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.
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.
