Center for E-Business Technology Seoul National University Seoul, Korea Collaborative joins in a pervasive computing environment Filip Perich, Anupam Joshi, Yelena Yesha, Tim Finin The VLDB Journal (2005) 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

Copyright  2008 by CEBT 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

Copyright  2008 by CEBT 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

Copyright  2008 by CEBT 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

Copyright  2008 by CEBT 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

Copyright  2008 by CEBT 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

Copyright  2008 by CEBT 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

Copyright  2008 by CEBT 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

Copyright  2008 by CEBT 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

Copyright  2008 by CEBT 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

Copyright  2008 by CEBT Experimental Setup  Environment Realistic model that mapped streets and intersections south of 72 nd 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

Copyright  2008 by CEBT 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

Copyright  2008 by CEBT Profile accuracy vs Query success rate  Fig 7a,b. a: Willingness to help = 0% b: Willingness to help = 75% 15

Copyright  2008 by CEBT Profile accuracy vs Computing Cost 16 Implicit Queries

Copyright  2008 by CEBT Willingness to help vs query success rate 17 Profile Accuracy 80%

Copyright  2008 by CEBT Willingness to help vs. computing and network cost 18 Profile Accuracy 80%

Copyright  2008 by CEBT Willingness to help vs. query success rate / computing cost 19 Profile Accuracy 80%

Copyright  2008 by CEBT 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

Copyright  2008 by CEBT 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