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 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 ArchitectureStorage server Registered service

Location recommendation

Operating system modules

Mock application

Localization client

Location-based application

Legend:

 Communication 

   Inheritance 

Func. Requirements – Server side

Server DatabaseThe storage server shall hold a database with all the users, the users' locations, registered services and the events the services are registered to.

SecurityThe framework should not expose the entire database to one user, only the information that relevant for him. The localization client will get information only relevant to the user it represents.

Add user locationLocalization client / registered service send to the storage server a location update, about a user, a specific time, and location coordinate.

Server sessions monitoring

The storage server shall manage a log file that will indicate who contacted the server, when the connection occurred and all the data transfer.

Server Deployment An installation guide on how to set up a new storage server will be provided.

Func. Requirements – Client side

Start localization client Localization client begins getting user's locations every period of time, and sending updates to the server. 

Register serviceA service adds itself to receive event notifications from the storage server ("push"). This also gives the service permission to ask the server for past locations and add new user locations.

Register userLocalization client sends a unique identifier of the user to the storage server. The storage server returns an ID of the user, and that's how the user is recognized from now on.

Predict next locationA function of the recommendation service. Returns the next recommended location of the given user based on the algorithm inside it.

Mock application A demonstrator for the localization client and the registered service will be implemented, with a simple GUI.

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 LevelUse CaseDiagram

Detailed Use Case – ID3ID: 3. Add user locationPrimary actors: User, Location-based applicationDescription: 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 upThe 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 – ID7ID: 7. Predict locationPrimary actors: User, Location-based applicationDescription: 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 upThe 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 user2. The client application gets the result.

Alternative flows: Case: not enough data / cannot predict a location for the userAction: a constant result will be returned: the nonexisting coordinate [200,200].

Thank You!