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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

18. Thank you! Kaifei Chen (kaifei@berkeley.edu)