CADD : Context Awareness for ... - Rutgers University

CADD : Context Awareness for Distraction-free Driving

System Design and Implementation

by

SANGEETHA SIDDEGOWDA

A thesis submitted to the

Graduate School-New Brunswick

Rutgers, The State University of New Jersey

in partial fulfillment of the requirements

for the degree of

Master of Science

Graduate Program in Electrical and Computer Engineering

written under the direction of

Professor Marco Gruteser

and approved by

________________________

________________________

________________________

________________________

New Brunswick, New Jersey

May, 2013

ii

ABSTRACT OF THE THESIS

CADD: CONTEXT AWARENESS FOR DISTRACTION–FREE DRIVING

System Design and Implementation

by Sangeetha Siddegowda

Thesis Director: Professor Marco Gruteser

Smart phones have extended the capability of a phone from "texting and calling" to a

whole new dimension of context-awareness with the capabilities of on-device sensors.

This is particularly useful in providing context-adaptive user-centric automated services,

which is emerging as an area of much current research interest. In this work, we present

the system design aspects pertaining to Context Awareness for Distraction-free Driving

(CADD) system, a realization of context awareness and context-aware automated

services, designed to mitigate in-vehicle distraction caused by cell phones. Context

awareness in this work refers to the state of the user: Driving or Available. This state is

detected using a Bluetooth and GPS sensor based scheme on the device. Along with the

end to end system design, our focus has been on reducing latency, enabling privacy

driven data sharing and attaining reliability, aimed at optimization of automated services.

The design exploits the Google Cloud to Device Messaging framework and Amazon Web

Services to enable efficient communication between clients and allow scaling to large

numbers of users. For critical services as context updates, we have improved the

reliability from a success rate less than 50% to greater than 90%, by introducing triple re-

transmissions and network connectivity monitored re-tries for intermittently connected

devices. Further, we have tested both GPS based and Network based updates for location

iii

services. By using an algorithm that combines both GPS and Network based updates, we

have reduced the latency of obtaining the first location fix from a few seconds (>

4seconds) to less than a second (~500-800msec) with a deviation in path limited to 500-

1000m. This scheme also improved performance with in-door locations where GPS-

based updates fail. To address the location related privacy concerns, our design maintains

no location history information and utilizes proximity metrics namely time and distance,

as opposed to plainly exposing the geo-location of users on maps. Further, we have also

designed the user interfaces iteratively based on feedback from test users. The user

interface has been optimized to keep the depth of navigation to be less than 4 (measured

as the number of clicks or the screens navigated to complete one service).

iv

Acknowledgements

I would like to express my sincere gratitude to my advisor Prof. Marco Gruteser for

believing in me and providing me with an opportunity to work under his guidance. I

would like to thank him for the timely inputs, valuable suggestions and constant support

that have reinforced my self-belief and helped me successfully overcome the hardships I

faced.

I would like to take this opportunity to thank Prof. Dipankar Raychaudhuri for his

untiring advice and constant encouragement through the course of my Masters and

also for directing me to the research opportunity at Intel Labs. I would also like to

thank Prof. Janne Lindqvist for his technical feedback and support through various stages

of the project. I would additionally like to thank both of them for accepting to serve on

the thesis committee.

I express my thanks to the enthusiastic students at Winlab who participated in testing,

enhancing and providing feedback on the system performance.

My friends have contributed significantly and helped me during my stay at the

University. I extend heartfelt thanks towards them.

I am indebted to all my family members and particularly my father Mr. Siddegowda,

who stood by me through the completion of my thesis and the Master’s program.

v

Dedication

To my family

vi

Table of Contents

Abstract .............................................................................................................................. ii

Acknowledgements .......................................................................................................... iv

Dedication ...........................................................................................................................v

List of Figures ................................................................................................................... ix

Chapter 01 ..........................................................................................................................1

Introduction ........................................................................................................................1

Chapter 02 ..........................................................................................................................5

Related Work .....................................................................................................................5

2.1. Background ......................................................................................................... 5

2.2. Addressing distraction ........................................................................................ 6

2.2.1. Hands-free aid ............................................................................................... 6

2.2.2. Context Aware services ................................................................................ 6

2.2.3. Utilizing Vehicle On-board devices .............................................................. 7

2.2.4. Usage in Context aware social networking applications .............................. 7

2.3. Approach ............................................................................................................. 8

Chapter 03 ........................................................................................................................10

Design ................................................................................................................................10

3.1. Key Ideas .......................................................................................................... 10

3.1.1. Context-aware services ............................................................................... 11

3.1.2. Automated services ..................................................................................... 11

3.1.3. Addressing passive entities ......................................................................... 11

3.1.4. Improving user acceptance ......................................................................... 11

vii

3.2. Design Goals ..................................................................................................... 12

3.3. Design Outline .................................................................................................. 12

3.4. User Interface Design ....................................................................................... 15

3.4.1. Relationship Diagram ................................................................................. 15

3.4.2. User interface .............................................................................................. 16

Chapter 04 ........................................................................................................................22

Implementation ................................................................................................................22

4.1. Use-case description ......................................................................................... 22

4.2. Requirements .................................................................................................... 23

4.3. System Architecture Components..................................................................... 24

4.3.1. Android Clients ........................................................................................... 25

4.3.2. Google Cloud to Device Messaging Framework ........................................ 30

4.3.3. Android Class Design ................................................................................. 32

4.3.4. Amazon Web Services ................................................................................ 34

4.4. Specs ................................................................................................................. 39

4.5. System Features Implementation ...................................................................... 40

4.5.1. Context Detection and context aware services ........................................... 40

4.5.2. Privacy Driven location Sharing - implementation .................................... 40

4.5.3. End to end system usage ............................................................................. 42

4.6. End to End Message Flows ............................................................................... 43

4.6.1. End device registration ............................................................................... 43

4.6.2. Context update ............................................................................................ 44

4.6.3. Event scheduling ......................................................................................... 45

viii

4.6.4. Proximity Data Sharing............................................................................... 46

Chapter 05 ........................................................................................................................48

Design Optimizations .......................................................................................................48

5.1. Network connectivity and context updates ....................................................... 48

5.2. Location updates ............................................................................................... 50

Chapter 06 ........................................................................................................................55

Test and Results ...............................................................................................................55

6.1. Features Supported across versions .................................................................. 55

6.2. Context updates - reliability .............................................................................. 56

6.2.1. Test Setup.................................................................................................... 56

6.3. Initial Location Fix and latency ........................................................................ 58

6.3.1. Test Set up................................................................................................... 58

Chapter 07 ........................................................................................................................60

Conclusion and Future Work .........................................................................................60

7.1. Future Work ...................................................................................................... 61

REFERENCES .................................................................................................................62

ix

List of Figures

FIGURE 1.1. SIMPLIFIED USE CASE DIAGRAM..................................................................................................... 2

FIGURE 3.1. SPECTRUM OF SOLUTIONS FOR DISTRACTED DRIVING .................................................................. 10

FIGURE 3.2. IDEA OUTLINE.............................................................................................................................. 13

FIGURE 3.3. RELATIONSHIP DIAGRAM ............................................................................................................. 16

FIGURE 3.4. MAIN SCREEN .............................................................................................................................. 17

FIGURE 3.5. CONTACT WHOSE CONTEXT IS ‘DRIVING’ AND PROXIMITY DATA AVAILABLE .............................. 18

FIGURE 3.6. CONTACT WHOSE CONTEXT IS ‘AVAILABLE’ AND PROXIMITY DATA AVAILABLE ......................... 18

FIGURE 3.7. WARNING TO USERS WHEN CONTACT’S CURRENT CONTEXT IS ‘DRIVING’ .................................... 19

FIGURE 3.8. OPTIONS AVAILABLE FOR A CONTACT WHOSE CONTEXT IS ‘AVAILABLE’ ..................................... 20

