1 / 18

Mobiscope: A Scalable Spatial Discovery Service for Mobile Network Resources

Mobiscope: A Scalable Spatial Discovery Service for Mobile Network Resources. Matthew Denny, M. J. Franklin, P. Castro, A. Purakayastha. Aug. 25. 2003 Seungwoo Kang. Problem. Increasingly surrounded by mobile objects that are connected to the network Cars, cell phones, PDAs

jessie
Download Presentation

Mobiscope: A Scalable Spatial Discovery Service for Mobile Network Resources

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. Mobiscope: A Scalable Spatial Discovery Service for Mobile Network Resources Matthew Denny, M. J. Franklin, P. Castro, A. Purakayastha Aug. 25. 2003 Seungwoo Kang

  2. Problem • Increasingly surrounded by mobile objects that are connected to the network • Cars, cell phones, PDAs • Need the discovery of mobile network resources keyed on position • Location-based service providers

  3. Solution approach • Mobiscope • Service for discovering moving network resources • Accepts ads from network resources containing position info. and queries for network resources within a specified spatial region • Position function • Returns a set of resources that are inside the region • Keeps the set current as resources move over time

  4. Related work • MODBMS • Position functions • Predict which objects will be within a given spatial region for some time interval • Two major limitations when position functions are rapidly changing • Not provide the correct semantics for Mobiscope queries • Derive future positions based only on ads that are currently stored by the MODBMS • Not scale to a large number of moving objects • Store position functions in a static, centralized database

  5. Features • Correct semantics • Run each new query over cached ads and then continuously over new incoming ads • Scalability • Distribute a set of directories in a network • Each directory has a spatial service region • Full reachability • Soft-state ads and queries • No expensive logging and recovery mechanisms

  6. Critique • Need a load balancing mechanism when ads or queries are skewed into some mds • I’m not sure that the simulation results are feasible

  7. Mobiscope components

  8. Mobiscope components • Directories (md) • Located throughout the network • Has a service region (SR) • Mobile resources (mr) • Sends advertisements to a md • Ads (UID, tExp, mr’s address, pos(position function)) • pos(t) -> (Xu,Yu), (Xl, Yl) • Sends new ad • when pos changes between tXmita and a.tExp • when a.tExp – Δ • Client • Sends queries • Q (rect, clients’ address, tExp, isRefresh) • Periodically send q refresh with a new tExp

  9. Mobiscope components

  10. Query Semantics • Query response • Find a set of (UID, network address) of mr currently in Q.rect • qra (UID, network address, tStart, tExp) • Run the query continuously over subsequent incoming ads • Two data structure for qr in client side • Maintain continuously updated result set of the query • A cache (t > qra.tStart) • A FRQ (future response queue) • FRQ -> cache • Current time t = t.Start field of the qr at the head of the queue

  11. Mobiscope distributed processing • Ad and query routing protocols ensure • All ads are routed to mds that can process them • Each Q is routed to a set of mds where mds’ SR contains Q.rect • Assume • Mr sends ads to a directory • Such that mr resides in the md’s SR at the time it sends its ad • Clients can submit a queries to any directory

  12. Query routing • Find a set of mds with SR that contain Q.rect • When a new Q comes into a md directly from client • Spatial routing table • (md ID, md address, SR, SR vn (version number)) • Each md has a routing table entry for every md • Cooridinator • Keep routing tables consistent • Use propagation of changes • Assumption • Md’s changes are not frequently -> no scalability problem

  13. Query routing • Processing refresh messages • Much more than new queries • Significant overhead to check all routing table entries • Query hashtable entry for a query received directly from client and routed to other mds • Key (client address + Q.rect) -> • Checks if vn of query hashtable entry is same with that of the corresponding routing table entry • If all of checks succeed, send refresh to mds listed in the entry md1, md1 vn md2, md2 vn md3, md3 vn

  14. Ad routing • Md use intersection and adjacency entries • More scalable routing • VDL (visitedDirList) • A list of directories that have already processed the ad • prohibit flooding • Md only sends an ad to a remote md if • Remote md is in the intersection or adjacency entry • Remote md’s SR intersects the ad’s pos for some time in the ad’s lifetime • Remote md is not already on the ad’s VDL

  15. Routing example

  16. Performance • Test the scalability and distribution model performance by simulation • 10 * 10 mi. area, paths 0.1 mi. apart • 1000 continuous queries initially running • 100000 mr • 10 new queries per min. • One refresh per min. • Wall clock time for one md to process all ads and queries in its entire workload

  17. Performance

  18. Performance

More Related