WLAN Design for Mobile Apps #AirheadsConf Italy

WLAN Design for Mobile Apps

Balajee Krishnamurthy, Ashutosh DashJune 2014

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

2 #AirheadsConf

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


3 #AirheadsConf

Agenda

• Analytics and Location Overview

• ALE System Overview

• Indoor Location Technology

• Probing

• Recommendations

• Summary

4CONFIDENTIAL © Copyright 2014. Aruba Networks, Inc. All rights reserved

#AirheadsConf

Analytics and Location Overview


#AirheadsConf

Analytics & Location Ecosystem

Big DataAnalytics Partners

NetworkApplications

Cloud Applications

User Context(who, what, where, when)

Location Applications

(Wayfinding, etc)

Context:1. Location2. Applications3. Destinations4. Identity5. Device types

ALE (Context Aggregation)


#AirheadsConf

ALE System Overview


#AirheadsConf

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


#AirheadsConf

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


#AirheadsConf

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

Energymanagement

4

3

5

6


#AirheadsConf

ALE System Overview

LocalController

RemoteControllers

NETWORK

InstantAPs

Campus/Remote APs

VisualRF

SERVICES

Context aggregation, location engine

ALE VM

Location data forvisualization

on maps

APPLICATIONS

Context visualization, analytics

Northbound APIs:REST, Protobuf/OMQ

Context Data


#AirheadsConf

Understanding Probe Flow and Location

ALE

Client pulls its location from the

cloud every __ seconds?

Probes between few seconds to 10s of minutes1

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


#AirheadsConf

Indoor Location Technology


#AirheadsConf

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


#AirheadsConf

Device vs Wi-Fi Network Based Location

Device-based software

The device performs signal scans ofnearby 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


#AirheadsConf

Location Positioning Technology

How Information is Transmitted

GPS Geofencing

Cell Phone Triangulation

Cell Towers

How Info is Transmitted Hardware Required

Requ

ires

Ons

ite Finge

rprin

ting

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


#AirheadsConf

GPS –Triangulation from Satellites


#AirheadsConf

Indoor Location Positioning Technology

Wi-Fi must be turned on/enabled on the device

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.

Used by:


#AirheadsConf

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


#AirheadsConf

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


#AirheadsConf

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


#AirheadsConf

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


#AirheadsConf

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


#AirheadsConf

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


#AirheadsConf

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


#AirheadsConf

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


#AirheadsConf

AP Placement: Voice Overlay Design


#AirheadsConf

AP Placement Recommendations Summary

Recommendation Priority Comments

Voice Overlay 1This 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 2This 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.


#AirheadsConf

RF Design Guidelines for Voice & Video


#AirheadsConf

Multimedia over WLAN Challenges

RF Challenges End-to-End QoS Battery life & Roaming Scaling Challenges Unreliable protocol Low speed transmission

Video Data

RF challenges End-to-End QoS Battery life & Roaming Scaling Challenges Bandwidth management

(CAC) Mobility and Roaming

Voice

RF Challenges Battery life & Roaming Scaling Challenges

Voice + Video + Data???


#AirheadsConf

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


#AirheadsConf

ARM Features for Voice

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


#AirheadsConf

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


#AirheadsConf

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


#AirheadsConf

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)


#AirheadsConf

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)


#AirheadsConf

Designing a Roaming Network


#AirheadsConf

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


#AirheadsConf

Authentication/Encryption Guidelines


#AirheadsConf

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


#AirheadsConf

End-to-End QoS


#AirheadsConf

QoS with Aruba WLAN


#AirheadsConf

End-to-End QoS: WMM Support

1. Voice Data

2. Video Data

3. Best Efforts

4. Background

“Air”

High Priority

Low Priority

Application Data

1. WMM Specifies how priority queues map to DSCP and dot1P tags

2. Different access categories, different contention parameters

3. 4 queues per radio; 8 queues total; supported on all APs

4. Voice and video gets priority over data


#AirheadsConf

Incoming traffic is unmarked, and controller is not configured for any classification


#AirheadsConf

Incoming traffic is unmarked, and controller is configured for classification


#AirheadsConf

Re-marking Traffic


#AirheadsConf

Incoming traffic is unmarked, and Lync heuristics is enabled on the controller


#AirheadsConf

Incoming traffic is marked, and heuristics is enabled on the controller (MSFT use case)


