Indicating a device has been detected in range of the WLAN
Entering or leaving a zone
Model, OS (as available from DHCP and browser user-agent)
Type of authentication, username
As detected by monitoring data-plane traffic from the device
As detected by monitoring data-plane traffic from the device
30:24 – 32:44
30:24 – 32:44
30:24 – 32:44
30:24 – 32:44
30:24 – 32:44
30:24 – 32:44
Worst case accuracy of 7.8 mtrs at 95% confidence
Military grade – 3 mtrs
The network APs in tandem with a RTLS analyze the device-based Wi-Fi signals to calculate the position of the device
This interaction enables the device apps to get their location from the network
however indoor GPS and proximity-based notifications require an app
(because the network does most of the work/calculation)
30:24 – 32:44
From Slide 17 & 18
Probe requests are attractive because they are generated by both non-associated and associated devices, provided Wi-Fi is enabled.
They cover multiple channels so they are detected by APs on different channels and APs don’t need to channel-switch – devices transmit bursts of probe requests across several channels when scanning.
And they are transmitted at low modulation rates so transmit power is high and relatively predictable, giving good accuracy (for RSSI)
The key drawback with probe requests is that there aren’t many of them.
Unassociated clients scan at intervals from 30 seconds to several minutes (approximate figures).
Associated clients with good signal strength may go longer between scans
Our measurements show that scans are often initiated only when the client is at some distance from its AP and its signal is poor
A pedestrian can cover 20+ meters before the smartphone will see fit to scan.
Device designers go to great pains to minimize scans in order to extend battery life
We believe that there will be ever-fewer probe requests over time
30:24 – 32:44
30:24 – 32:44
Distributed client health monitoring
Single feature that makes cohesive decisions in mapping clients to the best AP
30:24 – 32:44
30:24 – 32:44
IGMP snooping uses the WLAN controller to monitor which clients are subscribed to multicast video groups, and only sends multicast traffic to access points when required and even then only on a per-group basis.
IGMP proxy implements multicast routing by re-originating IGMP joins and leaves from the source of the controller. As an alternative to IGMP snooping, which works on a per-SSID tunnel basis and requires an external multicast router to generate the IGMP membership reports, IGMP proxy works on a per-client basis and does not require an external multicast router.
DMO Over-the-air transmissions can benefit from unicast transmissions depending on the number of clients in use. If only a small number of clients are subscribed to a multicast group, it can be more efficient to convert over-the-wire multicast to over-the-air unicast due to the faster data rates and prioritization capabilities of unicast connections. As this number grows, multicast gains in efficiency over unicast. Aruba’s DMO technology dynamically selects the appropriate conversion based on real-time network and video usage information. The conversion takes place at the controller at the 802.11 layer, on a client-by-client basis, and is transparent to the higher-level client layers.
- D-DMO With D-DMO, the multicast-to-unicast conversion happens at the AP instead of the controller. DMO is for VAPs in tunnel forwarding mode where the multicast-to-unicast conversion happens at the controller. For VAPs operating in decrypt-tunnel forwarding mode, the multicast-to-unicast conversion can be moved to the APs. So the VAPs that are operating in decrypt-tunnel forwarding mode implement D-DMO instead of DMO.
The bandwidth consumption on the link between the controller and APs is lower with D-DMO than DMO. This is because in D-DMO the transmissions between the controller and the APs are still multicast and the actual multicast-to-unicast conversion occurs only on the AP. With D-DMO, the controller sends multicast packets to APs only through the GRE tunnels of decrypt-tunnel mode VAPs that have active subscribers. The number of multicast streams through the GRE tunnel of a decrypt-tunnel VAP on an AP is equal to the sum of the number of multicast groups with active subscribers on each VLAN on that VAP.
30:24 – 32:44
30:24 – 32:44
30:24 – 32:44
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
Supports separate classification of audio and video streams
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
Eliminates the need for deep packet inspection
Adds Lync “Quality of Experience” (QoE) metrics for debugging
User establishes Lync call to another device
Call setup is through server, call is peer-to-peer
Lync server sends session information to Controller
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)
Controller sends app usage data to AirWave
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
The QoE server reports stats to the controller
Controller builds monitoring pages