Deep dive: Radio technologies for indoor location

#ATM15 |
Location Technologies
Peter Thornycroft
March 2015
@ArubaNetworks

CONFIDENTIAL © Copyright 2015. Aruba Networks, Inc. All rights reserved2#ATM15 |
Agenda
• General location requirements
– Users of location data
– Client-side vs Network-side
• Technologies for raw data
– Wi-Fi Signal Strength
– Wi-Fi Time of Flight / Time Difference of Arrival
– Wi-Fi Direction / Angle of Arrival
– Bluetooth Low Energy
– GPS
– Inertial sensors
@ArubaNetworks
• Twists and practical considerations
– iBeacons
– Hyperbolic techniques
– Sleeping clients
– Scrambled MAC addresses
• Calculating location
– Triangulation on RSSI
– Ray-tracing models
– Fingerprinting
– Crowd-sourcing
– Synthetic heat maps
– Neural networks

3 CONFIDENTIAL © Copyright 2015. Aruba Networks, Inc. All rights reserved#ATM15 |
General location requirements
Serve all client stances
1. Un-associated devices under WLAN coverage
2. Associated devices
3. Associated and with our app running
Cost/complexity
1. Minimize extra hardware requirements (sales/capex):
new hardware or more APs
2. Software upgrade to ‘legacy’ hardware
3. Minimize extra installation/calibration requirements
(sales/professional services)
4. Minimize ongoing professional services
requirements
Serve all client populations
1. iPhones/iPads: minimal scanning, no onboard
scan data, reasonable BLE support
2. Android: better characteristics, especially with
an app
3. PCs: most amenable, but least important
4. IoT/M2M devices: not significant yet but
emerging
Accuracy:
1. For bake-offs, PoC, beat competition to
sub-metre
2. For client-side navigation, 2m accuracy,
real-time
3. For analytics, avg 5m accuracy, not real-
time
4. Everyone’s goal: sub-metre accuracy, real-
time
Performance considerations
1. Minimize extra battery draw
2. Minimize frames on the air (congestion)

Uses for location information
Tell the client where it is (how?)
– 802.11k
– http?
Frames of reference
– Local (floorplan xy) (needs the floorplan data for context)
– Global (Lat/Long… GPS)
Tell the network admin where clients are/were
Context:
– Provide information on nearby objects & services
– Navigation
– Tell clients where other clients/mobile objects are
Provide northbound API for analytics tools (location is part of the information set)

Client-side vs Network-side
Client-side:
Navigation
Customer engagement
Network-side:
Analytics
Very fast calculation
Very accurate
Needs a map & AP locations
High volume
Slower calculation
Map & AP locations are known
“Am I in
Kansas?”
“What’s
around me?”
“How many people
visited my store?”
“What kind of
people and what
were they doing?”
Location
engine

Own-app combines the models
Client-side:
Sense & calculate location
Provide consumer services (navigation)
Report context to cloud service
Network-side:
Provide context (AP locations, maps, calibration)
Determine actions
Push notifications
Cloud service CRM etc
Location
engine

Aruba’s location architecture (roughly)
ALE
Meridian Service
Custom service
Controller Controller
AirWaveAirWave
App uses Meridian
SDK for location &
location context (or
turnkey app from
Meridian)
Custom software
takes location &
context directly from
ALE and feeds client
app on device
Analytic Partner provides data
analysis and integration with customer
database and other data sources
Meridian provides integration
with ad networks and coupon
engines
The Aruba WLAN provides raw data about devices,
users, signal strength etc. to ALE which calculates
location and aggregates context across the entire network
Third-party integration with
customer database, ad
networks and coupon engines
Analytic engine

Over-the-top location
Google Maps
“Internet”
Cellular data Wi-Fi
“I am at Lat… Long…,
give me a map
Wi-Fi scan
BSSID list
celltower scan
with triangulation
GPS
satellites
Bluetooth
LE beacons
Here’s a map for your
Lat… Long…
Inertial
sensors
No interaction with the
WLAN

Target population
Un-associated:
Track for analytics
Infrequent probe requests
Scrambled MACs
Full platform-infra interaction
Advertising
Navigation
Associated:
Limited interaction
Associated with our app:
Full interaction
Report true MAC address
Monitor traffic
Limited push capability
“Anyone
about?”
“Web
browsing…”
“MyStore
app”

Distance vs Location, frames of reference
Location
(45, 76)
9.7
4.4
12.2
11.5
Location
(32, 78)
Location
(37, 98)
Location
(48, 99)
x
y
longitude
latitude
Local coordinates
Easy
Private
Global coordinates
Tricky to fix
Universal
Arbitrary accuracy
Clients range relative to APs/beacons
But how does that relate to ‘location’?
- Requires knowledge of AP locations
- Requires a map with frame of
reference

