Deep Dive Radio Technologies For Indoor Location Small

Location Technologies
Peter Thornycroft
March 2015
#ATM15 | @ArubaNetworks
Agenda
•  General location requirements •  Twists and practical considerations
–  Users of location data –  iBeacons
–  Client-side vs Network-side –  Hyperbolic techniques
–  Sleeping clients
•  Technologies for raw data –  Scrambled MAC addresses
–  Wi-Fi Signal Strength
•  Calculating location
–  Wi-Fi Time of Flight / Time Difference of Arrival
–  Triangulation on RSSI
–  Wi-Fi Direction / Angle of Arrival
–  Ray-tracing models
–  Bluetooth Low Energy
–  GPS –  Fingerprinting
–  Inertial sensors –  Crowd-sourcing
–  Synthetic heat maps
–  Neural networks
#ATM15 | @ArubaNetworks 2 CONFIDENTIAL © Copyright 2015. Aruba Networks, Inc. All rights reserved
General location requirements
Accuracy: Cost/complexity
1.  For bake-offs, PoC, beat competition to 1.  Minimize extra hardware requirements (sales/capex):
sub-metre new hardware or more APs
2.  For client-side navigation, 2m accuracy, 2.  Software upgrade to ‘legacy’ hardware
real-time 3.  Minimize extra installation/calibration requirements
3.  For analytics, avg 5m accuracy, not real- (sales/professional services)
time 4.  Minimize ongoing professional services requirements
4.  Everyone’s goal: sub-metre accuracy, real-
time
Serve all client stances
Serve all client populations 1.  Un-associated devices under WLAN coverage
1.  iPhones/iPads: minimal scanning, no onboard 2.  Associated devices
scan data, reasonable BLE support 3.  Associated and with our app running
2.  Android: better characteristics, especially with
an app
3.  PCs: most amenable, but least important Performance considerations
4.  IoT/M2M devices: not significant yet but 1.  Minimize extra battery draw
emerging 2.  Minimize frames on the air (congestion)
#ATM15 | 3 CONFIDENTIAL © Copyright 2015. Aruba Networks, Inc. All rights reserved
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: Network-side:
Navigation Analytics
Customer engagement “How many people
Location visited my store?”
engine
“What kind of
people and what
were they doing?”
“Am I in
Kansas?”
“What’s
around me?”
Very fast calculation High volume
Very accurate Slower calculation
Needs a map & AP locations Map & AP locations are known
Own-app combines the models
Cloud service CRM etc

Network-side:
Provide context (AP locations, maps, calibration)
Determine actions
Push notifications
Location
engine
Client-side:
Sense & calculate location
Provide consumer services (navigation)
Report context to cloud service
Aruba’s location architecture (roughly)
Third-party integration with Analytic Partner provides data Meridian provides integration
customer database, ad analysis and integration with customer with ad networks and coupon
networks and coupon engines database and other data sources engines
Meridian Service
Custom service Analytic engine
Custom software
takes location & ALE App uses Meridian
context directly from SDK for location &
AirWave AirWave location context (or
ALE and feeds client
app on device Controller Controller turnkey app from
Meridian)
The Aruba WLAN provides raw data about devices,

users, signal strength etc. to ALE which calculates
location and aggregates context across the entire network
Over-the-top location
Google Maps
“I am at Lat… Long…, Here’s a map for your

give me a map Lat… Long…
“Internet”
Cellular data Wi-Fi
Bluetooth GPS
LE beacons satellites
No interaction with the Inertial

WLAN celltower scan sensors Wi-Fi scan
with triangulation BSSID list
Target population
Un-associated: Associated: Associated with our app:
Track for analytics Limited interaction Full interaction
“Anyone “Web “MyStore

about?” browsing…” app”
Infrequent probe requests Report true MAC address Full platform-infra interaction
Scrambled MACs Monitor traffic Advertising
Limited push capability Navigation
Distance vs Location, frames of reference
x
Location
(45, 76) Local coordinates
Location 12.2 9.7 Easy
(32, 78)
Private
y
11.5
4.4
longitude
Location Location
(37, 98) (48, 99) Global coordinates
Tricky to fix
Clients range relative to APs/beacons Universal
But how does that relate to ‘location’? Arbitrary accuracy
-  Requires knowledge of AP locations
-  Requires a map with frame of latitude
reference
The general RSSI location problem
AP 13 AP 11
Given a “training” set of
data showing expected -46
RSSI at a set of APs from -70
test targets with given tx -51
pwr at a given location, -43
Received signal -46