FIGURE 4.1. CADD SYSTEM DESIGN ................................................................................................................. 25

FIGURE 4.2. SIMPLIFIED ANDROID ARCHITECTURE .......................................................................................... 26

FIGURE 4.3. GOOGLE CLOUD TO DEVICE MESSAGING FRAMEWORK ................................................................. 31

FIGURE 4.4. ANDROID PACKAGES AND CLASSES ............................................................................................. 34

FIGURE 4.5. AWS APPLICATION SERVER .......................................................................................................... 35

FIGURE 4.6 SERVLET ARCHITECTURE .............................................................................................................. 37

FIGURE 4.7. SERVLET PACKAGES AND CLASSES .............................................................................................. 38

FIGURE 4.8. PRIVACY-DRIVEN LOCATION SHARING ........................................................................................ 41

FIGURE 4.9. USER INTERFACE DISPLAYING PROXIMITY DATA ......................................................................... 42

FIGURE 4.10. END TO END APPLICATION DESIGN ............................................................................................. 43

FIGURE 4.11. REGISTRATION MESSAGE FLOW ................................................................................................. 44

FIGURE 4.12. CONTEXT/USER STATUS UPDATE ................................................................................................ 45

FIGURE 4.13. EVENT SCHEDULING END TO END FLOW ..................................................................................... 46

FIGURE 4.14. DATA SHARE BETWEEN TWO CLIENTS ........................................................................................ 47

FIGURE 5.1. NETWORK CONNECTION FLUCTUATIONS ON A CLIENT ................................................................. 48

FIGURE 5.2. NETWORK CONNECTIVITY AND CONTEXT UPDATES ..................................................................... 49

x

FIGURE 5.3. NETWORK CONNECTIVITY OPTIMIZED CONTEXT UPDATES ........................................................... 50

FIGURE 5.4. GPS AND NETWORK TRIGGERED LOCATION UPDATES ................................................................... 51

FIGURE 5.5(A) ACCURACY OF GPS AND (B) NETWORK OBTAINED LOCATION DATA ......................................... 52

FIGURE 5.6. LATENCY INCURRED IN INITIAL FIX QUERY .................................................................................. 52

FIGURE 5.7. LOCATION SERVICE ALGORITHM .................................................................................................. 54

TABLE 6.1. FEATURES AND APPLICATION VERSIONS ....................................................................................... 56

TABLE 6.2. VARIOUS TEST LOCATIONS AND CONNECTION MODES ................................................................... 56

FIGURE 6.1. CONTEXT UPDATES SUCCESS RATE AGAINST APP VERSION .......................................................... 58

FIGURE 6.2. INITIAL LOCATION FIX DELAY...................................................................................................... 59

1

Chapter 01

Introduction

Usage of phones is known to be one of the primary causes for distracted driving. As per

the statistics announced by the National Safety Council at its annual attributable risk

estimate in 2011, about 1.3 million crashes involve cell phones. This accounts to about 23

percent of crashes per year [1]. The report also indicates that cell phone conversations are

about 12 times more frequently involved in crashes compared to texting. Various recent

research reports have stated and analyzed the impact of usage of phones on driving. It is

pointed out that even when drivers actually gaze at the object they fail to “see” them in a

driving environment when they are involved in a conversation as stated in [2]. There have

been legislative initiatives that permit hand-free devices [3]. However, a study indicates

that hands-free devices may not solve the problem but have distracting effects due to the

direction of attention towards internal cognitive context associated with conversation

over the external environment as studied in [4,5].

With the worldwide smart-phone user base touching 1 billion, as per the statistics from

research firm Strategy Analytics [6], it is important to address the cell phone induced

distraction. Smart phones are known for their multi-functional capability beyond

messaging and calling. Adding to this are the recent developments in on-device sensor

technology that have opened up newer avenues in user-centric context-aware research. In

this work, we have designed a proof of concept system, which exploits the ubiquity and

capabilities of smart phones. Smart phones with embedded sensors help in attaining user-

centric context –awareness that have been of research interest as outlined in [7]. We

leverage this smart phone capability, to attain a completely automated in-vehicle

2

distraction level mitigation system. This work is built on the knowledge that certain event

triggers can be set up prior to driving by the user, which could then be utilized in

achieving automated services as described under Activity based sharing and time shift

operations, as part of the work on attaining undistracted driving using mobile phones [8].

To the best of our knowledge the end to end system design presented here is novel.

The design presented here can be used as a platform to embed other context aware

services. The context-awareness here refers to the state of user: driving / available

derived from Bluetooth and GPS sensors. The design addresses two classes of users:

Drivers– whose state at the given time is “driving” and conversation partners- who are a

potential cause for distracted driving of active users.

The basic use case for the system is as shown in figure 1.1. Based on the class of user

different services are provided. The services available are context detection, context

share, event scheduling and privacy driven information sharing.

Figure 1.1. Simplified Use case Diagram

3

The solution has been implemented using Android clients [9]. The logic for context

detection and event scheduling are implemented on the client. The data share and

management related functionality is shifted to a separate centralized system/server. The

server has been implemented using the Amazon Web Services (AWS) cloud

infrastructure [10]. The end to end communication between end-user devices is enabled

using the Google Push service – Google Cloud to Device Messaging (C2DM) framework

[11]. The survey presented in [7] also points out the privacy concerns while the context

information is utilized and suggests that there should be a balance attained in using the

context information and ensuring privacy. There have been studies on privacy concerns

when location tracking is utilized as pointed out in [12] for two classes of services

location tracking and position aware services. This work indicates that users are more

willing to provide location information when it is useful to own context and are

concerned about privacy when location is shared with another user.

The system designed here offers services for distraction level mitigation. It address two

classes of users ‘Drivers’ and ‘Conversation partners’/ Passive users. Also, we utilize

position awareness- shared with other users and hence we have addressed location related

privacy in our design. We achieved this using the proximity metrics over plainly

exposing the geo-location of the users. We have also focused on attaining reliable

communication between entities involved and optimizing the location sensing on the

client. Further, we also cover the effective user interaction patterns achieved using

iterative testing based enhancements.

The rest of the thesis is organized as follows. Chapter 02 describes the related work

explored as part of the literature survey. It will include various applications and aids

4

available to help user attain undistracted driving. Chapter 03 details the system design

aspects that realize the various key ideas that drive the project. Chapter 04 covers the

system implementation starting with outline of specific use case and system design

requirements and then details of end to end architecture, Android class interaction and

server implementation and finally end to end message flow between entities. Chapter 05

covers the design challenges and respective optimizations. Chapter 06 will cover the

deployment of the application and results. Lastly, in Chapter 07 we discuss the

conclusion and future work.

5

Chapter 02

Related Work

With recent distraction-free driving campaigns and efforts by U.S government [13, 14,

and 15] and ATT [16], undistracted driving is surely gaining importance and momentum.

In this chapter we cover the literature survey, to include the various aids or applications

available to attain undistracted driving. These include hands-free devices, specific context

aware solutions and on-board device assistance based solutions.

2.1. Background

Distraction due to cell phones can be categorized into three classes :

Visual distraction: Task of driving requires user's active visual attention on road.

However, while performing operations on phone, a user's visual attention is

diverted.

Manual Distraction: Users manually control the steering while driving. However,

this capability shall be affected when user tries to use the phones while driving.

Cognitive distraction: This class refers to distraction of mental attention while

driving. This is cognitive distraction as the attention is split between the task of

using phones and driving.

One of the primary causes for distracted driving is texting and involves all 3 types of

distraction: visual , manual and cognitive. As per statistics from U.S gov [13] , about 4.6

seconds of attention is taken off the road while sending or reading one text message. This

is compared to driving the length of an entire football field at 55 mph, blindfolded.

6

