1 / 21

Collaborative joins in a pervasive computing environment

Filip Perich , Anupam Joshi, Yelena Yesha , Tim Finin The VLDB Journal (2005) 2008. 11. 17. Summarized & presented by Babar Tareen , IDS Lab., Seoul National University. Collaborative joins in a pervasive computing environment. Introduction. To obtains data

lundy
Télécharger la présentation

Collaborative joins in a pervasive computing environment

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. FilipPerich, Anupam Joshi, Yelena Yesha, Tim FininThe VLDB Journal (2005) 2008. 11. 17. Summarized & presented by Babar Tareen, IDS Lab., Seoul National University Collaborative joins in a pervasive computing environment

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. Query Representation SELECT (select_list) FROM (ontology_list) WHERE (conjunct_disjunct_predicate_list) LIMIT [minCardinality, maxCardinality] TIME neededBy • 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

  8. CQP

  9. 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

  10. 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

  11. CQP (4) • Acknowledgement • When the bidder receives bid award message it sends back an ack message • Starts an Acktimmer and waits for ack from Contractor • When contractor receives ack from Bidder it send ack message

  12. 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.

  13. 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)

  14. 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)

  15. Profile accuracy vs Query success rate • Fig 7a,b. • a: Willingness to help = 0% • b: Willingness to help = 75%

  16. Profile accuracy vs Computing Cost Implicit Queries

  17. Willingness to help vs query success rate Profile Accuracy 80%

  18. Willingness to help vs. computing and network cost Profile Accuracy 80%

  19. Willingness to help vs. query success rate / computing cost Profile Accuracy 80%

  20. 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

  21. 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

More Related