The general RSSI location problem
AP 12
AP 11AP 13
AP 10
-46
-75
-51
-43AP10 -41
AP11 -73
AP12 -47
AP13 -50 -42
-75
-41
-69
-46
-70
-51
-43
Received signal
strength (dBm)
Given a “training” set of
data showing expected
RSSI at a set of APs from
test targets with given tx
pwr at a given location,
And given a set of actual
RSSIs from a given target
at an unknown location,
Find the most likely
location of the target.

The general RSSI location problem
Access Point Target
Given a set of RSSI readings at (or of) AP’s:
AP1: - 71dBm
AP2: - 67dBm
AP3: - 80dBm
AP4: - 73dBm
Find the most likely location of the target
Location {𝑥∗, 𝑦∗} or X*
given [ 𝑟𝑠𝑠𝑖1, 𝑟𝑠𝑠𝑖2, 𝑟𝑠𝑠𝑖3, 𝑟𝑠𝑠𝑖4 ] or Y
or... (loosely) Find ( X* | Y )
AP1AP2
AP3 AP4

1313#ATM15 |
Technologies
@ArubaNetworks

Wi-Fi RSSI: signal attenuates with distance (etc)
transmitter receiver
10 dB
wall
6 dB
wall
100m
‘free space’
100m
‘free space’
50m
‘wooded region’
5m indoors
5m indoors
Signalstrength(dBscale)
Distance

Wi-Fi RSSI variation with distance
Free Space Path Loss dB = 20 𝑙𝑜𝑔10 𝑑 + 20𝑙𝑜𝑔10 𝑓 − 20𝑙𝑜𝑔10(
4π
𝑐
)
dB = 20 𝑙𝑜𝑔10 𝑑 + 17.2
dB = 20 𝑙𝑜𝑔10 𝑑 + 10.2At 2450 kHz
At 5500 kHz
At 3m 50dB, at 10m 60dB
At 3m 57dB, at 10m 67dB
5500 kHz is 7dB worse
than 2450 kHz
40.0
45.0
50.0
55.0
60.0
65.0
70.0
75.0
80.0
85.0
0 10 20 30 40
Path loss in dB / m for 2450 kHz and 5500 kHz
2450 kHz
5500 kHz
40.0
45.0
50.0
55.0
60.0
65.0
70.0
75.0
80.0
85.0
1 10
2450 kHz
5500 kHz

Wi-Fi RSSI variation with distance
Longer distance
>> fewer dB/m
>> Less accurate
40.0
45.0
50.0
55.0
60.0
65.0
70.0
75.0
80.0
85.0
0 10 20 30 40
2450 kHz
5500 kHz

Wi-Fi RSSI: offices are not free-space
Free Space Path Loss dB = 𝑛 𝑙𝑜𝑔10 𝑑 + 20𝑙𝑜𝑔10 𝑓 − 20𝑙𝑜𝑔10(
4π
𝑐
)
-120
-110
-100
-90
-80
-70
-60
-50
-40
0 20 40
Pathloss(dB)
Distance from transmitter (meters)
Power level with distance, for different exponents n
N = 20
N = 25
N = 30
N = 35
N = 40
-120
-110
-100
-90
-80
-70
-60
-50
-40
1 10
Pathloss(dB)
Distance from transmitter (meters)
Power level with distance, for different exponents n
N = 20
N = 25
N = 30
N = 35
N = 40
Path loss exponent for free space, n = 2.0 In an office environment, n varies from ~ 2.4 to 3.4.

Wi-Fi RSSI RSSI empirical data
Easy to measure vs
averages well
y = -1.3291x + 48.9
0.0
10.0
20.0
30.0
40.0
50.0
60.0
0 5 10 15 20 25 30 35
Signalstrengthindication(SNR,
dB)
Distance from AP (meters)
Variation of signal strength with distance, lin scale
Varies over timeVaries over distance
Very noisy (inaccurate)
Varies over time
Varies with environment
RSSI depends on tx power and antenna directionality

Wi-Fi RSSI empirical data

Measuring different frames for RSSI
Probe requests & Mgmt frames:
Low rates
Predictable tx pwr
Scarce
Data frames:
Plentiful
Vary in tx pwr
Acks:
Plentiful
Vary in tx pwr
No source address field

Measuring RSSI walk-around test
Scale 10m
20
Time and
distance on route
(at 1m/s)
Route followed
through the
building
Access point
monitored
AL40
20
42
75
100
130
148
Finish
168
Start
0A
B
C
D
E
F
G
H

Actual RSSI readings from walk-around test

Angle of Arrival
Stronger form of CSI or multi-dipoles
Resolve direction or pattern
Use with other techniques
δ1
δ1

AoA calibrating azimuth & fingerprinting
Easiest to calibrate on known-location AP
1 orients; 2 + distance, or 3 triangulate
Beware of NLOS
Need to be in a plane or close to it
For NLOS, fingerprint the signature of
a location
LOS or NLOS
Calibration of azimuth
Cost of hardware