2.2. Addressing distraction

2.2.1. Hands-free aid

There are hands-free aids that are Bluetooth or wireless based available in the market

which are assumed to attain some level of distraction-free driving. There have been

hands-free laws [17] passed that allow users to use cell phones while driving provided

they utilize a hands-free device. This means a user can dictate commands to device while

driving. Although this seems like an acceptable solution, there have been studies such as

one outlined in [18], which imply that distractions may be caused even while using a

hands-free device as the impact is cognitive and related to the task of talking rather than

how it is achieved. This can take care of visual and manual distraction but fails to address

the cognitive distraction.

2.2.2. Context Aware services

These are applications built on smart-phones [19, 20] that exploit information available

through sensors on smart-phones to provide services for distraction free driving. While

these can attain reduced distraction levels, user’s co-operation is required for their

operation. The solution by ATT [20], helps parents monitor and remotely control the

teenage driver’s cell phone usage while driving. We believe that this may receive low

acceptance owing to the privacy concerns of the users. With our design we provide

‘privacy driven data sharing’ between users, which shall encourage the users to utilize

this service improving the acceptance probability of the overall solution. We have

integrated this idea based on prior work [8], using the location context information to

provide privacy-driven data share. Although we utilize the location information of the

users, it is made available to people interested (parents / friends) as a proximity

7

estimation metrics in terms of distance/ time over plainly exposing the location of user

that shall be detailed in the next chapter

Simplest system would be one which utilizes context data to disable all services on

device. This solution can be thought of as a "Binary solution", which offers no flexibility

to user.

Another known problem with this class of applications is the identification or

classification of user in vehicle as driver or passenger. Our solution presented here can be

easily extended to plug-in a Bluetooth based driver detection algorithm developed

previously at our lab (WINLAB, Rutgers University) [21].

2.2.3. Utilizing Vehicle On-board devices

These solutions exploit the enhancements in the automotive industry like vehicle onboard

diagnostics [22]. The vehicles come with on-board sensors and display systems that can

be exploited to derive information required to provide context aware services using smart

devices. Some solutions perform context detection and require Driver’s speech input to

control various services. In the implementation presented here, we exploit the presence of

in-vehicle Bluetooth to provide contextual data. However, in cases where these sensors

are absent, these systems require special installations that come with an extra cost.

2.2.4. Usage in Context aware social networking applications

These are innumerable applications like Foursquare [23], Google Latitude [24], even

Facebook [25], which utilize the location awareness available from phones. Foursquare is

a social networking application that lets users check-in their location and update reviews

on the places visited. The location usage is based on user’s preference. Whereas, Google

8

Latitude, exposes the geo-location of the user at all places once enabled and also

maintains the history of user’s location information.

2.3. Approach

We design an end to end system that shall provide automated context aware services.

These services are designed to address all three classes of distraction- visual/ manual and

cognitive.

With automation, we address the cognitive distraction prominent in context aware

systems that are speech controlled or solutions such as hands-free devices. We not only

provide services for ‘Drivers’, we also provide services for conversation partners or

passive users who are a potential cause for distracted driving. Ex- Context of ‘Drivers’ is

made available to passive users, they are also warned of potential distraction that they

may cause when they initiate a call / message service to ‘Drivers’

We provide ‘privacy-driven data sharing’ between users, which shall encourage the

users to utilize this service improving the acceptance probability of the overall solution.

We have integrated this idea based on prior work [8], using the location context

information to provide privacy-driven data share. Although we utilize the location

information of the users, it is made available to people interested (parents / friends) as a

proximity estimation metrics in terms of distance/ time over plainly exposing the location

of user that shall be detailed in the next chapter.

Additionally we ensure that no location history of the user. We believe this is crucial in

attaining a higher acceptance probability for the over-all application and critical to the

active usage of the solution, when we provide users with flexibility to control the sharing.

9

Furthermore, to address the increasing popularity and usage of the social networking

applications as Facebook [25], we have designed the context information to be available

via API(s) that allow requests to our server. Using this, we can make the context of the

user – “Driving/Available” to the contacts on social networking circles.

With this background, we now move onto next chapter which will present the main

design goals to attain a distraction-free driving assistance system.

10

Chapter 03

Design

This chapter covers the key ideas that drive the system, provides the design goals that lay

foundation for the system implementation and cover the design aspects. We detail the

automated services along with user interface design and specifics.

3.1. Key Ideas

The spectrum of solutions available for the problem of in-vehicle distraction mitigation is

as in figure 3.1. At one end of the spectrum are the hands-free devices that address in

manual and visual distraction. However, they do not address the cognitive distraction as it

is due to the act of talking and not how it is achieved. At the other end are the context

aware binary systems which would turn off the distractive services when the user's

context is detected to be Driving. These address the distraction mitigation but do not offer

flexibility to users and hence would have a low acceptance among users. The system

presented here falls into the category of solutions that offer services beyond disabling all

functionalities and help users attain distraction mitigation.

Figure 3.1. Spectrum of solutions for distracted driving

The key ideas that drive this system design are as follows:

11

3.1.1. Context-aware services

Context aware automated services will help in addressing the cognitive distraction which

are unsolved by solutions such as hands-free devices.

This class of solution also helps in achieving middle ground as depicted in the spectrum

figure 3.1. Middle ground refers to the design of a solution that would provide services to

address the drawbacks of binary as well as hands-free device based solutions. By

providing automated services we aim to address cognitive distraction as in case of hands-

free devices. And, by providing data sharing services we offer more than the binary

systems.

3.1.2. Automated services

Automation reduces user decisions while ‘Driving’ unlike solutions such as hands-free

devices, user speech controlled designs.

3.1.3. Addressing passive entities

System directly addresses active users - who are ‘Driving’. We also want to address the

passive users as they are known to be a potential cause for distracted driving. This would

mean offering services to passive users based on their contact's context (i.e., set to

Driving).

3.1.4. Improving user acceptance

The design must ensure privacy of location data as data sharing involves other entities

with whom the location related information is shared with. We believe that exposing the

geo location would reduce the acceptance probability of the solution and hence one of the

12

primary design goals is to ensure privacy drive data sharing while utilizing location

sharing

3.2. Design Goals

The design goals for the project are derived from the key ideas detailed above and are as

listed below:

Context-aware user-centric services that ensure :

o Reliability

o Improved performance

Auto- functional capabilities that help in attaining :

o User trigger reduction while retaining flexibility and usability

Privacy for location data sharing

Efficient end to end communication scheme

3.3. Design Outline

The design outline is as depicted by figure 3.2 that shows an end to end system with the

two classes of users and the services enabled specific to each class of users. There are

two classes of users we identify – Active users and Passive users. The automated services

are designed to suit the needs of these two classes of users. This classification is based on

the context information of the users. If the context is detected to be “Driving”, this user is

an Active user else a passive user / conversation partner.

13

Figure 3.2. Idea outline

The automated services for the Drivers shall include context information broadcast, event

driven data share, and privacy enabled location share with specific passive users/

potential conversation partners and mode switching.

Context Information Broadcast

When the user’s context is detected to be “Driving”, a context broadcast is initiated. The

context information is updated to the application server that shall broadcast the context

information to all contacts on the user’s list via C2DM server.

Event Driven Data Share

If the Drivers have scheduled an event prior to driving, then a location data share is

initiated. This will involve timer triggered auto-location updates. The driver’s location

information is pushed to the application server that will calculate the proximity metrics –

namely time and distance measured between users. This is then pushed to user’s contacts

via C2DM service. The contacts refers to conversation partners with whom the event is

scheduled.

14

Privacy Enabled Data sharing

The location data shared above is in terms of proximity metrics and not the exact geo-

location of the user. This ensures privacy control of Driver’s location. Additionally this

service does not monitor patterns of user’ movement. The application server does not

maintain any history of user’s location updates.

