cssware: a middleware for scalable mobile crowd...

Ahmed Abdel Moamen and Nadeem Jamali

Agents Laboratory

Department of Computer Science

CSSWare: A Middleware for Scalable Mobile Crowd-Sourced Services

Nadeem Jamali Middleware for Scalable Crowd-Sourced Services 1

Growing ubiquity of connected personalcomputational devices

Multiple sensors on devices

Potential for services based on crowd-sourced data

Nadeem Jamali 2

Opportunity

Middleware for Scalable Crowd-Sourced Services

By “crowd-sourced,” we mean both:

Participatory sensing services

Crowdsensing services

A crowd-sourced service relies on thestate of the context in which data-contributing devices are located

Nadeem Jamali 3

Crowd-Sourced Services


Nadeem Jamali 4

Example: Restaurant Recommendation Service

. . . . . .

client

request

reply

Aggr


Nadeem Jamali 5

Example: Twitter-like Messaging Service

. . . . . .

Message 1

Message 2

Message n

. . .

Aggregation

Ob

serve

rs

Aggr


Many crowd-sourced services share acommon pattern of communication:

Messages sent autonomously by contributors Messages somehow aggregated to create a group

message

Nadeem Jamali 6

Communication in Crowd-Sourced Services

destination...

sender 1

sender 2

sender n

Ag

greg

ate


Two types of M -> N Communication

Single-Origin: One leader solicits support from other

potential senders

Multi-Origin: Senders autonomously send their

messages, which are then aggregated tocreate group messages

Nadeem Jamali 7

Multi-origin Communication

Requires Advance SetupMiddleware for Scalable Crowd-Sourced Services

Two ways:

One-off multi-origin communication

Continual multi-origin communication

Nadeem Jamali 8

Supporting Multi-Origin Communication

• Most examples of crowd-sourcedservices fit continual multi-origincommunication


Nadeem Jamali 9

Continual Multi-Origin Communication

requester

CommSetup

cond

cond

cond

coordinator sender 1 sender 2 sender n.... clock

event

event

event

P2

noyes

no

no

yes

yes

P1


Nadeem Jamali 10

Crowd-sourced services can be implemented usingmulti-origin communication

Solicit and receive multi-origin communicationsfrom a sensing crowd

Various types of clients: custom interfaces

Crowd-Sourced Services

service...

sen

sin

g c

row

d

interface

interface


The run-time system for CSSWare is organized intothree parts:

Service Platform

Contributor Side

Client Side

CSSWare Middleware


Service Platform


Event detector Event detection actors Filter

Optimizing sampling scheduler Sampling rate adaptation Sensor listeners

Contributor Side

ShareSens (Mobile Services 2015)

ModeSens(SPLASH 2015)


Custom interfaces for various types of clients Service view interface Service request API Request manager

Client Side


Server-side is implemented over CyberOrgs extension ofActor Architecture, a Java library implementation ofActors.

Middleware Implementation

Services

Operating System

CyberOrgs

CSSWare

. . .

7,473 lines of code


Contributor and client sides are implemented together asa self-contained application over CyberOrgs ported toAndroid.

Data from several sensors can be collected

High-level sensing events are defined in terms of low-level events

Middleware Implementation

4,622 lines of code

Between 7 and 18 lines of code to define high-level sensing event


We evaluated CSSWare for:

Programmability of new services

Performance, scalability and energy efficiencythrough experimental evaluation

Two example services are implemented as both servicesbuilt over CSSWare and as standalone services:

Restaurant recommendation service

Twitter-like messaging service

Evaluation


Nadeem Jamali 18

Example 1: Restaurant Recommendation Service

.......

restaurant 1

coordinatorcoordinator

restaurant n

service

requesterrequest

response


Nadeem Jamali 19

Example 2: Twitter-like Messaging Service

constituency

coordinatorcoordinator

constituency

service

requesterrequest

response


CSSWare offers orders of magnitude smaller size of codefor launching a new service

Two prototype services are implemented as both servicesbuilt over CSSWare and as standalone services:

Restaurant recommendation service

Twitter-like messaging service

Programmability

Service Standalone (LOC) CSSWare (LOC)

Restaurant recommendation 6,142 41

Twitter-like messaging 4,768 46