And given a set of actual strength (dBm) -75
RSSIs from a given target -51 AP 10
at an unknown location, AP10 -41 -43
AP11 -73
Find the most likely AP12 -47
AP13 -50 -42
location of the target. -75
-41
-69
AP 12
The general RSSI location problem
Given a set of RSSI readings at (or of) AP’s:

AP2 AP1
AP1: - 71dBm
AP2: - 67dBm
AP3: - 80dBm
AP4: - 73dBm
Find the most likely location of the target
Location {!∗,"#∗} or X*
AP3 AP4
given ["$%%&1,"$%%&2,"$%%&3,"$%%&4"] or Y
or... (loosely) Find ( X* | Y )

Access Point Target
Technologies
#ATM15 | @ArubaNetworks 13 13
Wi-Fi RSSI: signal attenuates with distance (etc)
5m indoors
10 dB
Signal strength (dB scale)
wall
100m 50m
‘free space’ ‘wooded region’
100m 6 dB
‘free space’ wall
5m indoors
transmitter receiver
Distance
Wi-Fi RSSI variation with distance
Free Space Path Loss dB =20"'()10(+)+20'()10(-)−20'()10(4π/0 )
Path loss in dB / m for 2450 kHz and 5500 kHz Path loss in dB / m for 2450 kHz and 5500 kHz
0 5 10 15 20 25 30 35 40 1 10
40.0 40.0
2450 kHz 2450 kHz
45.0 45.0
50.0 5500 kHz 50.0 5500 kHz
55.0 55.0
60.0 60.0
65.0 65.0
70.0 70.0
75.0 75.0
80.0 80.0
85.0 85.0
At 2450 kHz dB =20"'()10(+)+10.2

At 3m 50dB, at 10m 60dB 5500 kHz is 7dB worse
At 5500 kHz dB =20"'()10(+)+17.2
At 3m 57dB, at 10m 67dB than 2450 kHz
Wi-Fi RSSI variation with distance
Path loss in dB / m for 2450 kHz and 5500 kHz

0 5 10 15 20 25 30 35 40
40.0
2450 kHz
45.0
50.0 5500 kHz
55.0
Longer distance
60.0
>> fewer dB/m 65.0
>> Less accurate 70.0
75.0
80.0
85.0
Wi-Fi RSSI: offices are not free-space
Free Space Path Loss dB =2"'()10(+)+20'()10(-)−20'()10(4π/0 )
Power level with distance, for different exponents n Power level with distance, for different exponents n
-40 -40
-50 -50
-60 -60
Path loss (dB)
N = 20 N = 20
Path loss (dB)

-70 -70
N = 25 N = 25
-80 -80
N = 30 N = 30
-90 -90
N = 35 N = 35
-100 -100
N = 40 N = 40
-110 -110
-120 -120
0 10 20 30 40 50 1 10
Distance from transmitter (meters) Distance from transmitter (meters)
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 Very noisy (inaccurate)
averages well Varies over time
Varies with environment
RSSI depends on tx power and antenna directionality
Variation of signal strength with distance, lin scale

60.0
Signal strength indication (SNR,
50.0 y = -1.3291x + 48.9

40.0
30.0
dB)
20.0
10.0
0.0
0 5 10 15 20 25 30 35
Distance from AP (meters)
Varies over distance Varies over time

Wi-Fi RSSI empirical data
Measuring different frames for RSSI
Probe requests & Mgmt frames: Data frames: Acks:

Low rates Plentiful Plentiful
Predictable tx pwr Vary in tx pwr Vary in tx pwr
Scarce No source address field
Measuring RSSI walk-around test
Access point
monitored
75
Route followed
through the
D building
E
AL40
100 C 42
Time and
distance on route
F (at 1m/s)
G 20
130 B 20
Scale 10m
148 H
Finish Start
168 A 0
Actual RSSI readings from walk-around test
Angle of Arrival
δ1
δ1
Stronger form of CSI or multi-dipoles

Resolve direction or pattern
Use with other techniques
AoA calibrating azimuth & fingerprinting
Easiest to calibrate on known-location AP For NLOS, fingerprint the signature of

a location
1 orients; 2 + distance, or 3 triangulate
LOS or NLOS Beware of NLOS

Calibration of azimuth
Cost of hardware Need to be in a plane or close to it
GPS
“Why can’t
Wi-Fi be more
like GPS?
So good we don’t notice it Depends on seeing the satellites

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

A standard (actually two Once all four timestamps
standards and several are in one place,
proprietary variants) subtraction and /2 gives
time-of-flight and
“802.11k” Location Track multiply-by-speed-of-light
Notification, modified (to t1 gives distance
t4
finer timestamps) in Ack
“802.11mc” Measure
Fine Timing with me!
Measurements d = ((t4 – t1) – (t3 – t2)) * c / 2
Now here
are my t2 t3
Here’s the
first frame times t1, t4
Hyperbolic variations on time-based location
Not one-to-one distance
measurement, but many-to-
RTT RTT one or one-to-many
exchange exchange
Reduces the number of
frame
frames on the air, improves exchange
battery life
Client-side hyperbolic Network-side hyperbolic

Requires an AP-AP schedule Requires a stimulation schedule
APs and/or client channel-switch Requires AP –AP RTT
Both sides must use RTT standard APs channel-switch
Works with all clients
RTT: Calculating the AP constellation
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
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 UUID: Aruba

Major: 1000 Major: 1000
Minor: 501 Minor: 502
-76 -66
-68 -82
UUID: Aruba UUID: Aruba

Major: 1000 Major: 1000
Minor: 503 Minor: 509
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
Ch 37 Ch 38 Ch 39
(2402 MHz) (2426MHz) (2480MHz)
Bluetooth Low Energy Advertisement (iBeacon)
1 Wi-Fi 6 11
2402 2412 2422 2427 2437 2447 2452 2462 2472
2400 2483.5
2 MHz channels Advertisements are one-way transmissions. An

advertisement can be sent on any/all of the 3 designated
Gaussian Frequency Shift Keying channels
0.5 modulation index
Advertisements are repeated every 20 – 10000 msec
1 Msymbol/second rate (500msec typ)
1 Mbps data rate
Tx power ~ 0 dBm ( ~ 2 year battery life typ)
~250 kbps application throughput
(in connection mode) Apple specifications for iBeacons are more constrained (but
not widely followed)
BLE Advertisement and iBeacon
iBeacon information
BLE Advertisement Frame RSSI Measured by receiver
Preamble Advertiser PDU CRC MAC From BLE header

1 4 2 - 39 3
8E89BED6 Proximity UUID (can be) company reference
Major, Minor Integer values identifying the

BLE Advertisement Payload tag and/or zone
Header MAC address Data
2 6 1 - 31 Measured Tx Pwr Calibrated power at 1m from
size, type.. e.g. 112233445566 the iBeacon (dBm)
iBeacon Data
iBeacon Prefix Proximity UUID Major Minor Measured Tx Pwr
9 16 2 2 2
0201061AFF4C000215 e.g. 4152554e-f99b-86d0-947070693a78 e.g. 4159 e.g. 27341 e.g. -59
iBeacon RSSI vs distance
iBeacon RSSI (dBm) vs distance (m), line iBeacon RSSI (dBm) vs distance (m), line of
of sight sight
(RSSI averaged over 5 readings) -50
-50 -55
-55 -60
-60 -65
-65 -70
-75
-70
-80
-75
-85
-80
-90
-85
-95
-90
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 -100
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
GS4 with iBeacon 100 GS4 with iBeacon 101
GS4 with iBeacon 100 GS4 with iBeacon 101
Nexus 7 with iBeacon 100 Nexus 7 with iBeacon 101
Nexus 7 with iBeacon 100 Nexus 7 with iBeacon 101
grand average
iBeacon Tx power 0dBm ‘measured power’ -61dBm @ 1 m

Inertial sensors (“sensor fusion”)
Accelerometer Gyroscope Magnetometer Barometer
(motion & gravity) (rotation) (direction) (altitude)
N
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

Twists & practical
considerations
Techniques and constraints
Heatmap Model Constraints Prediction Models etc
i.  Floorplan i.  Snap to tramlines i.  Sparse samples
ii.  Place APs ii.  Motion constraints ii.  Stimulation
iii.  Calibrate AP-AP iii.  Motion boolean iii.  Gaussian Process
iv.  Training data iv.  Right floor iv.  Bayes
v.  Ground truth locations v.  AP Tx Pwr v.  Neural Networks
vi.  Other a-priori vi.  Target Tx Pwr vi.  Graphs Nodes*Edges
vii.  History vii.  Not heard by AP vii.  Inertial navigation
viii.  Out-of-bounds areas
Active techniques Type of client Auto-RF-tuning

i.  Stimulate client i.  Tag i.  Frequency of changes
ii.  Calibration points ii.  Non-Assoc or Assoc ii.  Higher Tx Pwr
iii.  Client assist iii.  Static or Mobile iii.  AP placement
iv.  Traffic generated iv.  Phone less sensitive &
accurate than APs
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, Example LCI
URL Latitude 37.381814, uncertainty 1 metre
Longitude -121.986111, uncertainty 1 metre
–  In Neighbour Report (associated) Altitude 2.7 metres, uncertainty 2 metres
–  Passpoint (ANQP) (pre-association) in Z co-ord Height above floor 4 metres, uncertainty 0.5 metres
Neighbour Report
Example civic address
Type Local Name Description Value
Over the top e.g. http/xml/SOAP/JSON 0 language en
1 A1 national subdivision CA
–  Various near-standards 3 A3 city Santa Clara
34 RD primary road or street Garrett
Over the top telco standards 18 STS street suffix or type Drive
19 HNO house number 3400
–  e.g. OMA-SUPL 24 PC postal / zip code 95054
Proprietary protocols
–  e.g. AirWave XML API
–  ALE REST, pub-sub
–  Qualcomm IZAT
Why iBeacons matter on iDevices
Database of UUID-
Major-Minor to locations
(part of the app server)
Mobile App
Register for < 20
UUIDs
The iOS app lifecycle puts an app on ice when not in foreground.
Woken from How to wake up on proximity to a particular location?
background when
iOS –  iOS maintains BLE in always-listening mode
UUID heard
–  If the app registers for a UUID, iOS will awaken it when that UUID is
seen
–  Event is a ‘region entry/exit’
Continuously
scanning for BLE radio –  iBeacon background detection can take minutes
iBeacons
Even in foreground, iOS will only return data on known, specified
UUIDs
BLE air interface –  ‘Ranging mode’ in foreground gives RSSI every ~ 1 second
Android makes a much more flexible iBeacon hunter

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

Off-channel scans discover neighbors’ beacons red: naturally-generated probe requests
Build up a table of neighbor beacons, channel, offsets from OTA measurements blue: stimulated probe requests
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
iPhone, associated, black screen
Go to neighbour’s channel milliseconds before super-beacon red: naturally-generated probe requests
Listen for transmissions from the AP and capture corresponding acks from clients blue: stimulated probe requests
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? New behavior when Switch to conventional mode
checking for Wi-Fi
When checking for network presence, Uses correct MAC when seeking to
probe request broadcasts: associate
When not associated, not seeking
-  Always include device MAC
association:
-  Can include SSID “14ParkRoad”
- Use random MAC
Probe request frame
“14ParkRoad” “RandomMAC”
or
“broadcast”
-  Reveal information about the device -  Pre-association probe request uses

while in unknown surroundings -  Random MAC uses locally-
correct MAC address
administered addresses
-  All subsequent exchanges use correct
x2:xx:xx:xx:xx:xx
MAC address
x6:xx:xx:xx:xx:xx
xA:xx:xx:xx:xx:xx
xE:xx:xx:xx:xx:xx
- Apple first, more to follow
Calculating location
Location engines
Last-generation location engines
Divide floorplan into grid ( ~ 2 metre squares) Estimate RSSI for each AP in each square Pick the most likely square
AP 13
-6dBm AP 11
-2dBm
-3dBm -8dBm
-0dBm 3dBm
6dBm 9dBm
10dBm
AP 10
14dBm 17dBm
10dBm
6dBm
2dBm AP 12
2dBm
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
5m indoors Rappaport et. al.

An improvement on triangulation
10 dB Cumbersome to implement
Signal strength (dB scale)
wall
100m 50m
‘free space’ ‘wooded region’
100m 6 dB
‘free space’ wall
5m indoors
transmitter receiver
Distance
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)… AP2 AP1
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 AP3 AP4

client software,
Or multi-mode location (one mode Access Point Target
checks the other) Fingerprints
Or crowd-sourcing (apps on users’
phones or data crunching)
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 Snap to fingerprint point or Interpolation more
>> click at beginning and end, app interpolates distance snap to tramlines: difficult but more
>> add some inertial sensor readings to improve accuracy Instant accuracy improvement! accurate.
(Blocking out impossible areas
can also help.)
Fingerprinting – Up vs Dn and corrections
Client-side fingerprinting: Cloud
- Location is known from touch on floorplan etc. service
- 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
Location
engine
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
Domain knowledge Training data Test points
Make a model for a

Tune the model with Apply test points
general form of the Results
data to the tuned model
problem
We have some idea of the We take some ‘training’ Take an unknown set of test
form of the problem and data and use it to set up points and find the most
solution. This influences the model. likely values.
the architecture of the
model. Invoke Bayes
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 Bayes’ Theorem
-  Easily computed on a variety of platforms (matrix algebra, software libraries) 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 Find the likelihood Find the most likely Apply a time-based
heatmaps / reverse of each location per- location due to this probabilistic
heatmaps AP, given RSSI test vector of RSSIs adjustment
AP14
AP27
AP45
Fingerprinting in the calculations
What do we know? AP2 AP1

>> ‘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) }