Mode Switch

Mode switch refers to changing the state of phone to silent when the user’s context is

detected to be ‘Driving’. Also, when the user’s context reverts to ‘Available’, mode

switch enables the last known settings on phones – like ringing/ vibrator mode.

The services pertaining to conversation partners or passive users shall include event

scheduling, specific warnings when they try to interact with currently active users, look-

up of active user’s location information if available, services to set up reminders for calls

or messages that can be triggered for example - when the active users become available

(change context to become passive and are available to take calls or messages).

Context Information

Conversation partners are updated about the context of their contacts. They can view the

context as ‘Driving’ or ‘Available’ on the client UI.

Event Scheduling

Event scheduling is an example of service that can be set before ‘Driving’. Event

scheduling lets users decide the duration of location data share with any contact. The time

selected during the event scheduling phase acts as trigger for automated location share

15

process. This will ensure that there is no user’s input required while he is ‘Driving ‘to

control permissions or to control data sharing.

Warnings

Conversation partners are a potential cause for distraction. They could place a call or

send a message to a contact that is currently ‘Driving’. With this service design, these

user’s get information on each of the contact’s context. Along with this when they initiate

a call or message to ‘Drivers’, warnings are displayed to warn them of contact’s context.

Reminders

This service helps the conversation partners to set up reminders. These reminders can be

set to remind them to call contacts that are ‘Driving’ when they become available or after

some time.

In the next section we cover the user interaction design on clients that realize the above

discussed design goals.

3.4. User Interface Design

3.4.1. Relationship Diagram

The UI relationship diagram for the application designed is as shown in figure 3.3.It is

represented by directed relationship between screens. An arrow from one screen to the

other (say A to B) implies that screen B can be reached via some user interaction in

screen A. The number of levels also indicates the depth of traversal or the maximum

clicks to complete a particular functionality. Any functionality in our application can be

completed in ≤ 4 clicks.

16

Figure 3.3. Relationship Diagram

3.4.2. User interface

The user interface for the application has undergone iterations and optimizations in

designs, based on test user feedback. In this section we cover the various user interfaces

of the application and the rationale behind the design.

3.4.2.1. Main screen

The motivation behind the main screen design is reduction in number of clicks to retrieve

critical data. In general, an application main screen is designed using the Dashboard

pattern in android that provides a shortcut access to various functionalities of application.

In our application, instead of employing the dashboard scheme, upon single click by user,

we enable user to directly view context of friends and navigate to any of the friend’s

17

profile. We also provide user’s current context information, shortcuts to notifications, add

contacts and scheduled events list as in figure 3.4.

Figure 3.4. Main screen

3.4.2.2. Contact’s profile

Upon click on contacts in the list, we navigate to the screen with various operations

available and also display the proximity information if an event is scheduled during that

time instance. We have the two different screens pertaining to each of the users in contact

list as shown in figure 3.5 and figure 3.6. The options available are maintained consistent

in both screens and the functionalities that are unsupported such as event schedule when

18

the contact’s context is ‘Driving’ are greyed out to indicate this, as in figure 3.5.

Figure 3.5. Contact whose context is ‘Driving’ and proximity data available

Figure 3.6. Contact whose context is ‘Available’ and proximity data available

19

3.4.2.3. Contact’s context is ‘Driving’

When a given contact’s context is driving, warnings are enable automatically for user

operations and if user is viewing the contact profile when context is “Available” and the

contact changes to “Driving”, the options are automatically reloaded with warnings.

These notifications warn users of the potential disturbance to Drivers (users currently

driving). The various warnings are as shown in figure 3.7.

Figure 3.7. Warning to users when contact’s current context is ‘Driving’

3.4.2.4. Contact’s context is ‘Available’

When contact is ‘Available’, an event may to enable data share pertaining to proximity

can be scheduled/ requested for a given duration with the contact. When the other options

such as call or message are used, there are no warnings displayed, as the contact is

currently not ‘Driving’ shown in figure 3.8.

20

Figure 3.8. Options available for a contact whose context is ‘Available’

3.4.2.5. Summary

The maximum number of clicks to activate any functionality is limited to ≤ 4, including

the click to launch application. The depth of screen navigation is also limited by this

factor.

We have also ensured consistency of options across screens while color coding (grey)

the functionalities unavailable in a particular list. This helps people to navigate and

understand screens easily and reduces time in looking up and understanding options on

screen.

The proximity data is shared as time and distance metrics and is available with a single

click from main screen.

To further enhance the user experience, we have optimized the backend to provide

functionalities such as auto-refresh of contact lists when view (contact list screen) is

21

active, auto update of options on contact profile screen and screen when contact’s context

change is detected. Auto refresh of proximity data when the view is active. Lastly, auto

retries of context updates to ensure reliability when there is intermittent data connectivity.

This design ensures optimal performance of application with minimal user interference,

even on passive user’s side. Further, the optimizations are designed keeping the states of

view (user interface) active/inactive, to ensure optimal battery usage, by automatically

disabling auto-refresh functionalities when user is actively not ‘viewing’ the interface.

We next explore the class design / back end design on android clients.

The next chapter will cover the end to end system architecture, the technologies

involved in realizing the design goals, design specifications of various entities involved

and end to end message flows.

22

Chapter 04

Implementation

In this chapter we cover the implementation details starting with use case and

requirements. We then cover the end to end system architecture. Further discuss the

Android class design and details of back-end server design. This server interacts with

C2DM server to enable end to end client communication via C2DM messaging. We

conclude the chapter with end to end message flow between the entities of the system

designed to attain various functionalities and services.

4.1. Use-case description

To understand the end to end system operation, consider a specific usage-case – event-

driven data sharing. This involves there stages - event scheduling, context detection and

event-driven data share. This enables users to share information beyond their context to a

specific class of passive users. The process is detailed as below -

Step 1: Two or more passive users can schedule en event. Once approved by all

participants, this will serve as triggers to share other context relevant information like

proximity estimation or speed etc.

Step 2: When one of the users context changes to driving – becomes an active user, upon

specific event triggers set up prior to driving, data share is enabled.

By default, only context – “driving” is broadcast to all users on contact list. With event

scheduling, the proximity estimators – time and distance, shall be shared with approved

passive users (approved as part of event scheduling).

Step 3: Once event is triggered, a passive user will be able to check the proximity

information of a currently active user.

23

Usage Context – An active user would want to share proximity information only with

family while driving. This is enabled by above use-case realization.

The next section will cover the details of system architecture of a platform for enabling

such end to end services.

4.2. Requirements

System shall support two classes of users – active and passive

Client shall register with C2DM service upon application installation

Users shall be able to add other contacts as friends

Users shall be able to view other contact’s (friend) context information at all times.

Client shall be manually paired with in-vehicle Bluetooth

Client shall automatically detect context of the users when a paired Bluetooth

connection is detected.

Client shall automatically change the state of phone to “silent” when context

detected is ‘driving’

Client shall automatically change the state of phone to last known state when

context detected is changed from “Driving” or active paired Bluetooth is

disconnected.

Client shall update the context change information to server automatically.

Server shall broadcast the context update from an “active user” to user’s contact list

via C2DM service.

Client shall handle all C2DM broadcasts and perform services required.

Client shall support event scheduling, by allowing users to select ‘date’ and ‘time

duration’ for information share with a specific contact.

24

Client shall automatically start location information share at times set by scheduled

events

Location share shall not expose user’s geo-location on maps

User’s proximity information shall be available to contacts that have scheduled

events only for duration schedule.

User’s location shall be shared as proximity data in “time and distance” format, the

time to reach other contact’s location and the distance between two contacts

respectively.

Client shall provide different services based on the context of user’s contacts. An

“active” contact services shall support notifications or warnings if a call or

message is initiated and further provide call reminder service.