GPS
So good we don’t notice it
One-way so no privacy concerns
Consistently better than 10m
Depends on seeing the satellites
Acquisition time
Combine with inertial sensors
Development for vehicle navigation
Depends on seeing the satellites
Not so good indoors indoors
Network privacy concerns
Not much better than 10m
Global coordinates only
Acquisition time
Quite power-hungry
“Why can’t
Wi-Fi be more
like GPS?

Time-based measurements
RTT “Round-Trip-Time”
Challenges:
- Need to combine/average
several frames to get a good
reading.
- Averaging many frames
affects battery life, network
capacity
Challenges:
- Measuring to nanoseconds
(speed of light: 1 ft per nsec)
- Setting up circuitry to
timestamp the right frame
- Calibration for time frame
leaves (arrives) at the antenna
Implementation
In mobile device Wi-Fi chips late
2014 (Android 5.0 ‘private API’)
In access points 2015
No Wi-Fi Alliance certification
till 2016 >> may cause
interoperability teething troubles
t1 t2
t3
Accuracy should be 1 – 5 metres,
depending on the number of frames
averaged & underlying hardware
Most useful in line-of-sight, but
better accuracy at longer distances
than RSSI
Many variations possible with
WLAN topologies
Expected accuracy (LOS) vs distance1m
10m
20m
1m 25m 50m 75m 100m
RTT
RSSI
Scheduled periodic bursts
t4

Time-based measurements
RTT/FTM protocol
A standard (actually two
standards and several
proprietary variants)
“802.11k” Location Track
Notification, modified (to
finer timestamps) in
“802.11mc”
Fine Timing
Measurements
Distance Calculations
Measure
with me!
Now here
are my
times t1, t4
Here’s the
first frame
t1
t3
t4
t2
Once all four timestamps
are in one place,
subtraction and /2 gives
time-of-flight and
multiply-by-speed-of-light
gives distance
d = ((t4 – t1) – (t3 – t2)) * c / 2
Ack

Hyperbolic variations on time-based location
RTT
exchange
RTT
exchange
Client-side hyperbolic
Requires an AP-AP schedule
APs and/or client channel-switch
Both sides must use RTT standard
Network-side hyperbolic
Requires a stimulation schedule
Requires AP –AP RTT
APs channel-switch
Works with all clients
Not one-to-one distance
measurement, but many-to-
one or one-to-many
Reduces the number of
frames on the air, improves
battery life
frame
exchange

The most time-consuming and error-prone step when
setting up AirWave?
>> Placing APs on the floorplan
For sub-metre accuracy, AP locations must be correct
Peer-to-peer RTT between APs provides a line-of-sight
tape measure
With known, accurate distances between each pair of
APs, we can build a stick-figure of the network…
Then rotate and shift the constellation over the
floorplan at known points…
And use that to scale the floorplan
RTT: Calculating the AP constellation

Bluetooth Low Energy technology
• BLE is also known as Bluetooth Smart, Bluetooth 4.0
• Evolution of the existing Bluetooth standard (2010)
• Focus on ultra-low power consumption (battery powered devices)
• Differences
– Efficient discovery / connection mechanism
– Very short packets
– Asymmetric design for peripherals
– Client server architecture
– Fixed advertising channels designed around WiFi channels
– Not compatible with older Bluetooth
• Most new devices support both ‘classic’ Bluetooth and BLE (“Bluetooth
Smart Ready”)
– iPhone 4S+, current (2013) iPad, Samsung Galaxy S4+, Nexus 7+

iBeacon deployment model for navigation
UUID: Aruba
Major: 1000
Minor: 501
UUID: Aruba
Major: 1000
Minor: 502
UUID: Aruba
Major: 1000
Minor: 509
UUID: Aruba
Major: 1000
Minor: 503
-66
-68
-76
-82

Bluetooth Low Energy & iBeacon
Bluetooth
– Very low-power consumption: years of life from a button cell
– Advertises… ‘beacons’
– Allows scanning for ‘peripherals’
– Allows ‘central’ devices to discover ‘peripherals’
– Two-way communication channel to read/write values
iBeacon
– A subset of BLE, just the ‘advertising’ function with special fields
– Allows a background app to be alerted on proximity
– No explicit location information in an iBeacon, just a reference ID

Spectrum for iBeacons & BLE
6 11
2412 2437 246224222402 2427 2447 2452 2472
1
2400 2483.5
Ch 37
(2402 MHz)
Ch 38
(2426MHz)
Ch 39
(2480MHz)
Wi-Fi
Bluetooth Low Energy Advertisement (iBeacon)
2 MHz channels
Gaussian Frequency Shift Keying
0.5 modulation index
1 Msymbol/second rate
1 Mbps data rate
~250 kbps application throughput
(in connection mode)
Advertisements are one-way transmissions. An
advertisement can be sent on any/all of the 3 designated
channels
Advertisements are repeated every 20 – 10000 msec
(500msec typ)
Tx power ~ 0 dBm ( ~ 2 year battery life typ)
Apple specifications for iBeacons are more constrained
(but not widely followed)

