Multi-criteria infrastructure for location-based applications Shortly known as: Localization Platform Ronen Abraham Ido Cohen Yuval Efrati Tomer 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 Architecture Storage server Registered service Location recommendation Operating system modules Mock application Localization client Location-based application Legend: Communication Inheritance

High Level Use Case Diagram

Data Model - Storage Server

Data Model - Prediction Server

Sequence Diagram Add location -

Events NameInitiated ByDescriptionAction A 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

Events The Android API events NameInitiated ByDescriptionAction User registersApplication developer The 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 SystemThe 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 SystemThe 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).

States Localization server state chart:

States Android client state chart

Object-Oriented Analysis Android Client Class Diagram

Object-Oriented Analysis Prediction Server Class Diagram

Task List PeriodLengthTask 10/4 - 23/4 2 weeks Implementing 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 weeks Finishing up the UI for prototype presentation, integrating the BestManager with the three algorithms 22/5 - 4/6 2 weeks Writing a User manual, expanding the ADD test part to a testing document 5/6 - 17/6 3 weeks Setting up a large scale emulator test, Starting a field test (Beta release).

Thank You!