Event scheduling shall be supported only between passive users (context is not

Driving).

Server shall not maintain any location history of users.

Server shall enable C2DM based message exchange between clients via C2DM

server.

4.3. System Architecture Components

The end to end real-time realization of the idea is as outlined in figure 4.1. The platform

for enablement of context aware services presented here is 3-tier architecture with data,

presentation and Logic layers -

Data layer is implemented on both the clients (SQLite) and the server (Simple

Db).

Presentation layer is implemented on the Android Clients

25

Logic layer is split across the end device and the centralized application server

We have utilized the Google Cloud to Device Messaging Framework for Push service for

enabling communication between clients via the application server instance running on

AWS.

Figure 4.1. CADD System Design

4.3.1. Android Clients

4.3.1.1. Android System Architecture

Android operating system is built on Linux 2.6 version optimized for mobile

performance. The internals of Android software architecture is as shown in figure 4.2.

This section provides a summary of Android Architecture available in the App

Framework section on android.com [9].

26

a. Applications

This layer refers to various application shipped with Android OS, includes applications

such as Calendar, contacts, browser, email client, maps etc. which provide the

fundamental functionalities. All applications utilize Java programming language. New set

of applications to perform other tasks can be added at this layer by the application

developer.

Figure 4.2. Simplified Android architecture

b. Application Framework

This component provides the framework to enable new applications to be built. It

includes rich and extensible set of Views such as buttons, grids, lists, text boxes, and

search boxes and also an embedded web browser that in building user interface for an

application. Further, also includes rich API (s) to utilize various sensors, such as Location

Manager to enable GPS related services. There are also content providers that enable data

share across applications; Resource Manager, providing access to non-code resources

http://developer.android.com/guide/topics/resources/resources-i18n.html

27

such as localized strings, graphics, and layout files and Activity Manager which takes

care of lifecycle of applications and provides a common navigation back stack.

c. Android Runtime

Dalvik is the virtual machine that runs application code written in Java and device using

Dalvik can run multiple Virtual Machines efficiently. The Dalvik Virtual Machine (VM)

executes files in the Dalvik Executable (.dex) format which is optimized for minimal

memory footprint. The VM is register-based, and runs classes compiled by a Java

language compiler that have been transformed into the .dex format by the included "dx"

tool. The Dalvik VM relies on the Linux 2.6 kernel for underlying functionality such as

threading and low-level memory management.

d. Libraries

Android comes with a set of libraries written in C/C++ such as LibWebCore, System C

library , media libraries , SQLite, etc. These are exposed to developers though Android

application framework.

e. Linux Kernel

The kernel also acts as an abstraction layer between the hardware and the rest of the

software stack. Android relies on Linux version 2.6 for core system services such as

security, memory management, process management, network stack, and driver model.

4.3.1.2. Sensors – GPS / Bluetooth / Accelerometer

The solution aims to utilize the advancements in the on-board sensors available as a part

of smart phones hardware. We mainly utilize the GPS and Bluetooth sensors to derive

http://developer.android.com/reference/android/app/Activity.html

28

context and location -related data. This could also be extended to include accelerometers

and gyroscope for improved accuracy.

4.3.1.3. Android Application components

In this section we summarize the concepts relevant to our system, provided under

Application Fundamentals on android.com [9] and also understand their significance in

this project.

a. Activities

Any application with a user interface is implemented using Activity, which is a single

focused thing a user can do. Activity creates a window to place the user interface using

setcontextView (View) operation. Activities in system are managed using the “activity

stack”. When a new activity is started it becomes the running activity and is placed above

the precious activity.

Activity is associated with four states:

Active/ Running

If an activity is at the top of the stack, it is said to be active or running.

Paused

An activity that has lost focus but is still visible and alive is said to be paused. It

maintains all state and member information and remains attached to the window

manager, but can be killed by the system in extreme low memory situations.

Stopped

If an activity is completely obscured by another activity while retaining all state and

member information but no longer visible to user (window is hidden), it is said to be

stopped. This also may be killed when memory is required elsewhere.

29

Restart

An activity is restarted after the system drops the activity from memory by asking it to

finish or simply killed. It is restored to its previous state.

All the user interfaces in our design implement the various stages of life cycle of Activity

which begins with onCreate( ) binding the user interface window and then goes onto

onStart( ). The onStop( ) and onPause( ) may be called multiple times during user

operations. onFinish( ) is called to force the activity to release the resources.

b. Service

Service is an Android application component used to perform time-consuming operations

in background without an associated font end or user interface. Another application

component such as activity can start service that will continue to run in background even

when user switched to another application. Service also supports inter-process

communication using bind.

In our application we have utilized service to perform long operations such as HTTP

based RESTful queries and also to update location related information in the context of

event driven sharing.

c. Content providers

In Android data sources are encapsulated through a concept called "content providers".

This encapsulation is responsible for both retrieving data and also storing data. The

available data storage/access mechanisms in Android and used as a part of our

application are -

30

Preferences: A set of key value pairs that can be persisted to store application

preferences. This is used to enable global data share across activities such as user id and

status in our application.

SQLite: SQLite database. Each database is private to the package that creates that

database. We have utilized database for storing user information such as contacts and

event schedules.

Content Providers: An inter application data sharing facility. The access to a

ContentProvider is done via an URI. In our application they are used in extracting data

related to user contacts.

d. Broadcast receivers

An Android application may be launched to process an element of data or respond to an

event, such as the receipt of a text messages. In our application we have employed

broadcast receivers to enable the C2DM message reception and also for Bluetooth based

context detection. We have also deployed customized broadcasts receivers using custom

intents.

More information on these components can be found at Android.com under developer’s

guide.

4.3.2. Google Cloud to Device Messaging Framework

4.3.2.1. Purpose

C2DM provides the Push service required for light weight end to end message exchange.

It must be noted that this service is specifically used with Android clients. The solution

out-lined follows a producer-consumer message exchange. Active users are the

producers of information such as context or location information and passive users are

31

the consumers of this data. For data communication between these entities we have the

classical poll and push scheme available.

Polling involves repeated timed queries to check availability of new data. This scheme is

known to be tedious and as with high battery efficiency requirements of clients we shift

our focus to Push service.

In contrast to polling, push service enables new data to be pushed to consumers as and

when new data is available. This can be accomplished using the C2DM service in

combination with Intents on Android devices.

4.3.2.2. C2DM Internals

Figure 4.3. Google Cloud to Device Messaging Framework

The end to end messages flow in the C2DM framework is as outlined in figure 4.3 and

summarizes the essentials as covered in the overview of the C2DM technology [11].

32

4.3.2.3. Usage

Each of the devices with this application must register with the C2DM service using

white-listed email id associated with the device.

They obtain a registration Id from C2DM server unique to the device, user mail ID and

application instance, which is then be used to identify the application to be invoked after

reception of C2DM Broadcast.

This registration id is pushed to 3rd

party application server to be utilized in enabling

communication between end clients via the C2DM server.

End device implements a broadcast receiver to enable reception of messages.

4.3.3. Android Class Design

The Android classes are designed keeping the classes organized in packages as in figure

4.4. Each of the packages refers to distinct functionality of the application.

Sensor data management includes background services that are invoked through

broadcasts/ intents that are used for context detection and event driven data share.

Bluetooth is used for context detection and GPS and Network Provider based

updates are used for event driven share to provide the proximity information.

User Interaction Management includes the user interfaces and activities

associated that enable users to view data or enable/disable services. These

interfaces enable users to access the user operations listed in User operations

package. As part of context aware services, we have classes that may start or

stop associated service, enable services such as changing the mode of the phone to

silent, handling notifications, enabling alarms if requested by user. It also includes

33

the event driven location share if there are any active events scheduled by starting

the Location service.

C2DMhelpers are used to handle C2DM Push messages. They support C2DM

