Multi-criteria infrastructure for location-based
applications Shortly known as:
Localization PlatformRonen AbrahamIdo CohenYuval EfratiTomer Sole'
Background
These days many mobile devices have an internal GPS service that can ask the GPS server where the holder of the device is location at.
This usage is very resource-heavy and wasteful to the user.
Project Goal"Localization Platform" is a framework for location-based applications.
The purpose is to answer on common needs in this subject, using efficient and reliable implementations of location-based issues:• Storing the present and past locations of every user in the
application.• Limiting the use of the following 4 parameters on the way:
– battery life– network data plan– processing time – memory space
System ArchitectureStorage server Registered service
Location recommendation
Operating system modules
Mock application
Localization client
Location-based application
Legend:
Communication
Inheritance
High LevelUse CaseDiagram
Data Model - Storage Server
Data Model - Prediction Server
Sequence DiagramAdd location-
Events
Name Initiated By Description ActionA server operation was made
System, triggered by the application developer (or the user in the mock application)
The server communicates through REST protocol. The user can either use Loca API to call a client operation which will call the server via REST, or call the server himself by entering the right parameters in a REST call, or press a button in the mock application.
When the server is triggered, depending on the operation it initiates a database session, and uses the database to read/write relevant data. If the caller was a client application and the function has an output, it is returned via REST protocol.
general client-server event
EventsThe Android API events
Name Initiated By Description ActionUser registers Application
developerThe user has to register itself before starting to track locations. LocaManager has a function for that.
After notifying Loca Server with the user's phone identifier (IMEI), a unique user ID is returned and saved. From now on, the system can start tracking locations.
User starts tracking location
Application developer
The user initiates the location collection process
Concrete LocaManager starts managing the user's locations. In BestManager's case, it starts listening to signals from each of the LocationSource classes.
GPS signal is received
System The system asks GPS for the current user location, or receives an event from the GPSSynchronizer
If BestManager is selected to manage locations, it sends the new location with its accuracy to all the other LocationSource classes, and they synchronize accordingly.
Accelerator / Compass signal is received
System The system asks an internal sensor for some input, or receives an event from it.
StayPolicy calculates whether the user has moved significantly from the last location he was at. GAC calculates the user's new location based on his internal algorithms, and returns the new location and the expected accuracy.
User stops tracking location
Application developer
The user asks LocaManager to stop the location tracking.
If BestManager is selected to manage locations, it turns off its input Location Sources (GPSSync, GAC, Stay) which turn off Android's internal location sources (GPS, compass, accelerometer).
StatesLocalization server state chart:
StatesAndroid client state chart
Object-Oriented AnalysisAndroid Client Class Diagram
Object-Oriented AnalysisPrediction Server Class Diagram
Task ListPeriod Length Task
10/4 - 23/4 2 weeksImplementing The GAC algorithm and the
Stay policy
24/4 - 7/5 2 weeks Implementing the BestManager, rearranging the server GUI
8/5 - 21/5 2 weeksFinishing up the UI for prototype
presentation, integrating the BestManager with the three algorithms
22/5 - 4/6 2 weeksWriting a User manual, expanding the ADD
test part to a testing document
5/6 - 17/6 3 weeksSetting up a large scale emulator test,
Starting a field test (Beta release).
Thank You!