BLE Advertisement and iBeacon
Preamble
1
Advertiser
4
PDU
2 - 39
CRC
3
MAC address
6
Header
2
Data
1 - 31
iBeacon Prefix
9
Proximity UUID
16
Major
2
8E89BED6
0201061AFF4C000215
Minor
2
size, type.. e.g. 112233445566
e.g. 4152554e-f99b-86d0-947070693a78 e.g. 4159 e.g. 27341
BLE Advertisement Frame
BLE Advertisement Payload
iBeacon Data
Measured Tx Pwr
2
e.g. -59
iBeacon information
RSSI Measured by receiver
MAC From BLE header
Proximity UUID (can be) company reference
Major, Minor Integer values identifying the
tag and/or zone
Measured Tx Pwr Calibrated power at 1m from
the iBeacon (dBm)

iBeacon RSSI vs distance
-100
-95
-90
-85
-80
-75
-70
-65
-60
-55
-50
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
iBeacon RSSI (dBm) vs distance (m), line of
sight
GS4 with iBeacon 100 GS4 with iBeacon 101
Nexus 7 with iBeacon 100 Nexus 7 with iBeacon 101
iBeacon Tx power 0dBm ‘measured power’ -61dBm @ 1 m
-90
-85
-80
-75
-70
-65
-60
-55
-50
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
iBeacon RSSI (dBm) vs distance (m), line
of sight
(RSSI averaged over 5 readings)
GS4 with iBeacon 100 GS4 with iBeacon 101
Nexus 7 with iBeacon 100 Nexus 7 with iBeacon 101
grand average

Inertial sensors (“sensor fusion”)
Accelerometer, Gyro, Compass, all 3-axis (& sometimes barometer)
Intrinsically accurate
But… read at intervals, not continuously (for battery life etc.)
Device attitude must be calculated out (via 3-axis)
And… errors integrate over time & distance
Manufacturers adding dedicated, continuously-running processor to the platform
Gyroscope
(rotation)
Accelerometer
(motion & gravity)
Magnetometer
(direction)
N
Barometer
(altitude)

3737#ATM15 |
Twists & practical
considerations
@ArubaNetworks

Techniques and constraints
Heatmap Model
i. Floorplan
ii. Place APs
iii. Calibrate AP-AP
iv. Training data
v. Ground truth locations
vi. Other a-priori
vii. History
Prediction Models etc
i. Sparse samples
ii. Stimulation
iii. Gaussian Process
iv. Bayes
v. Neural Networks
vi. Graphs Nodes*Edges
vii. Inertial navigation
Constraints
i. Snap to tramlines
ii. Motion constraints
iii. Motion boolean
iv. Right floor
v. AP Tx Pwr
vi. Target Tx Pwr
vii. Not heard by AP
viii. Out-of-bounds areas
Auto-RF-tuning
i. Frequency of changes
ii. Higher Tx Pwr
iii. AP placement
iv. Phone less sensitive &
accurate than APs
Type of client
i. Tag
ii. Non-Assoc or Assoc
iii. Static or Mobile
iv. Traffic generated
Active techniques
i. Stimulate client
ii. Calibration points
iii. Client assist

3-dimensions
Today, nearly all WLAN location is 2-dimensional
Per-floor location:
- First determine floor,
- then xy on the floor
In an open atrium, or with high ceilings, floor determination is difficult (bleed-through associations)
In an office building, emergency service (& other) requirements for correct floor are easy <90% but hard <99%
For sub-metre accuracy, 3-D models are required.

Getting AP locations & local map, POI data
At the Wi-Fi layer
– 802.11k three ways (associated) LCI, civic,
URL
– In Neighbour Report (associated)
– Passpoint (ANQP) (pre-association) in
Neighbour Report
Over the top e.g. http/xml/SOAP/JSON
– Various near-standards
Over the top telco standards
– e.g. OMA-SUPL
Proprietary protocols
– e.g. AirWave XML API
– ALE REST, pub-sub
– Qualcomm IZAT
Type Local Name Description Value
0 language en
1 A1 national subdivision CA
3 A3 city Santa Clara
34 RD primary road or street Garrett
18 STS street suffix or type Drive
19 HNO house number 3400
24 PC postal / zip code 95054
Example civic address
Latitude 37.381814, uncertainty 1 metre
Longitude -121.986111, uncertainty 1 metre
Altitude 2.7 metres, uncertainty 2 metres
Z co-ord Height above floor 4 metres, uncertainty 0.5 metres
Example LCI