device registration, C2DM message reception and handling. Maximum of

1024Bytes is supported length of C2DM message.

Auto services provide the automatic registration of client with C2DM service and

handle automated operations such as Bluetooth based context detection and event

driven location share.

Database helper serves as common interface for database related operations such

as storing user credentials, user contact lists, pending notifications and

maintaining list of events. The storage is performed on client based SQLite as

well as AWS Simple DB.

HttpHelper enables communication between client and AWS server through

HTTP based request/response scheme.

AWS Logger class shall help in collecting user statistics to improve user

interaction capabilities and also to assist in user experience study, without

exposing the user data to third party statistics collector such as Google Analytics

[28].

34

Figure 4.4. Android packages and classes

4.3.4. Amazon Web Services

AWS is the cloud infrastructure by AMAZON Web Services [10]. In our application we

have utilized two services from the AWS namely, elastic bean stalk and Simple DB.

Elastic Beanstalk enables deployment of application server we designed to enable Restful

interaction with Android clients. We utilize Simple DB for user data management. The

diagram above shows the AWS Elastic Beanstalk architecture. As outlined in the

overview in the AWS documentation [26] shown in figure 4.5, AWS Elastic Beanstalk

resources created per environment include one elastic load balancer, auto scaling group

and one or more Amazon EC2 instances. Security group shown defines the firewall rules

for the instances. By default it allows everyone to connect via port 80 (HTTP). AWS

Availability Zones are designed to be physically distinct, fail independently, and be

35

reliable. Every environment has a CNAME that points to the load balancer. Load

balancer sits in front of the Amazon EC2 instances, which are part of an Auto Scaling

group. Scaling automatically starts additional Amazon EC2 instances to accommodate

increasing load on the application. This is particularly useful functionality to auto-scale

when the number of clients to be served by the system increases.

Figure 4.5. AWS Application Server

4.3.4.1. Back-end Server Design

For effective communication between user devices, we employ a third party application

server on AWS , which shall enable communication between end user devices via Google

Cloud to Device Messaging framework. This section will cover the details of server

design and deployment in the scope of this project.

We have utilized the server for two important reasons:

It serves as a point of communication between device and C2DM server, by storing

the registration details of various devices with C2DM service.

36

It provides a centralized database (Simple DB) for user data storage and

management

a. Servlets

The interaction between server and client is via the REST interface. This is accomplished

using the HTTP based request/response scheme built using the Servlet technology. The

life-cycle of the servlet is as outlined in figure 4.6 and follows the following sequence of

events-

HTTP requests (URL/API based request from clients) that arrive at the AWS server

are directed to the appropriate servlet container.

Servlet container loads the servlet and then the service() method inside the servlet

is invoked.

A servlet container is designed to handle requests from multiple clients and hence

spawns multiple threads, each thread to execute service() method of single

instance of servlet.

37

Figure 4.6 Servlet architecture

The Servlets are grouped into various packages as in figure 4.7. Few Servlets provide

services to client request such as Registration Servlet, Context update servlet etc., under

the User interaction package, whereas other Servlets such as DriveSafeDB Servlet ,

Google Map Servlet, SendMessage servlet are Generic Servlets utilized only by other

Servlets internal to server and do not serve client requests.

38

Figure 4.7. Servlet packages and classes

User interaction includes Servlets that serve client requests. They are invoked by

using HTTP based requests from clients. Registration Servlet supports

registration, de-registration and isregistered look-up operations. Upon receiving a

registration request, it stores the user ID is hashed format and C2DM registration

ID received from the client, to be used later for broadcast using C2DM Push

service. Context update Servlet handles context update requests from clients.

Upon receiving a context update, the new context is updated and broadcast to all

the contacts on user’s friend list, by invoking C2DM Push service to each of these

clients. Adding friends and event scheduling follow the request/response format

and the respective Servlets enable interaction between clients involved by pushing

messages via C2DM Push service. A user can also explicitly request context

updates via the retrieve servlet invocation. Location Updates servlet refreshes the

latitude and longitude information of the client updating its location. It must be

39

noted that we do not maintain history of location updates from any client to

ensure privacy of user.

Database package has two types of storage namely Simple DB (persistent) and

data structure based storage that enables faster look-up while the server is active.

Google Maps Interaction is used in case of event scheduled data sharing between

clients, to query the time and distance data from Google server and uses the

C2DM Push service to send the data to clients.

4.4. Specs

The various entities and their specifications used in this architecture implementation are

as listed below :

• Android Client specifications

– Context detection : API level 17 and up (Android 4.2)

– Context aware services : API level 12 and up (Android 4.0)

• C2DM service requirements

– White-listed mail ID

– Android 2.2 and up with Google account on phone

– Android 4.0.4 and up w/o Google account

• Server specifications

– EC2 instance with Linux/Tomcat 6.0

– Simple DB service

40

4.5. System Features Implementation

The central functionalities of the system include context detection and share, event based

privacy driven location share. In this section we cover these central functionalities in

detail.

4.5.1. Context Detection and context aware services

We utilize the Android Bluetooth functionalities to extract the user’s context information.

Bluetooth on device is first paired with the vehicle Bluetooth, then subsequently utilized

to detect context. This process is enabled using listeners for active connection detection.

Listeners are utilized and hence the method is optimal as opposed to polling for

connections.

Upon context detection, contact aware services are activated for the user, without user

intervention.

Active user services: User’s status (or context) is set to “driving” and this data is pushed

to application server. Application server shares this context update with user’s contact

list. If there are any active events scheduled, location update service is initiated.

Passive user services: Each of the passive users on active user’s contacts receives an

update about status. Then services such as warn before call, call reminders are made

available to the passive user.

4.5.2. Privacy Driven location Sharing - implementation

This feature is designed to achieve higher acceptance probability of the solution and

mainly to help users attain location aware services without loss of privacy.

Two passive users can schedule an event. Event duration determines the location related

share duration between the two entities.

41

If one of the passive users changes to an active user and has an event scheduled, then

location updates are triggered.

Now, these location updates are utilized in providing passive user with proximity metrics.

As opposed to plainly exposing the geo location co-ordinates as in other applications

[20], we determine the approximate time and distance metrics using Google Map APIs

[27].

Figure 4.8. Privacy-driven Location Sharing

As shown in figure 4.8, a passive user can view information related to active user's

(username: nexus) proximity.

A screen shot of data displayed to passive user is as shown in the UI in figure 4.9.

42

Figure 4.9. User interface displaying proximity data

4.5.3. End to end system usage

The end to end usage of the system is as shown in figure 4.10. An active user ALICE's

status is detected to be "Driving" and shared with all contacts via AWS and Google

C2DM Push service. It also shows the realization of event based data sharing, where

Alice is sharing data with family and the location metrics are namely distance and time.

43

Figure 4.10. End to end application design

4.6. End to End Message Flows

The important message flows pertaining to four important services are covered in this

section namely, registration, context update/share, event scheduling and location share.

4.6.1. End device registration

Once the application is installed on an Android device with API level 17, the first

operation performed is registration figure 4.11. Registration refers to subscription to

C2DM service. A white-listed Google mail ID associated with the device, unique device

ID and application instance identifier set is sent to C2DM server and the C2DM

registration token is received. The application server also registers with C2DM service

and receives authentication ID. To enable communication between various registered

devices, we require the application server (AWS Server) to store the user ID [hash (mail

ID)] and associated C2DM registration ID.

44

Figure 4.11. Registration Message Flow

4.6.2. Context update

Context update is central functionality of the system. Once the devices have registered

with C2DM service and updated application server, they can add users to their "C2DM-

registered-contacts" lists. We have utilized Bluetooth trigger to detect context in our

application. The device Bluetooth is paired with car Bluetooth to begin with. When an

active connection is detected, the context of user is automatically updated to "Driving"

