Cricket: Location- Support For Wireless Mobile Networks Presented By: Bill Cabral wcabral@cs.brown.edu Purpose To provide a means of localization for inbuilding, location-dependent applications Maintain the complete privacy of its users, by locating, not tracking them Keep the system decentralized and avoid explicit coordination between beacons, for easy deployment and maintenance Key Concerns Goals Privacy Managing administration overhead (system could get very large) Scalability (work with high node density) Indoor deployment issues (reflection, interference, dead spots, etc) Scalable and Decentralized Network Heterogeneity Low Cost Room-size Granularity
Metrics to Study Performance Hardware Precision how well can a listener detect a real or virtual boundary? Granularity how small can we make spaces, while maintaining the ability to detect boundaries with high precision? Accuracy the degree to which detected distance matches actual distance Statically placed beacons and static or mobile listeners Capable of both RF and Ultrasonic transmission/reception to infer distance RF alone performed poorly indoors Distance determined by measuring the time between receiving RF signal and Ultrasonic signal (based on speed sound travels through air) How It Works Beacon Transmits Waves Simultaneously RF and Ultrasonic signals are emitted simultaneously RF signal is received by listener, which turns on US receiver and begins processing RF message Ultrasound arrives as RF message is being processed, and listener uses the time between RF and US arrival to determine distance Determination of which beacon is closest is more important than actual distance
RF Signal Received, Processing Begins (US Antenna set to ON) US Signal Arrives, Distance is Calculated Difficulties Solution for Collision System is not coordinated, so signals from different beacons can get confused Listener receives RF from one, US from another, calculates wrong distance Reflection, leading to multipath effects Causes interference between direct and reflected signals, increased noise, etc Dealing with changes in transmission medium Temporal/Spatial changes in temperature and humidity (affects speed of sound waves) Beacons transmit at variable intervals, drawn from given distribution Avoids persistent collisions and repeated synchronization Choice for interval depends on number of beacons we expect to be within range of each other, message size and link bandwidth Collect multiple samples before a decision is made, to lessen the impact of one bad reading due to collision
Solution for Inteference Interference Scenarios System Parameters Beacons transmit a string corresponding to the space and a unique identifier (the pair is unique throughout system) Use sluggish RF transmission rate, so US is received while RF is being processed; easier to correlate Case 1: We receive reflection of US before direct signal Unlikely because of diffraction; caused by misalignment of beacons Case 2: We receive US from interfering node before US from beacon Only a problem when the RF of the interfering node has a weaker signal than that of the beacon US from beacon should have arrived first; Use RF with long transmission range, so RF of interfering node will be strong Case 1: US Path Shown by Pink Line Case 2: Interference Coming From Right
Interference Scenarios (cont) Case 3: Interference Reflected From Right Case 3: Reflected US of interfering node received before US of beacon Likely and hard/impossible to remedy All we can do is make it unlikely with variable transmission times, so it won t be persistent Collect multiple samples and run an inference algorithm; do not depend on one RF, US pair Solution for Changes in Air Temperature Temporal caused by time of day/season Use relative rather than exact distance (will affect all beacons similarly) Spatial caused by sunlight/air conditioning, etc Aim beacons to get coarse-grained location information There would have to be very large fluctuations to really have an effect Algorithms to Compute Closest Beacon Majority Ignores distance, no US; pick node that appears in data set the most (not actually used, more for comparison) MinMean Listener calculates mean distance from each beacon, selects beacon with min mean as closest Can be hurt by multipath (outliers), and mean not reflective of an action beacon position MinMode Computes per-beacon modes over n samples Listener chooses beacon with min distance among all modes
Beacon Positioning Could provide listeners with centralized collection of beacon locations, but this violates our goals (privacy/decentralization) So place them intelligently! At a distance >= some critical distance away from the boundary Make sure to aim them correctly, in a way that minimizes reflection On To The Experiments System Parameters #1 : Setup and Results RF Transmission set to 7 bytes RF Transmission rate set to 1200 bits/s Takes about 47ms for a message to completely reach a listener (in which time US pulse can travel about 47 feet) RF radio range is about 30 feet Consumed about 15mW during normal operation; not bad at all Beacons placed 4 feet apart on the ceiling, making a virtual boundary in between Listeners randomly placed Listener could accurately determine the closest beacon when it was > 1 foot away from the boundary Proved that they could split rooms into discernable 4x4 foot cells Proved to be robust to interference, even with no coordination between beacons
Physical Setup - #1 #2 : Setup and Results Two beacons are set up, along with two interference beacons and two listeners One listener is placed closer to the interference beacons Interference beacons do NOT have active US transmitters Detected just 0.3% incorrect samples Attributed to random transmission scheduling and proper system parameters Physical Setup - #2 #3 : Setup and Results Set up multiple beacons and a mobile listener Listener will move through room at average walking speed Pauses when it crosses a boundary, to see how long it takes for closest-beacon reading to stabilize Listener always close to boundaries MinMode worked best, though it wasn t much better than MinMean (almost identical in small time windows, because of only one sample)
Physical Setup - #3 Application: vspace Creation of Virtual Spaces in I(ntentional)N(aming)S(ystem) Collection of applications/services that can communicate with each other Can have a vspace for each important location (room/floor/building/etc) Users/Apps can contact INS and learn of other services in the vspace, or register their own names and services Can be a member of more than one vspace simultaneously, and queries to each can be issued Application: floorplan Example Floorplan Floorplan Active-Map navigation utility using Cricket and a map server Highlights user s location/motion and provides clickable icons for services in the space Floorplan uses INS to download a control script or program for the app, and opens it in another window Allows one to control services with no other info about the environment
Conclusion Cricket provides location support to applications and users It is NOT a tracking system, and does not store any state information Deals well with interference and collision, and takes advantage of its decentralized architecture to make dynamic addition of beacons and listeners a breeze Achieves sufficient granularity to split rooms into subsections, allowing for more precise localization Y Ç