collaborative joins in a pervasive computing environment

Center for E-Business TechnologySeoul National University

Seoul, Korea

Collaborative joins in a pervasive computing environment

Filip Perich, Anupam Joshi, Yelena Yesha, Tim FininThe VLDB Journal (2005)

2008. 11. 17.

Summarized & presented by Babar Tareen,

IDS Lab., Seoul National University

Copyright 2008 by CEBT

Introduction

To obtains data

Devices should not solely depend on centralized servers

Devices should not be required to pre-cache all required data

A device should utilize its vicinity by collaborating with peers

2


Introduction (2)

Data

Static – User Profile

Dynamic – Context Sensitive Data

– Data which is affected by change in context

– Not the actual context data

– For example: List of restaurants near to a user

In this paper, context also includes

Belief, Desire, Intentions

Stored in user profile

Based on MoGATU

3


Contribution

Collaborative Query Protocol (CQP)

Based on Contract Nets

Enables a mobile device to query its vicinity for peers that can answer a given query

Allows two or more devices to cooperate

A realistic experimental model for simulating a city traffic scenario

Demonstrate the capability of CQP by implementing it in MoGATU and by evaluating its performance

4


MoGATU Overview

Information Providers

Represent Data sources available in environment

Information Consumers

Entity that query an update data available in the environment

Information Managers (InforMa)

Responsible for network communication and for most of the data management functions

5


Data Representation

Data Model

A set of ontologies

Define ontologies using DAML+OIL

Using ontologies because of reasoning

Do not take into account the time necessary for reasoning over the ontology knowledge

6


Query Representation

Explicit Query

User generated query

Implicit Query

Device generated query, inferred from user profile

User takes lunch between 12:00 pm – 2:00 pm and prefers Chinese food

Queries are specified in DAML-S

For this paper, abstracting queries to select-from-where form

query = (O, σ, θ,Σ, τ)

O : A set of used ontologies

σ : Selection list

θ : Filtering statement

Σ : Cardianality

τ: Temporal constraints

7

SELECT (select_list)FROM (ontology_list)WHERE (conjunct_disjunct_predicate_list)LIMIT [minCardinality, maxCardinality]TIME neededBy


CQP

8


CQP (2)

Call for query

Initially device attempts to satisfy query using local cache

If not possible, creates a call-for-query message

Message contains

– Query or part of query

– Cardinality requirements

– Deadline for delivering the complete answer

– Time when the winner will be announced

Device sends the message to its peers upto n-hops

And Starts its bid-submission timer

If device does not gets any bid-submission response then it starts to decompose the query

9


CQP (3)

Bid Submission (Upon receipt of call-for-query)

A device decides if it should interact in the proposed collaboration based on inference

If device does not wishes to participate or can not provide data, it simply ignores call-for-query

If device wishes to collaborate then it calculates the size of the answer it can provide

Returns bid message including estimated size of its answer

Starts a timer awaiting a bid-award

Bid Award

Contractor waits for a predefined time period for any responses

When bid submission timer expires, the bidder which claims to deliver the most data in shortest time is selected as winner

Contractor sends a bid award message

Starts Ack Timer

If a bidder does not receives a bid-award message before its timer expires, the bidder resend its bid message n-1 more times

10


CQP (4)

Acknowledgement

When the bidder receives bid award message it sends back an ack message

Starts an Ack timmer and waits for ack from Contractor

When contractor receives ack from Bidder it send ack message

11


Join Query over two streams

In case 1, querying device A asks its vicinity for one input stream only since it already holds the second stream.

In case 2, A asks its vicinity for the final join result only.

In case 3, A asks for each stream separately in order to perform the join locally.

In case 4, A asks B to process the query, but B needs to first obtain the second stream from some other device C.

In case 5, A “delegates” the task to C, which asks its vicinity for the input streams instead.

12


Experimental Setup

Environment

Realistic model that mapped streets and intersections south of 72nd Street in Manhattan

Directed graph with 793 intersections (vertices)

5000 x 9000 m

Each intersection was assigned an (x,y) coordinate

Each intersection was given a list of its neighboring intersections

Beacon entity

Assigned a stationary beacon to each intersection

Each beacon has knowledge about its vicinity (Resturants, Theaters, etc)

13


Experimental Setup (2)

Car entity

Use 100 cars

Transmission distance 125 m

Maximum throughput 2 Mbps

Mobility model

Car driven randomly by tourists (50 Cars)

Car driven by taxi driver on shortest possible route (50 Cars)

14


Profile accuracy vs Query success rate

Fig 7a,b.

a: Willingness to help = 0%

b: Willingness to help = 75%

15


Profile accuracy vs Computing Cost

16

Implicit Queries


Willingness to help vs query success rate

17

Profile Accuracy 80%


Willingness to help vs. computing and network cost

18



Willingness to help vs. query success rate / computing cost

19



Review

Pros

CQP can be used to query data from multiple sources

CQP can be used in any environment not just mobile peer – peer scenario

Cons

CQP is not much useful if devices already have access to some fixed network

More on discussion slide

20


Discussion

Matrices used for evaluation are not appropriate

No comparison with any existing system with similar architecture

No comparison with centralized server architecture

Any technical problems in device – device communication not specified

In the example scenario, at every intersection beacons were installed

Cost of installing such beacons not specified

Enhancing centralized system vs. installing beacons

Only 100 cars were used in a space of 5000 x 9000 m

What will be the performance of the protocol if number of devices increase

Cost of ontology reasoning not considered

I think there is a lot of packet over head for query and this protocol might not be practically usable

A combination of server and peer-peer querying might give better results

21

collaborative joins in a pervasive computing environment

Documents