and this update is sent to AWS Server, which enables share with other C2DM registered

contacts on user's contact list. The sequence of messages exchanged is shown in figure

4.12. Similarly, when the connection is terminated, context is updated to previous known

state, and update is sent to all contacts via AWS Server.

45

Figure 4.12. Context/User status update

4.6.3. Event scheduling

Event schedule is also one of the important services provided. It enables location related

data share between two entities involved for a known duration. The two parties involved

shall exchange request/response to schedule the duration of share. According to the

schedule of share, location services are enabled and disabled automatically using preset

timers and end to end messages sequence is as shown in figure 4.13.

46

Figure 4.13. Event scheduling end to end flow

4.6.4. Proximity Data Sharing

Proximity data share refers to the pre-scheduled event related location information

sharing between two clients. It requires the two clients involved to automatically

send the location updates, that shall be utilized in proximity calculation on server

and data is made available to clients via Google C2DM server Push service as

shown in figure 4.14.

47

Figure 4.14. Data share between two clients

48

Chapter 05

Design Optimizations

We have covered the overall system design and the end to end message flow and

communication in the previous chapter. As mentioned earlier, we have designed the

system iteratively, based on user usage results. In this chapter we cover the various usage

scenarios, results obtained and the optimizations designed to address issues pertaining to

each of these.

5.1. Network connectivity and context updates

One of the central functionalities of the system is the context share operation. This has

been implemented with RESTful communication between client and server that requires

active network connectivity. With mobile clients being the end-devices, we observed

varying levels of connectivity owing to the fluctuating network connection and

conditions as seen in figure 5.1. Data for clients under test run is as shown in the figure

5.2.

Figure 5.1. Network connection fluctuations on a client

49

Figure 5.2. Network connectivity and context updates

On an average due to fluctuating connectivity, we observed that over 50% or more of the

context updates failed. Also, when there is low connectivity, there are cases of complete

network connectivity failure for a given duration.

To improve the performance and support reliable context updates we have optimized the

context update implementation on the Android client via (as outlined in figure 5.3):

triple re-transmissions to help with fluctuating connectivity

Piggy-back the context update till active network connection is detected. Auto-

monitoring the device network connectivity status to detect active connection and

update context. This is designed to help in case of network disconnection where

triple retries fail.

50

Figure 5.3. Network connectivity optimized context updates

5.2. Location updates

GPS location updates are triggered from the device when there is an active event

scheduled in the solution presented. This is also an automated operation and hence

requires high reliability.

As the system design target two class of users can be involved in event driven data

sharing:

Active users - user are who are out-door driving and

51

Passive users - users who are not currently driving, a high probability of being

indoor.

Hence, addressing the issue of deriving location fix in indoor environment is a

requirement.

During our experiments both coarse and fine location updates were tested. A sample set

has been plotted below in figure 5.4. GPS based provider was observed to have cold start

of location updates, refers to the initial delay in providing fix, once the provider is

initialized and also is known to be limited to out-door updates. Hence, we utilize an

approximate fix using the coarse network updates based on WiFi or network cell-id to

begin the location updates that helps incase of passive users.

Figure 5.4. GPS and Network triggered location updates

52

Figure 5.5(a) Accuracy of GPS and (b) Network obtained location data

Experiments were performed to compare latency incurred in obtaining location fix using

only GPS provider based and only Network provider based updates. An application that

implements each of these providers separately was used to request location updates. The

time duration between request and instant at which location fix is obtained is calculated

in each of these cases. The process of location fix request is repeated across various

locations.

Figure 5.6. Latency incurred in initial fix query

53

Based on our study we observed that

Fine-grained location provider like the GPS provider we achieve location updates

with an accuracy of less than 100 m up-to as fine as 1m as in figure 5.5(a), but

unavailable in in-door locations.

Coarse-grained location provider like the network location provider we achieve an

accuracy of 20– 1000 m, useful when GPS based updates are not available, an

approximate location to start off with, but must be limited by deviation from

actual location.

Even with network provider updates, we observe a location fix outliers beyond 1-

mile radius in few experiments figure 5.5(b).

Based on these results shown in figure 5.6, in our implementation we support both GPS

as well as network provider for location updates. With approximate initial fix we start the

location service with reduced latency as in figure 5.7, while limiting the path-deviation to

be within the threshold set (~1000m).

54

Figure 5.7. Location service algorithm

The results of the performance improvements of these optimizations shall be covered as

part of the next chapter.

55

Chapter 06

Test and Results

This chapter covers the test scenarios and the usage results comparing various versions of

the application. We particularly compare the performance of various functionalities with

optimizations detailed in the previous chapter that are implemented as part of various

versions of the application.

6.1. Features Supported across versions

Application has had three major releases and the main functionalities supported and

tested in each of these versions are summarized in table 6.1 below.

Feature Version 1.0 Version 2.0 Version 3.0

Dashboard pattern X X

Auto Registration X(manual)

Auto context detection X(manual)

Triple re-transmission for context updates X

Network connectivity based piggy context updates X X

Auto-refresh contact list view X

Location share manual override X X

56

Auto enabled location share for events

GPS provider based location updates

Network provider based location updates X

Auto refresh proximity data X

Auto refresh contact profile view screen X

Auto refresh optimization X X

Table 6.1. Features and application versions

6.2. Context updates - reliability

6.2.1. Test Setup

A daemon service that runs on client was implemented that pumps http based status

updates to server every 2.5 seconds. This daemon app is implemented for each of the

versions, version1.0 - without any retries, version 2.0 with triple retries and version 3.0

with triple retransmission and network connectivity monitored piggy updates. The

various network modes used for testing are as tabulated in table 6.2.

Location Test mode

WINLAB 3G only

Rutgers Student center 3G with intermittent WiFi

Home 3G with active WiFi

Table 6.2. Various test locations and connection modes

57

We compared the success rate of context updates sent on 3client models with varying

levels of network connectivity, across different version of the application, figure 6.2. It is

seen that version 1.0 with no reliability optimization, more than 50% of the context

updates were dropped. With version 2.0, with triple re-transmissions we improved the

success rate as compared to version1.0, beneficial in case of flakey data connection.

However, with version 3.0, and network connectivity based piggy context updates

ensured greater than 90% context updates provided there was network connectivity

restored at the device before another context update is detected.

In client 01 and client03 there were few context updates that are not transmitted in

version 3.0, owing to the complete network connectivity loss and multiple context

switches during the no-network duration. Since, only the last change shall be updated as

part of piggy update there are few updates that are dropped when there is completely no

connectivity in device accompanied by multiple context switches.

58

Figure 6.1. Context updates success rate against app version

6.3. Initial Location Fix and latency

Event drive data share uses location information of users for a given duration. We have

addressed the issue with indoor location updates and also reduced the time taken to attain

the first fix by combining the GPS as well as Network provider updates in version 2.0

and version 3.0 of the application.

6.3.1. Test Set up

A sample application with the two versions of location retrieval was implemented and the

location retrieval was manually done using the application at specific locations. The

difference in time duration between the location fix request and the time location fix is

obtained is noted for each trial and for each of the versions of application. The data is

59

accumulated for various locations across Rutgers University campus, with multiple data

samples averaged over five trials at each location.

Various test locations used are:

– Indoor locations

• GPS provider based fix fails

– Rutgers student centers – active WiFi

• Least time in obtaining fix

– On-campus buses - active 3G

• These network provider based updates take higher time in

obtaining fix than WiFi based network provider updates

In application version 1.0 we used only GPS provider and hence the higher latency as

compared to version 2.0 and version 3.0 with as in figure 6.3.

Figure 6.2. Initial Location Fix delay

Network provider updates use cell and/ Wi-Fi to calculate the approximate location fix

and take lesser time (< 1 second in most cases) whereas GPS based updates take more

than 4 seconds.