Why iBeacons matter on iDevices
The iOS app lifecycle puts an app on ice when not in foreground.
How to wake up on proximity to a particular location?
– iOS maintains BLE in always-listening mode
– If the app registers for a UUID, iOS will awaken it when that UUID is
seen
– Event is a ‘region entry/exit’
– iBeacon background detection can take minutes
Even in foreground, iOS will only return data on known, specified
UUIDs
– ‘Ranging mode’ in foreground gives RSSI every ~ 1 second
Android makes a much more flexible iBeacon hunter
iOS
Mobile App
BLE radio
BLE air interface
Register for < 20
UUIDs
Continuously
scanning for
iBeacons
Woken from
background when
UUID heard
Database of UUID-
Major-Minor to locations
(part of the app server)

iBeacon use cases
Indoor location
– Beacons are placed throughout the building in such a way that each
location is covered by at least 3 beacons
– The mobile apps will look for nearby beacons, get beacon locations
from the cloud and calculate location locally
– Examples – any public venue with navigation apps: airports, casinos,
stadiums
Proximity
– Beacons are placed nearby exhibits or points of interest
– Mobile apps discover beacon context from the cloud and impart
interesting information
– Examples – museums, self-guided tours, door opening, forgot keys

iBeacon hunting with Android
Find a BLE-capable device
Run the app

Stimulating clients
Devices like to switch off their radios to
save the battery
When not associated
When associated
How to catch them awake?
Non-associated:
>> difficult
Associated: DTIM,
>> bombard with frames
Associated-with-app:
>> generate traffic
Same-channel APs are usually distant
enough that RSSI does not give accurate
location.
Many variations on the same basic technique:
- Associated AP advertises a schedule
- Neighbouring APs receive schedules of
channel & time
- Associated AP stimulates client
- Neighbouring APs switch off-channel to
receive frames
We can stimulate associated clients to-order
Neighbour APs may be busy, dedicated
monitors can help
Variations: use control frames, data frames,
acks
Downside:
Channel-switching is painful
Sensitive to battery considerations
More frames on the air

Stimulating clients: empirical algorithms & data
iPhone, associated, black screen
red: naturally-generated probe requests
blue: stimulated probe requests
Nexusy7, associated, black screen
red: naturally-generated probe requests
blue: stimulated probe requests
Off-channel scans discover neighbors’ beacons
Build up a table of neighbor beacons, channel, offsets from OTA measurements
Keep track of beacon sequence numbers (to identify super-beacon timing)
Establish ‘best’ scanning schedule
Limit off-channel scanning to ‘useful’ measurement opportunities
Curtail scanning if AP gets busy with own clients’ traffic
Other opportunities for optimization
Capture neighbour APs’ client transmissions
Go to neighbour’s channel milliseconds before super-beacon
Listen for transmissions from the AP and capture corresponding acks from clients
Return to service channel asap

Managing iBeacons
Key problems with iBeacons:
Reprogramming (frequency of chirp, UUID, tx pwr etc)
Where is this iBeacon (or what’s the UUID of the beacon here?)
Is the battery failing?
Solved by an (Aruba) BLE protocol to catch iBeacons awake, interrogate and re-program.

Getting antennas closer to the target
Shorter distances >> more accuracy
More hearing APs >> more accuracy
But… APs / AMs are expensive, need Ethernet & Power
So… can we make a monitor more like an iBeacon?

Scrambled MACs
What needs fixing?
When checking for network presence,
probe request broadcasts:
- Always include device MAC
- Can include SSID
New behavior when
checking for Wi-Fi
Switch to conventional mode
Uses correct MAC when seeking to
associate
- Reveal information about the device
while in unknown surroundings
When not associated, not seeking
association:
- Use random MAC
“14ParkRoad”
or
“broadcast”
“RandomMAC”
- Pre-association probe request uses
correct MAC address
- All subsequent exchanges use correct
MAC address
“14ParkRoad”
- Random MAC uses locally-
administered addresses
x2:xx:xx:xx:xx:xx
x6:xx:xx:xx:xx:xx
xA:xx:xx:xx:xx:xx
xE:xx:xx:xx:xx:xx
- Apple first, more to follow
Probe request frame

4949#ATM15 |
Calculating location
Location engines
@ArubaNetworks

Last-generation location engines
AP 12
2dBm
AP 11
-8dBm
AP 13
-6dBm
AP 10
17dBm
-3dBm
-0dBm
6dBm
10dBm
9dBm
3dBm
-2dBm
14dBm
10dBm
6dBm
2dBm
Divide floorplan into grid ( ~ 2 metre squares) Estimate RSSI for each AP in each square Pick the most likely square

RSSI & triangulation
Derive distance from path loss (RSSI
and tx pwr)
Draw a radius from each AP

