WLAN Design for Location

CONFIDENTIAL
© Copyright 2014. Aruba Networks, Inc. All rights
reserved
WLAN Design for Location
Abhi Maras
June 2014

CONFIDENTIAL © Copyright 2014. Aruba Networks, Inc. All rights reserved
Agenda
• Analytics and Location Overview
• ALE System Overview
• Indoor Location Technology
• Probing
• Recommendations
• Summary

Agenda
• Design Guidelines for WiFi grade Location
• Design Guidelines for WiFi grade Voice
• Design Guidelines for WiFi grade Video
• QOS and Traffic Optimization
• Enterprise Diagnostics and Troubleshooting

Analytics & Location Ecosystem
Big Data
Analytics Partners
Network
Applications
Cloud
Applications
User Context
(who, what, where, when)
Location
Applications
(Wayfinding, etc)
Context:
1. Location
2. Applications
3. Destinations
4. Identity
5. Device types
ALE (Context
Aggregation)

Analytics and Location Engine (ALE) Overview
ALE
Unified context for
each user (user name, IP,
MAC, device type, App
visibility, etc.)
1
Seamless, secure
cloud connectivity
4
Real time location
engine
2
Standard, high
performance northbound
APIs (publish/ subscribe,
polling)
3

Data Collected & Provided by ALE
• Presence feed
• Events when a device is detected crossing a Geofence
• Device information
• User information from authentication to the network
• Applications used
• Destination URLs