#AirheadsConf

Incoming traffic is unmarked, and SDN API is enabled on the controller


#AirheadsConf

Incoming traffic is marked, and SDN API is enabled on the controller


#AirheadsConf

UCC


#AirheadsConf

Aruba Lync Solution

1. Heuristics based detection – Lync traffic is identified based on known characteristics of Lync Voice and Video. As the Lync traffic traverses the controller it is inspected and classified as either Voice or Video and the appropriate QoS settings are applied to them.

2. SDN API based detection – Lync traffic is identified through the integration between the Lync Front End server and the WLAN controllers via Microsoft’s SDN API. The Lync front End server sends messages to the Aruba Controller identifying Lync traffic by type and endpoint.


#AirheadsConf

Lync Heuristics

• Called “Classify Media”

• Create an ACL to trigger deeper inspection of traffic• ACL triggers on ports used for UCC• May need to include IP address or hostname as well

• Once the ACL triggers, we analyze traffic from the client

• If the traffic looks like a supported audio or video stream format, we will QoS it appropriately

52


#AirheadsConf

What does an administrator get with Lync Heuristics today?

Today information available to an administrator is as follows– Visibility into video and voice calls– QoS for voice and video– CDR info(partial – no name of user, direction of the call)

In a future release (6.4.2, July/August timeframe)– Calculation of UCC score, delay, jitter and packet loss– UCC dashboard on controller can be used for real time correlation,

visibility, troubleshooting and diagnostics– UCC score would be a metric calculated over the wireless link for

downstream direction only

Why would a customer use Heuristics over SDN API today– Does not have the capability to use SDN API– Office 365– Aruba Instant based network in place


#AirheadsConf

Beyond Heuristics: Direct Integration with Microsoft Lync Server

• Heuristics are never perfect

• Microsoft SDN API Integration

• Uses information directly from the Microsoft server for fine-grained application identification

• Allows separate detection and QoS for Voice, Video, Desktop Sharing, and File Sharing in real time

• Eliminates the need for deep packet inspection on the controller

• Adds Lync “Quality of Experience” (QoE) metrics for debugging


#AirheadsConf

Lync SDN QoS Flow

1. User establishes Lync call to another device

– Call setup is through server, call is peer-to-peer

2. Lync server sends session information to Controller

3. Controller uses data for QoS and AppRF visibility

– Voice gets DSCP 56 (0x38)– Video gets DSCP 40 (0x28)– Desktop Sharing gets DSCP 40 (0x28)– File transfers get DSCP 24 (0x18)

4. Controller sends app usage data to AirWave

AirWave

2

1

4

3


#AirheadsConf

Lync SDN– Collecting call data

1. At the end of each call, the call participants send data on call quality to the Quality of Experience (QoE) server - a component of Lync

2. The QoE server reports stats to the controller

3. Controller builds monitoring pages

1

2

3


#AirheadsConf

What does an administrator get with Lync SDN API

Today information available to an administrator is as follows– Visibility into voice, video, desktop sharing and file transfer – QoS for voice, video, desktop sharing and file transfer – UCC score for real time correlation– Offer MOS scores for end-to-end visibility– Complete CDR which includes caller names, different legs of the call etc.

In a future release (6.5)– Work with Lync SDN API 2.1 for in-call quality metrics• MOS or UCC metric can be used for correlation

– Discussion around what other information can be used from QoE server to enhance visibility/debug ability is in place

Why would a customer use SDN API over heuristics– No guesswork, 100% confirmed data– End-to-end visibility etc.



#AirheadsConf

Deployment Guidelines - All Master Scenario


#AirheadsConf

Deployment Guidelines - Master-Local Scenario


#AirheadsConf

Deployment Guidelines - Controller based Branches


#AirheadsConf

Deployment Guidelines - IAP based Branches


#AirheadsConf

Deployment Guidelines - RAP based Branches


#AirheadsConf

Multi-Site Voice Architecture


#AirheadsConf

Troubleshooting and Diagnostics


#AirheadsConf

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


#AirheadsConf


Thank You

#AirheadsConf

WLAN Design for Mobile Apps #AirheadsConf Italy

Technology

aruba networks

confidential copyright

location ale client

airheadsconf data

airheadsconf agenda

real time location engine

protobufomq context

user user