Restaurant Recommendation Servicevoid createSensorService() {

/* initialize service variables */

String placeList = "Restaurant1,52.1269,-

106.7618;

Restaurant2,52.1156,-106.5997; .......";

int aggrMethod = ServiceEnum.average;

int Default_SamplingRate =

SensorManager.SENSOR_DELAY_NORMAL;

/* defining sensors */

Sensor GPS = new Sensor (ServiceEnum.GPS,

Default_SamplingRate);

Sensor acc = new Sensor(

serviceEnum.accelerometer,Default_SamplingRate);

Sensor gyroscope = new Sensor(

ServiceEnum.gyroscope, Default_SamplingRate);

/* define a location service event */

ServiceEvent locationEvent = new ServiceEvent

(ServiceEnum.sensorEvent, new List<Sensor>()

{GPS}, new List<EventParam>(){

createParam("trigger",ServiceEnum.enterPlace),

createParam("trigger",ServiceEnum.departPlace),

createParam("placeList",placeList),

createParam("updateInterval",30),

createParam("output",ServiceEnum.visitTime),

});

/* define an activity service event */

ServiceEvent activityEvent = new ServiceEvent

(ServiceEnum.sensorEvent, new List<Sensor>(){

accelerometer,gyroscope},

new List<EventParam>(){

createParam("trigger",ServiceEnum.sitDown),

createParam("trigger",ServiceEnum.still),

createParam("stillTime",1),

createParam("output",ServiceEnum.waitingTime),

});

/* create and launch the service */

CrowdService service = new CrowdService(title,

description, new List<ServiceEvent>()

{locationEvent, activityEvent}, aggrMethod);

service.launch();

} // end createSensorService

Initialize service variables

Define sensors

Define a location service event

Define an activity service event

Create and launch the service


Methodology

Created and launched a set of instances of the restaurantrecommendation service

Service platform processing demand Measured the resources required to host a service

Contributor processing demand Measured the resources required of serving a service’s

request for contribution

Client processing demand Measured the resources required of accessing a service,

as well as the on-going costs of receiving updates

Performance and Scalability


Server Results

Processing costs of one-time service launching tasks andon-going tasks on the server side


Per-Event-Feed CPU Time (ms/feed)

Process an event feed 7.35

Local aggregation (O(1) cost) 0.024

Local aggregation (O(log n) cost) 0.078

Local aggregation (O(n) cost) 0.280

Local aggregation (O(n2) cost) 0.680

Global aggregation (10 Restaurants) 0.95

Total processing time (O(1) local aggregation)

8.325Server ran on a Windows 7 laptop (2.6GHz

quad-core i7, 8GB RAM)

One-Time Cost CPU Time (ms)

Create a service actor 13.04

Create a coordinator 11.67

Create a service view 7.84

Total processing time 32.55

Measured costs for aggregation functions of different complexities


Contributor and Client Results

Processing costs of one-time service launching tasks andon-going tasks on both the contributor and client sides,measured separately


One-Time Cost (ms) Per-Event-Feed (ms/feed)

Contributor 54.87 8.68

Client 35.53 60.9

Contributor/client app ran on a Samsung Note II (1.6GHz quad-core,

2GB RAM) running Android 5.1


Results Interpretation

For services requiring 1 feed per minute, this means

support for 7,202 and 6,912 services on our server and

mobile hardware, respectively

In a broader context, a server of our modest

configuration could process 288,288 diners’ data,

equivalently data for a city of about 720,720 people,

given: 40% of the population dines out at a meal time (2 hrs) Each diner's device is sending 3 events (arrival,

seating, departure) over the course of their meal



Methodology and Results

Measured the energy used by CSSWare and identicalstandalone services implemented without using CSSWare

The sampling scheduler improved energy consumption ofaccelerometer and gyroscope sensors by up to 24.60% and26.63%, respectively

Energy Consumption

Sensor Standalone (J) CSSWare (J)

Accelerometer 2.646 1.995

Gyroscope 14.653 10.751

The difference is explained by the order-of-magnitude larger overall energy

demand of the gyroscope sensor itselfNadeem Jamali Middleware for Scalable Crowd-Sourced Services 26

Methodology and Results

Overhead Analysis

Measured the energy consumed by the contributordevice side of the framework, albeit without the actualsensing

In percentage, the average energy consumed wasroughly 4% of the total energy consumed in theaccelerometer experiments, and 0.8% for thegyroscope sensor

Energy Consumption


Crowd-sourced services defined in terms of multi-origin communication

Actor-based design and implementation

Evaluation for programmability, performance and energy demand

Nadeem Jamali 28

Conclusions


Further simplify programming of services through web-based graphical interfaces

Coordinate division of mobile resources between multiple services contributed to by a mobile device

Clearly understand the class of services possible; identifying other classes of services and implementing underlying communication mechanisms

Nadeem Jamali 29

Future Work


cssware: a middleware for scalable mobile crowd...

Documents