RSSI & triangulation
Derive distance from path loss (RSSI
and tx pwr)
Draw a radius from each AP
This is a joke, right?

Ray-tracing approach to propagation prediction
transmitter receiver
10 dB
wall
6 dB
wall
100m
‘free space’
100m
‘free space’
50m
‘wooded region’
5m indoors
5m indoors
Signalstrength(dBscale)
Distance
Rappaport et. al.
An improvement on triangulation
Cumbersome to implement

Configuring construction materials
If manual, this is tedious:
- How to identify the construction material?
- Label every wall
Where does the drawing appear from?
Do we have multi-layer architect’s drawings?
Can we read a .jpg or .dwg and infer walls & doors?

Fingerprinting
The most accurate method (to date)…
many points, well-averaged over many
frames at accurately-known locations.
But time-consuming, cumbersome
Non-reciprocal figures (tx pwr) may
cause difficulty
Fingerprinting may be solved by smart
client software,
Or multi-mode location (one mode
checks the other)
Or crowd-sourcing (apps on users’
phones or data crunching)
Access Point Target
AP1AP2
AP3 AP4
Fingerprints

Fingerprint apps: ALE Demonstrator
Pulls floorplan from ALE
Shows trail of already-fingerprinted points
Shows quality of fingerprint data per-square
Generates traffic for APs to fingerprint
Reports AP RSSI, channel etc
Reports BLE beacons
Demo Android App (java code) on GitHub

Fingerprinting – tricks & improvements
Standing & clicking at each point is laborious
>> click at beginning and end, app interpolates distance
>> add some inertial sensor readings to improve accuracy
Snap to fingerprint point or
snap to tramlines:
Instant accuracy improvement!
(Blocking out impossible areas
can also help.)
Interpolation more
difficult but more
accurate.

Fingerprinting – Up vs Dn and corrections
Location
engine
Client-side fingerprinting:
- Location is known from touch on floorplan etc.
- RSSI can be scanned by Android (Broadcom ~ 5sec,
QualcommAtheros 0.5sec)
- But… best to read AP tx pwr & channel and adjust later
- Usually report to cloud service
Cloud
service
Network-side fingerprinting:
- Interaction between Location Engine & client app
- Location is known from touch on floorplan etc.
- Best if client transmits constantly, data & control frames
- APs report RSSI from the client for the fingerprint
- Client reports RSSI from APs (& iBeacons & GPS etc.)
- Location engine returns status of fingerprint to client

Performance of last-generation RSSI systems
Small calibration data set
Limited transmissions from / measurements at the client (especially non-
associated clients)
Data upload / reduction problems limit timeliness if all clients are tracked
Tradeoff between generalized models and significant administration
effort required to customize for higher accuracy
Sometimes gets wrong floor (this upsets E9-1-1 enthusiasts)

Machine learning – supervised learning – nonparametric
techniques
Make a model for a
general form of the
problem
Tune the model with
data
We have some idea of the
form of the problem and
solution. This influences
the architecture of the
model.
We take some ‘training’
data and use it to set up
the model.
Training data
Apply test points
to the tuned model
Take an unknown set of test
points and find the most
likely values.
Invoke Bayes
Test pointsDomain knowledge
What’s so useful about machine learning?
- Very simple model structure (don’t need complicated physical models for the problem)
- Adapt to differing situations / buildings / topologies without major re-engineering
- Allows huge volumes of training data
- Add new training data types without re-engineering
- Provides expected values and confidence bounds
- Easily computed on a variety of platforms (matrix algebra, software libraries)
Results
Bayes’ Theorem
p(b|a) = p(a|b) p(b) / p(a)

Developing an RSSI heatmap
Propagation model based on AP
location, tx pwr, antenna
i. modified Friis exponent
ii. Rappaport ray model
Modified model using measurements
i. AP-AP calibration
ii. Clients at known locations
iii. Statistical methods
Gaussian Process (curve fitting)
iv.The more data the better

Synthetic heatmaps for RSSI location
Create synthetic
heatmaps / reverse
heatmaps
Find the likelihood
of each location
per-AP, given RSSI
Apply a time-based
probabilistic
adjustment
Find the most likely
location due to this
test vector of RSSIs
AP14
AP27
AP45

Fingerprinting in the calculations
Access Point Target
What do we know?
>> ‘fingerprint’ data: RSSI of a target at given locations, measured
at the APs
‘fingerprint data’
D = { (𝑥1, 𝑦1, 𝑟𝑠𝑠𝑖1, 𝑟𝑠𝑠𝑖2, 𝑟𝑠𝑠𝑖3, 𝑟𝑠𝑠𝑖4 1 ), (𝑥2, 𝑦2, 𝑟𝑠𝑠𝑖1, 𝑟𝑠𝑠𝑖2, 𝑟𝑠𝑠𝑖3, 𝑟𝑠𝑠𝑖4 2 ) }
Or… D = { (X1, Y1), (X2, Y2), (X3, Y3), (X4, Y4) }
Now… the problem becomes:
Find ( X* | Y, D )
AP1AP2
AP3 AP4
Fingerprints
But fingerprinting is still cumbersome.
Automated fingerprinting systems with smartphones and multi-mode location may solve all our problems.

