Deep dive: Radio technologies for indoor location

#ATM15 |

Location TechnologiesPeter 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 ServiceCustom 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 listcelltower scan

with triangulation

GPS

satellitesBluetooth

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

Sig

nal

stre

ngth

(d

B s

cale

)

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

Pa

th 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

Pa

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


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

na

l s

tren

gth

in

dic

ati

on

(S

NR

, d

B)

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

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

exchangeRTT

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

Sig

nal

stre

ngth

(d

B s

cale

)

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

= 5 , l2 = 10, σn2 = 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.

http://en.wikipedia.org/wiki/Density_estimation

http://en.wikipedia.org/wiki/Recursive_Bayesian_estimation


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

Technology

Deep dive: Radio technologies for indoor location