Peter Thornycroft - Airheads Community...#ATM15 | Location Technologies Peter Thornycroft March 2015 @ArubaNetworks

#ATM15 |

Location Technologies Peter Thornycroft

March 2015

@ArubaNetworks

CONFIDENTIAL © Copyright 2015. Aruba Networks, Inc. All rights reserved

2 #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)


#ATM15 |

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)


#ATM15 |

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


#ATM15 |

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


#ATM15 |

Aruba’s location architecture (roughly)

ALE

Meridian Service Custom service

Controller Controller

AirWave AirWave

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


#ATM15 |

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


#ATM15 |

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”


#ATM15 |

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


#ATM15 |

The general RSSI location problem

AP 12

AP 11 AP 13

AP 10

-46 -75 -51 -43

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


#ATM15 |

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 )

AP1 AP2

AP3 AP4

13 13 #ATM15 |

Technologies

@ArubaNetworks


#ATM15 |

Wi-Fi RSSI: signal attenuates with distance (etc)

transmitter receiver

10 dB wall

6 dB wall

100m ‘free space’


50m ‘wooded region’

5m indoors

5m indoors

Sign

al st

reng

th (d

B sc

ale)

Distance


#ATM15 |

Wi-Fi RSSI variation with distance

Free Space Path Loss dB =20"'()10(+)+20'()10(-)−20'()10( 4π/0 )

dB =20"'()10(+)+17.2 dB =20"'()10(+)+10.2 At 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 5 10 15 20 25 30 35 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


#ATM15 |

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 5 10 15 20 25 30 35 40


2450 kHz

5500 kHz


#ATM15 |

Wi-Fi RSSI: offices are not free-space

Free Space Path Loss dB =2"'()10(+)+20'()10(-)−20'()10( 4π/0 )

-120

-110

-100

-90

-80

-70

-60

-50

-40

0 10 20 30 40 50

Pat

h lo

ss (d

B)

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

Pat

h lo

ss (d

B)

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.


#ATM15 |

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

Sig

nal s

tren

gth

indi

catio

n (S

NR

, dB

)

Distance from AP (meters)

Variation of signal strength with distance, lin scale

Varies over time Varies over distance

Very noisy (inaccurate) Varies over time Varies with environment RSSI depends on tx power and antenna directionality


#ATM15 |

Wi-Fi RSSI empirical data


#ATM15 |

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


#ATM15 |

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

0 A

B

C

D

E

F

G

H


#ATM15 |

Actual RSSI readings from walk-around test


#ATM15 |

Angle of Arrival

Stronger form of CSI or multi-dipoles Resolve direction or pattern Use with other techniques

δ1 δ1


#ATM15 |

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


#ATM15 |

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?


#ATM15 |

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 distance 1m

10m

20m 1m 25m 50m 75m 100m

RTT

RSSI

Scheduled periodic bursts

t4


#ATM15 |

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


#ATM15 |

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


#ATM15 |

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


#ATM15 |

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+


#ATM15 |

iBeacon deployment model for navigation

UUID: Aruba Major: 1000 Minor: 501




-66

-68

-76

-82


#ATM15 |

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


#ATM15 |

Spectrum for iBeacons & BLE

6 11 2412 2437 2462 2422 2402 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)


#ATM15 |

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)


#ATM15 |

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


#ATM15 |

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)

37 37 #ATM15 |

Twists & practical considerations

@ArubaNetworks


#ATM15 |

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


#ATM15 |

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.


#ATM15 |

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


#ATM15 |

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)


#ATM15 |

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


#ATM15 |

iBeacon hunting with Android

Find a BLE-capable device Run the app


#ATM15 |

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


#ATM15 |

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


#ATM15 |

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.


#ATM15 |

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?


#ATM15 |

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

49 49 #ATM15 |

Calculating location Location engines

@ArubaNetworks


#ATM15 |

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


#ATM15 |

RSSI & triangulation

Derive distance from path loss (RSSI and tx pwr)

Draw a radius from each AP


#ATM15 |

RSSI & triangulation

Derive distance from path loss (RSSI and tx pwr)

Draw a radius from each AP

This is a joke, right?


#ATM15 |

Ray-tracing approach to propagation prediction

transmitter receiver

10 dB wall

6 dB wall



50m ‘wooded region’

5m indoors

5m indoors

Sign

al st

reng

th (d

B sc

ale)

Distance

Rappaport et. al. An improvement on triangulation Cumbersome to implement


#ATM15 |

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?


#ATM15 |

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

AP1 AP2

AP3 AP4

Fingerprints


#ATM15 |

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


#ATM15 |

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.


#ATM15 |

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


#ATM15 |

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)


#ATM15 |

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 points Domain 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)


#ATM15 |

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


#ATM15 |

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


#ATM15 |

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 )

AP1 AP2

AP3 AP4

Fingerprints

But fingerprinting is still cumbersome. Automated fingerprinting systems with smartphones and multi-mode location may solve all our problems.


#ATM15 |

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 points Domain knowledge

Diagrams from ‘Rasmussen & Williams’ 2006

Results

Input = 3.8

Output: ‘most likely’ value -0.5 with 95% confidence bounds of -0.5 +- 1 What’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


#ATM15 |

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?R↓T =(!↓2 ," #↓2 )?with?RSSI?value?Y↓2  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?R↓∗ =( !↓∗ ," #↓∗ )?and?wish?to?_ind?the?expected?RSSI?∝↓∗ =-( R↓∗ )from??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 The?variance?for??∝↓∗ ,""""""""""""""""""""""""" e↓h↓∗ ↑2 =""u(R↓∗ ," R↓∗ )"− x(R↓∗ ,"R)↑v (p+" w↓T↑6 q)↑−4 x( R↓∗ ,"R) 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??(z+" e↓2↑2 k)↑−1 ?which?is?nxn?for?the?training?set.


#ATM15 |

Gaussian Process for curve-fitting: examples

Same training data, different hyperparameters


#ATM15 |

= 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 ∝∗, ?(@∗) =A(B∗, B)C (D+ EF6 G)−4 H The variance for ∝∗, I(@∗)

2 = A(B∗, B∗) −J(B∗, B)C (D+ EF6 G)−4 J(B∗, B)

K = {(B4 , �1), (B6 , �2), (B7 , �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

0(b(Y↓c ," Y↓d )=" e↓-↑2 g!c(− (h↓c − h↓d )↑2 /2'↑2  ) +" e↓2↑2 δcq

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

AP1 AP2

AP3 AP4

Fingerprints


#ATM15 |

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


#ATM15 |

Gaussian Process probability map

Multiple overlaid countour plots of probability of RSSI x from APy


#ATM15 |

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


#ATM15 |

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


#ATM15 |

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


#ATM15 |

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


#ATM15 |

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.


#ATM15 |

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


#ATM15 |

Sign up, save $200!

arubanetworks.com/atmosphere2016

Give feedback!

… Before You Go

atmosphere 2016

Documents

Peter Thornycroft - Airheads Community...#ATM15 | Location Technologies Peter Thornycroft March 2015 @ArubaNetworks