The Gaussian Process as curve fitting
Make a model for a
general form of the
problem
Tune the model with
data
Training data
Apply test points to
the tuned model
Test pointsDomain knowledge
Diagrams from ‘Rasmussen & Williams’ 2006
Results
Input = 3.8
Output: ‘most
likely’
value -0.5
with 95%
confidence
bounds of
-0.5 +- 1What’s so useful about the Gaussian Process?
- Very tractable mathematically (a Gaussian differentiates, integrates, marginalizes, conditions to
another Gaussian)
- Depends on hyperparameters but can be tuned by training data
- Not too onerous to compute (On3, On2)
- Gives results as Gaussian distributions with mean, variance >> confidence bounds
- Provides automatic relevance determination across data types

The Gaussian Process creates synthetic heatmaps
Use the training set to create a curve for the expected RSSI due to a given AP in every square on the grid.
Result is an expected RSSI for each square, and an expected variance or standard deviation around that value.
Consider each AP separately (we will combine later)
Set of training points D consists of known locations 𝑿 𝒏 = 𝑥 𝑛, 𝑦𝑛 with RSSI value 𝛼 𝑛
𝑫 = {(𝑿 𝟏, ∝1), (𝑿 𝟐, ∝2), (𝑿 𝟑, ∝3), … 𝑿 𝟒, ∝4 }
Training points are sets of RSSI values taken at known points.
The covariance function is arbitrarily defined as a Radial Basis Function (RBF)
𝑐𝑜𝑣 𝛼 𝑝, 𝛼 𝑞 = 𝜎𝑓
2
𝑒𝑥𝑝 −
𝑋 𝑝−𝑋 𝑞
2
2𝑙2 + 𝜎 𝑛
2
δ 𝑝q
Where 𝜎𝑓, 𝜎 𝑛, 𝑙 are hyperparameters that determine scale and accuracy constraints on the resulting function. (σ 𝑛
2
𝐼 adds
the noise factor for the difference between modeled and measured values).
Constructing matrices for input points (X), rssi values (Λ) and covariance (K) 𝑐𝑜𝑣 𝜦 = 𝑲 + σ 𝑛
2
𝑰
When we have a new point 𝑿∗ = (𝑥∗, 𝑦∗) and wish to find the expected RSSI ∝∗= 𝑓(𝑿∗)from 𝑝 𝛼∗ 𝑿∗, 𝑿, 𝜦) =
𝓝(α∗ ; 𝜇 𝑋∗
, 𝜎 𝑋∗
2
)
The expected mean for ∝∗, 𝜇 𝑋∗
= 𝑘 𝑿∗, 𝑿 𝑻
𝑲 + 𝝈 𝒏
𝟐
𝑰
−𝟏
𝜦
The variance for ∝∗, 𝜎 𝑋∗
2
= 𝑘 𝑿∗, 𝑿∗ − 𝒌 𝑿∗, 𝑿 𝑻
𝑲 + 𝝈 𝒏
𝟐
𝑰
−𝟏
𝒌(𝑿∗, 𝑿)
Where the k* matrix is the nx1 vector of covariance of the new point X* to the training set.
The onerous part of the calculation is inverting the matrix 𝐾 + 𝜎 𝑛
2
𝐼 −1
which is nxn for the training set.

Gaussian Process for curve-fitting: examples
Same training data, different hyperparameters

= 2 1.4 1.2
1.4 2 3.2
1.2 3.2 2
K = cov(X1, X1) cov(X1,X2) cov( X1,X3)
cov(X2, X1) cov(X2,X2) cov( X2,X3)
cov(X3, X1) cov(X3,X2) cov( X3,X3)
Gaussian Process numerical example
The expected mean for ∝∗, 𝜇(𝑋∗) =𝑘(𝑿∗, 𝑿) 𝑻 (𝑲+ 𝝈 𝒏
𝟐 𝑰)−𝟏 𝜦
The variance for ∝∗, 𝜎(𝑋∗)
2 = 𝑘(𝑿∗, 𝑿∗) −𝒌(𝑿∗, 𝑿) 𝑻 (𝑲+ 𝝈 𝒏
𝟐 𝑰)−𝟏 𝒌(𝑿∗, 𝑿)
𝑫 = {(𝑿 𝟏 , ∝1), (𝑿 𝟐 , ∝2), (𝑿 𝟑 , ∝3)}
= { (4,2, -67), (3,7, -75), (6,7, -70) }
1 2 3 4 5 6 7
1
2
3
4
5
6
7
8
𝜇(𝑋∗) = 2.6 2.6 4.1 0.7 -0.1 -0.2 -67
-0.1 -0.3 0.6 -75
-0.2 0.6 -0.2 -70
𝑐𝑜𝑣 𝛼 𝑝, 𝛼 𝑞 = 𝜎𝑓
2
𝑒𝑥𝑝 −
𝑋 𝑝−𝑋 𝑞
2
2𝑙2 + 𝜎 𝑛
2
δ 𝑝q
Let’s try σf
2
= 5 , l2 = 10, σn
2
= 2
Let’s test at X* = (6,5) K(X*,X)T = 2.6 2.6 4.1
Access Point Target
AP1AP2
AP3 AP4
Fingerprints

