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 environmentso Personalized heating, ventilating, and air conditioning (HVAC) controlo Shopping mall navigationo Emergency rescue

• GPS doesn’t worko Signal is blockedo Higher accuracy requirements in indoor scenarios

• Many competing approaches:o Signal Fingerprinto Multi-angulation and multi-laterationo Dead reckoning (inertial measurement units)o Beacono Passive device-free approach (video, audio, etc.)o Data fusion

Problems of Current Systems

• Figure of merit is accuracy, not ease of development

• Founded on integrated client-server modelso Monolithic:

• Proprietary protocol• Not composable or reusable

o Does not fit dispersed configurations: • Sensors on the wall (WiFi RSS

sniffer)• Infrastructure as applications

(HVAC systems)

Indoor Localization Systems are Complex

• Components areo Distributed on different hardware (Map is on server)o Composed in complex ways (chains, N-to-1, 1-to-N)o Reused/multiplexed

BearLoc Design Goals

• System Partitioned to Componentso Has clear abstractions for developerso Runs on heterogeneous distributed hardware (mote, smartphone,

server)

• Component Compositiono Agree on data schemao Flexible communication pattern (1-to-N, N-to-1)o Easy composition

• Algorithm Multiplexingo Concept of sessiono Hide multiplexing logic from developers

BearLoc Architecture

• System overview: o Three layers: Network, BearLoc, Developer Codeso Three types of components: Sensor, Algorithm, Applicationo Defines data flow

Publish/Subscribe Network

• Publish/subscribe (Pub/Sub) networko Message-oriented event-driven overlay networko Subscribers and publishers connect to a brokero Publishers send messages to topicso Subscribers get messages that match topics of their interests

• Pub/Sub network is an ideal communication pattern for heterogeneous hardwareo Event-driveno Good for intermittent connections and dynamic network configurations

(e.g., changing IP address)o Multiplexing

• But not enough for end-to-end interoperabilityo Need higher level component abstractionso Need protocol between these abstractions

Sensors, Algorithms, and Applications

• Three indoor localization system component abstractions: sensors, algorithms, and applicationso Sensors are the components that generate location data (WiFi RSS,

User input)o Algorithms map sensor “readings” into a particular locationo Applications use the locations from algorithms for their particular tasks

• Components are developed and evolved independently

• Interface between components are defined in BearLoc

Algorithms Multiplexing

• Applications multiplex algorithmso Algorithms can be stateful (Kalman Filter)o Algorithm developers should not worry about

multiplexing, they should think about only one user (localization target)

• Algorithm manager does multiplexingo Starts and stops algorithm instances, processes of

algorithm executableo Every instance only service one usero Maintains communication states (e.g. sensor

topics, output topic) for all instances

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

WiFi RSS

GPS

WiFi RSI Fingerprinting

Particle Filter

Navigation

1. Algorithm manager subscribes to its control topic

2. Application sends Start Binding request that containso Sensor topicso A new algorithm output topico A keep-alive topico Optional configuration data

3. Algorithm manager o Subscribes to the sensor topics o Subscribes to the keep-alive topic

4. Application o Subscribes to the algorithm output topico Sends keep-alive messages periodically

Binding Control Protocol

Application

Algorithm Manager

Algorithm Instance

3

Broker

1

2Sensor

4

Binding

Evaluation

• Sensors and application run on one Android phone

• Algorithms run on server (WiFi) and laptop (ABS)

Lines of Developer Code

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.

• BearLoc simplifies developmento Clear abstractions of componentso Lines of developer codes with common functions implemented

• Codes saved by using BearLoc:o Data queuing and retransmission o Sensor data schema are provided by the BearLoco Algorithm Multiplexing

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.

Data Flow Overhead

• 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 discoveryo Now application needs to find all required sensors

• Interface/schema negotiationo The current interface and schema are also proprietary

• Streaming in pub/sub networko 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