Runking : a context aware running ranking system

Runking: a context aware running ranking system

Agenda

• Motivation

• System Architecture

• Mobile Data Management

• Context Awareness

• Q & A

Motivation

• People are lazy when doing fitness

• Import competition among friends to push them to do more exercise– “Mike is running longer than Jim”– “You’re the laziest among your friends”

• Track and rank their degree of running activity

User Scenario

Tom

Upload activity to

server

Ben

Login

Login

Alice

Jerry

Login

Run for 1000m

Push notification to Jerry

Pull data from

Server

disconnected

System Architecture

• Mobile Client-Server Model with:– Single Server– Multiple Clients

Mongo DB

User Information Activity Information

Python Script Engine

Asynchronous Socket Server

MongoDB Python Driver

TCP 4009 Port

Three tiered architecture

Database Server

Application Server

Android Client

Runking App

Android

Runking App

Server Side Design• A lightweight server

implementation containing all business logic and data storage

• Database Server– NoSQL database MongoDB

• Application Server– Python with Asynchronous

socket server Mongo DB

User InformationActivity

Information

Python Script Engine

Asynchronous Socket Server

MongoDB Python Driver

TCP 4009 Port

Database Design

Name Data type Description

uid string User identification

pwd string Login password

follow string array Whom the user have followed

Name Data type Description

uid string User Identification

beg date begin time of the activity

end date finish time of the activity

cur date the time that the activity was saved to database

length integer length of the running

trace string GPS latitude and longitude trace

User Collection

Activity Collection

Client Side Design

Smart Client

Activity List

Rank Chart

Trace on Google

Map

Settings

Context aware logging

Data manage

ment

Mobile Data Management

• Disconnected Operation– Local Data Copy– Local Command Queue

• Data Dissemination– Pub / Sub Model– Push & Pull

• Data Caching– DC-PS-SL

Disconnected Operation

• User can view / modify the data no matter there is network or not.

• If network is available, communicate with server directly.

• If no network, store the operation command sequence into the local queue.

• Send the queued commands when reconnected.

Disconnected Operation

Local Command Queue Operation

Data Dissemination

• Pub / Sub Model

• User can subscribe messages from interested users in “Setting -> Friend Setting”

• Only those subscribed message will be disseminated to user.

Pull and Push

• Pull the activity list down to pull data from server manually.

• Data push can be enabled in “Settings”

Push Policy Design

• New Friend Push:– Push as soon as some user

follow you

• New Activity Push:– Push only when:– Your rank will be surpassed

soon. (lead < 5%)– The rank has changed

Data Caching

• Cache data on cellphone

• Replace cached item only when expired.

• User can set the cache period in Settings, default is 60 days.

• User can manually clear all cached items

Protocol Design: DC-PS-SL

DC-PS-SL

• DC: (Delta Consistency) Server only push to client when satisfy certain policy (as described in push policy design).

• PS: Push

• SL: (Stateless) Server doesn’t maintain state information of client, client may miss the push when disconnected.

Context Awareness

Motivation of Context-aware

• Minimum human intervention– No need for user to manually start.– Even the most popular running apps requires user

to click the button to start. • Energy saving– GPS is off when user is not running

Context Aware System

• Context: Activity• Service: GPS

Context

Running Activity Detection

Service

GPS Information Enquiry

Offline Training

Activity Detection

Step 1Accelerometer Data and

label Collection

Step 2Classifier Generation

Online Detection

Step 1Accelerometer Data

Step 2Activity Detection

Offline Training

• Accelerometer Data and label Collection

Offline Training

• Classifier Generation

ThanksQ & A

Backup: Network Protocol• # request all users in DB

– REQ: friend all– RES: ok tom,jerry

• # get user's following list– REQ: friend follow jason– RES: ok tom,jerry

• # update following list for user– REQ: friend update jason tom,jerry,ben– RES: ok

• # get who is following user– REQ: friend follower jason– RES: ok tom,jerry

Backup: Network Protocol 2

• # synchronize the activity with server– REQ: activity sync jason 30– RES: ok tom,1333174320,1333177937,1332745920,874

jerry,1333174320,1333177937,1332745920,874• # add an activity to server– REQ: activity add

uid,epoch_beg,epoch_end,length,trace– EXA: activity add

jason,1333178959,1333178959,123,null– RES: ok