Gaussian Process: putting multiple APs together
Isolating the different APs contributing to the final location… pointers from the
chart of which APs contribute to the final decision:
27. Signal stronger
than expected…
41. Signal stronger
than expected…
59. Pretty good… 71. Pretty good…
This plot shows that the measured (orange) RSSI values from
almost every AP were much higher than expected (grey).
Maybe an anomalous scan? How many of them are there?
Can we spot them and discard/adjust?
(Triangles are probabilities: when the orange and grey dots
are close together, probability is high.)

Gaussian Process probability map
Multiple overlaid countour
plots of probability of RSSI x
from APy

Gaussian Process: visualized track
Track of ‘unknown’(not labeled with
ground-truth) scan points.
These were taken with the periodic
scan function whilst walking the
floor to take fingerprint points. The
points on a line are consecutive but
time differences are not measured.
(Conditions: AP tx pwr, AP-AP
calibration, linear propagation
model, 20 test points as training
points, mean error from known
points ~2.9m.)

Next-generation location engines: “Machine Learning”
Non-parametric: No physics knowledge required
Combine many types of input data
Automatic relevance determination discards un-useful data
“Train” with massive amounts of data
Significant computation to build the model, much less to exercise the model
Image recognition Speech recognition Text translation
Gallia est omnis divisa
in partes tres, quarum
unam incolunt Belgae,
aliam Aquitani, tertiam
qui ipsorum lingua
Celtae, nostra Galli

Using multiple data sources - example
Traditional
‘fingerprints’: test
points measured on the
floor
AP14
AP – AP calibration
from Airwave
(APx,y, APtxpwr , APrssi )
AP transmit power
(helps device-side)
Differences between network-side and device-
side
AP sees device RSSI and knows its (AP’s)
location but does not know tx pwr.
Device sees AP RSSI but does not know AP
location or tx pwr (esp. with ARM)
Multiple APs can hear the same frame, device can
only hear non-associated APs when scanning.
Multiple APs can make RSSI measurements on
data frames, probe requests… device only makes
measurements on current connection and when
scanning.
… but sleeping devices are difficult to locate from
the network
D = { (X1, Y1), (X2, Y2), (X3, Y3), (X4, Y4)… (Xn, Yn) }

Crowdsourcing and Statistics
Fingerprinting for the modern world, machine-
learning-style
Collect wads of data…
Let the data self-organize…
Let the data self-adjust
Floorplan interpretation helps (identify walls,
doors, corridors)
Combination of methods with independent errors
provides increased accuracy
Network-side analysis or client-side app reporting
data in foreground or background

Particle filters: time series
Particle filters or Sequential Monte Carlo (SMC) methods are a set of on-line
posterior density estimation algorithms that estimate the posterior density of the state-space by
directly implementing the Bayesian recursion equations. (Wikipedia)
One of many methods of applying Bayes’ theorem to sequential noisy data. Easily
implemented in code, allows for errors in prior estimates.
I think we were here…
We have new data…
So where could we be
now?
Generate many possible
new locations based on
prior estimates.
Assess the likelihood of
each possible location in
the light of new readings.
Pick the likeliest and
repeat.

Neural networks and deep learning
inputs
inputs
inputs
inputs
inputs
dog
cat
goat
yes/no
a
b
+1
Output = f ( w1a +w2b + w31 )
sigmoid function
+1
-1
Accepts differing input types
Requires massive amounts of “training” data
Can self-train with unlabeled data
Not too difficult to program

THANK YOU
76#ATM15 | @ArubaNetworks

Sign up, save $200!
arubanetworks.com/atmosphere2016
Give feedback!
… Before You Go
atmosphere
2016

Deep dive: Radio technologies for indoor location

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Deep dive: Radio technologies for indoor location

Similar a Deep dive: Radio technologies for indoor location (20)

Más de Aruba, a Hewlett Packard Enterprise company

Más de Aruba, a Hewlett Packard Enterprise company (20)

Último

Último (20)

Deep dive: Radio technologies for indoor location

Notas del editor