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 Components "Storage server" - Saves all the locations of the users in the application. "Localization clients" – Client-side code packages that handle the interaction with the storage server. We will provide localization clients for Android and iPhone platforms. "Registered service" – The service will register itself in the server. The consumer will use this when he needs to manage localization data of more than one user. The server can trigger events on the registered services ("push" instead of "pull"). "Location recommendation" – This contains an algorithm that based on the users' past locations, can try to recommend their upcoming movement. "Location-based application" – Uses the "localization client" or interacts with a "registered localization service", to take advantage of the framework's features. This will be developed by the consumer of our framework.

System Architecture Storage server Registered service Location recommendation Operating system modules Mock application Localization client Location-based application Legend: Communication Inheritance

Func. Requirements – Server side

Func. Requirements – Client side

Non-Func. Requirements The connection with the storage server should take less than 5 seconds. The location prediction should take less than 10 seconds.\ The storage server should handle as many as 150 requests simultaneously (The server is available to max. 999 users simultaneously, although some of them might wait until a thread becomes available). In 100% of the cases when an unregistered client makes a request, the operation fails. When a user sends a location update the storage server will update only this specific user's data The system works on the following mobile operating systems only: Android and IOS (IPhone) The client will be able to configure the sending current location frequency and the prediction frequency An initial prototype will be distributed by the end of December. The results from the prototype will determine the better combination of optimizations.

High Level Use Case Diagram

Detailed Use Case – ID3 ID:3. Add user location Primary actors:User, Location-based application Description:The user informs the system about his current location. Trigger:  In the mock application, the user clicks on the "Add new location" button.  Location-based application calls the "add new location" function. Pre-conditions:Storage server is up The location-based application knows the path to the storage server. The location-based application is running. The current user is registered. Post-conditions:The new location coordinates had been saved in the DB. Flow of events:The system takes the user's current location, either by the GPS service or by some prepared optimizations. The system sends the taken location sent to the server. The storage server updates the DB with the user's new location Alternative flows:none

Detailed Use Case – ID7 ID:7. Predict location Primary actors:User, Location-based application Description:The client asks for its most predicted location. Trigger:  In the mock application, the user clicks on the "predict location" button.  Location-based application calls the "predict location" function. Pre-conditions:The recommendation service is up The location-based application knows the path to the recommendation service. The location-based application is running. The current user is registered and posted more locations than the minimum required by the recommendation service. Post-conditions:The client application gets the coordinate of the most predicted location. Flow of events:1. The recommendation service runs its internal algorithm and gets the most predicted location for the given user 2. The client application gets the result. Alternative flows:Case: not enough data / cannot predict a location for the user Action: a constant result will be returned: the nonexisting coordinate [200,200].

Thank You!