AP3 AP4
Now… the problem becomes:
Find ( X* | Y, D ) Access Point Target

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
Domain knowledge Training data Test points
Make a model for a

Tune the model with Apply test points to
general form of the Results
data the tuned model
problem
Output: ‘most
likely’
value -0.5
with 95%
confidence
bounds of
What’s so useful about the Gaussian Process? Input = 3.8 -0.5 +- 1
-  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 Diagrams from ‘Rasmussen & Williams’ 2006
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)

↓T =(!↓2 ,"#↓2 )?with?RSSI?value?Y↓2 
R
Set?of?training?points?D?consists?of?known?locations?
Z={(R↓4 ,"∝↓1 ),?(R↓6 ,"∝↓2 ),?(R↓7 ,"∝↓3 ),?…(R↓8 ,"∝↓4 )}
Training?points?are?sets?of?RSSI?values?taken?at?known?points.

The?covariance?function?is?arbitrarily?de_ined?as?a?Radial?Basis?Function?(RBF)?????????????????
?0(b(Y↓c ,"Y↓d )="e↓-↑2 g!c⁠(−(h↓c −h↓d )↑2 /2'↑2  ) +"e↓2↑2 δcq
Where?e↓- ,"e↓2 ,"'"are?hyperparameters?that?determine?scale?and?accuracy?constraints?on?the?resulting?function.?
(σ↓2↑2 k?adds?the?noise?factor?for?the?difference?between?modeled?and?measured?values).

Constructing?matrices?for?input?points?(X),?rssi?values?(Λ)?and?covariance?(K)???? 0(b(o)=p+"σ↓2↑2 q??????

When?we?have?a?new?point? ↓∗ =(!↓∗ ,"#↓∗ )?and?wish?to?_ind?the?expected?RSSI?∝↓∗ =-(R↓∗ )from??
R
c(Y↓∗ |"R↓∗ ,"R,"o)="<(α↓∗ ";""t↓h↓∗  ","e↓h↓∗ ↑2 )??
The?expected?mean?for??∝↓∗ ,""""""""""t↓h↓∗  =u(R↓∗ ,"R)↑v (p+"w↓T↑6 q)↑−4 o
#ATM15 |
The?variance?for??∝↓∗ ,"""""""""""""""""""""""""e↓h↓∗ ↑2 =""u(R↓∗ ,"R↓∗ )"−x(R↓∗ ,"R)↑v (p
65 CONFIDENTIAL © Copyright 2015. Aruba Networks, Inc. All rights reserved
Gaussian Process for curve-fitting: examples
Same training data, different hyperparameters

Gaussian Process numerical example
The expected mean for ∝∗, ?(@∗) =A(B∗, B)C (D+ EF6 G)−4 H 1 2 3 4 5 6 7
The variance for ∝∗, I(@∗)2 = A(B∗, B∗) −J(B∗, B)C (D+ EF6 G)−4 J(B∗, B)
1
K = {(B4 , 1), (B6 , 2), (B7 , 3)} 2 AP2 AP1
= { (4,2, -67), (3,7, -75), (6,7, -70) } 3
0(b(Y↓c ,"Y↓d )="e↓-↑2 g!c⁠(−(h↓c −h↓d )↑2 /2'4 ↑2  ) +"e↓2↑2 δc q
5
Let’s try σ↓f↑2  5 , l = 10, σ↓n↑2  = 2
=
2
6
7
K = cov(X1, X1) cov(X1,X2) cov( X1,X3) = 2 1.4 1.2 8
cov(X2, X1) cov(X2,X2) cov( X2,X3) 1.4 2 3.2
1.2 3.2 2
cov(X3, X1) cov(X3,X2) cov( X3,X3)
Let’s test at X* = (6,5) K(X*,X)T = 2.6 2.6 4.1 AP3 AP4
?(@∗) = 2.6 2.6 4.1 0.7 -0.1 -0.2 -67

-0.1 -0.3 0.6 -75 Access Point Target
-0.2 0.6 -0.2 -70
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 41. Signal stronger 59. Pretty good… 71. Pretty good…
than expected… than expected…
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”
Gallia est omnis divisa

in partes tres, quarum
unam incolunt Belgae,
aliam Aquitani, tertiam
qui ipsorum lingua
Celtae, nostra Galli
Image recognition Speech recognition Text translation
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
Using multiple data sources - example
Differences between network-side and device-
side
Traditional
‘fingerprints’: test AP14 AP sees device RSSI and knows its (AP’s)
points measured on the location but does not know tx pwr.
floor Device sees AP RSSI but does not know AP
location or tx pwr (esp. with ARM)
AP – AP calibration
from Airwave Multiple APs can hear the same frame, device can
(APx,y, APtxpwr , APrssi ) 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
AP transmit power
scanning.
(helps device-side)
… 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
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… Generate many possible

We have new data… Assess the likelihood of Pick the likeliest and
new locations based on each possible location in
So where could we be prior estimates. repeat.
the light of new readings.
now?
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)
Neural networks and deep learning
+1
inputs
a -1
sigmoid function
inputs dog
b yes/no
inputs cat
+1
inputs goat
Output = f ( w1a +w2b + w31 ) inputs
Accepts differing input types

Requires massive amounts of “training” data
Can self-train with unlabeled data
Not too difficult to program
THANK YOU
#ATM15 | @ArubaNetworks 76
… Before You Go
Give feedback! Sign up, save $200!
atmosphere
2016
arubanetworks.com/atmosphere2016

Deep Dive Radio Technologies For Indoor Location Small

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Deep Dive Radio Technologies For Indoor Location Small

Diunggah oleh

Hak Cipta:

Format Tersedia

Location Technologies

Cloud service CRM etc

The Aruba WLAN provides raw data about devices,

“I am at Lat… Long…, Here’s a map for your

No interaction with the Inertial

“Anyone “Web “MyStore

Received signal -46

Given a set of RSSI readings at (or of) AP’s:

Find the most likely location of the target

or... (loosely) Find ( X* | Y )

At 2450 kHz dB =20"'()10(+)+10.2

Path loss in dB / m for 2450 kHz and 5500 kHz

Path loss (dB)

Variation of signal strength with distance, lin scale

50.0 y = -1.3291x + 48.9

Varies over distance Varies over time

Probe requests & Mgmt frames: Data frames: Acks:

Stronger form of CSI or multi-dipoles

Easiest to calibrate on known-location AP For NLOS, fingerprint the signature of

LOS or NLOS Beware of NLOS

So good we don’t notice it Depends on seeing the satellites

RTT/FTM protocol Distance Calculations

Client-side hyperbolic Network-side hyperbolic

The most time-consuming and error-prone step when

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

With known, accurate distances between each pair of

Then rotate and shift the constellation over the

And use that to scale the floorplan

UUID: Aruba UUID: Aruba

UUID: Aruba UUID: Aruba

2 MHz channels Advertisements are one-way transmissions. An

BLE Advertisement Frame RSSI Measured by receiver

Preamble Advertiser PDU CRC MAC From BLE header

Major, Minor Integer values identifying the

iBeacon Tx power 0dBm ‘measured power’ -61dBm @ 1 m

Accelerometer, Gyro, Compass, all 3-axis (& sometimes barometer)

Manufacturers adding dedicated, continuously-running processor to the platform

Active techniques Type of client Auto-RF-tuning

Today, nearly all WLAN location is 2-dimensional

For sub-metre accuracy, 3-D models are required.

Android makes a much more flexible iBeacon hunter

Find a BLE-capable device

Nexusy7, associated, black screen

Keep track of beacon sequence numbers (to identify super-beacon timing)

Establish ‘best’ scanning schedule

Key problems with iBeacons:

Is the battery failing?

Shorter distances >> more accuracy

But… APs / AMs are expensive, need Ethernet & Power

So… can we make a monitor more like an iBeacon?

- Reveal information about the device - Pre-association probe request uses

Derive distance from path loss (RSSI

Draw a radius from each AP

Derive distance from path loss (RSSI

Draw a radius from each AP

This is a joke, right?

5m indoors Rappaport et. al.

If manual, this is tedious:

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?

-  Reveal information about the device -  Pre-association probe request uses