60

Chapter 07

Conclusion and Future Work

The main contributions of this work are optimized and privacy driven scheme for mobile-

device based user location usage, a novel algorithm to improve reliability in attaining

automated services that demand data connectivity, critical for building automated

services on mobile devices that are known to have varying levels of connectivity and

lastly end-user interaction improvements by iterative user interface design. The system

design satisfies the design goals covered in Chapter 03 and the highlights are as listed

below:

• Design attains user-centric context aware services

– attains a middle-ground in attaining distraction-free driving

• Realization of privacy controlled location share scheme

• Demonstrates efficient communication scheme between entities

• Successfully designed a platform to deploy reliable automated services

– Improved the reliability from a success rate less than 50% to greater than

90%.

• Ensured location fix updates indoors

– Also, reduced the latency of obtaining first location fix from few seconds

> 4seconds) to less than a second (~500-800msec) with a deviation in path

limited to 500-1000m.

Further, this system mainly targeted the calls/messages based distraction mitigation. We

would like to add that, with the context information pertaining to registered user IDs

available via HTTP based API(s), it may be beneficial to make this context information

61

of the user available to ‘friends’ on social networking sites, to mitigate the distraction

caused by these as well.

This framework may also be easily utilized with other context aware solutions like [29]

and [30] to provide reliable automated services and communication framework between

clients.

As covered earlier there has been a solution by ATT Labs [20] aimed at mitigation of in-

vehicle distraction, allows the parents of the teenage drivers to control their phone

options while driving. Although it aims to attain distraction free driving, owing to the

privacy concerns of teenage drivers (users), we believe that it may receive lower

acceptance probability. With our design we have provided a distraction mitigation service

at reduced risk of privacy by utilizing proximity metrics for location sharing and also

providing the user with flexibility to limit the feature usage to a duration fixed by event

scheduling.

7.1. Future Work

We have utilized the Bluetooth based context detection. As a part of enhancements we

want to combine the data of various sensors to design an algorithm for context detection

as well as state detection such as moving / currently in traffic.

System already supports loggers for user activity that we plan to utilize and perform user-

experience study to understand the acceptance probability of the solution and also the

distraction-level mitigation achieved. We would also like to integrate this system with

other social networking applications [25], to ensure safety by informing user's contacts

about the context of the user on the social networking circle.

62

REFERENCES

[1]. Annual Attributable Risk Estimate for the year 2011, National Safety Council

announcement:http://www.nsc.org/Pages/NSCestimates16millioncrashescausedbydri

versusingcellphonesandtexting.aspx

[2]. Strayer, David L., and Frank A. Drews. “Cell-phone-induced driver distraction.”,

Current Directions in Psychological Science (2007).

[3]. Hands-free Laws : http://www.handsfreecellphonelaw.com/

[4]. Strayer, David L., Frank A. Drews, and William A. Johnston. "Cell phone-induced

failures of visual attention during simulated driving." Journal of experimental

psychology: Applied 9.1 (2003): 23.

[5]. William J. Horrey and Christopher D. Wickens. “Examining the Impact of Cell

Phone Conversations on Driving Using Meta-Analytic Techniques Human Factors"

The Journal of the Human Factors and Ergonomics Society.Spring 2006 48: 196-

205

[6]. http://blogs.strategyanalytics.com/WDS/post/2012/10/17/Worldwide-Smartphone-

Population-Tops-1-Billion-in-Q3-2012.aspx

[7]. Chen, Guanling, and David Kotz. “A survey of context-aware mobile computing

research.” Vol. 1. No. 2.1. Technical Report TR2000-381, Dept. of Computer

Science, Dartmouth College, 2000.

[8]. Lindqvist, Janne, and Jason Hong. "Undistracted driving: A mobile phone that

doesn't distract.” Proceedings of the 12th Workshop on Mobile Computing Systems

and Applications. ACM, (2011).

[9]. Android resources : http://www.android.com/

[10]. Amazon Web Services : http://aws.amazon.com/

[11]. Google Cloud to Device Messaging : https://developers.google.com/android/c2dm/

[12]. Barkhuus, Louise, and Anind Dey. "Location-based services for mobile telephony:

A study of user’s privacy concerns." Proc. Interact. Vol. 2003. 2003.

[13]. Distracted Driving Statistics and Information : http://www.distraction.gov/

[14]. National Conference of State Legislatures. "Along for the Ride: Reducing Driver

Distractions." Denver, Colo.: NCSL, March 2002.

[15]. McCartt, Anne T. "Cell phones and other driver distractions: Legislation,

regulation, and enforcement." Presentation given at the International Conference on

Distracted Driving Toronto, Canada. 2005.

[16]. ATT Campaign : http://www.att.com/gen/press-room?pid=2964

[17]. Hands-free devices and Laws : http://handsfreeinfo.com/

[18]. “Understanding the distracted brain- Why driving while using hands-free is a risky

behavior”, white paper , National Safety Council, April 2012

[19]. ZoomSafer Application : http://info.aegismobility.com/aegis-mobility-acquires-

zoomsafer

[20]. ATT Application : http://www.att.com/gen/press-room?pid=22682

[21]. Yang, Jie, et al. "Detecting driver phone use leveraging car speakers. “Proceedings

of the 17th annual international conference on Mobile computing and networking.

ACM, 2011.

[22]. On-board OBD: http://www.cravenspeed.com/bluetooth-obdii-connector/

[23]. Foursquare Application : https://foursquare.com/k

http://www.nsc.org/Pages/NSCestimates16millioncrashescausedbydriversusingcellphonesandtexting.aspx

http://www.nsc.org/Pages/NSCestimates16millioncrashescausedbydriversusingcellphonesandtexting.aspx

http://www.handsfreecellphonelaw.com/

http://blogs.strategyanalytics.com/WDS/post/2012/10/17/Worldwide-Smartphone-Population-Tops-1-Billion-in-Q3-2012.aspx

http://blogs.strategyanalytics.com/WDS/post/2012/10/17/Worldwide-Smartphone-Population-Tops-1-Billion-in-Q3-2012.aspx

http://www.android.com/

http://aws.amazon.com/

https://developers.google.com/android/c2dm/

http://www.distraction.gov/content/get-the-facts/state%20laws.html

http://www.att.com/gen/press-room?pid=2964

http://handsfreeinfo.com/

http://www.att.com/gen/press-room?pid=22682

http://www.cravenspeed.com/bluetooth-obdii-connector/

https://foursquare.com/k

63

[24]. Google Latitude Application: http://www.google.com/latitude/api.html

[25]. Facebook application : http://developers.facebook.com

[26]. AWS Elasticbeanstalk : http://aws.amazon.com/elasticbeanstalk/

[27]. Google Maps API : https://developers.google.com/maps/

[28]. Google analytics : http://www.google.com/analytics/features/index.html

[29]. Context Awareness Activity Recognition Application :

http://www.intel.com/content/www/us/en/research/intel-labs-context-awareness-

activity-recognition.html

[30]. http://www.intel.com/content/www/us/en/research/intel-labs-context-awareness-

social-proximity-detection.html

http://www.google.com/latitude/api.html

http://developers.facebook.com/

http://aws.amazon.com/elasticbeanstalk/

https://developers.google.com/maps/

http://www.google.com/analytics/features/index.html

http://www.intel.com/content/www/us/en/research/intel-labs-context-awareness-activity-recognition.html

http://www.intel.com/content/www/us/en/research/intel-labs-context-awareness-activity-recognition.html

http://www.intel.com/content/www/us/en/research/intel-labs-context-awareness-social-proximity-detection.html

http://www.intel.com/content/www/us/en/research/intel-labs-context-awareness-social-proximity-detection.html

CADD : Context Awareness for ... - Rutgers University

Documents

Transcript of CADD : Context Awareness for ... - Rutgers University