BearLoc: A Composable Distributed Framework for Indoor Localization Systems Kaifei Chen, Siyuan He, Beidi Chen, John Kolb, Randy H. Katz, David E. Culler UC Berkeley

Indoor Localization Location is important in indoor environments Personalized heating, ventilating, and air conditioning (HVAC) control Shopping mall navigation Emergency rescue GPS doesn’t work Signal is blocked Higher accuracy requirements in indoor scenarios Many competing approaches: Signal Fingerprint Multi-angulation and multi-lateration Dead reckoning (inertial measurement units) Beacon Passive device-free approach (video, audio, etc.) Data fusion Location I mean both generally occupancy, localization, and identification

Problems of Current Systems Figure of merit is accuracy, not ease of development Founded on integrated client-server models Monolithic: Proprietary protocol Not composable or reusable Does not fit dispersed configurations: Sensors on the wall (WiFi RSS sniffer) Infrastructure as applications (HVAC systems) People’s work are good, but systems are not used afterwards At least two reasons pause

Indoor Localization Systems are Complex Systems can be complex Components are Distributed on different hardware (Map is on server) Composed in complex ways (chains, N-to-1, 1-to-N) Reused/multiplexed

BearLoc Design Goals System Partitioned to Components Has clear abstractions for developers Runs on heterogeneous distributed hardware (mote, smartphone, server) Component Composition Agree on data schema Flexible communication pattern (1-to-N, N-to-1) Easy composition Algorithm Multiplexing Concept of session Hide multiplexing logic from developers Transit: pause

BearLoc Architecture System overview: Three layers: Network, BearLoc, Developer Codes Three types of components: Sensor, Algorithm, Application Defines data flow

Publish/Subscribe Network Publish/subscribe (Pub/Sub) network Message-oriented event-driven overlay network Subscribers and publishers connect to a broker Publishers send messages to topics Subscribers get messages that match topics of their interests Pub/Sub network is an ideal communication pattern for heterogeneous hardware Event-driven Good for intermittent connections and dynamic network configurations (e.g., changing IP address) Multiplexing But not enough for end-to-end interoperability Need higher level component abstractions Need protocol between these abstractions Transit: now let’s look at the detail What pub sub network Practice Facebook Messenger uses MQTT

Sensors, Algorithms, and Applications Three indoor localization system component abstractions: sensors, algorithms, and applications Sensors are the components that generate location data (WiFi RSS, User input) Algorithms map sensor “readings” into a particular location Applications use the locations from algorithms for their particular tasks Components are developed and evolved independently Interface between components are defined in BearLoc transit: representations on upper layer

Algorithms Multiplexing Applications multiplex algorithms Algorithms can be stateful (Kalman Filter) Algorithm developers should not worry about multiplexing, they should think about only one user (localization target) Algorithm manager does multiplexing Starts and stops algorithm instances, processes of algorithm executable Every instance only service one user Maintains communication states (e.g. sensor topics, output topic) for all instances Many algorithms are stateful, and one algorithm can be used for many user. Developers are not necessarily worry about maintaining states for different users They should developer thinking abut only one user pause

Binding: The Data Flow A binding defines how components can be connected using pub/sub network topics A binding is centered at an algorithm instance Binding is the primitive of composition in BearLoc transit: to form a binding How components are combined Add example Chain, multiplex pause WiFi RSS GPS WiFi RSI Fingerprinting Particle Filter Navigation

Binding Control Protocol Algorithm manager subscribes to its control topic Application sends Start Binding request that contains Sensor topics A new algorithm output topic A keep-alive topic Optional configuration data Algorithm manager Subscribes to the sensor topics Subscribes to the keep-alive topic Application Subscribes to the algorithm output topic Sends keep-alive messages periodically Algorithm Manager Algorithm Instance 1 3 Binding Broker Sensor The goal is to connect sensor, instance, and application 2 4 Application

End-to-end Case Study: Follow-Me Displays Each components are built independently Not sure whether to talk about it

Evaluation Sensors and application run on one Android phone Algorithms run on server (WiFi) and laptop (ABS) Transit: Sensor and App is on the same device

Lines of Developer Code BearLoc simplifies development Clear abstractions of components Lines of developer codes with common functions implemented Codes saved by using BearLoc: Data queuing and retransmission Sensor data schema are provided by the BearLoc Algorithm Multiplexing BearLoc Application codes are primarily performing the Binding Control Protocol Audio Sensor WiFi RSS Sensor WiFi RSS Algorithm Without BearLoc 856 925* 737 With BearLoc 173 184 350 * It shares 722 lines of codes with the audio sensor.

Data Flow Overhead Data flow overhead is the network delay overhead in a data flow introduced by distributing components in BearLoc Data flow overhead = (T4 – T1) – (T3 – T2) Our setup doesn’t need time synchronization because T4-T1 is measured on the phone, and T3-T2 is measured on the server. The overhead the BearLoc brings

Data Flow Overhead Low delay 90% of overhead in WiFi RSS is less than 100 milliseconds 90% of overhead in ABS is less than 1 second, given ABS has much more data (audio) to transmit

Future work Service discovery Interface/schema negotiation Now application needs to find all required sensors Interface/schema negotiation The current interface and schema are also proprietary Streaming in pub/sub network Vision-based person tracking Generalize the idea and apply to other IoT systems

Thank you! Kaifei Chen (kaifei@berkeley.edu) https://github.com/SoftwareDefinedBuildings/BearLoc