ALE Enabled Use Cases
ALE Use
cases
People movement,
congested paths
1
Way-finding (turn-
by-turn directions
2
Way-finding (turn-
by-turn directions
Busy times by
location
Web
analytics
Energy
management
4
3
5
6

ALE System Overview
Local
Controller
Remote
Controllers
NETWORK
Instant
APs
Campus/Rem
ote APs
Visual
RF
SERVICES
Context aggregation,
location engine
ALE VM
Location data for
visualization
on maps
APPLICATIONS
Context visualization,
analytics
Northbound APIs:
REST, Protobuf/OMQ
Context
Data

Understanding Probe Flow and Location
ALE
Client pulls its
location from the
cloud every __
seconds?
Probes between few
seconds to 10s of
minutes
1
AP sends RSSI on a timer,
default is 30 secs, can be
set to 1 sec (6.3.1.1)
(Future: Will be
instantaneous)
2
Controller sends the
data on a fixed
timer of 10 seconds
(Future: Will be
instantaneous)
3
ALE calculates the
location, latency
varies based on the
settings.
4

Indoor Location Technology Overview
• Satellite-based GPS does not work indoors
• Two main approaches to
indoor positioning technology:
– Device-based scans of radio signals (software/hardware)
– Network-based scans of device radio signals (Wi-Fi)
• No standard indoor positioning solution exists
today
• Indoor positioning (relative to the venue layout)
requires indoor maps
• Layouts within locations often change

Device vs Wi-Fi Network
Based Location
Device-based software
The device performs signal scans of
nearby network signals to analyzes signal
strengths to calculate position
Wi-Fi network based
The network APs perform signal scans of
Wi-Fi traffic and analyzes the device’s Wi-
Fi signal strength to calculate position

Location Positioning Technology
How Information
is Transmitted
GPS Geofencing
Cell Phone
Triangulatio
n
Cell
Towers
How Info is Transmitted Hardware Required
RequiresOnsiteFingerprinting
BLE
LED Light Pulses
Sensor Fusion
Device-Based Signal
Triangulation
RTLS Network-Based
Wi-Fi Triangulation
Existing Wireless APs
LED Lights With Chips
Wi-Fi Hotspots
BLE
Beacons or Nodes
Wi-Fi Hotspots
Audio Queue
Sound Emission Devices
Outside Venue
Inside Venue

GPS –Triangulation from Satellites

Indoor Location Positioning Technology
Network-Based Wi-Fi Positioning
• Devices are constantly scanning for Wi-Fi
• The network does the work
• Analytics can be delivered without
device app
• More battery efficient for mobile
devices
• Can work with any device, including
iPhones, Android, etc.
 Wi-Fi must be turned
on/enabled on the deviceUsed by:

The Wi-Fi Location Puzzle
• Sparse samples
– Easier & better from infrastructure than from device
– +/- 5dB inter-frame variation
– Clients want to minimize radio activity > maximize battery life
– Floor-level signal differs from ceiling-level
– Absence of signal does not mean a device is absent
• Frame of reference for signal sources / sinks
– Where are the AP locations? Tx Pwr? Directional antennas? – ARM changes RF Plan
• Frame of reference – local or global (Lat/Long) or civic?
– Enterprise and indoor apps mostly use local maps
– Google, Bing etc use Lat/Long
• Parametric or non-parametric?
– Build a synthetic heatmap using RF propagation model
– Or use AP-AP and other calibration and non-parametric curve-fitting (e.g. Gaussian
Process)
• Speed vs accuracy tradeoff
• Add Helpers
– GPS, celltower, Bluetooth beacons, BSSID surveys
– On-board compass, accelerometers
– Estimates for motion vectors and earlier position fixes
– Knowledge of walls, doors and snap-to-grid tramlines

Probing
• Again….location calculation today purely relies on client
probes
– NO PROBES…..NO LOCATION!!
• Unassociated devices will Probe more than associated
– If associated device is happily connected, it will not bother Probing.
• iOS devices Probe less than Android (battery life
considerations).
– Meridian and Aruba Utilities (mobile apps) can stimulate Probes
on Android.
– iOS does not expose any such API (to cause Wi0Fi scan)
• Going on Settings->Wifi on iOS will trigger Probes. If you want
to stimulate Probes on iOS, either unassociate, or
occasionally keep going to the Settings->Wifi page.
• A device must be heard by 3 or more
APs to calculate location

RSSI Based Locationing
• The raw data for location estimation is the
received signal strength (RSSI) of Wi-Fi frames
received from client devices
– RSSI is inherently variable due to fluctuating RF conditions, the
geospatial
attitude of the mobile device
and its proximity and
relationship to human tissue
– We expect a variation of RSSI
in the order of 6dB even when
the person holding the device
is stationary
– As the distance from the AP
increases, the RSSI - distance
curve flattens

Location: Accuracy & Latency
Accuracy
• Impacted by various factors:
– AP density, type, mounting type
– Physical Environments, enterprise, malls,
warehouse, etc.
– RSSI variations
– Client probing behavior, device type,
OS type
Latency
• Impacted by
– Client probe frequency (iOS vs Android)
– Network settings: AP/controller timers
– Engine smoothening algorithms
• Balance between accuracy and latency
ALE goal is to
be <10m 90%
of time on a
location grade
network

Location Applications in PFE
• Location has different facets:
– Presence (Inside a Store/Zone or outside)
• Useful for push notifications
– Wayfinding (“Blue Dot”)
• Useful in ultra large venues
• Most Location applications of
practical value in PFE fall under
“Presence” category
• Location Services are the not the
only “PFE” applications
– Guest Access, support for enterprise apps,
multimedia support, device onboarding,
etc., are all applicable
to PFE
Presence
Way-
Finding

Design Considerations for Locationing
• Start with a good understanding of commercial
requirements
• What is the key use case and “true” requirement?
– Self directed museum tour?
• In which case latency will not be an issue
– Ability to locate specific venue (conference room, restaurant, etc.)
within a large venue or a product with turn by turn directions?
– “Presence detection” in stores in a shopping mall?
• Knowledge of the use case is key to understanding
location accuracy, latency requirements

AP Placement Guidelines (1)
• RSSI location uses triangulation techniques
– This needs at least three APs to receive a target’s transmissions at
relatively short range to give a good location.
• Best indicator of location accuracy is AP spacing
• Studies and experience show that regularly spaced APs
give the best overall location accuracy.
– Most WLAN planning tools produce a regular
grid pattern of APs in the absence of local
propagation information
• Our best advice is to take the output of such
tools – or a wireless engineer’s design with
regular AP spacing - and adjust the output to
take account of local knowledge:
• Areas that present special challenges or where
accurate location is more important should
receive special attention

AP Placement
Recommendation (2)
• Do:
– Place AP every 2500 sq. feet or 50 feet apart
– Cover the extremities!
– 65 dbm coverage (“Voice Grade)
– Ensure AP placement on floor plan is accurate
– Stagger AP placement in multi-floor buildings
• Do Not:
– Place AP in straight lines
– Design for coverage only & not enough density
• The standard topology is a ‘square’ grid pattern of APs,
but there is research indicating a hexagonal pattern
gives better results
• Aruba is testing this configuration

AP Placement: Voice Overlay Design

AP Placement Recommendations Summary
Recommendation Priority Comments
Voice Overlay 1
This is a must in all deployments to achieve
triangulation which is core requirement of
location calculation.
AP every 2500 sq. feet or 50
feet apart and cover the edges
1
This is help achieve a good coverage
pattern and triangulation and is must for
most deployments.
Hexagonal pattern for AP layout 2
This is recommended but might be hard to
achieve in certain scenarios due to the
physical layout.
-65 dbm coverage
2
This is strongly recommended but might be
hard to achieve in certain parts of a building.
In those cases, ensure that there is at least
a -75 dbm coverage in those areas.

RF Design Guidelines for Voice
and Video

Pervasive RF Coverage
• 100% coverage in all areas of Voice use
• Capacity based Wireless network design recommended
– Higher number APs operating with low TX Power
– Small Cell sizes, clients use higher data rates
Coverage design with 7.2 Mb/s cell edge Capacity design with 216.7 Mb/s cell edge

ARM Features for Voice
• Interference Aware
• Band Steering
• Spectrum Load Balancing
• Voice/Video Aware Scanning

Clientmatch
• Deterministic steering of clients based on the SNR
and signal level information gathered from client's
perspective
• Steering decision is based on the probes request
from the client
• Periodic load balancing
• Resolves Sticky-client issue

RF Design Best Practices for Voice
• Pervasive RF Coverage
• Distance between APs to not exceed 50 Ft
• Minimum RF signal (RSSI) levels of -65 dBm
• Minimum signal-to-noise ratio (SNR) of 25 dB
• Minimum and maximum AP power difference no
greater
than two steps
• Disable lower data rates
• In the Adaptive Radio Management™
(ARM) profile
– Enable voice/video aware scan
– ClientMatch™-enabled

RF Design Best Practices for Voice (continued)
• Configure Supported Beacon rate to higher rate
• Enable WMM Traffic Management
– Give higher of bandwidth to Voice and Video
• Enable Fair access
– Provide high % of bandwidth to a VAP (For example, assign
higher % bandwidth to Corp VAP than Guest VAP)

Best Practices for Video
• RF Best practices for Voice applies to Video as
well
• Best practices for Delivering multicast video
– Enable IGMP Snooping Or IGMP Proxy
– Enable Dynamic Multicast Optimization (DMO)
– Enable Decrypt-tunnel Dynamic Multicast Optimization (D-
DMO)

Designing a Roaming Network
• Difference in power levels on the deployed APs
should not be too high
• Airtime fairness is recommended in an
environment with mobile clients to avoid
slower clients taking too much airtime
• In a dot1x environment, enable EAPOL rate
optimization
• For faster roaming, use OKC and 802.11r
• Enable ClientMatch to help with sticky
client problem
• Match QoS markings that the devices are
using

Authentication / Encryption
Guidelines

Authentication/Encryption Guidelines
• 802.1x based authentication through radius
server may introduce delay during re-
association/roaming
• Use Opportunistic Key Caching
with 802.1x for faster roaming
• PSK works better for voice
devices (less delay), but not a
preferred method due to weak
security
• EAP-TLS provides the best security
and is preferred in enterprises rather
than EAP-PEAP

QoS Segments
LAN core LAN edge Wireless
Tagged DSCP, 802.1p Tagged DSCP, 802.1p WMM / strict queuing
Tagged DSCP, 802.1p Tagged DSCP, 802.1p WMM / SVP
Bandwidth management
call admission control QoS
aware RF management
Bandwidth
Management
Tagging
Upstream traffic
Downstream traffic

Deep Dive into DSCP and WMM
AC

QOS - Tunnel Mode Client No Tag (WMM Only)
Aruba
Mobility Controller
AP
Client-A,
VO: DSCP 0
Client-B,
VO: DSCP 0
DSCP 0
WMM BE
DSCP 24
WMM BE
DSCP 24
DSCP 24
VO: 46
VI: 34
BE: 24
Summary:
• AP looks at L2 Priority and puts the DSCP as per DSCM-WMM mapping in controller
• Controller decrypts the packet and uses L2 priority to assign DSCP mapping in
downstream direction
Controller decrypts the
packet and retags as per
L2 priority
AP looks at L2 priority and
puts DSCP as per DSCP to
WMM mapping

QOS - Tunnel Mode
(WMM Only)
Aruba
Mobility Controller
AP
Client-A,
VO: DSCP 46
Client-B,
VO: DSCP 46
DSCP 46
WMM VI
DSCP 34
WMM VI
DSCP 34
DSCP 34
Summary:
• AP looks at L2 Priority and puts the DSCP as per DSCM-WMM mapping in controller
• Controller decrypts the packet and uses L2 priority to assign DSCP mapping in
downstream direction
Controller decrypts the
packet and retags as per
L2 priority
puts DSCP as per DSCP to
WMM mapping
VO: 46
VI: 34
BE: 24

QOS - Tunnel Mode
(Lync Heuristics for Voice)
Aruba
Mobility Controller
AP
Client-A,
VO: DSCP 46
Client-B,
VO: DSCP 46
DSCP 46
WMM VI
DSCP 46
WMM VO
DSCP 46
DSCP 34
Summary:
• AP looks at L2 priority and puts the DSCP as per DSCM-WMM mapping in controller
• Lync heuristics determines the AC based on the codec. If the codec used is voice, it gives
DSCP value corresponding to voice.
Controller decrypts
the packet and retags
as per traffic type
puts DSCP as per DSCP
to WMM mapping
VO: 46
VI: 34
BE: 24

Troubleshooting and
Diagnostics

Troubleshooting Guidelines
• Are RF and other Configuration Best Practices in
place?
• Does your Network have end-to-end QoS?
• Can you isolate if it is an RF Network issue Or
Wired Network?
• If required, enable debugging at controller to get
detail logs
• For example, if you are using Voice ALGs (Sip,
Lync), enable the following command to
troubleshoot voice issues:
– (SE_PFE_1) (config) #logging level debugging user process
stm subcat voice
– (SE_PFE_1) (config) #show log user all

Troubleshooting and
Diagnostics Demo

Voice Overlay Airwave

Airwave – Client Troubleshooting

WLAN Design for Location

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a WLAN Design for Location

Semelhante a WLAN Design for Location (20)

Mais de Aruba, a Hewlett Packard Enterprise company

Mais de Aruba, a Hewlett Packard Enterprise company (20)

Último

Último (20)

WLAN Design for Location

Notas do Editor